Why does Linux have so much trouble sleeping and waking?
Been running Linux for years and one thing that has always been frustrating is finding my laptops have either woken themselves up, or won't go to sleep.
The majority of time they do work as expected, but maybe 20% of the time they don't, is there a logical explanation for this?
I've had Macs and PCs which don't seem to suffer from the same issue.
272 comments
[ 2.2 ms ] story [ 328 ms ] threadAFAIK linux-only distributors like System76 don't have this problem.
Doesn't need to be linux-only, just well supported. My Dells and Thinkpads don't give be any trouble.
I also have a Legion Y520 that has been working perfectly for the past two years, so for me, the answer is that it indeed varies from laptop to laptop.
I haven't used Linux on a desktop/laptop in a decade so it's sad to hear that things are still the same.
The 2015's were incredibly solid machines, I've never heard of an issue like this happening. I still daily my 2015MBP and the thing is an absolute tank where everything just works.
I would literally bet money that your issue is hardware, not software.
Edit: I realize now that this comment could be referring to running Linux on a 2015 MBP, in which case I'm a moron and we can just disregard my comment.
If the OP does some internet research into this topic they will find articles detailing how almost all [1] non-apple laptop makers build to a single target: ms-windows. They also test against a single target: ms-windows. If it works there, they are done. Linux compatibility is not even an afterthought.
And as each makers various models all seem to also have slightly different ways to perform sleep/hibernate and subsequent wakeup, the result is that Linux kernel dev's are playing a continuous game of catch-up. One thing I've found is that upgrading the kernel to a later release sometimes fixes the issues (assuming patches were supplied by someone in the interim to fix them).
[1] Very few makers have any laptops that ship, from the maker, with Linux preinstalled, the few that do (one or two Dell models, the aftermarket "Linux Laptop" vendors, maybe a sliver of others) will more than likely work properly for sleep/wake. The reason why these work better is because the maker should, in theory, test for Linux compatibility and help fix any bugs (or simply build with compatible chipsets from the outset) since they are selling these with "Linux pre-loaded".
But as a user, you do have to pick your hardware.
My ThinkPad X240 has been suspending and resuming reliably for the majority of the last 6 to 7 years. There was a time when the touchpad didn't work after resume without tweaking (in Fedora), which was annoying and surprising and something that IMO shouldn't have happened. But other than that there have been no issues.
[1] https://certification.ubuntu.com/
See https://starlabs.systems/ and https://starlabs.kb.help/compatibility-reports/
Curiously enough, some of my colleagues which have the same laptop model running Windows, complain that their laptops only wake up about 50% of the time, ever since we had a mandatory upgrade to Windows 10.
Lenovo also certifies ThinkPads for Linux:
https://support.lenovo.com/us/en/solutions/pd031426-linux-fo...
Newer (?) ThinkPads even have a firmware option to switch between the default sleep state and one that is more compatible with Linux.
https://brauner.github.io/2018/09/08/thinkpad-6en-s3.html
I recently bought a T14, which also has this option.
(It enables S3 sleep.)
S0ix is the new standard for W10 and beyond, in which the operating system attempts to itself shut down as many peripherals as possible, downclock the CPU, shut off unnecessary cores - but stay in ACPI S0. Basically just run normally, but try to be as power efficient as possible, following how mobile phones do things. Its big advantage is that it allows for varying levels of background processing (and eg. network connectivity) that just aren't possible with traditional S3. The downside is that it needs great hardware support within the OS and that it's a complex, system-wide effort to implement (like, needs application cooperation). Linux's S0ix support (via s2idle) is quite mediocre right now.
S3 sleep is the same ACPI-driven suspend-to-RAM mode that PCs have been shipping with for decades, in which a complex rube goldberg of DSDT and platform controller pokes ends up making a CPU stop running, having saved its entire state into RAM. The upside of S3 sleep is that it generally works, unless a machine's ACPI DSDT is terribly broken (which still unfortunately happens). The downside is that it's pretty much binary (either you sleep or you don't) and that you can't control what wakes you up. I mean, there's some ACPI mechanisms for it, but they're limited and janky.
New Thinkpad BIOSes can let you choose between either exposing old-school S3 via ACPI for non-W10 systems, or enabling S0ix functionality for W10. The default is generally S0ix/s2idle.
See: https://www.kernel.org/doc/Documentation/power/states.txt
That being said I have not owned a laptop in the past decade that I trusted to sleep when running Linux. I've had nothing but problems with things like WiFi not coming back up or the machine randomly waking up in the middle of the night.
Those machines running Windows are much better. But really the only machines I trust to wake and sleep reliably are Macs. I haven't run into major sleep/wake issues on Mac laptops in twenty years of owning them.
Example: Lenovo ships some Thinkpads with a Fibocom LTE modem. But only Windows has PCIe drivers, Linux needs to use the USB interface. Not a problem one would think, but if you switch the modem to USB mode, the notebook will not boot. Lenovo still uses a whitelist for allowed devices and they forgot to add the USB mode for the modem.
Thread for further reading: https://forums.lenovo.com/t5/Linux-Discussion/Linux-support-...
https://forums.lenovo.com/t5/Other-Linux-Discussions/Linux-d...
This is why I have been using System76 personally for the last 5 years, since I first found out about them when given one by an employer. The first linux box I have had that didn't have little problems like that.
Disclaimer: not affiliated in any way, just a happy customer for work and play.
My personal ThinkPad E495 has pretty much flawless driver support.
Granted, I'm running different distros (Ubuntu on the Dell, Solus on the ThinkPad) but the fact that the Dell Precision is certified specifically for Ubuntu is pretty disappointing.
In general, Linux runs really well if you filter hardware a bit ahead of purchase. For example, an all Intel machine with Intel wireless card will rarely give any trouble.
That being said, after each reboot I do need to put the machine to sleep using the power button once. After that the sleep/wake works perfectly just by closing/opening the lid. It's a minor inconvenience and I'm actually kind of loving the thing!
Edit: yes, it's a model you can buy with Ubuntu pre-installed.
(If someone knows which log file will tell me the exact reason behind a mystery wakeup after it happens, please share!)
https://www.kernel.org/doc/Documentation/acpi/debug.txt
I'm not exactly sure what options you'd need to enable/disable to just catch useful info.
Hopefully you don't need to enable everything, which may produce enough (realtime) logspam to make journald use a noticeable amount of CPU.
* bricks, but can be restarted if one opens the case and resets the BIOS.
Had a Dell XPS before that, it was way worse on the same issue. With MacBooks, I didn't have that issue as much with personal machines, but I mostly used them for travel. I've had pretty bad issues with work MacBooks.
Love my System 76, but there's still work to be done there.
Usually, I've been running something that is either not very new, or else, is specifically branded as having linux support.
https://youtu.be/kZRE7HIO3vk
Have you ever gotten the native HDMI port to work in linux?
oh wow, okay I'll definitely try that haha
> Have you ever gotten the native HDMI port to work in linux?
Yes, with the nvidia drivers it works fine
The parent commenter just has higher standards than you: either that software and hardware are relatively easily decoupled and should be, or that laptop manufacturers should competently implement the standards they claim to, or even just that he's never worked at a company whose product was as poorly-made as almost every laptop's compatibility software.
Good sleep on windows has only returned recently.
After years of great sleep on Windows 7, there have been massive changes following the introduction of ACPI S0.
Case in point: I got a nice laptop for classes like 4 years ago and it did NOT implement either S3 or S4 mode, which caused a MASSIVE problem in Linux. I found out about the issue on mailing list: the bios simply didn't implement at all this part of ACPI, instead of exposing the hooks based on the OS detection. It was to reduce problems in theory, but it brought many more in practice.
Connected standby (S0idle) was very flaky on Windows 10, and very often the laptop would eat the battery overnight instead of going to sleep.
I'm not sure if there are direct lessons there for Linux driver handling as Microsoft has huge test labs that do forward these sorts of event logs to the hardware manufacturers and is in a position to expect at least some of them to do better next time (either next driver update or next hardware refresh).
Macs have always nailed it. When I worked at a computer store like 15 years ago, people would bring in their Macs, open up the lid and it would wake instantly after being asleep in someone's bag for 2 weeks and still have a 90% charge. Any Windows PC in that era would have run until it overheated and melted, or ran out of battery, whichever happened first.
My desktop (custom built) refuses to go to sleep when I'm booted into Linux. Straight up just wakes itself immediately.
Over in Windows land I've had this issue on a regular basis with a Thinkpad that keeps waking itself up. I've had this issue occasionally on a Surface Book 2, I suspect due to a finicky monitor attached to the dock. I've had this issue pretty much never on a first gen Surface Book attached to the same dock. Go figure.
It's probably a device that it's waking the computer up. In my case it was a mouse. See https://news.ycombinator.com/item?id=25389048 for a solution.
If I select the sleep option in the start menu it probably won't wake back up and I'll have to unplug it for about 10 minutes to get it to boot again.
Previous causes have been sound drivers, chrome, steam, joysticks, some unknown that an update fixes.
They had no idea what happened or how to fix it.
I doubt this is true. Windows = computing for a good over 80% of humanity. Not markets, not regions. Humanity.
Assuming you're not running a Mac (where the vendor controls the entire stack), you've got your OS vendor, your MB vendor, your every-single-external-device-vendor...
... and the interactions of all this hardware mediated through the OS, its drivers, and the reading comprehension and the development pressures of every single dev who's worked on any part of this stack.
There's an awful lot of room for ambiguities there. Protocol definition at this level is kind of a collaborative lurching towards consensus.
I wouldn't assume so. Is there a problem with the spec for using your turn signals while driving? And yet...
The fundamental challenge is complexity. Understanding how to build this stuff is a mix between figuring out which complexity to expose to “the masses” (masses here being other developers) and what else to hide in abstractions or better tooling.
I think the market would look very different if senior Linux kernel maintainers (including Torvalds) got together and said “this is the Linux power save API - implement it”. The challenge is that the same HW powers Windows (and used to power Macs and probably still does to at least some degree). No protocol worth a damn can handle that much variability. So then the question is can the firmware and driver code be given less to be responsible for rather than more and then let the kernel make all the decision making power. The problem with ACPI (at least as I understand it from reading about it superficially - I’ve never read the spec itself) is that decision making is extremely interdependent with the kernel ultimately not being fully in charge of decisions.
For example, a simple design for something like this is defining ACPI-lite that handles 80% of the hardware that ACPI currently supports but that drastically simplified the mental model and lets the kernel implement all the common logic with the driver and firmware not being responsible for anything more than translating kernel commands to the HW. Then you leave ACPI for the remaining 20% of HW that doesn’t fit in the bucket but you also make the warning verbose (you’re running legacy ACPI device X - this may degrade your battery power / prevent sleep wake from working effectively).
If they can also get Windows kernel engineers on board then you would have a compelling market forcing function on HW makers/driver writers to simplify their code.
If you want someone to do something, then you must make it realistic for them to do it, and you must make sure that they have some reason to bother.
When shopping for computer components, do people research whether that graphics card or USB hub behaves well in power saving modes? And if they wanted to, do they have easy access to that information? If not, then manufacturers will probably not prioritize it. They will prioritize whatever goes into the purchasing decision instead.
Though it is good in a way to know that there are specific things that could be improved on the technical side, because it means there's the possibility that things could be better.
Random thought: maybe some organization whose mission is energy conservation (government like Energy Star in the US or nonprofit) would be willing to fund the software revamp. Maybe in combination with people who pay data center electric bills.
They are done via ACPI. ACPI is implemented by the device vendor, is part of BIOS/UEFI and is notoriously buggy.
The runtime_pm framework is for when applications are still running but the device goes to sleep. In S3 suspend first every single user space application freezes, then the drivers go to sleep. S3 is much easier to implement.
That sounds like a brave statement to me.
Without knowing many details I believe that drivers can block the system from hibernating when they don't cooperate correctly.
I am absolutely sure during wakeup the driver needs to cooperate correctly. There are numerous cases that some device does no longer work correctly after wakeup. I doubt that ACPI alone can be blamed for all of the issues, even if I don't like the close source nature of ACPI.
Is there any open source approach to ACPI? Not that I'd expect to work better right away. But you know whom to blame. In the worst case yourself for not starting to fix it.
I think this is halfway accurate. Drivers are part of the problem and firmware is the other. Other folks in this thread have gone on to explain it better than I can, so I'll just point you to them.
That said, I think things like the new firmware update manager that connects device creators to the Linux ecosystem so they can provide smooth and regular updates to users are pivotal to solving these kinds of problems.
I've had less problems on PopOS due to this. Firmware updates have at times completely eradicated the more usual problems I experienced with Linux, which in an uneducated guess, probably boiled down to interoperability.
Drivers have to implement callbacks for suspend. A driver needs to make sure it saves all of its state before the suspend, and then it needs to make sure it restores all of its state after resume. S3 suspend often kills the state of every register that was previously written.
I have another laptop that takes about a minute to shut down, and it appears related to the wireless NIC. While it's an Intel-based card (Killer-rebranded... absolute garbage), I've had nothing but trouble with it. I plan on swapping it out one of these days.
I am obliged to conclude that it must be just an NVidia problem, because I always avoid those. (My laptops are built with an NVidia chip in them, but powered off. On-chip Intel graphics work very, very well lately.)
Meanwhile people do have serious issues with sleep even on Intel Macs running MacOS and Thinkpads running Windows. For whatever reason PC chip / hardware vendors just cannot get sleep to work properly. Apparently the problem is so low-level that even a company like Apple cannot paper over the problems without throwing out Intel entirely and using their own SoC in the new Macbooks.
That said, I have a work laptop (HP Elitebook G5) running Ubuntu that wakes and sleeps perfectly. Same situation with Ubuntu on my desktop PC.
I understand it's not quite the same thing, but it means you either need to turn it off, or charge it every week, even if you're not using it.
I believe it isn’t hitting S3, but I haven’t done too much troubleshooting.
The T480 I had was a company laptop and I don't have it anymore, so I can't check.
Mostly the P14s feels the same as the T480 did. I have none but the usual complaints (+ too new hardware so drivers are still a bit flaky), though I think the underpowered discrete graphics is a waste of money at least for my use.
Again, mostly it's great, but when I go to bed a night, I have a lot of "remember to plug the charger in" anxiety, it's a constant source of anxiety for me.
My laptop still has problems with a .NET "optimization" task you can't remove that basically thrashes the disk constantly erroring for x86 assemblies I don't even use. I ended up replacing the program with an empty one, but every year or two it restores the broken program.
I know it's back when my fan starts trying to take off like an aeroplane. I tried figuring out which .NET assembly was causing the problem, but in the end it was easier to just replace the offending program.
The most annoying part of that process is that you can actually remove the task, but windows would then see it was missing within a few days and add it back.
I know what you mean, it hasn't all been roses. But in general I have no major gripes with my latest Thinkpad laptops.
Lately it's been amazing actually, on a Thinkpad X1 Yoga 4th gen with Fedora 31 atm. I can't remember the last issue I had.
It's frustrating, but at least now that I don't have to leave my house anymore, it doesn't matter too much!
Now another software upgrade broke my desktop's waking up which has been working fine for 4 years...
At some point three or four years ago there was an article I saw where someone realized the way Linux handled memory layout during hibernate was way over complicated and they redid it much more simply. Ever since then I haven't had any issues with hibernate, either on my Thinkpad or my multiple Dell machines.
I did have a fun regression recently where my ~10 year old desktop machine started randomly hanging and it seems to be a regression of some sort in the nouveau drivers since reverting to a previous kernel version fixed the issue.
In turn, the implementation is rather poor. For example, it is impossible to suspend any machine while any ssh directory is mounted. It's been a bug for 10+ years. The bug is architectural and pretty much impossible to fix (Any file or directory read hangs on the SSH connection, and a process can't be paused for hibernation while a non-restartable syscall is running.)
While this kind of architectural bug exists, Linux hibernation will never be good. Fixing that bug properly is probably $500k worth of developer resources. Nobody wants to pay.
My laptop auto-mounts a sshfs directory at startup and hibernates with no problem. On resume, the sshfs mount still responds. Having an open shell on that directory is no problem, except that I can't manually unmount a FS being accessed. I remember configuring this when this Debian Testing laptop switched to systemd, years ago.
Simply being mounted isn't a problem. A syscall needs to be hung on a network request.
I regularly hit this issue. Most recent one was last year on 4.19 kernel when using NFS mount. I found the bug report for that one and they said it was fixed in 5.1 or similar.
Beware they were talking about that particular bug. Because as the parent comment says it is architectural issue that can't just be "fixed". It's a whack-a-mole. Developers need to be careful on all the call sites to avoid it. FUSE, NFS, CIFS code is all susceptible to it (and to my horror I've bitten by every single one of them several times in the past).
I use Synergy to use a single keyboard/mouse across multiple computers. It also seems to completely inhibit sleep in whatever computer is running a client.
Then there's shit like Discord or Firefox or Steam. Any time you run a full screen app or play music, the OS seems to think "oh hey you're playing a game" and then inhibits sleep.
I have once solved AMDGPU not waking up from hibernation just by compiling the driver into the kernel.
The AMDGPU modules weren't loading somehow and even after spending some time, I couldn't fully debug the issue, as I'm missing an USB debug cable, the hardware didn't had Intel AMT serial over LAN and it lacked a real serial port.
You can try netconsole, a debug console over UDP/IP, implemented within the Linux kernel at a very low-level. It can keep sending logs over the network even if a kernel panic has occurred. If both netconsole and the Ethernet driver is built into the kernel, it's almost a serial-port substitute, a really handy debug tool for all kinds of black-screen-of-death issues. To debug an issue like that, I prefer connecting my workstation directly to the target (without routers and switches) and assign a static IP address on both ends. Netconsole for kernel space, SSH for userspace.
The only thing it cannot do is collecting logs from the very earlyboot process. "The AMDGPU modules weren't loading" may or may not be an earlyboot problem, just try and see if you are lucky enough.
https://www.kernel.org/doc/html/latest/networking/netconsole...
IIRC it wasn't sending logs to my target machine at this boot stage, and I couldn't even get a flash of a kernel panic message to record it in slow motion on my phone. That's why I think only an USB debugger cable could help in this case.
And to be fair, I'm just guessing the modules weren't loading, after they got compiled in, everything worked like a charm. Didn't debug it further, as this happened in the beginning of the pandemic and finding an USB cable not shipping from China, with reasonable costs, was impossible.
I see.
> And to be fair, I'm just guessing the modules weren't loading, after they got compiled in, everything worked like a charm. Didn't debug it further
To be honest, I'm also guilty of WorksForMe-ism (adopting a workaround instead of debugging the real issue and call it a day, sometimes without even bother to publish the workaround)... ;)
On Windows many newer laptops don't even use actual "sleep" modes but rather simulate them with lower power active modes. Linux' problems with traditional sleep modes are only going to get worse as a consequence since manufacturers are going to abandon them. I'd stop using them ASAP.
Also, I have no idea how your computer boots in seconds.
POST to UEFI is at least 3-5 seconds.
Than I have to wait about 5-10 ish seconds after I type my password to decrypt my drive.
Than it gets to OS selection screen which takes 3-5 seconds. Then it has to load all services after boot which takes about another 5-10 seconds before things get into a vaguely usable state.
This versus 2 seconds to wake.
And when someone says "seconds" the implication is that its at max around 5-9 seconds. I would be pretty pissed if a application that took "seconds" to boot actually took 59 seconds.
Also probably most people don't have encrypted HDDs on their home computer, so another 10 seconds you can shave off.
My current Ubuntu boots in maybe 10 secs from power button to login. And that includes the 3sec Grub menu pause.
But my point is that, for most of the time, I just leave it on. It consumes almost the same power sleeping that fully on, at idle.
And 10 seconds is still nearly 1000 subjective years. A Commodore 64 boots faster than the CRT can warm up and, while certainly doing less in the process, does it with a 1Mhz processor. Which, for reference, is 3000 times slower than our single core 3Ghz example not even accounting for CPI=>IPC inversion.
Computers are ludicrously fast, but we've apparently worked hard as an industry to slow them down as much as possible even for the simplest of tasks.
This is the wrong year to complain about boot time.
I remember being on an airplane with no wifi and a brand new MacBook Air and spent most of the time idly turning it off and on, since I was really impressed :) . And today that > 1 minute boot time I would consider crap.
Because we have ludicrously fast computers, but they feel slow. I have an period appropriate XP laptop in my office and every time I have to pull it out and use it I'm momentarily shocked by how responsive it is compared to modern OSs. We should be better than this, but our industry sucks at its job and I'm kinda sick of it.
> These days my Linux desktop computer boots in around 10 seconds [...]
> My desktop literally boots in less time than it takes for my DP monitor to power on from zero and start displaying frames.
Your monitor takes more than 10 seconds to power on, and you seriously don't think this is ridiculous? What the hell is it doing that could possible be taking that long?
No matter how many cores the CPU has or how fast they're clocked they're not going to make all that IO faster. They also can't run a hard coded 10ms sleep faster than 10ms.
Even once you get into a booted kernel and PID 1 you're still going to wait on IO to get daemons running. If you've got services (in systemd parlance) waiting on Networking you can have totally variable wait periods depending on local network conditions.
SSDs and parallel starting of daemons has improved boot times a lot over the past decade but there's still hard minimums just based on booting up low level crap before the kernel turns things over to PID 1.
I haven't used Linux desktop lately though, but I'm not aware that they had an API for that.
You're probably right. Linux desktops environments (or at least some of them) used to have an attempt at something like that, but I think it only worked for applications that made an effort towards it, and I personally haven't even tried to see how or if that works nowadays.
Suspend to RAM and hibernation fill that hole for me, although it's admirable if someone has been able to properly solve the problem of restoring the session after a full reboot.
Into a clean screen, without any of the webpages, terminals, and other applications I've been running.
Recently upgraded to Ubuntu 20.04 and found out GNOME3 doesn't even support session save. (Seriously, WTF?) So sleep/hibernate is the only thing that allows me to get back to what I was doing.
Here is a real world scenario that is extremely common. I am using my laptop, say doing random hobby projects, with code open, a few browser tabs open, some terminal tabs, maybe with something running. My kid or spouse need my attention. I close my laptop lid so 1. It keeps all my windows open, 2. No one knocks over my laptop because its lid is open on a couch, 3. I can respond to my kid or spouse without having to shut down, wait for the shutdown process (a few seconds is a year when a kid is waiting for you... and in some cases, it could be a real emergency too).
Because my laptop where I run Linux on (Lenovo ideapad 320s) fails 100% of the time when I close the lid to put it to sleep, I simply cannot do this. When I say fail, I mean it hard crashes -- to fix it I'd have to hold the power button for 5 seconds to shut it down fully and reboot.
What I ended up doing was configuring it so closing the laptop lid does nothing at all (no sleep, no hibernate, simply turns off screen). This is an OK alternative but anyone who dosn't live alone know that when you close your laptop lid, you have no idea when you're going back to your laptop next. It could be in the next 5 minutes. Or, it could be the start of a series of events (changing diapers, bathing the kid, tantrums, etc.) that keeps you unavailable for the next 4 hours, and then it's bed time and you forget your laptop was still running, and then you go to work the next day, and finally a full 24 hours later you came back to your laptop and you remember that you didn't shut it down 24 hours ago, now it drained up all your battery and closed all your apps anyway. (Real world examples that have happened to me)
Plus: it's an attractive design, tiny bezels, super light.
Battery drain is higher during sleep than a Mac though.
Many Linux drivers can't pass this level of rigor. Back when I used to care about this professionally (before 2014), video + wifi drivers were some of the worst culprits. Each variant of each chipset would need its own driver, and often those drivers needed tweaks for stability.
Firmware implementations are (were?) also built + tested exclusively for Windows, and Linux is different enough that it can trigger untested/broken code paths or otherwise cause firmware to misbehave. Linux also has its own set of issues with ACPI + UEFI.
Canonical, RedHat, etc have teams dedicated to enablement and testing for OEMs like Dell that ship computers with Linux. Back when I was involved, Canonical had 60+ people dedicated to this, and qualified hundreds of SKUs each year. Even then they don't cover all hardware. The fixes+workarounds those teams produce also take time to make their way upstream.
To successfully suspend and resume a laptop, BIOS/UEFI and all drivers in the system, e.g. GPU, network, audio, USB, must have perfectly working power management code, a single bug in a driver is enough to prevent the entire system from sleeping.
> [...] I've had Macs and PCs which don't seem to suffer from the same issue.
Macs and PCs are fully tested by the vendor with all driver issues fixed before they are shipped - if they can't wake up, it's vendor's problem. On the other hand, if a laptop does not offer explicit Linux support, they are not tested at all. Linux developers are left on their own to figure it out. Worse, for some types of hardware, documentation is often lacking or nonexistent (OEMs have internal support from all device vendors). By saying "on their own", I really mean it - I've personally diagnosed and fixed a driver issue in the Linux kernel for my laptop, despite not being a kernel developer. If you have a popular machine, someone else will eventually fix it. But if you have an unique machine, sometimes there's really nobody that would do it for you.
By far, the most notorious suspended/wakeup problem I've ever encountered was on a Windows tablet. Once the machine is suspended (ACPI S3), it's impossible to wakeup the machine again. After a long thread in the Linux bugzilla, ultimately the problem was identified - a developer disassembled the ACPI DSDT from BIOS, and discovered this scandal.
Yes, it means what you think it meant, even if you don't speak ACPI. There's literally no code in BIOS to wakeup the system from ACPI S3, the only instruction is "return 0", it's not implemented at all!Why does it work in Windows then? In Windows, it uses Microsoft InstantGo (ConnectedStandy) - a proprietary Microsoft standby mode with network connection (to allow smartphone-like "push notification"). The vendor decided that implementing industry standards are not necessary - you only need to implement Microsoft - and simultaneously, they also decided that, rather than simply saying ACPI S3 is not supported, you should define a broken ACPI S3 just to screw up everyone who is not using Microsoft Windows.
It's seems doable with modern kernels: https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-li.... Maybe you should give it a try.
Yes, I knew s0ix. Unfortunately, the last time I've checked, s0ix had its own problems. Since then, I've given up and switched to a Thinkpad with coreboot. I just rechecked, it seems the s0ix bug is already resolved by a combination of BIOS update and a kernel parameter workaround, so suspend should finally be usable by now, hooray! Despite I'm not using it anymore, I'd still call it progress.
Also want to add that random wakeups can be triggered by interrupts hitting devices in `/proc/acpi/wakeup`. These wakeup sources can be selectively disabled once the problematic ones are identified. I disable XHC (USB ports), because it seems my routine closes the lid to suspend and _then_ remove peripherals.. which can cause a wakeup!
[1] https://gist.github.com/mailhost/d5b27b247fa26d8bdc8a5d20223...
+1. I love the Hackintosh community. Hackintosh forums are a gold mine of solutions to all types of ACPI DSDT problems. Many great tutorials, really helpful to Linux users. If the Hackintosh community doesn't exist, it wouldn't be possible. Not only DSDT, their EFI resources are also great, probably the biggest PC userbase of EFI bootloaders - earlier in this year I used a Hackintosh EFI device driver from Clover (free and open source) to help me booting from NVMe without BIOS support. In my previous life I also solved a non-standard graphics problem by backporting Hackintosh solution to Linux. Looking back, trying Hackintosh turned out to be a great decision, despite I only used it for a few months before quitting (I decided that voluntarily lock myself in a walled garden, then spent a lot of time installing a free software working environment back is unwise), otherwise I could not know its community and innovations.
> Using `acpiexec` was very helpful to simulate invoking sleep/suspend and being able to follow the execution path of where it would get stuck. Also want to add that random wakeups can be triggered by interrupts hitting devices in `/proc/acpi/wakeup`. These wakeup sources can be selectively disabled once the problematic ones are identified. I disable XHC (USB ports)
Thanks for the tip. I hope I'll never have to use it, but it could definitely help if I had to use yet another broken laptop for some reasons.
Hint: to execute any code, including quoted ASL, the processors has to be woken up and running in a proper context.
I get the impression more manufacturers are testing with linux nowadays, I think they realise that for a small (relative) amount of effort to just test the most obvious of things gives a good payoff, and the community will fix the quirks.
Upd: I don't see any mentioning of Linux on the official page of your laptop: https://www.lenovo.com/us/en/laptops/thinkpad/thinkpad-t-ser...
In both Linux & BSDs.
Arch & OpenBSD.
Running Linux 5.9, but it's been doing this on occasion for a while now.
I mean you've got an Nvidia GPU, which is basically a no-go from my perspective.