Hi, Summary: - Sorry for confusion about libcdio. - The drive is a bit strange with its replies. - There is a bus-or-power problem reported in the run of 1.3.2 which causes comand repetition and error 5 21 02 "ILLEGAL REQUEST". - The runs of 1.3.4 and 1.3.8 ended by the 0x7 SG_ERR_DID_ERROR indication from the kernel. - All runs were of write type DVD-R DAO. One could try type DVD-R Incremental. - At the end of this mail is a proposal for an experimental code change in libburn in case of the error of the 1.3.2 run.
======================================================================= > dmitry@D-NESTERKIN:~/libburn-1.3.4$ sudo cdrskin/compile_cdrskin.sh > compiling program cdrskin/cdrskin.c cdrskin/cdrfifo.c -O2 > -DCdrskin_libburn_1_3_4 libburn/cleanup.o > ... > /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:567: undefined reference to `cdio_get_arg' I now see in the script cdrskin/compile_cdrskin.c that libcdio is linked only if you run it with option -use_libcdio cdrskin/compile_cdrskin.sh -use_libcdio sudo should not be necessary if you unpack the tarball as normal user. Strange thing. I tested with cdrskin-1.3.2.pl01.tar.gz and it worked after i installed package libcdio-dev on my quite young system. Probably i ran cdrskin/cdrskin already after make. That's some autotools magic which might work or not. cdrskin/cdrskin is a shell script after "make". My dpkg -l reports the same Debian libcdio packages as yours: ii libcdio-cdda1 0.83-4.2 amd64 library to read and control digital audio CDs ii libcdio-dev 0.83-4.2 amd64 library to read and control CD-ROM (development files) ii libcdio-paranoia1 0.83-4.2 amd64 library to read digital audio CDs with error correction ii libcdio13 0.83-4.2 amd64 library to read and control CD-ROM ======================================================================= Your dropbox files: cdrskin-1.3.2.log : ---------------------------------------------------------------------- START/STOP UNIT 1b 00 00 00 03 00 +++ sense data = 70 00 05 00 00 00 00 0E 00 00 00 00 24 00 00 00 00 00 +++ key=5 asc=24h ascq=00h ---------------------------------------------------------------------- 5 24 00 means "INVALID FIELD IN CDB". (CDB is the SCSI command.) I guess the drive has no tray motor and dislikes the command to pull in the tray. After only 6.531 seconds of the burn run, WRITE(10) gets an error reply, which causes libburn to re-try: ---------------------------------------------------------------------- WRITE(10) 2a 00 00 00 03 10 00 00 10 00 +++ sense data = 70 00 02 00 00 00 00 0E 00 00 00 00 04 08 00 00 00 00 +++ key=2 asc=04h ascq=08h 1286 us [ 6531319 ] ---------------------------------------------------------------------- 2 04 08 is "LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS". This means that one should retry later in the hope that the drive gets ready. But normally a drive just waits with the reply until it is ready to take the next chunk of data (usually 32 KB). All byte codes are shown in hex notation. The bytes 2 to 5 "00 00 03 10" of WRITE(10) are the block address in big endian. I.e. 768 in decimal. Well, after nearly 50 seconds it goes on: ---------------------------------------------------------------------- WRITE(10) 2a 00 00 00 03 10 00 00 10 00 1685 us [ 54599719 ] WRITE(10) 2a 00 00 00 03 20 00 00 10 00 +++ sense data = 70 00 02 00 00 00 00 0E 00 00 00 00 04 08 00 00 00 00 +++ key=2 asc=04h ascq=08h 1320 us [ 54601087 ] ... WRITE(10) 2a 00 00 00 03 20 00 00 10 00 1771 us [ 54610346 ] WRITE(10) 2a 00 00 00 03 30 00 00 10 00 +++ sense data = 70 00 02 00 00 00 00 0E 00 00 00 00 04 08 00 00 00 00 +++ key=2 asc=04h ascq=08h 1207 us [ 54611606 ] ---------------------------------------------------------------------- This is strange drive behavior but still plausible for a DVD-R in DAO mode. But then comes an error reply which i have never seen before: ---------------------------------------------------------------------- WRITE(10) 2a 00 00 00 04 00 00 00 10 00 2298537 us [ 57069348 ] WRITE(10) 2a 00 00 00 04 10 00 00 10 00 +++ sense data = 70 00 06 00 00 00 00 0E 00 00 00 00 29 00 00 00 00 00 +++ key=6 asc=29h ascq=00h 774800 us [ 57844400 ] ---------------------------------------------------------------------- MMC-5 lists it as 6 29 00 "POWER ON, RESET, OR BUS DEVICE RESET OCCURRED". libburn perceives the error class 6 "Drive Event" as worth a retry. This leads to ---------------------------------------------------------------------- WRITE(10) 2a 00 00 00 04 10 00 00 10 00 +++ sense data = 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00 00 00 +++ key=5 asc=21h ascq=02h 5247 us [ 57849725 ] cdrskin: FATAL : SCSI error on write(1040,16): [5 21 02] Illegal request. Invalid address for write. ---------------------------------------------------------------------- Possibly the drive wants a write to the next address which would have been valid if the previous WRITE(10) command had succeeded. The two runs of 1.3.4 and 1.3.8 do not show the error 6 29 00, but rather end by the known 0x7 SG_ERR_DID_ERROR indication from the kernel. ======================================================================= Do you get better results if you try DVD-R write type "Incremental" ? It resembles much CD write type TAO and thus gets enabled by cdrskin option -tao: cdrskin/cdrskin -tao -V dev=/dev/sr0 blank=as_needed -eject image.iso \ 2>&1 | tee -i /tmp/cdrskin-1.X.Y.tao.log It will take less time before writing starts. Maybe the preparations for DAO consume too much electricity. ======================================================================= Proposal for a code change to better handle 6 29 00 "POWER ON, RESET, OR BUS DEVICE RESET OCCURRED": In File libburn/spc.c there is a code piece case 0x29: if (*ascq == 0) sprintf(msg, "Power on, reset, or bus device reset occured"); else if (*ascq == 1) ... goto return_retry; case 0x2c: There you could change the outcome decision from goto return_retry; case 0x2c: to return GO_ON; case 0x2c: If this succeeds then i would like to see another SCSI log of a sucessful run. This drive is interesting, at least. ======================================================================= Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org