On Fri, 19 May 2006, David Brownell wrote: > On Friday 19 May 2006 10:34 am, Alan Stern wrote: > > Dave: > > > > While trying to test some changes to the ISO handling in uhci-hcd, I ran > > across a whole mess of bugs. > > > > Easy one first: The ISO tests in usbtest don't report > > errors! test_iso_queue() will return 0 even if all the > > URBs fail. Not so good for testing purposes. > > Whoops. They don't get much use, this might explain some of it... > though I recall there being a tradeoff, since it's legit for ISO > transfers to fail and thus hard to see what faults were actual > test failures.
Well, certain types of failure obviously should be reported (-ESHUTDOWN for example). And if more than, say, 10% of the transfers fail for any reason, that's worth reporting. > > Intermediate ones: In inode.c, ep_aio_complete() assumes > > that iocb->ki_retry will be set for reads and will be NULL > > for writes. But it isn't; the aio core sets default values > > for ki_retry always. > > I suspect this was an API change in the AIO core ... they've rewhacked > the "retry" logic a few times since that code was written, and I didn't > have time to track what changed. Several of the changes didn't make > much sense to me, but then I was thinking more about real I/O queues than > about having that API be a front end to the block framework (which has > its own I/O queues). > > > > Even when that is fixed, the call to kick_iocb() (in the same > > routine) doesn't seem to do anything. ep_aio_read_retry() > > does not get invoked and the pending aio requests never > > terminate. > > See above re incompatible AIO changes... this would explain some of > the odd behavior I saw last time I tried to use the AIO stuff. I'll try to learn more about the AIO stuff. > > Hard one: When DMA is enabled in net2280, the first ISO > > request submitted by the gadget driver (an IN transfer) > > completes immediately. Even though the host hasn't tried > > to do any I/O. When DMA is disabled this doesn't happen. > > This is a problem how? The completion callbacks are specified so > it's OK to report completion when the IN fifo fills ... that helps > make sure drivers have the opportunity to keep the hardware busy. > The PIO code paths sometimes give more "precise" reporting, but > that's optional. You're right; this isn't really a bug. Forget I mentioned it. However it does point out a weak area of the Gadget API. Typically ISO transfers involve time-sensitive data. That is, if a transfer fails you prefer to ignore the failure rather than spending time to fix it. But the Gadget API doesn't provide any simple way to specify time limits for ISO submissions. If the gadget driver wants to send 100 packets at roughly 1-ms intervals, it can't tell the controller driver to forget about a packet that doesn't complete within its 1-ms window. If a transfer request isn't received from the host, all the remaining packets in the queue will be delayed until the current packet can be sent. Or am I misunderstanding something? Alan Stern ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&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
