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 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.
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. 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 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? Thanks Stuart -----Original Message----- From: Hayes, Stuart Sent: Tuesday, January 27, 2004 3:05 PM To: 'David Brownell' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [linux-usb-devel] PATCH for ehci-sched.c -- interrupt QHs aren't started right in E HCI driver (2.4 & 2.6) Right, thanks. Sorry I didn't see that--it was fixed it in a different way than I was looking for. I didn't actually test the latest kernels, but just looked at the source. Stuart -----Original Message----- From: David Brownell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 27, 2004 2:27 PM To: Hayes, Stuart Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [linux-usb-devel] PATCH for ehci-sched.c -- interrupt QHs aren't started right in E HCI driver (2.4 & 2.6) [EMAIL PROTECTED] wrote: > > I've found, in the EHCI driver, that queue heads set up for an interrupt > pipe (such as the one set up to check for connection changes on the USB2.0 > hub) are set up correctly, but the "halt" (QTD_STS_HALT) bit in the hw_token > in the overlay area is never cleared after the QH and QTDs are set up and On 2.4, that doesn't happen since about 20-June-2003; and on 2.6, just a few days earlier (BK describes it as a "micro-patch"). > scheduled. With this halt bit set, the HC will ignore the QH, so it doesn't > get executed. If the hw_token in the overlay is cleared to 0, the HC will > advance the queue (copy the first QTD into the overlay area) and do the > transaction. Sounds to me like your base kernel is missing EHCI patches I'd call essential. More current kernels should be fine. - Dave ------------------------------------------------------- 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
