https://bugzilla.kernel.org/show_bug.cgi?id=80711 --- Comment #8 from Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> --- On Wed, 6 Aug 2014, Christoph Hellwig wrote: > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote: > > > I doubt either of them forces users to hack up flags for these cases. > > > > Why was this change needed in the first place? There's no explanation > > in the patch itself. > > Which chance? The one to not support SG_FLAG_LUN_INHIBIT? No, the patch that started this Bugzilla entry. Tiziano says it is needed in order to send vendor-specific commands that use the LUN bits in CDB[1]. > > > At least for windows I suspect it just never sends the LUN encoded > > > in the CDB and treats USB devices special instead of our insistance > > > on pretending they are SCSI-2. > > > > We no longer pretend that USB mass-storage devices have any particular > > SCSI level. See commit 09b6b51b0b6c. > > So the origina reported device must report SCSI-2 all by itself if he's > running a recent kernel, ok. > > > > Maybe some of the USB people have on the wire traces or access to > > > device or windows documentation on this? > > > > Most likely it varies with the version of Windows and the INQUIRY data > > returned by the device. > > > > I can obtain hardware traces for the kinds of devices and computers > > lying around here. But what sort of combinations should I test? > > I'd mostly be interested to see if it actualy encodes the LUN in the CDB > for any USB multi-LUN device. I tried connecting a Linux mass-storage gadget with two logical units to a host PC running Windows 7. The host scanned the first logical unit and completely ignored the second! Didn't even send an INQUIRY command. So the question remains unanswered... Can someone tell me if anything special is needed to make Windows recognize logical units beyond the first? Alan Stern -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: 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
