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): How reproducible: Always Steps to Reproduce: 1.Boot kernel 2.4.19-0.pp.20 2.Fails to load ehci-hcd.o (even after unarchiving the .gz) 3. Actual Results: Nothing Expected Results: Successful loading of this module Additional info: 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: http://marc.theaimsgroup.com/?t=103987314600003&r=1&w=2 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 2.4.20-0.pp.7
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