Matthew Dharm wrote:
> On Sat, Nov 05, 2005 at 06:49:05PM -0600, James Bottomley wrote:
>
>>On Sat, 2005-11-05 at 15:55 -0800, Matthew Dharm wrote:
>>
>>>On Fri, Nov 04, 2005 at 02:49:55PM -0600, James Bottomley wrote:
>>>
>>>>Can you just try it with a modern kernel and see if anything still
>>>>breaks?
>>>
>>>I just realized this plan has a problem...
>>>
>>>The reported SCSI level of a device is mostly garbage, but not always.
>>>I've seen 0, 1, 2, 3, and 0xff all reported. HOWEVER, the reported value
>>>seems independent of what devices have vendor-specific commands (and thus
>>>need the CDB[1] not messed with).
>>>
>>>It is an interesting experiment to remove the force-to-SCSI_2 part of the
>>>usb-storage code (on the general principal of "we shouldn't be messing with
>>>the data passed through the driver), but it doesn't solve the original
>>>question of needing a way to pass commands without CDB[1] getting altered.
>>
>>Well, that might be a problem if it weren't for the fact that this
>>LUN_INHIBIT flag was removed in 2002. If it's taken three years to find
>>a device that has a problem with it, I don't really think it's a
>>particularly widespread problem. And since the device that now shows
>>the problem is setting the level to 0, it looks like we have a potential
>>solution that fits all known cases.
>
>
> Was it really removed that long ago?
yes
...
- if (!(hp->flags & SG_FLAG_LUN_INHIBIT)) {
- if (sdp->device->scsi_level <= SCSI_2)
- cmnd[1] = (cmnd[1] & 0x1f) | (sdp->device->lun << 5);
- }
...
17. 2002-10-15 [RFC PATCH] consolidate SCSI-2 command lun setting linux-scs Patrick Mansfield
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
