strange ide-cd MODE_SENSE response [2.6.8.1]

strange ide-cd MODE_SENSE response [2.6.8.1]

[Douglas Gilbert]

In lk 2.6.8.1 (and 2.6.7) if a MODE_SENSE (6 byte variant) is sent
to an "ide-cd" device (e.g. /dev/hdc) then it responds with a
"CONDITION MET" SCSI status and no sense buffer.

According to MMC, MODE_SENSE (6) is not supported. In this case a
polite SCSI device should set a SCSI status of "CHECK CONDITION"
with a sense key of ILLEGAL_REQUEST and appropriate ASC/ASCQ
values (i.e. operation code not supported).

The relevant code in ide-cd.c seems to be:

         /*
          * it's silly to pretend we understand 6-byte sense commands, just
          * reject with ILLEGAL_REQUEST and the caller should take the
          * appropriate action
          */
         if (c[0] == MODE_SENSE || c[0] == MODE_SELECT) {
                 rq->errors = ILLEGAL_REQUEST;
                 return BLKPREP_KILL;
         }

I couldn't see how that BLKPREP_KILL was processed.

Why have such code? I have a Yamaha SCSI cd writer that
correctly supports MODE_SENSE (6) and MODE_SENSE (10).
Support for MODE_SENSE (10) is mandatory in the MMC
standard but it would be surprising if it said a
MMC device could _not_ support MODE_SENSE (6).

The failure can be seen with the sg3_utils package and
commands like this:
    sg_modes -6 /dev/hdc
    sginfo -C -6 /dev/hdc


Doug Gilbert

Re: strange ide-cd MODE_SENSE response [2.6.8.1]

[Pat LaVarre]

// In short:

Me too.

I find PATAPI in Linux opaque here, not transparent.

// At length ...

 > Subject: strange ide-cd MODE_SENSE response [2.6.8.1]

Yes a device that fails without providing auto sense has spoken rudely 
to the host.

 > a MODE_SENSE (6 byte variant) ...
 > sent to an "ide-cd" device (e.g. /dev/hdc)
 > "CONDITION MET" SCSI status and no sense buffer.

Analogously, my more naive parse of ioctl SG_IO results yielded ...

... a check condition without intelligible sense and also a complaint 
of positive residue i.e. less data bytes copied than requested for the 
CDB.

Like you, I have devices that identify themselves as implementing SFF 
SCSI = MMC yet also in fact for compatibility choosing to implement the 
option of ANSI SCSI.  My devices are Iomega REV drives.  Contrasting 
what I get from the same device via USB or via ATAPI, I see:

  $ # usb-storage USB copies in data and good status
  $ uname -msr
  Linux 2.6.8.1 i686
  $
  $ sudo plscsi /dev/scd0 --please -i 4 -x "1A 3F:00:00 04 00" -v
  x 00000000 1A 3F:00:00 04 00 .. .. .. .. .. .. .. .. .. .. "Z?@@D@"
  x 00000000 07:70:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "Gp@@"
  // 0 = plscsi.main exit int
  $

  $ # ide-cd PATAPI loses the data, and provides no auto sense, but 
reports the data loss as positive residue
  $ sudo plscsi /dev/hdc --please -i 4 -x "1A 3F:00:00 04 00" -v
  x 00000000 1A 3F:00:00 04 00 .. .. .. .. .. .. .. .. .. .. "Z?@@D@"
  x 00000000 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
  // -x0102 = -258 = plscsi.main exit int
  $

  $ # ide-cd PATAPI can provide auto sense data when it likes
  $ sudo plscsi /dev/hdc -x "00 00:00:00 00 00" -v
  x 00000000 00 00:00:00 00 00 .. .. .. .. .. .. .. .. .. .. "@@@@@@"
  x 00000000 70:00:02:00 00:00:00:18 00:00:00:00 3A:00 .. .. 
"p@B@@@@X@@@@:@"
  // x 2 3A sense
  // -x0002 = -2 = plscsi.main exit int
  $

Pat LaVarre