On Sun, 10 Feb 2008, David Brownell wrote: > On Sunday 10 February 2008, Alan Stern wrote: > > > > In view of all the problems we've been seeing with IAA implementations, > > should the driver be changed to rely more on the watchdog timer? Maybe > > even avoid IAA altogether? > > We can't avoid the IAAD/IIA mechanism, since that's the only way to > unlink -- short of disabling the async schedule, waiting for that to > finish, taking the endpoints out of the ring, then re-enabling it.
I had thought that QHs could safely be removed after waiting a few frames or microframes -- but on rereading 4.8.2 it appears you are right. In fact the spec goes even farther: It says that active queue heads must not be removed from the schedule, and software should first deactivate all active qTDs and wait for the queue head to become inactive before removing it. Could that be a source of problems? > What I'd rather do is just get a proper handle on exactly what the > failure modes are. We know it's possible to work around them, since > Microsoft does. (Or at worst, vendors do it for them.) The basic > problem we have is that for PCs, Linux developers don't have access > to the level of documentation (and other support) Microsoft gets. > So we have to experiment a bit more widely. Hmmm, maybe Microsoft's (or the vendors') driver just waits 5 ms or so without bothering to use IAA... I wouldn't put it past them. :-) > In this case, I recently got information from one vendor about just > how their IAA malfunctioned: someone seems to have goofed what I'd > call a fairly simple latch gating mechsism. IAAD still behaves, so > that suggests a simple workaround. In fact, I'd not be surprised > to find the VIA problem is similar ... Yes, I have seen that discussion. It sounded rather unlikely to me, inasmuch as the proposed mechanism involved the host writing to the Status register at the same time as the controller was turning on the IAA bit. But something similar (and more likely!) may be occurring. > This larger patch includes a workaround for that *PLUS* lots of > paranoia checking for similar bugs. It's stuff we basically have > never tried before. Now that we have the timer cleanup (thanks!), > we can finally start to drill down on these problems, and I expect > it will help us to collect some useful information. Here's hoping... Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
