?

Log in

No account? Create an account
penrose orange

stephenw32768


/var/log/stephen

cat /var/log/stephen >/dev/eyes


hub 1-5:1.0: unable to enumerate USB device on port 3
penrose orange
stephenw32768
thalassa has two USB ports on the front panel. Internally, these are actually part of a four-port hub. The other two ports don't have any sockets and aren't connected to anything, but the hub still looks like a four-port hub to the operating system.

For reasons unknown (loose connection? dry joint?) the third port seems to generate bogus signals that Linux interprets as being evidence of some connected device. It tries to communicate with the device, fails, and spams my system log:
usb 1-5.3: new low speed USB device using ehci_hcd and address 22
usb 1-5.3: device descriptor read/64, error -32
usb 1-5.3: device descriptor read/64, error -32
usb 1-5.3: new low speed USB device using ehci_hcd and address 23
usb 1-5.3: device descriptor read/64, error -32
usb 1-5.3: device descriptor read/64, error -32
usb 1-5.3: new low speed USB device using ehci_hcd and address 24
usb 1-5: clear tt 3 (0000) error -32
usb 1-5.3: device not accepting address 24, error -71
hub 1-5:1.0: unable to enumerate USB device on port 3

It's harmless apart from occasionally on startup when the initialization of my keyboard is delayed due to the system trying repeatedly to initialize a nonexistent device.

This has been going on for ages, but I finally got around to hacking Linux to work around the problem. Here's my patch against Linux 2.6.30:
--- a/drivers/usb/core/hub.c	2009-06-10 04:05:27.000000000 +0100
+++ b/drivers/usb/core/hub.c	2009-11-01 11:50:56.000000000 +0000
@@ -2751,6 +2751,12 @@ static void hub_port_connect_change(stru
 	struct usb_device *udev;
 	int status, i;
 
+	if ((port1 == 3) &&
+	    (strcmp(dev_name(hub_dev), "1-5:1.0") == 0)) {
+		/* shonky workaround: ignore the dodgy port */
+		return;
+	}
+
 	dev_dbg (hub_dev,
 		"port %d, status %04x, change %04x, %s\n",
 		port1, portstatus, portchange, portspeed (portstatus));

It's near the top of hub_port_connect_change(), so the machine wastes as few cycles as possible.

The correct solution would be to perform some minor surgery on thalassa to completely disconnect the nonexistent port, if that's possible. But at least this workaround keeps the logs and error console clear.