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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
