We seem to be in pretty close agreement. I'll send in the patches we've got for the 'usbtest.c' driver a bit later this morning; and it looks like your test firmware is behaving well enough to circulate it so other folk can use it too.
>>>Idea is to let the firmware use the frame counter as timestamp to >>>indicate when the IN packet was sourced. The host has the same >>>synchronized timebase making it easy to measure latencies. >> >>Such measurements can be a related focus. Given those basic time >>measurement, it'll be practical for motivated people to put together >>charts'n'graphs showing interesting behaviors. > > > Even better: It allows for more validations. For example with UHCI we have > to wait one frame before the urb is finally dead (to be sure the HC > wouldn't see it anymore). With the frame counter stuffed into every > payload packet of the urb you can check this. Yes. Though last time I looked, UHCI could actually release the URB without that delay ... the delay was needed for the QH, but there was no need to keep the URB tied to it then (during normal completions). >>... "hands-off" is important, since I want us to be able to run overnight >>(or longer!) tests. > > > You mean longer runs just increasing the probability to hit some rare > issues? Well it definetedly helps - and yes, I have seen the old queing > code triggering a race only every few hours of continously streaming with > 1.1MB/s sustained. So I like the idea of long runs. But we should also > focus on creating test cases which are directly targeting such issues. > Sure, for races it's always a matter of probability, but concurrent > activities like ping -f or disconnect tend to increase it dramatically. > And this can be done automatedly. It's more like acknowledging that "rare" is a relative judgement, and a few million Linux users putting in (say) 8 hours a day will surely see some things that might not come up in tests that only run a few minutes. The kinds of things that'll race tend to have multiple threads involved, like concurrent reads/writes to the same device. (That's a "ping -f" type load.) Or in the case of the scatterlist testing, an HC can complete a TD at moments that are awkward for the HCD's logic to update an endpoint's queue of TDs ... I suspect that's what UHCI is seeing just now, I've seen similar problems with the EHCI and OHCI drivers (now fixed). (That's like the "hours of continuous streaming" test, though queuing lots of urbs with one packet each is a good way to make such errors happen sooner.) Good testing always comes down to test design and, at this level, making the probabilities work in your favor. Tests that _efectively_ torture the underlying code will make it more likely that problems come up in testing. So longer test runs are important. There will be things we have a more difficult time testing. Disconnect processing (enumeration testing) is likely one of them. But a "ping -f" load, or a continuous streaming load, or even lots of concurrent activity to multiple devices ... those are easily automated. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
