I moved to the USB C port and that is the work around I’m using until it gets figured out. Definately won’t be going back to Windows, left that behind a couple years ago.
thank you for responding to my issue - yes i did what you suggested but to no avail. After digging deeper and realizing everything was working properly - it came down LightDm - i was running on lightDm and it was not running correctly - after several tries I managed to install and run gdm3 - once i got the installed my problems all went a way both the keyboard and mouse are now in action and working properly - i never lost power, and the pc could see both the keyboard and the mouse. So thanks again
I am having a couple of issues with my Desktop, searching around the forum for similar issues being reported led me here.
I am running Windows 11 but I am seeing some of the same issues you guys are discussing.
If I let my Desktop enter sleep mode, I can’t wake the machine with either my mouse or keyboard.
I have both devices plugged into a USB-A hub. The hub has lights above each connector to indicate an active connection. In normal operation I can see an active light above both the keyboard and mouse connectors. After entering sleep mode and failing to wake the Desktop with either device, unplugging them and reconnecting results in those lights remaining off. The Desktop no longer recognises the connection. At this point I have to use the power button to switch off the Desktop.
I am also seeing a problem with my Ducky One 2 keyboard whereby on boot of Windows 11 it’s sometimes not recognised by the Desktop. I have to disconnect and reconnect the USB cable for it to become actice. I have tried the keyboard in multiple USB connectors on the Desktop and see the same issue.
I wanted to drop a note here as these problems appear to affect both Windows and Linux.
I think I’m having a similar issue on my Framework 13 laptop (AMD Ryzen 300 Series). Sometimes the laptop doesn’t want to wake from sleep. Mouse works, but keyboard doesn’t. I’m on Fedora 43 GNOME version.
@frank.crook ‘s script has been working for me on Framework Desktop running Fedora 43. Thanks for saving me from disk corruption.
Hey everyone — We’ve been tracking this one upstream at (Bug 221073) and working with the xHCI and AMD maintainers directly.
In the meantime, we’ve put together a workaround. It checks dmesg on resume — if the controller came back fine, it does nothing. If it died, it rebinds the correct controller and brings back all USB devices behind it. It also logs every event to the journal so you can see how often the failure is actually hitting you.
This works on Fedora, Arch/EndeavourOS/CachyOS, Debian, Bluefin, Bazzite — etc. You will need to change the PCI address to match your system. Check sudo dmesg | grep "HC died" to find yours.
The dmesg command above will yield something like:
[20223.807554] xhci_hcd 0000:c1:00.4: HC died; cleaning up
[20545.002227] xhci_hcd 0000:c1:00.4: HC died; cleaning up
Edited and corrected Feb 23rd.
sudo tee /usr/local/bin/xhci-resume-fix.sh << 'EOF'
#!/bin/bash
DRIVER_PATH="/sys/bus/pci/drivers/xhci_hcd"
for DEVICE in $(lspci -D | grep -i xhci | awk '{print $1}'); do
if dmesg --since="-30 seconds" | grep -q "xhci_hcd ${DEVICE}.*HC died\|usb.*failed to resume.*error"; then
logger -t xhci-fix "xHCI controller ${DEVICE} failed on resume, rebinding"
echo -n "$DEVICE" > "${DRIVER_PATH}/unbind"
sleep 2
echo -n "$DEVICE" > "${DRIVER_PATH}/bind"
logger -t xhci-fix "xHCI controller ${DEVICE} rebound successfully"
else
logger -t xhci-fix "xHCI controller ${DEVICE} resumed normally, no action needed"
fi
done
EOF
sudo chmod +x /usr/local/bin/xhci-resume-fix.sh
Then create the service:
sudo tee /etc/systemd/system/xhci-resume-fix.service << 'EOF'
[Unit]
Description=Rebind xHCI controller if dead after resume
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/xhci-resume-fix.sh
[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
EOF
Enable it:
sudo systemctl daemon-reload
sudo systemctl enable xhci-resume-fix.service
To verify it’s working after a resume (5 minutes is just an example):
journalctl -t xhci-fix --since="5 minutes ago"
Suspend, then when resuming later (say 5 minutes), check it:
journalctl -t xhci-fix --since="5 minutes ago"
The upstream bug is still open and we’re pushing for a proper kernel fix. This is a workaround until that lands.