Why does Linux have so much trouble sleeping and waking?

Re:Why does Linux have so much trouble sleeping and waking? by segfaultbuserr on Friday December 11, 2020 @10:11AM (#25386605)

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

[ Parent | on HN ]

Re:Why does Linux have so much trouble sleeping and waking? by halz on Friday December 11, 2020 @01:11PM (#25388735)

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

[ Parent | on HN ]

Re:Why does Linux have so much trouble sleeping and waking? by segfaultbuserr on Friday December 11, 2020 @01:50PM (#25389197)

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

[ Parent | on HN ]

Re:Why does Linux have so much trouble sleeping and waking? by gobblegobble2 on Friday December 11, 2020 @12:01PM (#25387913)

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.

[ Parent | on HN ]

Re:Why does Linux have so much trouble sleeping and waking? by segfaultbuserr on Friday December 11, 2020 @12:11PM (#25388034)

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.

[ Parent | on HN ]

Re:Why does Linux have so much trouble sleeping and waking? by agapon on Friday December 11, 2020 @05:32PM (#25392362)

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.

[ Parent | on HN ]

Re:Why does Linux have so much trouble sleeping and waking? by segfaultbuserr on Friday December 11, 2020 @08:11PM (#25394135)

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.

[ Parent | on HN ]