Hello all,
My firewall is running with a 2 port X550. I have these ports connected to a 2.5 gig switch. When I look at the switch these ports are running at 1 gig. In doing some research here I found that I need to augment the config of the X550 ports, to support 2.5 gig. Out of the gate the OS supports 100M, 1 gig, and 10 gig. I want to add support for 2.5 gig. I added sysctl dev.ix.0.advertise_speed=23 to /boot/loader.conf but it looks to get overwritten at OS boot time. The file's documentation tells me to add this to the tunables section in the GUI, so I did that and rebooted but my switch is still showing that the ports are running at 1 gig.
The tunables section has a type selection, which is boot-time, runtime, or environment. I have no ability to change this so my additions are running as environment. This could be the problem. Has anyone had success in get the X550 ports to support 2.5 gig?
Thanks,
Steve
Those adapters cannot reliably auto-negotiate the intermediate speeds, and they cannot do this on other OSes, either.
This has been the case since 23.1 - potentially because of the underlying FreeBSD version, see https://github.com/opnsense/core/issues/6526
Thus, you can only do as much as advertise the capability on OpnSense and force the 2.5 Gpbs speed from the other side.
See also:
https://forum.opnsense.org/index.php?topic=33154.0
(and other topics in this forum)
1st thing to try is what meyergru mentions, hard set both sides and see what you get.
After that, go see if there's some new firmware available from the Intel 34.0 bundle download.
I forget what driver is used for x550, but maybe try "dmesg |grep x550" and lets see where its at on nvm version.
Quote from: meyergru on September 16, 2025, 09:36:37 PMThose adapters cannot reliably auto-negotiate the intermediate speeds, and they cannot do this on other OSes, either. [...]
Interestingly, Intel indicates "NBASE-T support in Linux Only", and while multi-gig/NBASE-T rates are listed in some places ("Data Rate Per Port 10GbE/5GbE/2.5GbE/1GbE/100Mb"), they are not in others (e.g. the adapter product brief).
Quote from: pfry on September 17, 2025, 03:02:29 AMInterestingly, Intel indicates "NBASE-T support in Linux Only"
It's more weird than interesting. Probably has to do with linux driver, which gets more attention than any other.
Really need to go back and understand 802.3bz, because this spec has in it ability for "learning" best speed based on cable quality.
Is freeBSD driver as robust? Not sure.
Could it be switch firmware? Are there any updates available for that item?
Is your cable a quality twisted pair than is certified for 802.3bz? If not then get a certified cable is and see if that's better.
Hard to know for sure where/what is causing the issue. Try new cable and auto, try hard set, do you get your desired 2.5Gb?
Did you read this Intel doc https://cdrdv2.intel.com/v1/dl/getContent/335253
freeBSD 14.x is a supported OS
Quote from: BrandyWine on September 17, 2025, 04:47:01 AM[...]
Really need to go back and understand 802.3bz, because this spec has in it ability for "learning" best speed based on cable quality.[...]
I'm not aware of any cable testing or training as part of any Ethernet link establishment - the link is simply negotiated to the highest common advertised speed (and not always successfully). Cable quality (assuming a cable that allows minimal communication between the endpoints) should not affect autonegotiation. Any testing and link speed reduction would be manual (as in the rest of your post). Heck, the only relevant testing I know of (without specialized equipment) is "looking at counters" (on both ends). (I suppose TDR can be useful if you don't know how long your cable is.)
I don't know of any good resources that cover later 802 standards (for less than IEEE prices).
Folks, note, that I wrote: "It cannot handle
auto-negotiation of NBASE-T", not: "it cannot handle them it all".
AFAIK, it can handle those speeds in any OS. With autonegotiation, it normally will only use 100, 1 or 10000 Mbps and that pertains also to Linux. That is even in the Intel docs:
Quote# ethtool <ethX>
By default, devices based on the Intel(R) Ethernet Controller x550 do not
advertise 2.5 Gbps or 5 Gbps. To have your device advertise these speeds, use
the following:
# ethtool -s <ethX> advertise N
Where N is a combination of the following.
100baseTFull 0x008
1000baseTFull 0x020
2500baseTFull 0x800000000000
5000baseTFull 0x1000000000000
10000baseTFull 0x1000
For example, to turn on all modes:
# ethtool -s <ethX> advertise 0x1800000001028
For more details please refer to the ethtool man page.
NOTE: On Linux systems with INTERFACES(5), this can be specified as a pre-up
command in /etc/network/interfaces so that the interface is always brought up
with NBASE-T support. For example:
# iface <ethX> inet dhcp
pre-up ethtool -s <ethX> advertise 0x1800000001028 || true
Caution: Only experienced network administrators should force speed and duplex
or change autonegotiation advertising manually. The settings at the switch must
always match the adapter settings. Adapter performance may suffer or your
adapter may not operate if you configure the adapter differently from your
switch.
In Linux, you can ask the driver to advertise those speeds, though. So, it is either that or disable autonegotitation on either side.
BTW: The FreeBSD Intel ix driver has a section in it that reads:
Quoteif (hw->mac.type == ixgbe_mac_X550 &&
hw->phy.autoneg_advertised == 0) {
/*
* 2.5G and 5G autonegotiation speeds on X550
* are disabled by default due to reported
* interoperability issues with some switches.
*
* The second condition checks if any operations
* involving setting autonegotiation speeds have
* been performed prior to this ixgbe_config_link()
* call.
*
* If hw->phy.autoneg_advertised does not
* equal 0, this means that the user might have
* set autonegotiation speeds via the sysctl
* before bringing the interface up. In this
* case, we should not disable 2.5G and 5G
* since that speeds might be selected by the
* user.
*
* Otherwise (i.e. if hw->phy.autoneg_advertised
* is set to 0), it is the first time we set
* autonegotiation preferences and the default
* set of speeds should exclude 2.5G and 5G.
*/
autoneg &= ~(IXGBE_LINK_SPEED_2_5GB_FULL |
IXGBE_LINK_SPEED_5GB_FULL);
}
The FreeBSD ix docs (https://man.freebsd.org/cgi/man.cgi?ix) are quite unhelpful as to what is to be specified to get the correct advertisements, so:
#define IXGBE_LINK_SPEED_UNKNOWN 0
#define IXGBE_LINK_SPEED_10_FULL 0x0002
#define IXGBE_LINK_SPEED_100_FULL 0x0008
#define IXGBE_LINK_SPEED_1GB_FULL 0x0020
#define IXGBE_LINK_SPEED_2_5GB_FULL 0x0400
#define IXGBE_LINK_SPEED_5GB_FULL 0x0800
#define IXGBE_LINK_SPEED_10GB_FULL 0x0080
#define IXGBE_LINK_SPEED_82598_AUTONEG (IXGBE_LINK_SPEED_1GB_FULL | \
IXGBE_LINK_SPEED_10GB_FULL)
#define IXGBE_LINK_SPEED_82599_AUTONEG (IXGBE_LINK_SPEED_100_FULL | \
IXGBE_LINK_SPEED_1GB_FULL | \
IXGBE_LINK_SPEED_10GB_FULL)
Thus, I assume that "hw.ix.advertise_speed = 0x0CAA" or "hw.ix.advertise_speed = 3242" might do the trick, but I haven't tried.
Quote from: meyergru on September 17, 2025, 10:26:23 AMThus, I assume that "hw.ix.advertise_speed = 0x0CAA" or "hw.ix.advertise_speed = 3242" might do the trick, but I haven't tried.
That sysctl to define what the default advertise speed is for all, should work, but I think you add up all the values 1st. (https://man.freebsd.org/cgi/man.cgi?ix)
There's another per-nic setting to look at,
dev.ix.<X>.advertise_speedhttps://docs.netgate.com/pfsense/en/latest/hardware/tune.html#intel-ix-4-cards
It looks like you add up the hex values for each speed you want, that total goes into the tunable.
QuoteFor example, to advertise speeds of 1G, 2.5G, 5G, and 10G, add their corresponding values: 0x2+0x10+0x20+0x4 (hex) or 2+16+32+4 (decimal) for a total of 0x36 (hex) or 54 (decimal). Values in hexadecimal must start with 0x.
That could be, although I read somewhere that Netgate uses their own driver for ix (https://forum.netgate.com/topic/173897/pfsense-22-05-ix-driver-vs-intel-ix-kmod), so IDK if YMMV with OpnSense.
Also note that the hex values for pfSense differ from what can be read from the FreeBSD ix driver source code. I added up all the values from the constants contained in there to get at 0x0CAA hex / 3242 decimal.
Quote from: meyergru on September 17, 2025, 03:42:02 PMThat could be, although I read somewhere that Netgate uses their own driver for ix (https://forum.netgate.com/topic/173897/pfsense-22-05-ix-driver-vs-intel-ix-kmod), so IDK if YMMV with OpnSense.
Also note that the hex values for pfSense differ from what can be read from the FreeBSD ix driver source code. I added up all the values from the constants contained in there to get at 0x0CAA hex / 3242 decimal.
Good info.
And look at that chart on netgate page, kinda odd, the text mentions numbers but those numbers are not in the chart.
If possible, use the per-nic sysctl on a unused nic, then cable it up and see what it does.
So here is the problem that I see...
First off if you read the text at the top of /boot/loader.conf it says the file is autogenerated and to use /boot/loader.conf.local. I did that and entered two parameter lines: sysctl dev.ix.0.advertise_speed=23 and sysctl dev.ix.1.advertise_speed=23. This tells both ports that it can support 2.5 gig. It does not seem this gets loaded after a reboot bc when I run sysctl dev.ix.0.advertise_speed and sysctl dev.ix.1.advertise_speed they both output 7, which is the default to support 100M, 1G, and 10G.
I just tried hex instead of decimal and that made no change. I think the first thing is to understand if using loader.conf.local works bc right now it does not seem to be working. Second I am going to remove the changes and try to force it on the switch side and see what happens. More to come.
In loader.conf or loader.conf.local you just write the variables and their values without the "sysctl" in front.
Better use the UI: System > Settings > Tunables.
Quote from: meyergru on September 17, 2025, 10:26:23 AM[...]
Thus, I assume that "hw.ix.advertise_speed = 0x0CAA" or "hw.ix.advertise_speed = 3242" might do the trick, but I haven't tried.
Nice. Nitpick: I'd probably reset bit 1 (10BASE-T) on ix, as some of Intel's docs suggest that it's not supported. Of course, you could always try it. I don't know if anyone would need/want to set bit 2 (100BASE-TX half-duplex), but it's there.
As far as the "make the special case general" in the driver: Grrr.
@spetrillo: What makes you believe that 23 is the correct value? Do you have any reliable source for that assumption?
It is neither for the Netgate version according to their docs nor is it according to the source code of the ix driver in FreeBSD, which should be the one you use in OpnSense. The value 0x0CAA (or 3242 decimal) will enable autonegotiation for all speeds, 23 is most probably incorrect, IMHO.
Quote from: pfry on September 17, 2025, 04:58:01 PMNice. Nitpick: I'd probably reset bit 1 (10BASE-T) on ix, as some of Intel's docs suggest that it's not supported. Of course, you could always try it. I don't know if anyone would need/want to set bit 2 (100BASE-TX half-duplex), but it's there.
I posted the Intel doc a few posts back. It only runs 4 speeds (edit: it might support 100M). My guess is the nvm image is the final say so. If the ix supports a setting for 10 or 100, my guess is the nvm laughs at the request. NBASE-T is suppose to be 802.3bz compliant,
but I don't see it called out anywhere in Intel docs Intel does say x550 is 802.3bz, see post #28 for link to Intel doc. I would craft the tunable number to support these 4 speeds.
Quote5 Gb/s (NBASE-T mode)
• 2.5 Gb/s (NBASE-T mode)
• 1 Gb/s (1000BASE-T mode)
• 100 Mb/s (100BASE-TX mode)
Quote from: meyergru on September 17, 2025, 10:26:23 AMBTW: The FreeBSD Intel ix driver has a section in it that reads:
Quoteif (hw->mac.type == ixgbe_mac_X550 &&
hw->phy.autoneg_advertised == 0) {
/*
* 2.5G and 5G autonegotiation speeds on X550
* are disabled by default due to reported
* interoperability issues with some switches.
*
* The second condition checks if any operations
* involving setting autonegotiation speeds have
* been performed prior to this ixgbe_config_link()
* call.
*
* If hw->phy.autoneg_advertised does not
* equal 0, this means that the user might have
* set autonegotiation speeds via the sysctl
* before bringing the interface up. In this
* case, we should not disable 2.5G and 5G
* since that speeds might be selected by the
* user.
*
* Otherwise (i.e. if hw->phy.autoneg_advertised
* is set to 0), it is the first time we set
* autonegotiation preferences and the default
* set of speeds should exclude 2.5G and 5G.
*/
autoneg &= ~(IXGBE_LINK_SPEED_2_5GB_FULL |
IXGBE_LINK_SPEED_5GB_FULL);
}
Thus, I assume that "hw.ix.advertise_speed = 0x0CAA" or "hw.ix.advertise_speed = 3242" might do the trick, but I haven't tried.
You always bring up info that makes me wonder if coders are good or not.
If the tunable for phy.autoneg_advertised = 0, then why would coders think they should choose an arbitrary set of speeds to include or exclude? Makes no sense. If it's set to 0 then why would autonegotiate even happen? Would make more sense to just set a number (the default) that equals the math used to define what speeds should be advertised. And then we must ask, why disable speeds (by default) for the reason of "some switches were having an issue negotiating", just leave all the speeds active and when that rare switch has an issue there's a ReleaseNotes doc that explains how to set the tunable to exclude one or more speeds. And better yet, if they know autoneg for 2.5 a 5 are having issues, then why not actually fix that issue instead of band-aid that disables speeds most people want to use.
I guess from coding view they use "ixgbe", but the driver for freeBSD is "ix". Linux uses "ixbge"
But check this out. Looks like there's a driver issue where although it negotiated correctly, it did not report the actual speed. A fix as of Sep 12 2025. So the freeBSD might be lying about actual speed. Probably not related to actual speed if the switch port also says it's only 1G.
https://cgit.freebsd.org/src/commit/?h=stable/14&id=7dc494e6377451469763a8a687032dee2b8324b2
Quoteixgbe: Fix incomplete speed coverage in link status logging
Originally ixgbe_if_update_admin_status() only handled 1G and 10G speeds,
causing any other speeds to display as "1 Gbps" in link status logs.
(https://i.postimg.cc/sDKPyLw2/Screenshot-2025-09-17-131613.png)
I guess at the time of writing that code, Intel assumed that this is a server adapter and that the intermediate NBASE-T speeds would not be needed - they were newly introduced, the X540-T did not have them at all. Furthermore, the first switch implementations came before the finalization of the standard, so they feared problems. I find the lack of documentation way worse that the fact itself.
That adapter is kinda strange, anyways. Under Windows, you can only set speeds explicitely, not limit it. 10 Gbe sometimes is a problem with long cabling and also uses a boatload of power. 5 Gbps mostly works, but you have to disable autonegotiation to use it.
Sigh, drivers.... Today, I had to switch back to the NDIS drivers for my Realtek 8126 NIC under Windows 11 from the more modern NetAdapterCx variant, after I found out that the latter receives only 1.4 Gbps at most (sending was fine). The NDIS drivers can handle the full 5/5 Gbps.
Quote from: meyergru on September 17, 2025, 07:51:18 PM@spetrillo: What makes you believe that 23 is the correct value? Do you have any reliable source for that assumption?
It is neither for the Netgate version according to their docs nor is it according to the source code of the ix driver in FreeBSD, which should be the one you use in OpnSense. The value 0x0CAA (or 3242 decimal) will enable autonegotiation for all speeds, 23 is most probably incorrect, IMHO.
I found this in another post on the X550. Here is the post link: https://forum.opnsense.org/index.php?topic=43906.msg218886#quickreply_anchor
Quote from: AhnHEL on December 10, 2024, 02:48:32 AMSee if this helps you.
Quotesysctl dev.ix.X.advertise_speed=N
Where X is the interface number (e.g. for ix0, X=0 in the command above) and N is the sum of the advertised speeds, works.
In hex and decimal:
Control advertised link speed using these flags:
0x1 - 1 - advertise 100M
0x2 - 2 - advertise 1G
0x4 - 4 - advertise 10G
0x8 - 8 - advertise 10M
0x10 - 16 - advertise 2.5G
0x20 - 32 - advertise 5G
100M and 10M are only supported on certain adapters.
To add advertisement of 2.5G and 5G on ix0:
sysctl dev.ix.0.advertise_speed=55
Since 7 + 16 + 32 = 55.
One thing I did not do on the card was to update the NVM. I updated the card's firmware but not the NVM. I am going to do this now.
That info was:
1. Straight from the pfSense thread: https://forum.netgate.com/topic/146913/nbase-t-support-for-intel-x550/72
2. Not confirmed working in the thread you linked to for OpnSense.
The reason is - as I already told, that those values are not the ones in FreeBSD sources and that pfSense uses their own driver with different values, so: Did you try my proposed value?
I have not tried your proposed value...what I did was follow what Patrick Hausen propsed and it sorta worked. I entered the following in /System/Settings/Tunables section: dev.ix.0.advertise_speed and dev.ix.1.advertise_speed with a value of 23. Both ports now show 23 as their setting. Port 0 shows a speed of 2500M but port 1 shows a speed of 100M.
One step forward...sort of!
Well this is weird...but I think I know what has happened.
I went back into the Tunables section and just applied the changes one more time. I then rebooted. Now both ports are registering at 2500M. I would be careful when adding multiple additions in the Tunables. I would do one at a time, apply, and then reboot. Ensure the first change is working. Then rince and repeat with each change.
dev.ix.0.advertise_speed
dev.ix.1.advertise_speed
value is 23 for 2500M
I have an X550 in my firewall and I select the speed via the GUI. See attachment, connects at 2500 to cable modem. Provisioned for 1.2GbE, see speeds at high at 1.55Gb download speeds. I updated the NVM with the latest from Dec, 2024 and use the OPNsense ix driver without issue.
Z00m
Here's your numbers, add them up, insert into tunable, reboot as needed.
2+4+16+32 = 54
Quote#define IXGBE_SYSCTL_DESC_ADV_SPEED \
"\nControl advertised link speed using these flags:\n" \
"\t0x1 - advertise 100M\n" \
"\t0x2 - advertise 1G\n" \
"\t0x4 - advertise 10G\n" \
"\t0x8 - advertise 10M\n\n" \
"\t0x10 - advertise 2.5G\n" \
"\t0x20 - advertise 5G\n\n" \
"\t100M and 10M are only supported on certain adapters.\n"
Reference: if_ix.c and ixgbe.h
https://cgit.freebsd.org/src/tree/sys/dev/ixgbe?h=stable/14&id=7dc494e6377451469763a8a687032dee2b8324b2
Quote from: zz00mm on September 18, 2025, 12:54:42 AMI have an X550
I think OP has x550T2.
Interesting, in the ixgbe h file I don't find a device ID for x550T2. So a little more sleuth work to be done.
https://cgit.freebsd.org/src/tree/sys/dev/ixgbe/ixgbe_type.h
I have an X550 with two RJ-45 ports. I hope that clears things up.
Quote from: BrandyWine on September 17, 2025, 10:53:03 PMQuote from: meyergru on September 17, 2025, 10:26:23 AMBTW: The FreeBSD Intel ix driver has a section in it that reads:
Quoteif (hw->mac.type == ixgbe_mac_X550 &&
hw->phy.autoneg_advertised == 0) {
/*
* 2.5G and 5G autonegotiation speeds on X550
* are disabled by default due to reported
* interoperability issues with some switches.
*
* The second condition checks if any operations
* involving setting autonegotiation speeds have
* been performed prior to this ixgbe_config_link()
* call.
*
* If hw->phy.autoneg_advertised does not
* equal 0, this means that the user might have
* set autonegotiation speeds via the sysctl
* before bringing the interface up. In this
* case, we should not disable 2.5G and 5G
* since that speeds might be selected by the
* user.
*
* Otherwise (i.e. if hw->phy.autoneg_advertised
* is set to 0), it is the first time we set
* autonegotiation preferences and the default
* set of speeds should exclude 2.5G and 5G.
*/
autoneg &= ~(IXGBE_LINK_SPEED_2_5GB_FULL |
IXGBE_LINK_SPEED_5GB_FULL);
}
Thus, I assume that "hw.ix.advertise_speed = 0x0CAA" or "hw.ix.advertise_speed = 3242" might do the trick, but I haven't tried.
You always bring up info that makes me wonder if coders are good or not.
If the tunable for phy.autoneg_advertised = 0, then why would coders think they should choose an arbitrary set of speeds to include or exclude? Makes no sense. If it's set to 0 then why would autonegotiate even happen? Would make more sense to just set a number (the default) that equals the math used to define what speeds should be advertised. And then we must ask, why disable speeds (by default) for the reason of "some switches were having an issue negotiating", just leave all the speeds active and when that rare switch has an issue there's a ReleaseNotes doc that explains how to set the tunable to exclude one or more speeds. And better yet, if they know autoneg for 2.5 a 5 are having issues, then why not actually fix that issue instead of band-aid that disables speeds most people want to use.
I guess from coding view they use "ixgbe", but the driver for freeBSD is "ix". Linux uses "ixbge"
But check this out. Looks like there's a driver issue where although it negotiated correctly, it did not report the actual speed. A fix as of Sep 12 2025. So the freeBSD might be lying about actual speed. Probably not related to actual speed if the switch port also says it's only 1G.
https://cgit.freebsd.org/src/commit/?h=stable/14&id=7dc494e6377451469763a8a687032dee2b8324b2
Quoteixgbe: Fix incomplete speed coverage in link status logging
Originally ixgbe_if_update_admin_status() only handled 1G and 10G speeds,
causing any other speeds to display as "1 Gbps" in link status logs.
(https://i.postimg.cc/sDKPyLw2/Screenshot-2025-09-17-131613.png)
This might make sense. What I am seeing now is that the switch is reporting the second port is running at 100M but the firewall is telling me the dev.ix.1.advertise_speed=23, which should mean it should do 2500M.
Quote from: spetrillo on September 18, 2025, 02:30:57 AMI have an X550 with two RJ-45 ports. I hope that clears things up.
This might make sense. What I am seeing now is that the switch is reporting the second port is running at 100M but the firewall is telling me the dev.ix.1.advertise_speed=23, which should mean it should do 2500M.
Can you run "dmesg |grep ix" and "ifconfig |grep ix" and post that up.
I don't think 23 means 2.5G. 23 is a bit mask and it represents a selection of speeds.
23 is mask for 1/2/4/16, the 550 does not support 100M*(maybe), at least the Intel doc says that. If your ix has the reporting bug as I posted, then it will be hard to know for sure what speed it's at, but if there's a mismatch then the tx0/rx1-tx1/rx0 wont work right.
Try dev.ix.1.advertise_speed=22 (or 54) and see what happens. If when having 2.5 and/or 5.0 in the auto mask causes an issue for swicth port getting to link, then most likely you have one of the problem switches, as mentioned a few times in posts behind this one.
I am perhaps wrong about 100M support, but Intel docs seem to contradict themselves.
An interesting read. I believe freeBSD ix is capable for nbase-t.
With 2.5 and 5 advertise disabled in 550 nvm (default state), this is probably why the ix driver does the same when the sysctl settings = 0.
Item #6 is interesting, seems to suggest you can't disable autoneg (hard set) for x550 nics.
Quotehttps://cdrdv2-public.intel.com/333717/X550_SpecUpdate_rev3_1.pdf
Oct 2024
2. NBASE-T Speed Advertisement
NBASE-T speed advertisement (2.5 GbE/5 GbE) is disabled by default in the X550 NVM. An NBASE-T
enabled driver should be used to link at NBASE-T speeds.
Linux driver version 4.3.9 is currently the only supported software solution for NBASE-T.
For future planned enhancements, contact your Intel representative.
6. The X550 Supports Only Auto-Negotiated Link at 100Mb
The X550 does not implement the necessary function to detect and link at 100Mb without
Auto-Negotiation, as only Auto-Negotiation is supported at any speed.
Quote from: spetrillo on September 18, 2025, 02:30:57 AMI have an X550 with two RJ-45 ports. I hope that clears things up.
Is it a T2? We need the dmesg output, you said you had 550 dual port, so it's a AT2 or a BT2.
Quote from: spetrillo on September 01, 2025, 09:04:48 PMI am ab out to change out my Intel I350-T4 with an Intel X550-T2. I selected the X550-T2 because it does multiple speeds, including 2.5 and 5 gig
Here is the info right from the Amazon listing:
10Gb PCI-E NIC Network Card for Intel X550-T2,2.5GbE/5GbE/10GbE Copper Dual RJ45 Ports,with Intel ELX550AT2 Chip,10GbE PCI Express 3.0 X4 Ethernet Adapter Support Windows/Linux/VMware
So it seems the card is called a X550-T2 but the chipset is AT2. Did i read that correctly?
Quote from: spetrillo on September 18, 2025, 07:46:00 PMSo it seems the card is called a X550-T2 but the chipset is AT2. Did i read that correctly?
Let me explain.
1) You have it in reverse. Chipset is the x550, T AT2 BT2 are the form-factors.
2) Still need "dmesg |grep ix" to see how the system is identifying your x550. It's been seen before, weird device ID's are reported.
3) What switch make/model do you have?
4) I missed it earlier from Intel doc (page 24) in post #28, x550 is 802.3bz compliant. To get 2.5 5G both sides needs to be 802.3bz. It's very possible a "bad" cable causes link to downshift. Is your cable 802.3bz certified? A decent Cat5e cable should support 2.5G w/o issue.
Quote from: pfry on September 17, 2025, 09:25:16 AMI'm not aware of any cable testing or training as part of any Ethernet link establishment - the link is simply negotiated to the highest common advertised speed
Not the case in 802.3bz, as long as the devices are fully 802.3bz compliant. "NBASE-T Downshift" is the coding name for the learning. It's a method to detect if the cable is causing packet issues, the coding can then do a speed downshift in an effort to remedy the packet issue, this helps keep data moving err free but sacrificing some speed.
A good read (https://archive.nbaset.ethernetalliance.org/wp-content/uploads/2017/05/NBASET-Downshift-WP-1217.pdf)
Alien noise in home environments can be an issue just like a bundle of Cat5e/6 in structured wiring in buildings. More rare in the home though.
Quotehowever, the quality of the cable, how
cables are bundled together, or "alien noise"
IEEE 802.3bz Auto-Negotiation Detail
The 2.5GBASE-T and 5GBASE-T standards use IEEE 802.3bz
Auto-Negotiation, specified in Clause 28, Clause 126.6, Annex
28B, Annex 28C, and Annex 28D.
As part of the link-training sequence,
Quote from: BrandyWine on September 18, 2025, 08:50:08 PMNot the case in 802.3bz, as long as the devices are fully 802.3bz compliant. "NBASE-T Downshift" is the coding name for the learning.[...]
I had not seen that. Heh. Learn something new every day. I wonder what the implementation rate is. There is some material flying around on the Internet that claims "wide implementation". Perhaps it's been hanging around in the background.
Yet another update.
According to the driver code, you cannot use "dev.ix.<X>.advertise_speed" (well you can, but driver code disables based on phy).
The code is only checking for "phy.autoneg_advertised == 0", so even if per iface is set and the phy is 0, the driver will disable 2.5 5 autoneg capable bits.
More confusing in, Intel docs for x550 explicitly state 2.5 5 bits are set disabled in nvm, so by default those are out, so you must turn them on.
I would recommend using "phy.autoneg_advertised" tunable for best opportunity to get good 2.5 link. Or, set it to a non-zero and then also use the dev per nic setting. I wonder if phy setting overrides dev setting or vice-versa when they don't match?
But perhaps a catch-22. If the phy setting is set to 22, that part of ix code won't match the 'if' statement (so it does nothing), but where then does the ix driver code enable that 22 on the nics, because according to Intel docs for x550, the nvm has by default 2.5 and 5 autoneg capable bits set to disable. So now need to look into other parts of the driver code to see how the driver will set the bits to 'enable' when dev or phy sysctl setting is set to non-zero.
[b]if (hw->mac.type == ixgbe_mac_X550 &&
hw->phy.autoneg_advertised == 0)[/b] {
/*
* 2.5G and 5G autonegotiation speeds on X550
* are disabled by default due to reported
* interoperability issues with some switches.
*
* The second condition checks if any operations
* involving setting autonegotiation speeds have
* been performed prior to this ixgbe_config_link()
* call.
*
* If hw->phy.autoneg_advertised does not
* equal 0, this means that the user might have
* set autonegotiation speeds via the sysctl
* before bringing the interface up. In this
* case, we should not disable 2.5G and 5G
* since that speeds might be selected by the
* user.
*
* Otherwise (i.e. if hw->phy.autoneg_advertised
* is set to 0), it is the first time we set
* autonegotiation preferences and the default
* set of speeds should exclude 2.5G and 5G.
*/
autoneg &= ~(IXGBE_LINK_SPEED_2_5GB_FULL |
IXGBE_LINK_SPEED_5GB_FULL);
OK so below is the output from the grep command. What I noticed is the FW and NVM code needs to be updated. I thought I had updated the FW code but maybe it didnt apply. So that is the first place I am going to start working on. The switch is a ReadHD 2.5 gig switch with PoE. I have other devices running at 2.5 gig with no issue. The ethernet cables are Cat6 cables that were purchased about 6-12 months ago. I do not think they said anything about being 802.3bz compliant. I am not sure most cables tell you that.
So my course of action is as follows:
1) Update card with latest firmware and NVM code
2) Test other tunable options mentioned above
3) Dive into X550 code and Intel docs
Am I missing anything?
Steve
[1] acpi0: Power Button (fixed)
[1] ix0: <Intel(R) X550-T2> mem 0xb0400000-0xb07fffff,0xb0804000-0xb0807fff irq 17 at device 0.0 on pci1
[1] ix0: Using 2048 TX descriptors and 2048 RX descriptors
[1] ix0: Using 6 RX queues 6 TX queues
[1] ix0: Using MSI-X interrupts with 7 vectors
[1] ix0: allocated for 6 queues
[1] ix0: allocated for 6 rx queues
[1] ix0: Ethernet address: a0:36:9f:29:94:1c
[1] ix0: PCI Express Bus: Speed 8.0GT/s Width x4
[1] ix0: fw 2.11.11 nvm 1.86.0 Option ROM V1-b3863-p0 eTrack 0x80000c67
[1] ix0: netmap queues/slots: TX 6/2048, RX 6/2048
[1] ix1: <Intel(R) X550-T2> mem 0xb0000000-0xb03fffff,0xb0800000-0xb0803fff irq 16 at device 0.1 on pci1
[1] ix1: Using 2048 TX descriptors and 2048 RX descriptors
[1] ix1: Using 6 RX queues 6 TX queues
[1] ix1: Using MSI-X interrupts with 7 vectors
[1] ix1: allocated for 6 queues
[1] ix1: allocated for 6 rx queues
[1] ix1: Ethernet address: a0:36:9f:29:94:1e
[1] ix1: PCI Express Bus: Speed 8.0GT/s Width x4
[1] ix1: fw 2.11.11 nvm 1.86.0 Option ROM V1-b3863-p0 eTrack 0x80000c67
[1] ix1: netmap queues/slots: TX 6/2048, RX 6/2048
Quote from: spetrillo on September 19, 2025, 02:02:26 AMAm I missing anything?
dmesg cli command.
If you follow the directions for nvm update in the i226 thread, you'll get a log file that tells you what the update utility did.
What is the firmware you speak of?
This is what I updated, and what it looks like I did is update the boot agent: Intel(R) Boot Agent XE (X550) v2.4.59
So I did not do the firmware correct? I have to be honest I am very confused at this point. I have the Intel 30.4 update downloaded and unzipped. I thought this was the firmware but now I am not soo sure.
I ran the dmesg command...that is the output I posted in my last update. Is this not what you want to see? The rest of the output was about my vlans. I didnt think that was necessary to post but please tell me. You mention the I226 thread. Would you have a link for it? Is there a good doc for doing the update via UEFI? It seems that is the best way to do these updates?
So I just noticed that there is now a 30.4.2 update package. I am downloading that now and going to look into that for an update. Its highlighted in bold that it supports for FreeBSD 13.5 and FreeBSD 14.3 OSes. I wonder if that might help my situation.
Quote from: spetrillo on September 19, 2025, 03:43:44 AMI did is update the boot agent: Intel(R) Boot Agent XE (X550) v2.4.59
So I did not do the firmware correct? I have to be honest I am very confused at this point. I have the Intel 30.4 update downloaded and unzipped. I thought this was the firmware but now I am not soo sure.
That's the boot agent that allows a nic to boot from nic port.
Just follow the directions in the Intel 34.0 bundle download.
Extract out the FreeBSD tar file from the Intel zip, get it to your system, untar it, run the nvm util.
X550_NVMUpdatePackage_v3_70_FreeBSD.tar
QuoteUpdating Your NVM Using Interactive Mode
========================================
1. Extract the update package into a temporary folder.
2. Start the Intel Ethernet NVM Update Tool by running the executable.
For example, on an x64 Microsoft* Windows* system, type:
nvmupdatew64e
On an x64 Linux* system, type:
nvmupdate64e
3. Follow the prompts to update the NVM image on the desired device.
Quote from: spetrillo on September 19, 2025, 03:43:44 AMI ran the dmesg command...that is the output I posted in my last update. Is this not what you want to see? The rest of the output was about my vlans. I didnt think that was necessary to post but please tell me. You mention the I226 thread. Would you have a link for it? Is there a good doc for doing the update via UEFI? It seems that is the best way to do these updates?
So I just noticed that there is now a 30.4.2 update package. I am downloading that now and going to look into that for an update. Its highlighted in bold that it supports for FreeBSD 13.5 and FreeBSD 14.3 OSes. I wonder if that might help my situation.
Download 30.4.2 and see if the bins for x550 are any newer. And yep, best to have latest driver on latest nvm.
Your dmesg has no eeprom listed, weird.
Run pciconf -l -bv to see what device ID is being reported.
You have device with nvm etid 80000c67
The nvm util with cfg will replace your nvm with
Quote;**************************************************************************
; Retail_SagePond_B0_AT2_noMNG_H86377 ***********************************
;**************************************************************************
BEGIN DEVICE
DEVICENAME: SAGEVILLE_EXT
VENDOR: 8086
DEVICE: 1563
NVM IMAGE: Retail_SagePond_B0_AT2_noMNG_H86377_3p70.bin
SKIP OROM: FALSE
EEPID: 80001860
EEPROM MAP: dSGVL_0.txt
REPLACES: 80000492 80000C67 80000D43 80000CD8 80000C4D 80000F53 8000105A 80001141 80001184 800011FE 8000134E 80001377 8000156E 800016E0 80001731
RESET TYPE: POWER
END DEVICE
Where are you seeing 30.4.2?
I only see 30.4.1, and 30.4 and 30.3 have been yanked. Odd.
Edit: I was looking at the release notes area on Intel, no 30.4.2 there. That's Intel for you, docs and stuff not well sync'd.
But actual bundle download area has 30.4.2
(https://www.intel.com/content/www/us/en/download/15084/intel-ethernet-adapter-complete-driver-pack.html)
(https://i.postimg.cc/MGwSvY06/Screenshot-2025-09-18-191002.png)
Sadly, nothing new for your x550. I did not look at the other update files that apply to other x550's. I will get hashes for the rest.
QuoteAlgorithm Hash Path
--------- ---- ----
MD5 6FB99C7C91663CB4C53BBD1A42A766AE \x550\dSGVL_0.txt.30.4.2
MD5 6FB99C7C91663CB4C53BBD1A42A766AE \x550\dSGVL_0.txt.30.4
MD5 13F37D1B5B259C7B5C26B7A018C02D76 \x550\Retail_SagePond_B0_AT2_noMNG_H86377_3p70.bin.30.4
MD5 13F37D1B5B259C7B5C26B7A018C02D76 \x550\Retail_SagePond_B0_AT2_noMNG_H86377_3p70.bin.30.4.2
Sadly, not a single update for any x550 from 30.4 to 30.4.2
I did the gz's, that tells us the story, but also did all the individual files.
It's just a rebundle for x550, notice both say "v3_70".
There's probably something else in the 30.4.2 bundle that's different. I try and find it.
QuoteAlgorithm Hash Path
--------- ---- ----
MD5 9F13981E915BBB488909EE6E2E7DAC38 \x550\X550_NVMUpdatePackage_v3_70_FreeBSD.tar.gz.30.4
MD5 9F13981E915BBB488909EE6E2E7DAC38 \x550\X550_NVMUpdatePackage_v3_70_FreeBSD.tar.gz.30.4.2
MD5 F332ED2D04CE151509A01C7D709BB5AD \x550\X550_NVMUpdatePackage_v3_70_EFI.zip.30.4
MD5 F332ED2D04CE151509A01C7D709BB5AD \x550\X550_NVMUpdatePackage_v3_70_EFI.zip.30.4.2
MD5 5411C17F56944394AD1A6FC4F81B41C9 \x550\X550_NVMUpdatePackage_v3_70_ESX.tar.gz.30.4
MD5 5411C17F56944394AD1A6FC4F81B41C9 \x550\X550_NVMUpdatePackage_v3_70_ESX.tar.gz.30.4.2
MD5 0CC7A242AF46527AA2341D11D8ABFFDE \x550\X550_NVMUpdatePackage_v3_70_Linux.tar.gz.30.4
MD5 0CC7A242AF46527AA2341D11D8ABFFDE \x550\X550_NVMUpdatePackage_v3_70_Linux.tar.gz.30.4.2
MD5 34C312BC207D184516460458A58FD5FC \x550\X550_NVMUpdatePackage_v3_70_Windows.zip.30.4
MD5 34C312BC207D184516460458A58FD5FC \x550\X550_NVMUpdatePackage_v3_70_Windows.zip.30.4.2
Algorithm Hash Path
--------- ---- ----
MD5 6FB99C7C91663CB4C53BBD1A42A766AE \x550\dSGVL_0.txt.30.4
MD5 6FB99C7C91663CB4C53BBD1A42A766AE \x550\dSGVL_0.txt.30.4.2
MD5 AB3DA920FC6AF9FDF9EC617F0E902F19 \x550\dSGVL_1.txt.30.4
MD5 AB3DA920FC6AF9FDF9EC617F0E902F19 \x550\dSGVL_1.txt.30.4.2
MD5 6D380B2342F28BBCBACCC694F1ABB811 \x550\dSGVL_B0_AT2_MCTP_3p70.bin.30.4
MD5 6D380B2342F28BBCBACCC694F1ABB811 \x550\dSGVL_B0_AT2_MCTP_3p70.bin.30.4.2
MD5 4AAB88AC3F5B424A3D793D4318381B4E \x550\dSGVL_B0_AT2_NCSI_3p70.bin.30.4
MD5 4AAB88AC3F5B424A3D793D4318381B4E \x550\dSGVL_B0_AT2_NCSI_3p70.bin.30.4.2
MD5 02F16CCB674D078D904B359367939F89 \x550\dSGVL_B0_AT2_noMNG_3p70.bin.30.4
MD5 02F16CCB674D078D904B359367939F89 \x550\dSGVL_B0_AT2_noMNG_3p70.bin.30.4.2
MD5 8541437B110A7A98DC900B465EB97CB0 \x550\dSGVL_B0_AT2_SMB_3p70.bin.30.4
MD5 8541437B110A7A98DC900B465EB97CB0 \x550\dSGVL_B0_AT2_SMB_3p70.bin.30.4.2
MD5 D2FECA1A44D3DB5C50973FD3F8D67A37 \x550\dSGVL_B0_AT_SP_MCTP_3p70.bin.30.4
MD5 D2FECA1A44D3DB5C50973FD3F8D67A37 \x550\dSGVL_B0_AT_SP_MCTP_3p70.bin.30.4.2
MD5 CC1BADB271FC08DB1E80D13140609B59 \x550\dSGVL_B0_AT_SP_NCSI_3p70.bin.30.4
MD5 CC1BADB271FC08DB1E80D13140609B59 \x550\dSGVL_B0_AT_SP_NCSI_3p70.bin.34.0.2
MD5 6EC453426AC200339ABA7D3136FCE58F \x550\dSGVL_B0_AT_SP_noMNG_3p70.bin.30.4
MD5 6EC453426AC200339ABA7D3136FCE58F \x550\dSGVL_B0_AT_SP_noMNG_3p70.bin.30.4.2
MD5 6C5513375AC77C549F055E53FD7A47D4 \x550\dSGVL_B0_AT_SP_SMB_3p70.bin.30.4
MD5 6C5513375AC77C549F055E53FD7A47D4 \x550\dSGVL_B0_AT_SP_SMB_3p70.bin.30.4.2
MD5 08ACED106BC6F31EBB3AD54124938302 \x550\dSGVL_B0_BT2_MCTP_3p70.bin.30.4
MD5 08ACED106BC6F31EBB3AD54124938302 \x550\dSGVL_B0_BT2_MCTP_3p70.bin.30.4.2
MD5 272E7C738691B9CC319A15BC0FEF33EB \x550\dSGVL_B0_BT2_NCSI_3p70.bin.30.4
MD5 272E7C738691B9CC319A15BC0FEF33EB \x550\dSGVL_B0_BT2_NCSI_3p70.bin.30.4.2
MD5 5CD7090EC5DDD1CC267E9762D3DC1F90 \x550\dSGVL_B0_BT2_noMNG_3p70.bin.30.4
MD5 5CD7090EC5DDD1CC267E9762D3DC1F90 \x550\dSGVL_B0_BT2_noMNG_3p70.bin.30.4.2
MD5 4FE19F50B2FD0800C5B040F5A757F1F2 \x550\dSGVL_B0_BT2_SMB_3p70.bin.30.4
MD5 4FE19F50B2FD0800C5B040F5A757F1F2 \x550\dSGVL_B0_BT2_SMB_3p70.bin.30.4.2
MD5 52939860AF7A78E513340ABC3F86DBC3 \x550\nvmupdate.cfg.30.4
MD5 52939860AF7A78E513340ABC3F86DBC3 \x550\nvmupdate.cfg.30.4.2
MD5 0FFE7760E396D37924FA759A7EBDD103 \x550\OEMG_sagePond_B0_AT2_MCTP_H49289_3p70.bin.30.4
MD5 0FFE7760E396D37924FA759A7EBDD103 \x550\OEMG_sagePond_B0_AT2_MCTP_H49289_3p70.bin.30.4.2
MD5 0B6AFAF011532D99FC8707BFA5737DF8 \x550\OEMG_sagePond_B0_AT_MCTP_H89173_3p70.bin.30.4
MD5 0B6AFAF011532D99FC8707BFA5737DF8 \x550\OEMG_sagePond_B0_AT_MCTP_H89173_3p70.bin.30.4.2
MD5 13F37D1B5B259C7B5C26B7A018C02D76 \x550\Retail_SagePond_B0_AT2_noMNG_H86377_3p70.bin.30.4
MD5 13F37D1B5B259C7B5C26B7A018C02D76 \x550\Retail_SagePond_B0_AT2_noMNG_H86377_3p70.bin.30.4.2
MD5 C5B89642E5A6888DA12091820BE58AE5 \x550\Retail_SagePond_B0_AT_SP_noMNG_H92506_3p70.bin.30.4
MD5 C5B89642E5A6888DA12091820BE58AE5 \x550\Retail_SagePond_B0_AT_SP_noMNG_H92506_3p70.bin.30.4.2
I can't find any gz or zip in NVM area where MD5's are different !
30.4 vs 30.4.2 NVM files.
Names(path) appear the same because I had to do some sorting, but no diffs at all.
Whatever is "new", it's not in NVM.
QuoteA1075DB93C862F1D2EECA95B9E6B7E7F \700_Series\700Series_NVMUpdatePackage_v9_55_EFI.zip
A1075DB93C862F1D2EECA95B9E6B7E7F \700_Series\700Series_NVMUpdatePackage_v9_55_EFI.zip
126FCC960E7100CF58ECEC415D6528A7 \700_Series\700Series_NVMUpdatePackage_v9_55_ESX.tar.gz
126FCC960E7100CF58ECEC415D6528A7 \700_Series\700Series_NVMUpdatePackage_v9_55_ESX.tar.gz
0A99DD23D3B021CC63DFB57AE9408D54 \700_Series\700Series_NVMUpdatePackage_v9_55_FreeBSD.tar.gz
0A99DD23D3B021CC63DFB57AE9408D54 \700_Series\700Series_NVMUpdatePackage_v9_55_FreeBSD.tar.gz
993D7092F54825BC42CA9DC38007E2E4 \700_Series\700Series_NVMUpdatePackage_v9_55_Linux.tar.gz
993D7092F54825BC42CA9DC38007E2E4 \700_Series\700Series_NVMUpdatePackage_v9_55_Linux.tar.gz
5B4B063017ACA946304896923C79434F \700_Series\700Series_NVMUpdatePackage_v9_55_Windows.zip
5B4B063017ACA946304896923C79434F \700_Series\700Series_NVMUpdatePackage_v9_55_Windows.zip
33D567BF8E13B48A282318BAABC38792 \E610\E610_NVMUpdatePackage_v1_30_EFI.zip
33D567BF8E13B48A282318BAABC38792 \E610\E610_NVMUpdatePackage_v1_30_EFI.zip
5C34DD2877B97108382DC4D1F9D4C44D \E610\E610_NVMUpdatePackage_v1_30_ESX.tar.gz
5C34DD2877B97108382DC4D1F9D4C44D \E610\E610_NVMUpdatePackage_v1_30_ESX.tar.gz
AE271787DF8A0C547AECD360C02BE358 \E610\E610_NVMUpdatePackage_v1_30_FreeBSD.tar.gz
AE271787DF8A0C547AECD360C02BE358 \E610\E610_NVMUpdatePackage_v1_30_FreeBSD.tar.gz
6C194865B093F68332A04FE286FF25C4 \E610\E610_NVMUpdatePackage_v1_30_Linux.tar.gz
6C194865B093F68332A04FE286FF25C4 \E610\E610_NVMUpdatePackage_v1_30_Linux.tar.gz
195984E161159E0DF4A374913ACE9598 \E610\E610_NVMUpdatePackage_v1_30_Windows.zip
195984E161159E0DF4A374913ACE9598 \E610\E610_NVMUpdatePackage_v1_30_Windows.zip
100F01F6A4AEAE5EDC18AFB59301BB08 \E810\E810_NVMUpdatePackage_v4_90_EFI.zip
100F01F6A4AEAE5EDC18AFB59301BB08 \E810\E810_NVMUpdatePackage_v4_90_EFI.zip
171DFDD0A18B172BB34553DDF1BB4DF5 \E810\E810_NVMUpdatePackage_v4_90_ESX.tar.gz
171DFDD0A18B172BB34553DDF1BB4DF5 \E810\E810_NVMUpdatePackage_v4_90_ESX.tar.gz
69BD5070729B853F73DF26471826324B \E810\E810_NVMUpdatePackage_v4_90_FreeBSD.tar.gz
69BD5070729B853F73DF26471826324B \E810\E810_NVMUpdatePackage_v4_90_FreeBSD.tar.gz
DA6DAE1713B1C20D31788406557DA61C \E810\E810_NVMUpdatePackage_v4_90_Linux.tar.gz
DA6DAE1713B1C20D31788406557DA61C \E810\E810_NVMUpdatePackage_v4_90_Linux.tar.gz
7761A7F330E3D15998012593A821FDC4 \E810\E810_NVMUpdatePackage_v4_90_Windows.zip
7761A7F330E3D15998012593A821FDC4 \E810\E810_NVMUpdatePackage_v4_90_Windows.zip
A1CD250DE921643A6953A87B55B91A8B \E810\E810_NVMUpdatePackageAArch64_v4_90_EFI.zip
A1CD250DE921643A6953A87B55B91A8B \E810\E810_NVMUpdatePackageAArch64_v4_90_EFI.zip
2EB32B1472B5C227CDF1D270DAFF9049 \E810\E810_NVMUpdatePackageAArch64_v4_90_Linux.tar.gz
2EB32B1472B5C227CDF1D270DAFF9049 \E810\E810_NVMUpdatePackageAArch64_v4_90_Linux.tar.gz
F74A03325EC6C492E9421D96742D53EB \E830\E830_NVMUpdatePackage_v1_10_EFI.zip
F74A03325EC6C492E9421D96742D53EB \E830\E830_NVMUpdatePackage_v1_10_EFI.zip
C17D43FAB768746D7A0AB8DA8150E3DC \E830\E830_NVMUpdatePackage_v1_10_ESX.tar.gz
C17D43FAB768746D7A0AB8DA8150E3DC \E830\E830_NVMUpdatePackage_v1_10_ESX.tar.gz
147D9F687EF7D6AB9C522C842CBF27E3 \E830\E830_NVMUpdatePackage_v1_10_FreeBSD.tar.gz
147D9F687EF7D6AB9C522C842CBF27E3 \E830\E830_NVMUpdatePackage_v1_10_FreeBSD.tar.gz
634BDDC7734C4DAF39AE72B505E0E57C \E830\E830_NVMUpdatePackage_v1_10_Linux.tar.gz
634BDDC7734C4DAF39AE72B505E0E57C \E830\E830_NVMUpdatePackage_v1_10_Linux.tar.gz
ADE4825FCED4CAA13B2E1FDCA19C11D2 \E830\E830_NVMUpdatePackage_v1_10_Windows.zip
ADE4825FCED4CAA13B2E1FDCA19C11D2 \E830\E830_NVMUpdatePackage_v1_10_Windows.zip
CAA820D9F9043573E9AD667BFC31329B \I210\I210_NVMUpdatePackage_v2_00_EFI.zip
CAA820D9F9043573E9AD667BFC31329B \I210\I210_NVMUpdatePackage_v2_00_EFI.zip
BF3CC271E9183B75078195A1F92044B6 \I210\I210_NVMUpdatePackage_v2_00_ESX.tar.gz
BF3CC271E9183B75078195A1F92044B6 \I210\I210_NVMUpdatePackage_v2_00_ESX.tar.gz
2750BF0C0C6A178702EA2D912F6E7A6E \I210\I210_NVMUpdatePackage_v2_00_FreeBSD.tar.gz
2750BF0C0C6A178702EA2D912F6E7A6E \I210\I210_NVMUpdatePackage_v2_00_FreeBSD.tar.gz
9F906DBBA3B7E2778B9CA3C39E7F9CC0 \I210\I210_NVMUpdatePackage_v2_00_Linux.tar.gz
9F906DBBA3B7E2778B9CA3C39E7F9CC0 \I210\I210_NVMUpdatePackage_v2_00_Linux.tar.gz
4428AEC1E36EBACF08970E06BC530717 \I210\I210_NVMUpdatePackage_v2_00_Windows.zip
4428AEC1E36EBACF08970E06BC530717 \I210\I210_NVMUpdatePackage_v2_00_Windows.zip
4E1915F351946160E7EED81BDA598821 \I225\I225_NVMUpdatePackage_v1_00_EFI.zip
4E1915F351946160E7EED81BDA598821 \I225\I225_NVMUpdatePackage_v1_00_EFI.zip
3967DA51676565782D56A82CD31DE9D6 \I225\I225_NVMUpdatePackage_v1_00_Linux.tar.gz
3967DA51676565782D56A82CD31DE9D6 \I225\I225_NVMUpdatePackage_v1_00_Linux.tar.gz
9487EDE06314CB43963EBA7DD8EFE669 \I225\I225_NVMUpdatePackage_v1_00_Windows.zip
9487EDE06314CB43963EBA7DD8EFE669 \I225\I225_NVMUpdatePackage_v1_00_Windows.zip
F332ED2D04CE151509A01C7D709BB5AD \X550\X550_NVMUpdatePackage_v3_70_EFI.zip
F332ED2D04CE151509A01C7D709BB5AD \X550\X550_NVMUpdatePackage_v3_70_EFI.zip
5411C17F56944394AD1A6FC4F81B41C9 \X550\X550_NVMUpdatePackage_v3_70_ESX.tar.gz
5411C17F56944394AD1A6FC4F81B41C9 \X550\X550_NVMUpdatePackage_v3_70_ESX.tar.gz
9F13981E915BBB488909EE6E2E7DAC38 \X550\X550_NVMUpdatePackage_v3_70_FreeBSD.tar.gz
9F13981E915BBB488909EE6E2E7DAC38 \X550\X550_NVMUpdatePackage_v3_70_FreeBSD.tar.gz
0CC7A242AF46527AA2341D11D8ABFFDE \X550\X550_NVMUpdatePackage_v3_70_Linux.tar.gz
0CC7A242AF46527AA2341D11D8ABFFDE \X550\X550_NVMUpdatePackage_v3_70_Linux.tar.gz
34C312BC207D184516460458A58FD5FC \X550\X550_NVMUpdatePackage_v3_70_Windows.zip
34C312BC207D184516460458A58FD5FC \X550\X550_NVMUpdatePackage_v3_70_Windows.zip
First off I very much appreciate everyone's input to this. I really wish Intel would make it more straight forward but so be it. I do have one question and that is about the NVM update. Is that the only update I need to do to this card? We have talked about firmware and NVM almost interchangeably and I want to make sure I do whatever updates need to be done. I see the NVM update directory in the 30.4.2 update. I can follow that bouncing ball but is there another update for firmware or am I done at that point? Second what does the boot agent do for me and what options do most people pick when doing that kind of update on these cards?
Quote from: spetrillo on September 19, 2025, 04:00:12 PMFirst off I very much appreciate everyone's input to this. I really wish Intel would make it more straight forward but so be it. I do have one question and that is about the NVM update. Is that the only update I need to do to this card? We have talked about firmware and NVM almost interchangeably and I want to make sure I do whatever updates need to be done. I see the NVM update directory in the 30.4.2 update. I can follow that bouncing ball but is there another update for firmware or am I done at that point? Second what does the boot agent do for me and what options do most people pick when doing that kind of update on these cards?
Yep, for nvm just follow the directions, see post #38.
OR
You can curl -O the bundle download link from the fw device.
ssh into the box, shell "8"
unzip *.zip
cd ./Release_30.4.2.zip/NVMUpdatePackage/X550/
tar -xzf X550_NVMUpdatePackage_v3_70_FreeBSD.tar.gz
cd X550_NVMUpdatePackage_v3_70_FreeBSD/X550/FreeBSDx64/
chmod +x nvmupdate64e
./nvmupdate64e
***********************
Boot agent is the code that allows the system to boot from a boot image that is located somewhere outside your device.
Just info:
That newer 30.4.2 download bundle only has 3 new files (names, 1 dir 2 files) for ESX9. Note I said names.
I checking to see if files of same names have different MD5. The only file that has same name but different MD5 was "epct.txt" in the APPS folder. Everything else (of same name) was same MD5.
Quote$folder1 = "C:\Users\WildRice\Downloads\30.4"
$folder2 = "C:\Users\WildRice\Downloads\30.4.2"
$folder1Items = Get-ChildItem -Path $folder1 -Recurse
$folder2Items = Get-ChildItem -Path $folder2 -Recurse
Compare-Object -ReferenceObject $folder1Items -DifferenceObject $folder2Items -Property Name
located in 30.4.2 bundle zip \APPS\intnetcli\
Compare-Object -ReferenceObject $folder1Items -DifferenceObject $folder2Items -Property Name
Name SideIndicator
---- -------------
ESXi9.0 =>
Intel-esx-intnetcli_9.0-1.16.1.0-package.zip =>
intnetcli-esx90-readme.txt =>
Ok, more good discovery.
I just found.
Besides the nvmupdate util, there's an "app" called EPCT (ethernet port configuration tool).
In the Intel download bundle look in "\APPS\EPCT\" folder, read the epct.txt
Check out the "Detailed Usage Examples" section !
Ok so I finally got the NVM updated. We are now running 3.70, which matches the package. I installed Ubuntu 24.04.3, so I could work on a platform I know. I am not a FreeBSD guy, even though there are similarities. I just wanted to be on an OS I knew. I saw your update about EPCT. I followed the bouncing ball but the wierd part is the EPCT64e command comes back with no supported adapters found. Not sure why this happening but going to investigate a bit more.
Vendor ID is 8086 and Device ID is 1563, so we now confirm this is an Intel X5520-T2.
More to come...
Quote from: spetrillo on September 20, 2025, 08:22:52 PM[...]
the EPCT64e command comes back with no supported adapters found.[...]
It looks to me like a specialist utility for defining... er, port divisions for QSFP-based optical Ethernet adapters (40, 100, 200Gb - those that use a 4b interface). Useful if you wish to subdivide a point-to-point link or break out an interface into multiple connections. Examples: QSFP-to-SFP breakout DACs/AOCs (40 to 4x10, 100 to 4x25, 200 to 4x50) or QSFP-to-SFP adapters (where speed is determined by the installed SFP).
The Intel adapters seem to be pretty flexible. Chelsio T5 and T6 QSFP adapters, for instance, may only be subdivided in very particular ways ("Spider and QSA Modes" (https://service.chelsio.com/store2/T5/Unified%20Wire/Linux/ChelsioUwire-3.19.0.3/Chelsio-UnifiedWire-Linux-UserGuide.pdf)). I have no experience with Mellanox/nVidia or Broadcom. Caveat emptor.
There may be more to it. I'd have to try it on an x710 or e810.
Which nics are supported with EPCT tool? I am not 100% on that, but Intel page has more ink to read.
https://www.intel.com/content/www/us/en/download/19435/ethernet-port-configuration-tool-all-supported-oss.html
QuoteOverview
========
The Ethernet Port Configuration Tool (EPCT) is a command line utility
that allows users to change the link type of a device. The supported
types are defined within the adapter's NVM. This utility displays only
the devices that potentially support reconfiguration.
Quote from: spetrillo on September 20, 2025, 08:22:52 PMVendor ID is 8086 and Device ID is 1563, so we now confirm this is an Intel X5520-T2.
Note sure which OS you are looking from, but ix in freeBSD 14.3 says the 1563 is just a T model. They list 550T's as these two. I cannot find anything "T2" in driver files. I am not sure it matters because they go by the matching device ID, but we usually see model names in user gui's, so it can sometimes get confusing as to what actual model nic it is when we only look at names. I will assume "X550T" was really meant to say "X550T2".
Quote#define IXGBE_DEV_ID_X550T 0x1563
#define IXGBE_DEV_ID_X550T1 0x15D1
Quote from: BrandyWine on September 21, 2025, 02:07:02 AMQuote from: spetrillo on September 20, 2025, 08:22:52 PMVendor ID is 8086 and Device ID is 1563, so we now confirm this is an Intel X5520-T2.
Note sure which OS you are looking from, but ix in freeBSD 14.3 says the 1563 is just a T model. They list 550T's as these two. I cannot find anything "T2" in driver files. I am not sure it matters because they go by the matching device ID, but we usually see model names in user gui's, so it can sometimes get confusing as to what actual model nic it is when we only look at names. I will assume "X550T" was really meant to say "X550T2".
Quote#define IXGBE_DEV_ID_X550T 0x1563
#define IXGBE_DEV_ID_X550T1 0x15D1
Yes I guess it can be confusing. I was still on Ubuntu desktop when I checked for the vendor and device id. Now at least I know I can move forward without worrying about EPCT.
Will I need to worry about driver updates in FreeBSD?
More info - I used the ethtool command to set the speed at 2500 for both ports and they connected at 2500! This is a good step forward. I am going to do a new install of OPNsense tomorrow and see what happens with both ports. Is there a similar tool in FreeBSD?
Ok so I installed OPNsense and booted things up to the console. I set both ports 0 and 1 as follows: sysctl dev.ix.0.advertise_speed=23 and sysctl dev.ix.1.advertise_speed=23. Both ports are now showing as 2500 on my switch, whereas port 0 would show 2500 and port 1 would show 100. That is a very good step forward.
Going to let this sit for a bit and see what happens. Maybe the NVM update was all I needed? How do ppl feel about a driver update in FreeBSD? I would think that is a bit more complicated and I am not sure I want to take that on.
So some interesting driver info for FreeBSD. If I look at the Intel website it tells me the latest FreeBSD driver version is 3.4.31, however when I run sysctl -a | grep dev.ix.0.iflib.drive_version it tells me I am running 4.0.1-k on my OPNsense server. Not sure where this driver came from bc the Intel 30.4.2 pkg only shows the 3.4.31 version.
I would like to up the MTU on the two X550 ports to 9000. I can use the ifconfig but does this persist through reboots? If not do I just add this as another tunable?
I assume Interfaces > <interface name> > MTU will work as intended, doesn't it?
Hmmm I use vlans, so my interfaces are the actual vlans.
Maybe I have to make the change at the hardware level using ifconfig and then edit the MTU on each interface/vlan also?
I gotta say this X550 is toasty...I think I could put grill marks on a hot dog laying on the heat sink!
Quote from: spetrillo on September 21, 2025, 04:43:37 PMSo some interesting driver info for FreeBSD. If I look at the Intel website it tells me the latest FreeBSD driver version is 3.4.31, however when I run sysctl -a | grep dev.ix.0.iflib.driver_version it tells me I am running 4.0.1-k on my OPNsense server. Not sure where this driver came from bc the Intel 30.4.2 pkg only shows the 3.4.31 version.
Will I need to worry about driver updates in FreeBSD?
You have a if_ix.ko or if_ix_updated.ko on your system?
modinfo ixgbe
Driver updates, worry? Maybe not worry, but updates/patches do appear to be recent.
Quote from: spetrillo on September 22, 2025, 01:29:54 AM[...]
I gotta say this X550 is toasty...I think I could put grill marks on a hot dog laying on the heat sink!
Yeah, I have a 10GTek X550-T1 which has a larger-than-Intel heat sink, which is nice. I have a Lenovo X550-T2 with the Intel heat sink form factor/mount which I would prefer to use, but my firewall has limited vertical space in the last slot and modifying a heat sink to fit isn't worth the effort. I do have a standard Alpha 50x50x25 heat sink (https://www.alphanovatech.com/en/c_fsp50e.html) which screws right on, so that's what it's getting, and it will go in a different machine. (The FSP is not designed for passive use, but I used a similar Alpha 60x60x25 sink on an 18W Coppermine years ago and it worked fine.)
The X710 isn't so bad (28nm vs. 40), but I'd still want a heat sink upgrade. Is anyone brave enough to try the E610? 2.5W/port, and apparently uses the ix driver.
Quote from: spetrillo on September 21, 2025, 03:06:36 PMMaybe the NVM update was all I needed?
The x550 appears to be some Intel product that they rushed to market, noting support for only 10 GbE/1 GbE/100 Mb/s.
In some early "Product Brief" Intel docs they list NBASE-T 2.5 and 5 with footnote, which read "to be supported in future release of firmware".
A lot of the x550 docs do mention 2.5 5 is disabled in nvm, but I believe this to mean the enable/disable bit is set to disable by default (in the nvm).
It could also just be the early versions of x550 drivers had no code to enable 2.5 5G. Hard to know exactly when/how Intel nvm had code to run 2.5 5G, and when drivers were able to use it.
I believe even the latest nvm has 2.5 5G disabled by default, and you then enable them using sysctl or other method.
As I have mentioned a few times, and it's hinted in Intel readme's and such, using latest "base" driver with latest nvm is best way. I have seen where some people downgrade a newer driver due to some odd issue, but that's usually because they did not install a latest nvm.
Quote from: BrandyWine on September 22, 2025, 04:57:38 AMQuote from: spetrillo on September 21, 2025, 04:43:37 PMSo some interesting driver info for FreeBSD. If I look at the Intel website it tells me the latest FreeBSD driver version is 3.4.31, however when I run sysctl -a | grep dev.ix.0.iflib.driver_version it tells me I am running 4.0.1-k on my OPNsense server. Not sure where this driver came from bc the Intel 30.4.2 pkg only shows the 3.4.31 version.
Will I need to worry about driver updates in FreeBSD?
You have a if_ix.ko or if_ix_updated.ko on your system?
modinfo ixgbe
Driver updates, worry? Maybe not worry, but updates/patches do appear to be recent.
I just did a standard OPNsense install. Its just running 25.7. I ran sysctl -a | grep dev.ix.0.iflib.driver_version. It shows the version as 4.0.1-k. I thought this was the driver version for ix.
Quote from: pfry on September 22, 2025, 07:28:37 AMQuote from: spetrillo on September 22, 2025, 01:29:54 AM[...]
I gotta say this X550 is toasty...I think I could put grill marks on a hot dog laying on the heat sink!
Yeah, I have a 10GTek X550-T1 which has a larger-than-Intel heat sink, which is nice. I have a Lenovo X550-T2 with the Intel heat sink form factor/mount which I would prefer to use, but my firewall has limited vertical space in the last slot and modifying a heat sink to fit isn't worth the effort. I do have a standard Alpha 50x50x25 heat sink (https://www.alphanovatech.com/en/c_fsp50e.html) which screws right on, so that's what it's getting, and it will go in a different machine. (The FSP is not designed for passive use, but I used a similar Alpha 60x60x25 sink on an 18W Coppermine years ago and it worked fine.)
The X710 isn't so bad (28nm vs. 40), but I'd still want a heat sink upgrade. Is anyone brave enough to try the E610? 2.5W/port, and apparently uses the ix driver.
I am looking to purchase an E610 but I do not believe it will fit in my Lenovo M720q Tiny. I am constrained by space.
Quote from: BrandyWine on September 22, 2025, 06:45:13 PMQuote from: spetrillo on September 21, 2025, 03:06:36 PMMaybe the NVM update was all I needed?
The x550 appears to be some Intel product that they rushed to market, noting support for only 10 GbE/1 GbE/100 Mb/s.
In some early "Product Brief" Intel docs they list NBASE-T 2.5 and 5 with footnote, which read "to be supported in future release of firmware".
A lot of the x550 docs do mention 2.5 5 is disabled in nvm, but I believe this to mean the enable/disable bit is set to disable by default (in the nvm).
It could also just be the early versions of x550 drivers had no code to enable 2.5 5G. Hard to know exactly when/how Intel nvm had code to run 2.5 5G, and when drivers were able to use it.
I believe even the latest nvm has 2.5 5G disabled by default, and you then enable them using sysctl or other method.
As I have mentioned a few times, and it's hinted in Intel readme's and such, using latest "base" driver with latest nvm is best way. I have seen where some people downgrade a newer driver due to some odd issue, but that's usually because they did not install a latest nvm.
Definitely agree with that. I would want to run latest OS driver with the latest NVM code.
Quote from: pfry on September 22, 2025, 07:28:37 AMI do have a standard Alpha 50x50x25 heat sink (https://www.alphanovatech.com/en/c_fsp50e.html) which screws right on
This item comes with a fan on/in it? Does the x550 have fan header or you plug that in on mobo?
Quote from: BrandyWine on September 22, 2025, 06:58:32 PMThis item comes with a fan on/in it? Does the x550 have fan header or you plug that in on mobo?
Fans are optional - Sanyo Denki, I believe. I'd probably use Noctua, and just plug into the motherboard. Screws can be a bit tough to find (M3 x heat sink height + fan depth). But for me, I just use it passive, like the factory heat sink... in an actively-cooled enclosure. I tried running an Aquantia AQC-107 (nominally ~7.5W) in a fanless case with a 45x45x25 heat sink, and that did not work well. Anyway, the Alphas ain't cheap, but they have lots of different shapes/sizes/etc. and ship small quantities, at least in the US. Don't take my word on fitment, of course.
Quote from: spetrillo on September 22, 2025, 06:49:55 PMI am looking to purchase an E610 but I do not believe it will fit in my Lenovo M720q Tiny. I am constrained by space.
Both the E610-TX2 and -TX4 look like HHHL cards, same as most these days. PCI-e x4 and x8, respectively. Still too big?
(In the US, Provantage has good prices if you're buying new. Still not cheep.)
Quote from: pfry on September 22, 2025, 11:52:20 PMQuote from: spetrillo on September 22, 2025, 06:49:55 PMI am looking to purchase an E610 but I do not believe it will fit in my Lenovo M720q Tiny. I am constrained by space.
Both the E610-TX2 and -TX4 look like HHHL cards, same as most these days. PCI-e x4 and x8, respectively. Still too big?
(In the US, Provantage has good prices if you're buying new. Still not cheep.)
Provantage has good prices but they have to order them...not in stock!
Has the x550 speed issue been resolved by 1) updating the nvm, and 2) setting the dev.ix sysctl setting to 23?
And yep, my ix (attached to x520's) also shows the driver as v4.0.1-k
Quote from: BrandyWine on September 23, 2025, 04:24:17 AMHas the x550 speed issue been resolved by 1) updating the nvm, and 2) setting the dev.ix sysctl setting to 23?
And yep, my ix (attached to x520's) also shows the driver as v4.0.1-k
Yes I believe those were the key to this working now. I am going to keep an eye on it and also ensure that any NVM updates are applied when they come out.
As a side note I have learned alot about FreeBSD and dont have anxiety about it any longer. I can operate in this world, just like I operate in the Linux world. Sometimes you just got to dive into the deep end of the pool and see if you can swim! I also want to thank those that posted here. You all helped!
Hold the presses....
Connected my device to my original switch and port 1 is back to running at 100M, even though port 1 registers as 23. So now I can eliminate everything except my switch or cables. These are the only changes introduced. Everything else, including config, is the same. I am going to swap out cables first, as that is an easy swap. Going to use the cables I tested with.
Swapped cables and we are now running at 2500M on both ports...yea!
Quote from: spetrillo on September 23, 2025, 05:18:18 PMHold the presses....
Connected my device to my original switch and port 1 is back to running at 100M, even though port 1 registers as 23. So now I can eliminate everything except my switch or cables. These are the only changes introduced. Everything else, including config, is the same. I am going to swap out cables first, as that is an easy swap. Going to use the cables I tested with.
Swapped cables and we are now running at 2500M on both ports...yea!
"23" is not a connected speed, it's just a mask number that tells the device what speeds are ok to advertise for autonegotiate.
Can you verify, your test was using different cables not connected to your switch, you then unplug cables from fw and the re-use some oler cables that were still connected to your switch? That shows the 100M issue, you then replaced those cables with the "newer" cables you used in testing, and then it's good?
Does your switch logs show any info relating to speed downshifting, or do they show a basic negotiating link directly to 100M.
From your description of events, appears to have been a cables issue?
Yes swapping the cables fixed the issue. The switch log shows the connection and negotiation to 100M. Nothing abnormal.
Quote from: spetrillo on September 23, 2025, 08:31:52 PMYes swapping the cables fixed the issue. The switch log shows the connection and negotiation to 100M. Nothing abnormal.
If the switch is fully 802.3bz compliant it could have ran next/fext for alien noise and decided to accept the lower speed. I wonder what the switch would accept of 100M was not available from the x550? If say 2.5G was the only speed allowed in auto-neg would it accept that or not link at all? For me I would be curious and test it, but since your setup is working that's up to you.
Were your bad cables new and labeled as CAT6?
Quote from: spetrillo on September 22, 2025, 06:48:43 PMSo some interesting driver info for FreeBSD. If I look at the Intel website it tells me the latest FreeBSD driver version is 3.4.31, however when I run sysctl -a | grep dev.ix.0.iflib.driver_version it tells me I am running 4.0.1-k on my OPNsense server. Not sure where this driver came from bc the Intel 30.4.2 pkg only shows the 3.4.31 version.
I just did a standard OPNsense install. Its just running 25.7. I ran sysctl -a | grep dev.ix.0.iflib.driver_version. It shows the version as 4.0.1-k. I thought this was the driver version for ix.
Well, the ix ko shows 4.0.1-k
How it's loaded in? It's not in as klm
strings /boot/kernel/if_ix.ko | grep "4.0.1"
kldstat -v |grep ix
it's #146 on my OPNsense.
ix is in the kernel, I suspect the ko is the same code that's in the kernel. Edit: which is the case, v14.3 src code ID's ix driver as 4.0.1-k. Version numbers between freeBSD code and Intel code will be different, because it's different vendors numbering in different ways.
Why have a ko and in the kernel? Well, it is possible to unbind the static ix and then kldload the ko, which gives you flexibility, and ability to load your own compiled ko driver.
Quote from: BrandyWine on September 23, 2025, 09:47:22 PMQuote from: spetrillo on September 23, 2025, 08:31:52 PMYes swapping the cables fixed the issue. The switch log shows the connection and negotiation to 100M. Nothing abnormal.
If the switch is fully 802.3bz compliant it could have ran next/fext for alien noise and decided to accept the lower speed. I wonder what the switch would accept of 100M was not available from the x550? If say 2.5G was the only speed allowed in auto-neg would it accept that or not link at all? For me I would be curious and test it, but since your setup is working that's up to you.
Were your bad cables new and labeled as CAT6?
They were labeled as Cat6 and prolly no more than a year old. I am going to end up swapping out all cables for new ones, when I build my mini rack.
Quote from: BrandyWine on September 24, 2025, 06:39:03 AMQuote from: spetrillo on September 22, 2025, 06:48:43 PMSo some interesting driver info for FreeBSD. If I look at the Intel website it tells me the latest FreeBSD driver version is 3.4.31, however when I run sysctl -a | grep dev.ix.0.iflib.driver_version it tells me I am running 4.0.1-k on my OPNsense server. Not sure where this driver came from bc the Intel 30.4.2 pkg only shows the 3.4.31 version.
I just did a standard OPNsense install. Its just running 25.7. I ran sysctl -a | grep dev.ix.0.iflib.driver_version. It shows the version as 4.0.1-k. I thought this was the driver version for ix.
Well, the ix ko shows 4.0.1-k
How it's loaded in? It's not in as klm
strings /boot/kernel/if_ix.ko | grep "4.0.1"
kldstat -v |grep ix
it's #146 on my OPNsense.
ix is in the kernel, I suspect the ko is the same code that's in the kernel. Edit: which is the case, v14.3 src code ID's ix driver as 4.0.1-k. Version numbers between freeBSD code and Intel code will be different, because it's different vendors numbering in different ways.
Why have a ko and in the kernel? Well, it is possible to unbind the static ix and then kldload the ko, which gives you flexibility, and ability to load your own compiled ko driver.
So then dont worry about this for my build.
Quote from: spetrillo on October 04, 2025, 06:42:18 PMQuote from: BrandyWine on September 24, 2025, 06:39:03 AMQuote from: spetrillo on September 22, 2025, 06:48:43 PMSo some interesting driver info for FreeBSD. If I look at the Intel website it tells me the latest FreeBSD driver version is 3.4.31, however when I run sysctl -a | grep dev.ix.0.iflib.driver_version it tells me I am running 4.0.1-k on my OPNsense server. Not sure where this driver came from bc the Intel 30.4.2 pkg only shows the 3.4.31 version.
I just did a standard OPNsense install. Its just running 25.7. I ran sysctl -a | grep dev.ix.0.iflib.driver_version. It shows the version as 4.0.1-k. I thought this was the driver version for ix.
Well, the ix ko shows 4.0.1-k
How it's loaded in? It's not in as klm
strings /boot/kernel/if_ix.ko | grep "4.0.1"
kldstat -v |grep ix
it's #146 on my OPNsense.
ix is in the kernel, I suspect the ko is the same code that's in the kernel. Edit: which is the case, v14.3 src code ID's ix driver as 4.0.1-k. Version numbers between freeBSD code and Intel code will be different, because it's different vendors numbering in different ways.
Why have a ko and in the kernel? Well, it is possible to unbind the static ix and then kldload the ko, which gives you flexibility, and ability to load your own compiled ko driver.
So then dont worry about this for my build.
The driver is in the kernel, is what I was getting at. The GENERIC build still builds the kmods ko's, and many of them are compiled into the kernel modules.
To use the Intel one you need to re-compile kernel without ix, just as I outlined in the e610 thread.