Opt-in Linux 7.0 Kernel for Proxmox VE 9 available

As I mentioned in the thread I created, I think this is a kernel bug, so I'm posting it here as well.

I think this is a bug in kernel 7.0.14. Will it be fixed?

U

[SOLVED] Thread 'kernel 7.0.14-2, PCIe pass-through for amdgpu does not work properly.'

After applying kernel 7.0.14-2, the following error occurs when I start a virtual machine with an RX9070 XT connected via PCIe passthrough.

When this happens, the virtual machine task itself does not complete and hangs.

I have confirmed that the system operates normally when I pin the kernel to version 7.0.12-1.

I would like to resolve this issue. Could you please provide any advice on how to investigate this or suggest a solution?

When a virtual machine with GPU passthrough is running, I display the virtual machine's screen on monitor, and when it is stopped, I display the console...
 
Data point: ixgbe (Intel X550) tx-hang regression in 7.0.0-3-pve — resolved in 7.0.14-5-pve

Sharing in case anyone else on an early opt-in 7.0 build hits mystery packet loss.

Hardware: AMD EPYC host, Intel X550 dual-port 10GbE (ixgbe), copper link negotiated at 2.5G NBASE-T to a UniFi switch. PVE 9, no PCIe passthrough on the NIC, standard vlan-aware vmbr bridge.

Symptoms on 7.0.0-3-pve — starting ~76 seconds after boot and repeating every 10-15 seconds indefinitely (~3,400 events/day):

ixgbe 0000:42:00.0 nic1: NETDEV WATCHDOG: CPU: 5: transmit queue 21 timed out 5229 ms
ixgbe 0000:42:00.0 nic1: initiating reset due to tx timeout
ixgbe 0000:42:00.0 nic1: Reset adapter
ixgbe 0000:42:00.0 nic1: NIC Link is Up 2.5 Gbps, Flow Control: RX/TX

The interesting failure mode is per-flow packet loss: flows RSS-hashed onto the hung tx queue blackhole completely (100% loss) while flows on other queues are unaffected (0%), and each adapter reset reshuffles which destinations are affected. From the outside it looks like a flaky ISP or a bad cable rather than a NIC problem — ping one IP and get 100% loss, ping another at the same moment and get 0%. It was always queue 21 in our case. Forcing the link down to 1G did NOT stop the hangs, so it does not appear to be NBASE-T signal-integrity related. No IOMMU page faults logged (mentioning because there is a separate thread about ixgbe reset loops following AMD-Vi IO_PAGE_FAULT — ours starts clean from boot, so it is a different trigger).

Kernel comparison, same hardware/cabling/config:
- 6.17.13-2-pve: 17 days uptime, zero resets
- 7.0.0-3-pve: resets from 76 seconds after boot, ~3,400/day
- 7.0.14-5-pve: zero resets, several hours of soak at 2.5G with the default 63 queues

Whatever the regression was, it appears fixed in 7.0.14-5-pve — if you are on an early 7.0 opt-in build with an ixgbe NIC, just update. Posting mainly so this is searchable for the next person staring at "transmit queue N timed out" and blaming their switch.
 
You must log in or register to reply here.
Top Bottom
Back