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? I guess there are still a lot of people using 2.4 kernels, then. I've been recommending this flag to people as recently as 6 months ago (i.e. the last time someone asked me). It comes up 2-3 times a year. The last time it came up, the device set SCSI_2. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998
Attachment:
pgpbuQBBj9E9d.pgp
Description: PGP signature
