Slackware kernels do not include the amd iommu module. This causes io-remapping to fail and many devices may be unusable. For me, usb devices (kbd/mouse/storage) and my ethernet cards were unusable (perhaps other devices that I didn't notice as well). Recompiling the kernel with CONFIG_AMD_IOMMU=y fixed this. I started with the config for the slackware generic kernel, then made my change in 'make menuconfig'.
This is meant to help others who run into a similar situtation as my own. Symptoms to watch for are usb devices being unresponsive when get started with installation. To complete the install and then get through the kernel build, I used an old ps2 keyboard I have laying around.
Hope this helps.

Cheers,
John

<edit> Also, if you follow my use of the generic kernel's config, don't forget to create an initrd, also. (`man mkinitrd` and `less /boot/README.initrd`) </edit>

Do you have in a log somewhere "EHCI_HCD should be loaded before UHCI_HCD and OHCI_HCD" ?

I did before. I initially went at the problem from that angle. I reconfigured a kernel in such a way that no uhci and ohci stuff are built directly into the kernel; all modular. After installing that kernel, I created an initrd that included the xhci, ehci, and usbhid. Still, I was getting all usb devices below a root hub failing to enumerate. Then I remembered an issue I had back when I first built this box: the iommu (which I enabled in bios setup, to get benifits for virtualization) turned out to be the culprit to woes I had then with usb and net devices. The issue then was that one of the acpi tables (the ivrs table) had the sections on the iommu imcomplete, causing the amd_iommu module to fail loading. This was a known bug that occures in some bios firmware. There is a workaround in 3.10.x kernels (if interested, see ivrs_iommo[#]= in kernel-parameters.txt in 3.10.x kernel docs). When I built this box, I had installed Debian testing, reconfigured for and upgraded to unstable. After enabling the amd_iommu module, my usb and net devices start to work properly.

Now, looking back on all this, I realize that I had made the amd_iommu config change on top of my fully modular usb changes to the 3.10.9 generic kernel config. After posting this I will go back again and build two kernels: one with amd_iommu change only and one with fully modular usb only. I will report my findings after booting with both.

Thanks for asking. Sorry for the long wind.

Cheers,
John

OK. Built two kernels, both starting with the 3.10.9-generic config. The first one I only changed the AMD_IOMMU config option to y. The second one I changed many things pertaining to usb and other buses; mainly removed any option that causes the ssb and amba buses to be built and a few platform drivers that I'm fairly sure only make sense on an embedded system -- this allowed the usb drive core to be built modular. Also created a seperate initrd for each. Both initrd's built with the following modules called for on cmd-line: ext4,xhci-hcd,ehci-hcd,ohci-hcd,usbhid. The amd_iommu one boot normally with full use of my usb keyboard, mouse, external drive encloser, thumb drives... et al, working properly. The second kernel boots the same as the packaged 3.10.9-generic: no usb devices working and network borked. My previous kernel build is a combination of the two configs, with a few additional tweaks for personal preference and works great.

The core issue I see is that if the system board has an amd iommu and it is enabled, then the amd iommu driver is necessary. Simply enabling that single driver allowed my system to boot properly.
Another issue I see is that there are options turned on in the default kernel configs that only seem to make sense on an embedded platform:

ssb bus and amba bus -- I've seen this on devices like routers, but not on a x86/x86_64 based main board.
broadcom b43 wireless drivers -- these are also often on routers and maybe other embedded devices and pull in ssb bus driver.
broadcom 440x/47xx ethernet support -- again, embedded, pulls in ssb.

I may be on the wrong track about the drivers for embedded devices, but the iommu driver is important some modern main boards (the intel iommu driver is included, why not also add the amd one).

OK, well, no big deal. Building a kernel and initrd is basic stuff, so no major loss. Except the time I spent tracking down the problem. Oh, well.

Cheers,
John

So, is this only with the Generic kernel, or does this happen with the Huge kernel also?

I have encoutered similar problems on a Gigabyte board with the 970 chipset and EFI bios.
I tried the huge kernel on slack64-14.0 install dvd and also 3.2.45 in /patches.
In the end I managed to get everything to work by enabling the iommu controller in bios and supplying the option "iommu=soft" to the kernel at boot.
I'm not sure what implications this has to performance, especially to virtualization. It would be nice if somebody knowledgeable about these things could post here what each "iommu=" option does.

P.S. I have not tried this on modern kernels, only on those stated above.

@ReaperX7:
It happens on both. For me, the heart of the issue is the amd_iommu driver, so both kernels do not work for usb and networking devices, at the very least, on my machine.
Strange that the intel iommu driver is included and not the amd iommu driver; probably an oversite.

It appears that the Intel IOMMU driver is available on IA32, but the AMD IOMMU is not. That's probably the cause of the oversight. I'll add it on the x86_64 configs.

@javogel
Have you tried "iommu=soft" on your not-working 3.10 kernel? I'm curious if it gets Usb and network working for you.

@volkerdi:
Thanks! Slackware is still great. Thanks for keeping it that way. I strayed to Debian years back, but it's nice to come back to my first distro and find that it's still as rock solid as I remember it.

@chicken76:
OK, I can see where you are going with that and will let you know it that works. To me, if it does work, it would allow me to use my current iso for rescue without digging out a ps2 keyboard. Thanks for the suggestion.

@chicken76
Very nice. Keyboard and both network cards worked fine on huge.s on my current iso. Not a fix for the long term, but means that the iso is a keeper. Something to keep in mind when someone has the same issues I did, that they might try your suggestion and add "iommu=soft" for the boot disk. Thanks.

Thanks to everyone who gave input. I appreciate your time and efforts.

1 members found this post helpful.

Pardon me for my lack of knowing this of hand but where exactly would I add the "iommu=soft" to? I had to do a similar edit when on kubuntu to grub config file to be able to have working USB 3.0 ports but I am very new to lilo and what the proper way of editing it would be? Just a little more detail if possible for someone still learning their way around Linux still please.Is it as easy as appending : iommu="soft" to the boot section of lilo.conf and then run lilo?

You would add it to lilo.conf as an append

Make sure you run lilo after you edit lilo.conf for the changes to take place.

2 members found this post helpful.

Thank you so much! Excellent news! Worked like a charm.

I had forgotten about this thread. Very cool to see someone getting help through it and the excellent advice of bassmadrigal.

Cheers