Re: growisofs failing on some iso files

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> not only in Fedora [1] but also in Ubuntu [2] there is an issue when burning
> DVDs using growisofs (a utility from dvd+rw-tools). The error occurs when
> burning only some iso files, basically files that have different size than a
> multiple of 32kB. The error looks like this:
> 
> :-[ WRITE@LBA=350h failed with SK=0h/ASC=00h/ACQ=03h]: Input/output 
> error :-(
> write failed: Input/output error

This is a strange error reply (SCSI Sense Code).
SK=0 means according to SPC-3 4.5.6:
"NO SENSE:
 Indicates that there is no specific sense key information to be reported.
 This may occur for a successful command or for a command that receives
 CHECK CONDITION status because one of the FILEMARK, EOM, or ILI bits is
 set to one."

ASC=00h/ACQ=03h means:
"SETMARK DETECTED"
In SPC-3, "Setmark" is related to a command EXTENDED COPY. I am not aware
that growisofs would use it.
In MMC-6, which is in charge for DVD specifics, no "Setmark" is mentioned.

So i would say this is a stray SCSI diagnostic reply. Either caused by
a drive firmware bug, or a courtesy of the operating system transport
layer.


> Any comments on the patch are welcome

The DVD specs do not prescribe that a DVD DAO session has to be aligned
to 16 blocks.

For the sake of ISO image verification it is desirable to have a DVD
session of exactly the image size. At least on media types which can
represent such a session.

So i'd say that at least this alignment should be triggered by a new
-use-the-force-luke sub-option.
See growisofs.c after:
            else if (!strncmp(opt,"-use-the-force-luke",19))

---------------------------------------------------------------------------

But actually one should make the burn program properly handle a sense code
with SK=0. If it is such a code at all.

I am staring at transport.hxx now:

#define ERRCODE(s)      ((((s)[2]&0x0F)<<16)|((s)[12]<<8)|((s)[13]))
#define SK(errcode)     (((errcode)>>16)&0xF)
#define ASC(errcode)    (((errcode)>>8)&0xFF)
#define ASCQ(errcode)   ((errcode)&0xFF)

The first macro assumes flatly to deal with "Fixed format sense data".
There is another form named "Descriptor format sense data" where the three
status bytes are located at positions 1, 2, 3 rather than at 2, 12, and 13.

No MMC drive is supposed to emit the "Descriptor" format. But the Linux
kernel has been caught to confuse cdrecord by this format.
Google for "Sense Bytes: 72". These are in "Descriptor" format.
In contrast to "Sense Bytes: 70" which are in "Fixed" format.

This here could be the same problem with wodim rather than growisofs:
  http://forums.fedoraforum.org/archive/index.php/t-260389.html


Method Scsi_Command.transport() in transport.hxx issues the SCSI command:
            if (ioctl (fd,SG_IO,&sg_io)) return -1;
If the kernel indicates available sense data it does
                {   ret = ERRCODE(_sense.u);
                    if (ret==0) ret=-1;
                    else        CREAM_ON_ERRNO(_sense.u);
                }

So it returns non-zero is the status byte triple is not (0,0,0).
In the light of above SPC-3 prescription, it would be plausible to
return 0 if (SK(ret) == 0).

The macros are valid only if _sense.u[0] is 0x70 or 0x71.

For byte values 0x72 and 0x73 one would have to beef up the macro
which produces the 20 bit error code.
Like (untested):
#define ERRCODE_FIXED(s)      ((((s)[2]&0x0F)<<16)|((s)[12]<<8)|((s)[13]))
#define ERRCODE_DESCR(s)      ((((s)[1]&0x0F)<<16)|((s)[2]<<8)|((s)[3]))
#define ERRCODE(s)            ((s)[0] == 0x70 || (s)[0] == 0x71 ? \
                                ERRCODE_FIXED(s) : \
                               ((s)[0] == 0x72 || (s)[0] == 0x73 ? \
                                ERRCODE_DESCR(s) : 0))


If my found wodim error is really the same, then we actually have:
  Sense Bytes: 72 0B 00 00 00 00 00 0E 09 0C 00 00 00 03 00 00
  Sense Key: 0x0 No Additional Sense, Segment 11
  Sense Code: 0x00 Qual 0x03 (setmark detected) Fru 0x0
  Sense flags: Blk 0 (not valid) 
  ...
  write track data: error after 952320 bytes

Interpreted by growisofs it would appear like with wodim as:
  SK=0 ASC=0 ASCQ=3
But in reality it means:
  SK=0xB ASC=0 ASCQ=0
according to SPC-3:
  "COMMAND ABORTED" "NO ADDITIONAL SENSE INFORMATION"

This really looks like one should ask the kernel folks if by any chance
they emit(ted) this SCSI error artificially (and under what circumstances).
Or maybe it comes from the bus controller ?


> and feel free to use the patch if there is still any development
> in dvd+rw-tools.

Andy ? Are you still out there ?

------------------------------------------------------------------------

It would be interesting to see whether current versions of my programs
cdrskin and xorriso would do better in this situation.
If not, then the SCSI command log of a failed run might bring insight:
  cdrskin -V ...
  xorriso -scsi_log on ...

The only media types where DAO is applicable are DVD-R and unformatted DVD-RW.
DVD-RW have to be blanked before re-use:
  cdrskin -v dev=/dev/sr0 blank=fast
  xorriso -outdev /dev/sr0 -blank deformat_quickest


I will review the code of libburn and probably try to simulate the drive
quirk. But for that i'd need to know exactly the funny status message that
reaches the burn program. Especially if growisofs misinterprets it.


Have a nice day :)

Thomas