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.

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.

edit: found documentation

edit: Slackware64-current is now at kernel 3.8.11. You can get the ISO I built of it at http://slackware.slashusr.com/isos/s...t-20130506.iso

So tell me, what others does this kernel work for who have the xhci controller?

ehci & ohci/uhci are established modules with a good track record where everything worka. ehci tells uhci to go play in the traffic when usb-2.0 is around.

Load the fastest usb module first - thatś the key rule. Everyone and his aunt has some module in the kernel by this stage, so itś one massive mess. A simple guide to building is here
http://www.linuxfromscratch.org/lfs/...08/kernel.html

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.

http://en.wikipedia.org/wiki/EXtensi...for_all_speeds

I wouldn't say I'm stuck there. I know they exist.

They what? If your USB has XHCI, then that's all you need.

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.

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 :-)).