Opt-in Linux 7.0 Kernel for Proxmox VE 9 available

Hi all,

I would like to add a separate Intel X550 / ixgbe crash report on 7.0.14-20-pve. This differs from the recent Broadcom / bnxt_en reports in this thread.

We captured the full crash through pstore, which identifies the failing function as ixgbe_check_mdd_event().

Environment

  • Proxmox VE manager: 9.2.21
  • Kernel at the time of the crash: 7.0.14-20-pve
  • Mainboard: Supermicro H11DSi-NT
  • BIOS: 2.1, dated 2020-02-21
  • NIC: Intel X550 [8086:1563], revision 01
  • Subsystem: Supermicro [15d9:1563]
  • Driver: in-tree ixgbe
  • NIC firmware reported by ethtool: 0x800007f3, 1.1276.0
  • Affected interface: eno1, PCI address 0000:61:00.0
  • Interface used as a bridge uplink for VM traffic, with VLAN subinterfaces
  • Link: 10 Gbit/s
Messages immediately preceding the panic

ixgbe 0000:61:00.0: Malicious event on VF 8 tx:80000 rx:0
ixgbe 0000:61:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0004 address=0xd5b294c0 flags=0x0000]
BUG: kernel NULL pointer dereference, address: 000000000000078c
#PF: supervisor write access in kernel mode
Relevant pstore excerpt

Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 5 UID: 0 PID: 0 Comm: swapper/5 Tainted: P O 7.0.14-20-pve #1 PREEMPT(lazy)
Hardware name: Supermicro Super Server/H11DSi-NT, BIOS 2.1 02/21/2020
RIP: 0010:ixgbe_check_mdd_event+0x124/0x160 [ixgbe]
RAX: 0000000000000740 RBX: 0000000000000008 RCX: 0000000000000008
CR2: 000000000000078c
The IRQ call chain includes:

ixgbe_check_mdd_event
ixgbe_msg_task
ixgbe_msix_other
__handle_irq_event_percpu
handle_irq_event
handle_edge_irq
__common_interrupt
common_interrupt
Followed by:

Kernel panic - not syncing: Fatal exception in interrupt
The host became completely unresponsive and required a reboot.

No SR-IOV VFs configured

The following was checked after reboot:

cat /sys/class/net/eno1/device/sriov_numvfs
0
The private flags are:

legacy-rx : off
vf-ipsec : off
mdd-disable-vf: off
This appears consistent with the reported issue where an MDD event causes access to adapter->vfinfo[] despite no VFs being configured. The stacktrace confirms the crash location; we have not established what triggered the MDD event or the accompanying IOMMU fault.

Potentially related reports:

Current mitigation status

We have installed 6.17.13-21-pve in preparation for a comparison test. We do not yet have a stability result and cannot claim that it fixes this issue.

The X550 interfaces are required for our infrastructure, so bypassing these NICs is not a practical workaround.

Could the Proxmox team confirm:

  1. Whether 6.17.13-21-pve contains the same unguarded MDD/VF access path.
  2. Whether a fix or backport is planned for the 7.0 kernel series, and which build should contain it.
  3. Whether there is a validated workaround for systems with sriov_numvfs=0 while retaining the X550 interfaces.
We have the full pstore dump available if additional context would help.
 
uzumo said:
Some people say that SRIOV has been deprecated in the i915 driver.
...
Xe module currently does not support MTL (Meteor Lake) and LNL (Lunar Lake) platforms. Please use i915 instead.
Click to expand...
I’m working on an experimental Xe SR-IOV patch set targeting Meteor Lake and Arrow Lake: xe-sriov-mtl-arl.

On my Linux 7.2.7 test host, I have Windows guests running with Intel VFs, and I’ve resolved the rendering glitches affecting text, transparency and hover effects in the Windows UI.

I’ve also received independent feedback from dmfrpro, who tested my patches in a downstream fork on Meteor Lake (185H). In this GitHub comment, they reported:

Video games work
Firefox youtube videos work fine
WinUI3 doesn't have artifatcs
Click to expand...
This is encouraging, but the project remains highly experimental. I’m still investigating stability and reviewing the changes.

Feedback and further test reports are welcome!
 
theleatherman said:
Could the Proxmox team confirm:

  1. Whether 6.17.13-21-pve contains the same unguarded MDD/VF access path.
  2. Whether a fix or backport is planned for the 7.0 kernel series, and which build should contain it.
  3. Whether there is a validated workaround for systems with sriov_numvfs=0 while retaining the X550 interfaces.
We have the full pstore dump available if additional context would help.
Click to expand...

Not Proxmox staff, just another X550 user on 7.0.14-23-pve who dug into this.

1) Yes, 6.17.13-21-pve has the same code. The MDD handling arrived upstream
in v6.17 and ixgbe_check_mdd_event() is unchanged through 7.0 and mainline;
the compiled function in ixgbe.ko is the same size in 6.17.13-21-pve and
7.0.14-23-pve on my host. Your 6.17 test is unlikely to help. Your CR2 fits
exactly: VF 8 * 0xe8 (entry size) + 0x4c (clear_to_send) = 0x78c.

2) A fix is posted upstream but not merged. Thomas Lamprecht (Proxmox) sent
two patches on 2026-10-04: one guards the vfinfo access, one stops enabling
MDD when there are no VFs.
https://lore.kernel.org/netdev/20261004193704.2895700-1-t.lamprecht@proxmox.com/
In bug 7874 he says he wants initial upstream feedback before putting it in
Proxmox kernels, so there is no build to name yet. 7.0.14-23-pve does not
have it. Watch: https://bugzilla.proxmox.com/show_bug.cgi?id=7874

3) The only workaround I'm confident in is a pre-6.17 kernel. 6.14 is still
in the PVE 9 repo and has no MDD code:

apt install proxmox-kernel-6.14
proxmox-boot-tool kernel pin 6.14.11-9-pve
reboot

Afterwards "grep ixgbe_check_mdd_event /proc/kallsyms" should print nothing.
Undo with "proxmox-boot-tool kernel unpin". Caveat: the last 6.14 build is
from May 2026, and I don't know if Proxmox still officially supports it.

Not workarounds: mdd-disable-vf (different mechanism), and creating a VF or
two to make vfinfo non-NULL (an event on a PF queue then writes past the end
of the array instead).

The patch author tested on an H11DSi-NT like yours but has no reproducer for
the MDD events and is asking reporters to test. If your host crashes
regularly, attaching your pstore dump to bug 7874, or testing the patches
and reporting the result there, would help get this merged.

I haven't experienced the same panic that you are having -- I am using SR-IOV with 6 VF's, which may or may not be saving me from the crashes.

I can't explain the AMD-Vi IO_PAGE_FAULT; nothing I found covers it.
 
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom
Back