On Wednesday 01 March 2006 1:09 am, Marc Singer wrote: > On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote: > > > > http://www.linux-usb.org/usbtest/#gadgets > ... > > I'm not seeing an explanation of what the tests should look like. How > long should each one last? Most take about a second. A couple, 6, 7, > 8, and 9 take less than 20 seconds. 10 is still running after a few > minutes.
If you run direct from the command line, many of the tests use defaults that add up to one second for full speed peripherals. I usually run that through the test script though, so the timings are different. Test #10 taking a few minutes? Sounds troublesome. If this is using an OHCI or EHCI host controller and you've compiled with USB_DEBUG, you'll find a /sys/class/usb_host/.../async dump of the control and bulk queues. If it doesn't change, it suggests the peripheral is just sitting there NAKing packets for some reason. You can find out just which packet, and then work backward from there to "which test". (One test requests 1KB of data, that's a good marker to count back from. You can correctly infer that I've seen test #10 turn up lots of bugs like that ...) > I always see this as well, > > [EMAIL PROTECTED] ~/z/usb > sudo ./testusb -a -t10 > unknown speed /proc/bus/usb/002/005 > > Is the unknown speed message expected? Yes; usbfs doesn't provide a good way to map devices to their speed. I suppose the message should be removed, that's unlikely to get fixed. > The only oddity I've seen so far is that the gadget wasn't detected > when the target (gadget) rebooted. I know that the driver has an > error in the USB power control. Perhaps that's at fault in the > detection. Could be; I wouldn't know. > I'm also finding that the tests don't respond to ^C or ^\. In fact, > it looks like test 10 has locked-up, but I cannot be sure.. It stops > when I remove the USB cable. Yeah, it's annoying that signals don't kill the tests. It's an oddity caused by usbfs locking. > I'm running > > test.sh in out > > overnight to see if it finds anything peculiar. Here's hoping it doesn't ... and that the only bugs that need to be tracked down are in control transfers, or maybe (later) with transfer queues of length-more-than-one. :) - Dave ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
