On Sunday 10 February 2008, Alan Stern wrote: > On Sun, 10 Feb 2008, David Brownell wrote:\ > > 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.
It's always nice to have that happen. ;) > 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. That "must" language seems wrong; the behavior specified in 4.10 doesn't support it. Descriptor writebacks and reads are defined as happening in such a way that it's safe to unlink any QH, live or otherwise, given the IAA handshake. (If it were unsafe to do that, it would be unsafe to link a QH into the schedule too ...) Trying to deactivate active qTDs would be a nightmare of races against the HC, too. Consider that while the host is reading and modifying a qTD (to deactivate it), the HC may be doing the same thing (to mark its completion). And there's the "working copy" of the qTD at list head, stored in the QH ... and the fact that the notion of "list head" changes while the HC is working. There's no way to do that deactivation without sometimes losing races against the hardware, and trashing critical state. No, that sentence was written by someone so clueless they should never have been let near a keyboard. Some other text in that same section looks pretty goofy. (I was told by one of its authors that the EHCI spec team was under instructions to focus on the hardware behavior, not software ... even to the extent of not defining a software model. That would have been extreme, but sections like this one show a consequence of those priorities. Or maybe one of the pen-holders had problems like that.) > Could that be a source of problems? Any time a specification is internally inconsistent, there's obviously scope for problems. > > 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. I don't know about "at the same time", info was a bit sketchy. The failure was intermittent, in any case, which will often mean that an "unlikely" hardware race is won by the wrong signal. Of course, traffic patterns can make big changes to what's "unlikely". In some cases, they'll make particular races "certain" to appear. - Dave - 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
