You are not logged in.
I have run into problems with the xhci_hcd (USB 3.0) driver being buggy which causes the Hauppauge 950Q USB TV tuner device (xc5000 driver) to fail. I have figured out how to blacklist the xhci_hcd driver (to make matters more complex the computer is PXE booting so I need to do the blacklisting through the APPEND parameters) but the ehci_hcd driver is not loading instead. On older motherboards (the new one has an Intel Bay Trail chipset) which don't support USB 3.0 the ehci_hcd driver loads and everything works.
Offline
Load ehci-hcd explicitly.
Offline
How?
Can I do that from the APPEND when PXE booting? I added ehci_hcd there right after the modules.blacklist=xhci_hcd and it doesn't load. It is also in /etc/modules which doesn't seem to work either. I've googled it up and down and I find lots of people wanting to force USB 3.0, but nobody wanting to go the other way...
Offline
Of course /etc/modules doesn't work - what gave you the notion that it would?
Offline
Of course /etc/modules doesn't work - what gave you the notion that it would?
I'm 99% sure /etc/modules was used when arch still had an rc.conf (pre-systemd ).
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
tomk wrote:Of course /etc/modules doesn't work - what gave you the notion that it would?
I'm 99% sure /etc/modules was used when arch still had an rc.conf (pre-systemd ).
..and it probably was responsible for loading partial configuration files in /etc/modules-load.d/ or whatever directory it used.
Last edited by emeres (2014-09-05 12:27:58)
Offline
No... we used the MODULES() array in rc.conf back then.
Offline
Perhaps I should have mentioned that while I've been using Linux since 1993, I am relatively new to Arch and while I have some past experience dealing with kernel level development/debugging it was mostly in the 1980s on VAXen running BSD. The past 20 years I've mostly been doing app development but the app I am currently working on requires a few uncommon hardware devices which are currently behaving badly, thus this thread. In interests of brevity I had left most of that out.
I was able to get ehci_hcd to load instead of xhci_hcd, however the solution to my problem doesn't seem to be that simple. When the box boots ehci_hcd appears to be loaded but others I would expect to be aren't and the system is in an unusable state where the keyboard and mouse don't work, the tuner driver doesn't load, etc. I might be able to reconstruct all the modules that need to be loaded and the order that needs to be done by looking at what happens on older motherboards without USB 3.0 hardware, but at this point I'm running out of time to deal with it and I may have to pursue other avenues for solving this problem such as different motherboards, perhaps something AMD based.
I've been hoping that the xhci_hcd driver will get fixed, but it appears that the state of maintainership of the USB drivers is currently in a state of flux so I am skeptical that it will happen soon enough for my needs. It is probably also not a high priority since it appears xc5000 based devices like the Hauppauge TV tuners are the primary culprits in triggering the USB 3.0 bugs and they aren't that commonly used.
Offline
USB3 controllers aren't backwards compatible with USB2 drivers - you can only use xhci_hcd with them. Besides debugging xhci_hcd your only choice seems to be adding a PCI card with USB2 a controller.
Offline
USB3 controllers aren't backwards compatible with USB2 drivers - you can only use xhci_hcd with them. Besides debugging xhci_hcd your only choice seems to be adding a PCI card with USB2 a controller.
Wish I had known this before I spent so much time on this. Unfortunately a PCI card is not an option as the motherboards are Mini-ITX and adding more hardware to them would probably be price prohibitive for the product they are going into anyway even if there was a USB 2.0 controller that fit into the micro-PCI slots.
So bottom line at this point appears to be that any motherboard with the Bay Trail chipset is not going to work for me until if/when the xhci_hcd driver is fixed. That's a big problem because getting a few hundred at a time of the older motherboards and memory that works in them is becomming increasingly difficult. Unfortunately I can't afford to put much more time into this unless I have no alternative. Hopefully the AMD chipset motherboard I'm hoping to try next will work otherwise I'm back to square one again.
Offline