Computer has been running great other than when I wake it from sleep with the front power button, the wired mouse and keyboard do not wake back up and I have to hard power cycle to get them back.
Running EndeavourOS (Arch based) with kernel 6.17.1.
Anyone else dealing with this or know a solution?
I have a problem that may be related, where on boot, a keyboard (Ducky One) was not working until I disconnected and reconnected it. It seemed related to the “reset” not working properly. Funnily enough, plugging the keyboard in the front USBA adapter did not show this issue.
My other keyboard (very basic Fujitsu USB keyboard) was not showing this issue.
Maybe share your dmesg output related to usb?
One thing you can try, is to disable PS/2 emulation in the bios. I have found that on Omarchy (Arch based) that having it enabled in the bios would cause the trackpad to not work when resuming from suspend or hibernation with the Framework 12.
Thanks, I’ll give that a try when I get home.
I have the same issue with Debian. Different Kernel versions do not solve the problem. Even disabeling the USB-Power-Management does not fix it.
My workaround is, use the front sided USB-Ports or use the USB-C-Ports on the back.
I don’t know why, but the back sided USB-Type-A-Ports do not wake up the PC.
EDIT:
Correct, a mouse or keyboard connected to the back sided USB-Type-APorts do not come back after the PC woke up. My explanation was wrong.
While they don’t wake up the PC, my bigger problem and the problem I’m posting about is that once the pc wakes up (from me pushing the power button) the wired keyboard and mouse do not come back to life so I have no input into the PC until I force reboot it with the power button.
It works fine with half a dozen other computers I’ve used with Linux and this keyboard and mouse, this problem is unique to the Framework Desktop running Linux. At least it’s for me.
Appreciate the idea, I’ll try the USB C port and see if that works until I figure out why the USB A ports on the back are dead after waking from sleep. Thanks!
My bad, wrong explanation. I had this issue also on a different machine and the solution was to disable the power-saving for USB in the bios. I could not find this option in the BIOS of the Framework-Desktop.
Ran into the same, got some dmesg logs over SSH before rebooting:
[Tue Oct 21 09:39:10 2025] Freezing user space processes
[Tue Oct 21 09:39:10 2025] Freezing user space processes completed (elapsed 0.003 seconds)
[Tue Oct 21 09:39:10 2025] OOM killer disabled.
[Tue Oct 21 09:39:10 2025] Freezing remaining freezable tasks
[Tue Oct 21 09:39:10 2025] Freezing remaining freezable tasks completed (elapsed 0.024 seconds)
[Tue Oct 21 09:39:10 2025] printk: Suspending console(s) (use no_console_suspend to debug)
[Tue Oct 21 09:39:10 2025] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[Tue Oct 21 09:39:10 2025] ACPI: EC: interrupt blocked
[Tue Oct 21 19:59:29 2025] ACPI: EC: interrupt unblocked
[Tue Oct 21 19:59:30 2025] [drm] PCIE GART of 512M enabled (table at 0x0000008000900000).
[Tue Oct 21 19:59:30 2025] amdgpu 0000:c3:00.0: amdgpu: SMU is resuming…
[Tue Oct 21 19:59:30 2025] amdgpu 0000:c3:00.0: amdgpu: SMU is resumed successfully!
[Tue Oct 21 19:59:30 2025] xhci_hcd 0000:c3:00.4: Port resume timed out, port 3-1: 0x400e03
[Tue Oct 21 19:59:30 2025] nvme nvme0: 32/0/0 default/read/poll queues
[Tue Oct 21 19:59:30 2025] usb 9-1.3.4.1: reset high-speed USB device number 17 using xhci_hcd
[Tue Oct 21 19:59:30 2025] usb 1-1: reset high-speed USB device number 2 using xhci_hcd
[Tue Oct 21 19:59:30 2025] usb 2-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring vcn_unified_1 uses VM inv eng 1 on hub 8
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring jpeg_dec_0 uses VM inv eng 4 on hub 8
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring jpeg_dec_1 uses VM inv eng 6 on hub 8
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 13 on hub 0
[Tue Oct 21 19:59:31 2025] amdgpu 0000:c3:00.0: amdgpu: ring vpe uses VM inv eng 7 on hub 8
[Tue Oct 21 19:59:31 2025] usb 1-1.2: reset high-speed USB device number 3 using xhci_hcd
[Tue Oct 21 19:59:31 2025] usb 1-1.3: reset full-speed USB device number 4 using xhci_hcd
[Tue Oct 21 19:59:41 2025] xhci_hcd 0000:c3:00.4: xHCI host not responding to stop endpoint command
[Tue Oct 21 19:59:41 2025] xhci_hcd 0000:c3:00.4: xHCI host controller not responding, assume dead
[Tue Oct 21 19:59:41 2025] xhci_hcd 0000:c3:00.4: HC died; cleaning up
[Tue Oct 21 19:59:41 2025] usb 4-1: PM: dpm_run_callback(): usb_dev_resume.llvm.17814759931418841714 returns -22
[Tue Oct 21 19:59:41 2025] usb 4-1: PM: failed to resume async: error -22
[Tue Oct 21 19:59:41 2025] OOM killer enabled.
[Tue Oct 21 19:59:41 2025] Restarting tasks: Starting
[Tue Oct 21 19:59:41 2025] usb 4-1: USB disconnect, device number 2
[Tue Oct 21 19:59:41 2025] usb 4-1.2: USB disconnect, device number 3
[Tue Oct 21 19:59:41 2025] usb 3-1: USB disconnect, device number 2
[Tue Oct 21 19:59:41 2025] usb 3-1.1: USB disconnect, device number 3
[Tue Oct 21 19:59:41 2025] usb 3-1.1.1: USB disconnect, device number 4
[Tue Oct 21 19:59:41 2025] usb 3-1.1.1.1: USB disconnect, device number 5
[Tue Oct 21 19:59:41 2025] usb 9-1.3.4.1: USB disconnect, device number 17
[Tue Oct 21 19:59:41 2025] Restarting tasks: Done
[Tue Oct 21 19:59:41 2025] random: crng reseeded on system resumption
[Tue Oct 21 19:59:41 2025] PM: suspend exit
[Tue Oct 21 19:59:41 2025] usb 3-1.1.1.2: USB disconnect, device number 6
[Tue Oct 21 19:59:41 2025] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[Tue Oct 21 19:59:41 2025] Realtek Internal NBASE-T PHY r8169-0-bf00:00: attached PHY driver (mii_bus:phy_addr=r8169-0-bf00:00, irq=MAC)
[Tue Oct 21 19:59:41 2025] usb 9-1.3.4.1: new high-speed USB device number 20 using xhci_hcd
[Tue Oct 21 19:59:41 2025] sd 1:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[Tue Oct 21 19:59:41 2025] xhci_hcd 0000:c3:00.4: WARN Can’t disable streams for endpoint 0x85, streams are being disabled already
[Tue Oct 21 19:59:41 2025] usb 3-1.1.1.3: USB disconnect, device number 7
[Tue Oct 21 19:59:41 2025] usb 9-1.3.4.1: New USB device found, idVendor=152a, idProduct=8750, bcdDevice= 1.25
[Tue Oct 21 19:59:41 2025] usb 9-1.3.4.1: New USB device strings: Mfr=1, Product=3, SerialNumber=0
[Tue Oct 21 19:59:41 2025] usb 9-1.3.4.1: Product: DX3 Pro+
[Tue Oct 21 19:59:41 2025] usb 9-1.3.4.1: Manufacturer: Topping
[Tue Oct 21 19:59:41 2025] r8169 0000:bf:00.0 enp191s0: Link is Down
[Tue Oct 21 19:59:44 2025] r8169 0000:bf:00.0 enp191s0: Link is Up - 2.5Gbps/Full - flow control rx/tx
[Tue Oct 21 19:59:51 2025] handle_bus_lock: 34 callbacks suppressed
[Tue Oct 21 19:59:51 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:51 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:51 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:52 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:52 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:52 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:52 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:52 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:52 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:52 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] handle_bus_lock: 11156 callbacks suppressed
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/314565 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/314191 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/314191 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/314191 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 19:59:56 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] handle_bus_lock: 14809 callbacks suppressed
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/314565 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/314191 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/314191 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/313205 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/314565 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/314565 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/314191 took a bus_lock trap at address: 0xf3c0bc84
[Tue Oct 21 20:00:01 2025] x86/split lock detection: #DB: CHTTPClientThre/314565 took a bus_lock trap at address: 0xf3c0bc84
Unfortunately this doesn’t give me any ideas on how to resolve it and the idiot bios is so barren it is very unlikely to have any useful options that help with this.
I couldn’t find a solution but moving them to the USB C ports works.
I can confirm this issue on my desktop as well, I am running Fedora 42 kde, and I get the same problem, gemini helped me narrow down the logs to point to the issue:
Oct 22 22:41:50 FRAME-DESK kernel: PM: suspend entry (s2idle)
Oct 23 00:06:40 FRAME-DESK kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Oct 23 00:06:40 FRAME-DESK kernel: queueing ieee80211 work while going to suspend
Oct 23 00:06:40 FRAME-DESK kernel: PM: suspend devices took 0.122 seconds
Oct 23 00:06:40 FRAME-DESK kernel: amdgpu 0000:c2:00.0: amdgpu: SMU is resumed successfully!
Oct 23 00:06:40 FRAME-DESK kernel: xhci_hcd 0000:c2:00.4: Port resume timed out, port 1-1: 0x400e03
Oct 23 00:06:40 FRAME-DESK kernel: xhci_hcd 0000:c2:00.4: xHCI host not responding to stop endpoint comma>
Oct 23 00:06:40 FRAME-DESK kernel: xhci_hcd 0000:c2:00.4: xHCI host controller not responding, assume dead
Oct 23 00:06:40 FRAME-DESK kernel: xhci_hcd 0000:c2:00.4: HC died; cleaning up
Oct 23 00:06:40 FRAME-DESK kernel: usb 2-1: PM: dpm_run_callback(): usb_dev_resume returns -22
Oct 23 00:06:40 FRAME-DESK kernel: usb 2-1: PM: failed to resume async: error -22
Oct 23 00:06:40 FRAME-DESK kernel: PM: resume devices took 10.969 seconds
Oct 23 00:06:40 FRAME-DESK kernel: Component: resume devices, time: 10969
Oct 23 00:06:40 FRAME-DESK kernel: WARNING: CPU: 5 PID: 437816 at kernel/power/suspend_test.c:53 suspend\_>
Oct 23 00:06:40 FRAME-DESK kernel: Modules linked in: xt_MASQUERADE xt_mark nft_compat binfmt_misc tun ui>
Oct 23 00:06:40 FRAME-DESK kernel: i2c_piix4 joydev wmi_bmof cros_ec tee pcspkr realtek rfkill i2c_smbus>
Oct 23 00:06:40 FRAME-DESK kernel: RIP: 0010:suspend_test_finish+0x74/0x80
Oct 23 00:06:40 FRAME-DESK kernel: suspend_devices_and_enter+0x1e5/0x2b0
Oct 23 00:06:40 FRAME-DESK kernel: pm_suspend+0x43/0x80
Oct 23 00:06:40 FRAME-DESK kernel: usb 1-1: USB disconnect, device number 2
Oct 23 00:06:40 FRAME-DESK kernel: usb 1-1.1: USB disconnect, device number 3
Oct 23 00:06:40 FRAME-DESK kernel: usb 2-1: USB disconnect, device number 2
Oct 23 00:06:40 FRAME-DESK kernel: PM: suspend exit
What this means:
xhci_hcd is the driver for your USB 3.0 (and newer) host controller.
0000:c2:00.4 is the PCI address of this specific USB controller on your motherboard.
Upon resume, the kernel attempted to wake up this USB controller, but it timed out, failed to respond, and the kernel eventually declared it “dead” (HC died; cleaning up).
The usb 2-1: PM: failed to resume async: error -22 lines confirm that a USB device (likely one of your input devices) failed to resume due to the underlying controller being unresponsive.
The PM: suspend entry (s2idle) line also confirms you’re using the s2idle (deepest, but sometimes problematic) sleep state.
Gemini recommended me change some grub boot settings to use deep sleep instead of s2idle, so that’s my first step in mitigating the issue. We’ll see how well it works
Thanks for the additional information and please let us know if anything helps. I’m using EndeavourOS on mine (Arch based) and having the issue. I moved the mouse and keyboard to the USB C connection and it works fine there for some reason.
Yup, same issue on Fedora. Luckily my keyboard is USB-C (unlike my mouse), so I was able to fix it by logging in and rebinding the ports and made a quick script to automate it. I really do hope this gets fixed soon though.
Switching to deep sleep instead of s2idle didn’t work, so I just switched my keyboard to the usb-c port as suggested by @LBTRS and that works.
I hope the problem is clear and framework can address it soon, while usb-c is a nice workaround, it’s not the ideal solution
Similar issue on Bazzite (latest edition as of 10/28 sorry not very technical here). My wireless mouse works (connected to front panel modular type-A port), but the keyboard plugged into the motherboard just won’t receive any power after sleep - even after resetting the keyboard into different usb slots. Figured I’d tack on to help get this issue seen more.
My Framework Desktop running Bazzite; keyboard and mouse will not work if system goes to sleep; My Bazzite does not have a deep sleep option only s2idle. I hear some others tried deep sleep in a different Linux distro and it would not fix the issues. If framework don’t fix with a bios update I guess it’s time to go back to windows. Don’t make me do it framework… I am also not a fan of how hard it is to adjust iGPU max memory allocation in rpm-ostree kargs either when doing LLM. This sleep issue very frustrating though.
I’m not sure Framework can take responsibility for this one or fix it with a BIOS update. It looks like a problem with the xHCI kernel driver in some recent Linux kernel updates.
I don’t know what’s causing the timeout, but I can offer a quick fix to reload it when the system resumes until someone submits a patch.
If you are trying to make this work for something other than the Framework Desktop, you’ll need to identify the hardware address and pick whatever is freezing for you (you’ll see the address of the device that stops responding called out if you check the kernel log with dmesg. The message will say, “xHCI host controller not responding, assume dead”)
Get a root shell and write the following script to
/lib/systemd/system-sleep/framework-desktop-usb-fix.sh
#!/bin/bash
# Fix for xhci_hcd USB suspend bug.
# Reloads xhci device 0000:c2:00.4 (the back two USB-A ports on Framework Desktop)
#Check for 'post' in params so this only runs on resuming
if [[ "${1}" == "post" ]]; then
/bin/sh -c "/bin/echo -n '0000:c2:00.4' > /sys/bus/pci/drivers/xhci_hcd/unbind"
/bin/sleep 1
/bin/sh -c "/bin/echo -n '0000:c2:00.4' > /sys/bus/pci/drivers/xhci_hcd/bind"
fi
Then make the script executable with
chmod +x /lib/systemd/system-sleep/framework-desktop-usb-fix.sh
You can test if it works by running systemctl suspend. Even if the ports aren’t currently working for you, this should work without needing to reboot.
This isn’t going to be perfect. You’ll experience a 1 second delay after resuming from suspend before your keyboard works again. I assume someone will eventually submit a kernel patch and you can delete the script – just keep an eye on dmesg and see if the “xHCI host controller not responding, assume dead” goes away in a month or two after updating your system.
I have the same problem using Ubuntu 24.4 - it is an on again off again problem. The USB ports were working great and then I installed rocM for my models and rebooted and no the the mouse and keyboard gone - worked on it for half a day got the mouse to work then reboot and nothing. Bought a new keyboard mouse combo - thought it was a cheap C knockoff but plugged old one in window PC and fired right up. This has plagued my framework experience - to the point I nearly sent it BK - my own wish i did.
The best I can say is this is a common problem in Linux with any new hardware, and you’re using new hardware. You’d encounter it on this type of board whether you bought it from Framework or Dell. This is why a lot of Linux laptop users like to buy refurbished Thinkpads – the hardware is generally old enough to have very mature support in the kernel, and these things have been worked out.
Eventually driver support will get better as developers identify these bugs and correct the behavior problems. Someone working at Framework might end up submitting the patch themselves, idk.
Did the unbind/bind commands I shared work to wake up the hardware again after a suspend cycle? If they didn’t, you might have other issues.
It doesn’t happen on the EVO-X2 from GMKtec which uses the same “new hardware”.
These are different boards using different USB controllers. One of them is newer. If you own both of these, look at your lspci output and compare.
Framework doesn’t maintain the Linux kernel – but I’m not trying to play apologist here either: if you don’t want to use a cheap fix like the wakeup script I offered, your options are basically to use Windows, stop letting it sleep/hibernate and wait for a kernel patch, or try to return it and tell them they’ve lost your business because of a Linux kernel bug.