My Thinkpad R50P (Intel 82855PM with Speedstep 1.7GHz) shows the
following badness when resuming after an ACPI suspend - even if hotplug
and usb modules were never started beforehand:
Well clearly (a) something _did_ start at least one module, (b) there's bogus data in the controller's PCI config space, and (c) the EHCI driver would seem to need to defend itself against such bogus data.
If you "modprobe ehci_hcd" after (or during) a normal boot, rather than after ACPI suspend, does this happen? If not, that would seem to suggest that (b) is caused by ACPI.
You might want to find out what makes (a) happen; it sounds like it's not expected on your system.
... ehci_hcd 0000:00:1d.7: capability d49a4140 at 41 ... last message repeated 1266 times ...
This is repeated many many times -> CPU usage jumps to 100% (due to ehci_hcd module) and klogd becomes very busy with the above nonsense.
The attached patch should address (c); please let us know.
- Dave
Defend EHCI against some PCI problems seen during ACPI resume.
--- 1.70/drivers/usb/host/ehci-hcd.c Thu Feb 26 19:14:50 2004
+++ edited/drivers/usb/host/ehci-hcd.c Mon Mar 15 07:41:09 2004
@@ -326,6 +326,7 @@
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 temp;
+ unsigned count = 256/4;
spin_lock_init (&ehci->lock);
@@ -337,10 +338,11 @@
/* EHCI 0.96 and later may have "extended capabilities" */
temp = HCC_EXT_CAPS (readl (&ehci->caps->hcc_params));
- while (temp) {
+ while (temp && count--) {
u32 cap;
- pci_read_config_dword (to_pci_dev(ehci->hcd.self.controller), temp,
&cap);
+ pci_read_config_dword (to_pci_dev(ehci->hcd.self.controller),
+ temp, &cap);
ehci_dbg (ehci, "capability %04x at %02x\n", cap, temp);
switch (cap & 0xff) {
case 1: /* BIOS/SMM/... handoff */
@@ -355,6 +357,10 @@
break;
}
temp = (cap >> 8) & 0xff;
+ }
+ if (!count) {
+ ehci_err (ehci, "bogus capabilities ... PCI problems!\n");
+ return -EIO;
}
/* cache this readonly data; minimize PCI reads */
