You are not logged in.
I have the following setup: mouse and keyboard connected via a USB switch (to switch between work laptop and private desktop).
I suspend (deep) my desktop when I don't use it. Sometimes I switch the peripherals to the work laptop while the desktop is suspended. When I turn on the desktop again and then switch the peripherals back via the switch, they are sometimes not working with the desktop. I have not identified any pattern any switching behavior that gives me any clues.
The following is logged in dmesg after resume and switching the peripherals back to the desktop:
xhci_hcd 0000:0f:00.0: Error while assigning device slot ID: Command Aborted
xhci_hcd 0000:0f:00.0: Max number of devices this xHCI host supports is 64.
usb usb7-port1: couldn't allocate usb_device
xhci_hcd 0000:0f:00.0: WARN: xHC save state timeout
xhci_hcd 0000:0f:00.0: PM: suspend_common(): xhci_pci_suspend returns -110
xhci_hcd 0000:0f:00.0: can't suspend (hcd_pci_runtime_suspend returned -110)Any idea what is causing this and how to fix it?
Last edited by 31KM (2025-04-07 12:27:53)
Offline
unbinding and binding the device again helps:
echo -n "0000:0f:00.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
echo -n "0000:0f:00.0" | tee /sys/bus/pci/drivers/xhci_hcd/bindBut maybe someone can still point me in the direction to solve this permanently.
Offline
Looks like a kernel bug.
One known bug which could likely cause this was introduced in 6.13 and fixed in 6.13.7, so start with making sure that you aren't running a known bad kernel.
Offline
I'm on 6.13.6, I'll update and report back, thanks!
Offline
Did not help, still happens ![]()
Kernel now is 6.13.8
Last edited by 31KM (2025-04-07 09:28:39)
Offline
Did it ever work correctly in the past with some other kernel versions?
BTW, what if you disconnect the devices before suspending? Isn't it simply the case that suspending and resuming completely breaks this controller and makes all of its ports nonfunctional?
I suppose you could try to automate the unbind/bind trick on every resume, or try the RESET_ON_RESUME quirk which AFAIK has similar effect. For the latter, add to kernel parameters: xhci_hcd.quirks=0x80; note that this will cause all USB 3.x controllers to be reinitialized on resume, devices will disconnect and reconnect, etc.
Other than that, you could report the bug upstream and hope for a fix. This may involve needing to test kernel patches.
Last edited by mmy8x (2025-04-07 10:05:49)
Offline
Yes, it did work in the past, but I can't really tell when exactly it stopped working.
Disconnecting the devices before suspend and attaching them again once resumed just worked. Not sure what to make of that though.
Will test with the quirk enabled and report back.
Edit: it did the trick
Last edited by 31KM (2025-04-07 10:30:07)
Offline
I went ahead and marked the thread as solved, since I have neither the time nor the skills to report this upstream.
Thanks to mmy8x ![]()
Offline
If you want I can help you with the bisection and the report, but you would of course need to do the testing on your machine ![]()
Online
So I just took a look at my upgrade history:
grep "upgraded linux " /var/log/pacman.log
[2023-09-22T13:46:00+0200] [ALPM] upgraded linux (6.5.3.arch1-1 -> 6.5.4.arch2-1)
[2023-09-22T15:06:36+0200] [ALPM] upgraded linux (6.5.3.arch1-1 -> 6.5.4.arch2-1)
[2023-09-27T17:45:44+0200] [ALPM] upgraded linux (6.5.4.arch2-1 -> 6.5.5.arch1-1)
[2023-10-14T09:33:58+0200] [ALPM] upgraded linux (6.5.5.arch1-1 -> 6.5.7.arch1-1)
[2023-11-01T18:37:02+0100] [ALPM] upgraded linux (6.5.7.arch1-1 -> 6.5.9.arch2-1)
[2023-11-24T19:24:50+0100] [ALPM] upgraded linux (6.5.9.arch2-1 -> 6.6.2.arch1-1)
[2023-12-06T22:20:04+0100] [ALPM] upgraded linux (6.6.2.arch1-1 -> 6.6.4.arch1-1)
[2024-02-13T11:18:26+0100] [ALPM] upgraded linux (6.6.4.arch1-1 -> 6.7.4.arch1-1)
[2024-03-03T18:58:27+0100] [ALPM] upgraded linux (6.7.4.arch1-1 -> 6.7.8.arch1-1)
[2024-03-29T20:03:00+0100] [ALPM] upgraded linux (6.7.8.arch1-1 -> 6.8.2.arch2-1)
[2024-04-17T21:38:50+0200] [ALPM] upgraded linux (6.8.2.arch2-1 -> 6.8.6.arch1-1)
[2024-05-05T16:27:06+0200] [ALPM] upgraded linux (6.8.6.arch1-1 -> 6.8.9.arch1-1)
[2024-08-08T19:06:14+0200] [ALPM] upgraded linux (6.8.9.arch1-1 -> 6.10.3.arch1-2)
[2024-10-14T23:07:00+0200] [ALPM] upgraded linux (6.10.3.arch1-2 -> 6.11.3.arch1-1)
[2025-02-19T21:24:58+0100] [ALPM] upgraded linux (6.11.3.arch1-1 -> 6.13.3.arch1-1)
[2025-03-14T20:59:22+0100] [ALPM] upgraded linux (6.13.3.arch1-1 -> 6.13.6.arch1-1)
[2025-04-07T11:20:51+0200] [ALPM] upgraded linux (6.13.6.arch1-1 -> 6.13.8.arch1-1)I'm fairly certain that 6.8.9 is probably the lower bound because I didn't have the issue for _that_ long.
I also read https://www.kernel.org/doc/html/latest/ … isect.html.
I'll start by downgrading to 6.8.9 and just do a quick test with that.
Offline
Just downgraded to 6.8.9 and disabled the quirk.
Quirks before:
xhci_hcd 0000:0f:00.0: hcc params 0x0110ffc5 hci version 0x120 quirks 0x0000000200000090Quirks after downgrade:
xhci_hcd 0000:0f:00.0: hcc params 0x0110ffc5 hci version 0x120 quirks 0x0000000200000410Did a "suspend -> detach peripherals -> resume -> attach peripherals" cycle and it worked.
Will move on to 6.10.3 and check that.
Offline
6.10.3:
Quirks still disabled:
xhci_hcd 0000:0f:00.0: hcc params 0x0110ffc5 hci version 0x120 quirks 0x0000000200000010(I guess it's okay that the quirk value changed since the kernel version also changed?)
Did a cycle and it did NOT work.
Offline
... also downgraded to 6.8.9 again and did 4 cycles and all worked.
So I guess I need to bisect kernel versions ]6.8.9-6.10.3]? And once I got the first faulty version I then need to bisect kernel commits? For the kernel versions I probably do not need to build them myself but can grab them from the Wayback machine, right? There is no tool support then, but there shouldn't be too many versions so I can probably do it by hand.
Offline
Could you verify that the "plain" 6.8 is good and 6.10 is bad?
sudo pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.8.arch1-1-x86_64.pkg.tar.zstsudo pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.10.arch1-1-x86_64.pkg.tar.zstOnline
The first bisection kernel (if the above two are good/bad as expected) is the following:
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-v6.9.rc5.r309.g63407d3-1-x86_64.pkg.tar.zst(note that this installs the kernel as linux-mainline, so you need to configure your bootloader to boot it (for example via grub-mkconfig -o ... or by writing the systemd-boot loader entry))
Online
Sure thing. Starting with 6.8:
Quirks:
xhci_hcd 0000:0f:00.0: hcc params 0x0110ffc5 hci version 0x120 quirks 0x0000000200000410Failed on first resume ![]()
(But boot also failed because it couldn't mount a disk, I just removed it from fstab and continued boot).
Edit:
Did some more cycles (including some more after a reboot) and they all worked.
(After one resume I had vertical green lines on my screen, but these were gone after the next cycle /shrug).
Last edited by 31KM (2025-04-07 18:51:59)
Offline
I just tested again with 6.8.9 and that also failed :'(
My reproducer is probably unreliable or the USB switch is just broken?
Offline
Just tested with a random older kernel (6.0.8) and that also fails (: I think bisecting further makes no sense without a stable reproducer. I tested various timings (when to detach during suspend/when to attach during resume) but nothing reliable. Also it migt just be the device that is broken in some way. I think I'll just upgrade the kernel again and re-apply the quirk.
Offline