lkml.org 
[lkml]   [2006]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64
Date
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-09-19 22:53    [W:0.092 / U:9.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site