On Thu, 8 Dec 2011, Sebastian Andrzej Siewior wrote: > * Alan Stern | 2011-12-08 14:17:42 [-0500]: > > >On Thu, 8 Dec 2011, Sebastian Andrzej Siewior wrote: > > > >> UAS supports command queues only if running in SuperSpeed aka USB3.0. If > > > >Strictly speaking, this isn't true. UAS allows command queuing at > >all speeds. It's just your driver that doesn't support it. > > My driver could support it. The host side always uses tag 0 if streams > are not used. If you reply with this tag id, the host side fails to find > scsi command and aborts. Sounds like a bug in the host driver. Or rather, two bugs: It should use proper tags and queuing, and it should be able to find the tags it uses. > After looking at the uasp v1 spec I find this: > | When the command is complete, the device responds to the IN (Stat) with > | a DATA (Stat, SIU). The SIU contains > | the tag of the CIU. > > This would mean that the host side is doing it wrong. I could change > that part and see how it goes. But, what do we do if the folks in > Redmond get it wrong? If you've got a UAS driver for Windows, try hooking it up to a gadget running your driver. As far as I know, Microsoft hasn't released any UAS drivers yet. There may be one in the current pre-release version of Windows 8. If necessary, perhaps you can tell the host that you don't support queued commands. Or rather, perhaps you can tell the target layer to inform the host. By the way, do you know whether the target layer supports removable-media emulation? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html