Related branches

Yes, I can confirm that this happens on the following:
kernel: 2.6.27-8-generic
release: intrepid ibex 64 bit
where the following message appears in dmesg:
Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after

And also:
kernel: 2.6.24-21-generic
release: hardy heron 32 bit

In the hardy version there is no warning, but uhci is being loaded before ehci. I don't know the details, but according to [1], this is not good. I started probing around after a USB device of mine was behaving strangely, I don't know if this is to do with ehci and uhci being loaded in the wrong order, but warnings from the kernel aren't usually a good thing.

what scott said seems to make sense, even though i don't know the internals of the kernel that well...

this warning appears in the kernel since the patch i attached above was committed into linus's kernel tree on 17.10.2008. Quoting:
"Nowadays most distributions are pretty good about not doing this; maybe the warning will help convince anyone still doing it wrong."

> The point in having ehci-hcd loaded before the other is that if either
> uhci or ohci get loaded before and a usb2.0 is present then it will
> behave as a usb1 device and be blocked by these drivers.
>
Right

And what happens if the machine only has a USB 1 hub on boot, and later
on the user plugs in a hotpluggable USB 2 hub?

With last Intrepid kernel (2.6.27-11) this problem is still there !!! (ehci 1.00 driver 10 dec 2004)
What about the possibility to use hal to deal with the right hardware: by default, first load usb2 driver (if no usb2, then only use it with new one), or switch to the good driver when necessary ?

"This patch (as1139) adds a warning to the system log whenever ehci-hcd
is loaded after ohci-hcd or uhci-hcd. Nowadays most distributions are
pretty good about not doing this; maybe the warning will help convince
anyone still doing it wrong."

@fishor: That was the solution for me. In fact it seems that udev has nothing to do with this. the problem is that there is no control over what modules are loaded and when if they are in the initram.

@scot: If you only have usb 1.0 hardware then ehci-hcd will do nothing. only when you load uhci-hcd will you have access to those deices. The point is the ehci-hcd driver does not block the uhci-hcd controlled devices. But the later drier acts on the USB 2.0 devices and prevents them from working full speed, even if you load ehci afterwards.

A lot of drivers have been being compiled into the kernel lately, to the point of the need for an initram dropping to almost nil. As a bonus i got 4 seconds less in my boot time.

> @scot: If you only have usb 1.0 hardware then ehci-hcd will do nothing.
> only when you load uhci-hcd will you have access to those deices. The
> point is the ehci-hcd driver does not block the uhci-hcd controlled
> devices. But the later drier acts on the USB 2.0 devices and prevents
> them from working full speed, even if you load ehci afterwards.
>
Exactly my point.

If you have to load ehci-hcd before uhci-hcd for the kernel to function
properly, but ehci-hcd only has MODALIAS strings for USB 2 devices, then
it's the kernel's fault that this doesn't work!

If there's a pre-order condition, then these things shouldn't even be
considered separate drivers!

uhci-hcd/ohci-hcd should depend on the ehci-hcd driver to ensure that it
is loaded first.

Alternatively they should be just compiled into one single usb-hcd
driver that figures it out for itself.

A non-modular kernel only fixes this for people who don't compile their
own.

This issue still occurs in linux-source-2.6.28-4.11 kernels (jaunty)
Thanks for the workaround, fishor. I was trying all sorts of crazy things like editing modules.dep and using modconf, but I later found out that most of my work wasn't applicable because update-modules is "deprecated".

BTW, this problem was really easy to solve on Arch Linux. I just specified echi_hcd before ohci_hcd in the MODULES= section of /etc/rc.conf
Sometimes, I wish Debian administration was a little easier.

It's even simpler than you suggest. Simply add ehci_hcd to /etc/initramfs-tools/modules without changing anything else. At least initramfs-tools 0.92o gives preference to the modules set in that file, even if the MODULES setting is left to the default of "most." That behavior is implemented in scripts/functions, if you are curious.

> It's even simpler than you suggest. Simply add ehci_hcd to /etc
> /initramfs-tools/modules without changing anything else. At least
> initramfs-tools 0.92o gives preference to the modules set in that file,
> even if the MODULES setting is left to the default of "most." That
> behavior is implemented in scripts/functions, if you are curious.
>
Unlikely to help.

The ohci_hcd driver would be loaded first if you have a USB 1.0 hub and
not a 2.0 one.

This worked like a champ for me. added the line then regenerated the initramfs, no more problems.
I've got kubuntu installed on a USB stick, so it was painfully obvious that i was in usb 1.0 mode for awhile... good to actually have transfer rates back.

At some point a few weeks/months ago I believed I was but then the issue
went away and afterwards I pretty much convinced myself I'd been
imagining a problem since USB transfers were above the USB1 12Mbps rate
even if well below what I was expecting for USB2 480Mbps transfers.

> here is the output of the modalias thing (just in case) :
> root@jaunty# for hci in /sys/bus/pci/drivers/?hci_hcd; do echo $hci; cat $hci/*/modalias; done
> /sys/bus/pci/drivers/ehci_hcd
> pci:v00008086d000027CCsv0000144Dsd0000CA00bc0Csc03i20
> /sys/bus/pci/drivers/uhci_hcd
> pci:v00008086d000027C8sv0000144Dsd0000CA00bc0Csc03i00
> pci:v00008086d000027C9sv0000144Dsd0000CA00bc0Csc03i00
> pci:v00008086d000027CAsv0000144Dsd0000CA00bc0Csc03i00
> pci:v00008086d000027CBsv0000144Dsd0000CA00bc0Csc03i00
>
For each of those aliases, could you run the command

Ok, now I've looked into it, ehci_hcd, uhci_hcd and ohci_hcd have ZERO overlap in terms of device support. There is no way that any device would result in more than one of these modules being loaded in any given modprobe invocation, so modules.order would not apply (as I said above):

This obviously doesn't count if hardware not supported by ehci-hcd is found first,
but then that would also be true of building the module into the kernel.

Since you have USB-1 hardware and USB-2 hardware, and the USB-1 hardware is being detected first, you are fundamentally suffering from the problem I described above:

* a laptop with only USB 1.0 Host Control Devices is booted

* we'll only load ohci_hcd/uhci_hcd because those are all we need

* hours/days/weeks later, the laptop owner plugs in a pccard that provides a USB 2.0 interface

* we now load the ehci_hcd driver, and get that kernel warning

So there is no way to fix this from userspace.

Given that there's no overlap between module aliases, it baffles me as to why the kernel needs an ordering requirement at all? ehci_hcd should only take over those cards with an interface of 0x20, uhci_hcd with an interface of 0x00 and ohci_hcd with an interface of 0x10.

I'm marking the userspace parts of this as Won't Fix and will ask a Kernel Developer to weigh in on the kernel side.

So, as we know, the solution is to force ehci_hcd to load and initialise a host controller and, most importantly, *claim the shared ports* before uhci_hcd.

The previous gap in our understanding of this issue is the nature of the physical ports being *shared* by the host controllers on a first come, first served basis.

If the USB drivers remain as modules then this requires the modules listed in required load-order in /etc/initramfs-tools/modules:

ehci_hcd
uhci_hcd
ohci_hcd

Alternatively, if the modules are built-in to the kernel image we need to ensure the link order is the same (fastest protocol driver first), and that support for USB3 (SuperSpeed - 5Gbps) via a xhci_hcd module doesn't get tripped up by this issue in the future.

While not a show stopper, this warning is an indication of a fairly major annoyance. If you insert a USB 1.0 peripheral, and then insert a USB 2.0 peripheral in any other port, you are likely to only get USB 1.0 transfer speeds from your USB 2.0 peripheral. This race can only be solved conclusively by always loading ehci before uhci/ohci. Many folks have forced this sequence in initramfs, but the best solution is in the kernel (as always).

I have a problem with the ehci_hcd too. The printer, HP Photosmart C4180 only works in Linux if the USb 2.0 was disabled previously in the BIOS. But the point is that this printer has a USB 2 port which allways works perfectly, and even does a good job today with other operating systems. I believe this problem is related with the ehci_hcd "thing", I can't find the module in my filesystem.

Building these modules in (rather than just fixing to have a sensible/optional dependency) means it's impossible to force a particular driver and impossible (at least AFAICWO) to blacklist for debugging.

(The solution applied so far doesn't appear to have solved the problem and is instead just another step of the road to monolithic hell).

That's right Paul. I'm having issues now too, as I have defective usb 2.0 hardware (usb 1.1 is working flawlessly via the same usb connector) so I used to unload the ehci-hcd which is not possible anymore with the latest kernel revision 2.6.28-11.40 because *hci-hcd are built-in now.
So I either have to get new hardware or recompile my kernel...

> Nikias Bassen: I've opened bug #354832 on the basis of the regression of
> the modules being non-modular and therefore certain machine being let
> with non-working USB.
>
Isn't it better to fix the bug that causes the USB to not work than
bitch about the modules being built-in?

Scott: sure, but compiling this in hasn't fixed that bug either... but has had the (negative) impact of just making it even harder to diagnose/debug with end-users.

Eg. it's no longer possible to request "Hi XYZ, could you try 'modprobe -r abcd_hci' then 'modprobe ...' and post 'find /sys -path ... | xargs grep .' " We've instead just got a massive black box that collectively "doesn't work as of -11.38" with no possibility of an interim workaround while it's investigated.

Ubuntu was about the first distribution to go fully modular and has benefited significantly from that choice. It wasn't /easy/ to do; all the hard stuff with initramfs building and module hooks was *made to work*, even though it was complex.

If boot-speed and an easy life are the only reasons to ditch that policy of modularity then it's the focus narrow-minded and not being forward looking.

Presumbly the kernel does not have a single 'usb_hci' module for a reason; but this "subtle" change has created one.

> If boot-speed and an easy life are the only reasons to ditch that policy
> of modularity then it's the focus narrow-minded and not being forward
> looking.
>
The non-modularity of the HCI drivers has nothing to do with boot speed.

> Presumbly the kernel does not have a single 'usb_hci' module for a
> reason; but this "subtle" change has created one.
>
Ah, but that's the problem! You can't treat the hcd drivers as
separate, once you load one you need to load them all and you need to
load them all in a specific order unrelated to which one you first
started with.

Building these modules into the kernel, at this extremely late stage in the Jaunty development cycle, doesn't seem like a particularly good idea. Among other things, it has implications for laptop users who are trying to minimize power consumption, and it makes life unnecessarily difficult for users of VMWare Workstation which has numerous unusual use cases of USB peripherals.

> Building these modules into the kernel, at this extremely late stage in
> the Jaunty development cycle, doesn't seem like a particularly good
> idea. Among other things, it has implications for laptop users who are
> trying to minimize power consumption, and it makes life unnecessarily
> difficult for users of VMWare Workstation which has numerous unusual use
> cases of USB peripherals.
>
Why?

Whether or not they're built in or modules, they still have to be loaded
for your USB hardware to work.

Whether or not they're built in or modules, you can still disable
individual host control interfaces - the method is just slightly
different (though since the one that works for built-ins ALSO works for
modules, we should arguably be documenting that one instead of the
blacklist trick).

This has solved the bug where ehci was loaded second, therefore the host
controller placed in the wrong mode.

On Tue, Apr 7, 2009 at 10:16 AM, Scott James Remnant
<email address hidden> wrote:
> Whether or not they're built in or modules, they still have to be loaded
> for your USB hardware to work.

True.

> Whether or not they're built in or modules, you can still disable
> individual host control interfaces - the method is just slightly
> different (though since the one that works for built-ins ALSO works for
> modules, we should arguably be documenting that one instead of the
> blacklist trick).

OK, I should research this. A laptop user can save energy by
unloading the hcd modules, which puts the corresponding PCI functions
into D3. How can you achieve the same thing with the drivers
built-in?

> > Whether or not they're built in or modules, you can still disable
> > individual host control interfaces - the method is just slightly
> > different (though since the one that works for built-ins ALSO works for
> > modules, we should arguably be documenting that one instead of the
> > blacklist trick).
>
> OK, I should research this. A laptop user can save energy by
> unloading the hcd modules, which puts the corresponding PCI functions
> into D3.
>
Actually, the same effect can be achieved by enabling autosuspend on the
USB devices (including the hub). See:

I will try in two weeks, but the point is that a lot of people have this setup ordinary USB 2.0 HP printer with ordinary Intel PC, so I think this kind of things have to work before the Jaunty will be realesed. Sorry for my lack of feedback :(.

> I will try in two weeks, but the point is that a lot of people have this
> setup ordinary USB 2.0 HP printer with ordinary Intel PC, so I think
> this kind of things have to work before the Jaunty will be realesed.
> Sorry for my lack of feedback :(.
>
And I fully expect that for just about everybody, it works normally -
it's very likely that you are the only person suffering from
difficulties.

(I myself have an HP printer with an ordinary Intel PC)

Quickly glancing through the logs you provided, I can't see any
particular sign of failure.

@Miguel
Jour problem is not related to this one, or probably indirectly. The fix
should make USB 2 to work. And how you said, your usb 2 do not work
properly. Please open a new bug and subscribe me to it. Attach your
complete dmesg to new bug.

On Tue, Apr 14, 2009 at 10:50 AM, Scott James Remnant
<email address hidden> wrote:
> On Fri, 2009-04-10 at 12:02 +0000, Miguel wrote:
>
>> And here it is my attachment with the report. My computer is just
>> upgraded right now and the problem with the printer isn't solved :(.
>>
> Did you try unbinding the USB 2.0 host? (see above)

Yes, and it seems to works, thanks a lot :). The point now is how to
do the porcess automatically for the people who hasn't said anything
and has this problem.

> On Tue, Apr 14, 2009 at 10:50 AM, Scott James Remnant
> <email address hidden> wrote:
> > On Fri, 2009-04-10 at 12:02 +0000, Miguel wrote:
> >
> >> And here it is my attachment with the report. My computer is just
> >> upgraded right now and the problem with the printer isn't solved :(.
> >>
> > Did you try unbinding the USB 2.0 host? (see above)
>
> Yes, and it seems to works, thanks a lot :). The point now is how to
> do the porcess automatically for the people who hasn't said anything
> and has this problem.
>
Since we can't detect who has the problem, we can't do anything
automatically. When people file bugs or ask for support, they can be
given the udev rule:

> On Fri, 2009-05-01 at 18:29 +0000, Miguel wrote:
>
> > On Tue, Apr 14, 2009 at 10:50 AM, Scott James Remnant
> > <email address hidden> wrote:
> > > On Fri, 2009-04-10 at 12:02 +0000, Miguel wrote:
> > >
> > >> And here it is my attachment with the report. My computer is just
> > >> upgraded right now and the problem with the printer isn't solved :(.
> > >>
> > > Did you try unbinding the USB 2.0 host? (see above)
> >
> > Yes, and it seems to works, thanks a lot :). The point now is how to
> > do the porcess automatically for the people who hasn't said anything
> > and has this problem.
> >
> Since we can't detect who has the problem, we can't do anything
> automatically. When people file bugs or ask for support, they can be
> given the udev rule:
>
> ACTION=="add", SUBSYSTEM=="pci", DRIVER=="ehci_hcd", \
> RUN+="/bin/sh -c 'echo -n %k > %S%p/driver/unbind'"
>

Yes, I have tryed this following your instructions on [1], but unfortunately
Jaunty doesn't like it, and the system is unbootable after that change. The
only way to recover the system is using a live-cd to remove the file from
/etc/udev/rules.d/ .

however this now doesn't work as there's no module to unload. so I can't use usb storage full stop.
while I have an eSATA drive, most people use usb, so this is going to get very annoying very quickly.

I've got a pci usb card (with a different chipset) but that behaves exactly the same

Hi,
I read this thread with interest. I'm a developer for Puppy Linux and today ran into this warning when I was testing the 2.6.29.6 kernel with Puppy.

I think that I have fixed it, and my solution might interest you. Our boot scripts are very Different from Debian, or any other distro for that matter, but the essential part related to getting ehci_hcd to load first will be usable by you guys.

We have a little utility named 'elspci', which is kind of like 'lspci' but very simple. It was written by one of our developers, Jesse.

* Since we are already providing workarounds for kernel shortcomings,
add to the aliases file directives to load ehci-hcd before the other
HCD drivers. (Closes: #500001)
* docbook-to-man build-dependency replaced by docbook-utils which is
less broken.
* debhelper version upgraded from 4 to 5.

@Miles - your kernel version doesn't look like an Ubuntu version. I'm guessing you have EHCI/UHCI/OHCI configured as modules whereas the Ubuntu kernel config has all of them built into the kernel in a defined order.