Kernel 7.0.x regression: ACS violation on PCIe port 80:1b.4 causes VM freeze — Arrow Lake + Thunderbolt 5 + Intel Arc B50 passthrough

E

edcoppen

New Member
Jan 9, 2026
4
0
1
Hi all, following up from post #195 in the 7.0 opt-in thread as requested. Reposting the full details here with lspci -v output included.

Hardware
  • CPU: Intel Arrow Lake-S (Arrow Lake-HX 8p+16e cores)
  • Chipset: Intel 800 Series PCH
  • GPU (passthrough): Intel Arc Pro B50 (Battlemage G21, 04:00.0)
  • Thunderbolt: Intel JHL9580 Thunderbolt 5 Barlow Ridge (84:00.0 / 97:00.0)
  • USB controller (passthrough): ASMedia ASM3242 USB 3.2 (06:00.0)
  • NVMe (passthrough): Samsung S4LV008 Pascal (81:00.0)
Proxmox version: 9.2.3
Kernel boot parameters: intel_iommu=on iommu=pt split_lock_detect=off

VM Configuration
Code: 
agent: 1
bios: ovmf
boot: order=ide0;hostpci0
cores: 8
cpu: host
hostpci0: 0000:81:00,pcie=1   # Samsung NVMe
hostpci1: 0000:06:00,pcie=1   # ASMedia USB 3.2
hostpci2: 0000:04:00,pcie=1   # Intel Arc B50 GPU
hostpci3: 0000:05:00,pcie=1   # Intel Arc B50 Audio
machine: pc-q35-10.1
memory: 30518
ostype: win11
vga: none

Symptom
The Windows 11 VM freezes shortly after the Arc GPU driver initialises on boot. Display output is lost, CPU pegs at 100%, and the VM becomes completely unresponsive. The host immediately enters a continuous AER error loop on PCIe root port 0000:80:1b.4 which persists even after force-stopping the VM and requires a full host reboot to clear. Keyboard and mouse (connected via the passed-through ASMedia USB controller) also stop responding at the point of freeze.

Root cause
The AER loop is triggered by an ACS violation on PCIe root port 80:1b.4 (device 8086:7f44), which is the upstream port for the Thunderbolt 5 subsystem. The violation appears to be triggered by DMA activity when the Arc GPU driver initialises, crossing an ACS boundary between sibling root ports 80:1b.0 and 80:1b.4.

dmesg (kernel 7.0.6-2-pve)
Code: 
[  436.209061] pcieport 0000:80:1b.4: AER: Correctable error message received from 0000:80:1b.4
[  436.209134] pcieport 0000:80:1b.4:   device [8086:7f44] error status/mask=00300000/00000000
[  436.209138] pcieport 0000:80:1b.4:    [20] UnsupReq
[  436.209140] pcieport 0000:80:1b.4:    [21] ACSViol (First)
[  437.238805] thunderbolt 0000:84:00.0: AER: can't recover (no error_detected callback)
[  437.238815] xhci_hcd 0000:97:00.0: AER: can't recover (no error_detected callback)
[  437.238832] pcieport 0000:80:1b.4: AER: device recovery failed
... (repeats continuously until host reboot)

Kernels tested
  • 6.17.13-13-pve — VM boots and runs normally
  • 7.0.2-6-pve — freeze, ACS violation loop
  • 7.0.2-7-pve — freeze, ACS violation loop
  • 7.0.6-2-pve — freeze, ACS violation loop

Workaround
Pinned to 6.17.13-13-pve which resolves the issue completely.

lspci -v
Code: 
00:00.0 Host bridge: Intel Corporation Arrow Lake-HX 8p+16e cores Host Bridge (rev 01)
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IOMMU group 1
Capabilities: [e0] Vendor Specific Information: Len=14 <?>

00:02.0 VGA compatible controller: Intel Corporation Arrow Lake-S [Intel Graphics] (rev 06)
Subsystem: Intel Corporation Device 2212
Flags: bus master, fast devsel, latency 0, IRQ 208, IOMMU group 0
Kernel driver in use: i915

00:06.0 PCI bridge: Intel Corporation Arrow Lake-HX PCIe Root Port (rev 10)
Flags: bus master, fast devsel, latency 0, IRQ 125, IOMMU group 4
Bus: primary=00, secondary=02, subordinate=05
Kernel driver in use: pcieport

03:01.0 PCI bridge: Intel Corporation Device e2f0
Flags: bus master, fast devsel, latency 0, IOMMU group 15
Capabilities: [220] Access Control Services
Kernel driver in use: pcieport

03:02.0 PCI bridge: Intel Corporation Device e2f1
Flags: bus master, fast devsel, latency 0, IOMMU group 16
Capabilities: [220] Access Control Services
Kernel driver in use: pcieport

04:00.0 VGA compatible controller: Intel Corporation Battlemage G21 [Intel Graphics]
Subsystem: Intel Corporation Device 1114
Flags: bus master, fast devsel, latency 0, IRQ 227, IOMMU group 17
Kernel driver in use: vfio-pci

05:00.0 Audio device: Intel Corporation Device e2f7
Subsystem: Intel Corporation Device 1114
Flags: bus master, fast devsel, latency 0, IRQ 236, IOMMU group 18
Kernel driver in use: vfio-pci

06:00.0 USB controller: ASMedia Technology Inc. ASM3242 USB 3.2 Host Controller
Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 19
Kernel driver in use: vfio-pci

80:1b.0 PCI bridge: Intel Corporation 800 Series PCH PCIe Root Port (rev 10)
Flags: bus master, fast devsel, latency 0, IRQ 128, IOMMU group 24
Capabilities: [220] Access Control Services
Kernel driver in use: pcieport

80:1b.4 PCI bridge: Intel Corporation 800 Series PCH PCIe Root Port (rev 10)
Flags: bus master, fast devsel, latency 0, IRQ 129, IOMMU group 25
Bus: primary=80, secondary=82, subordinate=aa
Capabilities: [220] Access Control Services
Kernel driver in use: pcieport

81:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller S4LV008[Pascal]
Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 30
Kernel driver in use: vfio-pci

82:00.0 PCI bridge: Intel Corporation JHL9580 Thunderbolt 5 80/120G Bridge [Barlow Ridge Host 80G 2023] (rev 84)
Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 31
Kernel driver in use: pcieport

84:00.0 USB controller: Intel Corporation JHL9580 Thunderbolt 5 80/120G NHI [Barlow Ridge Host 80G 2023] (rev 84)
Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 36
Kernel driver in use: thunderbolt

97:00.0 USB controller: Intel Corporation JHL9580 Thunderbolt 5 80/120G USB Controller [Barlow Ridge Host 80G 2023]
Flags: fast devsel, IRQ 182, IOMMU group 37
Kernel driver in use: xhci_hcd

Full unabridged lspci -v output available on request.

Happy to provide any additional diagnostic output if helpful.
 
Update after further testing on kernel 7.0.14-11 (10 Aug 2026).

The regression is still present but the failure mode has become significantly worse: the AER/ACSViol storm on root port 0000:80:1b.4 now begins at bare host boot, during thunderbolt bring-up — before any VM is started and with no passthrough involved. On the earlier kernels (7.0.2-6/7, 7.0.6-2) the storm only triggered when the Arc GPU driver initialised inside the guest.

On 7.0.14-11 the host became unresponsive (systemd unreachable) and required reboot -f back to my pinned 6.17.13-21 to recover.

Same signature as before: UnsupReq / ACSViol (First) on device [8086:7f44], with "thunderbolt 0000:84:00.0: AER: can't recover (no error_detected callback)" and the same for xhci_hcd 0000:97:00.0.

This suggests the underlying issue is not passthrough-specific but a thunderbolt/AER platform interaction on Arrow Lake-HX + JHL9580 (Barlow Ridge), which passthrough merely exposed earlier on the older kernels. It lines up with reports from other Minisforum MS-02 Ultra owners seeing idle-boot AER floods on 7.0-era kernels with no passthrough configured at all (e.g. github.com/minisforum-docs/MS-02-Ultra/issues/10, multiple distros affected).

Kernels tested and failed so far: 7.0.2-6, 7.0.2-7, 7.0.6-2, 7.0.14-11. All 6.17.x kernels work normally. Happy to provide full dmesg or test patches.
 
+1 To this issue, i haven't done any tests on kernel 7 other than checking logs after boot and its still being spammed with the same AER errors.
also done test on 7.0.14-4, -5, -8, -12, -14, -16, -17, and -19

Currently pinned to 6.17.13-21-pve, hoping some new update will fix this
 
Same board/trigger here (Arrow Lake-HX, Arc B50 passthrough). I also tested across 7.0.x and they all storm — a newer point release won't fix it, since the cause is Linux runtime PM autosuspending the TB5 chain, not the kernel version.


The fix that worked for me, without masking AER or going to pcie_port_pm=off: a udev rule pinning power/control=on on the TB root port 80:1b.4 plus the downstream chain (device IDs 5780/5781/5782), with ACTION=="add|bind" so it survives rescans. Cold-boot verified: ACSViol went from ~1159 to 0, and stayed 0 through Arc guest-driver init and a multi-hour passthrough run. AER stays fully enabled.


It's documented in GitHub issue #10 on the minisforum-docs/MS-02-Ultra repo (madisonicus / moni11811 / my passthrough results). You can come off the 6.17 pin with that rule in place — no need to wait for an update.
 
You must log in or register to reply here.
Top Bottom
Back