Dynamische Zuweisung von Gerätedateien?

[Ashura]

Hallo.

Ergänzend zu meinem alten Thread stieß ich nun noch auf eine weitere Ungereimtheit:

Beim Systemstart werden offenbar (vom Kernel?) den verschiedenen physikalisch vorhandenen Ethernet-Adaptern beliebig Gerätedateien zugewiesen.

Ich verfüge über drei Ethernet-Adapter und meine derzeitige Verbindung läuft über eth0, beim nächsten Start kann es aber schon wieder eth1 sein. Und darauf hin wiederum eth0; eth2 ist bisher noch nicht aufgetreten.

Ich merke dieses Verhalten, wenn beim Systemstart nicht automatisch eine Verbindung aufgebaut wurde. (ping, „unknown host“)
Führe ich nun „pppoe -I ethX -A“ aus, so kann ich herausfinden, welche Gerätedatei in der aktuellen Session sich nun für meinen Adapter zuständig fühlt. Vorläufig lasse ich in meiner provider-Datei unter /etc/ppp/peers „plugin rp-pppoe.so ethX“ sowohl für eth0 als auch für eth1 ausführen, da ja nie sicher ist, welcher Adapter nun der richtige ist.
Wohlgemerkt: ich stecke weder Karten noch Kabel um.

Woran liegt dieses merkwürdige Verhalten und wie kann ich es unterbinden?

Einen schönen Freitag noch.

Gruß, Ashura

[Axel Richter]

Hallo,

Beim Systemstart werden offenbar (vom Kernel?) den verschiedenen physikalisch vorhandenen Ethernet-Adaptern beliebig Gerätedateien zugewiesen.

Nein, nicht beliebig.

Ich verfüge über drei Ethernet-Adapter und meine derzeitige Verbindung läuft über eth0, beim nächsten Start kann es aber schon wieder eth1 sein. Und darauf hin wiederum eth0; eth2 ist bisher noch nicht aufgetreten.
Woran liegt dieses merkwürdige Verhalten und wie kann ich es unterbinden?

Ich gehe mal von PCI-NICs aus.

Szenario1:
Beide NICs sind vom selben Typ, nutzen also das selbe Treiber-Modul, dann ist eth0 die NIC, die im PCI-Slot vor der zweiten NIC steckt. Wenn das bei Dir so ist, dann hast Du bei deinem Problem ein BIOS-Problem mit dem PCI-BUS.

Szenario2:
Die NICs sind unterschiedlich, haben also unterschiedliche Treiber-Module, dann ist eth0 die NIC, deren Modul zuerst geladen wird (etc/modules). Wenn das bei Dir zutrifft, dann werden die Treibermodule bei Dir offensichtlich nicht automatisch beim Systemstart geladen?

viele Grüße

Axel

[Ashura]

Hallo Axel.

Ich gehe mal von PCI-NICs aus.

Der erste ist onboard und wird per sis900-Modul versorgt, die anderen beiden sind Realtek-Karten.

Hm, ich habe mir eben noch einmal die Ausgabe von lsmod angeschaut:

mii                     5248  3 8139too,8139cp,sis900

Weshalb wurden hier zwei identischen Adaptern zwei verschiedene Module zugewiesen?

Szenario1:
Beide NICs sind vom selben Typ, nutzen also das selbe Treiber-Modul, […]

Dieses Szenario dürfte bei mir nicht in Frage kommen, da sich nur eth0 (onboard) und eth1 (Realtek1) abwechseln. eth2 (Realtek2) mischt sich da nicht ein.

Szenario2:
Die NICs sind unterschiedlich, haben also unterschiedliche Treiber-Module, dann ist eth0 die NIC, deren Modul zuerst geladen wird (etc/modules).

Darin steht hierzu gar nichts:

ide-cd  
ide-disk  
ide-generic  
psmouse

Wenn das bei Dir zutrifft, dann werden die Treibermodule bei Dir offensichtlich nicht automatisch beim Systemstart geladen?

Doch, davon gehe ich aus. Andernfalls könnte ich sie nicht nutzen.
Gibt es andere Orte, an denen die Ladereihenfolge von dieser Module festgelegt werden kann?

Die releavanten Zeilen aus /var/log/dmesg

sis900.c: v1.08.09 Sep. 19 2005  
[…]  
eth0: SiS 900 PCI Fast Ethernet at 0xdc00, IRQ 169, 00:00:00:00:00:00.  
[…]  
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)  
8139cp: pci dev 0000:00:0b.0 (id 10ec:8139 rev 10) is not an 8139C+ compatible chip  
8139cp: Try the "8139too" driver instead.  
8139cp: pci dev 0000:00:0e.0 (id 10ec:8139 rev 10) is not an 8139C+ compatible chip  
8139cp: Try the "8139too" driver instead.  
8139too Fast Ethernet driver 0.9.27  
[…]  
eth1: RealTek RTL8139 at 0xd800, 00:02:2a:d7:d4:f0, IRQ 169  
eth1:  Identified 8139 chip type 'RTL-8100B/8139D'  
[…]  
eth2: RealTek RTL8139 at 0xd000, 00:0e:2e:09:ee:94, IRQ 201  
eth2:  Identified 8139 chip type 'RTL-8100B/8139D'  
[…]  
eth0: Media Link Off  
eth1: link up, 100Mbps, full-duplex, lpa 0x41E1  
ADDRCONF(NETDEV_UP): eth0: link is not ready

So sollte es auch normalerweise sein und momentan läuft meine Verbindung auch wirklich über eth1, an dessen Adapter das Netzwerkkabel angeschlossen ist. Beim nächsten Start dürfte es aber schon wieder eth0 sein.

Fehlen noch irgend welche Informationen meinerseits?

Einen schönen Samstag noch.

Gruß, Ashura

[Fabian Transchel]

Hallo Ashura,

So sollte es auch normalerweise sein und momentan läuft meine Verbindung auch wirklich über eth1, an dessen Adapter das Netzwerkkabel angeschlossen ist. Beim nächsten Start dürfte es aber schon wieder eth0 sein.

Fehlen noch irgend welche Informationen meinerseits?

IMHO nein. Versuche einmal die entsprechenden Treiber als module zu bauen und dann in der  /etc/modules.autoload/kernel-2.6 (das ist bei mir unter gentoo die Datei) einzutragen, sodass die sis zuerst geladen wird.

Grüße aus Barsinghausen,
Fabian

[Ashura]

Hallo Fabian.

Versuche einmal die entsprechenden Treiber als module zu bauen

Die Treiber liegen doch schon als Module vor?
Warum sollte ich sie extra noch einmal bauen?

und dann in der  /etc/modules.autoload/kernel-2.6 (das ist bei mir unter gentoo die Datei) einzutragen, sodass die sis zuerst geladen wird.

Wie erwartet gibt es bei mir weder dieses Verzeichnis noch die Datei.
Aber ich werde einmal versuchen, sis900 in die von Axel erwähnte /etc/modules-Datei einzutragen und prüfen, ob dieser Adapter danach immer eth0 zugewiesen bekommt.

Einen schönen Samstag noch.

Gruß, Ashura

[Ashura]

Hallo Ingrid.

Die Treiber liegen doch schon als Module vor?

Um genau zu sein liegen diese unter „/lib/modules/2.6.12-1-k7/kernel/drivers/net/“.

Aber ich werde einmal versuchen, sis900 in die von Axel erwähnte /etc/modules-Datei einzutragen und prüfen, ob dieser Adapter danach immer eth0 zugewiesen bekommt.

Das hat genau das Gegenteil bewirkt. Nun wurden zuallererst die Module für die beiden Realtek-Adapter und danach das Modul für den onboard-Adapter geladen. Das Resultat: letzterer ist nun eth2. Die Datei /etc/modules ist im Übrigen offenbar funktional mit der /etc/modules.autoload[.d]/kernel-2.6 identisch. Zumindest deuten die Beschreibungen darauf hin.

Einen schönen Samstag noch.

Gruß, Ashura

[Ashura]

Hallo Ingrid nochmal.

Um genau zu sein liegen diese unter „/lib/modules/2.6.12-1-k7/kernel/drivers/net/“.

Wenn drei Zeilen ausgegeben werden, müssen diese nicht identisch sein.
Die Module liegen unter „/lib/modules/2.6.16-1-k7/kernel/drivers/net/sis900.ko“.

Einen schönen Samstag noch.

Ashura, der hofft, nicht noch einmal Ingrid belasten zu müssen.

[Axel Richter]

Hallo,

Hm, ich habe mir eben noch einmal die Ausgabe von lsmod angeschaut:

mii                     5248  3 8139too,8139cp,sis900

Weshalb wurden hier zwei identischen Adaptern zwei verschiedene Module zugewiesen?

Ja, das frage ich mich auch, wo doch dmesg eindeutig das zweimalige Scheitern von 8139cp dokumentiert.

Wenn das bei Dir zutrifft, dann werden die Treibermodule bei Dir offensichtlich nicht automatisch beim Systemstart geladen?

Doch, davon gehe ich aus. Andernfalls könnte ich sie nicht nutzen.
Gibt es andere Orte, an denen die Ladereihenfolge von dieser Module festgelegt werden kann?

Meiner Meinung nach nicht, wobei ich mich frage, warum die überhaupt geladen werden, wenn sie da nicht drinstehen. So ein Debian-Kenner bin ich allerdings auch nicht.

Soweit ich weiß, gibt es bei Debian ein Script "modconf". Eventuell probierst Du es man damit.

viele Grüße

Axel

[Ashura]

Hallo Axel.

Meiner Meinung nach nicht, wobei ich mich frage, warum die überhaupt geladen werden, wenn sie da nicht drinstehen.

Also werden zur Verfügung stehende Module normalerweise nicht automatisch in den Kernel geladen, wenn ein entsprechendes Gerät vorgefunden wurde? Hat bei alledem vielleicht udev seine Finger im Spiel?

Soweit ich weiß, gibt es bei Debian ein Script "modconf". Eventuell probierst Du es man damit.

Ich habe dieses nun einmal installiert. Es bietet mir lediglich die Möglichkeit, Module zu installieren und kennzeichnet die Ethernet-Module korrekt als installiert. Eine Reihenfolge kann ich auch hier leider nicht festlegen.

Einen schönen Sonntag noch.

Gruß, Ashura

[Axel Richter]

Hallo,

Meiner Meinung nach nicht, wobei ich mich frage, warum die überhaupt geladen werden, wenn sie da nicht drinstehen.

Also werden zur Verfügung stehende Module normalerweise nicht automatisch in den Kernel geladen, wenn ein entsprechendes Gerät vorgefunden wurde?

Doch, nur nach einer anderen Methode.

Hat bei alledem vielleicht udev seine Finger im Spiel?

Ja oder hotplug.

Eventuell hilft Dir dieser Thread http://lists.debian.org/debian-user-german/2006/02/thrd3.html#0134.

Der Fragesteller dort hat es am Ende mit einem Startscript gelöst, in dem er die Module erst wieder entläd, um sie dann in der richtigen Reihenfolge wieder zu laden.

viele Grüße

Axel

[Axel Richter]

Hallo,

Eventuell hilft Dir dieser Thread

Nein, dieser:
http://lists.debian.org/debian-user-german/2006/02/thrd3.html#01340

viele Grüße

Axel

[Ashura]

Hallo Axel.

http://lists.debian.org/debian-user-german/2006/02/thrd3.html#01340

In diesem Thread werden einige Möglichkeiten genannt, welche mir aber nicht weiter helfen.
Ich habe nun eth0 komplett in /etc/network/interfaces auskommentiert, womit eth1 nun das einzige ist, was geladen wird. Dies funktioniert soweit auch, d. h. pppoe -I eth1 -A liefert bei jedem Systemneustart einen erfolgreichen Paketaustausch.
Einziges Problem nun: pon wird nicht mehr automatisch beim Boot ausgeführt, womit also nicht mehr automatisch eine Verbindung aufgebaut wird.

Vielleicht finde ich hierfür noch eine Lösung, momentan habe ich erst einmal genug.

Ich bedanke mich bei dir und Fabian und wünsche noch einen schönen Sonntag.

Gruß, Ashura