Dear Tony,
One more follow-up: Am 18.02.26 um 13:09 schrieb Paul Menzel:
Am 17.02.26 um 19:16 schrieb Tony Nguyen:On 2/17/2026 9:15 AM, Paul Menzel wrote:I spoke to one of our link people about this.It works with Broadcom network controller BCM57414: $ lspci -nn -s c4:00 c4:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller [14e4:16d7] (rev 01) c4:00.1 Ethernet controller [0200]: Broadcom Inc. and subsidiaries BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller [14e4:16d7] (rev 01)The difference seems to be that the Broadcom device supports auto- negotiation, and the Intel device does not:Strictly speaking, optical links do not provide auto-negotiation.Intel E810-XXV: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 10000baseT/Full 25000baseCR/Full 25000baseSR/Full 1000baseX/Full 10000baseCR/Full 10000baseSR/Full 10000baseLR/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: None Advertised link modes: 25000baseSR/FullThe important part is here 10G is not an advertised link mode...Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: None Speed: Unknown! Duplex: Unknown! (255) Auto-negotiation: off Port: FIBRE PHYAD: 0 Transceiver: internal Supports Wake-on: d Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: no Broadcom BCM57414 NetXtreme-E: Supported ports: [ FIBRE ] Supported link modes: 25000baseSR/Full 10000baseSR/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: RS BASER Advertised link modes: 25000baseSR/Full 10000baseSR/Full... where it is here.Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Auto-negotiation: on Port: FIBRE PHYAD: 1 Transceiver: internal Supports Wake-on: g Wake-on: d Current message level: 0x00002081 (8321) drv tx_err hw Link detected: noPS: ``` $ ip link show net04 7: net04: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq switchid b48351ffff278d44 state DOWN mode DEFAULT group default qlen 1000 link/ether b4:83:51:27:8d:44 brd ff:ff:ff:ff:ff:ff alias eth4 $ sudo ethtool -m net04 Identifier : 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x07 (LC) Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x020x10 would be here for advertised 10G support. It is not, which is why it's not being advertised. He mentioned it's very common for dual rates to claim it on paper but not advertise it properly.Thank you for looking into this. It should work in this case, as it works with the Broadcom device.Could you provide the output for 'ethool -m <INT> hex on'?Sure. Please find it attached for the Intel and Broadcom device. It’s the same GBIC model and only the serial number should differ.
The Dell support pointed to the section *Known Issues* in the release notes of the Intel network controller firmware version 24.0.5 [1]:
- When using the dual rate 10G/25G SR optics module (DN# M14MK), linking at 10G may not be possible if auto negotiation is enabled. To workaround this issue, disable Auto Negotiation on the switch interface. On the adapter side: - To obtain 10Gps link on pre-OS environment, set Media Detection to Disabled in Main Configuration Page and in NIC Configuration, uncheck the box labeled 25G and make surethe box for 10G is checked, this will force the link speed to 10Gps. - To obtain 10Gps link on OS, you will need to manually set the speed to 10Gps. For example,use "ethtool -s INTERFACE advertise 0x80000000000" on Linux.
(I am unclear to what component “if auto negotiation is enabled” refers to.)Anyway, without changing anything on the switch, running the suggested command
sudo ethtool -s p3p2 advertise 0x80000000000
get the link up:
ice 0000:81:00.1 p3p2: NIC Link is up 10 Gbps Full Duplex,
Requested FEC: RS-FEC, Negotiated FEC: NONE, Autoneg Advertised: Off,
Autoneg Negotiated: False, Flow Control: None
Does the Linux kernel need a quirk to work around the broken firmware. (Which hopefully will still be fixed in future releases.)
Kind regards, Paul
PS: For completeness: $ ethtool -i net04 driver: ice version: 6.12.0-160000.5-default firmware-version: 4.80 0x800206a0 24.0.5 expansion-rom-version: bus-info: 0000:81:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes
[1]: https://dl.dell.com/FOLDER13423820M/2/fw_release_e810_e823-20250910.txt?uid=68fa5efd-5f60-4811-eb0a-05c0b9fee2e5&fn=fw_release_e810_e823-20250910.txt "Intel(R) E810 Adapter and E823 LOM Firmware Release Notes for Version 24.0.5"
