[PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[Larry Finger]

In my system, a number of messages that state "unable to enumerate USB device"
are logged. These are intermittent and likely due to some race condition
at bootup.

Some of these happen when the EHCI driver is loaded after UHCI or OHCI, which
causes the device to be switched away from the other controller that's trying
to enumerate it, at least momentarily. This type of message is logged at most
once for each hub and occurs in about 70% of my reboots.

A more insidious form of the message occurs hundreds of times in about 10% of
reboots. They continue until the system is rebooted. This patch limits the
number of these messages to 20. Once the actual cause of this message is
located, this patch can be reverted.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---

Index: linux-2.6/drivers/usb/core/hub.c
===================================================================
--- linux-2.6.orig/drivers/usb/core/hub.c
+++ linux-2.6/drivers/usb/core/hub.c
@@ -2746,6 +2746,7 @@ static void hub_port_connect_change(stru
 			le16_to_cpu(hub->descriptor->wHubCharacteristics);
 	struct usb_device *udev;
 	int status, i;
+	static int enum_count;

 	dev_dbg (hub_dev,
 		"port %d, status %04x, change %04x, %s\n",
@@ -2945,8 +2946,9 @@ loop:
 	if (hub->hdev->parent ||
 			!hcd->driver->port_handed_over ||
 			!(hcd->driver->port_handed_over)(hcd, port1))
-		dev_err(hub_dev, "unable to enumerate USB device on port %d\n",
-				port1);
+		if (enum_count++ < 20)
+			dev_err(hub_dev, "unable to enumerate USB device on "
+				"port %d\n", port1);

 done:
 	hub_port_disable(hub, port1, 1);

Re: [PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[Greg KH]

On Thu, Oct 23, 2008 at 04:35:01PM -0700, Larry Finger wrote:
> In my system, a number of messages that state "unable to enumerate USB device"
> are logged. These are intermittent and likely due to some race condition
> at bootup.
> 
> Some of these happen when the EHCI driver is loaded after UHCI or OHCI, which
> causes the device to be switched away from the other controller that's trying
> to enumerate it, at least momentarily. This type of message is logged at most
> once for each hub and occurs in about 70% of my reboots.

What kernel version are you having these problems with?

thanks,

greg k-h

Re: [PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[Larry Finger]

Greg KH wrote:

> What kernel version are you having these problems with?

This problem started sometime in the 2.6.26-git sequence, and persists to the
latest from the linux-2.6 git tree.

Larry

Re: [PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[Greg KH]

On Fri, Oct 24, 2008 at 09:25:57AM -0700, Larry Finger wrote:
> Greg KH wrote:
> 
> > What kernel version are you having these problems with?
> 
> This problem started sometime in the 2.6.26-git sequence, and persists to the
> latest from the linux-2.6 git tree.

The latest tree should warn you if you load the host controller drivers
in the wrong order, so this shouldn't really be an issue anymore, right?

Like Alan said, proper log messages would be helpful here.

thanks,

greg k-h

Re: [PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[Larry Finger]

Greg KH wrote:
> 
> The latest tree should warn you if you load the host controller drivers
> in the wrong order, so this shouldn't really be an issue anymore, right?

I have not seen such warhings, thus I expect loading is in the proper order.
> 
> Like Alan said, proper log messages would be helpful here.

Agreed, but I have no idea what I should be looking for. For the moment, I have
lots of test prints looking for the sequence of events that lead to this
spamming of the logs.

Larry

Re: [PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[Alan Stern]

On Fri, 24 Oct 2008, Larry Finger wrote:

> Greg KH wrote:
> > 
> > The latest tree should warn you if you load the host controller drivers
> > in the wrong order, so this shouldn't really be an issue anymore, right?
> 
> I have not seen such warhings, thus I expect loading is in the proper order.
> > 
> > Like Alan said, proper log messages would be helpful here.
> 
> Agreed, but I have no idea what I should be looking for. For the moment, I have
> lots of test prints looking for the sequence of events that lead to this
> spamming of the logs.

Just build your test kernel with USB debugging enabled, and when you 
get that spamming, post the complete dmesg log.

Alan Stern

Re: [PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[Larry Finger]

Alan Stern wrote:
> 
> Just build your test kernel with USB debugging enabled, and when you 
> get that spamming, post the complete dmesg log.

Once I added ehci_hcd to my initrd, which ensured that it was loaded first, the
error messages seem to have disappeared. If they return, I'll open a new thread.

Thanks for the help,

Larry

Re: [PATCH] usbcore: Limit number of 'unable to enumerate USB device' messages

[Alan Stern]

On Thu, 23 Oct 2008, Larry Finger wrote:

> In my system, a number of messages that state "unable to enumerate USB device"
> are logged. These are intermittent and likely due to some race condition
> at bootup.
> 
> Some of these happen when the EHCI driver is loaded after UHCI or OHCI, which
> causes the device to be switched away from the other controller that's trying
> to enumerate it, at least momentarily. This type of message is logged at most
> once for each hub and occurs in about 70% of my reboots.

This is normal; it is caused by userspace loading the drivers in the
wrong order.  ehci-hcd is supposed to be loaded before uhci-hcd or
ohci-hcd, not after.  There's no point trying to change the kernel to
avoid it.

> A more insidious form of the message occurs hundreds of times in about 10% of
> reboots. They continue until the system is rebooted. This patch limits the
> number of these messages to 20. Once the actual cause of this message is
> located, this patch can be reverted.

I would prefer to attack this problem directly rather than wallpaper 
over it.  Can you provide more information?  For example, a dmesg log 
with CONFIG_USB_DEBUG and CONFIG_PRINTK_TIME enabled would help.  It 
might also help to know what the devices which can't be enumerated 
actually are.

Alan Stern