On Sun, 6 Oct 2002, David Brownell wrote: > > IIRC the a3load is meant to load stuff into external memory, right? > > Yes, such as for two-stage loading. My point was just that it's possible > to have code (including EP0 support) that works on all types of EZ-USB.
Here we agree completely. It's just one cannot have anything useful for USB _except_ EP0 support running on all those types without having more code changes then a few defines... > I think that we can't really get away from needing EP0 implementations > in the general case. Given what you said later, I think you agree, > but would be glad to defer such work. Absolutely, EP0 implementation would be really useful for the usbtest stuff. But it's not trivial work and we can start doing important test without it. Later, anything can be added for improvement. > > I was thinking about putting the actual length in the first byte... > > Can't hurt, but eventually I want to see test cases where that's not > enough. For example, we know what should happen if the host issues > a read for exactly N != maxpacket bytes, and the device sends fewer > (or more) bytes. Those cases should get tested, we need to know that > all the HCDs fail in the same ways. Agreed. > >>We'll need to test short packet I/O ... so something as simple as a data > >>stream option to make the packet sizes go MAX, MAX-1, ... 2, 1, 0 would > >>be enough to test with. (Instead of a default that sends only MAX.) > > > > ... but you are right: it's sufficient and easier if we just send a > > defined sequence of lengths like this. > > I'd do both, actually ... :) Ok, these are all simple things we can easily put into the firmware. > > 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. > > If we want correct set/clear stall behavior triggered by the corresponding > > EP0 request we need our own EP0 implementation - see above. > > Yes. Though I won't start worrying about such things until after we > get all the HCDs behaving smoothly (no system lockups or strange errors) > on the basic I/O tests (which is all the tests we have now). Agreed. > > IMHO the easiest way to do so would be two chardev's in userland, one > > connected to the IN the other one to the OUT queue. Just start dd'ing > > stuff from/to these dev and then: use different blocksize, ^Z the reader > > or writer, different scheduling priorities, put some VM pressure, > > concurrent high interrupt load (ping -f over 100Tx link turned out to be a > > good test case). > > The problem with that test mode is it's not a hands-off test. I think > that "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. > > In general, I'm wondering whether it wouldn't be better not to have the > > testcases implemented in the driver module. Just forwarding the raw > > datastream to some chardev with ioctl might be an alternative - and people > > could write testcases in userland. > > We've already got one ioctl, why would we need another one? :) I meant if we would switch from usbfs-ioctl to some chardev - but not two different ioctl. > I don't have anything against tests from userland, but the things I'm > most concerned with wouldn't be as visible from there as they would > be to tests that only work inside the kernel. To some extent I want > to have unit tests for kernel APIs. Ok, part of this must be done in the kernel, no doubt. Martin ------------------------------------------------------- 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
