I’m new to Linux, recently got T480 and installed Fedora Workstation 44 because I used mint on T470s and didn’t like the UX/UI and interface design.
Absolutely love everything but it has some weird power management (or Thunderbolt driver) issue going on with my T480 (It’s i5-8350U / 32GB RAM / 500SSD)
When I close the lid, it takes 10-15 seconds to see the log in page and I cannot find the specific reason or how to fix it.
Did anyone have the same problem on T480 or in general? Here are some things I’ve tried out but really I cannot find a reason or fix. I tried Fedora KDE and had the same issue.
What’s been ruled out (extensively tested):
Kernel version (same behavior on two different kernels)
PCIe ASPM settings, forcing power/control on the Thunderbolt PCI chain
mem_sleep mode (deep vs s2idle)
Bluetooth (disabling it, autosuspend tweaks) — contributes a small ~2s firmware reload but isn’t the main delay
NVMe drive — investigated and discounted
Unbinding the xHCI driver entirely — this removes a recurring xHC error in resume, USBSTS 0x401, Reinit message tied to the Intel JHL6240 Thunderbolt controller, but the ~10–13s delay persists even without it, proving that error isn’t the actual cause
Thunderbolt BIOS Assist Mode (tested both settings) — no effect
Confirmed the hardware itself isn’t broken, since Linux Mint on the same machine suspends/resumes normally
I assume you meant when you open the lid, or resume from suspend, it takes a while to see the login screen?
You should post the kernel log so folks can take a look and have a better idea of what to suggest. Do a fresh reboot, recreate the issue, then post the dmesg output.
I’m not sure this is the way to share, apologies that I’m very new to this without any knowledge.
[Sat Aug 29 16:21:34 2026] lockdown_is_locked_down: 2 callbacks suppressed
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] wlp3s0: deauthenticating from d0:db:b7:c7:89:dd by local choice (Reason: 3=DEAUTH_LEAVING)
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:34 2026] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sat Aug 29 16:21:35 2026] PM: suspend entry (deep)
[Sat Aug 29 16:21:35 2026] Filesystems sync: 0.027 seconds
[Sat Aug 29 16:21:35 2026] Freezing user space processes
[Sat Aug 29 16:21:35 2026] Freezing user space processes completed (elapsed 0.001 seconds)
[Sat Aug 29 16:21:35 2026] OOM killer disabled.
[Sat Aug 29 16:21:35 2026] Freezing remaining freezable tasks
[Sat Aug 29 16:21:35 2026] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[Sat Aug 29 16:21:35 2026] printk: Suspending console(s) (use no_console_suspend to debug)
[Sat Aug 29 16:21:36 2026] e1000e: EEE TX LPI TIMER: 00000011
[Sat Aug 29 16:21:36 2026] PM: suspend devices took 0.198 seconds
[Sat Aug 29 16:21:36 2026] ACPI: EC: interrupt blocked
[Sat Aug 29 16:21:36 2026] ACPI: PM: Preparing to enter system sleep state S3
[Sat Aug 29 16:21:36 2026] ACPI: EC: event blocked
[Sat Aug 29 16:21:36 2026] ACPI: EC: EC stopped
[Sat Aug 29 16:21:36 2026] ACPI: PM: Saving platform NVS memory
[Sat Aug 29 16:21:36 2026] Disabling non-boot CPUs …
[Sat Aug 29 16:21:36 2026] smpboot: CPU 7 is now offline
[Sat Aug 29 16:21:36 2026] smpboot: CPU 6 is now offline
[Sat Aug 29 16:21:36 2026] smpboot: CPU 5 is now offline
[Sat Aug 29 16:21:36 2026] smpboot: CPU 4 is now offline
[Sat Aug 29 16:21:36 2026] smpboot: CPU 3 is now offline
[Sat Aug 29 16:21:36 2026] smpboot: CPU 2 is now offline
[Sat Aug 29 16:21:36 2026] smpboot: CPU 1 is now offline
[Sat Aug 29 16:21:36 2026] ACPI: PM: Low-level resume complete
[Sat Aug 29 16:21:36 2026] ACPI: EC: EC started
[Sat Aug 29 16:21:36 2026] ACPI: PM: Restoring platform NVS memory
[Sat Aug 29 16:21:36 2026] Enabling non-boot CPUs …
[Sat Aug 29 16:21:36 2026] smpboot: Booting Node 0 Processor 1 APIC 0x2
[Sat Aug 29 16:21:36 2026] CPU1 is up
[Sat Aug 29 16:21:36 2026] smpboot: Booting Node 0 Processor 2 APIC 0x4
[Sat Aug 29 16:21:36 2026] CPU2 is up
[Sat Aug 29 16:21:36 2026] smpboot: Booting Node 0 Processor 3 APIC 0x6
[Sat Aug 29 16:21:36 2026] CPU3 is up
[Sat Aug 29 16:21:36 2026] smpboot: Booting Node 0 Processor 4 APIC 0x1
[Sat Aug 29 16:21:36 2026] CPU4 is up
[Sat Aug 29 16:21:36 2026] smpboot: Booting Node 0 Processor 5 APIC 0x3
[Sat Aug 29 16:21:36 2026] CPU5 is up
[Sat Aug 29 16:21:36 2026] smpboot: Booting Node 0 Processor 6 APIC 0x5
[Sat Aug 29 16:21:36 2026] CPU6 is up
[Sat Aug 29 16:21:36 2026] smpboot: Booting Node 0 Processor 7 APIC 0x7
[Sat Aug 29 16:21:36 2026] CPU7 is up
[Sat Aug 29 16:21:36 2026] ACPI: PM: Waking up from system sleep state S3
[Sat Aug 29 16:21:36 2026] ACPI: EC: interrupt unblocked
[Sat Aug 29 16:21:36 2026] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io,decodes=io:owns=mem
[Sat Aug 29 16:21:36 2026] ACPI: EC: event unblocked
[Sat Aug 29 16:21:36 2026] nvme nvme0: D3 entry latency set to 8 seconds
[Sat Aug 29 16:21:36 2026] nvme nvme0: 8/0/0 default/read/poll queues
[Sat Aug 29 16:21:36 2026] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd
[Sat Aug 29 16:21:36 2026] usb 1-8: reset high-speed USB device number 3 using xhci_hcd
[Sat Aug 29 16:21:36 2026] usb 1-7: reset full-speed USB device number 2 using xhci_hcd
[Sat Aug 29 16:21:37 2026] PM: resume devices took 0.714 seconds
[Sat Aug 29 16:21:37 2026] Bluetooth: hci0: Bootloader revision 0.0 build 26 week 38 2015
[Sat Aug 29 16:21:37 2026] Bluetooth: hci0: Device revision is 16
[Sat Aug 29 16:21:37 2026] Bluetooth: hci0: Secure boot is enabled
[Sat Aug 29 16:21:37 2026] Bluetooth: hci0: OTP lock is enabled
[Sat Aug 29 16:21:37 2026] Bluetooth: hci0: API lock is enabled
[Sat Aug 29 16:21:37 2026] OOM killer enabled.
[Sat Aug 29 16:21:37 2026] Bluetooth: hci0: Debug lock is disabled
[Sat Aug 29 16:21:37 2026] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[Sat Aug 29 16:21:37 2026] Restarting tasks: Starting
[Sat Aug 29 16:21:37 2026] Restarting tasks: Done
[Sat Aug 29 16:21:37 2026] efivarfs: resyncing variable state
[Sat Aug 29 16:21:37 2026] efivarfs: finished resyncing variable state
[Sat Aug 29 16:21:37 2026] random: crng reseeded on system resumption
[Sat Aug 29 16:21:37 2026] Bluetooth: hci0: Found device firmware: intel/ibt-12-16.sfi
[Sat Aug 29 16:21:39 2026] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Waiting for firmware download to complete
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Firmware loaded in 2118954 usecs
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Waiting for device to boot
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Device booted in 13069 usecs
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-12-16.ddc
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Applying Intel DDC parameters completed
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Firmware revision 0.1 build 19 week 44 2021
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Reading supported features failed (-16)
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: Error reading debug features
[Sat Aug 29 16:21:39 2026] Bluetooth: hci0: HCI LE Coded PHY feature bit is set, but its usage is not supported.
[Sat Aug 29 16:21:39 2026] Bluetooth: MGMT ver 1.23
[Sat Aug 29 16:21:47 2026] PM: suspend exit
[Sat Aug 29 16:21:47 2026] e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Down
[Sat Aug 29 16:21:50 2026] wlp3s0: authenticate with d0:db:b7:c7:89:dd (local address=32:39:40:9d:6f:43)
[Sat Aug 29 16:21:50 2026] wlp3s0: send auth to d0:db:b7:c7:89:dd (try 1/3)
[Sat Aug 29 16:21:50 2026] wlp3s0: authenticated
[Sat Aug 29 16:21:50 2026] wlp3s0: associate with d0:db:b7:c7:89:dd (try 1/3)
[Sat Aug 29 16:21:50 2026] wlp3s0: RX AssocResp from d0:db:b7:c7:89:dd (capab=0x1011 status=0 aid=29)
[Sat Aug 29 16:21:50 2026] wlp3s0: associated
[Sat Aug 29 16:21:50 2026] wlp3s0: Limiting TX power to 36 (36 - 0) dBm as advertised by d0:db:b7:c7:89:dd
I am no expert but your bluetooth device is the main problem. It takes 8 seconds to finally come up properly while the wifi card takes another 3 seconds. The wifi card is fine but takes another 3 seconds before its linked. This is more a router issue. I am assuming you run DHCP. On modern routers you can leave them on DHCP but bind the MAC address of the Laptop to the Router. So the Router
will always give the same IP address in the moment it sees your Laptop.
The S3 state is defined as a low wake-latency sleep state. From the software viewpoint, this state is functionally the same as the S2 state. The operational difference is that some Power Resources that may have been left ON in the S2 state may not be available to the S3 state. As such, some devices may be in a lower power state when the system is in S3 state than when the system is in the S2 state. Similarly, some device wake events can function in S2 but not S3.
None of this so far is really helping. So lets do a comparison. On my Laptop (which is fully updated) I use the S2 state. In that state it is completely cold. Here is a log of how long it takes mine to wake up from opening the Lid.
[Mon Aug 31 07:58:12 2026] PM: suspend exit
[Mon Aug 31 07:58:12 2026] usb 3-4.1: reset full-speed USB device number 8 using xhci_hcd
[Mon Aug 31 07:58:12 2026] usb 3-4.1: reset full-speed USB device number 8 using xhci_hcd
[Mon Aug 31 07:58:15 2026] wlp192s0: authenticate with 3c:7c:3f:54:5d:84 (local address=d2:95:b3:d2:0a:ad)
[Mon Aug 31 07:58:15 2026] wlp192s0: send auth to 3c:7c:3f:54:5d:84 (try 1/3)
[Mon Aug 31 07:58:15 2026] wlp192s0: authenticated
[Mon Aug 31 07:58:15 2026] wlp192s0: associate with 3c:7c:3f:54:5d:84 (try 1/3)
[Mon Aug 31 07:58:15 2026] wlp192s0: RX AssocResp from 3c:7c:3f:54:5d:84 (capab=0x1011 status=0 aid=26)
[Mon Aug 31 07:58:15 2026] wlp192s0: associated
[Mon Aug 31 07:58:15 2026] wlp192s0: Limiting TX power to 30 (30 - 0) dBm as advertised by
Ignore the day and date as it is always a day ahead in these logs for some silly reason.
The point is that mine is up and running in 3 seconds from opening the lid and seeing the Password screen.
So may be try to use the S2 state for suspend and see how long it takes from there to wake up.
In S2 mine is stone cold.
I have done a bit of research and despite using AI I have tested these commands…so they work.
Your main problem is the Bluetooth driver during S3.
So what you can do is stop Bluetooth only from going into suspend and see if this is the best roundabout fix for you. This can always be easily reversed..so no harm done if you don’t like it.
In Terminal enter:
sudo kernelstub -a "btusb.enable_autosuspend=n"
The =n stands for not entering S3 for the Bluetooth.
You have to reboot your laptop after applying the command and then try and see if this makes an acceptable difference for you. Leave it in the Suspend state for a while and see if it works, then overnight maybe before putting it in suspends leave your Laptop on Battery and see how much % you lost after multiple hours.
To put it back (if this is no good for you), simply do: sudo kernelstub -a "btusb.enable_autosuspend=y"
Sorry for using AI here too but I thought this summarise things I have tried despite being a beginner and don’t really understand much. I really just want it to work and not sure why I am having so much problem with this issue and just cannot fix.
I also tried Ubuntu and issue is still happening. So I suspect something power management / or driver management issue? I don’t know why mint works and Fedora workstation 44, KDE and Ubuntu failed to work in this situation. Here are things I’ve tried so far:
Thanks for the suggestion — I actually already tested this (via /etc/modprobe.d/btusb.conf with enable_autosuspend=0, same setting kernelstub would apply, plus fully powering Bluetooth off before suspend with bluetoothctl power off). Neither changed the delay.
To save people re-suggesting things, here’s what’s been ruled out so far on this T480 (Fedora 44, kernel 7.1.9):
pcie_aspm=off
Forcing power/control=on on the Thunderbolt PCIe chain (04:00.0, 05:xx.0, 06:00.0, 3c:00.0)
mem_sleep deep vs s2idle
Kernel 6.19 vs 7.1 (same result on both)
Unbinding xhci_hcd from 3c:00.0 entirely (removes the USBSTS 0x401 error, delay unchanged)
Bluetooth fully powered off before suspend, and btusb.enable_autosuspend=0
NVMe D3 latency message — investigated, looks like a red herring
Thunderbolt BIOS Assist Mode enabled/disabled — no difference
The actual delay isn’t device resume — that consistently completes in well under a second (PM: resume devices took 0.7xx seconds). It’s a silent gap of ~8-10 seconds after that line and after Bluetooth finishes reinitializing, before PM: suspend exit is logged. Nothing at all gets written to the kernel log during that window:
16:21:39 Bluetooth: MGMT ver 1.23 <- BT done
... 8s of nothing logged ...
16:21:47 PM: suspend exit
Notably this happens on Fedora GNOME, Fedora KDE, and Ubuntu on the same hardware — but not on Mint. Mint uses TLP by default; Fedora/Ubuntu use power-profiles-daemon, which is the most obvious shared difference so far, though not confirmed as the cause yet.
Next step I’m trying is turning on /sys/power/pm_print_times and /sys/power/pm_debug_messages before a suspend cycle, since that should log per-device callback durations and finally name whatever’s actually blocking the return from suspend() during that gap, instead of inferring it from silence. Will post results once I’ve got a clean capture.