On Thu, 17 Jul 2003, David Brownell wrote: > 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.
Since the test program is intended for detecting non-conforming hard/firm/software, I would expect it to be able to deal with all sorts of responses, including nonsensical ones. > > 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. You're right. I'm not sure how the UHCI driver deals with that... In fact, it came up a few weeks ago that the interrupt-on-short-packet flag isn't being set properly. Fortunately, I don't think it matters in this context. > > 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. Could be. > > 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. Can you suggest any additional diagnostics that might help? Alan Stern ------------------------------------------------------- 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
