Done. And... yes, this allowed the 6.8 kernel install to complete. Thanks. This is a dirt simple solution and I should have thought of it. I was trying to temporarily pause the DKMS service, set the ixgbe 5.19.9 auto-install option to "no", etc. but nothing I tried cleared the road to allow the kernel to build.Just doing amv /usr/src/ixgbe-5.19.9/dkms.conf /usr/src/ixgbe-5.19.9/dkms.conf.bak
should be enough. Then you can install the 6.8 kernel, though you will lose function of the sfp+ ports unless you pin the 6.5 kernel with the DKMS 5.19.9 driver.
I'm hoping there is a new fix shortly or that Proxmox gets around to properly supporting this NIC. When I purchased this device, I didn't realize that these NICs were a problem for Proxmox.
While this affects proxmox, it is not just a proxmox issue, it is a general Linux kernel driver issue, that affects every distribution using Linux kernel 6.* and above, so Ubuntu, debian, suse, etc ....When I purchased this device, I didn't realize that these NICs were a problem for Proxmox.
So I did a bit more digging, but still no luck with this. I did find that the driver is properly detecting the DAC cable without complaints, but it's still stuck with the NO CARRIER message. This past week I ordered a pair of Intel-branded FTLX8571D3BCV-IT. I confirmed that it also detects these properly and does turn on the laser, but they will not connect either. So the problem does seem to be somewhere other than SFP detection. I tried one of the 1G SFP ports on my box and it also won't link up, so it seems all SFPs on this model NIC are just bricked with this new kernel.
Just sticking with 1G for now because it doesn't really affect what I'm currently running, but all those fancy ports I paid for are currently unusable.
Just took a look at 5.20.3 driver from Intel and it appears they already added money patch for kernel 6.8, so this version should compile with kernel 6.8 and there is no need to pin 6.5you can pin the last proxmox 6.5 kernel and build/install the 5.20.3 driver there to regain use of your 10g ports.
/* NEED_XDP_DO_FLUSH
*
* Upstream commit 1d233886dd90 ("xdp: Use bulking for non-map XDP_REDIRECT
* and consolidate code paths") replaced xdp_do_flush_map with xdp_do_flush
* and 7f04bd109d4c ("net: Tree wide: Replace xdp_do_flush_map() with
* xdp_do_flush()") cleaned up related code.
*/
#ifdef NEED_XDP_DO_FLUSH
static inline void xdp_do_flush(void)
{
xdp_do_flush_map();
}
#endif /* NEED_XDP_DO_FLUSH */
I pinned the 6.5 kernel and installed the 5.19.9 and 5.20.3 drivers, which sadly didn't work either. The link is up while booting but dissapears when Proxmox is booted.you can pin the last proxmox 6.5 kernel and build/install the 5.20.3 driver there to regain use of your 10g ports.
Must be a different issue than what I am experiencing then, those out of tree intel drivers work fine to resurrect my SFP+ ports when installed in the Proxmox 6.5 kernel.I pinned the 6.5 kernel and installed the 5.19.9 and 5.20.3 drivers, which sadly didn't work either. The link is up while booting but dissapears when Proxmox is booted.
Unless I am misunderstanding your suggestions, I did try already and the build errored out. See https://forum.proxmox.com/threads/intel-x553-sfp-ixgbe-no-go-on-pve8.135129/post-657758Just took a look at 5.20.3 driver from Intel and it appears they already added money patch for kernel 6.8, so this version should compile with kernel 6.8 and there is no need to pin 6.5
Anyone care enough to try it?
Basically they replaced all xdp_do_flush_map to xdp_do_flush and retained backward compatibility through the following macro.
C:/* NEED_XDP_DO_FLUSH * * Upstream commit 1d233886dd90 ("xdp: Use bulking for non-map XDP_REDIRECT * and consolidate code paths") replaced xdp_do_flush_map with xdp_do_flush * and 7f04bd109d4c ("net: Tree wide: Replace xdp_do_flush_map() with * xdp_do_flush()") cleaned up related code. */ #ifdef NEED_XDP_DO_FLUSH static inline void xdp_do_flush(void) { xdp_do_flush_map(); } #endif /* NEED_XDP_DO_FLUSH */
No freaking idea why but, its true that intel still makes call toUnless I am misunderstanding your suggestions, I did try already and the build errored out. See https://forum.proxmox.com/threads/intel-x553-sfp-ixgbe-no-go-on-pve8.135129/post-657758
xdp_do_flush_map
in 5.20.3xdp_do_flush
is present: gen NEED_XDP_DO_FLUSH if fun xdp_do_flush absent in "$fh"
Looks like you made the same decisions I did, except for 'xdp_do_flush_map rename xdp_do_flush'. I'll give that a try this week.This is with the newest version 6.8.4-3
So I downloaded 5.20.3 from source forge and extracted it.
mkdir /src
cd /src
Get the tar file from here.
https://sourceforge.net/projects/e1000/files/ixgbe stable/5.20.3/
tar xvf ixgbe-5.20.3.tar.gz
installed gcc make buildtools-esentials
went to compile and got errors
There are roughly 10 errors we will have to address.
5 instances in a row of replacing strlcpy with strncpy because the compiler wanted me to do it.
on lines that it errors on replace xdp_do_flush_map with xdp_do_flush
In the ethtool.c
There will be 2 further errors
The last 2 parts of a structure, now I am sure it will come up later, but I use // to comment both of them out.
compiled again
a few more of the above xdp_do_flush_map rename xdp_do_flush
finally it compiles
make
make install
for luck I added
vi etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1
rebooted
dhclient -v eno1
BING
I had an IP address and could ping things.
I hope someone creates an official patch so we don't have to dig around in the weds like this.
Remarking out 2 entries in the ethtool.c files seems especially dodgy, but it works for me.
-------
I got 5.19.9 to compile, but there were 2 more lines I had to comment out, and seemed even more sketchy to do so.
Went ahead and gave it another go. Confirmed link is up after a reboot. Note that you have to do a reboot, just inserting the updated module does not seem to bring it to life (I think that was my original issue).On kernel 6.8.4-3, I've managed to compile ixgbe 5.20.3... module is untested yet though.
Confirming:
1) replace all "xdp_do_flush_map" with "xdp_do_flush"
2) in ixgbe_eththool.c:
- comment out 2x erroring struc lines
- replace "strlcpy" with "strscpy" in function def
I may not get to test right away as I'm traveling and I don't want to play around remote. Any others that take a swing, please post results of getting x553 NIC to come up at 10G. Comments on issues/performance welcome!
root@pve:~# ethtool eno1
Settings for eno1:
Supported ports: [ FIBRE ]
Supported link modes: 10000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 10000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: off
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Went ahead and gave it another go. Confirmed link is up after a reboot. Note that you have to do a reboot, just inserting the updated module does not seem to bring it to life (I think that was my original issue).
Which DAC/Transceiver are you using? I tried multiple transceiver and DACs and still didn't get it to work
Either way I'm using this one: https://www.amazon.com/gp/product/B00WHS3NCA/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1Nevermind. The DACS and the transceivers worked flawlessly. I still didn't manage to get it working with proxmox, but I passed the PCIe Device to my pfSense VM and it worked right out of the box.