Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Ok, people have complained about this one before. The problem is that about every other boot, when linux is trying to initialize the usb-uhci controller, it hangs. Reboot, and it's fine. Reboot again, and you get the problem.
I've looked at modules.conf, no dice. I definately don't have the extra "1" on the alias line like others do. What's causing this?? Any help?? It's driving me mad!
I had my controllers backwards... ohci is the one for funky boards. the usb-uhci modules is as common as doughnuts. So is the intel USB chipset, so this is a little disconcerting. You might want to see if you can get the other usb module to load, just simple uhci. In /lib/modules/2.4.20-8/kernel/drivers/usb move the usb-uhci module and then run a depmod -a so the system will forget about it, then reboot and see if it freaks out. Hopefully RH didn't compile the usb-uhci code directly in, which I doubt they would.
It is also worth noting that a cold boot seems to solve the probem every time. For some reason, when you cold boot, it doesn't hang. I just figured this out. Maybe it gives some more insight into the problem?
The KTA board uses a VIA usb chipset, so its a vastly different problem, also I was poking around on google and finding that a lot of other people with stock usb chipsets, but inside Dell laptops were having similar issues, which makes me think that maybe its something in the Dell BIOS...
This one is getting into the realm of just being weird. Have you got a chunk of "dmesg" around the USB initialization?
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
uhci.c: USB UHCI at I/O 0xff80, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
uhci.c: USB UHCI at I/O 0xff60, IRQ 9
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: USB HID support drivers
hub.c: new USB device 00:1f.2-1, assigned address 2
input0: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb1:2.0
That however, is from a successful boot, how do I capture that from when it freezes?
Ohh... now we're getting into USB devfs, and I really know dink all about that. Hopefully on a crash boot it got logged properly to /var/log/syslog, hopefully syslogd started before modules were loaded... that would afterall only make sense, which means its a 50/50 chance of being true.
Ok, sorry it's been a few days since I promised I would post all the log stuff.
It seems that syslog doesn't start until after the problem. So it doesn't appear to log anything about the crash. Is there any way to change the startup order so it does start before the USB stuff is initialized?