Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Modulnamen ermitteln

5 views
Skip to first unread message

Helmut Hullen

unread,
May 3, 2012, 5:32:00 AM5/3/12
to
Hallo alle miteinander,

gibt es ein simples Verfahren, um den Modulnamen eines "Geräts" zu
ermitteln, wenn ich die Daten von "lspci" oder von "lsusb" habe?

Derzeit gehe ich mit den Daten von "lspci" (genauer: "lspci -n") in die
Datei "/lib/modules/<Kernel>/modules.alias" und suche dort weiter; ist
etwas umständlich ...

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

Sven Hartge

unread,
May 3, 2012, 6:30:21 AM5/3/12
to
Helmut Hullen <Hel...@hullen.de> wrote:

> gibt es ein simples Verfahren, um den Modulnamen eines "Geräts" zu
> ermitteln, wenn ich die Daten von "lspci" oder von "lsusb" habe?

Ist das Gerät aktiv und du willst nur wissen, welches Modul sich das
Gerät "geangelt" hat oder willst du vorher wissen, welches Modul für ein
Gerät verantwortlich wäre?



--
Sigmentation fault. Core dumped.

Thomas Bächler

unread,
May 3, 2012, 8:21:34 AM5/3/12
to
Am 03.05.2012 11:32, schrieb Helmut Hullen:
> Hallo alle miteinander,
>
> gibt es ein simples Verfahren, um den Modulnamen eines "Geräts" zu
> ermitteln, wenn ich die Daten von "lspci" oder von "lsusb" habe?
>
> Derzeit gehe ich mit den Daten von "lspci" (genauer: "lspci -n") in die
> Datei "/lib/modules/<Kernel>/modules.alias" und suche dort weiter; ist
> etwas umständlich ...
>
> Viele Gruesse
> Helmut

Direkt mit den lspci oder lsusb Daten wirds schwer. sysfs ist dein Freund:

lspci:

00:19.0 Ethernet controller: Intel Corporation 82577LC Gigabit Network
Connection (rev 06)

Dann im sysfs schauen:

cat /sys/devices/pci0000\:00/0000\:00\:19.0/modalias
modprobe --resolve-alias $(cat
/sys/devices/pci0000\:00/0000\:00\:19.0/modalias)

Das Konvertieren der PCI IDs zu den sysfs-Pfaden ist irgendwie komisch,
hab das System noch nicht ganz begriffen.

Message has been deleted

Sven Hartge

unread,
May 3, 2012, 8:38:59 AM5/3/12
to
Thomas Bächler <thomas....@rwth-aachen.de> wrote:
> Am 03.05.2012 11:32, schrieb Helmut Hullen:

>> gibt es ein simples Verfahren, um den Modulnamen eines "Geräts" zu
>> ermitteln, wenn ich die Daten von "lspci" oder von "lsusb" habe?
>>
>> Derzeit gehe ich mit den Daten von "lspci" (genauer: "lspci -n") in
>> die Datei "/lib/modules/<Kernel>/modules.alias" und suche dort
>> weiter; ist etwas umständlich ...

> Direkt mit den lspci oder lsusb Daten wirds schwer. sysfs ist dein
> Freund:

lspci -v:

00:09.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine] (rev 06)
Subsystem: D-Link System Inc DFE-530TX rev A
Flags: bus master, medium devsel, latency 32, IRQ 17
I/O ports at 9000 [size=128]
Memory at ea000000 (32-bit, non-prefetchable) [size=128]
[virtual] Expansion ROM at c0020000 [disabled] [size=64K]
Kernel driver in use: via-rhine

Siehe letzte Zeile.

Geht allerdings nur als root, nicht als normaler User.

Thomas Bächler

unread,
May 3, 2012, 8:54:42 AM5/3/12
to
Am 03.05.2012 14:38, schrieb Sven Hartge:
> lspci -v:
>
> 00:09.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine] (rev 06)
> Subsystem: D-Link System Inc DFE-530TX rev A
> Flags: bus master, medium devsel, latency 32, IRQ 17
> I/O ports at 9000 [size=128]
> Memory at ea000000 (32-bit, non-prefetchable) [size=128]
> [virtual] Expansion ROM at c0020000 [disabled] [size=64K]
> Kernel driver in use: via-rhine
>
> Siehe letzte Zeile.
>
> Geht allerdings nur als root, nicht als normaler User.

"in use" - das geht also nicht, wenn der Treiber nicht bereits geladen ist.

Werner Flamme

unread,
May 3, 2012, 9:09:45 AM5/3/12
to
Thomas Bächler [03.05.2012 14:54]:
Wer "hwinfo" installiert hat, erhält die Info, allerdings zum Teil gut
verborgen. "hwinfo --help" hilft ;-)

Beispielausgabe für "hwinfo --gfxcard":

33: PCI 200.0: 0300 VGA compatible controller (VGA)
[Created at pci.319]
Unique ID: B35A.1Wh5kZbzRY9
Parent ID: 37TO.R0aazaG3PyC
SysFS ID: /devices/pci0000:00/0000:00:10.0/0000:02:00.0
SysFS BusID: 0000:02:00.0
Hardware Class: graphics card
Model: "nVidia G96 [GeForce 9500 GT]"
Vendor: pci 0x10de "nVidia Corporation"
Device: pci 0x0640 "G96 [GeForce 9500 GT]"
SubVendor: pci 0x10b0 "CardExpert Technology"
SubDevice: pci 0x1401
Revision: 0xa1
Driver: "nvidia"
Driver Modules: "nvidia"
Memory Range: 0xfb000000-0xfbffffff (rw,non-prefetchable)
Memory Range: 0xd0000000-0xdfffffff (ro,non-prefetchable)
Memory Range: 0xf8000000-0xf9ffffff (rw,non-prefetchable)
I/O Ports: 0xec00-0xec7f (rw)
Memory Range: 0xfaf80000-0xfaffffff (ro,non-prefetchable,disabled)
IRQ: 19 (23064 events)
I/O Ports: 0x3c0-0x3df (rw)
Module Alias: "pci:v000010DEd00000640sv000010B0sd00001401bc03sc00i00"
Driver Info #0:
Driver Status: nvidiafb is not active
Driver Activation Cmd: "modprobe nvidiafb"
Driver Info #1:
Driver Status: nouveau is not active
Driver Activation Cmd: "modprobe nouveau"
Driver Info #2:
Driver Status: nvidia is active
Driver Activation Cmd: "modprobe nvidia"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #24 (PCI bridge)

Man sieht wohl unter "Driver" und "Driver Modules" die aktiven Treiber
und unter "Driver Activation Cmd" auch mögliche Alternativen.

Da der OP seine Mails ja immer mit einem Hinweis auf Schlackerware
beendet, findet er vielleicht was unter
<http://slackbuilds.org/repository/13.37/system/hwinfo/>. Homepage ist
wohl <http://gitorious.org/opensuse/hwinfo>.

Gruß
Werner

--

Helmut Hullen

unread,
May 3, 2012, 9:38:00 AM5/3/12
to
Hallo, Erik,

Du meintest am 03.05.12:

>> gibt es ein simples Verfahren, um den Modulnamen eines "Geräts" zu
>> ermitteln, wenn ich die Daten von "lspci" oder von "lsusb" habe?

> Für lspci ja.

>> "Ubuntu" - an African word, meaning "Slackware is too hard for me".

> Eigentlich ist das nicht mein Stil, aber Du willst es ja so:

> man lspci

Danke - die Option "-k" (oder "-v") scheint ein guter Startpunkt zu
sein.

Helmut Hullen

unread,
May 3, 2012, 9:39:00 AM5/3/12
to
Hallo, Sven,

Du meintest am 03.05.12:

>> gibt es ein simples Verfahren, um den Modulnamen eines "Geräts" zu
>> ermitteln, wenn ich die Daten von "lspci" oder von "lsusb" habe?

> Ist das Gerät aktiv und du willst nur wissen, welches Modul sich das
> Gerät "geangelt" hat oder willst du vorher wissen, welches Modul für
> ein Gerät verantwortlich wäre?

Eher letzteres - auch wenn da inzwischen einige weitere Automaten
werkeln (möchten).

Mal sehen, wie weit ich mit "lspci -k" komme.

Mein derzeitiger Favorit für Netzwerkkarten:

lspci -n -k | grep -A3 ' 0200:'

Helmut Hullen

unread,
May 3, 2012, 9:39:00 AM5/3/12
to
Hallo, Sven,

Du meintest am 03.05.12:

>>> gibt es ein simples Verfahren, um den Modulnamen eines "Geräts" zu
>>> ermitteln, wenn ich die Daten von "lspci" oder von "lsusb" habe?

> lspci -v:

> 00:09.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine]
> (rev 06) Subsystem: D-Link System Inc DFE-530TX rev A
> Flags: bus master, medium devsel, latency 32, IRQ 17
> I/O ports at 9000 [size=128]
> Memory at ea000000 (32-bit, non-prefetchable) [size=128]
> [virtual] Expansion ROM at c0020000 [disabled] [size=64K]
> Kernel driver in use: via-rhine

> Siehe letzte Zeile.

Könntest Du noch mal "lspci -k" ausprobieren?

Eigentlich sollte in beiden Fällen auch (in einer weiteren Zeile)
"Kernel modules: xxxyyy" angezeigt werden; bei der Realtek 8139
beispielsweise werden 2 mögliche Module angezeigt.

Hier: lspci Version 3.1.7

Und zur Vielfalt der Ausgaben bei "lspci -n -k":

02:0c.3 0c00: 1106:3044 (rev 46)
Subsystem: 00ff:9a01
Kernel driver in use: firewire_ohci
02:0d.0 0200: 10ec:8139 (rev 10)
Subsystem: 1259:2500
Kernel driver in use: 8139too
Kernel modules: 8139too, 8139cp
02:0e.0 0280: 1050:6692 (rev 01)
Subsystem: 1234:5678
Kernel modules: hisax

Man beachte die "Kernel"-Zeilen ...

Helmut Hullen

unread,
May 3, 2012, 10:05:00 AM5/3/12
to
Hallo, Werner,

Du meintest am 03.05.12:

>>> lspci -v:
>>>
>>> 00:09.0 Ethernet controller: VIA Technologies, Inc. VT86C100A
>>> [Rhine] (rev 06) Subsystem: D-Link System Inc DFE-530TX rev
>>> A Flags: bus master, medium devsel, latency 32, IRQ 17
>>> I/O ports at 9000 [size=128]
>>> Memory at ea000000 (32-bit, non-prefetchable) [size=128]
>>> [virtual] Expansion ROM at c0020000 [disabled] [size=64K]
>>> Kernel driver in use: via-rhine

[...]

> Wer "hwinfo" installiert hat, erhält die Info, allerdings zum Teil
> gut verborgen. "hwinfo --help" hilft ;-)

> Beispielausgabe für "hwinfo --gfxcard":

> 33: PCI 200.0: 0300 VGA compatible controller (VGA)
> [Created at pci.319]
> Unique ID: B35A.1Wh5kZbzRY9
> Parent ID: 37TO.R0aazaG3PyC

[...]

> SubDevice: pci 0x1401
> Revision: 0xa1
> Driver: "nvidia"
> Driver Modules: "nvidia"

[...]

> Module Alias: "pci:v000010DEd00000640sv000010B0sd00001401bc03sc00i0
> 0" Driver Info #0:
> Driver Status: nvidiafb is not active
> Driver Activation Cmd: "modprobe nvidiafb"
> Driver Info #1:
> Driver Status: nouveau is not active
> Driver Activation Cmd: "modprobe nouveau"
> Driver Info #2:
> Driver Status: nvidia is active
> Driver Activation Cmd: "modprobe nvidia"
> Config Status: cfg=new, avail=yes, need=no, active=unknown
> Attached to: #24 (PCI bridge)

Danke - vielleicht lässt sich mit "modprobe xyz" auch etwas anfangen.

Schnellschuss:

hwinfo | grep modprobe | cut -d'"' -f2 | sort -u

zeigt, dass die Liste nicht unkontrolliert abgearbeitet werden sollte.

Thomas Bächler

unread,
May 3, 2012, 10:27:42 AM5/3/12
to
Am 03.05.2012 15:39, schrieb Helmut Hullen:
> 02:0d.0 0200: 10ec:8139 (rev 10)
> Subsystem: 1259:2500
> Kernel driver in use: 8139too
> Kernel modules: 8139too, 8139cp

Klassiker. Die beiden lassen sich anhand der PCI ID nicht unterscheiden,
beide Module tragen das Alias 'pci:v000010ECd00008139sv*sd*bc*sc*i*'.
Beim Booten versucht das System tatsächlich, beide zu laden, und sie
einigen sich dann irgendwie (man kann wohl durch genaueres Hinsehen die
Geräte unterscheiden).

Helmut Hullen

unread,
May 3, 2012, 11:03:00 AM5/3/12
to
Hallo, Thomas,

Du meintest am 03.05.12:
Vermutlich definiert der (jeweilige) Kernel, was geladen werden kann;
seit einigen Jahren scheint nur noch 8139too in der Konfiguration zu
stehen.

Vermutlich ähnlich: Intel Fast Ethernet pro100 (oder so ähnlich); zu
Steinzeiten war auch "eepro" im Angebot der Kernel-Konfiguartion,
inzwischen scheint es (fast) nur noch e100 zu geben.
0 new messages