I have recently swapped network cards from a dual port Solarflare SFN6122F (uses an sfc_siena driver) to a Solarflare SFN8522 (uses sfc) adapter. Shut down, swapped cards, rebooted and have just spent the last 3 hours working out why my network card no longer has a link detected for more than a few seconds after power on. All cables are the same between the two adapter cards and I have also tried with different cables. kernel-6.4.4-200.fc38.x86_64 tuned-2.20.0-1.fc38.noarch This is possibly a tuned bug or maybe it's a kernel bug. Thoguth I'd start with tuned as not running that fixes the immediate problem. Reproducible: Always Steps to Reproduce: 1. Install Solarflare SFN8522 and connect using Direct Attach cable to a switch or to another machine (I do both) 2. Install tuned and set to use profile 'powersave' 3. May need a reboot to activate tuned Actual Results: A cold boot (power on) comes up as normal, link is detected, connection established for anything between 1s and about 1 minute then it goes away. Running `ethtool enp9s0f0np0` shows "Link detected: No". Syslog shows Jul 26 21:48:29 trevor4 kernel: [ 5.263140] sfc 0000:09:00.0: Solarflare NIC detected Jul 26 21:48:29 trevor4 kernel: [ 5.269260] sfc 0000:09:00.0: Part Number : SFN8522 Jul 26 21:48:29 trevor4 kernel: [ 5.498217] sfc 0000:09:00.1: Solarflare NIC detected Jul 26 21:48:29 trevor4 kernel: [ 5.501776] sfc 0000:09:00.1: Part Number : SFN8522 Jul 26 21:48:29 trevor4 kernel: [ 5.522425] sfc 0000:09:00.0 enp9s0f0np0: renamed from eth0 Jul 26 21:48:29 trevor4 kernel: [ 5.617192] sfc 0000:09:00.1 enp9s0f1np1: renamed from eth1 Jul 26 21:48:27 trevor4 kernel: sfc 0000:09:00.0: Solarflare NIC detected Jul 26 21:48:27 trevor4 kernel: sfc 0000:09:00.0: Part Number : SFN8522 Jul 26 21:48:27 trevor4 kernel: sfc 0000:09:00.1: Solarflare NIC detected Jul 26 21:48:27 trevor4 kernel: sfc 0000:09:00.1: Part Number : SFN8522 Jul 26 21:48:27 trevor4 kernel: sfc 0000:09:00.0 enp9s0f0np0: renamed from eth0 Jul 26 21:48:28 trevor4 kernel: sfc 0000:09:00.1 enp9s0f1np1: renamed from eth1 Jul 26 21:48:29 trevor4 kernel: [ 7.167012] sfc 0000:09:00.0 enp9s0f0np0: link up at 10000Mbps full-duplex (MTU 1500) Jul 26 21:48:29 trevor4 kernel: sfc 0000:09:00.0 enp9s0f0np0: link up at 10000Mbps full-duplex (MTU 1500) Jul 26 21:48:29 trevor4 kernel: [ 7.340488] sfc 0000:09:00.1 enp9s0f1np1: link up at 10000Mbps full-duplex (MTU 1500) Jul 26 21:48:29 trevor4 kernel: sfc 0000:09:00.1 enp9s0f1np1: link up at 10000Mbps full-duplex (MTU 1500) Jul 26 21:49:20 trevor4 kernel: [ 57.446270] sfc 0000:09:00.0 enp9s0f0np0: link down Jul 26 21:49:20 trevor4 kernel: [ 57.446440] sfc 0000:09:00.0 enp9s0f0np0: link down Jul 26 21:49:20 trevor4 kernel: [ 57.488974] sfc 0000:09:00.1 enp9s0f1np1: link down Jul 26 21:49:20 trevor4 kernel: [ 57.489024] sfc 0000:09:00.1 enp9s0f1np1: link down # sfctool enp9s0f0npo0 Settings for enp9s0f0np0: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 1000baseX/Full 10000baseCR/Full 10000baseSR/Full 10000baseLR/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 1000baseT/Full 1000baseX/Full 10000baseCR/Full 10000baseSR/Full 10000baseLR/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: Not reported Link partner advertised pause frame use: No Link partner advertised auto-negotiation: No Link partner advertised FEC modes: Not reported Speed: 10000Mb/s Duplex: Full Port: FIBRE PHYAD: 255 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x000020f7 (8439) drv probe link ifdown ifup rx_err tx_err hw Link detected: no At this point I found that the only way to get the Link Detected: yes back was to cold boot the machine using the power button. Ctrl-Alt-Del sometimes seemed to work but the only reliable way to get it working again was to power off/on. This was repeatable on every boot, link would connect, things would work for some time - never more than about one minute, sometimes going away before I could even login to ping things. I have two of these cards installed, one in a machine with tuned set to profile powersave which exhibits the problem. The other is set to profile virtual-host and does not. I have swapped SFN8522 cards between the 2 systems and both work in the virtual-host system and both fail in the one in powersave mode. After many many reboots into single user, multi-user, and emergency targets and activating the network manually with `ip`, then bringing up services one by one I found that `systemctl mask tuned` will stop this. I haven't experimented with tuned settings to see if I can get it to stop doing whatever it is that it's doing that breaks this. I'm just thankful to have a working network connection again! Expected Results: Network connection works reliably without needing power off/on! Link detected: yes While debugging this problem I have used sfboot to reset the dual port adapter to all default settings, upgraded to latest Solarflare firmware: Firmware version: v8.5.2 Controller type: Solarflare SFC9200 family Controller version: v8.5.0.1002 Boot ROM version: v5.2.2.1006 UEFI ROM version: v2.9.6.3 I actually use a profile called powersave-nodisk which is set to use the following # cat /etc/tuned/powersave-nodisk/tuned.conf [main] summary=Optimize for low power consumption but leave storage alone include=powersave [disk] devices=sdz I have no sdz, I just wanted it to stop powering down the two spinning rust devices in my mdadm array.