Dell DD9900 in an HA pair doesn't see the SFP on ethMa: State UP, link status NO, Cannot get module EEPROM information
I run a backup storage system in a data center. A pair of DD9900 in HA, network ports on the NDC QLogic. After a reboot or reseating the module, port ethMa stops seeing the transceiver, and it's not a one-off - it's a stable, repeating pattern.
- Dell DD9900, DD OS 7.2.0.95, HA configuration
- NDC QLogic QL41164HMCU 4x10GbE (Dell 0XVVY1)
- modules ABCU-5710RZ-CS4B, FCLF-8521-3-HP, FTLX8571D3BCL-FC, AFBR-703ASDZ - both copper and optical
What the system shows:
State UP
link status NO
Transceiver is unplugged
Cannot get module EEPROM informationethtool -m on that port returns nothing.
What we've already tried:
- swapped modules between ports and changed patch cords - the problem follows the port, not the module
- moved the link to another switch and another switch port
- replaced the NDC itself with a new one, and after a while got exactly the same thing
Meanwhile the port is listed as UP, so the system thinks everything is fine and doesn't raise any alarm. Where should I dig next - the driver, DD OS, or is it hardware after all?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 4
Since it doesn't reproduce on a standalone system but is stable on HA, you can let go of the hardware theory. This is a QLogic driver defect that surfaces specifically in an HA configuration on DD OS 7.2. That explains the whole picture: the port is listed as UP, there's no link, and the log shows Transceiver is unplugged and Cannot get module EEPROM information. The driver simply doesn't reach the module's EEPROM, and it doesn't care what module is installed, copper or optical - which is why swapping modules, cords, switch ports, and even replacing the NDC gave nothing.
It's fixed by updating DD OS to at least 7.10.1, which ships an updated firmware and driver bundle, after which the symptom goes away. Until the upgrade window is agreed:
A caveat on support: before upgrading, check with the vendor against the compatibility matrix for your exact HA configuration - 7.10.1 is a floor, not a recommendation to install exactly that version. And for the future: newer DD systems have moved away from these NDCs toward Intel X710, so the question resolves itself when you refresh the fleet.
Three questions to narrow it down. First: does this happen on a standalone system too, or only on the HA pair? That matters because HA changes how interfaces come up and migrate, and half of stories like this live exactly there.
Second: are there only SFP modules on this card, or is there a DAC hanging off a neighboring port? QLogic's documentation explicitly forbids mixing DAC and SFP on the same card, and the consequences are exactly this - some ports stop reading the EEPROM.
Third: does
ethtool -mon the neighboring ports of the same card work fine, or is it silent too?Set up a test rig and ran it through its paces. On a standalone system with the same modules and the same DD OS 7.2, couldn't reproduce it at all, no matter how much we pulled modules or rebooted. It only happens on the HA pair, and that does seem to be the key.
We're not mixing DAC and SFP on the same card, all four ports have modules of the same type.
ethtool -mreads fine on the neighboring ports, EEPROM comes back in full, but on ethMa it's that same Cannot get module EEPROM information, until the port comes up on its own after the next reboot.I'll second "move away from QLogic." We had a QLogic 8262 board (8200 series) in FreeNAS 11.3-U5 on an HP MicroServer Gen10: both PCI functions are visible, but only ql0 works, while ql1 comes up as none2 and doesn't initialize, so half the card is simply dead.
The log shows
0x200000 bytes of rid 0x10 res 3 failedon every boot, followed byunable to map any ports. Advice was to check viapciconf -lwhether it's a rebranded HP NC523SFP, update the adapter firmware, and play with the MSI/MSI-X tunables. None of it helped, the card ended up being replaced, and for storage the recommendation there in plain terms is Chelsio T520-CR or Intel X520. So the move to X710 in newer systems looks like a natural consequence.