Lantreiber trotz Blacklist geladen?

[daboss]

Hi,

ich habe bei meinem Laptop (Vostro 1510 von Dell) das Problem, das das Lan eher sporadisch als zuverlässig arbeitet.

Der Chip ist ein

$ lspci | grep -i real
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

Laut google soll es zum einen helfen, den Parameter

pci=nomsi

beim Starten zu übergeben. Danach gings auch erstmal halbwegs für zwei drei Tage. Sprich: Bei jedem Laptopstart bekam ich auch eine Verbindung ins (DHCP-)Lan.

Aber seit gestern braucht's wieder x Neustarts dafür. Also habe ich die Anleitung hier ausprobiert. (Kurz zusammengefasst: Statt dem standardmäßig geladenem Modul r8169 den Treiber direkt von Realtek holen, kompilieren und das Modul r8168 laden und r8169 mittel

sudo sh -c 'echo "blacklist r8169" >> /etc/modprobe.d/blacklist-network'

blacklisten. Den r8168 habe ich in die /etc/modules mit aufgenommen. Allerdings werden jetzt immer beide Module geladen (und das Lan zickt immer noch rum).

$ cat /etc/modprobe.d/blacklist-network
blacklist r8169

$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

fuse
lp
sbp2
r8168

$ lsmod | grep r8
r8168                  36752  0 
r8169                  32900  0

Hat jemand nen Tipp für mich, wie ich "wirklich" verhindern kann, das der r8169 geladen wird? Irgendwie scheint der Blacklisteintrag ja ignoriert zu werden Bin für jede dankbar!

 

[Gast1]

Überprüfe mal, ob der Treiber nicht über die initrd geladen wird.

Ansonsten verhindert "Blacklisten" nur das automatische Laden, sollten also udev-Regeln bzw. Einträge für r8169 in den Initscripten o.ä. existieren, dann nutzt das Blacklisten nichts.

Hier dürfte "grep" nützlich sein.

Sollte *Buntu linuxrc unterstützen, dann kann auch ein "brokenmodules"-Bootparameter in Betracht gezogen werden.

 

[daboss]

Okay, werd' ich heut Abend mal checken... Danke für die Antwort

 

[Der_Da_93]

Also ich hab ein Vostro 1310, mit Archlinux.
Bei mir läuft der selbe Chip, soweit ich es testen konnte, problemlos.
Allerdings benutze ich LAN nur relativ selten bzw. das Notebook ist noch sehr neu.
Momentan kann ich es nichteinmal testen, da ich mich grad aus dem Urlaub über ne buggy WLAN-Verbindung melde.
Aber falls ich irgendwelche Informationen liefern kann, werde ich sie gerne posten.
Also lsmod listet bei mir ganz regulär :

r8169                  27396  0

Schöne Grüße aus dem sonnigen Italien...

 

[daboss]

Ja, wie gesagt, der r8169 lädt bei mir auch. Aber den will ich ja eben nicht mehr haben, der oben beschriebenen Probleme wegen.

Und da im Netz bei diesem Fehlerbild (zum. bei dem NB) dazu eben öfters so was zu lesen ist, wie in den o.a. Link:

As the built-in network card currently doesn’t work with the r8169 driver in 2.6.24 kernel, you’ll have to built the r8168 driver provided by Realtek

will ich das eben jetzt (bzw. erst wieder heut Abend nach der Arbeit) ausprobieren.

 

[karru]

Blöde Frage aber hast du sudo update-initramfs -u ausgeführt?

 

[daboss]

Ja

/Edit: Und vorher halt den "alten" Treiber entladen und den neuen geladen... Halt alles genau so, wie's in obigem Link steht. (Bis auf das Patchen, das soll in der Version, die mitlerweile bei Realtek zum download angeboten wird, nicht mehr nötig sein - und ging auch nicht mehr fehlerlos (Genaues "nicht mehr fehlerlos" hab ich gerade nicht zur Verfügung))

 

[Der_Da_93]

Ja, wie gesagt, der r8169 lädt bei mir auch. Aber den will ich ja eben nicht mehr haben, der oben beschriebenen Probleme wegen.

Und da im Netz bei diesem Fehlerbild (zum. bei dem NB) dazu eben öfters so was zu lesen ist, wie in den o.a. Link:

will ich das eben jetzt (bzw. erst wieder heut Abend nach der Arbeit) ausprobieren.

Ah, Ok, ich hab 2.6.26.

 

[Gast1]

Im schlimmsten Fall hilft die "Radikalmethode".

Modul r8169.ko verschieben/löschen und einmal depmod ausführen.

(Das Spielchen darf man dann wie auch das händische Kompilieren/installieren des externen Treibers nach jedem Kernelupdate wiederholen.)

 

[daboss]

Naja, die "Radikalmethode" hab ich jetzt mal angewandt. Mal schauen, ob's jetzt wirklich mal "zuverlässig" wird. Immerhin wird jetzt, so wie es sein soll, nur noch der r8169 geladen.

Und ich hab den "älteren" mal hergenommen, also nicht den, den Realtek "aktuell" anbietet, sondern den, der in der Beschreibung verwendet worden ist...




Da drauf:

Das Spielchen darf man dann wie auch das händische Kompilieren/installieren des externen Treibers nach jedem Kernelupdate wiederholen.)

freu ich mich jetzt schon ^^ zumal ich sowas regelmäßig vergess (beim lanchip vom alten desktop, bei der alten graka...) und mich immer erst wunder/ärger, wieso auf einmal nix mehr geht.

 

[Gast1]

Kernelupdates und "Warum einfach, wenns auch kompliziert geht"?

Es soll auch Distributionen geben (Ich nenne jetzt keine Namen .... ), bei denen extern gebaute Kernelmodule ein Kernelupdate innerhalb einer minor-Version (2.6.X) "überleben"*, den Rest erledigen dann die "module-init-tools".

Das Prinzip dahinter ist dann auch noch denkbar einfach, wenn man die extern gebauten Kernelmodule nur ins "richtige" Verzeichnis installieren lässt, namentlich in das Verzeichnis "/lib/modules/*Kernelversion*/updates".

(BTW: Für händisch gebaute Module funktioniert das übrigens bei einer der nicht genannten Distributionen witzigerweise auch ohne spezielles Kernelmodul-Paket, wenn man das/die fertige(n) Modul(e) nach /lib/modules/*Kernelversion*/updates installiert.)

Der "Update-Mechanismus" ist dabei denkbar einfach, ein "Postinstall"-Script des neuen Kernelpaketes setzt für alle Module in /lib/modules/*alte-Kernelversion*/updates Symlinks nach /lib/modules/*neue-Kernelversion*/weak-updates/ und fertig ist die Laube.

Die module-init-tools sorgend dafür (das gilt im Übrigen distributionsübergreifend!), daß Module aus den beiden "update"-Verzeichnissen bevorzugt geladen werden (bei Modulen selben Namens, falls z.B. das im Kernel befindliche Modul einen Bug hat bzw. das extern gebaute Modul im Update-Verzeichnis eine HW unterstützt, die das interne Modul noch nicht kennt, Stichwort "Backport").

Simpel und zuverlässig, einmal externes Modul installieren und bis zum nächsten Distributionsupdate (Ausnahme, siehe *) hat man keinen Ärger mehr, wieso das die meisten Distributionen mit "stabilen" Releases (= innerhalb einer Version gibt es i.d.R. keine Kernelupdates auf eine andere Minor-Version 2,6.x auf 2.6.y) nicht genau so machen, ist mir ehrlicherweise ein Rätsel.

Greetz,

RM

(*Sofern keine ABI-Änderungen innerhalb einer minor-Version vorgenommen wird, was jedoch bei "stable"-Kerneln der absolute Ausnahmefall ist, allerdings ist das z.B. bei 2.6.22 geschehen und betraf natürlich alle Distributionen, die diesen Kernel verwendeten, also z.B. *Buntu 7.10 und openSUSE 10.3, siehe z.B: hier.)