> I enabled USB debugging. Although I don't understand all the data, this
> section
> looks strange.
> 
> ehci_hcd 0000:00:04.1: GetStatus port:5 status 003001 0  ACK POWER OWNER
> sig=se0 CONNECT
> hub 2-0:1.0: port 5 not reset yet, waiting 50ms
> ehci_hcd 0000:00:04.1: GetStatus port:5 status 001002 0  ACK POWER sig=se0
> CSC
> hub 2-0:1.0: unable to enumerate USB device on port 5

This is normal enough.  When a non-high-speed device is attached to an 
EHCI controller, the controller reports its presence, tries to 
initialize it, and only then realizes that the device can't run at high 
speed.  Instead a bit gets set which causes the device connection to 
be routed to the companion OHCI controller.  That's what the

	ehci_hcd 0000:00:04.1: port 5 full speed --> companion

message means.  It looks like something goes wrong at this point and 
the device is reconnected to the EHCI controller, which sees it as a 
brand-new connection.  The connection routing isn't working right.

> ===========================================
> A bigger portion of the dmesg output with USB debugging enabled follows (full
> dmesg output attached):

In the future, please attach large files like this to the bug report 
instead of pasting them directly in the comment field.

Alan Stern

Hi all, 

maybe this information helps:

The mentioned behaviour appeared in Debian/testing exactly since kernel version

linux-image-2.6.32-5-amd64. All higher versions include this bug.

However, I have to specify it, to get an exactly date of change!


working:      linux-image-2.6.32-5-amd64 (exact version 2.6.32-30)
non-working:  linux-image-2.6.32-5-amd64 (exact version 2.6.32-34s)

Between these two version must have been a change of the module "ohci-hcd", which causes this bug. Maybe it is possible, to revert only this module to an older and working state? This bug effects ALL kernels, so it appears also on any lifefile systems, like Knoppix, Backtrack5 and so on.

Hope this helps.

Best regards

Hans

This should now be fixed by commit 69d8d8fd0dabc5357f5ec91046bc1bd9011012b6 (OHCI: fix regression caused by nVidia shutdown workaround) in 2.6.39.1 and perhaps other stable kernels.

Just tested linux-image-2.6.39-2-amd64 from debian-amd64/wheezy, but got the same error again. I also tested the newest kernel from debian-amd4/experimental, with no success, too.

Sorry to tell, the bug seems not to be fixed, yet.

As soon, as there is a new version in debian available, I will test this, and report of success or failure.

Thank you very much for your help anyway!

Best regards

Hans-J. Ullrich

What are the details for your USB hub as shown by lspci? As noted above, one of my hubs on an HP laptop seems to be wired incorrectly. There are two ways to kill the error messages:

(1) Add the following to a script that will run as soon as user space is working. On my openSUSE system, these are in /etc/init.d/boot.local:

echo "0000:00:04.1" > /sys/bus/pci/drivers/ehci_hcd/unbind
echo "0000:00:04.0" > /sys/bus/pci/drivers/ohci_hcd/unbind

The bus numbers would have to change for your system.

(2) Get rid of the message with the following patch:

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
@@ -3136,6 +3136,7 @@ static void hub_port_connect_change(stru
                        le16_to_cpu(hub->descriptor->wHubCharacteristics);
        struct usb_device *udev;
        int status, i;
+       static int msg_count;
 
        dev_dbg (hub_dev,
                "port %d, status %04x, change %04x, %s\n",
@@ -3347,8 +3348,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 (msg_count++ < 5)
+                       dev_err(hub_dev, "unable to enumerate USB device on port %d\n",
+                                       port1);
  
 done:
        hub_port_disable(hub, port1, 1);

With this installed, you will get 5 of the messages.

That linux-image-2.6.39-2-amd64 sonds like it still uses a 2.6.39 kernel, not 2.6.39.1 or later.  What version does debian-amd4/experimental use?

Can you try building your own kernel from the source at kernel.org?

Hi Alan, 

maybe you are right, the debian kernel might still be a 2.6.39 (although they patch kernels sometimes and add a "-N" (where N is a number) to it.
I dare not to build an own kernel from kernel.org, as this is my productive notebook, which I need every day and can not allow me, to brick it with a kernel I built by myself. I am not much experienced with building a kernel from kernel.org, although it was easy for me to rebuild with the kernel-sources from debian.


Hello Larry,
I already tried this thing before, but it did not work for me. In my case the usb-hub on my notebook should be wired correctly, as I already mentioned, it is ok with an older kernel. 


General
I googled a little bit, and it seems, this bug appears only on systems with a Nvidia chipset  MCP67. Because of this, there are not many bugreports, as the combination 
"Kernel-2.6.3[3-9] + Nvidia chipset MCP67" will be not much used.

I will wait for 2.6.39.1 in debian. Fingers crossed! In the meantime I am still using 2.6.32, which is running great, too.

Thanks and great, that you took a look at this bug, although we are only few people with this problem.

Hans

My system was OK with an older kernel. Any kernel prior to the commit in the title of this bug report was OK.

I agree that the nVidia controllers are the problem.

You can check the debian source code to see if the patch which was supposed to fix the regression has been incorporated.  The patch itself is here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b7aaf503d56216b847c8265421d2a7d9b42df3e

If it isn't in the debian source, you can add it yourself and test it.

Hi Alan,

just tested the latest kernel from debian. Due to the changelog, your fix 
69d8d8fd0dabc5357f5ec91046bc1bd9011012b6 is included. But sorry, to tell you, the fix on my system does still not work. 

My USB-Controller is this:

00:02.0 USB Controller: nVidia Corporation MCP67 OHCI USB 1.1 Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation MCP67 EHCI USB 2.0 Controller (rev a2)
00:04.0 USB Controller: nVidia Corporation MCP67 OHCI USB 1.1 Controller (rev a2)
00:04.1 USB Controller: nVidia Corporation MCP67 EHCI USB 2.0 Controller (rev a2)

I read, that this problem is not easy to fix. But there is no time to hurry! I will be happy, if you or someone else will have a look on it, but there is no reason for hurry.

This comment is just an info, that the bug is still existent (maybe now only on very few and special systems like mine).

I am very happy, that someone cares at all!

Cheers

Hans

Can you build a kernel with CONFIG_USB_DEBUG enabled and then attach a copy of the dmesg log for bootup?

Hi Alan, 

lasted a little bit, but now I managed to build the kernel. I hope, the attached dmesg is not too long.

I hope, this will help a little bit.

Happy hacking!

Hans

The log you sent clearly came from a kernel built without CONFIG_USB_DEBUG, so I can't tell anything much from looking at it.  But at least it doesn't contain any of those "unable to enumerate USB device" messages.  Does that mean it's working correctly?

Hello Alan,

nope, the logs should be from the kernel built with CONFIG_USB_DEBUG=y (before build, i checked, and I saw during build a lot of "--opt-debug" messages.

Let me check again, I will create new dmesg files and send them again. Maybe I made somthing wrong, as I had had a little troubly while building (my /usr partition was too small, so I had to free some space and had to build several times).

I will send the logs to your e-mail-address again.


Hans

You should be able to attach the log with no difficulty.  What went wrong last time?

If you have to email it to me, it's not necessary to include multiple copies of the log; one copy is enough.  Plain text, not compressed.

Sorry for sending too much of the logs. I searched for a "attach file" button in this mask, but found none. As the kernel-module was spamming my logfiles, I did not dare, to sent this long textfile here in this messages. I thought the original one from Larry might explainb things, too.

The error message appears almost every second (or faster) in the console, so my log is also full of it.

Working with kernel-2.6.39 is nealy imposible, as it spams console (tty1-6), too. I am just working in X (with xterm), where I do not see any error messages.

Please excuse, that I can help only such few. Besides just a question: I wondered, that during kernel build the sources blew up from to over 6GB! That is very much, is that normal? It broke my /usr partition (no space left), as I had only 4GB free.

Hans

Hi Alan, 

it's me again. I just dicovered, that debian offers an already compiled debug kernel as a simply to install package. That way, it is easy for me to create dmesg-files with a lot of information. Howevedr, i think, they might be very large. So I decided to send them directly to you, if you don't mind. The bug is still existent, despite of the already mentioned bugfix in the changelog.


Please feel free, to populate the necessary dmesg-parts here, so that other people can also have a look at it and might be able to help. 

For any futher information I will be happy to help.

Hans

What I'd like to see at this point is a dmesg log starting from bootup of 2.6.39.1 with CONFIG_USB_DEBUG enabled.  Also, you can stop sending those logs with thousands of debugging messages about the port statuses -- they're all exactly the same, so seeing hundreds and hundreds of them gives me no more information than seeing just one.

The "Add an attachment" button is at the bottom of the "Attachments" box near the top of this Bugzilla web page.

Created attachment 64762 [details]
dmesg file with debugging in kernel = on

This is my dmesg output. During this session I unloaded ohci-hcd using rmmod and loaded it again with modprobe ohci-hcd.

The attached file is useless because it contains nothing but those port status messages.  You may need to increase CONFIG_LOG_BUF_SHIFT, perhaps make it as large as 20.  Or else boot with a serial or network console so that the log can be captured remotely.

Also, when you add an attachment that is a plain text file, you should tell Bugzilla it is plain text by choosing the appropriate selection under "Content Type" -- don't use auto-detect.

Hi Alan, 

I suggest to close this bugreport, as it seems, I am the only one who has got this problem. It always lasted hours to build a new kernel, then testing ist and then uninstall it again and make everything clean again. It is really kind of you to help, but doing this only for me it is not worth the thing. I can stay at the older kernel, it does not matter for me. Obviously your fix already helped the others (like Larry) and for myself to fix this bug is not necessary. There are more important things than fix this little bug to do. 

So I suggest not to spend any time for me, I see, it will not be easy to solve. You already helped me by confirming, it is because of my Nvidia-special-hardware. 

So again, safely close the bugreport, I will check again when kernel-3.0 will be released. Then maybe I might reopen the bug again, if you don't mind.

Thank you for all the patience and the time you were looking at my messages.

Best regards

Hans

I still have the problem and there is at least one more person on the openSUSE Forums that sees it. I'm happy with my workarounds, but I think the bug should be left open just in case it is not a hardware problem as Alan and I concluded earlier.

Hello Larry, it is ok for me to let this bug open. 

I just wanted to avoid, that people cared of ONE person (me), who 
- additionally can only very little help. 
- has lot of problems, due to small ressources of time and hardware
- counts that bug not so muich important for himself

Please excuse!

Best regards

Hans

Larry, if you're willing to continue investigating, you can do what I asked Hans: Attach a dmesg log from a kernel with CONFIG_USB_DEBUG enabled.  It doesn't have to start from bootup; all I really need to see is what happens when ohci-hcd is loaded and the host controllers are initialized.

Created attachment 64812 [details]
Config file, how I built the kernel

Created attachment 64832 [details]
dmesg log with CONFIG_USB_DEBUG enabled.

Alan: I hope I let this run long enough for you. I disabled my code that limits the number of messages that are logged and the special commands that unbind the offending hubs.

As you see, the kernel is a 3.0.0-rc5 from the staging-2.6 git tree.

That's plenty long enough -- in fact, the first 20 seconds would have been more than long enough.

Our of curiosity, what happens if you unload ehci-hcd?  Does the low-speed device plugged into port 5 then connect okay?  Or do the OHCI ports remain unusable?

Comparing the current system with the code before the troublesome commit, I see only one difference.  In drivers/usb/host/pci-quirks.c:quirk_usb_handoff_ohci(), these lines

	/* reset controller, preserving RWC (and possibly IR) */
	writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);

used to be up a little, inside the "if (control & OHCI_CTRL_IR) {" block.  With NVIDIA hardware, I assume that test fails and the block doesn't get executed.

You can test to see if commenting out that writel() gets rid of all those messages, and if it allows the low-speed device to work with the OHCI controller.

Hi Alan, 

when ehci-hcd is unloaded, the spamming messages are staying. But when you unload ohci-hcd, the messages disappear. I also tried to reinitialise /dev/usb (there was a workaround I found somewhere in the internet), that told me to echo something to /proc, but I cannot remember, what exactly it told me. Sorry for that!
But I can confirm, that workaround did not work here. However, I could find out, that ehci-hcd does not interfere with ohci-hcd and other round. 

Hope this helps a little bit.

Hans

Hi Alan, 

when ehci-hcd is unloaded, the spamming messages are staying. But when you unload ohci-hcd, the messages disappear. I also tried to reinitialise /dev/usb (there was a workaround I found somewhere in the internet), that told me to echo something to /proc, but I cannot remember, what exactly it told me. Sorry for that!
But I can confirm, that workaround did not work here. However, I could find out, that ehci-hcd does not interfere with ohci-hcd and other round. 

Hope this helps a little bit.

Hans

On my system, lsusb shows the following:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 04f2:b016 Chicony Electronics Co., Ltd VGA 30fps UVC Webcam

There are 3 accessible USB ports. I do not have any low-speed devices, but high-speed units plugged into those ports all show up on Bus 1. From that I concluded that Bus 2 and its companion 1.1 root hub (Bus 4?) are present on the motherboard, but have no ports attached. On a laptop, it is hard to tell. In any case, I have no way of testing that any port on those hubs is functional.

Yes, disabling the writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL); line causes the problem to disappear.

I have a local patch that limits the number of "unable to enumerate" messages logged to 5. That way I can quickly determine when and if a solution has been found. I also unlink those two hubs in boot.local just in case I run a kernel without the patch. Keeping those two modifications are not a severe burden.

Thanks for looking at this again.

Larry

Created attachment 64912 [details]
put OHCI controller into suspend after reset

Larry, here's a patch for you to try.  The only difference between the current driver and the old one is that during initialization, the OHCI controllers are now put into the RESET state (that's what the writel() does).  Evidently NVIDIA controllers don't like to remain in RESET for a long time.

This patch puts the controller into the SUSPEND state after 50 ms of reset.  Hopefully the controller won't mind this as much.

Congratulations. Adding that patch got rid of the remaining failure messages that I was allowing through and seems to have solved the problem.

I'm in the middle of a bisection at the moment with 8 steps left, which makes it tough to revert my special patch that suppresses the messages, but I feel that it is safe to push this one with a Tested-by: Larry Finger <Larry.Finger@lwfinger.net>. If that is wrong, I'll let you know within 24 hours.

That's great!  Still, I'd like to see more testing before I submit this.  Hans, can you try out that patch?  I'll also ask Ben Hutchings to prepare a kernel for other Debian users to try.

By the way, what happens with this patch if you unload ohci-hcd and then a few seconds later, modprobe it back?

The "unable to enumerate" messages return after unloading/reloading ohci-hcd.

I was afraid something like that might happen.  The driver leaves the controller in the RESET state when it exits.  Still, this doesn't seem like such a high price to pay.  Most people don't unload and reload their drivers.

I never have before. I agree that the "price" is reasonable, particularly as only a few of us are affected.

Hi Alan, 

unloading ohci-hcd stops spamming the logs. When I load it again (modprobe ohci-hcd), the spamming is starting again. 

Very nice, when there is a kernel-package available, I will be pleased to install and test it. 
Either I can download it somewhere, or I may pull it from the debian repositories (experimental/debian-amd64).

As soon as I got results, I will be happy to report it.

Hans

Hi Alan and Larry,

I just tested the latest kernel in debian, which is linux-image-3.0.0-rc6-amd64. I am not know, if your newest patch is already in this kernel. The changelog delivered by debian did nothing tell about usb. Well, the bug is still existent in this kernel, so I doubt, the fix is included. If it is, it did not work.

Does this help?

Hans

Ben Hutchings has now created some updated debian kernels for people to test:

> The binary packages are:
>
> http://people.debian.org/~benh/packages/linux-image-2.6.39-3-686-pae_2.6.39-4~a.test1_i386.deb
>
> http://people.debian.org/~benh/packages/linux-image-2.6.39-3-amd64_2.6.39-4~a.test1_amd64.deb
> 
> The source package and signed changes file are in the same directory.

Hi Ben, Alan and all the other helpers. I just tested Ben's packages, and here they work very fine! Woot! No more annoying messages seen yet. 

Although I could bot build the nvidia-kernel-module (as the correct headers are yet missing), I suppose, the bug has been fixed. 

As soon as all packages are officially available, I will build nvidia-kernel-module and test again, but I think, this will be not necessary. I am very happy, really!

You should know, if this really works, it means, also most of the livefile systems like Backtrack5, Partimage, Clonezilla and many others, based on this kernel, will work in the next verion again. I am looking forward to the next release,, so that I can fix my version of Backtrack5 (which is at the moment unusable for me)

Thank you very much! Great work! 

Cheers

Hans

That's good news.  All right, I'll submit this patch for inclusion in the kernel.

The patch has been accepted and will appear in the 3.1 kernel as well as various stable kernels.  This bug report can be closed out.

A patch referencing this bug report has been merged in Linux v3.1-rc1:

commit 6ea12a04d295235ed67010a09fdea58c949e3eb0
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Jul 15 17:22:15 2011 -0400

    USB: OHCI: fix another regression for NVIDIA controllers

All USB bugs should be sent to the linux-usb@vger.kernel.org mailing 
list, and not entered into bugzilla.  Please bring this issue up there,
if it is still a problem in the latest kernel release.

This seems to be fixed already.