Netzwerk Ordnung
Jan 'RedBully' Seiffert
redbully at cc.fh-luh.de
Sat Jan 14 04:21:41 CET 2006
Joern Muehlencord wrote:
> Hallo zusammen,
>
> ich habe ein Problem mit meinem Netzwerk - irgendwie verdrehen sich die
> Netzwerkkarte nach Lust und Laune. Wenn alles glatt geht, dann ist eth0
> das interne Netzwerk (Yukon, modul skge) und eth1 das DSL interface
> (Nvidia nforce, forcedeth oder nvnet). Mit schöner Regelmässigkeit
> kommen die beiden Interfaces aber verdreht hoch - d.h. DSL = eth0,
> intern = eth1. Dann passen natürlich alle Einstellungen nicht mehr
> (pppd, samba, postfix, ...). Also muss ich die beiden Module entladen
> und modprobe und ifup in der richten Reihenfolge aufrufen, alle Netzwerk
> basierten Dienste neustarten und dann passt es wieder.
>
> Kann man dem System das ganze auch noch abgewöhnen? Nervt ein wenig.
>
Ja, das nervt wirklich, ich wuerde da durchdrehen ;)
Nun, du bist da wohl Opfer einer klasischen Race-Condition. Der
zeitliche ablauf des Ladevorgangs bestimmt, wer welches eth bekommt.
Da kann man in dem Fall nicht viel dran tun, ausser work-arounds.
1) Ich habe hier mit einkompilierten Treibern keine Probleme, sie werden
anscheinend in der Reihenfolge wie der Kernel sie in der PCI-Config
findet initialisiert. Also beide einkompilieren.
2) Ein Treiber einkompilieren, den anderen als Modul, sie sollten nun
immer die gleiche Reihenfolge haben.
3) Ein Modul in der module-autoloads, einer ueber Hotplugging (bei mir
heisst das mitlerweile Coldplugging, schaut beim Booten halt was hamma
denn fuer Geraete (quasi lspci & lspnp) und laedt dann Treiber dafuer,
und das wichtigste, wird nach der autoloads ausgefuehrt (zumindest bei mir))
4) Es gibt dafuer noch einen speziellen Knopf, der mir unbekannt ist.
Moment, wo ichs sage, konnte man Devices nicht umbennen? (mit ip(8) aus
dem iproute2 Packet?)
2 & 3 baut darauf, das laden zeitlich so zu trennen, das der eine
Treiber (hoffentlich) ein eth allozieiert hat, wenn der andere erst
anfaengt.
Bei Modulen bietet sich auch keine richtige Loesung an (ausser in einem
Startscript die modprobes definiert nacheinander absetzen mit sleep x
dazwischen -> bandaid).
Nach einem oberflaechlichen blick in den Source laufen das Laden (die
initfunktion, darauf blockt modprobe) eines PCI-Treibers (und sicher
auch anderer Busse) und der eigentliche Hardwaretest asynchron ab. In
der initfunktion werden nur die PCI-IDs regestriert, aus einer Workqueue
(quasi ein Helperthread) werden dann die Probe-funktionen aufgerufen.
Also da ist nix zu fixen (und das ist auch eigentlich gut so wie es ist).
[snip config]
> Gruß
> Jörn
>
Gruss
Jan
--
Thema Dudelfunk:
"Die industrielle Optimierung des Ohrfutters erinnert an die
Massentierhaltung. Die Schweine in den Boxen nehmen's grunzend hin, und
solange im Stall niemand plötzlich das Licht anmacht, fällt auch keines
tot um."
<http://www.zeit.de/2005/09/RettetdasRadio?page=4>
More information about the Linux
mailing list