Few years back I wrote about running Linux on a MacBook Pro. An year ago, the OpenSuse failed to boot on the Mac. Little bit of debugging, I realized the problem isn't in the hardware. That particular kernel update simply didn't work on that particular hardware anymore. Totally fair, who would be stupid enough to attempt using 8 years old laptop. Well, I do.
There aren't that many distros I use and I always wanted to see Fedora Workstation. It booted from USB and also, unlike OpenSuse Leap, it also booted installed. So, ever since I've been running a Fedora Workstation on encrypted root drive.
One glitch, though. It didn't always sleep wake. Quite easily, I found stories of a MBP not sleeping. Here's one: Macbook Pro doesn't suspend properly. Unlike that 2015 model, this 2013 puppy slept ok, but had such deep state, it had major trouble regaining consciousness. Pressing the power for 10 seconds obviously recycled power, but it always felt too much of a cannon for simple task.
Checking what ACPI has at /proc/acpi/wakeup:
Device S-state Status Sysfs node
P0P2 S3 *enabled pci:0000:00:01.0
PEG1 S3 *disabled
EC S4 *disabled platform:PNP0C09:00
GMUX S3 *disabled pnp:00:03
HDEF S3 *disabled pci:0000:00:1b.0
RP03 S3 *enabled pci:0000:00:1c.2
ARPT S4 *disabled pci:0000:02:00.0
RP04 S3 *enabled pci:0000:00:1c.3
RP05 S3 *enabled pci:0000:00:1c.4
XHC1 S3 *enabled pci:0000:00:14.0
ADP1 S4 *disabled platform:ACPI0003:00
LID0 S4 *enabled platform:PNP0C0D:00
For those had-to-sleep -cases, disabling XHC1 and LID0 did help, but made wakeup troublesome. While troubleshooting my issue, I did try if disabling XHC1 and/or LID0 would a difference. It didn't.
Also, I found it very difficult to find any detailed information on what those registered ACPI wakeup -sources translate into. Lid is kinda obvious, but rest remain relatively unknown.
While reading System Sleep States from Intel, a thought occurred to me. Let's make this one hibernate to see if that would work. Sleep semi-worked, but I wanted to see if hibernate was equally unreliable.
Going for systemctl hibernate didn't quite go as well as I expected. It simply resulted in an error of: Failed to hibernate system via logind: Not enough swap space for hibernation
With free, the point was made obvious:
total used free shared buff/cache available
Mem: 8038896 1632760 2424492 1149792 3981644 4994500
Swap: 8038396 0 8038396
For those not aware: Modern Linux systems don't have swap anymore. They have zram instead. If you're really interested, go study zram: Compressed RAM-based block devices.
To verify the previous, running zramctl displayed prettyy much the above information in form of:
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 7.7G 4K 80B 12K 8 [SWAP]
I finally gave up on that by bumping into article Supporting hibernation in Workstation ed., draft 3. It states following:
The Fedora Workstation working group recognizes hibernation can be useful, but due to impediments it's currently not practical to support it.
Ok ok ok. Got the point, no hibernate.
Looking into sleep wake issue more, I bumped into this thread Ubuntu Processor Power State Management. There a merited user Toz suggested following:
It may be a bit of a stretch, but can you give the following kernel parameters a try:
acpi=strictnoapic
I had attempted lots of options, that didn't sound that radical. Finding the active kernel file /boot/vmlinuz-5.18.18-200.fc36.x86_64, then adding mentioned kernel arguments to GRUB2 with: grubby --args=acpi=strict --args=noapic --update-kernel=vmlinuz-5.18.18-200.fc36.x86_64
... aaand a reboot!
To my surprise, it improved the situation. Closing the lid and opening it now works robust. However, that does not solve the problem where battery is nearly running out and I plug the Magsafe. Any power input to the system taints sleep and its back to deep freeze. I'm happy about the improvement, tough.
This is definitely a far fetch, but still: If you have an idea how to fix Linux sleep wake on an ancient Apple-hardware, drop me a comment. I'll be sure to test it out.