[Pkg-libburnia-devel] Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Thomas Schmitt
scdbackup at gmx.net
Thu Jun 25 15:21:06 UTC 2015
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 at 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
More information about the Pkg-libburnia-devel
mailing list