From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
ehci-hcd.o fails to load...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Boot kernel 2.4.19-0.pp.20
2.Fails to load ehci-hcd.o (even after unarchiving the .gz)
Actual Results: Nothing
Expected Results: Successful loading of this module
Found it strange that all the drivers in :
/lib/modules/2.4.19-0.pp.20/kernel/drivers/usb were all archived
can you find the PCI ID of your USB controller ?
(and the modules are compressed to save space; modutils knows how to uncompress
them on the fly when needed)
Has nothing to do with uncompressing on the fly..., since that works just fine.
Weird thing is that I see the insmod failure on kernel boot... but no where in
the system logs... peculiar
Doing an lspci bears this out:
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02)
No idea why the kernel is balking at boot and not logging this to kernel messages!
Sent Arjanv an attachment with a patch from the maintainer
Greg K-H pointed to this:
David-B said the timeout ought to be increased:
From: David Brownell
> static int ehci_reset (struct ehci_hcd *ehci)
> return handshake (&ehci->regs->command, CMD_RESET, 0, 250);
> handshake() is always returning non-zero due to ETIMEOUT, I've also tried
> increasing 250 to 2000; if I ignore the return code from ehci_reset()
> the driver loads.
But does it work afterwards? It didn't actually reset yet,
which is what the ETIMEDOUT indicates.
The EHCI 1.0 spec says (2.3.1) that bit clears itself when
the reset is done, and the only constraint on it is that
the STS_HALT bit must be set. Which is guaranteed by the
call to ehci_halt() shortly before.
That 250 is in microseconds, not milliseconds, so maybe
this hardware is just slower to reset than the other EHCI
hardware I've used. Try using "250 * 1000" instead ... your
"2000" was just two milliseconds, which still isn't much.
Requestor never indicated if he actually tested increased timeouts,
but just "sent Arjan a patch". Never attached the patch to the bug
either. But since Greg says it's known for the Intel's EHCI to have
this quirk, I'm assuming it's the timeout thing.
Created attachment 88739 [details]
The aforementioned patch
I have not tested the patch.
kernel 2.4.20-2.2 continues to show the same ehci-hcd.o load failure as
No change in the way ehci-hcd.o loads... same failure as 2.4.20-2.2
Close this bug... patch created back on Dec 15 from Brownell works on my
2.4.20-2.5 custom kernel. Perfectly