Sounds like a duplicate of #458. The latest version (v5.14.9) should improve things a bit.

I saw #458 however it seemed to be more about suspend and S0ix.

@qzed I just updated to v5.14.9, I will let you know if its working well in a couple hours to a day.

If I understand you correctly the main issue is that you close the lid and then the device consumes a lot of power even though it should be suspended. That should hopefully be addressed in the v5.14.9 (thanks to a ton of work by @nakato). Prior to that, a mis-configured interrupt kept the device awake and busy, leading to the high power consumption.

The problem that it doesn't hibernate after a couple of hours is a separate thing and should be something you can configure. Have a look at systemctl suspend-then-hibernate.

One issue that is remaining on all Surface devices is that the device will not auto-wake on low battery (needed for auto-hibernation on low battery), because that needs event filtering. I haven't figured out how to do that yet without waking the device up completely, which then leads to a ton of spurious wakes (read device won't stay suspended longer than ~5 minutes).

Interesting, I appreciate all the help and work that you have done.

It seems that the v5.14.9 is working great for the power consumption, however I have not been able to test the hibernation yet.

I can see how the low battery hibernation would be a pain to implement.

Confirmed. 5.14.9 fixes the suspend power draw. Keyboard backlight turns off as well. Thank you @qzed and @nakato !

@professor-rage Have you been able to test hibernation yet? I haven't seen my laptop go into hibernation yet. However the suspend works great.

@DrBrad I have not. I think that requires some configuration to enable in popos, and with suspend working so well now (still at 100% battery after 2 hours in suspend), I don't have a need to. I thought my battery indicator wasn't working when it still showed 100%! I don't mind trying it out for you, but will need instructions enabling hibernate on popos 21.04. Cheers

I realized my PC was crashing when it was trying to hibernate because I forgot to set my swap space when installing my OS.
I just set my swap space to 8GB, I should be able to test it now.

Ah yes. Curious why you pick hibernate over suspend? I avoid hibernate like the plague primarily because of wear concerns with the ssd . 16gb ram, 16gb write to swap every hibernate? Ty.

I prefer having hibernation over a complete power off, I'm okay with buying a new SSD for around $200 if it means a bit of ease of life for a couple years.I rarely let it die, however when it does I don't want to restart everything.

I like using suspend then when almost dead hibernate.

@DrBrad I have not. I think that requires some configuration to enable in popos, and with suspend working so well now (still at 100% battery after 2 hours in suspend), I don't have a need to. I thought my battery indicator wasn't working when it still showed 100%! I don't mind trying it out for you, but will need instructions enabling hibernate on popos 21.04. Cheers

I have never used popos, so I wouldn't be able to help ya there haha.

Just a small note on hibernation and disk wear: You're almost never writing the full amount of ram to disk. It should only be what you're using at that time and then that's also being compressed. See e.g. Arch wiki on how you can influence the size (trade-off size vs. speed). The Gentoo wiki mentions that a size half of available ram should be enough most of the time (IMHO you'd probably get away with 4G on a 16G machine if you don't have a lot of stuff running when hibernating). With the advances in SSD technology I'm pretty sure that this should be fine. Also failure modes of the SSD are a lot more graceful, AFAIK most SSDs these days should lock down into read-only mode when the write cap is hit (so still going to be quite annoying but an improvement over HDDs; also please don't take this as reason to not back up your important data).

Ideally we'd indeed have a way that the device wakes up when it's almost out of battery. Then UPower (included in every major distro) or something comparable will notice and trigger hibernation. AFAIK that's how it should work and does work on other devices. But as said above, that's hard to do on the Surface lineup due to the need for filtering events while also not fully waking up the device.

I do still want to figure out how to make the event filtering work, but that will take some time that I don't have right now. So for now your best bet is to set up suspend-then-hibernate as suspend target (and set the hibernation timeout to whatever you prefer).

@qzed thanks for the detailed explanation. Great to know about the compression.

Also, separately, my light usage estimates show between 8 and 10 hours on a full charge after powertop --auto-tune . Given the surface 15" has a smallish 45Wh battery, really happy with that runtime.

With regards to powertop (and the likes) just keep in mind that if you experience any weird issues (like some devices not behaving properly, sensors not updating, timeout errors) to check if that might be causing it (in such a case the solution would be to mask the offending device, also maybe open an issue here). These days things should be quite stable and I don't expect any major issues with powertop, but there has been some weird behavior in the past and unfortunately issues caused by runtime power-management aren't particular easy to track down. Again, just a heads-up in case you experience anything out of the ordinary.

#624

As far as I have seen, which it has been allot of testing just to pin down what the issue is or what is causing the broken suspend. It seems as though if you have grub amd_iommu=off and iommu=off or if you have amd_iommu=force-isolate the suspend is unresponsive on resume. However if you have nomodset enabled aka disabling the amd drivers the suspend works fine.

Update of v5.15.5 persists.