Why does Linux have so much trouble sleeping and waking?

248 points by bamboozled ↗ HN
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 ] thread
I've always assumed this is more a factor of installing linux "aftermarket" versus the manufacturer able to be careful about the bios+os interop, rather than anything with the OS itself. I imagine hackintoshes are similar.

AFAIK linux-only distributors like System76 don't have this problem.

In my experience, hackintoshes sleep/wake much more quickly than Linux, even on the same hardware.
> AFAIK 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.

My XPS13 9360 or similar has given me a few issues over the years: Occasionally not sleeping, inability to wake WiFi-circuit from low-power mode, sometimes the touchpad would freak out - I think it would latch a multitouch state pressed down.
Which hardware are you using? My assorted Thinkpads haven't had that trouble in quite a while. (Although the sleep/wake stuff definitely seems janky to me in terms of UI behavior.)
Not the OP, but I've got an older W530, and it's a very careful dance for me with sleep and power. If I'm using it at a desk, I have to unplug the power, wait a few seconds, and then close the lid. If I close the lid and then unplug the power, the power change event seems to wake the system back up and I'll find it hot with a dead battery in my backpack when I get to my destination. Running Ubuntu 18.04. When I finally get around to the 20.04 upgrade I'll test it again and see if it's fixed, but I have my doubts.
I have a T495 with a Ryzen processor running Arch that has some issues waking up (maybe once or twice a month). Sometimes it refuses to wake up, and sometimes it wakes up but CPU clock speed gets stuck at minimum frequency, making the laptop extremely sluggish until the next reboot.

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.

Drivers. The way laptops sleep and wake is pretty unique to each type of computer, and many manufacturers don't care about Linux support so kernel developers are left to figure it out on their own.

I haven't used Linux on a desktop/laptop in a decade so it's sad to hear that things are still the same.

E.g on my 2015 macbook pro I need to remove and re-add the wifi driver module to make it connect.
...what?

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.

Yeah, it's Linux. :) macOS always ran nicely, and the hardware itself is great. I think if somebody more capable in Linux kernel/drivers' hacking looked into it they could fix it, it's just that nobody cares (and `rmmod brcmfmac && modprobe brcmfmac` is simple enough).
This ...

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".

Which laptops get this right then? Any of them?
Had no issues with my current thinkpad (t480) and previous thinkpads (x240, x220, edge 11)
anyone that sells a linux on top; failing that its a crapshoot which mostly depends on developer popularity of that model / devices
I have a Carbon X1 and it works perfectly, including the fingerprint unlock and the touchscreen.
what version X1 do you have? And which distribution do you run on it?
I don't know which one it is. I bought it in autumn 2019 and it has a touch screen. I run bog standard Ubuntu 20.04 LTS on it.
I'd expect e.g. Ubuntu certified devices [1] to handle it. There are certified laptops from at least Dell and Lenovo, and probably the odd model from other manufacturers. While the certification technically only means the hardware is compatible with Ubuntu, and perhaps only as pre-installed by the OEM, in practice that probably means general Linux compatibility. I have trouble seeing any point in making Ubuntu-specific tweaks to an OEM install, as it's easier to just send only the models with compatible components for certification (or to pick compatible components in the first place, which may be feasible at least for premium laptops).

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/

I've always had good luck with Dell's Inspiron line. Have had three of them now that worked perfectly well. I always pick hibernate over sleep though, so I guess I can't say how sleep works on them.
My Thinkpad L440 has never properly been able to use sleep or hibernate modes with Ubuntu, I have to shut down completely.
I've used two or three HP Elitebooks in past few years, and suspend/resume, as well as hibernation/resume just worked on them. I never even really thought about it, to be honest, I just used it - mostly just suspend - daily.

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.

one or two Dell models, the aftermarket "Linux Laptop" vendors, maybe a sliver of others

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.

Could you tell me more about this firmware option? As a ThinkPad owner/Linux user, I'd be very interested!
So, PCs can generally either do S3 sleep, or a new fancy 'S0ix' sleep since Haswell & co, and some similar mechanism on AMD machines.

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

What percent power savings are achieved?
Percent of what? This all depends on the particular hardware. If you want hard data, measure this yourself on your own device.
IME the S0ix sleep on a fully charged battery could last ones of days. So sleeping for an afternoon or overnight doesn't drain the battery too much. With S3 sleep I've had systems sleep for more than a week with only a little battery loss. It's only keeping RAM refreshed so it's way lower power than even just minor (massively under locked) CPU activity.

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.

Lenovo has Linux fails too. This list is on part a blatant lie.

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...

> manufacturers don't care about Linux support

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.

Chiming in to add an anecdotal data point in support of the parent's comment. I too own a System76 laptop which is running their drivers and PopOS (Debian and Ubuntu derivative). Sleep/wake works well.
Any machine covered by Ubuntu certified hardware seems to work very well by default, including my work Dell XPS13. Sleep/wake happens flawlessly.
I had two dell XPSes in 2015/16, one of which shipped with Ubuntu, and they were by far the worst compatibility experience I've ever had with a Linux laptop. I loved the hardware, but my God was the firmware garbage.
My Dell Precision 5530 for work is kinda meh - by which I mean it works most of the time, but the fact that it doesn't work every time is fairly big deal at this point.

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.

Most machines with decent drivers also have flawless sleep. This includes NUCs, many Thinkpads, etc.

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.

This is true in terms of software state, but the power management is often pretty bad even with fully "supported" hardware like thinkpad, xps developer edition, etc. To be fair this seems to be a problem shared with Windows.
The child comment is dead for some reason so I can't reply, but he's right: it's important to note that filtering can be difficult, bexause even laptops that nominally support Linux (or ship with it!) can have terrible support. The Dell XPS developer editions (I bought two, one for work and one for home) are the worst Linux compatibility experience I've ever had. Amazing hardware, but shame on me for believing the line that Dell had turned over a new leaf and was competent now.
I bought one with Ubuntu installed, and have had a few small problems. I.e., power remaining is slightly optimistic: it shut down this morning with 3% showing. Also it seems to have more trouble connecting to paired bluetooth devices than my phone has. I like it well enough to live with these issues. Is there something awful coming soon?
I mentioned this in my other comment but should have mentioned it here too: I got these in 2015/16, so I can't comment on what the line is like now. My main point was that shipping with Linux is no guarantee that they'll work well, as ludicrous as that sounds.
I’m not an electrical engineer but batteries don’t give perfect output constantly so your three percent might have been correct. It’s an hard problem and if you want it to be “it should always be able to go to zero” then they will just increase the margin of when to shut down and people will wonder where their battery life went.
Yes. I just got myself a cheapo ThinkPad E15 to use as a backup computer if Apple somehow screws up my old MacBook Pro. Installed OpenSUSE Tumbleweed on the ThinkPad and everything seems to be working quite well (or at least predictably).

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!

Ubuntu just couple a weeks ago pushed a kernel update to 20.04 LTS that 100% broke resuming from suspend on my 2020 Thinkpad (Intel graphics driver hang, no surprise there). I had to switch to edge kernel to get it back working.

Edit: yes, it's a model you can buy with Ubuntu pre-installed.

I have a Surface Pro 3 with Ubuntu and not only sleep is not working, when turning the screen on again the WiFi stops working...
In the past 5 years, I've used ThinkPads for work (a T-series, X1 5G, and X1 6G); All of them mysteriously like to wake themselves out of sleep for no clear reason while closed and not connected to any external devices/power.

(If someone knows which log file will tell me the exact reason behind a mystery wakeup after it happens, please share!)

Enabling verbose ACPI debug messages might do it:

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.

One of my Intel NUC models needs a BIOS update to not soft-brick* itself after sleeping from Linux. Even today restarting from sleep needs a particular 'dance' which if not followed will need a restart to use the computer again. Everything else works though.

* bricks, but can be restarted if one opens the case and resets the BIOS.

yeah System 76 is a solid laptop, granted they do maintain PopOS which is the default OS on their systesm. so they do indeed have more custom hardware support which is why it's such a good marriage.
Writing this on a System 76 laptop running the latest PopOS and I wish I had the same experience. Sleep/wake works if I explicitly put my machine into sleep, but not if I just close the screen.
It's just a matter of a user setting. It does not necessarily mean something doesn't work. I, for example, hate automatic suspect on lid close.
My last laptop was a System76, and my current is a Purism Librem 15. Also no problems with suspend/resume.
I've got a System 76 laptop, and it's the best laptop I've owned so far out of the Windows, Mac, and Linux laptops I've had. But it still won't wake up from sleeping sometimes, maybe once a month.

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.

On some laptops and desktops it works flawlessly. This is purely anecotal, but my last 5-7 linux computers over the years (~15 years) have never had issues sleeping and waking.

Usually, I've been running something that is either not very new, or else, is specifically branded as having linux support.

They don't even necessarily care about Windows support. Upgrade to a new version that doesn't quite work the same with the hacks in their cobbled-together drivers, and you're quickly in the same boat as the Linux users.
This hasn't been my experience with Windows in the last 5 years. Truth be told it's pretty stable by now and for me, issues like that are rare. Even things like working with external docking stations are pretty seamless nowadays.
Beh, my laptop (MSI GS65) has trouble waking up from sleep on windows too. When putting it to sleep on linux it always comes back up, but I have to reboot to get wifi back. On windows wifi comes back, but the ethernet port needs to be disabled & reenabled in the control panel to work. Laptops suck.
Hey I'm also running a GS65 (First Ubuntu - now PopOs), the Wifi is frustrating, but I found double-tapping (2x [FN+F10]) in quick succession would bring the radios back up.

Have you ever gotten the native HDMI port to work in linux?

> Hey I'm also running a GS65 (First Ubuntu - now PopOs), the Wifi is frustrating, but I found double-tapping (2x [FN+F10]) in quick succession would bring the radios back up.

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

Laptops don’t suck. My MacBook rarely reboots.. only in case of system updates. Sleep/wake up works perfect
This is also true of every ThinkPad Linux system I've used over the last fifteen years, as the ThinkPad is as close to first-party Linux hardware as exists. It's also true for the majority of Windows laptops in the MacBook price range, I assume. I'd also assume that Hackintoshes don't work as smoothly as you describe, which feeds right into the parent commenter's complaint.

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.

> This hasn't been my experience with Windows in the last 5 years. Truth be told it's pretty stable by now and for me, issues like that are rare.

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 don't think a lot of Windows users notice when hardware has things like missing ACPI states because Windows since Vista tends to treat a lot of drivers as potentially "sleep hostile" and does all sorts of crazy tricks to paper over bad driver behavior, including sometimes hard shutting off/rebooting hardware on tough timeout limits (depending on hardware class) and fakes sleep/suspend as best as it can given whatever limits it comes across. The few times I've ever skimmed the ACPI/Power Events event logs in Windows, it's an amazing glimpse into some real wild goings on that rarely seem noticeable from a user level, but clearly indicate that drivers are as much of a mess as ever and Windows does a lot of work to make it look like things are fine, everything is fine, and system is peacefully sleeping (as hardware gets kicked under the table for acting up).

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).

This is how I feel about Linux on my laptop. Haven't had any sleep or dock issues in a long time. I think that PCs are much better overall about power management than they used to be. I think most of that has to do with the hardware vendors, and less to do with Windows or Linux.

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.

I don't think any of our individual experiences will say much on this topic. It clearly works well enough for some and not for others.

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.

> My desktop (custom built) refuses to go to sleep when I'm booted into Linux. Straight up just wakes itself immediately.

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 let my Windows desktop go to sleep by being idle, it works perfectly fine.

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.

Every once in a while there will be a week or two where I have issues with my pc not sleeping.

Previous causes have been sound drivers, chrome, steam, joysticks, some unknown that an update fixes.

Only Macs sleep reasonably correctly, and even they have issues. In my Macbook Air, Wi-Fi is the first victim after "n" cycles so I need to reboot it.
Indeed. External display detection often bugs out after sleep in Mac OS.
That's too bad. My Lenovo Yoga with Windows 10 works perfectly. Never a glitch.
I know people where windows update removed their GPU driver leaving them with only VESA graphics.

They had no idea what happened or how to fix it.

> They don't even necessarily care about Windows support.

I doubt this is true. Windows = computing for a good over 80% of humanity. Not markets, not regions. Humanity.

One particular issue is that nobody actually implements the ACPI power management protocol correctly.
Then the problem is with the protocol no? Seems like an architectural issue that the Linux community needs to spearhead with HW vendors to resolve. Good standards that reduce sources of error are the only antidote to vertical integration approaches that big tech is going down.
I think even the best standards can have ambiguities. SHOULD, MAY, etc.

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.

Yeah, it seems most tech standards are design-by-committee disasters.
> problem is with the protocol

I wouldn't assume so. Is there a problem with the spec for using your turn signals while driving? And yet...

I’ve implemented a lot of protocols. The more complex a protocol is and the more moving parts, the harder it is.

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.

I'm not negating that complexity is a problem. I'm saying that there are two problems, complexity and incentives.

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.

Sleep and hibernate have nothing to do with drivers.

They are done via ACPI. ACPI is implemented by the device vendor, is part of BIOS/UEFI and is notoriously buggy.

Some manufacturer selectively implement ACPI (ex: no S3 or S4, only S0 for connected standby) making things worse
No. Linux drivers are supposed to implement runtime_pm callbacks. These are called based on the usage counter of those devices. ACPI is an Intel/microsoft standard for power state definition with spotty compliance. How and when you put those devices into whatever power state, ACPI or not is dictated by those callbacks. Bugs seem to most often occur when you turn off something when it is still being used cuz someone failed to claim it or released it too soon. Also asic bugs in their definitions of their power states.
runtime_pm is generally for runtime suspend (Intel calls it s0ix) instead of S3 suspend. You can implement S3 suspend using the same callbacks as your runtime_pm callbacks, but you don't need to.

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.

I think ideally all pm would be controlled by the runtime_pm and qos frameworks. You then don't need to define explicit power states like 'sleep' or 'suspend', you instead simply use what you need for a given performance spec and naturally use a minimum of power. I think that is the ultimate plan
It's not that simple. There's a lot of predicting the future when it comes to power management. When you put things to sleep in order to save power you add latency, because waking up the hardware and restoring its state takes a long time. It's all tradeoffs, and "use minimum power" is taking the slider and shifting it all the way to one side.
> Sleep and hibernate have nothing to do with drivers.

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.

Well, there is a driver for ACPI. I have the vague souvenir of Linus Torvalds calling BIOS/UEFI dev "monkeys on crack" or something along the line...
Yes but on top of that Linus had a very "stern taking to" kernel developers who would fix it for one model but break it for others, so has made sure developers wouldn't break each others code
> Sleep and hibernate have nothing to do with drivers.

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.

I remember trying to set up a PVR and getting pretty far using mpv and at. The system worked as long as it was left on. rtcwake was the bridge that was too far: Upon waking, recording started but ACPI errors occurred soon after, culminating with ivtv reporting the encoder had died. I never got past that stage, but it was a worthy try - and I learned that some bugs ain't never going to be fixed. Edit: It was an Arch setup from about 5 years ago.
Driver developer here. The sentences above are just plain wrong.

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.

Would it be for the same reason that it takes too long to shutdown? My laptop (dualboot - ubuntu/windows) takes significantly longer to shutdown when on linux. Even with the SSD - which made windows really faster.
I have a desktop that shuts down nearly instantly and a ThinkPad that shuts down nearly instantly.

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.

Perhaps, or maybe some service just keeps hanging for some reason before it shuts down. It might be a software matter, too.
I have not seen this problem on Linux in the past decade.

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.)

I don't think I've encountered a single smartphone by a reputable vendor that has had significant issues sleeping, no matter the chip vendor or OS.

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.

Yup. Go for the most boring hardware you can. No fancy GPU. Or be willing to spend time editing blacklist files, or writing your own rmmod/modprobe hooks for sleep/wake.
My last 2 laptops: T440s and an XPS 13 (9310) have both not had this issue, and that accounts for about the last 6 years of linux laptop usage for me. Several crummy laptops (the 300-700 dollar range at best buy) prior to that have had it, though.
I have a similar experience with T4xx laptops. I think most likely answer is every engineer at Red Hat is given a thinkpad T or P series so I figure plenty of them contributed fixes for sleep, power, etc. Dell obviously has Linux certified laptops so I'm sure it's a similar story.
As a widespread counterpoint, look at Chrome OS. I’ve never seen any ChromeBook, clear back to the very first CR-48 ever fail on this.

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.

It's easy to make things work when you control both hardware and software.
Which is also the Apple approach. Mac OS is pretty terrible at sleep and wake on non-Apple hardware, but of course it is, Apple doesn't test against hardware they don't support. In both cases it isn't anything wrong with the Linux or Darwin kernels, it's inconsistent implementations and little manufacturer care.
Why would Chrome OS be considered an alternative to Linux? The only thing in common seems to be the kernel running somewhere under the hood.
Just pointing out that Linux can sleep. It's not an inherent issue.
ChromeOS comes out of the box with a full Linux userspace. It has a terminal emulator, X11, software toolchain, and the rest of it.
Last I knew, they did not support hibernate.

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 have experienced this on desktops that I have built. I haven't had this problem on my laptops in a while though. I am running stock Fedora on thinkpads for my past few laptops, and hardware support has been great. I haven't experienced the same hardware issues that I did on my desktop.
Use a thinkpad and avoid problems
Actually, my T480 on Ubuntu 20.04 drains battery drastically while “sleeping”.

I believe it isn’t hitting S3, but I haven’t done too much troubleshooting.

I had some success with T480 sleep battery drain by finding a bios option to turn off all USB when sleeping. Went from empty overnight to can sleep over weekend.
Just tried it and it made no change, thank you for the tip anyway!
Yeah. All the PM stuff with Ubuntu and T480 was a bit of a disaster, there was issues at least with Thunderbolt and NVIDIA discrete graphics eating up the battery. IIRC in the end I think I just found a way to completely disable both.

The T480 I had was a company laptop and I don't have it anymore, so I can't check.

What's your daily driver now, if I may ask? I was seriously considering the T14, but the M1 Air is tempting me.
I now have a P14s, as a weird compromise between what I wanted (14", under 2kg), company requirements for the size class (Lenovo with Intel i7 or i9 and NVIDIA discrete graphics), and what the supplier had available with short notice. Given free choice, I'd probably got a T495 or T14 with AMD.

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.

Try powertop, there are some useful toggles for power savings there. I apply all saving settings automatically with a systemd service
I wouldn't say that Thinkpads are immune. Was braking my brain trying to figure out, why my X230 doesn't sleep properly. Turned out, USB hard drive was causing the issue, even when disconnected. Not sure, if it was hardware or drivers, but that drive was causing issue.
I am using a ThinkPad :)

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.

Windows was that way back in 2000. Some android tablets are like that too.
Windows still does sometimes. I've had two different windows 10 machines constantly wake themselves up (one was at at 1am!) regular as clockwork because a scheduled task you couldn't turn off had gone bonkers.

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've been lucky with Thinkpads. Have you been using Thinkpads?

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.

My 2013 thinkpad on Ubuntu 20 with newest drivers doesn't wake up 1 in 5 tries.

It's frustrating, but at least now that I don't have to leave my house anymore, it doesn't matter too much!

I have this issue with my T470. I'd love to use some Linux distribution, but not waking up brought me back to Windows. A temporary solution was just keeping it on, which used up about 13% of the battery per night, but that's not a long term solution.
my T440, T470 and T495s all do the same thing. Nightmare. I use a mac mini most of the time now though.
The first wakeup issue I had was on a T495... but a software upgrade fixed it thankfully.

Now another software upgrade broke my desktop's waking up which has been working fine for 4 years...

My Thinkpad is the only computer I've ever had hibernate issues with.

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.

I've spent the last decade exclusively on lower-end and more obscure linux laptops. Haven't had a single issue. I'm probably the exception that proves the rule though. I've found that most of the time it's not a linux / kernel issue, it's a udev or config issue. If you write 'mem' to the right file in /proc or /sys (I forget which) they just go to sleep. Any acpi event will wake them back up. I've done this with all sorts of custom kernel configurations on older chromebooks and cheap chinese laptops. Never had an issue. Sleeping to memory works great. Sleeping to disk or 'hybernate' is another story though. You need swap properly configured for that and it's finicky.
Sleep is merely a few commands away. What's to complain about?
My point here is that it's largely not a drivers/support issue at this point. A crazy amount of hardware is supported.
Sleep/wake/hibernate isn't a feature servers, home routers, or a whole host of other Linux powered commercial devices use. That means it doesn't get much attention from Linux kernel developers.

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.

Are you sure this bug was not resolved long ago?

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.

Not by a long shot.

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).

Android phones, tablets and wearables use sleep quite a bit in addition to desktoo and laptop users. Servers at home too often use wake on lan.
Android is not sleeping in a PC sense, all processes still run.
This usef to be the case perhaps. Check out documentation on SystemSuspend and doze mode in current Android.
This is false. Android is famously narcoleptic, if you don't have a kernel wake lock, you sleep. Doze mode is orthogonal to CPU sleep.
The opposite is true, Android sleeps unless something explicitly keeps it awake - i.o.w. a process holds a wake lock. Where PC operating systems go to sleep when there is nothing to do for a while, Android sleeps until being woken by user interaction or scheduled timer events. It then performs the task(s) after which it goes to sleep again. A music player on a PC would keep the machine awake, a similarly built player would stop playing after a few seconds on Android unless the developer made sure to schedule wakeups or used the big hammer of requesting a wake lock. Spurious wake locks used to be a common cause of drained batteries until Android started to put limits on background processes.
I've always found it to be a software problem. There's a lot of software that inhibits the computer from sleeping.

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.

My HP laptop with windows and other desktop with windows both have BIG troubles with waking up. Typically after I accidentally put them to sleep, I have to somehow restart them, otherwise they wake up to black screen. For me, sleeping in windows never worked right, I'm always disabling it on new installs.
Mainly driver issues.

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.

> 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...

I have tried netconsole, but the kernel froze right after PM restored memory from swap.

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.

> That's why I think only an USB debugger cable could help in this case.

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)... ;)

Many times I find I can still ssh into the laptop even if the screen/GPU fails to draw the screen on wakeup
Why do people still use sleep? The lowest power saving modes are basically so great these days I can at least a couple of days out of them without any configuration whatsoever...

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.

Yes. The core reason that linux is horrible in this area is that so few people care about sleep functionality. Sleep was developed when turning on/off a windows computer took minutes (boot, antivirus self-scan, updates to xyz, reboot, scan again etc). A modern linux machine boots in seconds. So the usefulness of sleep/hibernate modes on desktops/laptops has shrunk.
I dislike having to enter my extremely long decryption password every time I boot.

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.

10+10+5=35 seconds, not minutes. As i said, sleep was developed when boot took minutes. So the motivation for this feature has been greatly diminished and is now less of a priority in the linux community.
I don't believe you. This is a community that recompiles kernels for imaginary performance increases. Who would forgo practical increases in speed.

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.

TBH I think the times of kernel recompiles with your personal settings are long gone. Folks these days just run Ubuntu/Fedora/<pick your distro> and that's it.

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.

35 seconds is still kinda ridiculous when you consider the ludicrous speed of modern computers. If every cycle of a single core of a 3Ghz processor were a subjective second, then in that 35 seconds the core experiences a subjective 3327 years.
Half of the 35 seconds in this case is from decrypting a drive and menu screens from having multiples OSs. Removing that and using fast boot BIOS options could easily drop this under 10 seconds.
And time waiting for the wifi to reconnect. That is an entirely different wait cycle.
Yes, my desktop usually boots in around 10 seconds. Or at least feels like 10 seconds; no more. In fact it takes more time for it to wake than to boot from full power off, albeit that says more about Linux sleep/wake support than anything else.

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.

You say that like the decryption steps should be slow. The decryption is orders of magnitude faster than reading from the drive in the first place.

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.

Seriously, why would you complain about this these days? In 2012, I was _impressed as hell_ when the SSD MacBook Air would fully boot OSX in 1 minute 30 seconds, being used to computers taking minutes to start and then spending even more minutes being unusable with the HDD thrashing like hell. These days my Linux desktop computer boots in around 10 seconds (much faster than either Windows or macOS on similar hardware, but at least on windows the boot time improvements have been incredible too). My desktop literally boots in less time than it takes for my DP monitor to power on from zero and start displaying frames.

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.

> Seriously, why would you complain about this these days?

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?

You claim that XP is snappy? Even on a 2020 machine VM, it still takes more time to boot that 10!
I've confused the argument here, because it is true that it does not have an impressive boot time. However, once booted it is significantly more responsive than any modern OS I've ever used.
While CPUs are ridiculously fast, pretty much everything involved in booting a system involves a lot of polling or hard coded waits. Modern peripherals also contain only the barest of firmware in ROM and need the drivers to actually upload their operating firmware.

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.

Even if the system starts quickly enough to not matter that much, keeping state still matters. An IDE, any documents that are open in other applications, possible virtual machines etc. are immediately there where you left them after resuming from sleep, but not after a boot. I also find it easier to resume my mental state when things are as I left them without having to bring them up again.
Frankly that is one of the major advantages of macOS, it's indispensable for me.
Works For Me(TM) on Linux and Windows 10, but macOS has of course been for a long time known for pretty quick suspend and resume.
Most apps on Windows I use at least doesn't have that, I need to reopen apps after a reboot (unless they auto-launch at all boots) and the windows definitively doesn't stay in the same position and have the same contents as before the reboot.

I haven't used Linux desktop lately though, but I'm not aware that they had an API for that.

Ah, you mean session restoration rather than reliable sleep.

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.

> A modern linux machine boots in seconds.

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.

This perspective ignores the actual UX, though.

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)

I think sleep means that the RAM is powered. This is vs hibernation, which is RAM saved to disk and everything is shut down.
because I don't want to open my backpack and be greeted by a furnace and 10% battery left
as someone who also dealt with this and finally decided to just support a linux vendor (system76), i'm glad i did - the extra $$ is worthwhile & it feels much better knowing I supported an open-source friendly company
I've had a couple of Dell XPS13 models over the past ~6 years. Linux on XPS13 for the most part 'just works'. Dell does ship a configuration of XPS13 with Ubuntu, and that's likely the biggest factor in its success.

Plus: it's an attractive design, tiny bezels, super light.

Sleep/wake has been 100% perfect on my X1 Carbon running Linux. Not a single issue since I got the device over a year ago.

Battery drain is higher during sleep than a Mac though.

What distro are you running? What are your UPower settings?
OEMs perform rigorous stress-test cycles during development. For example they might require a machine to suspend+resume 1000 times in a row. This shakes out both OS + driver issues before they go to market. This level of rigor is important to avoid support calls + RMAs, which are expensive for the OEM.

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.

> Why does Linux have so much trouble sleeping and waking?

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.

    Device (PWRB)
    {
        /*
         * Power Button Device.
         * _PRW: Power Resources for Wake.
         */
        Name (_HID, EisaId ("PNP0C0C")
        Method (_PRW, 0, NotSerialized)
        {
            Return (Package (0x02)
            {
                0x00, 
                0x00
            })
        }
    }
Yes, it means what you think it meant, even if you don't speak ACPI.

    power_button_wakeup() {
        return 0;
    }

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.

Isn't InstantGo/ConnectedStandby basically the same thing as S0IX ACPI state? (according to this: https://www.thurrott.com/mobile/microsoft-surface/64867/tryi...)

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.

Thanks for the comment, it's a great suggestion. The Intel documentation is really comprehensive (too bad that it didn't exist back when I was still using the tablet).

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.

Yes, ACPI DSDT being utterly broken seems to be a pretty common trip point for Linux suspend/sleep. For my Dell Precision 5510, I was able to patch[1] a missing device back into the DSDT, as well as 'fix' some thunderbolt port enumeration race condition. The hackintosh community was helpful in providing ACPI dumps from similar enough Dell systems in the same generation that I was able to paste in the missing device to get very consistent S3 performance. 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), 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...

> The hackintosh community was helpful in providing ACPI dumps from similar enough Dell systems in the same generation that I was able to paste in the missing device to get very consistent S3 performance.

+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.

I think that you seriously misunderstand what _PRW method does.

Hint: to execute any code, including quoted ASL, the processors has to be woken up and running in a proper context.

Thanks for point it out. A developer told me that this code snippet was sufficient to conclude that the ACPI wakeup was broken, so I misinterpreted it to be "the method was not defined" (while totally ignored that any AML code must be executed by the OS). Just RTFMed quickly, hopefully I've reached the correct understanding: "_PRW" is a definition of wakeup capability of this power button, the first argument "0x00" means its event is located at register GPE0, bit 0, and the second argument "0x00" means it's capable of waking up the system from ACPI S0 ("power on"), which excluded all low-power states like S3 or S4 - which was probably why I was told that S3 wakeup was broken.
My Lenovo laptop with Pop_OS seems to work just fine - keyboards lights, wake/suspend/flippy screen to tablet mode.

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.

Just find a laptop officially supported by Linux, just like you do with Windows and Mac.
I've been using Linux on Dell laptops (various distributions and desktops, Precision / Inspiron) since the late 90s and it's always just sort of worked, had an IBM Thinkpad along the way as well. As another few comments mention, solid vendor firmware really seems to be a key factor and I prefer ATI/AMD gpu chips for their no-nonsense out of the box performance (I'm not a laptop gamer).
I am also extremenly frustrated by this. Even on my linux-only librem 13, it still occasionaly fails to start after a sleep. Suspend to disk is even worse. If there was a kernel dev out there accepting donations / patreon to fix this, I would be willing to sign up for a decent amount.
Works flawlessly on all of my thinkpads.

In both Linux & BSDs.

Which Thinkpad model and Linux distro? I have a brand new Thinkpad Yoga 9i running a fresh Ubuntu 18.04 and I have to type "systemctl suspend|hibernate" because the power switch ALWAYS powers off. Annoying as heck.
I've experienced no sleep issues on T490 and two Yogas (920 and some 500 series before that, can't remember exact model). Mostly elementary OS, though I've also used Ubuntu GNOME while that was a thing and Ubuntu + pure GNOME shell afterwards.
I have a 7th Gen X1 Carbon and an X270.

Arch & OpenBSD.

Funny because I'm running a ThinkPad X1 Extreme Gen 2, last night I put my laptop down, closed the lid, didn't connect a charger, came back an hour later and my battery was at only 1% and died after opening the lid.

Running Linux 5.9, but it's been doing this on occasion for a while now.

The X1 Extremes are less compatible.

I mean you've got an Nvidia GPU, which is basically a no-go from my perspective.