How do I find out which module drives which device?

baldy3105 · 04-06-2008, 05:54 AM

Hi Chaps,

I have a peice of hardware that is failing while my laptop is running. I want to unload and reload the module for it to see if the driver is getting upset, however when I lsmod I can't find any name that even vaguely resembles the name of the hardware device I get from lspci.

So how do I unequivocally identify the driver/module that is currently handling any specific device?

Cheers

Pete

Bruce Hill · 04-06-2008, 07:57 AM

Read Linux Kernel in a Nutshell ... iirc chapter 7.

jschiwal · 04-06-2008, 08:15 AM

For many devices, the Kernel source documentation will indicate which devices the driver works with.
You an also use google for the answer. Look at the output of "lspci -v" and then "lspci -n". The latter will contain the manufactures code with will identify the device controller.

baldy3105 · 04-06-2008, 09:03 AM

The chapter links on that site don't appear to work at the moment. I'll try again later.

In the meantime, I used lspci to find out the device type, in this case a bcm5755. Google reveals this page http://hardware4linux.info/component/21350/

which says that the module supporting this device is tg3, and sure enough I have a module loaded called tg3.

However gnome network manager, which is giving me the occasional odd behaviour, says that the driver being used is iwl4965, and again lsmod shows that I have that running too.

The documentation will only tell me which driver is _intended_ to be used for a device, not which one is actually being used. Given how explicit the info is given by lspci and the like I assumed that there would be a simple way of verifying which driver was _actually_ associated with which piece of hardware, hence the question.

Cheers

Pete

Bruce Hill · 04-06-2008, 09:15 AM

Get the pdf tarball.

The output of "lspci -v" shows which module the kernel is presently using. The tg3 (Tigon 3) module is for a Broadcom wired NIC, and iwl4965 is for a Intel wireless NIC.

I'll bet "lspci | grep -i ethernet" will confirm that.

Do you not get output like this:

Code:

root@silas:~# lspci -v
<snip>
00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
        Subsystem: ASUSTeK Computer Inc. Marvell 88E8001 Gigabit Ethernet Controller (Asus)
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
        Memory at fde00000 (32-bit, non-prefetchable) [size=16K]
        I/O ports at ec00 [size=256]
        Expansion ROM at fdd00000 [disabled] [size=128K]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data <?>
        Kernel driver in use: skge
        Kernel modules: skge

baldy3105 · 04-06-2008, 09:46 AM

Interestingly, no it only gives me this -

09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M Gigabit Ethernet PCI Express (rev 02)
Subsystem: Dell Unknown device 01f9
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at fe7f0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] Vendor Specific Information
Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [d0] Express Endpoint IRQ 0

Which doesn't show the kernel drivers used. However looking closer at this output does reveal that I made a stupid assed assumption. That because my old laptop had a broadcom wireless controller the broadcom device in this one was also the wireless and then saw what I expected to see when I ran lspci. On closer inspection the following device shows -

0c:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
Subsystem: Intel Corporation Unknown device 1121
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at fe8fe000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [e0] Express Endpoint IRQ 0

whoops.

thanks for your help.

cheers

Pete

Bruce Hill · 04-06-2008, 09:53 AM

Pete,

I'm not sure when "lspci -v" started showing the modules,
or if that's a kernel option, or what. Maybe jschiwal can
enlighten us on that.

pixellany · 04-06-2008, 10:35 AM

lspci -v does not give me anything on driver, modules, or kernel.

Nor does lspci -vv or lspci -vvv

pixellany · 04-06-2008, 10:41 AM

I don't know if this might be useful. This goes through a directory and determines which of the drivers appear in lsmod:

for i in `ls -R|sed '/^\./d'`; do lsmod|grep `echo $i|cut -d. -f1`;done

Run it (for example) in /lib/modules/`uname -r`/kernel/drivers

To test this, I tried to find the driver that runs my ethernet card--I could not find it (perhaps this means that it is built into the kernel??)

jschiwal · 04-06-2008, 11:13 AM

Does /usr/src/linux/Documentation/networking/00-INDEX have any useful info?

bigrigdriver · 04-06-2008, 11:27 AM

In Suse, run '/usr/sbin/hwinfo --netcard'. You will get output like this:

Quote:

/usr/sbin/hwinfo --netcard
30: PCI 106.0: 0200 Ethernet controller
[Created at pci.273]
Unique ID: rBUF.ZnUy5NLS7T1
Parent ID: WL76.vuIf6LvchL4
SysFS ID: /devices/pci0000:00/0000:00:09.0/0000:01:06.0
SysFS BusID: 0000:01:06.0
Hardware Class: network
Model: "D-Link VT6105 [Rhine-III]"
Vendor: pci 0x1106 "VIA Technologies, Inc."
Device: pci 0x3106 "VT6105 [Rhine-III]"
SubVendor: pci 0x1186 "D-Link System Inc"
SubDevice: pci 0x1406
Revision: 0x86
Driver: "via-rhine"
Device File: eth0
I/O Ports: 0xac00-0xacff (rw)
Memory Range: 0xfdeff000-0xfdeff0ff (rw,non-prefetchable)
Memory Range: 0x00000000-0x0000ffff (ro,prefetchable,disabled)
IRQ: 66 (1525107 events)
HW Address: 00:1b:11:0c:d6:22
Driver Info #0:
Driver Status: via-rhine is active
Driver Activation Cmd: "modprobe via-rhine"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #18 (PCI bridge)

tredegar · 04-06-2008, 11:45 AM

baldy3105 seems to have solved his problem, but the Q "How do I find out which module drives which device?" is still interesting.
Isn't this sort of information available from sysfs ?

Quote:

To illustrate this, consider a PCI network device
and driver. When the system boots, the PCI de-
vice is discovered and a sysfs directory is cre-
ated for it, long before it is bound to a speciﬁc
driver. At some later time, the network driver
is loaded, which may or may not bind to any
devices. This is a different object type than the
physical PCI device represents, so a new direc-
tory is created for it.

Their association is illustrated in Table 12.
Shown is the driver’s directory in sysfs, which
is named after the name of the driver module.
This contains a symbolic link that points to the
devices to which it is bound (in this case, just
one). The name of the symbolic link and the
target directory are the same, and based on the
physical bus ID of the device.

The above is from "The sysfs Filesystem" by Patrick Mochel
Here's a link:
http://www.kernel.org/pub/linux/kern...005/mochel.pdf

baldy3105 · 04-07-2008, 04:07 AM

I'm not sure about "solved" but I'm not stuck anymore! I may raise further questions but not unless I get stuck again.

However I was suprised that there is not some sort of record, say in dmesg, of modules grabbing devices, succesfully or otherwise. Just a one-liner recording the module name, the device it tried to associate with and success or failure would be enough.

Otherwise I'm reduced to rmmod'ing things to see what breaks, which isn't ideal!

Thanks again, you guys are always totally helpfull.

Pete

Bruce Hill · 04-07-2008, 08:02 AM

Just decided to less the Changelog for pciutils and see when this happened:

Code:

mingdao@silas:~$ less /usr/doc/pciutils-2.2.10/ChangeLog
<snip>
2007-11-06  Martin Mares <address-munged>

        * Released as 2.2.9.

        * lspci.c: Added a new switch `-k' which requests printing
        of information on kernel drivers attached to each device
        and on kernel modules reporting the ability to handle the
        device. So far, this is supported only on Linux with the
        sysfs back-end, so it is implemented internally in the lspci
        instead of the libpci. Thanks to Anicka <address-munged>
        for help.

And from "man lspci"

Code:

OPTIONS
<snip>
       -k     Show kernel drivers handling each device and also kernel modules capable of handling it.  Turned on by default when -v is given in the  normal  mode  of  output.
              (Currently works only on Linux with kernel 2.6 or newer.)

So now we know, the rest ... of the story.