You are not logged in.
Hello dear Arch community.
I have two different laptops, Lenovo and Dell, with Arch Linux running on those and they both have the same issue: they always resume with a black screen after being suspended.
I had a look several times at the Arch wiki to try to solve the issue.
But my attempts failed.
Initially, I only had the issue on my Dell laptop (for months), but for a week my Lenovo laptop has also the same issue.
Since I am not comfortable to attempt alone anything else, I humbly query your precious help.
I definitely need help to diagnosis what's exactly happening.
Here is the information I can already provide:
- Lenovo ThinkPad P1 Gen 3, with Intel® Core™ i7-10750H × 12 & Quadro T2000 with Max-Q Design, using firmware N2VET46W (1.31 ) and kernel Linux 6.9.5-arch1-1.
- Dell Inc. Precision M4800, wth Intel® Core™ i7-4800MQ x 8 & QuadroK1100M, using firmware A03 and kernel Linux 6.9.5-arch1-1.
Thanks in advance.
Offline
Is this S3 ("deep") or s2idle?
https://wiki.archlinux.org/title/Power_ … end_method
Do the systems still respond to an ICMP request (ping) and/or can you ssh into them?
Is this also an issue when only booting the multi-user.target (in doubt along "nomodeset")?
Can you reboot the system from the "black screen" using the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) (nb. that you've to explicitly enable that first!)
Since it's both nvidia, do you https://wiki.archlinux.org/title/NVIDIA … er_suspend ?
Offline
Greetings!
This is also happening to me after a recent update. Using Framework with Intel i7-1165G7 Gen11 graphics (no external), and I use xfce4. On 6.9.7-arch1-1 and have been updating for several days hoping this goes away.
I use [deep] always generally, as I have issues with overheating in my backpack and battery drain on [s2idle].
Some observations:
The system appears to be running behind the black screen. I see things happening in the journal and I can see my power button presses.
Cannot get the system to respond at all to any keyboard combo (ctrl+alt+del, ctrl+alt+F2, typing my password - definitely feel like the login screen is not being loaded) or lid closing. The display stays lit and black, and it does not go back into suspended mode.
The only solution for me so far has been to hold down the power button for hard power off.
I can do my best to give any debug attempts (multi-user / nomodeset whatever booting), but hopefully this evidence helps narrow the issue down.
Thought maybe it could have something to do with this "fastboot" thing? I'm not sure exactly what my kernel version was before experiencing this last week or so, but saw something about 6.9 linking to some intel related change in the kernel:
https://wiki.archlinux.org/title/intel_ … s#Fastboot
https://git.kernel.org/pub/scm/linux/ke … eaebc06f65
Last edited by mikelago (2024-07-03 01:13:17)
Offline
The OP uses an nvidia GPU, though.
Does the LTS kernel exhibit the same behavior?
Offline
So far so good (no black screen on suspend resume) with lts kernel for me
Offline
Okay, so it happened again today with linux-lts kernel. I *feel* like it wasn't happening as much as with the latest linux kernel at least, but maybe it's the workload. I'll try to experiment.
Posting some journal ctl logs below just in case that can help.
When opening lid (it seems strange to me that there are log messages about freezing / turning off things here, since the computer is definitely in [deep] sleep before these timestamps, which are all the same as the first lid open timestamp) :
kernel: Freezing user space processes
kernel: Freezing user space processes completed (elapsed 0.002 seconds)
kernel: OOM killer disabled.
kernel: Freezing remaining freezable tasks
kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
kernel: printk: Suspending console(s) (use no_console_suspend to debug)
kernel: ACPI: EC: interrupt blocked
kernel: ACPI: PM: Preparing to enter system sleep state S3
kernel: ACPI: EC: event blocked
kernel: ACPI: EC: EC stopped
kernel: ACPI: PM: Saving platform NVS memory
kernel: Disabling non-boot CPUs ...
kernel: smpboot: CPU 1 is now offline
kernel: smpboot: CPU 2 is now offline
kernel: smpboot: CPU 3 is now offline
kernel: smpboot: CPU 4 is now offline
kernel: smpboot: CPU 5 is now offline
kernel: smpboot: CPU 6 is now offline
kernel: smpboot: CPU 7 is now offline
kernel: ACPI: PM: Low-level resume complete
kernel: ACPI: EC: EC started
kernel: ACPI: PM: Restoring platform NVS memory
kernel: Enabling non-boot CPUs ...
kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
kernel: CPU1 is up
kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4
kernel: CPU2 is up
kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6
kernel: CPU3 is up
kernel: smpboot: Booting Node 0 Processor 4 APIC 0x1
kernel: CPU4 is up
kernel: smpboot: Booting Node 0 Processor 5 APIC 0x3
kernel: CPU5 is up
kernel: smpboot: Booting Node 0 Processor 6 APIC 0x5
kernel: CPU6 is up
kernel: smpboot: Booting Node 0 Processor 7 APIC 0x7
kernel: CPU7 is up
kernel: ACPI: PM: Waking up from system sleep state S3
kernel: ACPI: EC: interrupt unblocked
kernel: ACPI: EC: event unblocked
kernel: nvme nvme0: Shutdown timeout set to 10 seconds
kernel: nvme nvme0: 8/0/0 default/read/poll queues
kernel: usb 3-4: reset full-speed USB device number 2 using xhci_hcd
kernel: ish-hid {**}: [hid-ish]: enum_devices_done OK, num_hid_devices=1
kernel: usb 3-7: reset high-speed USB device number 3 using xhci_hcd
kernel: mei_hdcp 0000:00:16.0-**: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
kernel: mei_pxp 0000:00:16.0-**: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
kernel: OOM killer enabled.
iwd[498]: Received Deauthentication event, reason: 3, from_ap: false
iwd[498]: event: disconnect-info, reason: 3
iwd[498]: event: state, old: connected, new: disconnected
iwd[498]: event: state, old: disconnected, new: autoconnect_quick
systemd-logind[501]: Lid opened.
kernel: Restarting tasks ... done.
kernel: random: crng reseeded on system resumption
kernel: usb 3-9: USB disconnect, device number 7
systemd-sleep[16959]: System returned from sleep operation 'suspend'.
bluetoothd[7884]: Controller resume with wake event 0x0
systemd[1]: systemd-suspend.service: Deactivated successfully.
kernel: PM: suspend exit
systemd[1]: Finished System Suspend.
systemd[1]: Stopped target Sleep.
systemd[1]: Reached target Suspend.
systemd-logind[501]: Operation 'suspend' finished.
systemd[1]: Stopped target Suspend.
kernel: usb 3-9: new full-speed USB device number 9 using xhci_hcd
kernel: usb 3-9: New USB device found, **
kernel: usb 3-9: New USB device strings: **
kernel: usb 3-9: Product: ** USB2.0 MISC
mtp-probe[17015]: checking bus 3, device 9: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-9"
mtp-probe[17015]: bus: 3, device: 9 was not an MTP device
mtp-probe[17016]: checking bus 3, device 9: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-9"
mtp-probe[17016]: bus: 3, device: 9 was not an MTP device
iwd[498]: event: connect-info,
iwd[498]: event: state, old: connecting (auto), new: connected
After Opening Lid:
systemd-logind[501]: Power key pressed short.
systemd-logind[501]: Lid closed.
systemd-logind[501]: Lid opened.
systemd-logind[501]: Power key pressed short.
iwd[498]: event: roam-scan,
systemd-logind[501]: Power key pressed short.
systemd-logind[501]: Power key pressed short.
systemd-logind[501]: Power key pressed short.
kernel: ACPI Error: No installed handler for fixed event - PowerButton (2), disabling (20230628/evevent-255)
-- Boot
Offline
It very much looks like the system wakes up an you trigger a reboot w/ a short power key press (which isn't a hard reboot)
=> Please post your complete system journal for the boot, eg.
sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st
for the previous ("-1") one.
Offline
The reboot (and really, anything) doesn't happen with the short presses (verified myself before finding this thread I could see the short button presses happen during this black screen issue, so I always knew the system wasn't completely down). Was trying to make that clear with my first bullet point above.
Here's the log from boot per request (note I have an issue with the time resetting on my laptop due to broken CMOS battery plastic slot):
Offline
That's not a journal but the unreadable mess you left behind after some redaction efforts, completely breaking syntax highlighting (thanks) and possibly missing random lines.
You can pseudonymize numbers (though typically pointless, there does't even seem to be a network connection or maybe you deleted those line), ie. replace pattern details with fake values: aaa:bb-c => ddd:ee-f, but replacing everything you don't understand with (**) makes the thing close to useless.
It however includes two S3 cycles, you wake up from both, afterwards multiple short presses of the power key are intercepted but apaprently not handled
17:10:17 hostname kernel: ACPI Error: No installed handler for fixed event - PowerButton (2), disabling (20230628/evevent-255)
Fwwi, there's https://bbs.archlinux.org/viewtopic.php?id=297491 - the user is also on xfce, do you have the same problems when only booting the multi-user.target (2nd link below) and suspend from there?
Offline
Hey, thanks again for the help! And sorry about the mangled log, will look into your suggestions on that.
I actually have a successful then an unsuccessful deep sleep in my log. I think I might have some potential evidence based on comparing the two.
Successful [deep] sleep and awaken:
hostname systemd-sleep[1326]: Successfully froze unit 'user.slice'.
Unsuccessful [deep] sleep (black screen with no response):
hostname systemd-sleep[16959]: Failed to freeze unit 'user.slice': Connection timed out
Why "freezing unit slice" requires a network connection makes me curious (maybe could be VM network connection or something??), but I have a feeling this lack of a frozen slice is the culprit. I do know I have random WAN network issues (details not relevant to this topic), so I can also make sure my connection is active perhaps to experiment before going to sleep.
From the post you linked:
Jul 07 14:07:05 kanon systemd-sleep[23620]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
drop-in applies
I removed the drop-in (made the things even worse since I can't do anything after resume and have to do an hard shutdown).
If I understand at all (probably not, I'm not savvy with this stuff at all), my guess is that his issue is "removing the drop in" (setting SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 ??) in combination with going into deep sleep. Perhaps he did that because he hit the problem (issues "freezing unit slice") I'm hitting?
Offline
It however includes two S3 cycles, you wake up from both, afterwards multiple short presses of the power key are intercepted but apaprently not handled
17:10:17 hostname kernel: ACPI Error: No installed handler for fixed event - PowerButton (2), disabling (20230628/evevent-255)
Forgot to reply to this part, just want to make sure everything is clear:
As I've mentioned, the short presses are me indicating that I am in the black screen trying to do anything to get a response.
As you mention and I also observe in my previous post, there is a successful sleep (on my way to work) and an unsuccessful sleep (back from work).
The "PowerButton (2)" is just my long press going through and my laptop shutting down.
Offline
Found some interesting information here (I am also using KVM by the way):
https://github.com/systemd/systemd/issues/33083
Overall seems to be narrowing down on systemd issues.
Looks like there's a request to test out with KVM this kernel version with a fix:
https://github.com/systemd/systemd/issues/33626
Not sure the best way for me to grab that one, but hopefully this issue will be behind us soon.
Last edited by mikelago (2024-07-09 19:22:46)
Offline
Please don't bump, edit your previous post if nobody has yet replied.
Does this only happen since systemd 256?
=> https://bbs.archlinux.org/viewtopic.php?id=296954
Ftr, you're 2nd sleep successfully wakes up, that's why it and the subsequent (short) power key presses show up in the journal at all.
The problem is with your session *after* the wakeup.
If you'd failed to wake up, the journal would abruptly end w/ the system falling asleep.
Offline