Hi,
i now have clear evidence from a run of
sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
that the read attempt for sector 0xffffffff (= -1) brings the
ASUS DRW-24D5MT into the unusable state.
@ Mauro Sacchetto:
Could you please try to reproduce this finding after installing sg3-utils.
The main suspect for emitting SCSI this command is Brasero function
brasero_medium_track_written_SAO()
in libbrasero-media/brasero-medium.c .
Code study of that function and the logs of Brasero "Copy" runs with
the Pioneer and the TSSTcorp show that bad things happen if the function
is called:
- The Pioneer drive does not trigger the log message from
brasero_medium_track_written_SAO()
and leaves no problem report lines in dmesg.
So i conclude that the function was not called.
- The TSSTcorp drive triggers this message:
BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.
and dmesg reports a (successful / harmless ?) USB reset.
-------------------------------------------------------------------------
Possible remedies:
We would need a Brasero developer to find a workaround, because not
only the bad READ CD command needs to be avoided, but also a replacement
for the code gesture to distinguish TAO CDs from SAO CDs would have to
be developed.
Maybe this distinction is not really necessary. It seems not to work
properly on the TSSTcorp drive by making a false correction of the
track size. But that would be up to a Brasero developer to decide.
A cheaper workaround would be to identify the drive model from the
function parameter
BraseroDeviceHandle *handle
and to return before any read attempt if it is an ASUS DRW-24D5MT
and maybe others, which still need to have been found.
Again it would be up to a Brasero developer to decide whether TRUE or
FALSE would be the best reply in this case.
Maybe it would be possible to read that sector by SCSI command
READ CD MSF with address 00:01:74.
(The track begins at 00:02:00. Brasero wants one sector before that
start which to my computation would be 00:01:74.)
-------------------------------------------------------------------------
Experiments made:
I tried the "Copy" task of Brasero with the TSSTcorp drive in its USB box
at /dev/sr2.
Other than with the Pioneer at /dev/sr1, this run reports
BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found
BraseroMedia: (at brasero-medium.c:1645) Retrieving track information for 1
BraseroMedia: (at brasero-medium.c:1715) Data track belongs to first session
of multisession CD. Checking for real size (193686 sectors currently).
BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.
BraseroMedia: (at brasero-medium.c:1742) Correcting track size (now 193688)
which indicates that Brasero thinks this CD was written with write
type SAO.
But i burnt it with xorriso -as cdrecord -tao. libburn's demo program
telltoc reports that blocks 193687 and 193688 are not readable and thus
supposes the CD to be burnt by TAO.
Later the log confrims telltoc's findings:
BraseroBurn: (at burn-process.c:417) BraseroCdrdao stderr: Found L-EC error
at sector 193686 - ignored.
BraseroBurn: (at burn-job.c:1430) BraseroCdrdao called brasero_job_get_action
BraseroBurn: (at burn-process.c:417) BraseroCdrdao stderr: Found L-EC error
at sector 193687 - ignore
("L-EC error" would mean a medium problem. So the drive maybe contributes
to the confusion of Brasero. dmesg reports the same errors, probably from
blkid inspecting the medium for an UDF anchor.)
dmesg reports around the time when Brasero was inspecting the drive:
usb 1-13: reset high-speed USB device number 5 using xhci_hcd
and with another "Copy" task again:
usb 1-13: reset high-speed USB device number 5 using xhci_hcd
Whatever, the drive stays usable and no error of READ CD for sector
0xffffffff is reported in dmesg.
--------------------------------
Poking manually into that drive:
# apt-get install sg3-utils
$ sg_raw /dev/sr2 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
>>> transport error: Host_status=0x03 [DID_TIME_OUT]
Driver_status=0x00 [DRIVER_OK]
SCSI Status: Good
and another USB device reset is reported in dmesg
usb 1-13: reset high-speed USB device number 5 using xhci_hcd
Still the drive is usable afterwards.
----------------------------------------------------
Now the decisive test with /dev/sr0, the ASUS drive:
No Brasero is running.
After inserting the CD into /dev/sr0, i see in dmesg complaints about
i/o errors with the last two blocks. This time not "L-EC error" but
rather "Illegal Request", as i would expect from the specs.
The drive is usable for xorriso.
So:
$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
SCSI Status: Check Condition
Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Unaligned write command
dmesg reports
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata3.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 11
Volume set (in), Read cd be 00 ff ff ff ff 00 00 01 10 00 00res
40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: hard resetting link
The drive is now unusable for xorriso:
libburn : FAILURE : SCSI command 12h yielded host problem: 0x4
SG_ERR_DID_BAD_TARGET (Bad target, device not responding ?)
libburn : FAILURE : Command: INQUIRY : 12 00 00 00 24 00 : dxfer_len= 36
dmesg reports about this xorriso attempt:
sr 2:0:0:0: [sr0] tag#15 FAILED Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK cmd_age=0s
sr 2:0:0:0: [sr0] tag#15 CDB: Test Unit Ready 00 00 00 00 00 00
So i can now trigger the drive problem without Brasero.
-------------------------------------------------------------------------
I think my skills as burn programmer are exhausted now.
Have a nice day :)
Thomas
