I have a debian mint based system where I plug in 16 usb devices. The Kernal is: 3.11.0-12-generic After about 10 or so devices I start to experience problems with connecting new ones. There error for one such device can be found in dmesgs as follows (the last 2 lines differ)

[NEW UPDATE: WORKAROUND] I found that this issue is specific to xhci. In my bios I was able to actually disable xhci and force linux to fall back to ehci (presumably). Now all my devices are working just fine!. Of course this means no USB3 devices for me. Fortunately my immediate application does not require them. I don't know if this is an intel issue or a linux issue. It would be good to leave this page up because someone else is very like to find it.

dmesg | grep -i 3-5.1 

working device:

[    1.883505] hub 3-5:1.0: USB hub found
[    1.883733] hub 3-5:1.0: 4 ports detected
[    3.370272] usb 3-5.1: new full-speed USB device number 17 using xhci_hcd
[    3.387126] usb 3-5.1: New USB device found, idVendor=03eb, idProduct=2045
[    3.387129] usb 3-5.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.387908] usb-storage 3-5.1:1.0: USB Mass Storage device detected
[    3.388006] scsi14 : usb-storage 3-5.1:1.0
[  121.738568] usb 3-5.1: USB disconnect, device number 17
[  121.942662] usb 3-5.1: new full-speed USB device number 28 using xhci_hcd
[  121.961332] usb 3-5.1: New USB device found, idVendor=03eb, idProduct=204b
[  121.961334] usb 3-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[  121.961336] usb 3-5.1: Product: LUFA USB-RS232 Adapter
[  121.961337] usb 3-5.1: Manufacturer: Dean Camera
[  121.961338] usb 3-5.1: SerialNumber: 741333532373518080C1
[  121.961408] usb 3-5.1: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[  121.962080] cdc_acm 3-5.1:1.0: ttyACM3: USB ACM device
[ 1281.513105] usb 3-5.1: USB disconnect, device number 28

dmesg | grep -i 3-5.1 

Failing device:

[    3.638401] usb 3-5.4: new full-speed USB device number 20 using xhci_hcd
[    3.655067] usb 3-5.4: New USB device found, idVendor=03eb, idProduct=2045
[    3.655070] usb 3-5.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.655868] usb-storage 3-5.4:1.0: USB Mass Storage device detected
[    3.655977] scsi17 : usb-storage 3-5.4:1.0
[  118.793161] usb 3-5.4: USB disconnect, device number 20
[  122.603119] usb 3-5.4: new full-speed USB device number 31 using xhci_hcd
[  122.621653] usb 3-5.4: New USB device found, idVendor=03eb, idProduct=204b
[  122.621655] usb 3-5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[  122.621656] usb 3-5.4: Product: LUFA USB-RS232 Adapter
[  122.621657] usb 3-5.4: Manufacturer: Dean Camera
[  122.621658] usb 3-5.4: SerialNumber: 74133353237351808021
[  122.621795] usb 3-5.4: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[  122.622419] usb 3-5.4: Not enough host controller resources for new device state.
[  122.622424] usb 3-5.4: can't set config #1, error -12

I have a hardware topology as follows: PC -> 4 powered usb2 hubs -> each with 4 usb(1) devices. These devices are "dual boot" and you can see above where they are being ejected as mass storage devices and booting back up as serial devices on the same ports.

I powered the USB hubs straight form the power supply, each of my devices pulls about 700mA and the 5V line from the supply drops to 4.69V.

There are a number of usb areas on my machine, as I understand these are connected to underlying hubs or root hubs. Moving the external hubs around makes no difference to the findings. Experimentally: I thought that placing hubs on hubs would lead to bigger problems, but the results were the same.

When I have all the devices plugged into power (and drawing current), but only 3 hubs plugged into the PC, every thing is fine. When I plug in the 4th hub, i can see in LSUSB that all the devices are there, However, only 1 out of the 4 devices on that last hub comes up. In this case. 3-5.1 is fine, but 3-5.2 3-5.3 and 3-5.4 seems to not load the drivers.

All the devices are identical and I have already tested things like swapping the devices around, swapping hubs, etc. It is always the last devices to go in. This even happens if the last device is something completely different like a mouse or a wifi dongle. The device will be visible in lsusb, but it won't work. I assume that this is an indication of an over-lying USB limitation on the operating system, rather than something that is driver specific.

On a reboot, it still the last 3 devices when current is being drawing. HOWEVER. I am also able to put these devices into a state where no current is being drawing and it is possible to get them up.

My conclusion is that the OS is reading the current draw and making some assessment about power resources. Possibly they are getting this information from the hubs and maybe even adding the values together. It would be good to know if I could simply have "more host controller resources"

[update] I found here what looks like the source code for the error message: I don't like the look of "/* FIXME: can we allocate more resources for the HC? */" Maybe this also means there is a way to allocate more resources from the start.

Any clues would be great David

  • Are you using a 64-bit kernel? If not, you should start by doing that. Mar 21, 2014 at 11:47

3 Answers 3


I too hit this bug (after trying to connect a dozen USB network interface devices). I'm pretty sure it's not an electrical current problem with the devices: they are all on powered hubs and well within the current limitations. I think it's an issue of allocating interrupts or some other resource.

I tried the workaround of disabling USB 3.0 in the BIOS but I suspect the motherboard uses USB 3.0 internally (for Bluetooth and some other stuff), it didn't work (lsusb -t showed that xhci_hcd was being used). I had to rebuild the kernel (I'm using Ubuntu 14.04) to remove the xhci support and then it worked.

Note: Ubuntu by default compiles ehci and xhci into the kernel - it doesn't load them as modules. I tried rebuilding them as modules so that I could play around with them using modprobe but that failed because:

  1. If ehci is a module, it must be loaded before ohci and ahci modules (see warning in dmesg), and every way I tried to do that failed (in any case, I thought kernel modules were required to be load-order independent?).

  2. The xchi module always ended up loaded, even if blacklisted, presumably to handle internal hardware. Didn't investigate this much, however.

Only by setting up a kernel config where ehci was compiled in and xhci was compiled out did it work. I haven't tested re-enabling USB 3.0 in the BIOS with the new xhci-free kernel.

  • 1
    thanks for the varification. Really good info. The issue for me now is starting to be that it is becoming harder to get good USB2 hubs and the market is populating with USB3 hubs. The Linux driver writers need to look into this, in my opinion. Of course... such is open source, it might be up to us :-P
    – SpiRail
    Aug 11, 2014 at 20:34
Not enough host controller resources for new device state.

can't set config #1, error -12

Faced with the same errors. XHCI (usb 3.0) in linux kernel is limited to 32 devices. It looks like a bug. But maybe this is a Bill Gates way "640 kilobytes enough for everyone". In any case, it's a pain.

1) The easiest way to fix it: disable XHCI (usb 3.0) support in motherboard BIOS if possible. 2) The hard way to fix it: disable XHCI linux module. modprobe -r xhci-hcd But in most cases it does not work. You must recompile the kernel to disable XHCI and enable OHCI (usb 1.1) and EHXI (usb 2.0).

  • I cant understand the logic. Can you help me? USB3.0 it appears to be a newer standard than usb 2.0 that it suppose it can support even more devices. What are the limitations of xHC or OHCI? Jun 11, 2023 at 20:52

This issue comes from the underlying USB hardware controller which cannot handle that much devices. Linux source code shows the xHC returned a "resource error" code when trying to configure the interface. Chapter 4.4.6 of the xHCI standard explains this case:

The Resources Required variable is compared to the Resources Available variable, if the result indicates an oversubscription of resources by the command (i.e. Resources Available - Resources Required is less than 0), then the command shall be unsuccessful and a Resource Error Completion Code shall be returned in the Command Completion Event. Refer to section for more information on xHC resources.

My workaround is to release xHCI resources by removing every USB device I don't need, such as internal USB devices (e.g. bluetooth, wifi, etc.) and USB 3.0 hubs with only USB 2.0 devices attached to them.

Here are the steps:

  1. Run lsusb to see if there is anything unused.
  2. Remove your unused devices using sysfs echo 1 > /sys/<path to device>/remove. Have a look at dmesg and see how it removes the device and every sub-device. Which means that you can remove an entire USB tree by using this command on the root device.
  3. You should now be able to correctly plug more devices (cf. dmesg logs).

To make this persistent when rebooting, add udev rules to remove the devices:

SUBSYSTEM=="usb" <your conditions to match unused devices> RUN="sh -c 'echo 1 > /sys$DEVPATH/remove'"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .