Messages in this thread | | | Date | Sun, 20 Oct 2002 19:44:42 -0700 | From | David Brownell <> | Subject | Re: [linux-usb-devel] 2.5.42-ac1, 2.5.42, 2.5.41 boot hang with CONFIG_USB_DEBUG=n |
| |
>> 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |