1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking Benchmarking Platform
Phoromatic Test Orchestration

The Leading Cause Of The Recent Linux Kernel Power Problems

Michael Larabel

Published on 26 June 2011
Written by Michael Larabel
Page 2 of 3 - 144 Comments

Without further ado, the biggest cause of the 2.6.38 power issue (according to my testing software and the hardware I've been running) is due to a change in behavior regarding ASPM. ASPM is the Active-State Power Management for PCI Express. Namely, to blame is commit 2f671e2dbff6eb5ef4e2600adbec550c13b8fe72 that is titled "PCI: Disable ASPM if BIOS asks us to."

"We currently refuse to touch the ASPM registers if the BIOS tells us that ASPM isn't supported. This can cause problems if the BIOS has (for any reason) enabled ASPM on some devices anyway. Change the code such that we explicitly clear ASPM if the FADT indicates that ASPM is not supported, and make sure we tidy up appropriately on device removal in order to deal with the hot-plug case. If ASPM is disabled because the BIOS doesn't hand over control then we won't touch the registers."

This change is what was made during the Linux 2.6.38 merge window, pushed mainline in early January, and is causing increased power usage on a plethora of systems. Active-State Power Management is a feature that is supposed to save system power by setting a lower power state for unused PCI Express links. The downside to ASPM is that it can increase device latency due to the time required in switching PCI-E link power modes, but on the positive side it's capable of saving a fair amount of power, which can make it worthwhile for mobile systems. ASPM can work on desktops too, but it is not as common there due to the possible increase in latency when switching states. With the 2.6.38 commit that is noted, if the BIOS indicates it does not support ASPM, the behavior is changed.

Evidently, some BIOSes have their ASPM support misconfigured and thus problems can arise if the PCI-E link power mode is dropped on an unsupported device. There are a few mentions of hangs and other issues under Linux associated with this power management feature. It's not really a surprise though that the BIOSes would be misconfigured given all of the other BIOS-related problems under Linux and the once very poor suspend-and-resume support due to all of the workarounds and hacks that BIOS/hardware vendors have done to cater towards Microsoft Windows power management. In this case, it seems a large number of mobile systems are supporting ASPM but not properly advertising the support via the standard BIOS ACPI FADT (Fixed ACPI Description Table). Some Linux drivers even forcibly disable ASPM on Linux (e.g. this kernel patch).

With this being a PCI Express power management bug, the number of systems potentially affected is massive and doesn't isolate the problem to those just using a select driver or obscure configuration. PCI-E ASPM is mostly used on mobile systems, but on at least some desktop systems I have seen the power consumption affected by this issue.

Given the thousands of users having this 2.6.38 power regression by this change, there is a big ASPM problem at hand. Fortunately, as PCI-E ASPM problems are not new, a few boot options can be used. Namely, most people affected by this issue will want to add "pcie_aspm=force" to their boot command line. Simply adding this will force Active-State Power Management to be enabled. This is supported before the Linux 2.6.38 kernel (looks to be going back to circa 2.6.27) and it is still supported today in the latest upstream Git. Just adding that to 2.6.38+ kernels on the systems I have tested will workaround this problem-causing commit and lead to noticeable power savings.

Latest Linux News
  1. Phoronix Test Suite 5.8 Milestone 5 Brings Near Final "Belev" Experience
  2. For AMD Users, Linux 4.2 Will Bring The New AMDGPU Driver & VCE1 For Radeon
  3. Atomic Mode-Setting Still Baking For Samsung's Exynos DRM Driver
  4. Ubuntu Phone Update This Month Brings Many Improvements
  5. Fedora's "Fedup" To Be Replaced In Fedora 23
  6. Android M Should Bring Greater Performance & Efficiency
  7. AMD Teases Upcoming Radeon "Fiji" GPU Launch
  8. Dell Makes An Ubuntu Installation Guide, Suggests Users Try It Out
  9. Running Linux On The Intel Compute Stick
  10. AMD Launches The A10-7870K "Godavari" APU
Latest Articles & Reviews
  1. Opening The Gates To Our Daily Open-Source Linux Benchmark Results
  2. The Latest Features For Linux Performance Management + Benchmark Monitoring
  3. Noctua NH-U12DX i4 + NF-F12
  4. Btrfs RAID 0/1 Benchmarks On The Linux 4.1 Kernel
Most Viewed News This Week
  1. The Linux 4.0 EXT4 RAID Corruption Bug Has Been Uncovered
  2. NVIDIA's Proprietary Driver Is Moving Closer With Kernel Mode-Setting
  3. Systemd 220 Has Finally Been Released
  4. Zapcc Claims To Be A "Much Faster C++ Compiler"
  5. LibreOffice 5.0 Beta 1 Released
  6. OpenWRT 15.05 Preparing Improved Security & Better Networking
  7. Features Added To Mesa 10.6 For Open-Source GPU Drivers
  8. Ubuntu's LXD vs. KVM For The Linux Cloud