Re: vd+rw-tools 7.1, Blu-Ray, and INVALID FIELD IN CDB on session close
Hi,
First a summary and proposals:
Currently it seems to me that this is the old
concurrent disturbance problem as of CD and
DVD-R, although it is yet unknown with BD-R.
Its randomness would match a race condition
about a reader process which tries to inspect
the media while xorriso begins to write it.
Do you see fresh error messages in dmesg after
you inserted a blank media ?
Some complain about unreadable Table-of-content
or some read error ?
Those complaints would come from CD inspecting
entities of the operating system. E.g. hald.
(I kill hald-addon-storage processes which
are set to watch my drives. To find them:
ps -ef | grep 'addon-storage.*sr'
)
Another workaround would be to load the media
and to wait until all blinking stopped.
This should give the OS demons opportunity to
inspect the media and to then stay away from it.
Elsewise i can only recommend that you use
growisofs with BD-R and wait for it to fail like
the others.
If it never fails then you are lucky and i am
quite clueless.
If you want to make use of xorriso as ISO 9660
formatter. you can foist it under growisofs by
export MKISOFS=xorrisofs
and then
growisofs -Z /dev/sr1 ...mkisofs options...
or
growisofs -Z /dev/sr1 -- outdev - ...xorriso options...
xorrisofs is a link to xorriso which causes it
to start up in mkisofs emulation. This is
necessary because growisofs gives some mkisofs
options unconditionally.
By argument "--" you can leave mkisofs emulation
and get to the main command interpreter of
xorriso.
------------------------------------------------
Now for the details:
> New problem: After using xorriso successfully for several burns, now it
> works no longer, but fails with "Invalid address" almost immediately after
> formatting a new blank BD-R disc.
>
> $ xorriso -dev /dev/sr1 -volid "etc" -add * -- -commit_eject all
> ...
> xorriso : UPDATE : Writing: 2640s 0.0% fifo 78% buf 28%
> libburn : FATAL : SCSI error on write(3600,16): [5 21 02] Invalid address
This looks much like the cdrskin failure from
your initial mail.
> FATAL : SCSI error on write(3632,16): [5 21 02] Invalid address
As said then, this is a usual effect with CD-R[W]
and DVD-R[W] if other processes try to read from
the media while writing is going on.
But it is unusual that BD-R show that problem.
> As usual there are no useful SCSI errors in the kernel messages.
That is because all burn programs have to use
generic SCSI drivers and send own SCSI commands.
The error messages in the kernel log mostly stem
from higher device driver levels which use the
same transport mechanism for their commands.
Our errors are reported by our programs to their
output terminals.
There is nothing more known than that the drive
dislikes the command to write 32 kB to block
address 3600.
That means about 7 MB of data have been accepted
by the drive before. That is more than the drive
buffer size. So it must have already started
physical writing at that time.
Suddenly it decides that after 225 consequtive
write operations the 226th is directed to a bad
address. (With the cdrskin failure it was 227
successfull WRITEs.)
A plausible reason would be if the failing WRITE
command would not be directed to the Next
Writeable Address as expected by the drive.
But i am very sure that libburn increments the
WRITE addresses correctly after each transaction.
Another reason would be if the drive quitted the
state of sequential burning. This happens with
CD and DVD-R if it encounters commands other than
WRITE and some harmless inquiry commands.
Not harmless are READ or inquiry of the media's
Table-of-content.
> I updated firmware of BDR-205 to
> version 1.04, power cycled drive, then tried again with the same result.
> Then out of exasperation I tried growisofs -Z /dev/sr1 -rJ -V"etc" . and
> it gives me no problems except for the usual error in subject:
Currently i would assume a random error cause.
We had a time period when cdrskin failed and
xorriso succeeded, although they share the burn
code.
Differences between growisofs and libburn:
- growisofs automatically unmounts media if they
are still mounted.
But that should make no difference with
a blank BD-R.
- growisofs uses write mode BD-R SRM with
Pseudo-Overwrite, whereas libburn uses BD-R SRM
without Pseudo-Overwrite.
But that difference should only show up at the
very end of the burn run. Not already after
7 MB.
> READ TRACK INFORMATION[#1]:
> Track State: partial incremental
> Track Size: 11244672*2KB
> Last Recorded Address: 879*2KB
> ...
> And then a retry burn:
> $ xorriso -dev /dev/sr1 -add * -- -commit_eject all
> libburn : WARNING : Last session on media is still open.
> ...
> xorriso : FATAL : Cannot read ISO image tree
> ...
> xorriso : aborting : -abort_on 'FATAL' encountered 'FATAL'
The first track is already recorded partially but
was not closed properly by the failed run.
xorriso was instructed by option -dev to look for
an existing ISO 9660 image. It found a damaged
one and decided to abort rather than to operate
on a bad directory tree.
The BD-R media is spoiled, i fear.
One could close the open track to make the rest
of the media usable again. But that would be
only 2 GB and it would need a specially prepared
ISO image to have it mountable.
Have a nice day :)
Thomas
Reply to: