Solarflare SFN7122F under TrueNAS: card is detected, but working multimode SFP+ modules stay dark
Building a storage box at home and picked up a dual 10GbE Solarflare SFN7122F (SFC9120) because it was cheap. The card itself looks healthy, the system sees it and both ports enumerate, but not one of my existing multimode SFP+ modules will bring up a link in it.
- Solarflare SFN7122F, dual port, SFC9120 controller
- TrueNAS SCALE on the NAS, CORE was the original plan
- 10G multimode SFP+ modules that link without complaint in another NIC
- short multimode patch cord, the same one used in the working test
eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP>What I tried:
- both ports, both modules, all four combinations, nothig ever links
- moved the exact same modules and the same patch cord to the other card, link comes up immediately
- swapped patch cords in case of a dirty end face
So the fibre and the modules are not the problem. Is this card refusing optics that are not coded for it, or is something wrong on the driver side, and would CORE behave differently from SCALE here? If it is coding, which modules do people actually have running in an SFN7122F?
Comments 3
The driver side is not your problem. The FreeBSD sfxge driver covers the Solarflare SFC9000-family 10GbE adapters, so an SFC9120 is fine on CORE, and you already see that SCALE enumerates the hardware. What you are hitting is the card's own transceiver check: it accepts modules coded for Solarflare and quietly ignores the rest, which looks exactly like what you have - a healthy card with ports that never come up.
Parts that people do have running in these: FTLX8571D3BCL-SL and SFM10G-SR. FS will also supply modules pre-coded for Solarflare if you state the target when ordering, which is usually easier than hunting down original-coded stock.
Before you spend anything, think about how long this card has to live. Solarflare went to Xilinx and driver work has stopped, so nothing further is coming for it. For a box you want to forget about, I would put Chelsio first on this platform and Intel second. For what it is worth, one long-running report here was about two years of trouble-free service from the closely related SFN6122F, rated more tolerant of random transceivers than the Intel X520 sitting next to it - but that is the older card and it does not change the coding behaviour on yours.
Ordered a pair of SFM10G-SR coded for the card and both ports came up on the first insert, so the coding theory holds. Only a partial result from my side though: the old multimode modules are still completely dead in this NIC and work only in the other card, so I now keep two sets of optics labelled and separated.
The card stays for now since it does its job, but the Chelsio hint is noted for the next one - I would rather not buy specially coded optics every time I add a port.
Worth adding one check to the general procedure, because "unsupported optics" means very different things depending on the box. On an Instant On 1930 24G the vendor's own answer was that an unsupported module (SX, LH and similar) only gets flagged - flashing port LED plus a syslog message - and the port is not disabled at all, so a link that stays down there points at the physical path, not at a lock. That case ended with a new fibre run plus a third-party 10G single-mode LR SFP+ and the link came up.
The same trap runs in the other direction with HBAs: a Brocade 825 shows up twice in lspci, and inserting optics produces nothing in dmesg, which people read as a fault. Drivers log link state, not module insertion, so silence there is not a diagnosis either.
In your case you already ran the one test that settles it, same module and same cord linking in another NIC, so a coding lock is the right conclusion. Just do not let anyone talk you into that conclusion on a box where it is only an LED and a log line.