[personal profile] mjg59
(Edit to add: this issue is restricted to the mobile SKUs. Desktop parts have very different power management behaviour)

Linux 4.5 seems to have got Intel's Skylake platform (ie, 6th-generation Core CPUs) to the point where graphics work pretty reliably, which is great progress (4.4 tended to lose all my windows every so often, especially over suspend/resume). I'm even running Wayland happily. Unfortunately one of the reasons I have a laptop is that I want to be able to do things like use it on battery, and power consumption's an important part of that. Skylake continues the trend from Haswell of moving to an SoC-type model where clock and power domains are shared between components that were previously entirely independent, and so you can't enter deep power saving states unless multiple components all have the correct power management configuration. On Haswell/Broadwell this manifested in the form of Serial ATA link power management being involved in preventing the package from going into deep power saving states - setting that up correctly resulted in a reduction in full-system power consumption of about 40%[1].

I've now got a Skylake platform with a nice shiny NVMe device, so Serial ATA policy isn't relevant (the platform doesn't even expose a SATA controller). The deepest power saving state I can get into is PC3, despite Skylake supporting PC8 - so I'm probably consuming about 40% more power than I should be. And nobody seems to know what needs to be done to fix this. I've found no public documentation on the power management dependencies on Skylake. Turning on everything in Powertop doesn't improve anything. My battery life is pretty poor and the system is pretty warm.

The best thing about this is the following statement from page 64 of the 6th Generation Intel ® Processor Datasheet for U-Platforms:

Caution: Long term reliability cannot be assured unless all the Low-Power Idle States are enabled.

which is pretty concerning. Without support for states deeper than PC3, Linux is running in a configuration that Intel imply may trigger premature failure. That's obviously not good. Until this situation is improved, you probably shouldn't buy any Skylake systems if you're planning on running Linux.

[1] These patches never went upstream. Someone reported that they resulted in their SSD throwing errors and I couldn't find anybody with deeper levels of SATA experience who was interested in working on the problem. Intel's AHCI drivers for Windows do the right thing, but I couldn't find anybody at Intel who could get any information from their Windows driver team.

SATA PM Patches

Date: 2016-04-13 10:09 pm (UTC)
From: (Anonymous)
I've read your blog post about SATA PM when it was fresh, saw your patches on LKML and thought: well, everything is on it's way. Also mentioned Panel Self Refresh and friends for i915 are slowly getting in mainline, so I thought we might get to a point, where power comsumption would get in a good state and that i should spend some time optimizing my Haswell notebook again. I tried but mostly gave up and thought I needed to wait some more time. Now I just learned your SATA patches were never merged, which makes me sad about pm in Linux again :(

I'm just a user, no expert at all, but If there is a possibility to give mainlining that patches another shot, i would be absolutely thankful.

Keep up the good work Mathew, it's really appreciated. You solved a lot of problems for us Linux users! :)

Regards!
Wilken Haase
parttime happy linux user

Re: SATA PM Patches

Date: 2016-04-14 01:16 am (UTC)
From: (Anonymous)
The issue with SATA ALPM is that enabling that will interact badly with several SSDs, triggering *data destroying* firmware bugs in those SSDs.

And we're not talking el-cheap-o crap SSDs either, several models from Micron (datacenter) and Crucial (consumer) are included, for example... and not all of them have firmware updates that address this.

And yes, such issues do exist under the Intel ISRT Windows drivers. You really can't enable SATA ALPM by default if the device identifies itself as a SSD. I don't know if the issues with HDDs and ODDs is better, either.

Re: SATA PM Patches

Date: 2016-04-14 08:26 am (UTC)
From: (Anonymous)
1. Does this also apply to "firmware defaults" settings?

2. What does Windows do by default?

3. If the problem is with SSDs, then why we can't modify that patch to only apply to !SSD?

Re: SATA PM Patches

Date: 2016-04-14 10:23 am (UTC)
From: (Anonymous)
I thought that current RST Windows drivers do enable LPM by default. They certainly must have a long black-/whitelist though.
I guess the goal should be to do the same on Linux. There is already ATA_HORKAGE_NOLPM in libata-core.c to mark drives with broken LPM, so if you know such drives that aren't in ata_device_blacklist in libata-core.c yet, please report and/or send a patch!

Re: SATA PM Patches

Date: 2016-04-16 01:53 am (UTC)
From: [identity profile] hobbs.cleverdomain.org
Everyone else has "quirks", but libata has "horkages"? I love it.

Re: SATA PM Patches

Date: 2016-05-22 11:18 pm (UTC)
From: (Anonymous)
It would be nice if affected models would be named, at least people would be aware or steer clear of those models.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. [personal profile] mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.

Page Summary

Expand Cut Tags

No cut tags