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.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

To prevent modules loading you can
1. put them in /etc/modprobe.d/blacklist

They still just might load, so you can also have some usb.conf in /etc/modprobe.d with lines like

Code:

install ohci_hcd /sbin/modprobe xhci_hcd

The 'install command offers an alternative action when the command to load that module comes along.

Using those two, you should be able to experiment with all the modules one by one.

I successfully blocked the modules from loading. No joy because the issue is what is in the kernel. So at this point it's not a load order, but maybe a conflict of 2 drivers trying the same devices via different controllers.

Personally, I think youŕe barking up the wrong tree. Linux is not windows, where labyrinthine errors are commonplace. Stuff generally works. The kernel works for others with your setup. I would start from square 1 and try narrow down the issue and eliminate things from suspicion. It could be hardware, cables, or plugs. Check silly stuff.

Personally, I think youŕe barking up the wrong tree. Linux is not windows, where labyrinthine errors are commonplace. Stuff generally works. The kernel works for others with your setup. I would start from square 1 and try narrow down the issue and eliminate things from suspicion. It could be hardware, cables, or plugs. Check silly stuff.

The hardware is fine.

I know this because it all works just fine in Xubuntu. The obvious thing many people would say is "just use Xubuntu". Or others may say "find out how Xubuntu does that and change Slackware to do the same". But that's just too wide open because LOTS of things are different. I want the MINIMAL change to Slackware.

I've been reading up on this and I now know that I only need the xhci driver. That is because there was a change in how USB works. Previously each new USB upgrade added a new controller just for that speed alone, and to support all the speeds, you need all the drivers. This mixed support apparently caused with device conflicts. I know I've seen it where plugging in a 1.2 device crashed all the 2.0 devices, and such. The new xhci controller takes care of ALL speeds in one controller. So only one driver (xhci) is needed ... if the xhci controller exists (it does) and manages all devices and ports (I'm not sure, but I think so).

Maybe many people are not aware of this change to USB with the xhci controller. I think it is a good change, but it certain makes for some complications when software has to deal with legacy hardware, too.

One complication is that other controllers still exist, or at least the ehci one does, on this board or chipset. I'm sure the reasoning is to support an OS that does not have xhci. But that ends up confusing things which don't understand that xhci is different USB logic than in the past. Apparently the kernel developers are either not aware, or have not fully solved this, yet. If an xhci controller is present and an xhci driver is available, or becomes available, it should bump out the uhci, ohci, and ehci drivers for all devices, unless some explicit configuration parameter says otherwise (like maybe from the boot time parameters).

In theory, it should be possible to have all the controllers (uhci, ohci, ehci, xhci) present, and it would just do the right thing. We're not there, yet.

In my case, what I am trying to get to is having ONLY the xhci driver. I want to know if xhci will work as expected.

It's been so long since I built kernels before, and my most recent doings of a few years ago were just running other people's scripts. The steps I (THINK) I remember are not working (so my memory of this is lacking). So I have to go back and find documentation on what to do.

You're still stuck in the old USB box where each different speed operates with its own controller (UHCI, OHCI, and EHCI). That's not the way it is with XHCI. Now with XHCI it's one controller for everything.

This is what made it work: I plugged the mouse into the USB 3.0 port! Later I found that every port attached to the XHCI controller works just fine. The 2 ports right under the PS/2 port ... the manuals says these MUST be used for keyboard and mouse over USB. But they apparently those ports are attached via a different controller. I don;t know why Xubuntu figures it out. I built a 3.8.11 kernel by modifying the Slackware kernel config to make the USB and HID parts match the Xubuntu but that still didn't work. Something else must be doing something to USB or HID or something. It could be other kernel config details. It could be kernel regression since 3.8.0. It could be my long time nemesis udev.

I still consider this to technically be a workaround, since all USB ports should work, and somehow Xubuntu did it. But I will mark this thread as solved so people can at least find a way to make things work.

Edit:

A little too jumpy on analyzing this. Yes, all the ports work when it works. But things still fail when the mouse is plugged in during boot up, and SOMETIMES works when moving the mouse to another port. What works more reliably is to leave the mouse UNPLUGGED during boot up. Then plug it in after everything is up. Then it seems to work just fine. But this is still on the kernel I compiled with every USB controller configured static in the kernel (e.g. =y not =m).

That's where the system looks for them. It's a BIOS or hardware thing.

What is the "the system"? It's not the Linux kernel ... how would it know this?

When the mouse is plugged in to ANY port and the system boots, the mouse will not work and many USB error messages are produced. When I plug the mouse into any other port, the mouse then works. The first time I tried this it was plugging it into a USB 3.0 port so I jumped to a conclusion that it was USB 3.0 related. Turns out the mouse works when plugged into ANY USB port. It MAY be that BIOS expects keyboard/mouse to be in the first 2 ports right under the PS/2 connector. But I've never seen BIOS use mouse for anything.

Now I need to find out a way to fake in software the effect of unplugging the mouse and plugging it back in after an appropriate amount of waiting.

If I boot up with the mouse not plugged in, I can plug it in later and all is well. The mouse can be plugged into ANY USB port and it works.

It now seems to be an issue related to startup, possibly the udev initial triggering.

What is the "the system"? It's not the Linux kernel ... how would it know this?

Either what you are telolinjg us is not true, the manual is wrong, or what I suggested, the bios or hardware looks for your mouse and keyboard in one specific pair of ports. That would explain the thread. But perhaps none of this happened at all, and certainty is just an emotion :-)).