Reverting back to the built-in ixgbe module
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
Red Hat
Guru
8602 points
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
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.
Guru
3184 points
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.
Active Contributor
139 points
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