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