Atheros, now part of Qualcomm, is well known for it’s wireless Ethernet chips but what is not so well know is that this company also makes a range of Gigabit Ethernet chips.
The AR8031 is part of the Arctic family of PHYs – which includes the AR8030, AR8033, and AR8035. The AR8031 is Atheros’ 4th generation, single port, 10/100/1000 Mbps Ethernet PHY. It supports both RGMII and SGMII interfaces to the MAC. The AR8031 provides a low-power, low BOM (bill-of-materials) cost solution for a wide range of applications, including enterprise, carrier and home networks, including optical modules and media converters. The AR8031 supports both Sync-E and IEEE1588-V2 timing protcols. The AR8031 device incorporates a 1.25 GHz SERDES which can be connected directly to fiber-optic transceivers for 1000 Base-X/100 Base-FX mode.
The AR8031 integrates Atheros ETHOS-Designed Green Ethernet (EDGE) power saving technologies to automatically save significant power in all operating and idle modes. The AR8031 also supports IEEE 802.3az EEE standard (Energy Efficient Ethernet) with proprietary SmartEEE technology to improve energy efficiency in systems using legacy MAC devices without 802.3az support – enabling customers to fully realize the energy benefits of the new standard by just replacing the PHY devices in their designs.
The AR8031 also supports Wake-on-LAN (WoL), embeds CDT (Cable Diagnostics Test) technology on-chip, and requires only a single, 3.3V power supply. On-chip regulators provide the other voltages. It integrates the termination R/C circuitry on both the MAC interfaces (RGMII/SGMII) and the line side.
For the purposes of testing a new application, I recently had to install CentOS 5.6 on an ASUS system which contained a AS8131 network interface. The installation was smooth but no network was available when I rebooted and logged in. Interesting there was no notice (or none that I noticed) that a driver not not available for the network interface. A quick check of PCI devices using lspci revealed the existence of an AR8031 controller. A check of installed kernel modules using lsmod showed that no driver for this device was installed. That implied that CentOS was unable to supply a suitable driver for the AS8131.
Nowadays my first stop when I need a oddball device driver for Red Hat or Centos is generally ELRepo. ELRepo stands for Enterprise Linux Repository or, in Spanish, The Repo. ELRepo is a community repository for Enterprise Linux distributions, e.g. Red Hat Enterprise Linux (RHEL), CentOS, Oracle Enterprise Linux and Scientific Linux. ELRepo exists to meet a need for packages that enhance Enterprise Linux that are not currently met by the distributions themselves or other 3rd party repositories. All their packages are built against the RHEL kernel and are compatible with other clone distributions who maintain compatibility with the RHEL kernel.
ELRepo focuses on hardware related packages including filesystem, graphics, hardware monitoring, network, sound and webcam drivers. Kernel drivers in kABI-tracking kmod packages are backported to extend and enhance the functionality of a distribution’s kernel. Such drivers may be backported directly from upstream projects, from the mainline kernel or directly from third party device vendors. One of the people behind ELRepo is Dag Wieers, a name that will be familiar to anybody who has spent time looking for third party RPM packages.
So, I hear you ask, what exactly is a kABI-tracking kmod? Normally a Linux device driver must be built against the specific kernel for which it is going to be used on. As most common device drivers are part of the kernel, this is usually not a problem. However, third party drivers must be recompiled against each new kernel. This causes inconvenience for users who must rebuild the driver every time a new kernel is installed. Third party video drivers such as the proprietary NVidia driver is typically where most users come across this problem.
A Kernel Application Binary Interface (kABI) is the exported binary interface provided by a particular Linux kernel, and it’s accompanying kernel modules. Linux itself does not provide a stable ABI for kernel modules. Linux does publish a ABI of sorts but the reality it that is meaningless as far as kernel modules are concerned. Read this interesting rational by Greg Kroah-Hartman for why there is no real Linux ABI. This means that there can be considerable differences in internal structure and function between different kernel versions. Fortunately, nowadays, symbol versioning information is placed within the .modinfo section of loadable modules. This versioning information can be compared with that of a running kernel before loading a module and if the versions are incompatible, the module will not be loaded.
The idea behind a kernel ABI is that it should not change without a really good reason in a released distribution. Some distributions do not care about this issue but most Linux distributions including Red Hat and Ubuntu do and take steps to ensure that a kABI is maintained. This is not always possible. Sometimes, usually due to a security issue, a change is accepted into a kernel package that forces a change of it’s ABI. Such an ABI change is denoted by a change in the SONAME portion of a kernel package name. If this occurs, kernel module packages will need to be recompiled against the updated kernel headers.
There is no industry-wide agreement on the how to handle the kABI issue or when to perform a kABI bump. Most distributions have kABI checkers with white/black lists in their build systems to detect when the kernel’s exported interface has changed, and when kernel modules may need to be recompiled.
Red Hat was probably the first to identify a subset of the kABI that was to be considered sufficiently stable for third party use. These specific symbols are listed on various whitelists (available within corresponding kernel-devel packages, and named kabi_whitelist), which are tied into their internal build process such that all subsequent kernel builds automatically include verification against any compatibility breaks. As a result developers who use only whitelisted symbols should not need to rebuild their drivers on kernel updates.
A consistent kABI is a key feature of all Red Hat Enterprise Linux distributions and, so long as upstream does not break the kABI, a kABI-tracking kmod driver will work across all kernels for a given Red Hat Enterprise Linux distribution (eg, RHEL5, CentOS 5, Scientific Linux 5) without the need to recompile the module for each kernel update. CentOS probably makes the strongest claim about it’s kABI policy as They claim that a particular kABI will be preserved for the entire life of a release.
Red Hat also provides developers with the infrastructure and documentation to support kernel module packaging. See Red Hat Kernel Module Packaging and Red Hat Driver Update Program (RHEL5 DUP) for complete details. An online kABI checker is also available or you can download and use the abi_check.py script. See here for information on the Debian kABI. If you want to explore the gory details of kernel ABIs, I suggest you read this post by Jon Masters.
OK, now that you have learned about kABI and kmod tracking, let us return to the question on how to find the right driver for a particular device. There is no magic to the process. An example of how I found the driver for my AR8131 NIC will demonstrate the correct steps to perform.
# /sbin/lspci | grep -i net 01:00.0 Ethernet controller: Atheros Communications AR8131 Gigabit Ethernet (rev c0) # /sbin/lspci -n | grep 01:00.0 01:00.0 0200: 1969:1063 (rev c0) $ grep -i 1969 /lib/modules/*/modules.alias | grep -i 1063
By using the vendor and device numbers, you can check to see if your system already contains an appropriate driver module. In my case it did not. However searching for the Vendor:Device ID pairing of 1969:1063 on the ElRepo Device IDs page showed that kmod-atl1e should work with the AR8131 NIC. So I downloaded the kmod-atl1e package, installed the appropriate driver for my platform from the package, rebooted, and voila I had a working network.
Well, that is all that you should need to know to resolve how and where to find a missing Linux kernel device driver!