X540-at2 Driver

0 views

Skip to first unread message

Charolette Antosh

unread,

Aug 3, 2024, 3:44:01 PM8/3/24

to haylaliles

Hello,

Thanks for your quick response.
Are there plans to release a driver for Windows 11 in the future, or is that not part of the roadmap? Wondering if I need a different NIC, need to downgrade, or wait for drivers to be released.

Thanks again!

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

I am having issues with the ixgbe driver in Linux (specifically Ubuntu 22.04). The machine is a Supermicro server with a X9DRW-CTF31 motherboard. It has TWO built in X540-AT2 10GBase-T ethernet ports. On boot, one of the onboard interfaces is labeled as disabled. I have replicated this on CentOS 8 and Ubuntu 22.04. The ixgbe module must be unloaded and re-loaded for both interfaces to be recognized. Supermicro has no firmware updates specific to the ethernet interfaces, and I have the latest BIOS and firmware updates for the board. These ports are built-in to the motherboard so I am at a loss as to why this is happening. They are connected to a DELL PowerConnect 6248P switch. It should eb noted that bonding is set up for both ports, but this of course fails when the machine is booted because one of the interfaces fails to come up. This is resolved with re-loading of the ixgbe driver. Both NICs are recognized by lspci, and there is obviously not a hardware issue since the ports BOTH come up when the driver is reloaded. I could write a script to unload and reload the driver after boot but I was wondering if there is a fix for the driver.

Also here is the output after boot where I look for error messages about the ixgbe module, and the second command is to show the two onboard interfaces. As you can see, when running lshw command the second interface is listed as disabled. Again these commands are run immediately after boot. In a follow up post I will provide the output when the module is unloaded and reloaded.

Thank you for sharing the information. We appreciate you reaching out to us regarding the reported issue. As the product was in built in motherboard. we kindly advise you to contact the OEM Supermicro serve support team for further assistance. They will be best equipped to provide support and address any concerns related to your query.

This is a second follow up regarding the issue reported to us. We just wanted to know if you got the opportunity to review our last update and whether you tried our suggestion and what is the outcome. Please let us know if there is any other help required.

Fails with the following error: "fatal error: linux/pci-aspm.h: No such file or directory #include "
I sent this as a reply to another message I was sent. I was told the engineers would look into it. I didn't save that email.

For some reason, there are two different threads on this request, because I am not seeing the response I sent, and this is the first email I received from you, but I see the posts asking for the first and second time. I am not sure what is going on.

Hm, I tried all that and at least got it up to 1Gbps with the modprobe line, no luck with 10. The cable should be good enough but I'm not sure, thanks anyway so far!
dmesg had no errors, and MTU didn't seem to make a difference. Forcing speed vs autoneg (on both sides) didn't change anything either.

Changing your options via modprobing was simply a shot in the dark, as I'd seen nixing those options fix other old drivers that are rarely used these days. So, that makes me happy that wild guess paid off with a decent speed improvement.

First, try Intel 10G without any additional drivers. However, there is also the possibility that TCRP will forcefully automatically add IXGBE. I think you should use the manual option at the end of the rploader.sh line

Sent from my iPhone using Tapatalk

Intel 10GB nic and DS3622xs+ issue was discussed. There was no user who could not solve it at the time, and you are the first case that has not been solved now. I think you should check the detailed junior og analysis and the correct driver list. -ext/issues/103

Sent from my iPhone using Tapatalk

Now I have some more serious problems in disk detection (it detects 8 SATA inputs on the board, being only 6, the m2 is not detected and 3 asmedia hdd is not detected), question: is it possible that the installation by DTS file?

The models that require DTC are DS1621+ and DS920+.
The vanilla driver for the Intel 10GB NIC is not included, so there is no need to do the same as now, and it seems to be used as TCRP automatically finds it.

I installed a new Intel X540 10g network card in my Ubuntu 22.04.1 pc, but I'm struggling to get it working (built in 1gbps ethernet ports are working). lshw shows network UNCLAIMED - anyone have any insights on what I did wrong or what I can do to get it going? Details below, thanks!

I had the same issue on a system running a X553 chipset. Interestingly the gigabit ports on the chip were fine, but the 10 gig ports vanished. For extra fun they worked when I initially set it up, then stopped after an update.

Trying to build a kernel module failed, mostly due to past me's mistakes, but should work. You will need to sign it - there seem to be logical instructions on ubuntu's blog, but my machine's remote, currenly on CSM, and you need to enable secureboot and add your own key. However, the 6.x kernels seem to have fixed it, and installing it will get you a working in kernel driver with minimal faff.

5.15.0-101-generic was the current, non HWE kernel at the time of this post, and the 10 gig ports on my system didn't work. 6.5.0-26-generic is the HWE kernel - and includes working ixgbe drivers. I kind of figured out it was a issue with this kernel series from the comments to this serve at home post, and the comments narrowed it down to a specific commit

WARNING: The ixgbe driver supports the Large Receive Offload (LRO) feature. This option offers the lowest CPU utilization for receives but is completely incompatible with routing/ip forwarding and bridging. If enabling ip forwarding or bridging is a requirement, it is necessary to disable LRO using compile time options as noted in the LRO section later in this document. The result of not disabling LRO when combined with ip forwarding or bridging can be low throughput or even a kernel panic.

Hi Carlos,

You actually can (although it's not officially supported by us). Make sure to have the SANLink2 10Gb plugged in before you boot your machine. Thunderbolt is an extension of PCIe so the device needs to be plugged in prior to the machine booting up so it's recognized during the boot-up sequence and the built-in Intel driver from ESXi loads the modules/drivers for the device. I've only tested this on ESXi 6, 3620759.

1. In the vSphere Client, select the ESXi Host.
2. The Network Adapters will appear under Home > Inventory > Host and Clusters > Configuration> Network Adapters.

3. You can also ssh into the ESXi host to verify the network adapters with the following command:

We have some of the same Dell PowerEdge 620 systems in production but with the Broadcom 10g SFP+ / 1g ethernet interfaces. They are connected to Dell 10g switches. With IPFire, it just works and the CPU utilization never goes over 5 percent even with heavy OpenVPN and internet traffic.

This sounds like a driver or a switch issue. Is the switch set to auto negotiate? Which NIC mezzanine card is in your R620? The Dell part number is clearly marked on the card and maybe the key to getting to the bottom of your problem.

The X540 needs perfect cables, otherwise you will have unstable links even with a few meters. I even had problems with 20 meters of cat7 cables with cat6a connectors. The bad transmitter output was fixed with the X550 series.

More testing has shown that 10gig is successfully negotiated if I connect to an HP FlexFabric 5940 or a different HP 5406R. Apparently the problem is somewhere in the 5406R I was originally using. The two 5406r have different software versions, so that may be the culprit, and upgrades need to happen anyway.

Most of this doesn't matter, ethernet flow control has never been widely supported and most switch devices will respect PAUSE frames, but not send them. That being said, your questions can be addressed fairly easily:

Not exactly. You can still send pause frames, but your card won't respect ones sent by the switch (which you will likely never get anyhow). The driver probably doesn't send pause frames though, so any you send would have to be generated manually.

The ethtool source code (rev 3.18) and a register interface for a part I'm familiar with, reveal an explanation for the behavior you observed. The 802.3x standard defines flow-control, but I haven't looked there in a while.