Message-Id: <200609192253.55170.rjw@sisk.pl>
Date:	Tue, 19 Sep 2006 22:53:54 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	David Brownell <david-b@...bell.net>
Cc:	Jan De Luyck <ml_linuxkernel_20060528@...re.org>,
	Andrew Morton <akpm@...l.org>,
	LKML <linux-kernel@...r.kernel.org>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists