Opt-in Linux 6.14 Kernel for Proxmox VE 8 available on test & no-subscription
- Thread starter t.lamprecht
- Start date
this works perfectly thank you. great work as always.
for reference i applied the patch to the driver .run file, installed it, installed 6.14 and rebooted. the modules built fine and all is well.
also if you do not mind me asking, i noticed you have a pascal on 17.5? is there a trick to that? i replaced my
vgpuConfig.xml file, which works fine to make vGPU function, but linux VMs say driver mismatch on any driver version (and they do not work) and windows will still only use 535.... just wondering if i am doing something wrong or missing something (it seems like i am. i could never figure out this or getting LXCs to use the gpu right with the kvm driver haha. )Not sure if there is a difference between POLLED and INTERRUPT when the igen6_edac is loaded, but I noticed that was a difference between 6.8 and 6.14 kernels.
Yeah, polling is exactly what the patch I linked implements, from the commit message:
Again, I'd not be surprised if it's an issue in the firmware of your board, those are often done rather sloppy for those cheaper motherboards. Adding the polling mode seems to be a workaround for something like that too.
Switched to 6.14 kernel. Found an issue with Realtek 8125 NIC: iperf3 reports 2.35 Gbits/s in one direction, but only 2.24 Gbits/s in reverse direction.
Code:
# iperf3 -c router.home
Connecting to host router.home, port 5201
[ 5] local 192.168.64.2 port 51652 connected to 192.168.64.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 282 MBytes 2.37 Gbits/sec 0 749 KBytes
[ 5] 1.00-2.00 sec 281 MBytes 2.35 Gbits/sec 44 837 KBytes
[ 5] 2.00-3.00 sec 281 MBytes 2.35 Gbits/sec 0 837 KBytes
[ 5] 3.00-4.00 sec 281 MBytes 2.36 Gbits/sec 0 837 KBytes
[ 5] 4.00-5.00 sec 281 MBytes 2.35 Gbits/sec 0 837 KBytes
[ 5] 5.00-6.00 sec 280 MBytes 2.35 Gbits/sec 0 837 KBytes
[ 5] 6.00-7.00 sec 281 MBytes 2.35 Gbits/sec 0 837 KBytes
[ 5] 7.00-8.00 sec 281 MBytes 2.36 Gbits/sec 0 837 KBytes
[ 5] 8.00-9.00 sec 281 MBytes 2.36 Gbits/sec 0 837 KBytes
[ 5] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec 0 837 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.74 GBytes 2.36 Gbits/sec 44 sender
[ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
iperf Done.
# iperf3 -c router.home -R
Connecting to host router.home, port 5201
Reverse mode, remote host router.home is sending
[ 5] local 192.168.64.2 port 39748 connected to 192.168.64.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 268 MBytes 2.24 Gbits/sec
[ 5] 1.00-2.00 sec 267 MBytes 2.24 Gbits/sec
[ 5] 2.00-3.00 sec 267 MBytes 2.24 Gbits/sec
[ 5] 3.00-4.00 sec 267 MBytes 2.24 Gbits/sec
[ 5] 4.00-5.00 sec 267 MBytes 2.24 Gbits/sec
[ 5] 5.00-6.00 sec 267 MBytes 2.24 Gbits/sec
[ 5] 6.00-7.00 sec 267 MBytes 2.24 Gbits/sec
[ 5] 7.00-8.00 sec 267 MBytes 2.24 Gbits/sec
[ 5] 8.00-9.00 sec 267 MBytes 2.24 Gbits/sec
[ 5] 9.00-10.00 sec 267 MBytes 2.24 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 2.61 GBytes 2.24 Gbits/sec receiver
iperf Done.On 6.11 kernel bitrate is symmetric:
Code:
# iperf3 -c router.home
Connecting to host router.home, port 5201
[ 5] local 192.168.64.2 port 42146 connected to 192.168.64.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 282 MBytes 2.36 Gbits/sec 88 730 KBytes
[ 5] 1.00-2.00 sec 280 MBytes 2.35 Gbits/sec 0 747 KBytes
[ 5] 2.00-3.00 sec 281 MBytes 2.35 Gbits/sec 0 747 KBytes
[ 5] 3.00-4.00 sec 281 MBytes 2.36 Gbits/sec 18 748 KBytes
[ 5] 4.00-5.00 sec 280 MBytes 2.35 Gbits/sec 0 748 KBytes
[ 5] 5.00-6.00 sec 281 MBytes 2.36 Gbits/sec 0 748 KBytes
[ 5] 6.00-7.00 sec 280 MBytes 2.35 Gbits/sec 0 768 KBytes
[ 5] 7.00-8.00 sec 281 MBytes 2.35 Gbits/sec 0 793 KBytes
[ 5] 8.00-9.00 sec 281 MBytes 2.36 Gbits/sec 0 793 KBytes
[ 5] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec 0 874 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.74 GBytes 2.35 Gbits/sec 106 sender
[ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
iperf Done.
# iperf3 -c router.home -R
Connecting to host router.home, port 5201
Reverse mode, remote host router.home is sending
[ 5] local 192.168.64.2 port 39790 connected to 192.168.64.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 1.00-2.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 2.00-3.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 3.00-4.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 4.00-5.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 5.00-6.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 6.00-7.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 7.00-8.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 8.00-9.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 2.74 GBytes 2.35 Gbits/sec receiver
iperf Done.Update: Propably, this has nothing to do with R8125. Previously I tested throughput between my PC and VM (VM sending via Virtio device). But throughput between PC and Proxmox host itself is ok:
Code:
# iperf3 -c proxmox.home -R
Connecting to host proxmox.home, port 5201
Reverse mode, remote host proxmox.home is sending
[ 5] local 192.168.64.2 port 57700 connected to 192.168.64.100 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 1.00-2.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 2.00-3.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 3.00-4.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 4.00-5.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 5.00-6.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 6.00-7.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 7.00-8.00 sec 281 MBytes 2.35 Gbits/sec
[ 5] 8.00-9.00 sec 280 MBytes 2.35 Gbits/sec
[ 5] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 2.74 GBytes 2.35 Gbits/sec receiver
iperf Done.
Last edited:
On kernel
Linux 6.8.12-9-pve (2025-03-16T19:18Z this would be "unsymmetric" in your books (- not mine!):
Code:
root@WRKSPC-DEBIAN:~# iperf3 -c 192.168.1.205 -R
Connecting to host 192.168.1.205, port 5201
Reverse mode, remote host 192.168.1.205 is sending
[ 5] local 192.168.1.204 port 52986 connected to 192.168.1.205 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 9.03 GBytes 77.6 Gbits/sec
[ 5] 1.00-2.00 sec 9.21 GBytes 79.2 Gbits/sec
[ 5] 2.00-3.00 sec 9.52 GBytes 81.7 Gbits/sec
[ 5] 3.00-4.00 sec 9.54 GBytes 81.9 Gbits/sec
[ 5] 4.00-5.00 sec 9.49 GBytes 81.5 Gbits/sec
[ 5] 5.00-6.00 sec 9.51 GBytes 81.7 Gbits/sec
[ 5] 6.00-7.00 sec 9.54 GBytes 82.0 Gbits/sec
[ 5] 7.00-8.00 sec 9.54 GBytes 81.9 Gbits/sec
[ 5] 8.00-9.00 sec 9.12 GBytes 78.3 Gbits/sec
[ 5] 9.00-10.00 sec 9.23 GBytes 79.3 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 93.7 GBytes 80.5 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 93.7 GBytes 80.5 Gbits/sec receiver
iperf Done.
root@WRKSPC-DEBIAN:~# iperf3 -c 192.168.1.205
Connecting to host 192.168.1.205, port 5201
[ 5] local 192.168.1.204 port 47862 connected to 192.168.1.205 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 9.60 GBytes 82.5 Gbits/sec 0 462 KBytes
[ 5] 1.00-2.00 sec 9.59 GBytes 82.4 Gbits/sec 0 462 KBytes
[ 5] 2.00-3.00 sec 9.59 GBytes 82.4 Gbits/sec 0 462 KBytes
[ 5] 3.00-4.00 sec 9.59 GBytes 82.4 Gbits/sec 0 462 KBytes
[ 5] 4.00-5.00 sec 9.57 GBytes 82.2 Gbits/sec 0 650 KBytes
[ 5] 5.00-6.00 sec 9.59 GBytes 82.4 Gbits/sec 0 650 KBytes
[ 5] 6.00-7.00 sec 9.55 GBytes 82.1 Gbits/sec 0 650 KBytes
[ 5] 7.00-8.00 sec 9.59 GBytes 82.4 Gbits/sec 0 683 KBytes
[ 5] 8.00-9.00 sec 9.57 GBytes 82.2 Gbits/sec 0 683 KBytes
[ 5] 9.00-10.00 sec 9.58 GBytes 82.3 Gbits/sec 0 683 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 95.8 GBytes 82.3 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 95.8 GBytes 82.3 Gbits/sec receiver
iperf Done.So a deviation of (a whopping!) 2.19% - nothing to write home about! I notice a lot of Retr on your end (on both kernels) - probably NW activity etc.
1. My network is practically idle, but difference in throughput is about 110 Mbits/s.
2. My results are repeatable. I'm measuring 2.35 Gbit/s in both directions on kernel 6.11, reboot into 6.14 and measuring 2.35 Gbits/s in one direction and 2.24 Gbits/s in the other.
3. This has nothing to do with retranslations, because:
a) in submitted results retranslations shown only for forward direction, which still has 2.35-2.36 Gbits/s, no matter if there were retranslations;
b) I ran the same test from the opposite side (VM as a client, PC as a server, VM is sending), and saw zero retranslations, and still only 2.24-2.25 Gbits/s.
4. I think we should not compare 2.5G network with 100G one in terms of deviation. With 100G network even CPU or PCI-E might become bottleneck.
AFAIK
Retr stands for Retransmitted, as in Retransmitted packets.My tests were done CT to CT on same Proxmox host. Maybe try that in your tests & compare results.
Same problem with a GMKtec N150. That constant flood of messages can't be good for the SSD so I've reverted back to 6.11.
Thanks for the pointer, so seems really like an issue with some specific N CPUs/motherboard combos that can luckily be worked around in the kernel.
I checked and saw that the POC patch was sent as an actual one and the maintainer accepted it. So I cherry-picked that for our next 6.14 build (few weeks at max), disable edac until then as workaround if you run an affected system and still really want to run 6.14.
Oh, of course, I meant retransmissions.
Sorry, English is not my native language.OK, I performed additional tests and wrote results in the table:
It looks to me, that tests inside Proxmox are not representative, and the difference is within the margin of error. The bottleneck here is, propably, CPU (AMD Ryzen 1700 in my case), so I don't really care.
But tests with PC are not good. 2.5G (2.35G with MTU 1500) should not be a problem ever. But we can clearly see, that upgrading kernel results in ~4-5% loss in throughput. Importantly, the test between PVE and PC shows no losses, so maybe this has something to do with changes in linux bridge?
https://github.com/GreenDamTan/vgpu_unlock-rs/commit/a651cf35c0097426c369c2783c749b2ed28bce39this works perfectly thank you. great work as always.
for reference i applied the patch to the driver .run file, installed it, installed 6.14 and rebooted. the modules built fine and all is well.
also if you do not mind me asking, i noticed you have a pascal on 17.5? is there a trick to that? i replaced myvgpuConfig.xmlfile, which works fine to make vGPU function, but linux VMs say driver mismatch on any driver version (and they do not work) and windows will still only use 535.... just wondering if i am doing something wrong or missing something (it seems like i am. i could never figure out this or getting LXCs to use the gpu right with the kvm driver haha. )
try to use A5500 device id in pascal card
I am currently considering replacing my Realtek 2.5G 8125BG with an Intel 10G x550 network card, as I would like to use the drivers supplied.
Does anyone know if the Realtek 8125BG is fully supported in kernel versions 6.11, 6.14? If so, is it through the r8169 driver or a special one for the 8125BG chip?
Does anyone know if the Realtek 8125BG is fully supported in kernel versions 6.11, 6.14? If so, is it through the r8169 driver or a special one for the 8125BG chip?
The issue with Realtek NICs is that their individual models actually represent quite a large array of slightly different NICs - which gain support eventually in the mainline 8169 driver - e.g. for some systems I've seen - a Realtek 8125 from Q2 2024 is supported by r8169 since kernel 6.2, while one from Q4 2024 only got support in kernel 6.14.
We ship the `r8125-dkms` package (repackaged from Debian) but currently I don't think it supports any NICs that are not already supported by the 6.14 opt-in kernel.
That being said - once supported by the mainline driver there are not many reports about issues - so they generally work reasonably well.
I hope this helps!
Thanks Stoiko!
I'm still not really sure what I can expect. I used the 8169 driver with 6.8 with PE8.2 and had issues with failover in a bond.
I think I will continue to install the driver on the Realtek site as dkms. If I succeed that the driver is still there after a kernel update, then I will stay with the Realtek card. Otherwise I will move.
I'm still not really sure what I can expect
. I used the 8169 driver with 6.8 with PE8.2 and had issues with failover in a bond. I think I will continue to install the driver on the Realtek site as dkms. If I succeed that the driver is still there after a kernel update, then I will stay with the Realtek card. Otherwise I will move.
We have the same issue with the AMD EPYC 9754...