The first four subtests (#0..#3) will run in a loop, 5000 times each. At most four will be queued simultaneously: 012301230123....0123.
- get device descriptor (18 bytes) - get config descriptor (9 bytes, NOT including interfaces, etc) - get altsetting for interface 0 (one byte, some devices stall this) - get status for interface 0 (two bytes)
There are no short transfers involved.
Maybe there aren't supposed to be. But there's no question in my mind
that subtest 2 completed as a short transfer. Part of the log that I
omitted includes the TD status word for that URB; it has the Active bit
off, the Short-Packet-Detect bit on, and the Stalled bit off.
OK, so it's possible that some of these problems start because the chip is making a nonsensical response ... perhaps not unexpected, since it wasn't actually running firmware at that point.
A sensible response would have been just NAKing the request until the host timed it out, if it can't provide an authoritative response like a STALL, or the relevant data byte. Hardware could obviously choose that policy instead of sending a zero length data packet.
Another theory would be that the EZ-USB chip is deeply broken, but I thought they were more reasonable than that. (For all that they're only 8 bit CPUs!)
Remember, Charles said that he was going through all this to test his firmware. Isn't it possible that an error in his firmware program could have caused this short transfer? (Although, come to think of it, this test was supposedly run without any firmware loaded...)
He also implied he was using firmware that, as far as I recall, works just fine in this test: the stuff Martin Diehl wrote.
There's nothing wrong with completing a queued URB that follows one with a short transfer.
In this case (control traffic), that makes sense even when SHORT_NOT_OK is set -- else there ends up being real chaos in HCDs to retrigger the status stage but stop the queue immediately after.
In general I'd disagree ... if drivers expect to read N bytes, and don't get it, something's wrong that they may need to pay attention to before any more data gets tranferred.
uhci: took urbp c575653c off remove_list uhci: added urbp c575653c to complete_list uhci: took urbp c57564f4 off remove_list uhci: added urbp c57564f4 to complete_list The 2 unlinked URBs were marked as having finished.
uhci: added urbp c5756464 to complete_list Although the same address as that 4th one, this must refer to a new URB that was submitted and completed.
Does this refer to subtest 3 in the second loop? It's an URB that was
submitted after all those earlier ones were unlinked, and apparently it completed normally. If it were subtest 2, I would have expected it to result in another short transfer.
Subtest 3 should never have been re-issued. I can imagine that the device misbehavior would have made that happen.
Remember that those tests require devices that behave more or less correctly. Garbage in, Garbage out. It would seem that without firmware, the FX is reporting garbage when asked to report the altsetting.
Sorry about that; I didn't think it would make much difference. These three URBs are the unlinked second-loop instances of subtests 0, 1, and possibly 3. I don't know why there doesn't seem to be any subtest 2 in the second loop.
Because when subtest 2 failed the first time around, the looping was all supposed to stop. If we assume the device misbehavior prevented the queue from being processed correctly, that would explain the "out of order" for subcase 3.
- Dave
drivers/usb/misc/usbtest.c: subcase 3 completed out of order, last 1
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
