public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Jan De Luyck <ml_linuxkernel_20060528@kcore.org>
Cc: Andrew Morton <akpm@osdl.org>,
	LKML <linux-kernel@vger.kernel.org>,
	USB development list <linux-usb-devel@lists.sourceforge.net>
Subject: Re: 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64
Date: Mon, 18 Sep 2006 17:04:41 -0700	[thread overview]
Message-ID: <200609181704.42063.david-b@pacbell.net> (raw)
In-Reply-To: <200609160013.16014.rjw@sisk.pl>

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".

- Dave




  parent reply	other threads:[~2006-09-19  2:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-15 22:13 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64 Rafael J. Wysocki
2006-09-16  8:13 ` 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices Rafael J. Wysocki
2006-09-18  6:27   ` Rafael J. Wysocki
2006-09-18  6:50     ` Jan De Luyck
2006-09-18 11:20       ` Rafael J. Wysocki
2006-09-18 15:07     ` Alan Stern
2006-09-18 20:51       ` Rafael J. Wysocki
2006-09-18 21:16         ` Alan Stern
2006-09-19  0:04 ` David Brownell [this message]
2006-09-19 20:53   ` 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64 Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200609181704.42063.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=ml_linuxkernel_20060528@kcore.org \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox