+++ This bug was initially created as a clone of Bug #666563 +++

Description of problem:

During boot, two of the USB hubs on the motherboard seem to have problems. There is nothing plugged in to any USB port on the 


Version-Release number of selected component (if applicable):
2.6.35.10-74.fc14.x86_64

How reproducible:


Steps to Reproduce:
1. boot system
2. watch syslog
  
Actual results:

repeated, continual messages like this:
Dec 31 01:57:40 copernicus kernel: [    2.804273] hub 2-0:1.0: unable to enumerate USB device on port 4
Dec 31 01:57:40 copernicus kernel: [    2.976020] hub 4-0:1.0: unable to enumerate USB device on port 3


Expected results:

no (or few) such messages.


Additional info:

This is a fresh install of Fedora 14. Previously,the system had Fedora 12 but due to a hard drive failure, I installed F14 fresh. These messages were not observed prior to the drive failure.
Motherboard: MSI P7NGM-Digital
CPU:Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz

Possibly related to Bug #597651, but note that unlike that case, there are NO devices plugged in to any USB port.

[root@copernicus ~]# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[root@copernicus ~]# lspci
00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1)
00:00.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.0 ISA bridge: nVidia Corporation MCP79 LPC Bridge (rev b2)
00:03.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1)
00:03.3 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.4 RAM memory: nVidia Corporation Device 0a98 (rev b1)
00:03.5 Co-processor: nVidia Corporation MCP79 Co-processor (rev b1)
00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:06.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:06.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1)
00:09.0 PCI bridge: nVidia Corporation MCP79 PCI Bridge (rev b1)
00:0b.0 SATA controller: nVidia Corporation MCP79 AHCI Controller (rev b1)
00:0c.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:10.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:16.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:17.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:18.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
03:00.0 VGA compatible controller: nVidia Corporation C79 [GeForce 9300 / nForce 730i] (rev b1)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
06:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller
07:00.0 IDE interface: JMicron Technology Corp. JMB368 IDE controller

--- Additional comment from renich on 2011-06-03 00:08:50 EDT ---

Confirmed in F15 also.

--- Additional comment from kloe0040 on 2011-06-03 17:44:34 EDT ---

Also I see the same issue with F15.
No devices plugged in, but a continuous stream of 'unable to enumerate' messages, both in the syslog (/var/log/messages) and also in the dmesg output.
It causes the syslog file to grow fast (about a hundred new lines per minute) making it almost impossible to spot any other messages by eye without strict filtering.
The dmesg output seems limited by about 1800 lines, so in just a few seconds all usefull information is gone from this output, making it really hard to (manually) get information on new usb devices plugged in etc.

--- Additional comment from kloe0040 on 2011-06-26 07:51:01 EDT ---

In addition: the message is also printed in all tty screens.
Switching with control-alt-F2 just displays an endlessly repeating list of the same error with increasing timestamps.

This makes it nearly impossible to fall back to the commandline in case you need to fix something with the graphical mode (i.e. manually kill a frozen application that uses full-screen etc.). You have to type blind and be really fast in spotting any commandline output you might need, or it is gone again.
Seems to me a good enough reason to raise the urgency of this bug to medium or high.

--- Additional comment from kloe0040 on 2011-07-04 17:28:01 EDT ---

It seems these debian users are suffering from the same issue:
http://lists.debian.org/debian-kernel/2011/04/msg00576.html
they suspect it has to do with a recent nvidia hardware workaround. (I do have  nvidia hardware in my laptop as well).

So it seems not fedora specific.

However, I don't seem to be running the ohci-hcd kernel module, so could not test what the effect of unloading it is (or is this compiled in the kernel on fedora systems? How to check this?) so I am not completely sure.

--- Additional comment from abeclaudius on 2011-08-12 13:30:48 EDT ---

I all, it is not only about Debian users, i´m using Fedora 15 and i got the same error.

--- Additional comment from josdekloe on 2011-08-20 17:26:31 EDT ---

Upgrading from kernel 2.6.40-4.fc15 to kernel 2.6.40.3-0.fc15 (part of the default updates released past week by Fedora) seems to have solved this issue for me. At least I don't see other updates that I applied that day that can explain the fix. The full list of updates that I applied that day is:

Aug 18 10:52:32 Updated: ibus-libs-1.3.99.20110419-14.fc15.x86_64
Aug 18 10:52:33 Updated: gnome-python2-extras-2.25.3-33.fc15.x86_64
Aug 18 10:52:34 Updated: ibus-gtk2-1.3.99.20110419-14.fc15.x86_64
Aug 18 10:53:00 Updated: ibus-1.3.99.20110419-14.fc15.x86_64
Aug 18 10:53:01 Updated: ibus-gtk3-1.3.99.20110419-14.fc15.x86_64
Aug 18 10:53:06 Updated: xulrunner-6.0-2.fc15.x86_64
Aug 18 10:53:07 Updated: httpd-tools-2.2.19-2.fc15.x86_64
Aug 18 10:53:13 Updated: httpd-2.2.19-2.fc15.x86_64
Aug 18 10:53:21 Updated: firefox-6.0-1.fc15.x86_64
Aug 18 10:53:22 Updated: gnome-python2-libegg-2.25.3-33.fc15.x86_64
Aug 18 10:53:22 Updated: gnome-python2-gtkhtml2-2.25.3-33.fc15.x86_64
Aug 18 10:53:23 Updated: gnome-python2-gtkspell-2.25.3-33.fc15.x86_64
Aug 18 10:54:02 Installed: kernel-devel-2.6.40.3-0.fc15.x86_64
Aug 18 10:54:07 Updated: yum-utils-1.1.31-2.fc15.noarch
Aug 18 10:54:10 Updated: kernel-headers-2.6.40.3-0.fc15.x86_64
Aug 18 10:54:23 Installed: kernel-2.6.40.3-0.fc15.x86_64

I still have no idea what caused it or what fixed it, so if anyone has more information I would still be interested.
This bug can however be closed I think.

--- Additional comment from adalbert.prokop on 2011-08-25 14:09:32 EDT ---

I still see the reported errors - many "unable to enumerate USB device" with kernel 2.6.40.3-0 (PAE and x86).
I also have a NVidia video card (NForce2)

--- Additional comment from adalbert.prokop on 2011-08-25 14:17:36 EDT ---

Seems to be related to the kernel version. I've downgraded to 2.6.38.6 and the USB system works.

--- Additional comment from sha256sum on 2012-01-02 15:35:59 EST ---

I have this bug too in Fedora 16. Please update bug version number.

--- Additional comment from chrisa on 2012-01-28 12:28:55 EST ---

I have this problem as well on Fedora 16, latest kernel (3.2.2.1.fc16_x86_64).
It completely swamps messages.log

--- Additional comment from chrisa on 2012-02-03 01:16:12 EST ---

There appears to be a fix for Debian as per this link:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635573

Perhaps this can be used to resolve the problem in Fedora. Right now I have only two choices: 

1. Leave USB enabled in BIOS and have nothing but the "unable to enumerate USB device on port" messages in my messages logs (unending at the rate of about 3 or 4 a second) or

2. Disable USB in BIOS and be unable to use any attached USB devices.

--- Additional comment from chrisa on 2012-02-16 00:02:35 EST ---

Still exists with latest kernel (Linux <machine name> 3.2.6-3.fc16.x86_64 #1 SMP Mon Feb 13 20:35:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux), with same terrible choices: no USB or basically useless messages.log

As mentioned in comment 3, the fact that it swamps logs AND continues to exist across Fedora versions "Seems to me a good enough reason to raise the urgency of this bug to medium or
high."

--- Additional comment from chrisa on 2012-02-17 00:45:39 EST ---

Created a quick and dirty patch for drivers/usb/host/pci-quirks.c based on Debian fix mentioned in comment 11 at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635573

diff -uNrp kernel-3.2.fc16.orig/drivers/usb/host/pci-quirks.c kernel-3.2.fc16.new/drivers/usb/host/pci-quirks.c
--- kernel-3.2.fc16.orig/drivers/usb/host/pci-quirks.c	2012-02-16 09:22:07.466625150 -0500
+++ kernel-3.2.fc16.new/drivers/usb/host/pci-quirks.c	2012-02-16 01:29:30.933895895 -0500
@@ -505,7 +505,7 @@ static void __devinit quirk_usb_handoff_
 	writel((u32) ~0, base + OHCI_INTRDISABLE);
 
 	/* Reset the USB bus, if the controller isn't already in RESET */
-	if (control & OHCI_HCFS) {
+	if ((control & OHCI_HCFS) || (pdev->vendor == PCI_VENDOR_ID_NVIDIA)) {
 		/* Go into RESET, preserving RWC (and possibly IR) */
 		writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
 		readl(base + OHCI_CONTROL);

Tested on my box with NVIDIA proprietary kernel and VMWare Workstation, both of which are finicky - works perfectly.

No more constant stream of "unable to enumerate USB device on port", USB (and everything else it seems) appears to be working.

If there's anything else I can do to encourage/speed up fixing this bug, please let me know. BTW, the page on building your own kernel is FANTASTIC.
http://fedoraproject.org/wiki/Building_a_custom_kernel

One small niggle: I used a buildid of .USBPATCH001 which worked for creating the kernel, but was not recognized as newer than the release kernel version. Changing the buildid to .999 fixed that though.

--- Additional comment from chrisa on 2012-02-17 00:50:25 EST ---

Debian bug report with fix

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635573

Most of this code seems to be in the latest kernel, except specifically targeting NVIDIA hardware to force drive bus reset for 50ms.

Last entry for tonight, I promise :-)

--- Additional comment from chrisa on 2012-03-22 00:46:41 EDT ---

Problem still exists in latest Fedora 16 x86_64 kernel
Linux mythpiggy 3.2.10-3.fc16.x86_64 #1 SMP Thu Mar 15 19:39:46 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Rebuild using patch above fixes the problem, until the next kernel update :(

--- Additional comment from jwboyer on 2012-07-11 13:50:50 EDT ---

Fedora 15 has reached it's end of life as of June 26, 2012.  As a result, we will not be fixing any remaining bugs found in Fedora 15.

In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with.  Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered.

Thank you for taking the time to file a report.  We hope newer versions of Fedora suit your needs.

--- Additional comment from sha256sum on 2012-07-14 04:48:47 EDT ---

Please reopen and tag with F17. It is still a problem.