Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Thomas Schmitt]

Hi,

i made the experiments which i mentioned in the previous mail:

- The Pioneer drive does not go mad from READ CD for LBA -1 or from
  READ CD MSF for sector 00:01:74.

- The ASUS drive does not go mad from READ CD MSF for sector 00:01:74.

- The TSSTcorp drive tolerates READ CD MSF for sector 00:01:74 without
  a message in dmesg about USB reset. (It did that reset with READ CD for
  LBA -1 but showed no lasting problem.)

None of the drives reports success with the READ CD MSF command. So with
this command the Brasero function brasero_medium_track_written_SAO()
would return TRUE, which is wrong with the given CD.

The desire to read the Lead-in sector before the start of the payload
data simply seems not fulfillable here for the first track of a CD.

Brasero will have to abandon this idea or come up with a better read
command - which i currently fail to imagine.

-------------------------------------------------------------------------
The SCSI specs say that LBA -1 is bad:

While exploring how to encode the READ CD MFS command for 00:01:74, i found
this statement in the MMC-5 specs:
  "3.2.21 Method 1 Addressing
   [...] Method 1 logical sector numbering is not defined for
   sectors outside of the program area."
This sector numbering is in effect with command READ CD. The "program area"
is the payload part of the CD with a single track.
So READ CD with logical block address -1 is not defined.

-------------------------------------------------------------------------
Experiments with the ASUS drive:

(Anybody remembers BCD number encoding ? I can be glad that they did not
choose to use Gray codes. BCD is easy to write in hex. :))

The READ CD MSF expects an inclusive start address (here 00:01:74) and
an exclusive end address (here 00:02:00). Except the address fields it
has the same byte layout as READ CD. So the command as replacement for
the bad READ CD command

  be 00 ff ff ff ff 00 00 01 10 00 00

is

  b9 00 00 00 01 74 00 02 00 10 00 00

This does not yield a good result in form a of data, but also no bad
consequences for the drive or complaints from the transport layer in dmesg.

  $ sg_raw /dev/sr0 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin
  SCSI Status: Check Condition

  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: Invalid field in cdb

  Error 5 occurred, no data received

(I meanwhile learned that i need to tell sg_raw to expect a certain number
of bytes as reply. My choice 2352 is the size of CD-DA payload. The data
CD is supposed to deliver only 2048 bytes of payload. I tried a request
size of 2048, but the behavior of sg_raw did not change.)

In order to prove that my SCSI command is correctly encoded, i asked for
the first valid payload block at 00:02:00 = LBA 0 :

  $ sg_raw /dev/sr0 b9 00 00 00 02 00 00 02 01 10 00 00 --request=2352 --outfile=tdb_data.bin
  SCSI Status: Good

  Writing 2352 bytes of data to tdb_data.bin

The file tdb_data.bin shows the MBR data of the Debian netinst ISO.
The same result i get with a valid READ CD command for LBA 0:

  $ sg_raw /dev/sr0 be 00 00 00 00 00 00 00 01 10 00 00 --request=2352 --outfile=tdb_data.bin

None of these experiments caused problems like with Brasero.

-------------------------------------------------------------------------
What does PIONEER BD-RW BDR-S09 say to such commands:

  $ sg_raw /dev/sr1 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin
  SCSI Status: Check Condition

  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: Invalid field in cdb

  Error 5 occurred, no data received

The drive is still usable and dmesg shows no new complaints.
(Except blkid's graceful failures to read the Run-out blocks.)

With CDB b9 00 00 00 02 00 00 02 01 10 00 00 i get the first data block
from the CD: the isohybrid MBR, which xorriso inserted when it created
the ISO for the debian-cd project.

Now for the ugly test:

  $ sg_raw /dev/sr1 be 00 ff ff ff ff 00 00 01 10 00 00 --request=2352 --outfile=tdb_data.bin
  SCSI Status: Check Condition

  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: Logical block address out of range

  Error 22 occurred, no data received

It turns out that this drive and its transport layers in the kernel can
stand the bad READ CD command.
No dmesg complaints to see from this experiment. xorriso still works with
the drive.

This quite kills the theory that the kernel transport layer gets a hickup
without the help of the drive's SATA interface.

So the ASUS drive indeed has a stake in the problem.

-------------------------------------------------------------------------
And the TSSTcorp CDDVDW SH-S223B :

  $ sg_raw /dev/sr2 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin
  SCSI Status: Check Condition

  Sense Information:
  Fixed format, current; Sense key: Illegal Request
  Additional sense: Invalid field in cdb

  Error 5 occurred, no data received
  $ sg_raw /dev/sr2 b9 00 00 00 02 00 00 02 01 10 00 00 --request=2352 --outfile=tdb_data.bin
  SCSI Status: Good

  Writing 2048 bytes of data to tdb_data.bin
  $

No dmesg messages to see. xorriso still works with the drive.


Have a nice day :)

Thomas