When uhci.c module receives uhci_pci_suspend event, it calls reset_hc().
If the system has complex APM scripts which take a long time to do their
job (like I have), it just might be that the hardware reset finishes
before the system actually enters suspend state and you get errors like
this:
hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s
hub.c: USB new device connect on bus1/1, assigned device number 7
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=7 (error=-110)
The same problem is in the 2.2.19 kernel uhci.c driver, except that
the 2.2.19 uhci driver never recovers from this situation.
Here is a trivial patch against linux-2.4.9-ac10, which fixes the problem
(at least, it fixes it for me). Please CC your comments to me, since I am
not on the list.
--- uhci.c.orig Thu Sep 13 18:36:00 2001
+++ uhci.c Sun Sep 23 19:05:26 2001
@@ -2921,7 +2921,7 @@
#ifdef CONFIG_PM
static int uhci_pci_suspend(struct pci_dev *dev, u32 state)
{
- reset_hc((struct uhci *) dev->driver_data);
+ suspend_hc((struct uhci *) dev->driver_data);
return 0;
}
- Jani
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel