"Justin T. Gibbs" wrote:
>
> >The Scsi_Cmnd::scsi_level member looks promising for
> >controlling whether that is done:
> > if (SDpnt->scsi_level <= SCSI_2)
> > scsi_cmd[1] = (lun << 5) & 0xe0;
>
> This is the correct thing to do. You'll also need to inherit the
> scsi_level on new lun instances for a target that already has probed
> luns. In otherwords, scsi_cmd[1] is always 0 for lun 0, so scanning
> lun 0 is safe. All higher lun scans should pick up the scsi level
> from lun 0. Even if lun 0 is not supported by the device, it should
> return inquiry data with enough information to determine what scsi
> level the target supports. If you don't perform the inheritence, then
> modern SCSI-3 devices will complain about the now reserved field in
> the cdb being non-zero.
The attached patch builds on top of the one Eric posted
a few days ago for lk 2.4.1 . As well as Eric's changes
this patch:
- puts the above lun check in:
mid-level, sd, st, osst, sg, sr (sr_ioctl + sr_vendor)
- implements the lun 0 scsi_level inheritance discussed
above during scanning
- has no CRs :-)
It builds and is running on my machine but I don't have
any devices with lun > 0 so I would be grateful if others
would test it. Implementing 64 bit luns would be quite
messy (I see CAM3 uses an array of 2 (32 bit) integers).
Just to catalog other scsi patches floating around for lk 2.4
there is:
- scsi reservations + reset [James Bottomley]
- scsi device detection message correction
(was in the lk 2.4.0ac series but didn't make
it into the lk 2.4.1ac series) [me]
- janitorial + documentation [Torben Mathiasen]
Doug Gilbert
scsi241_ey2.diff.gz
