> > On Thu, Nov 03, 2005 at 11:08:07PM -0500, James Bottomley wrote: > > On Wed, 2005-11-02 at 15:45 -0800, Matthew Dharm wrote: > > > On Wed, Nov 02, 2005 at 02:18:52PM -0800, Timothy Thelin wrote: > > > > > > > > If you had time to spare, instead of touching usb-storage, > > > > it might be better spent resurecting SG_FLAG_LUN_INHIBIT to > > > > stop the above behavior so that SG_IO cdbs can be passed > > > > through untouched. > > > > (SG_FLAG_FUN_INHIBIT was a flag SG_IO used to support a long > > > > time ago, and I have no idea why it was dropped, but it was) > > > > > > I didn't realize that had been removed. Anyone that sends a > > > vendor-specific command to a device needs this flag to > make sure it goes > > > through unmangled. > > > > > > Perhaps someone on linux-scsi can comment on why this was > removed and how > > > we might get it back? > > > > I've no distinct recollection of someone removing this, but if I > > remember correctly what it used to do, it was a hack to stop us from > > mangling SCSI-3 CDB's. We fixed the mid-layer not to > require the hack > > by only setting the CDB[1] lun field for SCSI-1 and SCSI-2 > devices (as > > the standards mandate). What's the actual problem? No > SCSI-1 or SCSI-2 > > device should have any vendor specific CDBs that uses these bits in > > CDB[1]. > > Unfortunately, reality appears to disagree with the last > "should". I've > personally seen devices with vendor-specific commands that > want to control > CDB[1] in SCSI-2. > > I didn't know it was removed; I only know what Timothy Thelin > told me. Can > we get the feature back? > > Matt And for an even more concrete example: The CY7C68300B cypress bridge board (has various siblings as well on their site that act very similar) implements SCSI spec 0 (ie it doesn't claim to support any scsi spec). Now usb-storage sees this in inquiry, and decides to export the device as a scsi2 device since based on the usb-storage devs' experience most usb devices really want scsi2 cdbs. So SCSI core thinks this is a scsi2 device and procedes to mangle the cdbs as they're going through. The problem then is with vendor specific commands as SCSI core mangles those as well. The vendor specific command I had issues with is the "ATACB" ATA passthru cdb that cypress boards understand. CDB[1] is a signature byte that must be 0x24. Needless to say, that leading 2 gets masked off to a 0, and the drive aborts the ATACB. Now cypress could have been smarter about designing their cdb, but they wern't, and so there really needs to be a way to tell SCSI core "hands off the cdb". This is also going to be an issue with USB devices that implement SAT passthru but state they implement SCSI spec 0, as SAT passthru CDB[1] can't afford to be mangled either. I started this conversation a little over a month ago, but it died. http://marc.theaimsgroup.com/?l=linux-scsi&m=112714917116713&w=2 Regards, Tim Thelin - : 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
