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

Reply via email to