Intel Arc A580 idle power regression with kernel 7.0.14-20/22-pve

S

seylon79

New Member
Oct 8, 2026
5
0
1
Hi,

I've noticed what appears to be a kernel regression affecting the idle power consumption of an Intel Arc A580.

Hardware:

  • Proxmox VE 9.2
  • AMD Ryzen 5 9600X
  • Intel Arc A580
  • Arc is using the i915 driver
I originally noticed that the Arc was drawing significantly more power than expected at idle. I tested this by booting different installed Proxmox kernels.

Results:

KernelArc A580 idle power
7.0.14-16-pve~6 W
7.0.14-20-pve~40–50 W
7.0.14-22-pve~40–50 W
The difference is reproducible. I can boot 7.0.14-16-pve and the Arc returns to approximately 6 W idle. Booting 7.0.14-20-pve or 7.0.14-22-pve causes the idle consumption to increase substantially.

I also disabled GPU monitoring in Beszel (SKIP_GPU=true) during the testing, so the higher power draw isn't being caused by Beszel polling the GPU.

I verified the power difference using the i915 energy counter rather than relying only on monitoring software. On 7.0.14-22-pve, the counter increased by approximately 3.0 kJ in about one minute, corresponding to roughly 50 W.

Interestingly, I also noticed different behavior from the AMD iGPU between the kernels, although I haven't investigated that separately.

For now I've pinned the host back to 7.0.14-16-pve, where the Arc returns to its normal ~6 W idle consumption.

Is this a known regression in the newer 7.0 kernels, particularly around i915/DRM power management?

Thanks!
 
mhmm could you also check the -17, -18 and -19 kernels? this would shrink the possible regression window by a lot
from a good and a bad boot the following output would also be practical:

Code: 
lspci -PP -vvv
 
Last edited:
Thanks, I did some further testing to narrow this down.

I tested 7.0.14-17-pve first. The high idle power consumption was immediately present after boot, so I didn't test -18 or -19 since the regression is already present in -17.

I also tested the latest available kernel, 7.0.14-23-pve, to see whether the issue had been fixed there. Unfortunately the regression is still present.

My current results are:

KernelArc A580 idle power
7.0.14-16-pve~6 W
7.0.14-17-pve~44 W
7.0.14-20-pve~40–50 W
7.0.14-22-pve~40–50 W
7.0.14-23-pve~42 W
I also verified the -17 result using the i915 energy counter. Over approximately one minute it increased from 7,582,748,413 µJ to 10,209,383,605 µJ, corresponding to approximately 44 W.

After returning to 7.0.14-16-pve, the Arc immediately returned to its normal ~6 W idle consumption.

I've attached the requested lspci -PP -vvv output and diagnostics from the 7.0.14-17-pve boot.

So at this point the regression appears to be introduced somewhere between 7.0.14-16-pve and 7.0.14-17-pve, and it is still present in the current 7.0.14-23-pve.

Thanks!
 

Attachments

can you also attach a lspci output from a bad kernel?

EDIT: also please run lspci as root, otherwise some information is not visible there (such as the capabilities, etc.)
 
Last edited:
My apologies. i thought i had run it as root. I've now captured the lspci -PP -vvv output as root from both kernels so there's a direct comparison between the known-good and known-bad versions.

I've attached both files:

  • lspci-PP-vvv-root-16.txt from 7.0.14-16-pve (known good, ~6 W idle)
  • lspci-PP-vvv-root-17.txt from 7.0.14-17-pve (first known bad, ~44 W idle)
Hopefully the comparison provides some useful information.
 

Attachments

mhmm the only thing that stands out is that ASPM L1 is enabled on the working system while not on the not working one.

between those kernels there are only a few ASPM related changes, and only one is generic:
https://lore.kernel.org/all/20260428040104.78524-1-carlos.bilbao@kernel.org/

not sure if it's the reason for the behavior though.

you might want to report the behavior upstream to the kernel though if you can reproduce with an upstream kernel..
 
Thanks for taking a look.

I'm fairly new to homelabbing, and I only noticed this because the server's fans suddenly started getting noticeably louder than they used to. That's what led me to investigate the GPU power draw in the first place.

I'm not familiar with kernel development, so I'm not entirely sure what you mean by reproducing this with an upstream kernel or how I'd go about testing that. Is that something I should look into, or is there anything else you'd suggest I do at this point?
 
it would entail installing an upstream kernel, best on a test machine and if it's still the upstream behavior open a bug on https://bugzilla.kernel.org/
i don't have a a580 to test here at the moment so I can't do the test myself sadly
 
Thanks for all the help and for taking the time to look into this. I think testing upstream kernels and opening a kernel bug report is getting a bit beyond my current skill set, so I'll stick with the known-good kernel for now and keep testing newer Proxmox kernels as they become available. Hopefully the issue gets resolved in a future update. Thanks again!
 
I can confirm a very similar ASPM regression on a different hardware platform, using an Intel Arc A380 with VFIO passthrough.

Hardware and software​

  • Motherboard: Supermicro H12SSL-C
  • CPU: AMD EPYC 7313
  • GPU: ASRock Intel Arc A380 (DG2, PCI ID 8086:56a5)
  • GPU configuration: PCIe passthrough via vfio-pci to a Debian 13 VM
  • Proxmox VE: 9.2.21
  • QEMU: pve-qemu-kvm 11.0.3-4
  • Guest kernel at the time of the regression: 6.12.107+deb13-amd64

When the problem started​

On September 21, 2026, I upgraded the Proxmox host kernel from 7.0.14-16-pve to 7.0.14-17-pve.

Following that update and reboot, my system's idle power consumption increased by approximately 15–20 W and remained elevated.

The Debian guest was running the same kernel (6.12.107) before and after the host update, so there was no simultaneous guest kernel change.

Kernel comparison​

Today (October 26), I booted the host back into 7.0.14-16-pve without changing the BIOS, hardware, GPU passthrough configuration or PCIe settings.

Both the TrueNAS VM and the Debian VM with the Arc A380 were running during the measurements. All eight HDDs were in standby.

7.0.14-25-pve7.0.14-16-pve
System idle power~140–145 W~125 W
AMD PCIe root port (80:01.1)ASPM DisabledASPM L1 Enabled
Intel PCIe bridge (81:00.0)ASPM DisabledASPM L1 Enabled
Power consumption was measured externally using a smart plug. The measurement also includes some network equipment, which remained unchanged between tests.

With the older kernel, the idle power consumption returned to its previous level immediately after booting and spinning down the HDDs.

PCIe ASPM configuration​

The ASPM policy with the working kernel is:

Code: 
default performance [powersave] powersupersave
Relevant kernel parameters:

Code: 
amd_iommu=on iommu=pt
There is no pcie_aspm=off or pcie_aspm=force override.

With kernel 7.0.14-16-pve, both affected PCIe links report:

Code: 
LnkCtl: ASPM L1 Enabled
With kernel 7.0.14-25-pve, both report:

Code: 
LnkCtl: ASPM Disabled

Conclusion​

The combination of the power measurements and the PCIe configuration differences strongly suggests an ASPM regression introduced between 7.0.14-16-pve and 7.0.14-17-pve.

This is particularly interesting because the affected Intel Arc GPU is passed through to a VM using VFIO, rather than being driven by i915 directly on the Proxmox host.

I have attached the complete lspci -PP -vvv output collected as root under the working kernel 7.0.14-16-pve, together with the PCIe topology, kernel parameters, ASPM policy and installed Proxmox package versions.

The full PCIe dump from the affected kernel was not captured, but the relevant ASPM states were verified directly.

I'm currently using 7.0.14-16-pve as a temporary workaround.
 

Attachments

You must log in or register to reply here.
Top Bottom
Back