I give up
I give up
Absolutely nothing in journalctl, dmesg, etc ๐ญ
I give up
Absolutely nothing in journalctl, dmesg, etc ๐ญ
Meanwhile every Windows 10 install I've ever had fails to go to sleep 90% of the time, and none of the powercfg commands reveal why.
Can't go to sleep if its busy doing telemetry
Almost like sleep mode on x86 is impossible to do correctly. I'm not even sure Windows does better or worse than Linux on this one.
It worked decades ago perfectly
I have had some luck disabling Wake-On-LAN on the systems that donโt need it, or enabling higher sleep modes on the systems where that is available. My pet theory is that a lot of systems are constantly looking at what is active on the network and those pings are keeping the machine awake.
it's almost like we peaked in the late 90s early 2000s.
Best I've had is to disable modern standby and re enable s3 standby.
Bruh I have the asus laptop with nvidia gpu and I never had single issue with sleep or wake up.
I'm almost certain it's not hardware considering all three have NixOS and they all have the exact behaviour of shutting down immediately as soon as the LED lights up as if the power is abruptly removed (yay reproducible), but not knowing how I can fix this is really frustrating. There simply isn't a good way to concisely describe the issue, so finding people with the same issue is really hard.
The easiest way to find something that could help is journalctl -r --boot=-1
after rebooting your laptop. These options will display all of the entries in reverse chronological order, starting from when you powered the computer off. When you find something complaining about waking from suspend, just look up that entry in a search engine. This method helped me many times, mostly with amdgpu bugs in the kernel fucking with my system.
Edit:
Absolutely nothing in journalctl, dmesg, etc ๐ญ
Woops, didn't read that. dmesg
only keeps track of everything from the last boot, so unless you used SSH to remote into your laptop while it tried wake from suspend, you wouldn't see anything anyways. journalctl
on its own vomits out a metric fuckton of entries, but it does persist across reboots. If you use my aforementioned options or something like journalctl | grep suspend
, it might be easier to find something
I hope you find a fix and if you please let me know
Specifically what is the behavior you're seeing? I can't guess exactly from the meme.
I hope you find a fix and if you please let me know
Have you tried using nix-hardware repo? They have some device specific configs that apply.
If you are, have you tried doing it "raw" in the configs instead?
Also if you are using an AMD CPU, smokeless UMAF has more BIOS options, and you can try enabling/disabling modern standby as well as a LOT of other power options.
I'll try that. Thank you!
I am facing similar issues on an old laptop running debian. Sometimes work and sometimes doesn't but my guess is the kernel update but I don't use it enough to try and fix it. Try downgrading kernel, may help your case. It does run pretty well for a 10 yr old laptop without ssd so no complaints there.
Odd how this affects laptops. My desktop works perfectly with suspend, far better than It ever did with windows.
Desktops donโt normally have S0 suspend. Laptops have all switched over to that and itโs a pain in the ass.
My Asus ROG laptop does the same thing. 4080 laptop gpu Ryzen processor. Mine also if it darkens the screen and locks when I come back my external monitors resolution is wrong and requires me to fully unplug it from my laptop and plug it back in to get it correct again. Same when my laptop starts from full power off. I've also just kind of given up on these issues and have resulted to work around lol
I have same on Asus laptop ,and pressing many times suspend until it will go sleep
X86 gonna x86.
I had this issue when I had my filesystem on an sdcard. Turns out they turn off after sleep and don't wake back up automatically.
mines been staying awake and asking me to confirm when I open it back up.
Do you have a swap partition mounted?
Suspend doesn't save state to disk, it saves state to RAM. So you don't need swap to be able to suspend.
systemd, the solution for all Linux issues.
Or so they said...
I'd guess that it's most likely not systemd itself causing the problem, but rather something kernel- or hardware-side.
To fix this, I pass
amd_iommu=off
as a kernel parameter in GRUB ฮฟptions.