Es wurden doch neue Einträge erstellt. Siehe meinen letzten Beitrag. Aber merkwürdigerweise gibt mir dmesg keine Meldungen mehr zu den Karten aus, wie zuvor. Darüberhinaus werden die Module beim Neustart nicht geladen, auch dann nicht wenn ich sie wieder in die /etc/initramfs-tools/modules eintrage.
Interfaces bekommen keine Bezeichnung zugeordnet
(Themenstarter)
Anmeldungsdatum: Beiträge: 222 |
|
Anmeldungsdatum: Beiträge: 29307 Wohnort: NRW |
Pardon, da hatte ich nicht weit genug herunter gescrollt.
Ist doch ok.
Entferne die Einträge. Nutze stattdessen rc.local um die Module in der gewünschten Reihenfolge zu laden. In der Datei sollten sich momentan keine Einträge bfinden. Prüfe vorab, der Befehl überschreibt den vorhandenen Inhalt! echo -e "/sbin/modprobe r8168 && /sbin/modprobe r8169\nexit 0" | sudo tee /etc/rc.local Edit: Befehl korrigiert. Bereinige noch die 70-persistent-net.rules, also alle alten Einträge einfach löschen und nur die neu erzeugten beibehalten. Die Reihenfolge kann angepasst werden. # PCI device 0x10ec:0x8168 (r8168) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="74:d4:35:80:0f:20", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x10ec:0x8168 (r8168) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c4:6e:1f:00:aa:0c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" # PCI device 0x10ec:0x8168 (r8168) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:94:f6:08:6a:c4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" # PCI device 0x10ec:0x8168 (r8168) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:94:f6:08:4d:f1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" # PCI device 0x10ec:0x8169 (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:de:27:a8:89:ac", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4" # PCI device 0x10ec:0x8169 (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:de:27:a8:8b:8a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5" Nun muss wahrscheinlich nur noch die interfaces entsprechend angepasst werden. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 222 |
Ok, soweit so gut, scheint so, als läuft nun alles... Aber, die Netzwerkkonfiguration beim starten dauert ewigkeiten, ca. 2-3 Minuten. Woran liegt das nun? Ich hab nun auch die Einstellungen für den Bond wieder in die interfaces eingetragen, aber der Bond funktioniert nicht. Hier nochmal die interfaces, die Einstellungen für den Bond sind auf Desktop und Server gleich, bis auf die Adresse natürlich. # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static # metric 100 address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 pre-down /usr/sbin/ethtool -s eth0 wol g auto eth1 iface eth1 inet manual bond-master bond0 bond-primary eth1 auto eth2 iface eth2 inet manual bond-master bond0 auto eth3 iface eth3 inet manual bond-master bond0 auto eth4 iface eth4 inet manual bond-master bond0 auto bond0 iface bond0 inet static address 10.0.0.11 netmask 255.255.255.0 mtu 9000 network 10.0.0.0 broadcast 10.0.0.255 # gateway 10.0.0.1 bond-slaves none bond-mode 0 bond-miimon 100 bond-lacp-rate 1 # bond-updelay 200 # bond-downdelay 200 #auto eth5 #iface eth5 inet static # metric 200 # address 192.168.178.99 # netmask 255.255.255.0 # gateway 192.168.178.1 # network 192.168.178.0 # broadcast 192.168.178.255 # dns-nameserver 192.168.178.1 Zwar ist laut dieser Ausgabe alles ok, aber ich kann weder per SSH auf den Server (10.0.0.11) zugreifen noch auf meine Sambafreigaben. cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: load balancing (round-robin) MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth2 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 1 Permanent HW addr: e8:94:f6:08:5d:57 Slave queue ID: 0 Slave Interface: eth4 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 1 Permanent HW addr: c4:6e:1f:00:73:7a Slave queue ID: 0 Slave Interface: eth3 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 1 Permanent HW addr: c4:6e:1f:00:8b:be Slave queue ID: 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 1 Permanent HW addr: e8:94:f6:08:5d:52 Slave queue ID: 0 |
Anmeldungsdatum: Beiträge: 29307 Wohnort: NRW |
Wenn der Bootvorgang so lange dauert, liegt es bestimmt an der Konfiguration der interfaces.. Zunächst mal mit den Grundeinstellungen ändern: auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 pre-down /usr/sbin/ethtool -s eth0 wol g auto bond0 iface bond0 inet static address 10.0.0.11 netmask 255.255.255.0 network 10.0.0.0 broadcast 10.0.0.255 bond-slaves eth1 eth2 eth3 eth4 bond-mode 0 bond-miimon 100 bond-updelay 200 bond-downdelay 200 Dann fehlt auch noch ein DNS-Eintrag ( dns-nameservers ... ) |
(Themenstarter)
Anmeldungsdatum: Beiträge: 222 |
Die von dir vorgeschlagene Konfiguration fürs Bonding hat bei mir noch nie funktioniert. Wenn kein Nameserver angegeben ist, dann wird doch automatisch das Gateway genutzt...soweit mir bekannt. |
Anmeldungsdatum: Beiträge: 29307 Wohnort: NRW |
Dazu kann ich nichts konkreteres sagen, da fehlt mir die praktische Erfahrung. Grundsätzlich würde ich dann entsprechende Einträge erstmal auskommentieren und das Netzwerk neu starten und die Einstellungen kontrollieren. Dann einzelne Einträge wieder aktivieren, Netzwerk wieder neu starten usw. - Fehler werden dann ja im Terminal angezeigt, wie lange die Konfiguration dauert läßt sich ebenfalls einschätzen. Möglicherweise hat die Verzögerung ja einen ganz anderen Grund. sudo /etc/init.d/networking restart
Da musst Du mal schauen, was in der /etc/resolv.conf eingetragen wird/ist. Momentan fehlt wahrscheinlich ein entsprechender Eintrag. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 222 |
Also ich hab nun schon diverse Dinge versucht. Auch hab ich die interfaces so kurz wie möglich gehalten, selbst wenn nur die ersten beiden Zeilen drin stehen, tritt das Problem auf... Im Internet konnte ich bisher auch nichts hilfreiches finden. Da wird bei diesem Problem oft dazu geraten die /etc/init/failsafe.conf zu bearbeiten und die Wartezeiten zu verkürzen...aber das löst ja nicht das eigentlich Problem. Der Bond funktioniert ja auch noch immer nicht, also muss es ja irgendetwas damit zutun haben. In der resolv.conf steht übrigens die Adresse des Gateways, also das haut schonmal hin. |
Anmeldungsdatum: Beiträge: 29307 Wohnort: NRW |
Ok, entlade r8168 und r8169 und lade zunächst nur r8169 erneut, möglicherweise kommt es doch zu einem Treiberkonflikt. Das kann ich aber nur vermuten. Wenn dem so ist, würde ich den systeminternen r8169 probeweise durch den Treiber v6.019 von Realtek ersetzen. Dieser unterstützt nur r8169-basierende Karten. Ein Konflikt mit dem manuell gebauten r8168 ließe sich so umgehen. modinfo r8169.ko filename: /home/rainer/Downloads/r8169-6.019.00/r8169/src/r8169.ko version: 6.019.00-NAPI license: GPL srcversion: 2A8AD2D745679FFC77CF2DF alias: pci:v00001186d00004300sv00001186sd00004C00bc*sc*i* alias: pci:v000010ECd00008169sv*sd*bc*sc*i* alias: pci:v000010ECd00008167sv*sd*bc*sc*i* depends: vermagic: 3.13.0-45-generic SMP mod_unload modversions parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int) parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int) parm: debug:Debug verbosity level (0=none, ..., 16=all) (int) |
(Themenstarter)
Anmeldungsdatum: Beiträge: 222 |
Tatsache, da scheint was im Argen zu sein. Ich hab beide entladen und dann nur den r8169 geladen und n paar Sekunden später konnte ich per SSH auf 10.0.0.11 zugreifen und auch ein Test mit iperf funktionierte nun. |
Anmeldungsdatum: Beiträge: 29307 Wohnort: NRW |
Dann dürften ja nur zwei Schnittstellen vorhanden gewesen sein, oder doch alle? Möglicherweise laufen jetzt alle Karten einwandfrei mit dem r8169-Modul!? Ich hatte meinen vorhergehenden Beitrag überarbeitet. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 222 |
Ne, alle, deine Bearbeitung hatte ich noch nich gesehen. |
Anmeldungsdatum: Beiträge: 29307 Wohnort: NRW |
Dann prüfe bitte mal welche Karten mit dem r8169 aktuell funktionieren. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 222 |
Natürlich alle. Das war ja auch nie anders. Nur hatte ich in der Vergangenheit Stabilitätsprobleme mit dem r8169 Treiber, da kam es hin und wieder zu Timeouts beim Bond. |
Anmeldungsdatum: Beiträge: 29307 Wohnort: NRW |
Selbstverständlich ist das nicht. Manchmal funktionieren die r8168-Karten überhaupt nicht mit dem r8169 Modul. Dann teste doch einfach die Stabilität. Ansonsten würde ich, wie zuvor vorgeschlagen, den r8169 von Realtek installieren und zusammen mit der r8186 testen. Eine andere Möglichkeit sehe ich nicht mehr. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 222 |
Einen wesentlichen Unterschied sehe ich jetzt schonmal. Die Übertragungsrate liegt laut iperf bei 3,81GBit/s. Mit den r8168 Treibern lag sie bei 3,91GBit/s. Das zeigt ja schon, dass die Treiber nicht ganz optimal sind. Ich werde mal versuchen den r8169 von Realtek zu nehmen. |