On Wednesday 25 July 2007, Mike Nuss wrote: > David Brownell wrote: > > > > This fix enhances the scope of the existing OHCI_QUIRK_ZFMICRO flag: > > > > 1. A watchdog routine periodically scans the OHCI structures to check > > for orphaned TDs. In these cases the TD is taken back from the > > controller and completed normally. > > Of course, just after I verified and signed off on the final version of > this patch, a problem has cropped up.
grrr... > This just showed up in the log of > one of my test systems: > > user.warn kernel: ohci_hcd 0000:00:13.0: Reclaiming orphaned TD c3f41380 > user.err kernel: ohci_hcd 0000:00:13.0: bad entry 3f41381 > > The first message indicates that my watchdog was triggered and the TD > was taken back from the HC. The second message seems to indicate that > the HC did, in fact, later complete the TD. > > I can think of two explanations for this: > > 1. We aren't waiting long enough between the time the TD is popped off > the queue and the time it's taken back through the donelist. If that's > the case, I don't know how long would be reasonable. The worst case should be seven frames (maximum time any WDH irq would be deferred) and two WDH irqs. That would even cover that mostly-safe assumption that multi-TD interrupt transfers aren't happening (they're pretty rare with full speed hardware). > 2. The logic is too naive. The quirk assumes that if HeadP and DoneP > remain equal (meaning that the HC's queue is empty) for at least one > frame, but the HCD still sees an outstanding TD, then that TD must be > lost. But it may be that even though the queue is still empty, there > were intervening transactions in the meantime (it was momentarily > nonempty, but is now empty again). I'm missing something. No matter what, the HCD has a record that some TD *was* queued, but it's not yet been handed back through the donelist. Oh ... I guess you're thinking that "which TD" needs tracking? You could do that easily enough; you're already tracking the ED, just save a TD pointer too. > Either way, this patch in its current form isn't safe. Darn. OK, I'm sure Greg will know not to merge it. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
