Re: [linux-usb-devel] oops when loading ehci_hcd

From: David Brownell
Date: Fri Apr 16 2004 - 13:17:07 EST

Bill Nottingham wrote:
With a 2.6.6-rc1 based kernel. Happened when loading ehci_hcd some
10 hours after booting, couldn't reproduce in initial attempts. I
suppose the question is also why it failed to init, but it certainly
didn't like the failure...

Hmm, no it didn't. The "illegal capability" is the hardware acting
broken (what kind of EHCI hardware?); I've had reports of similar
stuff happening after ACPI resume (bogus PCI config space values,
in this case zero).

The "-19" means -ENODEV, which seem likely to be another case of a PCI
request not responding correctly: handshake() failing because reading
a register returned 0xffffffff.

Looks like a cleanup path needs to handle early failure a bit better;
likely just having ehci_stop test for ehci->async non-null (before
calling scan-async to clean up any pending work) would suffice.

- Dave


PCI: Enabling device 0000:00:1d.7 (0000 -> 0002)
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: illegal capability!
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 11, pci mem 22946000
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: init error -19ehci_hcd 0000:00:1d.7: remove, state 0
Unable to handle kernel NULL pointer dereference at virtual address 00000048
--- 1.75/drivers/usb/host/ehci-hcd.c Wed Apr 14 20:20:58 2004
+++ edited/drivers/usb/host/ehci-hcd.c Fri Apr 16 11:03:50 2004
@@ -592,7 +592,8 @@

/* root hub is shut down separately (first, when possible) */
spin_lock_irq (&ehci->lock);
- ehci_work (ehci, NULL);
+ if (ehci->async)
+ ehci_work (ehci, NULL);
spin_unlock_irq (&ehci->lock);
ehci_mem_cleanup (ehci);