Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD

[Thomas Schmitt]

Hi,

for now i can only guess that something about transmission of Sense data
is wrong. The drive is supposed to indicate to TEST UNIT READY that
Sense data are available. The kernel is then supposed to issue a REQUEST
SENSE command to retrieve the Sense data.

On NetBSD this is done by ioctl(SCIOCCOMMAND) which is then supposed to
indicate the presence of Sense data by scsireq_t.retsts so that libburn
can copy the sense data info to its own struct command *c and local variable
sense_len.
libburn/sg-netbsd.c:

                if (req.retsts == SCCMD_SENSE) {
                        memcpy(c->sense, req.sense, max_sl);
                        sense_len = req.senselen > max_sl ?
                                                         max_sl : req.senselen;
                }

The drive is supposed to produce Sense data like this hex string:

   71 00 02 00 00 00 00 0A 00 00 00 00 04 07 00 80 00 00

The format is specified in SPC-3, 4.5.3 "Fixed format sense data".
KEY is in the lower 4 bits of byte offset 2. Here value 2.
ADDITIONAL SENSE CODE is at byte offset 12. Here value 4.
ADDITIONAL SENSE CODE QUALIFIER is at byte offset 13. Here value 7.

My best bet is that the 4 and the 7 do not make it to libburn's data.

There is a macro case in libburn/sg-netbsd.c:

  /* #define Libburn_debug_sg_netbsD */
  #ifdef Libburn_debug_sg_netbsD
                   fprintf(stderr, "libburn_DEBUG: ret= %d, retsts = 0x%X, ...

which tells the outcome reported by the ioctl().
Maybe we can learn something from the reported numbers.


-------------------------------------------------------------------------
Motivation for my guess:

The problem appears only after quite some drive inspection happened
successfully.
Only with SCSI command BLANK, there suddenly appear implausible Sense data
(i.e. error indications).

I am now trying to understand
  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/
especially function scsi_ioc_cmd() in
  
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/scsi_ioctl.c?rev=1.52&content-type=text/x-cvsweb-markup
scsi_xs_sync() and scsi_xs_exec() in
  
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/scsi_base.c?rev=1.224&content-type=text/x-cvsweb-markup
where i end up at

        /* The adapter's scsi_cmd() is responsible for calling scsi_done(). */
        KERNEL_LOCK();
        xs->sc_link->adapter->scsi_cmd(xs);
        KERNEL_UNLOCK();

which looks very bus controller oriented.
I'd assume that any specific interpretation of the SCSI command BLANK
should have happened before. None to see.

But as already stated, KEY = 2 together with ASC, ASCQ = 0,0 is not what
a drive should emit.


Have a nice day :)

Thomas