On Tuesday, 19 September 2006 02:04, David Brownell wrote: > On Friday 15 September 2006 3:13 pm, Rafael J. Wysocki wrote: > > Hi, > > > > It looks like the ohci_hcd driver sometimes has problems with the > > initialization (eg. USB mouse doesn't work after a fresh boot and reloading > > of the driver helps). > > > > I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), > > but it is not readily reproducible. Anyway I've got a dmesg output from a > > failing case which is attached. > > Where I've seen such issues in the past has been with one specific > device: a UPS that seems unhappy if it doesn't get a VBUS power cycle, > so that OHCI implementations that don't implement power switching are > bad choices for connecting that particular UPS. > > I believe that's not the issue in your case. I compared the boot > sequence you sent with one for the NF3-150 I use a lot (also x86_64) > which does not exhibit this failure, and the differences I noticed > were: > > - NOCP set in roothub.a ... your BIOS reports no overcurrent protection > - different 2.6.18 prepatches ... you used rc6-mm2, not rc7 > - different irqs (you used PIC not IOAPIC) > - driver registration sequence different ... I registered EHCI first > - yours came _up_ with RHSC irq pending on one root (device present) > > And re those last two, it didn't finish mouse enumeration with OHCI before > starting to do it with EHCI. I could easily see how that would lead to > timing-dependent/intermittent failures. > > Now, registering EHCI first is not "supposed" to matter, but I'm thinking > it started to matter a while back, since a few folk have reported as much. > > One suspicion being that some of the hub driver changes have had some bad > consequences. (My suspicions there were highlighted by noticing some of > the misbehavior associated with an embedded USB controller I was testing, > which provoked failures in those same code paths...) The root hub handoff > relies on the usb/core/hub.c code to do the right things, notably treating > disconnect-during-reset (handoff to companion) as routine, but I think I > noticed that fault handling logic has changed. > > At any rate, that suggests a few experiments to me. > > - First, does this still show up with the stock RC7 code? There are > a bunch of IMO rather experimental USB patches in the MM tree... > including several affecting usbcore hub support. > > - Second does it appear without EHCI loaded? If not, that would > tend to confirm an issue usbcore hub driver handoff logic. > > - Third, does it appear if EHCI is loaded _first_ (as the distro > should already have been doing just to avoid thrashing during > system startup)? Similar comment re previous experiment, though > it'd provide a potential workaround. > > I'd kind of suspect that the generic RC7 code, with EHCI loaded first > as it should be, would "just work".
Yes, I think the problem resulted from the experimental patches in -mm. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel