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

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.

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.

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.

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!

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

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.

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.

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.

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.

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

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.

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

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.

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

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.

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

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.

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.

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

https://youtu.be/kZRE7HIO3vk

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

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.

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.

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

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.

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.

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

Now what is not flawless: There are any number of ACPI things that, if set, will immediately re-wake the computer once suspended. The following script is on my current problematic one as /usr/lib/systemd/system-sleep/wakefix.pl

#!/usr/bin/perl open(FILE,"/proc/acpi/wakeup"); while(<FILE>) { chomp; if(/enabled/) { ($a,$b) = split / /; system("echo $a >/proc/acpi/wakeup"); } }

[Sorry about the mangled formatting]

It just turns off everything that is enabled to wake the machine up. As this list happens not to include the power button - the only thing I want to be able to wake the laptop up - this works fine.

I've never experimented with auto-suspend on lid close and auto-resume on open; maybe that's what's more troublesome.

Another thing that's not suspend-resume, but nonetheless annoying - if the machine is running an SDL fullscreen thing (Tuxpaint) or if the MATE desktop has a pop-up menu open, the power button won't suspend the computer, because something intercepts the button press.

My experience with suspend/resume on Desktop machines has been 100% bad, on the other hand. Usually they suspend just fine, but don't resume to a usable state.

That's what 99% of all laptop users would like a laptop be able to do, no? At the very least auto-suspend on close.

That's the main reason I can't even be bothered to configure this (as in from the GUI) on my Linux machines.

My use case is in direct contrast to the 99%, and with Linux being focused on a technical audience, it gets short shrift in terms of priorities/ resources.

(honestly, most of my computers are generally set to no automatic sleeping/ suspension)

Even now, turning off or disconnecting my Bluetooth headphones causes my modern/up-to-date Linux machines to reawake if they were connected before sleep, which inevitably causes my monitors to come back online and fill my room with light and fan noise while I'm trying to put _myself_ to sleep...

I have a habit now of just running:

    systemctl suspend -i

Right? It's like, trying to suffocate itself. I just turn the damned thing off before going home now.

If I get it right, it's saying that Linux is intentionally bad at shutdown / hibernation because that's how its users want it. And users want it because they are better users than other users: they are "professionals", whose computers never sleep.

So, if you are using an OS that actually works as expected, that's just proof that you're an amateur.

(and let's ignore the mention of the lid being closed. Because that would be devastating to this argument)

At no point did I say users want it to be bad at shutdown/hibernation.

I said for my job/use-case, I spend most of my time trying to stop the computer from sleeping. I posted this because the comment I was responding to said that 99% of users wanted the computer to sleep on lid-shut, and I thought I'd contribute to point out that's the opposite of my use case (indeed, I pretty much want the computer to never sleep on lid-shut). And i run linux as the primary OS on pretty much all my computers. A lot of linux users are also probably coming from a background where computers didn't sleep/shutdown very often.

I didn't use the word amateur. I didn't use the word professional. I didn't mention anything about using an OS that works as expected. I listed my background and use case.

I didn't say anything about any users being better than others.

I do think, based on all that, you may have some sensitivities that made you interpret things in a particular light.

on lid close being the operative term here.

The first line seems to disagree that there's any issue, says it has been "flawless". Then goes on to list what I would certainly consider some very big flaws which can only be partially worked around with custom shell scripts and the like.

Suspend/resume to memory and to disk have been exceedingly reliable on every machine I've touched for a decade for me. On my old Dell convertible laptop, the wifi would only turn on every other time it woke up.

The machines waking up is a real problem. I have `HandleLidSwitch=ignore` in systemd's logind.conf[1]. I see there are other options though, which I might also try setting to ignore. I too sometimes have unexpected wakeups. I'd like to learn more about how to debug these. I've asked twice on IRC & gotten no reply. My backup plan has been to write a daemon to make the system go to sleep, and whenever it wakes up, put it back to sleep, unless I "disarm" the daemon. I'm in a fairly low-visibility environment now though- I feel like I should work the problem some, fix whatever is going wrong, rather than hack around, but I have not been successful at figuring out second steps in debugging systemd daemons, once `systemd status` & upping the logging level falls short.

I too have problems with some desktop things intercepting my power button, which again, I wish I had better visibility in to. I don't know other than trial & error to figure out who might be grabbing the input devices.

[1] https://www.freedesktop.org/software/systemd/man/logind.conf....

Kind of like cryonics then?

And people actually expect Linux to win over the desktop crowd when it can’t support even the most basic features consumers expect.

Hibernate has been a bit tricky for me. But a few months ago I have finally found a solution that has since worked on all Ubuntu 18.04 and later machines I have tried it on.

Described in detail in a blog post at https://tkainrad.dev/posts/setting-up-linux-workstation/#hib...

Commands and config there can be copy-pasted and should hopefully fix any hibernation problems.

It depends on explicitly creating a large enough swapfile and setting the UUID and offset in the grub configuration.

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

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.

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

I love the laptop a lot, but the sleeping isn't as dependable as my Mac was.

Overall the laptop has performed well running Linux, although I must say, the Nvidia GPU is a massive let down from a driver / support perspective. I'll never buy a Laptop with an Nvidia GPU again so long as I run Linux or probably ever because they treat open source like crap.

In the interest of giving a fair review, I'll explain why this laptop falls short with an Nvidia GPU (in my view), it might even explain why the sleep issues:

Basically the USB-C ports are hardwired directly to the Nvidia GPU, this is so the GPU drives external monitors. Which is fine, but what's not fine is that the GPU must be on an enabled permanently to use an external monitor.

If I turn off the GPU, the external monitors can't be used.

I can turn off the GPU by changing modes (dramatically improving battery time and life), but this means I need to go change my X configuration, login and log out. So either having good battery life, or working at my desk is a compromise, because it's highly inconvenient to change settings and reboot.

It basically lets the entire machine down when it comes to functioning as a Laptop. Apparently there is talk the drivers might support the offloading behaviour one might expect in the future. To be able to drive external monitors just using the integrated graphics.

The HDMI port might not be hardwired, but I'm not really interested in using that as I like the USB-C port because I use my monitor as a USB Hub / docking station.

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.

That said I haven't had a single suspend/wakeup issue with my Linux machine in years, I even find Windows considerably more buggy and unstable in this respect.

My suggestion is that you run Linux on laptops that everybody else buys. These days the famous ones are Dell XPS and Lenovo Thinkpad.

Also, please make sure you report your issues. Regressions on S3 are often common. Unfortunately developers lack properly testing S3, because it's difficult to test.

Oh, and forget Hibernation (S4). It's crap and it's just never going to work fine. It's not even worth it since the machines boot fast.

You're right in saying that it's better on these systems with later kernels, I do remember a time when I was younger and buying the wrong laptop without suspend support though :)

Seem to, but windows also has these problems, for example https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X1-Ca... https://forum.thinkpads.com/viewtopic.php?t=127945

It's funny, I don't have a problem with sleep/wake on my 6.5 year old HP laptop under Linux but on Windows 10 it can't seem to ever stay asleep. It loves to wake up at random times and stay awake, even when it is only on battery.

With that said, Linux can't successfully manage the laptops P-States. I have to force the system to just not manage them under Linux because it will randomly lockup.

Fortunately, I don't normally live in Windows, so I have little desire to spend much time hunting down and fixing the problem.

Battery drain is higher during sleep than a Mac though.

In both Linux & BSDs.

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.

Arch & OpenBSD.

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

It probably works so well on my T530 since it's an 8 year old thinkpad.

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.

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

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

    power_button_wakeup() {
        return 0;
    }

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.

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.

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.

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

Incidentally I had this very problem when using Mac Os on a Macbook 2015 and I couldn't do much about it. When I started using linux on said Macbook at least I could disable ACPI signals.

The first thing I do in any linux laptop I own is disable all ACPI signals and setup a script to do so at every boot. Then you just need to have a DE to suspend after X amount of inactivity (often the default) and you're set.

Sure, you won't turn off/on your laptop by closing the lid, but it should work fine, turning on / off with power button.

This would be a better machine all around anyway. You could close it with ssh sessions open and open it again and they're still open. You could run P2P software in the background and it would never have to re-bootstrap. You could connect to it remotely to access files any time. Computers that turn off all the time suck.

My windows computers will wake up less than 5 minutes after going to sleep but I've left my linux systems on sleep for days and sometimes weeks at a time with no problem at all.

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.

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.

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.

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.

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?

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.

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)

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.

It's incredibly annoying. Sometimes I put a PC to sleep, and it will wake up a minute later. Sometimes it wakes up in the middle of the night to spin up its fans. Laptops I put to sleep without being hooked up to power will have their battery drained next time I want to use them. I can't imagine any OS being worse at sleeping than Windows.

[1] https://answers.microsoft.com/en-us/windows/forum/windows_10...

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.

Here's my kernel log from today's a failed wake-from-suspend. https://bpa.st/VIPQ

Linux 5.4.81 with amdgpu

I notice in particular:

    kernel: amdgpu 0000:09:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring gfx test failed (-110)
    kernel: BUG: kernel NULL pointer dereference, address: 0000000000000008

> Ahzo 2019-10-11 18:33:10 UTC

> bisection between these two, while backporting 533aed278afe on every step, lead to commit 2a91f272e34c, which failed to boot and thus had to be skipped, and commit e0128efb08b3d628d767ec8578e77cdd7ecc8f81 looks like a likely root cause. Indeed, adding 'return 0;' at the beginning of uvd_v6_0_enc_ring_test_ib makes the problem unreproducible, even on the latest linux 5.4-rc2.

And,

> Ahzo 2019-10-11 18:37:48 UTC

> By the way, some of the kernel NULL pointer dereferences, that can happen after a resume failure, also happen always on shutdown. Attached patch prevents them.

Do you know how to build a kernel? I suggest you to build Linux 5.4 (you can avoid reconfiguring the kernel by using /proc/config.gz) with the code workaround (adding 'return 0;' at the beginning of uvd_v6_0_enc_ring_test_ib) applied, and see whether it fixes your problem. You should also check the NULL pointer patch and see whether it's already included in the source code by manual inspection, if not, also apply the patch. If it fixes your problems, report it to the Bugzilla thread.

Nevertheless, I still recommend you to try reproducing it in Linux 5.9 first and see whether you can reproduce the original problem. The comments in Bugzilla suggests that the latest kernel has already fixed the issue.

> Alex Deucher 2020-10-01 14:59:58 UTC

> The original issue reported in this bug was fixed long ago.

If Linux 5.9 fixes it, good. If not, see whether the error messages are different. If so, you should chase the new issue instead of the original issue.

---

[0] https://bugzilla.kernel.org/show_bug.cgi?id=204241

I don't know anything specific about AMDGPU, but if I were you, the first step I'd always try is to reproduce it in the latest mainline kernel, it's currently 5.9. Check the documentation of your distribution to see how can you get one. Often a partial fix exists in a newer kernel, and you may be able to identify and debug a different part of the issue.

The people who write that firmware code test a lot to make sure it works when the device is programmed the way Windows programs it.

If Linux turns out to use the device in a different way the procedure is untested and often this firmware is very buggy which is why it isn’t reliable.

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.

Buy a Thinkpad, Zenbook, Dell XPS, System76 laptop or some model known to have good Linux support next time.

Can't remember any problems like this in the last decade, but I always, always research Linux compatibility before buying any hardware.

Either the battery is empty when I open it again, or it somehow shut itself down and boots anew with battery intact.

What are you talking about? Sleep and hibernation can keep the state of the computer on next use.

Glad you can boot quickly but that's not the point.

I came from Linux laptops to MacBooks 6 years ago and that was such a big improvement. Not having to think about where I’m pausing my work. Even with the Linux laptop only failing to wake up about 20%. Although sometimes it’d fail to sleep and empty my battery and heat my backpack.

I also never had problems with suspend. Resume is a different story, though.

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.