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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
