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
Bill
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);
