Determine whether kernel built-in driver supports a device

Question

I'm trying to find a way to accurately determine whether all the hardware on some system has a valid driver installed either via a kernel module or built-in to the kernel.

I'm working with RHEL 5.5 on a Dell Optiplex 990.

I know that lspci is a good starting point, but it's not reliable because it could be manually updated and new drivers don't always update it. I know that I can look look at /lib/modules/$(uname -r)/modules.pcimap to find out whether there is a driver module for the device base on the ID, but what about built-in drivers? I've installed a new kernel and I'm trying to find out whether the built-in agpgart-intel module supports the host bridge with vendor:device ID 8086:0100.

Also, is there a proper procedure for updating the pci.ids list when updating the kernel? I know I could just update everything using update-pciids or by downloading the list from the internet, but doesn't it make more sense to only include IDs supported by the current install?

Answer 1

Alex answers your question. Compare lspci

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 06)
00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06)
00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 (rev 06)
00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 5 (rev 06)
00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation QM57 Chipset LPC Interface Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 06)
02:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
ff:02.1 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor QPI Physical 0 (rev 02)
ff:02.2 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved (rev 02)
ff:02.3 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved (rev 02)

with the result of ls -l pci*/*:*/driver

lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:00.0/driver -> ../../../bus/pci/drivers/agpgart-intel
lrwxrwxrwx. 1 root root 0 May 21 09:34 pci0000:00/0000:00:02.0/driver -> ../../../bus/pci/drivers/i915
lrwxrwxrwx. 1 root root 0 May 21 09:06 pci0000:00/0000:00:16.0/driver -> ../../../bus/pci/drivers/mei_me
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:19.0/driver -> ../../../bus/pci/drivers/e1000e
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1a.0/driver -> ../../../bus/pci/drivers/ehci-pci
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1b.0/driver -> ../../../bus/pci/drivers/snd_hda_intel
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1c.0/driver -> ../../../bus/pci/drivers/pcieport
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1c.3/driver -> ../../../bus/pci/drivers/pcieport
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1c.4/driver -> ../../../bus/pci/drivers/pcieport
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1d.0/driver -> ../../../bus/pci/drivers/ehci-pci
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1f.0/driver -> ../../../bus/pci/drivers/lpc_ich
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1f.2/driver -> ../../../bus/pci/drivers/ahci
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1f.3/driver -> ../../../bus/pci/drivers/i801_smbus
lrwxrwxrwx. 1 root root 0 May 21 09:37 pci0000:00/0000:00:1f.6/driver -> ../../../bus/pci/drivers/intel ips

It won't necessarily cover "all the hardware". In particular there could be functionality accessed through ACPI. That would be too much to spelunk manually though.

An alternative would be to start by building a basic checklist of functions as you try to use the system. It's a more positive approach for me, in that Linux often doesn't support some function on my system, but I use Linux happily without needing that function :).

I agree lspci makes a nice helper. However it could be simpler e.g. when you see the Ethernet line, to just confirm you have working ethernet. If Ethernet didn't work, I can check for the lack of a driver, but I don't need to check the driver before I try it.

I also might want a record of what the exact driver is later because I'm happy it worked well and I think it's good hardware to choose again :). Unfortunately as vonbrand says hardware support can be a minefield, so ideally you'd still want to have certification for your OS, or the community equivalent: lots of "works great for me" reports in Google.

I wonder if agp is something you wanted to use? RHEL 5 is pre-gnome3, so you can open your terminal emulators without any 3D acceleration if you need to. If you do need 3D acceleration, you need a GL library for it as well. Why not try the most demanding graphics app(s) you might want to use, and check that they run?

Performance is a bit more annoying to judge. It's more than a checkbox, but it could still be caused by a discrete possibility like having a generic driver instead of a hardware-specific one. It may be useful to look for quick benchmarks across your list of functions, and note results as a reference point. E.g. Gnome Disks makes for a very convenient benchmark tool which is installed by default on recent versions (cough) of that desktop.

When you notice a performance failure on one of your systems (e.g. Gnome 3 being jerky), you can note it as a potential checklist item. I.e. on a new system you might then note that Gnome 3 is not jerky all the time, so it's passed that particular test.

Answer 2

If you know the Kbuild symbols for the desired drivers, you can check /proc/config.gz or any other source of kernel configuration available (distributions usually place config in /boot alongside the kernel, or you could extract the config from the kernel with scripts/extract-ikconfig from the kernel source tree - provided the configuration was compiled into the kernel of course).

Answer 3

You'd have to look up the devices listed for the machine against a list of devices supported by RHEL. Yes, there might be ones that happen to work but nobody has bothered to check/certify they work.

Be careful, sometimes devices with similar names (e.g. some Ethernet card called like SC-423+ was a completely different beast than the superficially identical SC-423; and once we got bitten by cards with the exact same model number that were quite different). And the other way around, completely different devices from separate providers were built on the same pieces. But also so that manufacturer A was rock solid, while B was flaky as hell.