On Tue, 2012-01-17 at 13:29 -0500, Alan Stern wrote: > 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'll be merging Sebastian's patch to handle unknown size, and I've asked him to keep the data-direction look-up out of target-core in lio-core.git for the moment with his target_uas development code. Instead of adding another CDB table, we need data-direction hints to individual CDB lookup in transport_generic_cmd_sequencer() to handle this in target core. > > 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. > Ouch. Canceling individual se_cmd's sounds less painful if residual is not supported in UAS. Thanks for your comments Alan! --nab -- 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
