Reverting back to the built-in ixgbe module

Latest response

While doing some performance tuning and such on a 6.7 physical machine with a pair of Intel 10Gb NICs (82599s), someone advised trying the latest 5.x driver from Intel which sounded like a good idea (either it would be worth it or not). Unfortunately this didn't solve what we were looking to solve and folks concerned with the whole kernel upgrade conundrum suggest just putting back the old ixgbe module. Alas, there seems to be no well-documented method (at least from Intel or plenty or searching the web), so does anyone have a clear cut way to drop this "updated" version and make it use the default one?

modinfo ixgbe

filename: /lib/modules/2.6.32-573.el6.x86_64/updates/drivers/net/ethernet/intel/ixgbe/ixgbe.ko
version: 5.0.4

What we need to go back to is:
filename: /lib/modules/2.6.32-573.el6.x86_64/kernel/drivers/net/ixgbe/ixgbe.ko
version: 4.0.1-k

thanks!

Responses

How did you install "the latest 5.x driver from Intel"?

Following the Intel readme, as I recall, it was as simple as untaring the thing, cd into src, then running make install.

Assuming the driver doesn't come from an RPM, something like this should do it:

service network stop
modprobe -r ixgbe
mv /lib/modules/2.6.32-573.el6.x86_64/updates/drivers/net/ethernet/intel/ixgbe/ixgbe.ko /root/
depmod -a
service network start

Once network is back up, delete the old driver:

rm /root/ixgbe.ko

wow, if that works that would be awesome. I had tried removing the module after downing the interfaces, then renaming the path to the updates, but I did not use the depmod -a command, had just tried doing the insmod ixgbe (with the path to the built in driver). I'll give it a whirl and see how it goes. thanks

I ran through these steps but it did not reload the default driver, so those interfaces wouldn't light back up. I copied the ixgbe.ko file back into place and they started right up. I figured it was a lost cause, but, now I see after a reboot, 4.0.1-k is loaded again. I don't totally get why that is.

That's what depmod does, it looks through the drivers available at the time of running and builds a set of dependencies. So when modprobe goes "I have device 8086:10f9 (which is the PCI ID of an 82599_SFP), what driver do I use?" it looks through the files in /lib/modules/ created by depmod and finds a driver which advertises support for that device. As you ran depmod with the third-party driver removed, the in-kernel driver took over all the PCI IDs of ixgbe devices, so the in-kernel ixgbe is loaded by modprobe. I'm not sure why a reboot was required but that's good to know. You can probably safely move/remove the third-party driver file now.

Next time when you wish to try out a newer version, you might want to ask ELRepo ( http://elrepo.org/ ) to build a kmod package for that version. One of the advantages with using a kmod is that it is easy to install AND uninstall. Uninstallation is done by a simple "yum remove kmod-xxx". But more importantly, ELRepo's kmod packages are kABI-tracking, meaning there is no need to rebuild for each kernel update.

Doesn't kABI tracking kmod RPMs only help when the given code only used kABI-whitelisted interfaces? I think ixgbe uses some stuff outside of the kABI so those guarantees don't buy you much, but I could be mistaken.

Kind of correct. RH publishes a kABI whitelist, and if a driver (module) only uses kernel symbols on that whitelist then it should, in theory, never need rebuilding for kernel updates throughout the lifespan of RHEL. However, in reality, most drivers use kernel symbols that are not on the whitelist so have the potential for kABI breakage. That said, breakage only occurs when RH change the ABI of a particular kernel symbol that driver uses. In reality this very rarely happens within a given point release, but can more commonly occur moving from one point release to another. The further down the lifespan road we travel within any RHEL release, the less tinkering there is within the kernel, so the less likely it is that a kABI-tracking kmod package will require rebuilding after a point release update. Given where we are on the RHEL6 release map, it doesn't get much better than it is now. Bottom line though, it's totally driver dependant as each driver uses a (likely) unique set of kernel symbols

Never heard of it but that sounds awesome. I had read up some on the DKMS method, but even that didn't sound like it would make folks happy. I was actually griping about that very same issue around "why isn't there a better way", this changes everything. thanks

I see. Thanks for your response!