On 01/17/2012 07:29 PM, Alan Stern wrote:
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
This is also the case with the current BOT storage gadget which does
everything on its own.
it. With BOT this isn't so critical; the CBW includes a flag for the
data direction.
According to the spec, the device should not consider it while
evaluating the command. If the host attempts to do VERIFY in OUT
direction (which is wrong because VERIFY should not move data) the
device should abort it instead of reading the data and throwing it away.
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.
Yes, and this is why I have this lookup table. It was initially
submitted as an extension to target but since I'm the only user it was
moved into the gadget. Maybe it can be moved into drivers/scsi since
there are other drivers having another lookup table.
BTW: the storage gadget has a similar kind of lookup table :)
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?
yes, I did.
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.
Argh. Nope, didn't.
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.
good to hear :)
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?
So I wired that part up now. So Windows retries the first command
twice. This also happens with the mass_storage gadget but somehow it
answers the second request properly. Anyway, the MODE_SENSE response is
little complicated. Target response always with KEY=UNIT_ATTENTION and
Windows somehow ignores it. With KEY=ILLEGAL_REQUEST this request is not
re-retried. Let me see how I tell target this....
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.
Interesting. If I get the direction wrong, it will stall and will have
to cancel the command because it times out. If I send too much data it
will timeout because it does not receive the status urb. If I send not
enough data then it will notice it soon because the status URB arrives
before the data URB completes.
Alan Stern
Sebastian
--
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
