linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Nicolas Mailhot <Nicolas.Mailhot@laPoste.net>
Cc: greg@kroah.com, linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] 2.5.42-ac1, 2.5.42, 2.5.41 boot hang with CONFIG_USB_DEBUG=n
Date: Tue, 15 Oct 2002 10:10:00 -0700	[thread overview]
Message-ID: <3DAC4BE8.6080109@pacbell.net> (raw)
In-Reply-To: 20021014212000.GA1002@rousalka.noos.fr

> Procedure was following :
> 1. reboot the computer (software reboot if ok kernel, else reset)
> 2. go through bios (long initiation with memory testing)
> 3. when the bootloader shows up (might hang just before, my disks really 
> do not like being stopped before reboot) / when the system hangs, press 
> reset
> 4. go through bios initialization (bis)
> 5. when grub shows up, play a bit in the menus (up-down...) then choose 
> a kernel
> 
> With this protocol I got a 100% boot rate on the original kernel and an 
> almost-always hang with the kernel where debuging was undefed in 
> drivers/usb/host/ohci-hcd.c. It did boot two times (out of maybe 10-15 
> tries) but that doesn't count since both times the keyboard was dead. 

Well, I've seen USB getting annoyingly flakey results in recent kernels.
That's a little bit outside the bounds of the inconsistency I've seen,
but (I hate to say) not unrealistically so, since you're kicking init
sequences in different ways.  That makes troubleshooting harder!

There are some one-liners floating around that make it a lot better,
like making drivers/base/core.c found_match() "return error != 0"
(true == matched) instead of "return error" (true == failed).  That
one might not be your issue at all, but I've seen it to fix failures
that closely resemble your "dead devices" mode.


> No such luck. It really looks like ohci is the culprit:(

Maybe not, given that you did report (in an earlier note):

 > + ... Unfortunately I've found out today not even CONFIG_USB_DEBUG
 > + was sufficient, since I had a boot hand (cold boot) with my debug
 > + kernel today (warm boot afterwards was ok, though).

Even if it isn't one of the bugs causing generic flakiness, a
warm-vs-cold boot problem that's ohci-specific isn't something
that should have appeared in recent kernels.  I'd be curious.
Was 2.5.38 behaving OK for you?  Or earlier 2.5 kernels?


> P.S.
> 
>     I don't know if it's important, but I had to enable usb keyboard 
> legacy mode in the bios to have keyboard support in the bootloader 
> stage. I had a bad feeling about the option though, a good bios is a 
> lean bios.

Unless your boot loader has a small USB stack, leave that emulation
enabled in the bios.  Linux will disable it when you bring up USB.

But it'd be worth seeing if there were any problems with that.  In fact,
in drivers/usb/host/ohci-hcd.c there is one dbg() that could affect
init timing.  Experiment:  leave all debug messages off, but change
the first dbg() call in hc_reset() into an err() call.  Does that make
things better?

- Dave


  reply	other threads:[~2002-10-15 17:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-13 17:25 2.5.42-ac1, 2.5.42, 2.5.41 boot hang with CONFIG_USB_DEBUG=n Nicolas Mailhot
2002-10-14 16:53 ` [linux-usb-devel] " David Brownell
2002-10-14 21:20   ` Nicolas Mailhot
2002-10-15 17:10     ` David Brownell [this message]
2002-10-15 17:39       ` Nicolas Mailhot
2002-10-15 21:00         ` David Brownell
2002-10-18 17:45       ` Nicolas Mailhot
2002-10-21  2:44         ` David Brownell

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=3DAC4BE8.6080109@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=Nicolas.Mailhot@laPoste.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    /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;
as well as URLs for NNTP newsgroup(s).