Linux Developers Ponder Decade-Old Decision To Disable PCI Runtime Power Management By Default

[Adarion]

Powertop is useful for figuring this out. It allows you to enable PM for each device to see if it has issues. I had an issue with a mouse that would switch of the Lazer after 1 second of not being used until a button was clicked - making it useless

Logitech G5 maybe? I had to exclude it / write an extra script to re-activate it each time. It kinda sucked cause to mouse was good otherwise.


I'm curious how this will end up. But I think I should try that command line parameter on my old boxes and see what happens. Iirc we also had a similar PCIe-APSM issue and I still have pcie_aspm=force near everywhere (on my newer boxes).

[polarathene]

The note was referring to the fact my command shows power management settings for more things than just the pci devices themselves like sata power management for drives, etc.

A good example from your output is this:

/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/hdaudioC1D0/power/control:on
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/power/control:on

In the above case I think the first is power management for the audio chipset itself and the second is for the pci device for the audio chipset.

Awesome, that's the clarification I was looking for thanks!

So limiting the depth should do the trick? (and a pattern to filter out non PCI devices)

$ find /sys/devices -maxdepth 5 -path "*\.[0-9]/power/control" -exec grep -H "on" \{\} \; | sort
/sys/devices/pci0000:00/0000:00:00.0/power/control:on
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/power/control:on
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/power/control:on
/sys/devices/pci0000:00/0000:00:14.0/power/control:on
/sys/devices/pci0000:00/0000:00:14.2/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/power/control:on
/sys/devices/pci0000:00/0000:00:1f.0/power/control:on
/sys/devices/pci0000:00/0000:00:1f.2/power/control:on
/sys/devices/pci0000:00/0000:00:1f.3/power/control:on
/sys/devices/pci0000:00/0000:00:1f.4/power/control:on

This also seems to work too with the same results above:

find /sys/devices -regextype posix-extended -regex ".*[[:xdigit:]]{4}:[[:xdigit:]]{2}:[[:xdigit:]]{2}\.[[:xdigit:]]/power/control" -exec grep -H "on" \{\} \; | sort

Where

[[:xdigit:]]{4}:[[:xdigit:]]{2}:[[:xdigit:]]{2}\.[[:xdigit:]]

matches PCI device address

DDDD:BB:DD.F (Domain:Bus:Device.Function)

"[:xdigit:]" matches hexadecimal values, and the "{4}"/"{2}" brace expansions require using regex posix-extended to work.

[calc]

So your "Note" warning after your command about showing more than devices with PCI power management was not about your command but the previous suggested one from Hi-Angel?

All the results from your command are PCI power management results?

The note was referring to the fact my command shows power management settings for more things than just the pci devices themselves like sata power management for drives, etc.

A good example from your output is this:

/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/hdaudioC1D0/power/control:on
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/power/control:on

In the above case I think the first is power management for the audio chipset itself and the second is for the pci device for the audio chipset.

My previous command shows anything with the power management 'control' file that isn't set to 'auto'. You can run the following command instead to have it show you all the power management 'control' files and what they are set to, most will be set to 'auto' already:

find /sys/devices -iname control -exec grep -H "" \{\} \; | sort

[Old Nobody]

As far as I understand, it's about PCI(e) devices, not about mainboards/BIOSes.
I usually don't throw my PCI/PCIe cards in the trash when I get a new mainboard but continue to use them if required.
I guess many people use some SATA controllers, DVB receivers, WIFI cards or sound cards that were designed more than 10 years ago. Many of them are still being produced and sold.

[polarathene]

The ones shown in the command I listed are the ones that do not have power management enabled. If you use the 'powertop --auto-tune' command it will set them all to enabled.

So your "Note" warning after your command about showing more than devices with PCI power management was not about your command but the previous suggested one from Hi-Angel?

All the results from your command are PCI power management results?

[calc]

How do you differentiate the results between what is not using PCI power management?

--snip--

Seems to report different devices entirely?:

Yes, the two commands report a different set of devices since the grep is filtering out anything that already has power management enabled "auto". The original command that Hi-Angel mentioned does not look under the root pci device so misses pretty much all of the pci devices.

The ones shown in the command I listed are the ones that do not have power management enabled. If you use the 'powertop --auto-tune' command it will set them all to enabled.

[calc]

There are still many 32-bit embedded processors, but they can't use Linux properly because some believe that 32-bit is not relevant anymore. Which is surely not true. Granted, a 32-bit server is not up to the tasks larger systems have. But as said before, for many SOHO tasks these systems are still enough - provided they have enough memory. But maybe I missed in the past the point that Linux developers might have become overconfident when they reached a small percentage market share? Is the goal still to have Linux on many desktops? Not with this strategy. As a response on the last few words of the above quote, advancement should not be the goal but rather a means to have and evolve an usable OS. (Said as a consumer, not as being a scientist)

Then again, Phoronix is rather focused on games, which have an ever greater appetite for processor power etc. fast, faster, but never fast enough!
So, it is no surprise that there are a lot of Phoronix supporters with probably deep pockets to have every 2-3 year "old" machines scrapped.

There are plenty of Linux dists that still cater to ancient (17yo+) 32bit x86 systems, even P4s from 2004 were 64bit. Those ancient 32bit systems generally aren't actually capable of holding enough memory to properly run modern DEs and web browsers with heavy HTML5 webpages even if the dists that dropped 32bit had still supported them.

I do replace my primary system every 3-4 years, since I use it for work, but I keep my old ones for the rest of my family members to use. My oldest system still in regular use is a ~ 8yo+ quad core with 32GB ram and a SSD. It can easily run any modern DE with no problem.

[polarathene]

find /sys/devices -iname control -exec grep -H "on" \{\} \; | sort

NOTE: the above will also show more than just pci power management.

How do you differentiate the results between what is not using PCI power management?

$ grep "" /sys/devices/*/power/control 
/sys/devices/breakpoint/power/control:auto 
/sys/devices/cpu/power/control:auto 
/sys/devices/cstate_core/power/control:auto 
/sys/devices/cstate_pkg/power/control:auto 
/sys/devices/intel_pt/power/control:auto 
/sys/devices/isa/power/control:auto 
/sys/devices/kprobe/power/control:auto 
/sys/devices/LNXSYSTM:00/power/control:auto 
/sys/devices/msr/power/control:auto 
/sys/devices/pci0000:00/power/control:auto 
/sys/devices/platform/power/control:auto 
/sys/devices/pnp0/power/control:auto 
/sys/devices/power/power/control:auto 
/sys/devices/software/power/control:auto 
/sys/devices/tracepoint/power/control:auto 
/sys/devices/uncore_arb/power/control:auto 
/sys/devices/uncore_cbox_0/power/control:auto 
/sys/devices/uncore_cbox_1/power/control:auto 
/sys/devices/uncore_cbox_2/power/control:auto 
/sys/devices/uncore_cbox_3/power/control:auto 
/sys/devices/uncore_imc/power/control:auto 
/sys/devices/uprobe/power/control:auto

Seems to report different devices entirely?:

$ find /sys/devices -iname control -exec grep -H "on" \{\} \; | sort 
/sys/devices/pci0000:00/0000:00:00.0/power/control:on
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/power/control:on
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/hdaudioC1D0/power/control:on
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/power/control:on
/sys/devices/pci0000:00/0000:00:14.0/power/control:on
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/power/control:on
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/host6/target6:0:0/6:0:0:0/power/control:on
/sys/devices/pci0000:00/0000:00:14.2/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/ata1/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/ata2/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/ata3/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/ata4/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/ata5/host4/target4:0:0/4:0:0:0/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/ata5/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/ata6/power/control:on
/sys/devices/pci0000:00/0000:00:17.0/power/control:on
/sys/devices/pci0000:00/0000:00:1f.0/power/control:on
/sys/devices/pci0000:00/0000:00:1f.2/power/control:on
/sys/devices/pci0000:00/0000:00:1f.3/hdaudioC0D0/power/control:on
/sys/devices/pci0000:00/0000:00:1f.3/power/control:on
/sys/devices/pci0000:00/0000:00:1f.4/power/control:on

Looking up those PCI devices:

$ sudo lspci 
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 07)
00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode] (rev 31)
00:1b.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #19 (rev f1)
00:1b.3 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #20 (rev f1)
00:1c.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #3 (rev f1)
00:1d.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #9 (rev f1)
00:1f.0 ISA bridge: Intel Corporation H170 Chipset LPC/eSPI Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller (rev 31)
00:1f.3 Audio device: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31)
00:1f.4 SMBus: Intel Corporation 100 Series/C230 Series Chipset Family SMBus (rev 31)
01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1070] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller (rev a1)

So mostly on-board controllers?

Here's a `sudo lspci -vv` snippet for the SATA controller output:

00:17.0 SATA controller: Intel Corporation Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode] (rev 31) (prog-if 01 [AHCI 1.
0])
       Subsystem: ASRock Incorporation Device a102
       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
       Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
       Latency: 0
       Interrupt: pin A routed to IRQ 127
       Region 0: Memory at df128000 (32-bit, non-prefetchable) [size=8K]
       Region 1: Memory at df12c000 (32-bit, non-prefetchable) [size=256]
       Region 2: I/O ports at f050 [size=8]
       Region 3: I/O ports at f040 [size=4]
       Region 4: I/O ports at f020 [size=32]
       Region 5: Memory at df12b000 (32-bit, non-prefetchable) [size=2K]
       Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
               Address: fee00318  Data: 0000
       Capabilities: [70] Power Management version 3
               Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
               Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
       Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
       Kernel driver in use: ahci
       Kernel modules: ahci

Looks like under Capabilities we have possible power states in the flag PME(...) with only D3hot enabled/available, and status PME-Enable- and PME- indicate the lack of Power Management Enabled (as in it's disabled).

My VGA controller, NVIDIA GPU appears to have no power management active/enabled?:

       Capabilities: [60] Power Management version 3 
               Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
               Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-

The audio device 00:1f.3 which is using PCI above, has both D3hot+ and D3cold+, I don't know if that means these are the only available states if PME was enabled?

       Capabilities: [50] Power Management version 3 
               Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
               Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-

The PCI bridge chipset for PCIe root port at device 00:1c.0 does have PME-Enable enabled, but not PME:

       Capabilities: [a0] Power Management version 3 
               Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
               Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-

[fransdb]

Because newer systems shouldn't have to suffer from bugs and workarounds in older hardware. I agree we should move to a blacklist for older systems, and enable things that will improve things going forward. Why should new computers be hobbled because of 10 year old hardware bugs? By all means, make sure old stuff doesn't break, but not at the expense of new stuff. We are moving forward, not backward, no matter what many people may wish to happen. I feel the same way about 32 vs. 64-bit. The sooner we can kill 32-bit, the better. Have options for it (virtualization, etc), but clearly mark is as being the exception to the rule, the outlier, etc. Otherwise we will never advance in this field.

I agree that older systems should not hamper progress. Advance all you want, but people should not be so arrogant to only count the newest gadgets as relevant. That said, I can live with the fact that we might need some switches to allow older systems to keep on running. As one participant already remarked: take an example from other OS'en.

There are still many 32-bit embedded processors, but they can't use Linux properly because some believe that 32-bit is not relevant anymore. Which is surely not true. Granted, a 32-bit server is not up to the tasks larger systems have. But as said before, for many SOHO tasks these systems are still enough - provided they have enough memory. But maybe I missed in the past the point that Linux developers might have become overconfident when they reached a small percentage market share? Is the goal still to have Linux on many desktops? Not with this strategy. As a response on the last few words of the above quote, advancement should not be the goal but rather a means to have and evolve an usable OS. (Said as a consumer, not as being a scientist)

Then again, Phoronix is rather focused on games, which have an ever greater appetite for processor power etc. fast, faster, but never fast enough!
So, it is no surprise that there are a lot of Phoronix supporters with probably deep pockets to have every 2-3 year "old" machines scrapped.

[camel_case]

Yup. I think a lot of mobos still use ISA for Super I/O sensor chip connectivity. My B450 mobo:

00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)

Isnt it used because of its Simplicity? ISA/LPC Interrupt lines are directly connected to the CPU. A benifit for small firmwares like BIOS. And compatibility: Generic drivers listen to default interupts.