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: Sun, 20 Oct 2002 19:44:42 -0700 [thread overview]
Message-ID: <3DB36A1A.5040802@pacbell.net> (raw)
In-Reply-To: 20021018174553.GA1271@rousalka.noos.fr
>> 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?
>
>
> The answer is yes.
I'll submit a patch to make that arbitrary timeout longer, and make
sure the debug messages won't affect that timing again.
> I feel changing dbg() in err() is a bit worse than full
> CONFIG_USB_DEBUG=y. It certainly did hang more often at boot than with
> CONFIG_USB_DEBUG=y. However :
> * with err() I get about 50% boot chance
> * with err() I've never so far booted with a useless keyboard (sole
> times I booted with unchanged kernel and CONFIG_USB_DEBUG=n keyboard was
> dead)
> * when it hangs with err() the takeover message is printed (never was
> before on hang)
I think there's something funky about your BIOS, causing these boot
time problems. That takeover problem should _never_ happen. Can you
still get BIOS updates for that motherboard?
> Sometimes after 2.5.43 is booted switching to the console freezes the
> usb mouse. Don't know if it's related to the boot hang, but
> chain-restarting gpm will more often result into an oops than a
> recovered mouse. However I've just found that re-pluging it instead of
> restarting gpm unfreezes the mouse cursor.
That'd seem to be a different problem.
> drivers/usb/host/ohci-q.c: 00:07.4 bad entry 5fb7d1e1
> drivers/usb/host/ohci-q.c: 00:07.4 bad entry ffffffe1
> drivers/usb/host/ohci-q.c: 00:07.4 bad entry 5fb7d1e1
> drivers/usb/host/ohci-q.c: 00:07.4 bad entry ffffffe1
> drivers/usb/core/usb.c: USB disconnect on device 4
> drivers/usb/core/hub.c: new USB device 00:07.4-2.3, assigned address 6
> input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-00:07.4-2.3
>
>
> The « drivers/usb/host/ohci-q.c: 00:07.4 bad entry » are triggerred by
> gpm failing to restart.
Now that's the wierdest clue to that failure I've seen yet! :)
Good that for you it didn't seem to cause other trouble. I'm
starting to think I probably know where that problem must live.
- Dave
prev parent reply other threads:[~2002-10-21 3:10 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
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 [this message]
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=3DB36A1A.5040802@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.