Intel_Idle C-States in Proxmox with Intel Series 200 CPUs

The command I just executed

*Warning
Use at your own risk. For questions about effects of use, removal methods, etc., ask powertop. Don't ask here.

Code:
apt install libpci-dev libnl-3-dev libnl-genl-3-dev gettext libgettextpo-dev autopoint gettext libncurses5-dev libncursesw5-dev libtool-bin dh-autoreconf autoconf-archive pkg-config git

mkdir /root/tmp/git/ -p
cd /root/tmp/git
rm -rf .git
git init
git clone https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
cd libtraceevent; make; make install; cd ..;

git clone https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
cd libtracefs; make; make install; cd ..;

git clone https://github.com/fenrus75/powertop.git
cd powertop
sed -i '/autoreconf --install --verbose/c autoreconf --install --verbose --force' autogen.sh
./autogen.sh; ./configure; make; make install
 
Last edited:
Thanks for you answer @uzumo!
I tried to build it with you commands...unfortunatly it didn't work out of the box and I had not much time last week to tinker on it.
I think I'll wait for the release of the new kernel version and if it doesn't fix it, I'll try to build it again or use the package suggested from @news i7z.
Thanks guys. I'll keep you updated, once the update is released!

BR

Bastae
 
The Ubuntu vs Proxmox split on the same 6.17 is the useful clue here. The same kernel version reaching C10 on Ubuntu but only C3 on Proxmox almost always means a config or boot-param difference, not the kernel build itself. Two things worth comparing side by side:

1. ASPM policy. Run cat /sys/module/pcie_aspm/parameters/policy on both. Debian and Proxmox tend to leave it firmware-controlled, while a desktop Ubuntu install often ends up on powersave. Try adding pcie_aspm.policy=powersupersave to the kernel cmdline and reboot. If the NIC root port never gets ASPM L1, the package cannot drop much below C3 no matter what else you do.

2. The idle states themselves. cpupower idle-info and cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name on both, plus cat /proc/cmdline on each. If Proxmox only exposes POLL/C1/C1E/C3 while Ubuntu shows C6/C8/C10, something is capping it. A stray intel_idle.max_cstate= or processor.max_cstate= copied from a ZFS tuning guide is the usual culprit, even though stock Proxmox sets neither.

The other thing, and probably your real floor with this exact build: the TX410 is an Aquantia AQC113, and that chip is a known deep-C-state blocker. On a lot of consumer boards it negotiates ASPM L0s but not the L1 substates, which keeps its PCIe root port awake and caps the whole package. Check it directly with lspci -vvv on the NIC and look in LnkCtl for ASPM L1 Enabled and in L1SubCtl for L1.1/L1.2. If those are off, no kernel version gets you to package C10 while that card is seated. Easiest test is to pull it and re-measure: if the watts drop, the NIC is your answer, and an Intel X710/X550 or an i226-based 2.5G behaves much better for deep idle. The ServeTheHome TinyMiniMicro crowd hit the same wall, X550 and X710 keep idle sane while AQC and i350 do not.

Same logic for the WD Reds, check powertop device-stats for anything pinned 100% active and confirm SATA link power management is on. Realistically ~42W with a 10G AQC NIC plus three spinning HDDs is not far off the floor for that combo, so the lever is the NIC link state, not the Proxmox kernel.

Unrelated to your fix but maybe useful for setting expectations: I got tired of re-deriving what a given box should idle at and which NIC wrecks it from scattered forum posts, so I aggregated the measured numbers (wall-meter idle watts, NIC chipset, ECC, passthrough notes) for about 50 mini-PC and SFF boxes into one open dataset. Full disclosure, I built it. It is CC BY, corrections and new wall-meter readings welcome as PRs. Finder: https://idlewatt.vercel.app and raw data: https://github.com/SolvoHQ/homelab-mini-pc-dataset