Lantreiber trotz Blacklist geladen?

Dieses Thema im Forum "Internet, lokale Netzwerke und Wireless Lan" wurde erstellt von daboss, 26.08.2008.

  1. daboss

    daboss Keine Macht für niemand!

    Dabei seit:
    05.01.2007
    Beiträge:
    1.294
    Zustimmungen:
    0
    Ort:
    sydney.australia.world
    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
    Code:
    $ 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
    Code:
    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
    Code:
    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).

    Code:
    $ cat /etc/modprobe.d/blacklist-network
    blacklist r8169
    
    Code:
    $ 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
    
    Code:
    $ 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 :hilfe2: dankbar!
     
  2. Anzeige

    Schau dir mal diese Kategorie an. Dort findest du bestimmt etwas.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. Gast1

    Gast1 Guest

    Ü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.
     
  4. daboss

    daboss Keine Macht für niemand!

    Dabei seit:
    05.01.2007
    Beiträge:
    1.294
    Zustimmungen:
    0
    Ort:
    sydney.australia.world
    Okay, werd' ich heut Abend mal checken... Danke für die Antwort ;)
     
  5. #4 Der_Da_93, 27.08.2008
    Der_Da_93

    Der_Da_93 irgendwie

    Dabei seit:
    01.06.2007
    Beiträge:
    152
    Zustimmungen:
    0
    Ort:
    127.0.0.1
    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 :
    Code:
    r8169                  27396  0 
    
    Schöne Grüße aus dem sonnigen Italien...
     
  6. daboss

    daboss Keine Macht für niemand!

    Dabei seit:
    05.01.2007
    Beiträge:
    1.294
    Zustimmungen:
    0
    Ort:
    sydney.australia.world
    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.
     
  7. karru

    karru OSX'ler

    Dabei seit:
    02.05.2006
    Beiträge:
    338
    Zustimmungen:
    0
    Blöde Frage aber hast du sudo update-initramfs -u ausgeführt?
     
  8. daboss

    daboss Keine Macht für niemand!

    Dabei seit:
    05.01.2007
    Beiträge:
    1.294
    Zustimmungen:
    0
    Ort:
    sydney.australia.world
    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))
     
  9. #8 Der_Da_93, 27.08.2008
    Der_Da_93

    Der_Da_93 irgendwie

    Dabei seit:
    01.06.2007
    Beiträge:
    152
    Zustimmungen:
    0
    Ort:
    127.0.0.1
    Ah, Ok, ich hab 2.6.26.
     
  10. Gast1

    Gast1 Guest

    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.)
     
  11. Anzeige

    Vielleicht findest du HIER Antworten.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  12. daboss

    daboss Keine Macht für niemand!

    Dabei seit:
    05.01.2007
    Beiträge:
    1.294
    Zustimmungen:
    0
    Ort:
    sydney.australia.world
    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:
    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. :rolleyes:
     
  13. Gast1

    Gast1 Guest

    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.)
     
Thema:

Lantreiber trotz Blacklist geladen?

Die Seite wird geladen...

Lantreiber trotz Blacklist geladen? - Ähnliche Themen

  1. Stagefright für Android trotz Patch weiterhin gefährlich

    Stagefright für Android trotz Patch weiterhin gefährlich: Die kürzlich Furore machende Sicherheitslücke Stagefright ist inzwischen repariert und viele Smartphones haben den Patchset bereits erhalten....
  2. LTO-4 SAS Laufwerk immer stop & go trotz schnellem Raid 0 asl Quelle

    LTO-4 SAS Laufwerk immer stop & go trotz schnellem Raid 0 asl Quelle: Hallo zusammen, ich bin neu hier im Forum. Ich habe einige Tage mit diversen Google-Suchen zu diesem Problem beschäftigt und einiges...
  3. Trotz Win7 DNS-Regfix kein Join in die Domäne möglich

    Trotz Win7 DNS-Regfix kein Join in die Domäne möglich: Hallo! ich bin bald am Verzweifeln! Vor 2 Wochen einen anderen Rechner auf die selbe Art und weise Installiert und jetz gehts nicht mehr......
  4. gcc meldet Error trotz vorhandenem Header in FreeBSD

    gcc meldet Error trotz vorhandenem Header in FreeBSD: Hallo, Ich habe das Problem ,daß ich mit der X.h header Datei arbeiten möchte, aber gcc findet sie nicht, obwohl sie da ist. Nachgeguckt habe...
  5. Rechte fehlen trotz Freigabe

    Rechte fehlen trotz Freigabe: Ich habe folgendes Problem, wir haben einen OpenSuse 11.3 Server mit Samba 3.6.7 und ca. 10 Windowsclienten trotz folgender Einstellung schaffen...