warning: ehci_hcd loaded AFTER uhci_hcd and ohci_hcd

[dino99]

i've made an install of new kernel on Intrepid: 2.6.27-8-generic (32 bits)
and kernel.log have a warning about load order of ehci_hcd:

"Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after"

[zenzike (zenzike)]

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.

[1] http://bugs.archlinux.org/task/12009?project=1&order=dateopened&sort=desc

[dino99 (9d9)]

yes , it's a known issue and the kernel is suspected.
Look at bug report, a workaround is proposed, but i have not tested it yet:

http://<email address hidden>/msg570259.html

Some questions also about graphics chipsets:
https://lists.ubuntu.com/archives/kernel-bugs/2008-April/035300.html

[Dimitrios Symeonidis (azimout)]

assigning to the linux source package, though it might be udev or something similar...

i am also seeing this warning, but all the devices on my system (8.10, 32-bit, 2.6.27-8) work perfectly.

also look at this:
http://kerneltrap.org/mailarchive/git-commits-head/2008/10/18/3712134

note: ehci does usb 2.0, ohci (microsoft) and uhci (intel) do usb 1.1

[Dimitrios Symeonidis (azimout)]

on second thought, i think it's more likely to be a udev bug.

note also that, also in the upstream bug they cannot agree whether it's the kernel, udev or module-init-tools

[Scott James Remnant (Canonical) (canonical-scott)]

My opinion is that this is a kernel bug that the order matters at all.

ehci_hcd is the USB 2.0 HC driver.

ohci_hcd and uhci_hcd are the older USB 1.0 drivers.

Now imagine this scenario:

 * 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

There's no way to guarantee module ordering, because there's no way to guarantee that the USB 2.0 hardware is even connected at the point we discover USB 1.0 hardware.

I'd therefore suggest there is no way to correct this in userspace.

The kernel should not be so stupid as to require a module ordering.

And arguable, those three drivers should be built in to the kernel anyway, then it can worry about it!

[Dimitrios Symeonidis (azimout)]

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."

do you think they are wrong to ask for this?

[Luis Silva (lacsilva)]

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.

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-01-15 at 21:13 +0000, Luis Silva wrote:

> 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?

Scott
--
Scott James Remnant
<email address hidden>

[dino99 (9d9)]

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 ?

[Oleksij Rempel (olerem)]

"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."

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9beeee6584b9aa4f9192055512411484a2a624df;hp=2b70f07343389cb474235def00b021a645ede916

[Oleksij Rempel (olerem)]

You can use small work around:

1. sudo vi /etc/initramfs-tools/initramfs.conf
change MODULES=list
2. sudo lsmod | sed 's/\([[:graph:]]*\).*/\1/' >>
/etc/initramfs-tools/modules
3. sudo vi /etc/initramfs-tools/modules
remove "Module", move ehci_hcd to the first place
4. sudo update-initramfs -u

instead of complete modules list you can add only one: "ehci_hcd"

[Luis Silva (lacsilva)]

@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.

[Scott James Remnant (Canonical) (canonical-scott)]

On Sat, 2009-01-17 at 19:03 +0000, Luis Silva wrote:

> @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.

Scott
--
Scott James Remnant
<email address hidden>

[Daniel Letzeisen (dtl131)]

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.

[Javier Kohen (jkohen)]

@fishor

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.

[Scott James Remnant (Canonical) (canonical-scott)]

On Sun, 2009-02-15 at 14:25 +0000, Javier Kohen wrote:

> 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.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

New module-init-tools, combined with new kernel, will load modules in the order specified by the installed modules.order file - ehci-hcd is listed before ohci-hcd and uhci-hcd so will be used first.

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.

[Florent (florent.x)]

Still problem with Jaunty, kernel 2.6.28-9.29

module-init-tools 3.7~pre7-3

[Alessandro Ghersi (alessandro-ghersi)]

This bug is present in Jaunty with 2.6.28-9-generic kernel

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-03-13 at 05:23 +0000, Alessandro Ghersi wrote:

> This bug is present in Jaunty with 2.6.28-9-generic kernel
>
Please attach your /lib/modules/2.6.28-9-generic/modules.order file.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-03-13 at 12:49 +0000, Florent Xicluna wrote:

> ** Attachment added: "/lib/modules/2.6.28-9-generic/modules.order"
> http://launchpadlibrarian.net/23822802/modules.order
>
This states:

  1102 kernel/drivers/usb/host/whci/whci-hcd.ko
  1103 kernel/drivers/usb/host/ehci-hcd.ko
  1105 kernel/drivers/usb/host/ohci-hcd.ko
  1106 kernel/drivers/usb/host/uhci-hcd.ko

So ehci-hcd should be loaded before the other two.

Could you provide the output of the following three commands:

  cat /sys/bus/pci/ehci_hcd/*/modalias
  cat /sys/bus/pci/uhci_hcd/*/modalias
  cat /sys/bus/pci/ohci_hcd/*/modalias

Scott
--
Scott James Remnant
<email address hidden>

[Florent (florent.x)]

No modalias found: "No such file or directory"

Is it possible that the error occurs at the "initramfs" stage?
I am not convinced that initramfs take care of modules.order...

How I can check this point?

[Andrew M. (ender-neo)]

> It's even simpler than you suggest.
> Simply add ehci_hcd to /etc/initramfs-tools/modules
> without changing anything else.

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.

[Dimitrios Symeonidis (azimout)]

it's very possible that the source of the warning is the initramfs, because I think that I stopped getting it when I set MODULES=dep in /etc/initramfs-tools/initramfs.conf

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.92bubuntu25

---------------
initramfs-tools (0.92bubuntu25) jaunty; urgency=low

  * mkinitramfs: include the modules.order file. LP: #296710.

 -- Scott James Remnant <email address hidden> Fri, 13 Mar 2009 16:11:49 +0000

[RuiDC (ruidc)]

even with initramfs-tools (0.92bubuntu25) installed and running up-to-date jaunty with 2.6.28-9-generic x86_64, and after running:

sudo dpkg-reconfigure linux-image-2.6.28-9-generic

the order of the usb modules in modules.order is still not being respected and i am still getting the error.

Is there any other action i need to take to apply the fix?

[Aurius Bendikas Chang (aurius-bendikas)]

Sorry to inform but initramfs-tools - 0.92bubuntu25 does not fixed this problem. I am still getting this warning and USB misbehaves.

I am running linux-image-2.6.28-9-generic 2.6.28-9.31 (latest). Can we look at this issue again?

[TJ (tj)]

Florent:

The modalias reporting command was missing 'drivers/'. Here's an alternative and an example of the output to expect:

for hci in /sys/bus/pci/drivers/?hci_hcd; do echo $hci; cat $hci/*/modalias; done

/sys/bus/pci/drivers/ehci_hcd
pci:v00008086d000027CCsv0000104Dsd000081EFbc0Csc03i20
/sys/bus/pci/drivers/uhci_hcd
pci:v00008086d000027C8sv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027C9sv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027CAsv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027CBsv0000104Dsd000081EFbc0Csc03i00

[Scott James Remnant (Canonical) (canonical-scott)]

On Sat, 2009-03-14 at 17:13 +0000, TJ wrote:

> The modalias reporting command was missing 'drivers/'. Here's an
> alternative and an example of the output to expect:
>
> for hci in /sys/bus/pci/drivers/?hci_hcd; do echo $hci; cat
> $hci/*/modalias; done
>
> /sys/bus/pci/drivers/ehci_hcd
> pci:v00008086d000027CCsv0000104Dsd000081EFbc0Csc03i20
> /sys/bus/pci/drivers/uhci_hcd
> pci:v00008086d000027C8sv0000104Dsd000081EFbc0Csc03i00
> pci:v00008086d000027C9sv0000104Dsd000081EFbc0Csc03i00
> pci:v00008086d000027CAsv0000104Dsd000081EFbc0Csc03i00
> pci:v00008086d000027CBsv0000104Dsd000081EFbc0Csc03i00
>
Are you affected by this bug?

Scott
--
Scott James Remnant
<email address hidden>

[TJ (tj)]

On Mon, 2009-03-16 at 16:38 +0000, Scott James Remnant wrote:

> Are you affected by this bug?

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.

[Florent (florent.x)]

Scott,

I still have the problem in "initramfs" (like reported by Aurius).
  module-init-tools 3.7~pre9-1
  initramfs-tools 0.92bubuntu25

The workaround "add ehci_hcd to /etc/initramfs-tools/modules" provided by Javier works for me.

The workaround "MODULES=dep" provided by Dimitrio DOES NOT work for me.

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

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-03-16 at 17:02 +0000, Florent Xicluna wrote:

> 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

  sudo modprobe -n -v --first-time ALIAS

And provide the output (including the command you ran)

Thanks,

Scott
--
Scott James Remnant
<email address hidden>

[Florent (florent.x)]

florent@jaunty:~$ for chr in 8 9 A B; do als=pci:v00008086d000027C${chr}sv0000144Dsd0000CA00bc0Csc03i00; echo $als; sudo modprobe -n -v --first-time $als; done
pci:v00008086d000027C8sv0000144Dsd0000CA00bc0Csc03i00
FATAL: Module uhci_hcd already in kernel.
pci:v00008086d000027C9sv0000144Dsd0000CA00bc0Csc03i00
FATAL: Module uhci_hcd already in kernel.
pci:v00008086d000027CAsv0000144Dsd0000CA00bc0Csc03i00
FATAL: Module uhci_hcd already in kernel.
pci:v00008086d000027CBsv0000144Dsd0000CA00bc0Csc03i00
FATAL: Module uhci_hcd already in kernel.

florent@jaunty:~$ als=pci:v00008086d000027CCsv0000144Dsd0000CA00bc0Csc03i20; echo $als; sudo modprobe -n -v --first-time $als
pci:v00008086d000027CCsv0000144Dsd0000CA00bc0Csc03i20
FATAL: Module ehci_hcd already in kernel.

[Florent (florent.x)]

Note: the symptom is exactly what is reported by dino99 on the initial bug report:

florent@jaunty:~$ dmesg | grep Warn
[ 10.564129] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after

But I do not diagnose any other problem with USB.

[Scott James Remnant (Canonical) (canonical-scott)]

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.

[TJ (tj)]

Adding information here for the ongoing debug session with Keybuk and rtg on IRC, for the following system:

Sony Viao VGN-FE41Z

lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
00:01.0 PCI bridge [0604]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port [8086:27a1] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 02)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 [8086:27d2] (rev 02)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 [8086:27d4] (rev 02)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 [8086:27d6] (rev 02)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 02)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 02)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 02)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 02)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02)
00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 02)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 02)
01:00.0 VGA compatible controller [0300]: nVidia Corporation G70 [GeForce Go 7600] [10de:0398] (rev a1)
06:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
0a:03.0 CardBus bridge [0607]: Texas Instruments PCIxx12 Cardbus Controller [104c:8039]
0a:03.1 FireWire (IEEE 1394) [0c00]: Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller [104c:803a]
0a:03.2 Mass storage controller [0180]: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) [104c:803b]
0a:08.0 Ethernet controller [0200]: Intel Corporation PRO/100 VE Network Connection [8086:1092] (rev 02)

== Using initramfs module load order to insert ehci_hcd first ==

for hci in /sys/bus/pci/drivers/?hci_hcd; do echo $hci; cat $hci/*/modalias; done
/sys/bus/pci/drivers/ehci_hcd
pci:v00008086d000027CCsv0000104Dsd000081EFbc0Csc03i20
/sys/bus/pci/drivers/uhci_hcd
pci:v00008086d000027C8sv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027C9sv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027CAsv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027CBsv0000104Dsd000081EFbc0Csc03i00

[TJ (tj)]

dmesg log exhibiting warning message.

for hci in /sys/bus/pci/drivers/?hci_hcd; do echo $hci; cat $hci/*/modalias; done
/sys/bus/pci/drivers/ehci_hcd
pci:v00008086d000027CCsv0000104Dsd000081EFbc0Csc03i20
/sys/bus/pci/drivers/uhci_hcd
pci:v00008086d000027C8sv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027C9sv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027CAsv0000104Dsd000081EFbc0Csc03i00
pci:v00008086d000027CBsv0000104Dsd000081EFbc0Csc03i00

[TJ (tj)]

The laptop has three external-facing USB ports on the right side; number them from back to front 1 2 3. Attached an external USB hard drive to port 1:

kernel: [ 393.808054] usb 5-3: new high speed USB device using ehci_hcd and address 6
kernel: [ 393.941436] usb 5-3: configuration #1 chosen from 1 choice
kernel: [ 393.956290] scsi6 : SCSI emulation for USB Mass Storage devices
kernel: [ 393.958125] usb-storage: device found at 6
kernel: [ 393.958130] usb-storage: waiting for device to settle before scanning
kernel: [ 398.956266] usb-storage: device scan complete
kernel: [ 398.956729] scsi 6:0:0:0: Direct-Access FUJITSU MHV2200BT PQ: 0 ANSI: 2 CCS
kernel: [ 398.959619] sd 6:0:0:0: [sdc] 390721968 512-byte hardware sectors: (200 GB/186 GiB)
kernel: [ 398.962271] sd 6:0:0:0: [sdc] Write Protect is off
kernel: [ 398.962277] sd 6:0:0:0: [sdc] Mode Sense: 34 00 00 00
kernel: [ 398.962281] sd 6:0:0:0: [sdc] Assuming drive cache: write through
kernel: [ 398.971071] sd 6:0:0:0: [sdc] 390721968 512-byte hardware sectors: (200 GB/186 GiB)
kernel: [ 398.973723] sd 6:0:0:0: [sdc] Write Protect is off
kernel: [ 398.973729] sd 6:0:0:0: [sdc] Mode Sense: 34 00 00 00
kernel: [ 398.973733] sd 6:0:0:0: [sdc] Assuming drive cache: write through
kernel: [ 398.973741] sdc: sdc1 sdc2 sdc3 sdc4
kernel: [ 399.082519] sd 6:0:0:0: [sdc] Attached SCSI disk
kernel: [ 399.082633] sd 6:0:0:0: Attached scsi generic sg3 type 0

sudo dd if=/dev/sdc1 of=/dev/null
497952+0 records in
497952+0 records out
254951424 bytes (255 MB) copied, 8.74248 s, 29.2 MB/s

[TJ (tj)]

Test without ehci_hcd. ehci_hcd was blacklisted and didn't load:

lsmod | grep hci
ohci1394 42036 0
ieee1394 108416 1 ohci1394
uhci_hcd 34464 0

/var/log/kern.log:

kernel: [ 365.076048] usb 2-1: new full speed USB device using uhci_hcd and address 3
kernel: [ 365.250610] usb 2-1: configuration #1 chosen from 1 choice
kernel: [ 365.262339] scsi7 : SCSI emulation for USB Mass Storage devices
kernel: [ 365.263052] usb-storage: device found at 3
kernel: [ 365.263056] usb-storage: waiting for device to settle before scanning
kernel: [ 370.262211] usb-storage: device scan complete
kernel: [ 370.266143] scsi 7:0:0:0: Direct-Access FUJITSU MHV2200BT PQ: 0 ANSI: 2 CCS
kernel: [ 370.277212] sd 7:0:0:0: [sdb] 390721968 512-byte hardware sectors: (200 GB/186 GiB)
kernel: [ 370.285207] sd 7:0:0:0: [sdb] Write Protect is off
kernel: [ 370.285213] sd 7:0:0:0: [sdb] Mode Sense: 34 00 00 00
kernel: [ 370.285218] sd 7:0:0:0: [sdb] Assuming drive cache: write through
kernel: [ 370.290101] sd 7:0:0:0: [sdb] 390721968 512-byte hardware sectors: (200 GB/186 GiB)
kernel: [ 370.295097] sd 7:0:0:0: [sdb] Write Protect is off
kernel: [ 370.295102] sd 7:0:0:0: [sdb] Mode Sense: 34 00 00 00
kernel: [ 370.295106] sd 7:0:0:0: [sdb] Assuming drive cache: write through
kernel: [ 370.295113] sdb: sdb1 sdb2 sdb3 sdb4
kernel: [ 370.408427] sd 7:0:0:0: [sdb] Attached SCSI disk
kernel: [ 370.408537] sd 7:0:0:0: Attached scsi generic sg2 type 0
kernel: [ 372.133199] kjournald starting. Commit interval 5 seconds
kernel: [ 372.133218] EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
kernel: [ 372.136649] EXT3 FS on sdb1, internal journal
kernel: [ 372.136657] EXT3-fs: mounted filesystem with ordered data mode.

sudo dd if=/dev/sdb1 of=/dev/null
497952+0 records in
497952+0 records out
254951424 bytes (255 MB) copied, 245.269 s, 1.0 MB/s

readlink /sys/block/sdb
../devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/host7/target7:0:0/7:0:0:0/block/sdb

[TJ (tj)]

Without ehci_hcd

[TJ (tj)]

Without rebooting I disconnected the external USB device, unloaded the USB modules then loaded ehci_hcd first:

sudo modprobe -r uhci_hcd
sudo modprobe -r ohci_hcd

sudo modprobe ehci_hcd
sudo modprobe uhci_hcd
sudo modprobe ohci_hcd

readlink /sys/block/sdb
../devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0/host8/target8:0:0/8:0:0:0/block/sdb

Now rinse and repeat with a different load order:

sudo modprobe -r ohci_hcd
sudo modprobe -r uhci_hcd
sudo modprobe -r ehci_hcd
sudo modprobe uhci_hcd
sudo modprobe ohci_hcd
sudo modprobe ehci_hcd
readlink /sys/block/sdb
../devices/pci0000:00/0000:00:1d.7/usb5/5-3/5-3:1.0/host12/target12:0:0/12:0:0:0/block/sdb

[TJ (tj)]

So, as described on IRC #ubuntu-kernel by mjg59, the issue is USB host controllers sharing physical ports.

In this test-case the PC has 4x USB 1.1 host controllers and 1x USB2 host controller.

The three physical external USB ports are connected such that the USB2 host controller and one of the USB1.1 controllers can access and claim them.

The test-case used port 1 (the rear-most port). If ehci_hcd (USB2) starts first it claims the port via:

/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0/host8/target8:0:0

If uhci_hcd (USB1.1) starts first it claims the port via:

/sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/host7/target7:0:0

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.

[TJ (tj)]

Something to be aware of: It looks as if once a port has been claimed after power-up it will always be associated with the host controller that claimed it until the system does a cold boot.

[Tim Gardner (timg-tpi)]

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=462941e9684b5f55b13617e726c54ade0495465a

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).

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.28-10.33

---------------
linux (2.6.28-10.33) jaunty; urgency=low

  [ Scott James Remnant ]

  * SAUCE: nbd: Change default partitions per device to 15
    - LP: #342563

  [ Tejun Heo ]

  * SAUCE: libata: make sure port is thawed when skipping resets
    - LP: #269652

  [ Tim Gardner ]

  * Revert "SAUCE: Auto-load esp module when device opened."
    This driver performs unsafe ISA probes (according to Alan Cox).
  * Enable CONFIG_USB_GADGET_DUMMY_HCD
    This facilitates gadget slave endpoints in virtual environments.
  * Build ehci, uhci, and ohci into the i386/amd64 kernels
    - LP: #296710

  [ Upstream Kernel Changes ]

  * Add "thumbee" to the hwcap_str array
    - LP: #343602
  * Add HWCAP_NEON to the ARM hwcap.h file
    - LP: #343602
  * x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs
    - LP: #292619

 -- Tim Gardner <email address hidden> Mon, 16 Mar 2009 08:19:53 -0600

[Bremm (bremm)]

This bug wasn't fixed yet in 2.6.28-2-rt

$ dmesg | grep _hcd
[ 4.395576] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 4.395977] ohci_hcd 0000:00:02.0: PCI INT A -> Link[APCF] -> GSI 22 (level, low) -> IRQ 22
[ 4.395999] ohci_hcd 0000:00:02.0: setting latency timer to 64
[ 4.396023] ohci_hcd 0000:00:02.0: OHCI Host Controller
[ 4.396119] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
[ 4.398042] ohci_hcd 0000:00:02.0: irq 22, io mem 0xc6003000
[ 4.405023] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 4.405028] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after
[ 4.452311] ehci_hcd 0000:00:02.1: PCI INT B -> Link[APCL] -> GSI 21 (level, low) -> IRQ 21
[ 4.452369] ehci_hcd 0000:00:02.1: setting latency timer to 64
[ 4.452371] ehci_hcd 0000:00:02.1: EHCI Host Controller
[ 4.452468] ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
[ 4.452496] ehci_hcd 0000:00:02.1: debug port 1
[ 4.452499] ehci_hcd 0000:00:02.1: cache line size of 64 is not supported
[ 4.464236] ehci_hcd 0000:00:02.1: irq 21, io mem 0xfeb00000
[ 4.470024] ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00
[ 5.085025] usb 1-2: new low speed USB device using ohci_hcd and address 2
[ 5.701031] usb 1-7: new full speed USB device using ohci_hcd and address 3
[ 6.203053] usb 1-7.1: new low speed USB device using ohci_hcd and address 4
[ 6.407047] usb 1-7.4: new low speed USB device using ohci_hcd and address 5

[Aurius Bendikas Chang (aurius-bendikas)]

Received the latest updates. Works like a charm. Thank you very much.

[Miguel (miguel-glug)]

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.

Some data:
Kernel: 2.6.28-11

~$ dmesg | tail -20
[ 704.637705] usb-storage: waiting for device to settle before scanning
[ 709.636166] usb-storage: device scan complete
[ 709.752010] usb 1-6: reset high speed USB device using ehci_hcd and address 11
[ 709.884766] usb 1-6: device firmware changed
[ 709.884806] usb 1-6: USB disconnect, address 11
[ 710.000016] usb 1-6: new high speed USB device using ehci_hcd and address 12
[ 710.132649] usb 1-6: device descriptor read/all, error -71
[ 710.248020] usb 1-6: new high speed USB device using ehci_hcd and address 13
[ 710.381408] usb 1-6: string descriptor 0 read error: -71
[ 710.383417] usb 1-6: configuration #1 chosen from 1 choice
[ 710.383531] usb 1-6: can't set config #1, error -32
[ 727.721339] usb 1-3: USB disconnect, address 5
[ 730.581426] usb 1-6: USB disconnect, address 13
[ 1909.996010] usb 1-6: new high speed USB device using ehci_hcd and address 14
[ 1910.128809] usb 1-6: unable to read config index 0 descriptor/start: -71
[ 1910.128812] usb 1-6: chopping to 0 config(s)
[ 1910.129307] usb 1-6: string descriptor 0 read error: -71
[ 1910.129807] usb 1-6: string descriptor 0 read error: -71
[ 1910.130307] usb 1-6: string descriptor 0 read error: -71
[ 1910.130556] usb 1-6: no configuration chosen from 0 choices

~$ lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 10)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[TJ (tj)]

Miguel, you'll need to provide more information.

1. Are any USB devices connected during power-up?
2. Create a series of reports:

sudo -i
mkdir /tmp/report
uname -a >/tmp/report/system.log
lsb_release -a >>/tmp/report/system.log
lspci -vvnn >/tmp/report/lspci-vvnn.log
lsub -v >/tmp/report/lsusb-v.log
dmidecode >/tmp/report/dmidecode.log
exit

3. Create a single archive containing the reports and attach it to this bug

tar -czf /tmp/report.logs.tar.gz /tmp/report/* /var/log/dmesg /var/log/kern.log

[Miguel (miguel-glug)]

There weren't any usb devices conected. Sorry, but I am far away from that computer for two weeks. If the error is there by that time, I will send you these files when I come back.

Thank you very much for your guide.

[Paul Sladen (sladen)]

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).

Have we got a better approach than this sledgehammer?

[Nikias Bassen (nikias)]

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...

[Paul Sladen (sladen)]

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.

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-04-03 at 22:52 +0000, Paul Sladen wrote:

> 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
--
Scott James Remnant
<email address hidden>

[Paul Sladen (sladen)]

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.

[Scott James Remnant (Canonical) (canonical-scott)]

On Sat, 2009-04-04 at 11:45 +0000, Paul Sladen wrote:

> 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.

This is why they're built in.

Scott
--
Scott James Remnant
<email address hidden>

[Jeffrey Baker (jwbaker)]

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.

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-04-07 at 03:36 +0000, Jeffrey Baker wrote:

> 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.

Scott
--
Scott James Remnant
<email address hidden>

[Jeffrey Baker (jwbaker)]

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?

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-04-07 at 18:02 +0000, Jeffrey Baker wrote:

> > 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:

http://www.lesswatts.org/projects/devices-power-management/usb.php

This is the kind of thing we can't turn on just before release, but I
suspect that's a good target for Karmic.

> How can you achieve the same thing with the drivers
> built-in?
>
You can disable the host controller itself by unbinding it from the
driver, for example:

# cd /sys/bus/pci/drivers/ehci_hcd
# ls
0000:00:1d.7 bind module new_id uevent unbind
# echo -n 0000:00:1d.7 > unbind
# ls
bind module new_id uevent unbind

Scott
--
Scott James Remnant
<email address hidden>

[Miguel (miguel-glug)]

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 :(.

[Scott James Remnant (Canonical) (canonical-scott)]

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)

Scott
--
Scott James Remnant
<email address hidden>

[Miguel (miguel-glug)]

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 :(.

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-04-14 at 10:31 +0000, Miguel wrote:

> 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.

Apr 5 14:41 & 14:43 shows your printer being registered normally via
uhci_hcd

The fact that it's being registered via uhci_hcd strongly suggests that
this is *not* a USB 2.0 printer. The HP website lacks any technical
documents, so it's hard to say for sure.

(It's possible that the printer comes up as USB 1.0 and requires
firmware to allow it to use USB 2.0 - have you configured this?)

Scott
--
Scott James Remnant
<email address hidden>

[Oleksij Rempel (olerem)]

@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.

[Oleksij Rempel (olerem)]

i found a working dmesg of printer you have. Now i can see what you
posted only part with broken storage. So the question, printer or build
in card reader is broken for you?

[Abraham Smith (adsmith)]

Incidentally, he's not the only one. I have having an identical problem with ehci/uhci mis-detection between a ThinkPad X61s and a Sansa Vuze mp3 player.

In hardy & intrepid, I could blacklist uhci_hcd. Obviously, this is not possible with the new Jaunty kernel.

unbinding all devices under uhci_hcd appears to disable usb mass storage detection all together.

[Miguel (miguel-glug)]

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.

Thanks, Miguel.

> Scott
> --
> Scott James Remnant
> <email address hidden>
>
> --
> warning: ehci_hcd loaded AFTER uhci_hcd and ohci_hcd
> https://bugs.launchpad.net/bugs/296710
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Scott James Remnant (Canonical) (canonical-scott)]

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'"

Scott
--
Scott James Remnant
<email address hidden>

[Miguel (miguel-glug)]

On Tue, May 5, 2009 at 12:27 PM, Scott James Remnant <email address hidden>wrote:

> 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/ .

Miguel.

[1]
http://www.linux-archive.org/ubuntu-kernel-team/276583-linux-image-2-6-28-11-generic-modularity.html

> Scott
> --
> Scott James Remnant
> <email address hidden>
>
> --
> warning: ehci_hcd loaded AFTER uhci_hcd and ohci_hcd
> https://bugs.launchpad.net/bugs/296710
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[x1um1n (x1um1n)]

Hi Guys,
is there a kernel I can install which doesn't have these modules compiled in?
I know I can compile my own kernel, but that kinda defeats the object of running ubuntu

my usb2's been broken since intrepid, i've had to unload ehci_hcd and deal with usb1 speeds (and use eSATA for big stuff)

see this linky for details/logs etc:
http://www.linuxquestions.org/questions/linux-hardware-18/cant-get-ehcihcd-to-map-usb2-hdd-with-nforce4-chipset-715835/

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

Please tell me there's a solution, it's 2009 I NEED usb..

[dino99 (9d9)]

hi all,

problem fixed for me.
Thanks

[wayward4now (wayward4now)]

dino99, what worked?? Thanx! Ric

[Barry Kauler (bkauler-gmail)]

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.

It is just a matter of testing for certain PCI ID number:

ELSPCI="`elspci -l`" #jesses great little utility.
[ "`echo "$ELSPCI" | grep '0C0320'`" != "" ] && modprobe ehci-hcd

That covers all cases where ehci-hcd is needed, I think.

Put that somewhere in a boot script before the rest of the module loading, and you're right.

The source for elspci is at my source repo, puppylinux.com/sources, but I've attached a static binary.

My recent relevant blog post:
http://puppylinux.com/blog/?viewDetailed=00946

I'm posting this as an extra item of interest. It seems though that other solution(s) is/have been worked out.

Regards,
Barry Kauler
puppylinux.com/blog

[Artur Rona (ari-tczew)]

 module-init-tools (3.7-pre9-1) unstable; urgency=medium

   * 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.

 -- Marco d'Itri <email address hidden> Fri, 13 Mar 2009 00:42:17 +0100

[Miles Lane (miles-lane)]

I am seeing this still:

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after

Kernel 2.6.33-rc3-git3
udev 149-5
module-init-tools 3.11.1-1
Distro Ubuntu Lucid 10.04.

[Tim Gardner (timg-tpi)]

@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.