fix some hubs and hid devices at startup

PATCH In review Greg KH 2 participants 4 messages Mar 11, 2002 – Mar 20, 2002 USB

lore

Share & tools

lore

Greg KH

author

2002-03-11 21:50 UTC #0 lore raw

PATCH 1/1 fix some hubs and hid devices at startup

Hi,

Since the latest USB patch went in that added a proper delay to the hub connection sequence, a lot of people have been reporting odd problems with some USB hubs, keyboards, and mice. I've seen this problem too. It is usually fixed by just replugging the device in, but not all of the time.

The reason seems to be that usbmodules is getting called from the hotplug package at the same time the hub driver is talking to the device. Since we don't have control endpoint locking in the kernel USB code yet, this messes things up :)

The patch below, from Olaf Hering, seems to fix the problem. Also just removing the usbmodules binary seems to fix it for other people, but that's not really a good fix.

Let me know what you think about this.

thanks,

greg k-h

Index: etc/hotplug/usb.agent
=================================RCS file: /cvsroot/linux-hotplug/admin/etc/hotplug/usb.agent,v retrieving revision 1.19

hotplug/usb.agent +3 -0

diff -a -u -r1.19 usb.agent
@@ -297,6 +297,9 @@
 case $ACTION in
 
 add)
+    # Let the usb subsystem finish talking to the device, before we do
+    sleep 3
+
     usb_convert_vars
 
     FOUNDúlse

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Greg KH

author

2002-03-12 20:33 UTC #1 lore raw

Quoted 9 lines · Oliver Neukum

Quoted 6 lines
The patch below, from Olaf Hering, seems to fix the problem. Also just removing the usbmodules binary seems to fix it for other people, but that's not really a good fix.
Let me know what you think about this.
It is voodoo, but it works.
I trust it won't keep you from fixing the locking.

No, it will not :)
Thanks for reminding me to add this to the TODO list.

greg k-h

Olaf Hering

2002-03-20 14:53 UTC #2 lore raw

In reply to Greg KH

Quoted 31 lines · Greg KH

Hi,
Since the latest USB patch went in that added a proper delay to the hub connection sequence, a lot of people have been reporting odd problems with some USB hubs, keyboards, and mice. I've seen this problem too. It is usually fixed by just replugging the device in, but not all of the time.
The reason seems to be that usbmodules is getting called from the hotplug package at the same time the hub driver is talking to the device. Since we don't have control endpoint locking in the kernel USB code yet, this messes things up :)
The patch below, from Olaf Hering, seems to fix the problem. Also just removing the usbmodules binary seems to fix it for other people, but that's not really a good fix.
Let me know what you think about this.
thanks,
greg k-h
Index: etc/hotplug/usb.agent
=================================> RCS file: /cvsroot/linux-hotplug/admin/etc/hotplug/usb.agent,v retrieving revision 1.19
diff -a -u -r1.19 usb.agent

hotplug/usb.agent line 305

Quoted 9 lines

hotplug/usb.agent +3 -0

@@ -297,6 +297,9 @@
 case $ACTION in
 
 add)
+    # Let the usb subsystem finish talking to the device, before we do
+    sleep 3
+
     usb_convert_vars
 
     FOUNDúlse

That patch does indeed fix the problem with some devices, sometimes you even need a sleep 5.

But since all that runs in background the bootscripts will continue to run. And if gpm wants the /dev/input/mice node and the mousedriver is not loaded ...
Or printer.o and rclpd, everything fails :)

The delay has to be added, either to the hotplug scripts or to the usbdevfs core. But it will delay the driver loading in both cases, so the startup scripts may fail. It depends on your configuration and the speed of your cpu and/or IO.

Gruss Olaf

Signature · 9 lines

 $ man clone

BUGS
       Main feature not yet implemented...

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Greg KH

author

2002-03-20 17:19 UTC #3 lore raw

In reply to Greg KH

Quoted 8 lines · Olaf Hering

That patch does indeed fix the problem with some devices, sometimes you even need a sleep 5.
But since all that runs in background the bootscripts will continue to run. And if gpm wants the /dev/input/mice node and the mousedriver is not loaded ...
Or printer.o and rclpd, everything fails :)

Quoted 4 lines

The delay has to be added, either to the hotplug scripts or to the usbdevfs core. But it will delay the driver loading in both cases, so the startup scripts may fail. It depends on your configuration and the speed of your cpu and/or IO.

Yes, it's a bandage over the real problem, sorry.

But here's a patch from Itai Nahshon that seems to fix a lot of problems that he was having with the latest 2.4.19-pre3 USB code when a device is connected to the bus. It also seems to fix a lot of issues a few keyboards and hubs that I was seeing here.

I've applied this to both the 2.4 and 2.5 trees.

thanks,

greg k-h

drivers/usb/hub.c +2 -2

diff -Nru a/drivers/usb/hub.c b/drivers/usb/hub.c
@@ -655,11 +655,11 @@
  * Not covered by the spec - but easy to deal with.
  *
  * This implementation uses 400ms minimum debounce timeout and checks
- * every 10ms for transient disconnects to restart the delay.
+ * every 100ms for transient disconnects to restart the delay.
  */
 
 #define HUB_DEBOUNCE_TIMEOUT	400
-#define HUB_DEBOUNCE_STEP	10
+#define HUB_DEBOUNCE_STEP	100
 
 /* return: -1 on error, 0 on success, 1 on disconnect.  */
 static int usb_hub_port_debounce(struct usb_device *hub, int port)