On Tue, 17 Jan 2012, Sebastian Andrzej Siewior wrote: > On 01/17/2012 04:39 PM, Alan Stern wrote: > > On Tue, 17 Jan 2012, Sebastian Andrzej Siewior wrote: > > > >> responded with CSW.status=1. > > > > It shouldn't complain when that happens; that's normal. What error > > recovery did you need? > I have a database where I lookup the transfer direction for each > command. That's not robust. You might have to fail a command simply because it isn't in your table, even though the target layer could have handled it. With BOT this isn't so critical; the CBW includes a flag for the data direction. In fact, this sounds like a weakness in the target layer. A transport driver should be able to ask the target layer how much data should be transferred for a command, and in which direction. > I did not have the direction for the VERIFY which is issued by > WindowsXP after a disk format. Not doing anything resulted in timeouts. > So added that I sucking the incoming data or sending dummy data and > then so I could send the CSW (basic error recovery). Yes, that is part of the BOT spec. > After I replied with CSW.status=1 for that command Windows issued > MODE_SENSE Do you mean REQUEST SENSE? > and retried VERIFY. This ended in a loop. What sense information did you return? SK=5 (illegal request) and ASC=0x20 (invalid command operation code) would be the proper response for a command you don't implement. > After I replied > with CSW.status=2 Windows retried the command again. This also ended in > a loop. So I had to add the direction to the database so the show can > go on. I have no idea what I can do if this happens with an other > commands where the remote OS just repeats the commands which will fail > again. As long as you send back the correct sense data, whatever happens is the remote OS's fault. > However, it works for other commands: Target isn't handling > GPCMD_READ_FORMAT_CAPACITIES which is issued by Windows. After I reply > with CSW.status=1 it does a set_alt and repeats it again. This repeats > two times and then Windows moves on. Windows also tries a MODE_SENSE > request which fails in target with: > MODE SENSE: unimplemented page/subpage: 0x1c/0x00 ASC=0x24 (illegal field in CDB) would be appropriate for this. Have you tried attaching the mass-storage-gadget to Windows, to see how it responds to these commands? > Windows retries this command a few times without set_alt and continues. > I noticed the same behavior on Windows8 (the preview edition available > for download). Unfortunately it does not try UAS :/ > > > UAS doesn't seem to have anything resembling BOT's > > dCBWDataTransferLength or dCSWDataResidue. How do you deal with this? > > And how does the uas driver deal with it? > Neither the host side nor the device has any kind recovery implemented > if something does not go as planned. > In UAS I have four endpoints, DATA IN+OUT, CMD (OUT) and STATUS (IN). > If everything goes as planned, then I receive the CMD, send/receive > the data and ack it via STATUS. So if something goes wrong I should > send a different status response. The host can also send "TASK > MANAGEMENT" commands for some extra magic which is also not implemented. The real question is what happens when the amount of data you want to send/receive is different from what the other side expects. It sounds like the only way to recover will be for the host to cancel the command and possibly reset the device. 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
