A Comment On The Linux 2.6.38 Power Regression

[DanaG]

If the BIOS is enabling ASPM on a port, despite claiming not to support it, should we consider keeping it enabled?

[allquixotic]

Tomorrow is a look at the Catalyst vs. Radeon DRM/KMS power consumption in different power management modes.

Looking forward to this. Even with ASPM enabled, I think Catalyst is gonna slaughter the open source drivers here, unfortunately. Performance is getting more and more competitive, but power consumption isn't. I can feel the heat difference in my room between how much my big card (HD5970) puts out, when running Catalyst vs. the open source drivers. Even just using kwin and no other 3d apps, my card gets as hot as it does when playing a AAA DirectX 11 title on Windows.

[Smorg]

Jun 27 19:01:51 smorg kernel: [    0.912182] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Jun 27 19:01:51 smorg kernel: [    0.912293] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
Jun 27 19:01:51 smorg kernel: [    0.912322] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
Jun 27 19:01:51 smorg kernel: [    0.912336] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P6._PRT]
Jun 27 19:01:51 smorg kernel: [    0.912350] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P8._PRT]
Jun 27 19:01:51 smorg kernel: [    0.912367] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT]
Jun 27 19:01:51 smorg kernel: [    0.912380] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE3._PRT]
Jun 27 19:01:51 smorg kernel: [    0.912393] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT]
Jun 27 19:01:51 smorg kernel: [    0.912409]  pci0000:00: Requesting ACPI _OSC control (0x1d)
Jun 27 19:01:51 smorg kernel: [    0.912435] Unable to assume _OSC PCIe control. Disabling ASPM
Jun 27 19:01:51 smorg kernel: [    0.918144] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 *11 12 14 15)
Jun 27 19:01:51 smorg kernel: [    0.918309] ACPI: PCI Interrupt Link [LNKB] (IRQs *5)
Jun 27 19:01:51 smorg kernel: [    0.918386] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 *10 11 12 14 15)
Jun 27 19:01:51 smorg kernel: [    0.918549] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12 *14 15)
Jun 27 19:01:51 smorg kernel: [    0.919238] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 *15)
Jun 27 19:01:51 smorg kernel: [    0.919401] ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 6 7 10 11 12 14 15)
Jun 27 19:01:51 smorg kernel: [    0.919562] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 6 *7 10 11 12 14 15)
Jun 27 19:01:51 smorg kernel: [    0.919724] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 *4 6 7 10 11 12 14 15)

So is that doing the right thing or just guessing?

[tettamanti]

Jun 27 19:01:51 smorg kernel: [    0.912409]  pci0000:00: Requesting ACPI _OSC control (0x1d)
Jun 27 19:01:51 smorg kernel: [    0.912435] Unable to assume _OSC PCIe control. Disabling ASPM

So is that doing the right thing or just guessing?

It means that Linux is asking the BIOS to hand off the management of ASPM using _OSC (operating system capabilities) method; the BIOS returns a mask acknowledging the transition from platform to OS control and in this case it's actively refusing to transfer control. The problem is that there's no way of knowing whether the firmware is really managing ASPM or it's lying.

[AlbertP]

But how does Windows know when to enable ASPM? Do hardware manufacturers put that into their drivers?

Maybe we should make a whitelist of ASPM-compatible devices that will always be forced to use ASPM, even when the BIOS doesn't advertise it.
What about putting a script on internet that uploads ASPM data from computers with a proper BIOS (yes, they exist !)?
Then volunteers from all over the world can, without too much technical knowledge, send their ASPM data. And then it can be put into the kernel.

[jbarnes]

You can do things to help:
- test your system with ASPM forced on (see previous articles on that)
- test each device to make sure it operates properly after given time to transition into different ASPM states

Assuming things work well for you, ping the appropriate driver maintainers for the devices in your system indicating that ASPM can safely be enabled for your devices (ideally with patches attached; see the e1000e driver for examples of how a driver can configure ASPM directly).

[RealNC]

You can do things to help:
- test each device to make sure it operates properly after given time to transition into different ASPM states

How do we know when a transition occurs? Also, I assume the "Unable to assume _OSC PCIe control. Disabling ASPM" warning is misleading and can be ignored?

[jbarnes]

How do we know when a transition occurs? Also, I assume the "Unable to assume _OSC PCIe control. Disabling ASPM" warning is misleading and can be ignored?

Yes, if you set the force option, you can ignore this message.

[RealNC]

Yes, if you set the force option, you can ignore this message.

I asked because this message does not appear if I don't set the force option. So most users will use the force option, and then (and *only* then) they will be told "Unable to assume _OSC PCIe control. Disabling ASPM". As you can imagine, this is extremely confusing

[jbarnes]

Yes, if you set the force option, you can ignore this message.

Oh and for testing you'll need to look at the output of lspci to make sure your device supports ASPM and that it's enabled. Hardware will transition into L0S or L1 automatically after very short periods of time; to really check if things are working you'd need to measure power differences. But if the device is broken and hangs you'll probably notice in that case.