Recently, my ThinkPad T570 suddenly developed a rather troublesome issue under Ubuntu:
After the computer enters suspend, the screen stays black when waking up, and I ultimately have no choice but to long-press the power button to force a shutdown.
In the past, when I paused using the computer, I would often just suspend it. When I came back next time, a quick press of the power button would let me continue my previous work. But on July 30, 2026, this usage pattern started failing consecutively.
On that day, at least twice during normal use, the display failed to recover after suspend. Later, after completing a system update, I proactively tested it once more, and the issue was still reproducible.
Initially, I wanted to continue troubleshooting the kernel, Intel i915, NVIDIA, PRIME, and display recovery issues.
But after troubleshooting for a while, I reassessed my actual needs:
I don’t necessarily need true “suspend.”
I just want to avoid shutting down the computer when I step away, so that when I return, I can resume Firefox, VS Code, the terminal, and other already open work.
So I ultimately adopted a simpler approach:
Completely bypass suspend for now: disable automatic suspend, disable suspend on lid close, and keep only screen lock and automatic screen blank.
The final physical lid close test passed.
1. The initial problem: screen fails to recover after suspend
My computer is a Lenovo ThinkPad T570.
The current primary environment is:
Linux kernel: 7.0.0-28-generic; PRIME mode: on-demand; Intel integrated graphics: HD Graphics 620; Intel driver: i915; NVIDIA discrete graphics: GeForce 940MX; NVIDIA driver: 580.173.02.
After the issue occurred, the general sequence was:
Normal computer use → enter suspend → briefly press power button later → screen does not light up → press a few more times → still black screen → finally had to long-press power button → force shutdown → power back on.
At the time, it was easy to get an illusion:
After pressing the power button, the computer did not recover from suspend at all.
But subsequent log analysis showed that the actual situation was not like that.
2. The system actually woke up; only the screen failed to recover
After checking the previous boot log, I could see that the system normally entered deep suspend:
PM: suspend entry (deep)
And after attempting to wake up, I could also see:
ACPI: PM: Low-level resume complete
ACPI: PM: Waking up from system sleep state S3
Followed by:
System returned from sleep operation 'suspend'.
PM: suspend exit
The NVIDIA recovery process also executed normally:
Starting nvidia-resume.service
...
Finished nvidia-resume.service
Even Wi-Fi reconnected successfully and obtained an IP address again.
So the more accurate situation was actually:
Computer enters suspend → press power button to wake → low-level power management recovers successfully → NVIDIA recovery process completes → network reconnects → but the screen fails to recover display.
In other words:
The computer actually woke up; only the display recovery encountered a problem.
This also explains why, from my external observation, it felt like “briefly pressing the power button had absolutely no effect.”
3. The same issue occurred multiple times in one day
One relatively complete timeline was:
Entered deep suspend on July 29 at 22:33 → attempted to wake up on July 30 at 10:57 → system completed recovery → screen remained black → long-pressed power button to force shutdown around 11:00 → powered back on around 11:01.
Another occurrence happened around noon that day:
Entered deep suspend around 12:33 → might have briefly pressed the power button once around 12:56 → system had already recovered → screen remained black → came back around 13:30 and briefly pressed the power button a few more times → still no display → long-pressed power button to force shutdown → powered back on.
This already seemed less like an isolated incident.
4. Intel i915 display anomalies also appeared in the logs
Upon further inspection, I also found that the Intel i915 driver repeatedly produced:
i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A
And:
workqueue: i915_hpd_poll_init_work [i915]
hogged CPU for >10000us
Additionally, before entering suspend, GNOME also showed:
Cursor update failed: drmModeAtomicCommit: 无效的参数
Moreover, this similar situation did not just happen once.
So at present, it can at least be confirmed that:
The failure leans more toward graphics display recovery after suspend, rather than the power button itself being unable to wake the computer.
However, I ultimately did not dig deeper into whether the Linux kernel, Intel i915, NVIDIA, or some layer in the hybrid graphics display chain was causing the black screen.
Because I later realized that there was actually no need to continue making extensive system modifications for this issue.
5. First performed a normal system update
Before considering modifying kernel and graphics card configurations, I first performed a normal update:
sudo apt update
sudo apt upgrade
At the time, the system indicated that 75 packages could be upgraded:
Upgraded 75 packages, installed 2, removed 0.
These included some components related to the desktop, display, and firmware, such as:
These included gnome-shell, gdm3, gnome-session, ubuntu-session, linux-firmware-intel-graphics, linux-firmware-nvidia-graphics, and fwupd.
This update did not change the current kernel, nor did it change the NVIDIA driver version.
After completing the update and rebooting, I confirmed again:
echo "当前内核：$(uname -r)"
echo "PRIME 模式：$(prime-select query)"
nvidia-smi | head -n 10
The result was still:
当前内核：7.0.0-28-generic
PRIME 模式：on-demand
NVIDIA Driver Version: 580.173.02
Afterwards, I executed “Suspend” again via the Ubuntu system menu.
The result:
Still failed.
The screen went black again, and ultimately I still had to force a shutdown.
So it can at least be confirmed that:
This routine package update did not resolve the black screen issue after suspend.
6. Reassessing needs: I don’t necessarily need suspend
After troubleshooting to this point, I started to reconsider:
Why exactly do I need suspend?
The answer is actually quite simple.
What I truly want to achieve on a daily basis is:
Pause using the computer → no need to close Firefox, VS Code, and the terminal → no need to shut down → come back a while later or even the next day → continue previous work.
Whether the computer actually enters Suspend during this time is not actually important to me.
Moreover, this T570 currently has no battery and is always connected to power.
Therefore:
Having the computer continue running normally with only the screen turned off is perfectly acceptable to me.
This also directly bypasses the currently problematic path of “suspend → recover → display recovery fails → black screen.”
Thus, I decided to temporarily stop modifying the kernel, switching PRIME modes, or adjusting the NVIDIA driver, and instead completely disable the suspend feature.
7. Disabling automatic suspend
First, I went to:
Settings → Power → Power Saver
In my original settings:
Automatic screen blank: enabled, 5-minute delay; Automatic suspend: enabled on battery power, 15 minutes; disabled when plugged in.
Because my computer no longer has a battery, the “When plugged in: disabled” setting is actually the one currently in effect.
However, just to be safe, I also turned off automatic suspend for “On battery power.”
The final settings became:
Automatic screen blank: enabled, 5 minutes; Automatic suspend: disabled on battery power, disabled when plugged in.
Two concepts need to be distinguished here: automatic screen blank ≠ automatic suspend. I still keep the 5-minute automatic screen blank.
That is to say:
Leave the computer → no operation for 5 minutes → screen turns off → computer continues running → will not enter suspend due to excessive idle time.
This is already sufficient for most scenarios where I temporarily step away from the computer.
8. Disabling automatic suspend is not enough; lid close is another entry point
There is still another issue next:
What happens after closing the laptop screen?
Disabling “automatic suspend” only resolves suspends caused by prolonged inactivity.
However, closing the laptop lid is another independent action.
What I truly want to achieve is:
Working → close the T570 screen → computer continues running → reopen it a while later → directly continue working.
So the lid close behavior also needs to be handled separately.
9. The lid close option can no longer be found in GNOME Tweaks
My computer already has GNOME Tweaks installed.
Initially, I also tried looking here for a toggle like “Suspend when laptop lid is closed.”
But this item is no longer visible in the current version of the Tweaks interface.
So I ultimately chose to configure the lid close behavior directly via systemd.
10. Disabling suspend on lid close via systemd
Execute:
sudo mkdir -p /etc/systemd/logind.conf.d
sudo tee /etc/systemd/logind.conf.d/99-lid-no-suspend.conf >/dev/null <<'EOF'
[Login]
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
EOF
echo "========== 合盖配置 =========="
cat /etc/systemd/logind.conf.d/99-lid-no-suspend.conf
Output:
========== 合盖配置 ==========
[Login]
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
ignoreHere, HandleLidSwitch=ignore means normal lid close does not trigger suspend; HandleLidSwitchExternalPower=ignore means closing the lid while plugged in also does not trigger suspend; and HandleLidSwitchDocked=ignore similarly sets the lid close action to be ignored in the Docked state.
For my actual situation, HandleLidSwitchExternalPower=ignore is the most important, because this T570 is currently always connected to power.
11. The first command-line reboot was also blocked
After configuration, I originally just executed:
sudo reboot
But the result was:
Call to Reboot failed: Operation denied due to active block inhibitor
This meant that a session or program in the system was preventing a direct reboot at the time.
I did not use a force parameter to bypass it, but instead normally executed “Restart” directly through the Ubuntu graphical interface.
This allows the desktop environment to properly handle the current session first before completing the reboot.
12. Confirming after reboot whether the lid close configuration actually took effect
After logging back into the system, I executed:
echo "========== 合盖处理配置 =========="
systemd-analyze cat-config systemd/logind.conf \
| grep -E 'HandleLidSwitch'
The result:
#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
Special attention needs to be paid here to the difference between the two sets of configurations.
The preceding #HandleLidSwitch=suspend, #HandleLidSwitchExternalPower=suspend, and #HandleLidSwitchDocked=ignore all have #; they are just comments in the default configuration and do not take effect directly.
What really needs attention are the final HandleLidSwitch=ignore, HandleLidSwitchExternalPower=ignore, and HandleLidSwitchDocked=ignore. This shows that the /etc/systemd/logind.conf.d/99-lid-no-suspend.conf created just now has been correctly read by the system.
13. Conducting the final physical lid close test
After both configuration and reboot were complete, I did not test “suspend” again, which had already failed consecutively multiple times.
Instead, I directly tested the usage scenario I truly wanted:
Normal computer use → close the T570 screen → wait about 30 seconds → reopen the screen.
The final result:
Test passed.
The computer did not enter suspend.
After reopening the screen, I was able to continue my previous work.
In other words, the following has now been achieved:
Using the computer → temporarily step away → lock screen / close lid → screen turns off → computer itself continues running → return after a while → reopen the screen → continue working.
This is exactly the effect I truly need.
14. My final configuration now
Currently, I keep automatic screen blank enabled, set to 5 minutes.
Automatic suspend is completely disabled: disabled on battery power, and also disabled when plugged in.
At the same time, HandleLidSwitch=ignore, HandleLidSwitchExternalPower=ignore, and HandleLidSwitchDocked=ignore are set.
So there are now two daily usage methods.
When stepping away for a short time:
Lock screen → automatic screen blank after 5 minutes → computer continues running → unlock upon return.
When not using it for a longer period, I can also:
Close the lid → computer continues running → reopen it → continue previous work.
No need to shut down frequently.
And no need to risk a black screen after suspend, ultimately being forced to do a hard shutdown.
15. Why I ultimately did not roll back the kernel or switch graphics card modes
During troubleshooting, I also found that the computer retained two kernel versions, 7.0.0-27-generic and 7.0.0-28-generic.
I had previously considered rolling back to 7.0.0-27, or switching PRIME from on-demand to Intel; I could have also continued testing s2idle, and further investigating which layer among i915, DRM, NVIDIA, GNOME, and ACPI was causing the display recovery to fail.
But all these operations would mean continuing to expand the troubleshooting scope.
And my actual goal was merely:
After pausing use of the computer, not having to shut down and power on again.
This goal has now been achieved through a simpler solution.
So I ultimately decided:
To temporarily stop further modifying the kernel, graphics card, and boot parameters.
After future system updates, I can occasionally test true suspend again.
If I find one day that “suspend → briefly press power button → screen recovers normally” has become stable and functional, I will then consider re-enabling the suspend feature.
16. This solution also has a trade-off: the computer does not hibernate after lid close
It should be specifically noted: “closing the lid” no longer equals “suspend.”
After closing the screen, the computer remains in a normal running state.
That is to say, the CPU still runs, memory keeps working, Wi-Fi stays connected, background tasks continue to execute, and terminal programs may still keep running.
So power consumption is definitely higher than with true suspend.
However, my T570 already has no battery, is always plugged in, and is mainly used on a desk, so this trade-off is currently acceptable.
There is actually an added benefit:
Tasks executing in the background will not be interrupted by suspend.
But please note:
After closing the lid, do not directly stuff the still-running computer into a laptop bag or other enclosed space.
Because the computer has not actually hibernated, it will still generate heat.
17. How to restore default suspend on lid close in the future
This solution did not modify the original systemd configuration file, but instead created 99-lid-no-suspend.conf inside /etc/systemd/logind.conf.d/.
So restoring it is also very simple.
After the suspend issue is resolved in the future, you can execute:
sudo rm /etc/systemd/logind.conf.d/99-lid-no-suspend.conf
Then restart the computer normally.
Afterwards, as needed, in:
Settings → Power
re-enable automatic suspend.
This way, the original usage method can be restored.
18. Final conclusion
Initially, this problem appeared to be:
ThinkPad T570 fails to wake up after suspend.
But combined with the system logs, the reality is closer to:
Entering suspend normally → power button successfully triggers recovery → low-level recovery process completes → NVIDIA recovery completes → network recovers → display does not recover normally → screen stays black.
During this time, display-related anomalies such as i915, drmModeAtomicCommit, and Atomic update failure were indeed observed.
However, after a routine system update, the issue remained reproducible.
Ultimately, I did not continue tinkering with the kernel and graphics card just for the sake of “having to restore suspend functionality.”
Because upon reassessing my needs, I found that:
What I truly need is to not have to shut down after stepping away from the computer, and to be able to continue working when I return, rather than necessarily making the computer enter suspend.
Thus, the final solution became:
Disable automatic suspend + disable suspend on lid close + keep automatic screen blank.
Then I conducted a physical test:
Close the lid → wait about 30 seconds → reopen → normally continue working.
Test passed.
At least for now, this has solved my most practical issue:
No longer having to frequently endure a black screen followed by a long power button press to force a shutdown just because I paused using the computer.
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复