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

Re: Actually been fixed.

Date: 2016-04-15 07:38 pm (UTC)
kensey: (Default)
From: [personal profile] kensey

At least this is less bad than when I got a Broadwell i7 5700hq laptop last year and the microcode-based TSX issues were so bad I could only boot Fedora 22 for a month stably (it would crash under any load) until MSI (the ones I bought it from) were the first out with a fixed microcode update.

Funny you should mention -- my Sager work laptop has an i7-5700HQ, and Fedora 22 runs fine on it, but 23 crashes within seconds to minutes. For now I'm just continuing to run F22, but I also can't run any VMs or containers that contain a libc that tickles the TSX issue or my laptop reboots!

Eventually I'll have to buckle down and figure out how to apply one of the firmware updates floating around out there that supposedly fix this (I think actually the one most commonly used came from MSI's updater), because neither Sager nor Clevo (the hardware OEM) has put out any firmware updates for it, and I don't want to be stuck running F22 past its end-of-support.

Re: Actually been fixed.

Date: 2016-04-15 09:31 pm (UTC)
From: [personal profile] gourdcaptain
Yeah, I had that issue, although luckily I had the MSI laptop those updates came from.
https://github.com/bgw/bdw-ucode-update-tool - Someone's attempt to hack together an updater for those.
Unfortunately, all my experience with messing with microcode packages is on Arch where I can just stick it in my systemd-boot config as another initrd before the main one. Which I know you can do with GRUB as well, it's just GRUB's config files are hilariously complicated, IMHO.

Honestly, the lack of updates is a shame upon your hardware vendor, given that it even affects things under Windows - apparently Office 2016's installer, even.

EDIT: Nothing against Fedora, but I had to get off it as soon as possible because while I like a lot of the stuff it does as a distro, nobody'd packaged Bumblebee and CUDA in a way where you could get both on the same system (and I needed both at the time for work urgently) - all the CUDA packages had a hard dependency on a normal NVIDIA driver install. (Primarily because the guy doing it sees Bumblebee as a "dirty hack" that shouldn't be supported. Okay, buddy, you got any other options for making this hardware work in the meantime?) Arch is the only distro I've found which DOESN'T have a NVIDIA driver dependency for the CUDA package, which is pretty handy for being able to run the CUDA debugger on a laptop remotely connected to your system with an NVIDIA card.
Edited Date: 2016-04-15 09:36 pm (UTC)

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Member of the Free Software Foundation board of directors. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags