Re: SCSI descriptor sense changes, testing needed

This has been committed to head, and the plan is to get it into stable/9
in time for 9.0.

Please let me know if you run into any problems with the changes.

Thanks,

Ken

On Fri, Sep 30, 2011 at 23:19:14 -0600, Kenneth D. Merry wrote:
> 
> I have attached a new version of the patches, with a number of changes.
> 
> One issue that has cropped up is that the previous sense code and my new
> descriptor sense changes never paid any attention to the actual length of
> the sense data returned by the controller.
> 
> I have changed all of the error recovery code and sense printing code to
> honor the sense data length in the CAM CCB.
> 
> One other problem related to that is that many controller drivers don't set
> the sense residual field in struct ccb_scsiio properly, or don't set it at
> all.  This patch includes changes to the isp, mps, mpt, umass, and ciss
> drivers to set the sense_resid field properly.
> 
> There are lots of other drivers in the system, however, that haven't been
> audited, and may or may not set the sense residual correctly.
> 
> I also fixed an issue reported by Fabian Keil that showed up with the ahci
> driver.  In reverting a change I have in my local tree to switch to a 2
> byte length field in the SCSI inquiry CDB, I accidently shortened the CDB
> to 5 bytes.  Oops.
> 
> I'd really appreciate more feedback; Fabian is the only person to report
> testing the previous patch.
> 
> Thanks,
> 
> Ken
> 
> On Thu, Sep 22, 2011 at 13:33:05 -0600, Kenneth D. Merry wrote:
> > 
> > I have attached a set of patches against head that implement SCSI
> > descriptor sense support for CAM.
> > 
> > Descriptor sense is a new sense (SCSI error) format introduced in the SPC-3
> > spec in 2006.  FreeBSD doesn't currently support it.
> > 
> > Seagate's new 3TB SAS drives come with descriptor sense enabled by default,
> > and it's possible that other newer drives do as well.  Because all the
> > sense key, additional sense code, and additional sense code qualifier
> > fields are in different places, the CAM error recovery code will not do the
> > right thing when it gets descriptor sense.
> > 
> > These patches do bump up the size of struct scsi_sense_data, and so I have
> > incremented CAM_VERSION as well.  I have discussed this with re_at_, and it
> > looks like we'll be putting the changes in before 9.0, so it ships with
> > support for newer SCSI devices.
> > 
> > A number of things have changed in these patches, but in particular, it
> > would be good to test the following:
> > 
> >  - The sa(4) (SCSI tape) driver.  The residual handling code, which looks
> >    at the sense data, has changed.
> >  - The Playstation 3 CDROM driver.
> >  - Firewire target mode.
> >  - umass devices with the NO_INQUIRY_EVPD quirk.
> > 
> > Also, please let me know if you see any anomalies with the sense printing
> > code.  In the common cases the output should look identical to the old
> > code, but in some cases it will be a little different.  e.g.:
> > 
> > # camcontrol inquiry da40 -v
> > pass47: <SEAGATE ST33000650SS 0002> Fixed Direct Access SCSI-6 device
> > pass47: Serial Number 9XK0GAJ70000S125XDNU
> > pass47: 300.000MB/s transfers, Command Queueing Enabled
> > 
> > (Seagate 3TB drive)
> > 
> > # camcontrol modepage da40 -m 10 |grep D_SENSE
> > D_SENSE:  1
> > 
> > (Descriptor sense is enabled)
> > 
> > # camcontrol modepage da40 -m 15 -v
> > (pass47:mps1:0:47:0): MODE SENSE(6). CDB: 1a 0 4f 0 ff 0 
> > (pass47:mps1:0:47:0): CAM status: SCSI Status Error
> > (pass47:mps1:0:47:0): SCSI status: Check Condition
> > (pass47:mps1:0:47:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
> > (pass47:mps1:0:47:0): Field Replaceable Unit: 1
> > (pass47:mps1:0:47:0): Command byte 2 bit 5 is invalid
> > (pass47:mps1:0:47:0): Descriptor 0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > camcontrol: error sending mode sense command
> > 
> > (The FRU and Sense Key Specific entries are on separate lines, and a
> > vendor-specific sense descriptor is printed out in hex format.)
> > 
> > Anyway, I'd appreciate any testing and feedback on these changes.  As I
> > said, they will probably be in 9.0, so if there are any issues it would be
> > better to find them now. :)
> > 
> > Thanks,
> > 
> > Ken
> > -- 
> > Kenneth Merry
> > ken_at_FreeBSD.ORG
> -- 
> Kenneth Merry
> ken_at_FreeBSD.ORG
-- 
Kenneth Merry
ken_at_FreeBSD.ORG