That's what I was missing: the queue advance is aborted if the QTD's active bit isn't set. Thanks again! Stuart
-----Original Message----- From: David Brownell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 27, 2004 5:56 PM To: Hayes, Stuart Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [linux-usb-devel] PATCH for ehci-sched.c -- interrupt QHs are n't started right in E HCI driver (2.4 & 2.6) [EMAIL PROTECTED] wrote: > One question on that, though. With the fix that was put into 2.4.22, the qh > is now initialized as live by qh_make (i.e., the halt bit isn't set). Then, > in intr_submit, the qh is scheduled with no QTDs, and the QTDs are added to Or as the comment says, scheduling errors are forced (in the rare case the QH isn't yet scheduled, AND there's no space); periodic qTDs are always added to a QH that's live (which can't fail). > the live qh. When the QTDs are inserted by qh_append_tds, it sets the QTD > token to have the halt bit set, moves the QTD into position, and, finally, > puts the correct token into the QTD. That is, the old dummy is overwritten by the first QTD in the list, and the original first QTD becomes the new dummy. Why? Because the dummy is already in position (but not ACTIVE), and trying to substitute another QTD there gets racey. > It seems like there would be a race condition in qh_append_tds between the > software and host controller--if the host controller looks at this qh after > the QTD is added to the qh, but before the real token is copied into the QTD > (which is pretty much the last thing that qh_append_tds does), the host > controller will copy the incomplete QTD into the overlay area, see that the > active bit isn't set (because it copied the token that just has the halt bit > set), and go on to the next qh. The next time around, the host controller > will look at the overlay, see the halt bit is set, and move on to the next > qh, and the complete QTD will never be seen. See section 4.10.2 of the EHCI spec, which says the controller won't overlay any QTD unless its ACTIVE bit is set. On the other hand ... I believe some EHCI 0.95 controllers don't always do that. I'm pretty sure I've seen both NEC and Philips 0.95 controllers overlay the (inactive) dummy; see comments at the end of qh_completions(). That type of failure was pretty uncommon, at least in the system I was using at that time and using the tests I had then, and I think it's got a complete-enough workaround. > Granted, this isn't very likely to happen, but it seems possible. It seems > like there would be two ways to avoid this possibility: One way would be to > leave the halt bit set in the overlay until all of the QTDs are added to the > qh (this is what I had proposed). The second would be to change And that's in fact similar to what the original driver version was doing; as bugs got fixed, and deep queues got to behaving, the code evolved to the current simpler approach. > qh_append_tds to put a 0 (instead of a halt) in the QTD's token until it is > done adding the QTD--in this way, if the HC *did* copy the incomplete QTD > into the overlay area, it would see the that the active bit isn't set and > move on to the next QH, but the next time around it would see that neither > halt nor active were set in the overlay, and it would go fetch the QTD > again. > > Does this seem reasonable, or am I missing something? I remember thinking leaving HALT in qh_append_tds() should pretty much guarantee that qh_completions() would _always_ patch up after up that EHCI 0.95 bug at the next IRQ (or watchdog). Also, think of the other race: the incomplete QTD would have hw_next pointing to some rather irrelevant location in memory ... but that's what the HC would fetch and try to use! So it'd die after a DMA fault, in at least some cases. - Dave > > Thanks > Stuart > > > ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
