openSUSE 11.4 (x86_64) - Realtek Onboard NIC schafft keinen Link nach dem Booten

Deutsch (German) Netzwerk
#1

Moin,

seit einiger Zeit (wenige Wochen?), geht mein Netzwerk nicht mehr auf Anhieb, wenn ich meinen Rechner boote. Ich komme dann schon nicht per ping auf meinen Router.
Ein “rcnetwork restart” löst das Problem immer. Es ist aber ziemlich lästig, sich erst einmal einloggen und das Netzwerk neu starten zu müssen.
Leider kann ich nicht mehr sagen, seit wann das passiert. Ich habe im Verdacht, dass irgendein Update schuld ist (mache ich täglich), kann das aber jetzt nicht mehr so recht nachvollziehen.

Hat irgendjemand eine Idee, woran es liegt, dass mein Netzwerk erst nach einem manuellen Restart zuverlässig funktioniert und was ich machen kann, dass das wieder automatisch geht?

Hier einige Infos zum System.

Auszug aus /var/log/messages, wenn es nicht geht:


Mar 11 11:46:20 vetinari ifup:     lo        
Mar 11 11:46:20 vetinari ifup:     lo        
Mar 11 11:46:20 vetinari ifup: IP address: 127.0.0.1/8  
Mar 11 11:46:20 vetinari ifup:  
Mar 11 11:46:20 vetinari ifup:               
Mar 11 11:46:20 vetinari ifup: IP address: 127.0.0.2/8  
Mar 11 11:46:20 vetinari ifup:  
Mar 11 11:46:21 vetinari ifup:     eth0      device: Realtek Semiconductor Co., Ltd. RTL8111/8168B
Mar 11 11:46:21 vetinari kernel:    12.143582] r8169 0000:05:00.0: eth0: link down
**Mar 11 11:46:21 vetinari kernel:    12.143819] ADDRCONF(NETDEV_UP): eth0: link is not ready**
Mar 11 11:46:21 vetinari ifup:     eth0      
Mar 11 11:46:21 vetinari ifup: IP address: 192.168.1.93/24  
Mar 11 11:46:21 vetinari ifup:  
Mar 11 11:46:21 vetinari kernel: Kernel logging (proc) stopped.

Auszug aus /var/log/messages, nach dem Restart des Netzwerk-Subsystems:


Mar 11 11:48:45 vetinari kernel:   156.366645] lo: Disabled Privacy Extensions
Mar 11 11:48:46 vetinari kernel:   157.174949] fuse init (API version 7.15)
Mar 11 11:48:54 vetinari dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched...
Mar 11 11:48:54 vetinari dns-resolver: You can find my version in /etc/resolv.conf.netconfig
Mar 11 11:48:54 vetinari ifdown:     eth0      device: Realtek Semiconductor Co., Ltd. RTL8111/8168B
Mar 11 11:48:56 vetinari ifup:     eth0      device: Realtek Semiconductor Co., Ltd. RTL8111/8168B
Mar 11 11:48:56 vetinari kernel:   166.895971] r8169 0000:05:00.0: eth0: link up
Mar 11 11:48:56 vetinari ifup:     eth0      
Mar 11 11:48:56 vetinari ifup: IP address: 192.168.1.93/24  
Mar 11 11:48:56 vetinari ifup:

Ausgabe von “uname -a”


Linux vetinari 2.6.37.6-0.11-desktop #1 SMP PREEMPT 2011-12-19 23:39:38 +0100 x86_64 x86_64 x86_64 GNU/Linux

Auszug von “/sbin/lspci -nnk”


05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03)
        Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard [1043:83a3]
        Kernel driver in use: r8169

Ausgabe von “rpm -qa ‘"kernel*’”


kernel-desktop-devel-2.6.37.6-0.11.1.x86_64
kernel-devel-2.6.37.6-0.11.1.noarch
kernel-firmware-2.6.38-1.2.1.noarch
kernel-source-2.6.37.6-0.11.1.noarch
kernel-desktop-2.6.37.6-0.11.1.x86_64
#2

Verbindest Du Dich per dhcp oder fester IP?

Was sagt:

cat /etc/hosts

cat /etc/resolv.conf
#3

Ich verwende eine feste IP für den Rechner

cat /etc/hosts


127.0.0.1       localhost
::1             localhost ipv6-localhost ipv6-loopback
fe00::0         ipv6-localnet
ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts
127.0.0.2       vetinari.site vetinari
192.168.1.93    vetinari.site vetinari
192.168.1.96    brack.site brack
192.168.1.93    vetinari.site vetinari

cat /etc/resolv.conf (hab ich manuell angepasst, weil Hansenet/Alice/O2 zeitweise ziemlich instabile DNS Server hatte)


nameserver 8.8.8.8
nameserver 213.191.92.87
nameserver 95.185.185.195

route -n


Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Wobei das jetzt gerade der Zustand ist, wenn es wieder geht

#4

Hi,

interessant ist noch die grundlegende interface-Konfiguration.
Gib mal bitte

/etc/sysconfig/network/ifcfg-eth0
#5

Eine Idee habe ich.

Ich würde mal vermuten, dass Dein Rechner ein falsches Kernelmodul/einen falschen Treiber benutzt, weil der richtige nicht (richtig) gebaut wurde, vergleiche zu anderen Distributionen mit Kerneln ähnlichen Alters:

realtek-dropping-packets-on-linux-ubuntu-and-fedora - foxhop.net
Linux Mint Forums • View topic - How to Guide - Realtek RTL8111/8168B

Daher könntest Du mal versuchen, für den Kernel, den Du gerade benutzt, ein zur Versionsnummer des benutzen Kernels (zum Beispiel 2.6.37.6-0.11) und dessen Kernelflavor (zum Beispiel: desktop) passendes Kernelmodul zu suchen:
software.opensuse.org: Suchergebnisse

Dies wäre in Deinem Fall dann wohl dieses Kernelmodul:

Dann (eventuell nach Herunter- und Herauffahren des Rechners?)
mal (wieder) mit

/sbin/lspci -nnk

und/oder

lsmod | grep r816*

nachschauen, welches Kernelmodul nun benutzt wird (und prüfen, ob die Verbindung nun besser ist).

Eventuell (hierzu gerne nochmals nachfragen) kannst Du dann noch versuchen, ob es nützt, wenn Du das falsche Kernelmodul (…9) dann manuell entlädst und das richtige (…8) manuell nachlädst. Sollte erst das nützen, solltest Du das …8er Kernelmodul blacklisten, damit Dein Rechner weiß, dass er es nicht laden soll.

Viel Glück und Erfolg

Martin

#6

Ok, hier noch die Konfigdatei /etc/sysconfig/network/ifcfg-eth0


BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.1.93/24'
MTU='1492'
NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
PREFIXLEN='24'

Ich hab jetzt das Paket “r8168-kmp-desktop-8.024.00_k2.6.37.6_0.11-1.7.x86_64” installiert und frisch gebootet:

/sbin/lspci -nnk


05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03)
        Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard [1043:83a3]
        Kernel driver in use: r8169

lsmod | grep r816*


r8168                 190697  0 
r8169                  43831  0

Nach dem ersten Boot mit dem neu installierten Kernel-Modul ging das Netz ohne manuellen Eingriff. Ich würde da aber noch keine Entwarnung geben, weil in den letzten Wochen ca. bei jedem 10. Boot das Netz dann doch auf Anhieb ging.

Ich beobachte das mal und gebe dann Rückmeldung. Schonmal vielen Dank bis hierhin.

#7

Am 19.03.2012 11:56, schrieb Brackmeister:

…]
>
> Ich hab jetzt das Paket
> “r8168-kmp-desktop-8.024.00_k2.6.37.6_0.11-1.7.x86_64” installiert und
> frisch gebootet:
>
> /sbin/lspci -nnk
>
> Code:
> --------------------
>
> 05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03)
> Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard [1043:83a3]
> Kernel driver in use: r8169
>
> --------------------

Dein System scheint noch immer das Kernelmodul/den Treiber mit der 9 zu
verwenden (obwohl das 8er-Kernelmodul offenbar vorhanden ist).

Versuche nun einmal mit root Rechten
(per substitute user, option: make the shell a login shell)
den 9er - erst einmal vorhergehend - zu ‘entladen’
(z. B. mit rmmod - “simple program to remove a module from the Linux
Kernel”)
und den neu eingespielten 8er zu laden
(mit modprobe - “program to add and remove modules from the Linux Kernel”):

Folgendes müsste dies bewirken:


su -
rmmod r8169
modprobe r8168

oder
Optionen ausgeschrieben und mit der Option für Gesprächigkeit auch wenn
alles funktioniert ("–verbose" entspricht kurz:"-v"):


su --login
rmmod --verbose r8169
modprobe --verbose r8168

Nach dem Verlassen der root-Shell mit exit müsste dann


/sbin/lspci -nnk

anzeigen, dass Dein System für die Netzwerkkarte aktuell r8168 (also das
Kernelmodul mit der Acht als letzte Zahl) als Treiber benutzt.

Sollte damit deine Netzwerkkarte funktionieren (besser oder zumindest
nicht schlechter), könntest Du dann versuchen, Deinem Kernel dauerhaft
zu verbieten, den den ‘falschen’ Treiber beim Booten zu laden. Dies
macht man, in dem man diesen Treiber ‘blacklistest’. Die entsprechende
schwarze List ist die Datei /etc/modprobe.d/50-blacklist.conf , für die
nur root Schreibrechte besitzt (aber der normale Benutzer kann sie auch
lesen). Zum Blacklisten muss man die Zeile
blacklist r8169
in dieser schwarzen Liste unten als letzte Zeile hinzugefügen
(Anleitungen folgen):

a)
Am schnellsten geht dies wohl auf der Kommandozeile:

Mit “su -” wieder eine Login-Shell für root öffnen und dann:


echo "blacklist r8169" >> /etc/modprobe.d/50-blacklist.conf

b) Die etwas graphischere Alternative diese Datei mit GNOME zu verändern
wäre folgende:


gnomesu gedit /etc/modprobe.d/50-blacklist.conf

root-Password eingeben
und dann die Zeile

blacklist r8169

als letze Zeile hinzufügen
und speichern.

c)
Alternativ müsste mit KDE (habe gerade kein KDE installiert) folgendes
funktionieren:


kdesu kwrite /etc/modprobe.d/50-blacklist.conf

root-Password eingeben
und dann die Zeile

blacklist r8169

als letze Zeile hinzufügen
und speichern.

Viel Glück!
Martin

–
…]
Fünfte Minute
Es gibt also Rechtsgrundsätze, die stärker sind als jede rechtliche
Satzung, so daß ein Gesetz, das ihnen widerspricht, der Geltung bar ist.
Man nennt diese Grundsätze das Naturrecht oder das Vernunftrecht. Gewiß
sind sie im Einzelnen von manchem Zweifel umgeben, aber die Arbeit der
Jahrhunderte hat doch einen festen Bestand herausgearbeitet, und in den
sogenannten Erklärungen der Menschen- und Bürgerrechte mit so
weitreichender Übereinstimmung gesammelt, daß in Hinsicht auf manche von
ihnen nur noch gewollte Skepsis den Zweifel aufrechterhalten kann…]
(Gustav Radbruch, Fünf Minuten Rechtsphilosophie, in:
Rhein-Neckar-Zeitung, 1945/09/12)
translated to English as: Five Minutes of Legal Philosophy (1945),
Oxford J Legal Studies (Spring 2006) 26 (1): 13-15. doi:
10.1093/ojls/gqi042

#8

Hallo Martin,

das Netzwerk läuft noch/wieder, nachdem ich beide Kernelmodule ent- und nur das r8168 wieder geladen habe.

Das r8169 Modul hab ich in die Blacklist eingetragen. Dann sehe ich morgen beim nächsten Booten, ob sich die Sache damit erledigt hat.

Danke :slight_smile:

#9

Hallo Brackmeister,

freut mich, falls ich Dir helfen konnte
(wird sich wohl noch herausstellen…:\ ).

Solltest Du daran interessiert sein,
an der Verbesserung des Kernelkodes und insbesondere des r8169 (siehe unten) mitzuarbeiten,
so wäre es schön, wenn Du Dich mal auf Bugzilla
bei
Bug 702205 - RTL8111/8168B hard locking and rebooting machines when under heavy load
https://bugzilla.novell.com/show_bug.cgi?id=702205
melden könntest
(auf Englisch - ich helfe ggf. gerne bei der Übersetzung).

Dort treiben sich diejenigen herum, die am Code oder zumindest deren Implementierung in openSUSE herumschreiben
und wohl auch von der Sache mehr davon verstehen als ich (als bloßer Jurist).

Ob das dann im selben Bugreport oder in einem eigenen besser wäre,
werden Dir hoffentlich die openSUSE-Kernelentwickler mitteilen…

Vergleiche:

https://bugzilla.novell.com/show_bug.cgi?id=702205#c7

(In reply to comment #7)
> (In reply to comment #6)
> > Compare:
> >
> > 1) In/against openSUSE 12.1:
> > [opensuse] Install help for Network driver
> > (Date: Wed, 14 Mar 2012 15:27:02 -0400)
> > http://lists.opensuse.org/opensuse/2012-03/msg00676.html
> > especially:
> > http://lists.opensuse.org/opensuse/2012-03/msg00765.html
>
> There is some confusion in that thread:
>
> > As suspected your software system uses a r8169 kernel module (…9)
> > but your hardware is a Realtek …] RTL8111/8168B [10ec:8168] (…8).
>
> Despite it’s name, the r8169 module is meant to drive cards based on the
> realtek 8168/8111 chips.
>
> The difference between the two modules is that:
> r8168 is a binary-only driver provided by realtek
> r8169 is a community-developped and supported driver
>
> While it is the case that r8168 usually supports newer chips first, the version
> of r8169 currently in openSUSE 12.1 supports all the chips I’ve seen in
> circulation so far. IMO, steering users towards r8168 is ill-advised as it will
> be extremely difficult to find some developpers willing and able to provide
> support for it.
>
> Secondly, lspci output is insufficient to determine the chip version as many of
> them share a small set of pci ids. A first step in identifying the chip version
> is the (masked) XID line found in the kernel logs as pointed out at the end of
> comment 4. The chip version is identified from the (unmasked) XID in
> rtl8169_get_mac_version()
>
> http://lxr.linux.no/#linux+v3.1.10/drivers/net/r8169.c#L1724

Beste Grüße
Martin

#10

Problem ist leider nicht gelöst. Das Blacklisting hat funktioniert, d.h. es wurde nur das r8168 Modul geladen (Version “8.024.00” aus dem installierten Update “r8168-kmp-desktop”). Die Probleme sind aber exakt dieselben, d.h. ich musste wieder ein “rcnetwork restart” ausführen, bevor ich online war.

Komisch finde ich auch, dass mii-tool meldet, dass nur “10baseT-FD” ausgehandelt wurde. Der Realtek Chip in Verbindung mit einer Fritz!Box 3270 sollte doch eigentlich auch “100baseT-FD” schaffen, oder?

Ich hab mir jetzt mal den Treiber bei Realtek direkt runtergeladen und installiert, der hat eine neuere Version (“8.028.00”), vielleicht hilft’s ja.

Im Bugzilla schau ich auch mal und mach ggf. ein neues Ticket auf.

#11

Kleines Update, damit das hier nicht im Sande verläuft…

In dem angegebenen Thread im openSUSE Bugzilla gabs den dezenten Hinweis

Since the release of openSUSE 12.1, openSUSE 11.4 is now getting important
security and bug fixes only. From what I can tell, the problems reported here
are related to support for new hardware on 11.4 so I’ll go ahead and close this
bug entry.

Ich hab dann mal ein dist-upgrade per zypper von 11.4 auf 12.1 gemacht, aber das Problem ist geblieben.
Das r8168-Modul war gar nicht mehr dabei und das r8169 hat mir überhaupt kein Netz beschert. Ich hab dann das r8168-Modul von der Realtek-Homepage installiert. Damit hatte ich wenigstens Netz, aber mit den ursprünglichen Problemen (funktioniert erst nach “rcnetwork restart” und es wird nur 10MBit mit dem Router ausgehandelt).

Dieses Update kommt recht spät, weil in der Zwischenzeit ein Umzug stattgefunden hat. Und was soll ich sagen? Jetzt geht das Netz auf Anhieb und es werden auch die erwarteten 100MBit ausgehandelt.
Wenn ich raten müsste, würde ich annehmen, dass das damit zu tun hat, dass der Rechner ein paar Tage vom Stromnetz getrennt war. So was ähnliches hatte ich mal nach dem Booten des vorinstallierten Windows 7. Dessen Treiber hat die NIC so stark schlafen gelegt, dass der Linux-Treiber die nicht mehr aufwecken konnte und gar kein Netz mehr ging. Damals war die einzige Abhilfe, den Netzstecker zu ziehen und dann den Antaster zu drücken, um alle Restspannung loszuwerden.

Wie gesagt, nach zwei Boot-Vorgängen in der neuen Wohnung ist soweit alles in Ordnung. Wenn das die nächsten Tage so bleibt, melde ich mich und setz’ den Thread auf “gelöst”.

#12

Ok, das Problem ist seit 2 Wochen nicht mehr aufgetaucht.