Regression in kernel 3.8-rc1 bisected to commit adfa79d: I now get many "unable to enumerate USB device" messages

The problem has been bisected to commit adfa79d entitled "USB: EHCI: make ehci-pci a separate driver". The symptom is that my NVIDIA controller again reverts to unended logging of messages of the form "hub 2-0:1.0: unable to enumerate USB device on port 5".

This behavior was previously fixed with commit c618759.

Quoted 4 lines · Larry Finger

The problem has been bisected to commit adfa79d entitled "USB: EHCI: make ehci-pci a separate driver". The symptom is that my NVIDIA controller again reverts to unended logging of messages of the form "hub 2-0:1.0: unable to enumerate USB device on port 5".

A few more details would be helpful, such as the dmesg log (with CONFIG_USB_DEBUG enabled). As it is, I don't see how that commit could cause this problem. It should not have resulted in any changes in behavior -- all it did was split up a driver that was one module into two modules.

Quoted 1 line

This behavior was previously fixed with commit c618759.

That commit affected the ohci-hcd driver, whereas this one affects ehci-hcd. They can't possibly be related.

Quoted 13 lines · Alan Stern

Quoted 4 lines · Larry Finger

The problem has been bisected to commit adfa79d entitled "USB: EHCI: make ehci-pci a separate driver". The symptom is that my NVIDIA controller again reverts to unended logging of messages of the form "hub 2-0:1.0: unable to enumerate USB device on port 5".

A few more details would be helpful, such as the dmesg log (with CONFIG_USB_DEBUG enabled). As it is, I don't see how that commit could cause this problem. It should not have resulted in any changes in behavior -- all it did was split up a driver that was one module into two modules.

Quoted 4 lines

Quoted 1 line

This behavior was previously fixed with commit c618759.

That commit affected the ohci-hcd driver, whereas this one affects ehci-hcd. They can't possibly be related.

Alan,

You are the expert, but I am confident of my bisection. A kernel built from commit 3e02320 does not have the problem, but commit adfa79d does.

The dmesg output with CONFIG_USB_DEBUG enabled is posted at
http://susepaste.org/790689.

I see. Do you happen to have CONFIG_USB_EHCI_HCD=y and CONFIG_USB_EHCI_PCI=m in your .config? If you do, try changing EHCI_PCI to y.

I see. Do you happen to have CONFIG_USB_EHCI_HCD=y and CONFIG_USB_EHCI_PCI=m in your .config? If you do, try changing EHCI_PCI to y.

Quoted 4 lines · Alan Stern

I see. Do you happen to have CONFIG_USB_EHCI_HCD=y and CONFIG_USB_EHCI_PCI=m in your .config? If you do, try changing EHCI_PCI to y.

One additional data point: When the EHCI and HCD parameters are set to y rather than m as in the list that follows, the enumerate messages do not occur.

CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
CONFIG_USB_UHCI_HCD=y

This looks like a matter of getting modules to load in the right order. Apparently your OHCI controller doesn't work right if the EHCI driver isn't present. Before the troublesome commit, this meant ehci-hcd had to be loaded before ohci-hcd. Now it means ehci-hcd and ehci-pci both have to be loaded before ohci-hcd.

In the dmesg log you provided, ehci-hcd was loaded before ohci-hcd but ehci-pci was loaded after. Of course, when everything is built into the kernel (not as modules) then questions of loading order don't arise.

You can test this hypothesis by booting a kernel without that commit and blacklisting ehci-hcd, so that it doesn't get loaded automatically. See if the errors start to come, and see if they stop when you load ehci-hcd manually.

I could not do exactly the experiment that you wanted, as ehci-hcd was loaded even though it was blacklisted. Rather than solve that problem, I generated a kernel from just before commit adfa79d with ohci-hcd built in and ehci-hcd as a module. This one generated the errors, but they stopped when ehci-hcd loaded. I also tested a 3.8-rc1 kernel with ehci-hcd and ehcd-pci built in and ohci-hcd as a module. No errors for that one. Your hypothesis looks correct.

I hope there is some way to force ehci-pci to load as soon as ehci-hcd is loaded, and before ohci-hcd loads, but if there is not, I know how to prevent the errors on my system even though this solution won't help the users of distro kernels. At least this time the errors stop once all 3 modules are loaded, and the number of error outputs is limited.

Quoted 7 lines · Larry Finger

I could not do exactly the experiment that you wanted, as ehci-hcd was loaded even though it was blacklisted. Rather than solve that problem, I generated a kernel from just before commit adfa79d with ohci-hcd built in and ehci-hcd as a module. This one generated the errors, but they stopped when ehci-hcd loaded. I also tested a 3.8-rc1 kernel with ehci-hcd and ehcd-pci built in and ohci-hcd as a module. No errors for that one. Your hypothesis looks correct.

Quoted 5 lines

I hope there is some way to force ehci-pci to load as soon as ehci-hcd is loaded, and before ohci-hcd loads, but if there is not, I know how to prevent the errors on my system even though this solution won't help the users of distro kernels. At least this time the errors stop once all 3 modules are loaded, and the number of error outputs is limited.

This is now a userspace issue. Perhaps a change to a udev rule will prevent ohci-hcd from loading until ehci-pci is in place. Or a change to a startup script in your initramfs. However the problem gets solved, there doesn't seem to be much the kernel can do about it.