Strange boot kernel driver bug (USB)

Software & Operating Systems Linux
1

I have a threadripper 2950X on and Aorus X399 Xtreme. I am running Netrunner (Manjaro) on kernel 4.20.7 (kernel version doesn’t seem to make a difference) and I am getting this strange bug that happens occasionly and I have no idea how to even start debugging.

When I boot I get a failure of my builtin bluetooth (Intel 8265) with the error in dmesg:

Bluetooth: hci0: urb 00000000dafd9c2c failed to resubmit (113)

Also, the front panel USB doesn’t work one reboot (works in Bios and Windows). The two problems seem to be related. If one isn’t working the other also doesn’t work, but if one works the other seems to work.

One of the ways to get it to work is keeping a USB flash drive plugged in to the front panel while booting. Suddenly both the Bluetooth and Front USB will work. The built in bluetooth interface is through USB so that is how they are related I believe. I just don’t understand why the USB fails if it boots with nothing plugged in.

2

Try for the lulz if the devices awake if you disable & enable the kernel module, might be a kernel issue

sudo rmmod btusb
sudo modprobe btusb

or replace ‘btusb’ with ‘bluetooth’

3

I edited your post for clarity.

4

Already tried that, rmmod and then modprobe doesn’t fix it.

If the issue presents itself the only way I found to fix it is reboot with usb device plugged in the front.

5

Some Ideapads have weird powersaving features, you need to blacklist the ideapad_module in order for wifi & bluetooth to work, otherwise they stay suspended.
Maybe there’s something similar going on in your mobo?

6

Delving deeper into this I find that in both cases during the boot sequence you get towards the end of the boot sequence

kernel: usb usb1: root hub lost power or was reset
kernel: usb usb2: root hub lost power or was reset

But when I don’t have a device plugged in it doesn’t seem to reset properly and I get

kernel: Bluetooth: hci0: urb 000000000bbeda3c failed to resubmit (113)
kernel: xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
kernel: xhci_hcd 0000:01:00.0: HC died; cleaning up

Here is the kernel log of a working boot.
And Here is one when things break down.

I am guessing it must be a USB power bug in the kernel that is causing some controllers to sleep and not wake up properly.

7

Well since xhci = usb 3, then check this out:
(And some googling shows that people having these issues all have Gigabyte boards…)

8

Thanks for this. I had initially wrote down in my notes many months ago that the USB issue seems to be related to IOMMU, but since then I have had it not work sometimes with IOMMU disabled, so I thought it might not be related after all.

It is good to know that this isn’t an isolated incident and not a sign of having defective hardware. I guess I will wait for a patch to fix it, and until then I just need to remember to plug a USB in the machine when booting.

9

Your working report shows this as not loading correctly
Feb 19 23:28:33 shockwave kernel: ACPI: FACS 0x0000000076E44700 000040
Could this be an issue as web search says facs is firmware thing so maybe its not getting recognized correctly as device firmware written with windows in mind and has just minimum linux support (driver calls to firmware)
Windows never the same from 1 boot to next
Its always changing things so if linux driver not know this about firmwares that are biased to windows you can have plethora of issues