William Studenmund wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2006, at 1:59 PM, Scott Long wrote:Kenneth D. Merry wrote:On Fri, Aug 25, 2006 at 11:37:15 -0700, William Studenmund wrote: See above...CAM sets the LUN number when it does the initial probe of a LUN, and when the LUN reports it is SCSI-2 or below. The problem with rejecting the LUN number on the inquiry is that theinitiator is issuing the inquiry to find out what SCSI rev the target is in the first place. It has to do so in a way that will work on old and newtargets. Things work okay on LUN 0, because the LUN field is set to 0.My suggestion would be to allow setting of the LUN number on the inquiry command only. That way the initiator can figure out what SCSI rev you areand do things accordingly. KenAre there cases where a target has multiple LUNs that will each report a different SCSI rev? If not, then CAM should look at the rev of LUN 0 of the target when deciding how to form an INQ of LUNs >0.While I think there could be a difference between reported levels, if LUN 0 reports > SCSI-1, then I think it's appropriate to not put the LUN in the CDB. SCSI-2 mentions that the LUN field should be set to zero as SCSI-3 may reclaim the bits (which it did).I believe that by the time LUN 0 has been probed, the system should have enough information to figure out if the device is SCSI-1, SCSI-2. or SCSI-3 (i.e. sam-X, spc-Y, etc.). I think that Scott's suggestion is good; if LUN 0 is SCSI-1, fill in the LUN in the CBD. If LUN 0 is > SCSI-1, don't.Also, while probing LUN 0, it's probably best to perform a REPORT LUNS command. If it succeeds, you 1) don't need to blindly probe, and 2) you know that you shouldn't put the LUN in the CDB (REPORT LUNS appeared in SPC, which is SCSI-3).
The REPORT_LUNS angle has been discussed many times in the past. The problem is that it's a risky command without the right heuristics. Older SCSI devices are notorious for going down in flames if given a CDB that they don't understand, so we can't universally send a REPORT_LUNS to every target that responds on LUN 0. We've discussed
adding some heuristics to look at the rev field and decide from there,but that's only part of the problem. The other part of the problem involves tackling the CAM probe state machine to handle both the
current sequential scan as well as a REPORT_LUNS enumeration. That's not an exceptionally hard task, it just takes a bit of work. Scott _______________________________________________ freebsd-scsi_(_at_)_freebsd_(_dot_)_org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to "freebsd-scsi-unsubscribe_(_at_)_freebsd_(_dot_)_org"