Why is USB not working in Linux when it works in UEFI/BIOS?

Question

For background I have just built a new machine with modern hardware including:

• AMD FX-8350
• Gigabyte GA-990FXA-UD3 motherboard
• 16GB RAM
• NVidia GTX 650 Ti
• Kingston SSD

Given that, I tried to install various versions of Linux on the SSD and was met with failure almost every time. I tried installing Arch, Debian stable, Debian sid, and Ubuntu 12.10 from a USB thumb drive but while the BIOS saw the USB drive and started to boot from it, as soon as the OS attempted to enumerate the USB devices I lost all USB functionality (including the boot device).

Eventually I burned a DVD and installed Ubuntu 12.10 onto the SSD. It should be noted that my USB keyboard (and mouse) work fine while in the American Megatrends UEFI/BIOS. Even when I'm in the pre-installation menus on the Live Ubuntu DVD the keyboard works fine.

As soon as Linux is booted (either Live DVD or from the SSD) I lose all USB functionality and can only navigate the OS using a PS/2 keyboard.

What I see in the dmesg/syslog is a few lines about "failed to load microcode amd_ucode/microcode_amd_fam15h.bin" and I can see USB devices failing to initialize.

If I do an lsusb I can see all the USB host controllers but none of the devices. Doing an lspci shows me all the hardware I'd expect. And doing an lsmod I do not see any usb modules loaded (usb_ehci for example).

I tried passing noapic to the kernel boot string and it had no effect on this problem.

The motherboard supports USB 3.0 but all the devices I have plugged into normal USB 2.0 ports.

I'm rather baffled at what could be killing/preventing USB (and my on-board network card) from working in Linux. There doesn't seem to be any problem with any of these devices working in BIOS and I do not have a Windows installation available to test and see if it works.

I've already RMA'd the motherboard once but the second one has exactly the same behavior so I think I can safely rule out hardware failure (since the behavior is identical, I don't think the odd of me getting two identically defective boards are greater than the odds of this being a Linux problem).

What else can I try to get USB (and ideally my network, but we'll stick to USB for now) working?

Edit #1:

Since I have no networking I can only relate interesting bits from dmesg here.

Of interest in dmesg I can see I have 11 USB host controllers (OHCI, EHCI, and xHCI). It detects my USB devices and then fails immediately as follows:

usb 3-1: new high-speed USB device number 2 using ehci_hcd
usb 3-1: device descriptor read/64, error -32

That repeats several times incrementing the number and trying other USB Host controllers until it falls back to OHCI controllers which also fail but have an additional message:

usb 8-1: device not accepting address 4, error -32

I think my networking problems have to do with the fact that I don't have IPv6 enabled on my router and that seems to be a problem

eth1: no IPv6 routers present

Edit #2:

lspci -vvv shows that my network adapters (both onboard and expansion) are Realtek Semiconductor (no surprise); RTL8111/8168B and RTL8169/8110 respectively. My USB controllers are Etron Technology EJ168 (xHCI) and AMD nee ATI SB7x0/SB8x0/SB9x0 (EHCI & OHCI)

Now running Debian wheezy modprobe shows usb_common, usbcore, xhci_hcd, ehci_hcd, and ohci_hcd all loaded and functioning.

Solution 1

I found the answer from this thread (http://ubuntuforums.org/showthread.php?t=2114055) over at ubuntuforums.org.

It seems with newer Gigabyte mainboards (at least) there is a BIOS option called IOMMU Controller that is disabled by default and gives no clue or indication as to what it is for.

Enabling this setting and rebooting "magically" restores all my USB and networking problems in a 64-bit Linux OS (doesn't matter which one).

I am rather shocked and elated that it was such a long search for such a simple fix.

Thanks everyone for your help and suggestions. Hopefully others will find this helpful.

Update: I'd just like to add that my current BIOS settings also include enabling XHCI Handoff and EHCI Handoff in addition to IOMMU Controller. Others have mentioned this as well and enabling those two handoffs also allows my USB 3.0 ports to function as expected.

Solution 2

I just learned, with my GA-990FXA-UD7, that for both the USB 2.0 and USB 3.0 controllers and the onboard Ethernet controller to function properly in Linux (I'm using Mint 17.1) it required the following settings in the BIOS:

• xHCI handoff - Enabled
• EHCI handoff - Enabled
• IOMMU controller - Enabled

Don't forget to disable UEFI and change all boot options to "Legacy Only".

If you really need to boot from a HDD of >2.2TB capacity, you might have a different problem on your hands.

I'm using a 256GB SSD for my boot drive and a pair of 3TB HDDs in a RAID 1 (mirrored) array using mdadm for my /home and all is working well.

Having worked with Gigabyte boards quite a lot, I know the 990FXA-UD5 and 990FXA-UD3 boards have very similar BIOS, so it is likely the same will apply with those boards as well.

Solution 3

Oddly enough, even though I have an almost identical setup (same motherboard, FX8350 processor), enabling the IOMMU didn't make any difference for me. Still no USB, networking, etc.

What did help, though, was adding "iommu=soft" to the kernel command line. Now it all works fine (except that, for some strange reason, my Logitech Zone Touch Mouse doesn't work).

Solution 4

FYI, the technical reasons why Linux can't use devices "through" the BIOS: once the OS has transitioned to "protected mode" (32-bit) or "long mode" (64-bit), it can no longer send interrupts to the BIOS. In "real mode" (16-bit, at boot) it can call BIOS interrupts to have disks read, keyboard input, etc.

But it's also got downsides. For one, you don't even have a megabyte of addressable memory. So modern OS's switch out of real mode nearly first thing. (Actually, I believe grub switches to protected mode before it even loads the kernel).

More details: http://wiki.osdev.org/Real_Mode http://wiki.osdev.org/Protected_Mode

Solution 5

These steps worked for me with a GIGABYTE 970A-DS3P and AMD-FX-8320 running Ubuntu 15.04

• xHCI handoff - Enabled
• EHCI handoff - Enabled
• IOMMU controller - Enabled
• UEFI - Disabled
• All boot options - Legacy Only

View more solutions

Comments

[Admin]

The failure of loading microcode seems peculiar. I'm thinking about the motherboard not being supported yet or missing microcode package.

[Admin]

It seems like that issue may be able to go away (butterflyofdream.wordpress.com/2012/09/10/…) as this CPU has been out for a while and there are packages that update the microcode. However, I'm wondering how that would prevent USB from working in Linux when USB works in BIOS without issue. Also, until I can figure out why the network device doesn't connect either I won't be able to apply the patch (though an add-in card may let me rule this out tonight).

[Admin]

I'd rather say that it would be weird the opposite way. BIOS which is supposed to support everything on the motherboard has to work. Linux kind of doesn't. BIOS often supports devices in a simplified way, for example VBE for graphics card - while you wouldn't like to use them instead or regular GPU drivers.

[Admin]

So is there a way for me to force Linux to let the BIOS manage the devices for the USB and network controllers until such time as they are (better?) supported in the Linux kernel?

[Admin]

I don't think so. The days when all devices were accessed through BIOS are long gone. However, I can't assure you that the problem is due to the lack of drivers. Did you find anything interesting in dmesg, tried to modprobe USB related modules?

[Admin]

I will have more time to experiment this evening. My recollection is that I could not insmod usb_ehci but I'm not sure why. In the BIOS I set EHCI and OCHI to legacy mode - perhaps I should only set one or the other? In syslog I see messages like this device not accepting address 6, error -32

[Admin]

@BrionS please pastebin the entire dmesg or /var/log/dmesg from right after it boots up. You can redact out any MAC & IP addresses if you'd like. Also, lspci -vvv.

[Admin]

Will do @derobert, but I will be several hours before I'll have access to the machine again.

[Admin]

@derobert, I cannot paste the entire dmesg here because I do not have network connectivity (I think it's related). I even removed my ethernet card from the old machine and placed it in this one and it doesn't work either - can't even ping the local router.

[Admin]

@BrionS Hmm, can't get the data off with USB, or Ethernet. I'm guessing serial isn't present (or you don't have the cables...). You might be able to use a CD-RW to move the file. I'd suggest trying things like pci=noacpi or acpi=noirq. Maybe one of those will get it working. Also, make sure to try the latest kernel version—possibly even the latest 3.9 rc.

[Admin]

Also, I found bugs.launchpad.net/ubuntu/+source/linux/+bug/859137 which suggests that your USB3 ports might work. It also suggests a BIOS option to play with, and making sure you have the latest BIOS installed. I'd check for latest BIOS first.

[Anthon]

It would be more helpful if you provided a solution here in text, and only use links for background information and non-essential details. Without that, once your link becomes invalid your answer has no value.

[mikeserv]

They're never the same. Even just a few weeks difference in manufacturing dates could mean a new source for a common motherboard component and/or superio revision. Circuit board manufacture is the shady underbelly of computing.

[Robbie]

I'll point out that for me even though turning on IOMMU worked for me, it deactivated all my internal USB 3 ports. Also, I was previously experiencing some issues with the ethernet port, but turning IOMMU on fixed those issues.

[enthusiasticgeek]

Like one of the users commented in the link you provided "This is NOT a fix. This means you are not using your drive at full speed. This is like putting a band-aid on a severed limb."

[Andor]

Did you try enabling xHCI Handoff to fix the USB 3.0 ports?

[Rahul Singh]

@StuartP.Bentley yes xHCI and eHCI Handoff settings are enabled as well as IOMMU Controller. This does enable my USB 3.0 ports but for whatever reason does not enable my USB keyboard to work in BIOS or grub screens - however my USB mouse does (go figure). I have a second PS/2 style keyboard plugged in solely for booting into BIOS.

[Bruce]

There is more to it. If you wend your way through all the ubuntu fora, you find that a boot loader setting is recommended ("iommu=soft") with IOMMU DISabled. My GB 990FXA-UD3 defaults to enabled and I could not use my external USB3 hub. BOTTOM LINE: this may not solve your problem. If not, keep googling.

[Bruce]

I am glad it works for you. I have exactly your setup (256GB SSD + mirrored 3TB drives for /u (/home)). My USB3 ports work, but the USB3 hub hung off of one does not. (Well, I can use a thumb drive on it, but not a keyboard or mouse.)

[Admin]

iommu=soft in conjunction with xHCI+eHIC Handoff and IOMMU Controller(all enabled), without having to enable "Legacy Only". Arch Linux at full speed boot, EFI and witout iommu or usb3 root device issues.

[Marc.2377]

It is recommended to leave EHCI handoff disabled in BIOS for best performance with USB2.0.

[Polymerase]

Works perfect, even 3 years later (Ubuntu 20.04, AMD FX-8320, Gigabyte GA-970A-D3). You saved me sir. I was trying to debug unsuccessfully a whole day. Until I searched with the right keywords and found your post. Note that video, ram, ssd are unrelated. This USB freezing issue is the Gigabyte mobo AND Linux. The PC was working perfect with Windows.

[nrmad]

You beautiful human you. Must of been a cosmic ray haha