# \[WORKAROUND\] Suspend/resume taking ~20s to recover \[edit: USB xHCI Host Controller problem\]

**URL:** <https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891>\
**Category:** Linux\
**Tags:** fedora\
**Created:** [April 1, 2025, 12:48pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891 "2025-04-01T12:48:10Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_Obscurant](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/john_obscurant/32/22180_2.png) [@John\_Obscurant](https://community.frame.work/u/John_Obscurant)\
**Post date:** [April 1, 2025, 12:48pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/1 "2025-04-01T12:48:10Z")

</div>

Starting a few weeks ago, when I resume from suspend, the screen powers on, shows the desktop (not the lock screen), then everything freezes for 10-30 seconds. After that time, the lockscreen appears and works as expected.

System: Framework Laptop 16 / firmware 0.0.3.4  
Fedora 41 / Linux Kernel 6.13.7 (same behaviour on 6.14)

journalctl after resume first shows this:  
// edit: Those messages are actually not related to the problem I experienced, but to a different one mentioned in the other thread.

> **Summary**
>
> Apr 01 14:27:44 joshua kernel: amdgpu 0000:03:00.0: amdgpu: MES FW versoin must be larger than 0x63 to support limit single process feature.  
> Apr 01 14:27:44 joshua kernel: amdgpu 0000:03:00.0: amdgpu: failed to change\_config.  
> Apr 01 14:27:44 joshua kernel: amdgpu 0000:03:00.0: amdgpu: resume of IP block \<mes\_v11\_0\> failed -22  
> Apr 01 14:27:44 joshua kernel: amdgpu 0000:03:00.0: amdgpu: amdgpu\_device\_ip\_resume failed (-22).  
> Apr 01 14:27:44 joshua kernel: amdgpu 0000:03:00.0: PM: dpm\_run\_callback(): pci\_pm\_resume returns -22  
> Apr 01 14:27:44 joshua kernel: amdgpu 0000:03:00.0: PM: failed to resume async: error -22

and seconds later this:

> **Summary**
>
> Apr 01 14:27:51 joshua kernel: ------------[cut here]------------  
> Apr 01 14:27:51 joshua kernel: WARNING: CPU: 13 PID: 91770 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu\_dm/amdgpu\_dm.c:3073 dm\_suspend+0x274/0x2e0 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: Modules linked in: uinput uhid rfcomm snd\_seq\_dummy snd\_hrtimer nls\_utf8 cifs cifs\_arc4 nls\_ucs2\_utils cifs\_md4 dns\_resolver netfs nf\_conntrack\_netbios\_ns nf\_conntrack\_broadcast nft\_fib\_inet nft\_fib\_ipv4 nft\_fib\_ipv6 nft\_fib nft\_reject\_inet nf\_reject\_ipv4 nf\_reject\_ipv6 nft\_reject nft\_ct nft\_chain\_nat nf\_nat nf\_conntrack nf\_defrag\_ipv6 nf\_defrag\_ipv4 ip\_set nf\_tables qrtr bnep sunrpc binfmt\_misc snd\_hda\_codec\_realtek snd\_hda\_codec\_generic snd\_hda\_scodec\_component snd\_hda\_codec\_hdmi vfat fat squashfs snd\_sof\_amd\_acp70 snd\_sof\_amd\_acp63 snd\_sof\_amd\_vangogh snd\_sof\_amd\_rembrandt snd\_sof\_amd\_renoir snd\_sof\_amd\_acp snd\_sof\_pci snd\_sof\_xtensa\_dsp snd\_sof snd\_sof\_utils snd\_pci\_ps leds\_cros\_ec cros\_usbpd\_charger snd\_soc\_acpi\_amd\_match led\_class\_multicolor cros\_charge\_control gpio\_cros\_ec cros\_ec\_hwmon cros\_usbpd\_logger cros\_ec\_sysfs cros\_ec\_chardev cros\_usbpd\_notify snd\_amd\_sdw\_acpi soundwire\_amd soundwire\_generic\_allocation cros\_ec\_dev soundwire\_bus mt7921e intel\_rapl\_msr amd\_atl snd\_soc\_sdca mt7921\_common  
> Apr 01 14:27:51 joshua kernel: intel\_rapl\_common snd\_soc\_core mt792x\_lib snd\_usb\_audio btusb edac\_mce\_amd snd\_hda\_intel btrtl mt76\_connac\_lib snd\_compress snd\_intel\_dspcfg btintel ac97\_bus snd\_intel\_sdw\_acpi snd\_pcm\_dmaengine mt76 btbcm snd\_rpl\_pci\_acp6x snd\_usbmidi\_lib snd\_hda\_codec snd\_acp\_pci btmtk snd\_ump cros\_ec\_lpcs kvm\_amd snd\_acp\_legacy\_common spd5118 cros\_ec bluetooth snd\_rawmidi snd\_hda\_core snd\_pci\_acp6x kvm mac80211 mc snd\_hwdep hid\_sensor\_als hid\_sensor\_trigger snd\_pci\_acp5x hid\_sensor\_iio\_common industrialio\_triggered\_buffer kfifo\_buf snd\_seq snd\_rn\_pci\_acp3x rapl libarc4 snd\_acp\_config industrialio snd\_seq\_device wmi\_bmof pcspkr snd\_soc\_acpi i2c\_piix4 thunderbolt snd\_pcm cfg80211 k10temp snd\_pci\_acp3x i2c\_smbus snd\_timer amd\_pmf snd amdtee rfkill soundcore amd\_sfh tee platform\_profile joydev amd\_pmc loop nfnetlink zram lz4hc\_compress lz4\_compress dm\_crypt typec\_displayport amdgpu amdxcp i2c\_algo\_bit drm\_ttm\_helper ttm drm\_exec gpu\_sched drm\_suballoc\_helper nvme drm\_panel\_backlight\_quirks drm\_buddy crct10dif\_pclmul  
> Apr 01 14:27:51 joshua kernel: nvme\_core crc32\_pclmul drm\_display\_helper crc32c\_intel polyval\_clmulni polyval\_generic ghash\_clmulni\_intel video ucsi\_acpi hid\_sensor\_hub sha512\_ssse3 hid\_multitouch sha256\_ssse3 sha1\_ssse3 typec\_ucsi cec typec sp5100\_tco nvme\_auth wmi i2c\_hid\_acpi i2c\_hid fuse i2c\_dev  
> Apr 01 14:27:51 joshua kernel: CPU: 13 UID: 0 PID: 91770 Comm: kworker/13:1 Tainted: G W 6.13.7-200.fc41.x86\_64 #1  
> Apr 01 14:27:51 joshua kernel: Tainted: [W]=WARN  
> Apr 01 14:27:51 joshua kernel: Hardware name: Framework Laptop 16 (AMD Ryzen 7040 Series)/FRANMZCP07, BIOS 03.04 07/09/2024  
> Apr 01 14:27:51 joshua kernel: Workqueue: pm pm\_runtime\_work  
> Apr 01 14:27:51 joshua kernel: RIP: 0010:dm\_suspend+0x274/0x2e0 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: Code: 08 31 04 00 e9 66 fe ff ff 41 0f b6 84 24 a0 02 00 00 48 8d 74 24 10 4c 89 ef 4c 89 64 24 10 88 44 24 18 e8 ee 3a 4c 00 eb a2 \<0f\> 0b e9 d7 fd ff ff 48 c7 c7 20 e8 f7 c0 e8 39 86 0f f2 e9 77 ff  
> Apr 01 14:27:51 joshua kernel: RSP: 0018:ffffa640cace3c48 EFLAGS: 00010286  
> Apr 01 14:27:51 joshua kernel: RAX: 0000000000000000 RBX: ffff931f9c000000 RCX: 000000000000000d  
> Apr 01 14:27:51 joshua kernel: RDX: 0000000000000000 RSI: 000000000001629a RDI: ffff931f9c000000  
> Apr 01 14:27:51 joshua kernel: RBP: ffff931f9c0455b8 R08: 0000000000000000 R09: 0000000000000001  
> Apr 01 14:27:51 joshua kernel: R10: 0000000000380002 R11: 00000000ffffffff R12: 0000000000000005  
> Apr 01 14:27:51 joshua kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff931fec533040  
> Apr 01 14:27:51 joshua kernel: FS: 0000000000000000(0000) GS:ffff9326de880000(0000) knlGS:0000000000000000  
> Apr 01 14:27:51 joshua kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033  
> Apr 01 14:27:51 joshua kernel: CR2: 00007f0441962008 CR3: 00000001bb82c000 CR4: 0000000000f50ef0  
> Apr 01 14:27:51 joshua kernel: PKRU: 55555554  
> Apr 01 14:27:51 joshua kernel: Call Trace:  
> Apr 01 14:27:51 joshua kernel:   
> Apr 01 14:27:51 joshua kernel: ? srso\_alias\_return\_thunk+0x5/0xfbef5  
> Apr 01 14:27:51 joshua kernel: ? show\_trace\_log\_lvl+0x255/0x2f0  
> Apr 01 14:27:51 joshua kernel: ? show\_trace\_log\_lvl+0x255/0x2f0  
> Apr 01 14:27:51 joshua kernel: ? amdgpu\_ip\_block\_suspend+0x24/0x40 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: ? dm\_suspend+0x274/0x2e0 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: ? \_\_warn.cold+0x93/0xfa  
> Apr 01 14:27:51 joshua kernel: ? dm\_suspend+0x274/0x2e0 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: ? report\_bug+0xff/0x140  
> Apr 01 14:27:51 joshua kernel: ? handle\_bug+0x58/0x90  
> Apr 01 14:27:51 joshua kernel: ? exc\_invalid\_op+0x17/0x70  
> Apr 01 14:27:51 joshua kernel: ? asm\_exc\_invalid\_op+0x1a/0x20  
> Apr 01 14:27:51 joshua kernel: ? dm\_suspend+0x274/0x2e0 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: ? dm\_suspend+0x3c/0x2e0 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: ? smu\_cmn\_send\_smc\_msg\_with\_param+0x1ec/0x500 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: amdgpu\_ip\_block\_suspend+0x24/0x40 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: amdgpu\_device\_ip\_suspend\_phase1+0x89/0xe0 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: amdgpu\_device\_suspend+0x74/0x170 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: amdgpu\_pmops\_runtime\_suspend+0xb9/0x1a0 [amdgpu]  
> Apr 01 14:27:51 joshua kernel: pci\_pm\_runtime\_suspend+0x67/0x1a0  
> Apr 01 14:27:51 joshua kernel: ? \_\_pfx\_pci\_pm\_runtime\_suspend+0x10/0x10  
> Apr 01 14:27:51 joshua kernel: \_\_rpm\_callback+0x41/0x170  
> Apr 01 14:27:51 joshua kernel: ? \_\_pfx\_pci\_pm\_runtime\_suspend+0x10/0x10  
> Apr 01 14:27:51 joshua kernel: rpm\_callback+0x55/0x60  
> Apr 01 14:27:51 joshua kernel: ? \_\_pfx\_pci\_pm\_runtime\_suspend+0x10/0x10  
> Apr 01 14:27:51 joshua kernel: rpm\_suspend+0xe6/0x5f0  
> Apr 01 14:27:51 joshua kernel: ? srso\_alias\_return\_thunk+0x5/0xfbef5  
> Apr 01 14:27:51 joshua kernel: ? finish\_task\_switch.isra.0+0x99/0x2c0  
> Apr 01 14:27:51 joshua kernel: pm\_runtime\_work+0x98/0xb0  
> Apr 01 14:27:51 joshua kernel: process\_one\_work+0x176/0x330  
> Apr 01 14:27:51 joshua kernel: worker\_thread+0x252/0x390  
> Apr 01 14:27:51 joshua kernel: ? \_\_pfx\_worker\_thread+0x10/0x10  
> Apr 01 14:27:51 joshua kernel: kthread+0xcf/0x100  
> Apr 01 14:27:51 joshua kernel: ? \_\_pfx\_kthread+0x10/0x10  
> Apr 01 14:27:51 joshua kernel: ret\_from\_fork+0x31/0x50  
> Apr 01 14:27:51 joshua kernel: ? \_\_pfx\_kthread+0x10/0x10  
> Apr 01 14:27:51 joshua kernel: ret\_from\_fork\_asm+0x1a/0x30  
> Apr 01 14:27:51 joshua kernel:   
> Apr 01 14:27:51 joshua kernel: —[end trace 0000000000000000]—  
> Apr 01 14:27:51 joshua kernel: ------------[cut here]------------

several additional kernel traces are following, then this:

> **Summary**
>
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706  
> Apr 01 14:28:15 joshua kernel: [drm] PCIE GART of 512M enabled (table at 0x00000081FEB00000).  
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: PSP is resuming…  
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: reserve 0x1300000 from 0x81fc000000 for PSP TMR  
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available  
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available  
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available  
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resuming…  
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x00000035, smu fw if version = 0x00000040, smu fw program = 0, smu fw version = 0x00525c00 (82.92.0)  
> Apr 01 14:28:15 joshua kernel: amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched  
> Apr 01 14:28:16 joshua kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully!

The system then became responsive again at 14:28:30.

I first suspected 6.14 kernels (which I’ve been trying from rc1) as the culprit, but the same problem occurs with 6.13.7. Firmware is up to date from linux-firmware git repo.

@Mario_Limonciello I thought you might have ideas on how to best investigate this issue? Should I report it somewhere else? Thanks for any help!

---

<div class="post-metadata">

**Author:** ![TechPriestNhyk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/techpriestnhyk/32/27853_2.png) [@TechPriestNhyk](https://community.frame.work/u/TechPriestNhyk)\
**Post date:** [April 1, 2025, 3:19pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/2 "2025-04-01T15:19:43Z")

</div>

This could be related to a dGPU suspend issue introduced in 6.13.6 seen here: [Graphics card not available - Framework Laptop 16 / Linux - Framework Community](https://community.frame.work/t/graphics-card-not-available/66269/35)

If you need the device working now, you can roll back to 6.13.5 which multiple users (myself included) have reported as being the last working version.

---

<div class="post-metadata">

**Author:** ![John\_Obscurant](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/john_obscurant/32/22180_2.png) [@John\_Obscurant](https://community.frame.work/u/John_Obscurant)\
**Post date:** [April 1, 2025, 3:49pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/3 "2025-04-01T15:49:05Z")

</div>

Thanks a lot. I am reading the forum regularly but not all posts, so I had not noticed people in that other thread were getting the same errors.  
You are correct that it might have the same cause. Only the symptoms here are different, the dGPU does not effectively disappear (though something is really wrong for a while after suspend/resume)

---

<div class="post-metadata">

**Author:** ![TechPriestNhyk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/techpriestnhyk/32/27853_2.png) [@TechPriestNhyk](https://community.frame.work/u/TechPriestNhyk)\
**Post date:** [April 1, 2025, 3:52pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/4 "2025-04-01T15:52:15Z")

</div>

When I first encountered the issue I didn’t find the thread either despite being active and having searched for it, and I created a duplicate thread (that has since been merged into it) so there’s no shade being thrown from my direction. I’ve noticed that the issue can be a bit inconsistent, sometimes the dGPU will disappear and sometimes it won’t. My situation didn’t line up 100% with what was happening in that thread either, but their fix did fix my issue as well, so I’d say it’s probably worth giving 6.13.5 a shot on your device.

---

<div class="post-metadata">

**Author:** ![John\_Obscurant](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/john_obscurant/32/22180_2.png) [@John\_Obscurant](https://community.frame.work/u/John_Obscurant)\
**Post date:** [April 1, 2025, 4:32pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/5 "2025-04-01T16:32:23Z")

</div>

I have downgraded to 6.13.5, there is no more crash in the system log, but the freeze still happens.

---

<div class="post-metadata">

**Author:** ![Mario\_Limonciello](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/mario_limonciello/32/19277_2.png) [@Mario\_Limonciello](https://community.frame.work/u/Mario_Limonciello)\
**Post date:** [April 2, 2025, 2:02am UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/6 "2025-04-02T02:02:50Z")

</div>

Try this series

> **[\[PATCH 1/2\] drm/amdgpu/mes11: optimize MES pipe FW version fetching - Alex...](https://lore.kernel.org/amd-gfx/20250328130857.4071486-1-alexander.deucher@amd.com/)**

And if it helps you can leave comments here: [https://gitlab.freedesktop.org/drm/amd/-/issues/4083](https://gitlab.freedesktop.org/drm/amd/-/issues/4083)

---

<div class="post-metadata">

**Author:** ![John\_Obscurant](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/john_obscurant/32/22180_2.png) [@John\_Obscurant](https://community.frame.work/u/John_Obscurant)\
**Post date:** [April 2, 2025, 1:18pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/7 "2025-04-02T13:18:25Z")

</div>

Unfortunately my problem is not fixed by this patch ☹

There is no more crash in amdgpu, but the delay is still there. So that crash was probably unrelated to the freezing problem. I’m playing around more trying to find the actual problem …

---

<div class="post-metadata">

**Author:** ![TechPriestNhyk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/techpriestnhyk/32/27853_2.png) [@TechPriestNhyk](https://community.frame.work/u/TechPriestNhyk)\
**Post date:** [April 2, 2025, 1:34pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/8 "2025-04-02T13:34:23Z")

</div>

I’ve seen similar issues when trying to resume from suspend. To be entirely honest, I never found a fix and just stopped using sleep. I only recently started giving it another shot now that I’m on Fedora and it supposedly “works out of the box”. If you narrow the issue down any further I’d be interested.

---

<div class="post-metadata">

**Author:** ![John\_Obscurant](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/john_obscurant/32/22180_2.png) [@John\_Obscurant](https://community.frame.work/u/John_Obscurant)\
**Post date:** [April 2, 2025, 5:14pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/9 "2025-04-02T17:14:32Z")

</div>

I’ll do a clean reinstall when Fedora 42 is released. Then I can see if the problem is also present with a fresh installation and file a better bug report.

It might also be caused by some customisation I did for my local system - I’m using a few special applications so maybe something I did while trying to get those to run is the culprit …

---

<div class="post-metadata">

**Author:** ![John\_Obscurant](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/john_obscurant/32/22180_2.png) [@John\_Obscurant](https://community.frame.work/u/John_Obscurant)\
**Post date:** [April 18, 2025, 8:52am UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/10 "2025-04-18T08:52:55Z")

</div>

I have updated to Fedora 42 now. The issue I’m having is apparently **not** the same as [Graphics card not available](https://community.frame.work/t/graphics-card-not-available/66269).

I have made some new observations though.

- The log shows several of the following errors:

```auto
Apr 18 10:42:27 ****** kernel: xhci_hcd 0000:c4:00.3: Timeout while waiting for setup device command
Apr 18 10:42:27 ****** kernel: usb 2-2: device not accepting address 7, error -62

```

_lsusb -v_ will freeze for 5-30 seconds before showing the information on the usb 2-2 controller. This also provokes another error message in the log as above.

I’m suspecting that the same thing is happening on system resume which would explain the freeze until reaching the lock screen.

The device causing the problems also does not always show in /sys/bus/usb, so it is difficult to get further information. _lsusb -v_ says it is the following:

```auto
Bus 002 Device 002: ID 05e3:0625 Genesys Logic, Inc. USB3.2 Hub

```

I’m suspecting it might be the controller for the dGPU rear USB port?

I’m not using that port for anything. Is it possible to simply disable that device for the moment?

---

<div class="post-metadata">

**Author:** ![John\_Obscurant](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/john_obscurant/32/22180_2.png) [@John\_Obscurant](https://community.frame.work/u/John_Obscurant)\
**Post date:** [April 18, 2025, 9:31am UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/11 "2025-04-18T09:31:16Z")

</div>

More information:  
Disabling the “parent” device manually by

```auto
echo 0 > /sys/bus/usb/devices/usb2/authorized

```

fixes the problem.

//edit:  
I have found a way to do this via a udev rule:

```auto
SUBSYSTEM=="usb", ATTRS{idVendor}=="05e3", ATTRS{idProduct}=="0625", RUN="/bin/sh -c 'echo 0 >/sys/\$devpath/../authorized'"

```

Also, I have no idea what this controller is responsible for. After disabling it, everything still works as normal. I tested that all the following devices are still working: all 6 expansion cards, internal camera + microphone, fingerprint reader, keyboard/macropad, touchpad.

---

<div class="post-metadata">

**Author:** ![AleXutzZu](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/alexutzzu/32/27202_2.png) [@AleXutzZu](https://community.frame.work/u/AleXutzZu)\
**Post date:** [April 25, 2025, 9:22pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/12 "2025-04-25T21:22:54Z")

</div>

I have the same problem when recovering from suspend and this did not fix it for me. I think I’ve started having this issue since Fedora 41 on the later 6.13 kernels.  
I am not sure if another issue I face is related to this one but besides taking a long time to recover, some apps seem broken: taking an eternity to start or not even opening at all. Take for example the Settings app or the Files app.

---

<div class="post-metadata">

**Author:** ![John\_Obscurant](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/john_obscurant/32/22180_2.png) [@John\_Obscurant](https://community.frame.work/u/John_Obscurant)\
**Post date:** [April 28, 2025, 11:00am UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/13 "2025-04-28T11:00:31Z")

</div>

I had similar problems because of the hanging usb driver as well. Did you check whether `lsusb -v` does hang for you as well?

---

<div class="post-metadata">

**Author:** ![AleXutzZu](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/alexutzzu/32/27202_2.png) [@AleXutzZu](https://community.frame.work/u/AleXutzZu)\
**Post date:** [April 28, 2025, 9:11pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/14 "2025-04-28T21:11:53Z")

</div>

It did hang, and applying the fix you provided made it not hang anymore, but it did not fix the issue when putting the laptop in suspend. I don’t think it would have anything to do with running the command directly instead of applying the udev rule.

Some posts suggest the possibility of SSD firmware having a play, something which I don’t exactly know how to test, but it is bothersome as I feel this suspend problem has been on-going for at least 3-4 kernel versions, and I can’t even pinpoint when was the last version that this bug has not manifested on.

EDIT: On further testing it seems that the issue is somewhat resolved, BUT:

- Letting the system go into suspend still seems to break things
- It still takes around 10s to wake up from suspend
- Trying to see available networks is a really bad idea (the display freezes and the cursor barely moves)
- FUSE apps still take a while to start up

---

<div class="post-metadata">

**Author:** ![AleXutzZu](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/alexutzzu/32/27202_2.png) [@AleXutzZu](https://community.frame.work/u/AleXutzZu)\
**Post date:** [May 5, 2025, 12:15pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/15 "2025-05-05T12:15:57Z")

</div>

As of kernel 6.14.4 the problem seems to be gone at least for my system. However, running `lsusb -v` still hangs on that specific device, but it does not seem to affect recovery from suspend. However, after running that command the problem seemed to be the time it takes to reach the suspend state. Running the fix provided above fixed that as well but from my initial testing it was not needed until I ran `lsusb -v`.

---

<div class="post-metadata">

**Author:** ![TenPin](https://avatars.discourse-cdn.com/v4/letter/t/da6949/32.png) [@TenPin](https://community.frame.work/u/TenPin)\
**Post date:** [May 5, 2025, 6:08pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/16 "2025-05-05T18:08:33Z")

</div>

Running `lsusb -v` as root also pauses for me at:

```auto
Bus 002 Device 002: ID 05e3:0625 Genesys Logic, Inc. USB3.2 Hub
Couldn't open device, some information will be missing

```

kernel 6.14.4

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/1X/64c81a89f963ddb07633887baceb642a4b056046.png) [@system](https://community.frame.work/u/system)\
**Post date:** [November 1, 2025, 6:09pm UTC](https://community.frame.work/t/workaround-suspend-resume-taking-20s-to-recover-edit-usb-xhci-host-controller-problem/66891/17 "2025-11-01T18:09:05Z")

</div>

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.
