ubuntuusers.de

8.10: nach suspend to RAM kein Netzwerk mehr

Status: Gelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |

unsen

Anmeldungsdatum:
2. September 2008

Beiträge: 133

ich hatte mich schon gefreut, dass der suspend to RAM nach dem update 8.04 auf 8.10 auf anhieb funktioniert, aber..:

nach dem wakeup from S3 läuft das Netzwerk nicht mehr. bei 8.04 gings noch. im KDE4 Systemapplet Systeminformationen wird noch angezeigt, dass das 'Netzwerk' läuft (grünes Weltkugelsymbol) weder Browser noch sonst eine Applikation können aber auf das Netzwerk zugreifen.

System: ein ASUS M2N SLI deluxe mit 590 nvidia Chipsatz und zwei GBit LAN Schnittstellen. mit einer bin ich verbunden zum Router (Speedport W700V)

was kann ich tun, um das problem einzugrenzen/lösen?

unsen

(Themenstarter)

Anmeldungsdatum:
2. September 2008

Beiträge: 133

ip addr show nach dem letzten wakeup:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 00:1b:fc:a1:1c:c7 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:1b:fc:a1:15:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.104/24 brd 192.168.2.255 scope global eth1
    inet6 fe80::21b:fcff:fea1:153d/64 scope link
       valid_lft forever preferred_lft forever
4: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether c6:dc:ab:54:82:9f brd ff:ff:ff:ff:ff:ff

die inet zeile bei eth1 fehlt aber für gewöhnlich nach einem wakeup. trotzdem habe ich auch in diesem fall keine internetverbindung mehr bekommen.

Mr._Natural

Avatar von Mr._Natural

Anmeldungsdatum:
12. Juni 2008

Beiträge: Zähle...

Wohnort: Westensee, SH

Hi zusammen,

an die Frage hänge ich mich mal dran. Bei mir ist genau das gleiche der Fall. Suspend to Disk geht ohne Probleme...

00:0a.0 Ethernet controller: nVidia Corporation MCP67 Ethernet (rev a2)
	Subsystem: Biostar Microtech Int'l Corp Device 2507
	Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 215
	Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at d800 [size=8]
	Memory at fe02a000 (32-bit, non-prefetchable) [size=256]
	Memory at fe029000 (32-bit, non-prefetchable) [size=16]
	Capabilities: [44] Power Management version 2
	Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable+
	Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: forcedeth
	Kernel modules: forcedeth

Rain_Maker

Anmeldungsdatum:
29. Juni 2006

Beiträge: 999

Sofern die pm-utils verwendet werden (sollte eigentlich seit längerem Standard sein), nach dem Suspend und anschliessendem Aufwachen folgendes testen:

a) Netzwerkdienste neu starten (je nachdem, was verwendet wird "/etc/init.d/entsprechender_Netzwerkdienst restart")

b) Falls das nicht genügt, Kernelmodul der Karte entladen/laden und Netzwerkdienst neu starten (siehe a)

Eine der beiden Methoden wird wahrscheinlich funktionieren, diese dann als entsprechenden "hook" in die Konfiguration der pm-utils eintragen.

Dokumentation dazu:

http://de.opensuse.org/Pm-utils

http://de.opensuse.org/Pm-utils#Erstellen_ihrer_eigenen_hooks

Mr._Natural

Avatar von Mr._Natural

Anmeldungsdatum:
12. Juni 2008

Beiträge: 15

Wohnort: Westensee, SH

Moin zusammen!

Ich hab das Problem mittlerweile mit tatkräftiger Unterstützung aus dem Thinkpad-Forum auf meinem System gelöst. Zuerst mit lsmod herausfinden, welchen Modulnamen die Netzwerkkarte hat (bei mir forcedeth) und diesen dann an der entsprechenden Stelle (SUSPEND_MODULES) in die Datei /usr/lib/pm-tools/defaults eintragen:

# If you need to unload any modules to suspend/resume, add them here.
SUSPEND_MODULES="forcedeth"

Grüße und danke für die Hilfe! Matt

CiRecT

Avatar von CiRecT

Anmeldungsdatum:
13. Juni 2006

Beiträge: 334

Wohnort: Würzburg, Bayern

Hallo,

ich wollte mal fragen wie es mit Ndiswrapper läuft? Ich verwende einen AVM Fritz! Wlan Stick. Muss ich dann bei SUSPEND_MODULES als Treiber "ndiswrapper" eintragen oder den Treiber für den Wlan-Stick? Dankeschön ☺ MFG

Rain_Maker

Anmeldungsdatum:
29. Juni 2006

Beiträge: 999

Und was hindert Dich daran, es einfach mal auszuprobieren?

Die verlinkte Dokumentation ist auch lesenwert, falls man z.B. noch das Netzwerk neu starten muss.

CiRecT

Avatar von CiRecT

Anmeldungsdatum:
13. Juni 2006

Beiträge: 334

Wohnort: Würzburg, Bayern

Also ich habe es mal ausprobiert. Habe mir ein hook erstellt, der beim "suspenden" (was für ein wort oO) mittels

rmmod ndiswrapper

entlädt und bei resume wieder

modprobe ndiswrapper

lädt. Klappt einwandfrei ☺

Wäre vllt mal ein Wiki-Artikel wert. MFG

unsen

(Themenstarter)

Anmeldungsdatum:
2. September 2008

Beiträge: 133

Mr. Natural schrieb:

Zuerst mit lsmod herausfinden, welchen Modulnamen die Netzwerkkarte hat (bei mir forcedeth) und diesen dann an der >entsprechenden Stelle (SUSPEND_MODULES) in die Datei /usr/lib/pm-tools/defaults eintragen:

# If you need to unload any modules to suspend/resume, add them here.
SUSPEND_MODULES="forcedeth"

Grüße und danke für die Hilfe! Matt

dake, das war#s auch bei mir!

anmerkung: die datei liegt unter pm-utils also: /usr/lib/pm-utils/defaults

in der datei wird auch darauf hingewiesen, dass man individuelle einstellungen in /etc/pm/config.d/ vornehmen soll. ich habe da eine datei 00sleep_module und werde mal testen, wie sich die einstellung dort verhält.. gerade keine zeit 😉

komisch nur: ich hatte schon versucht forcedeth mit modprobe -r zu entfernen und dann wieder zu laden. müsste sich doch dann wieder initialisieren, nein? jedenfalls war es mir so nicht möglich mit dhclient eth0, networking restart oder NetworkManager restart irgendwie ein funtionierendes netzwerk oder IPv4 zu beziehen.

@Rainmaker: diesen weg habe ich zu genüge probiert. kein erfolg, s.o.

@Mr. Natural: die hw-info oben, ist das eine ausgabe von lshw? sieht bei mir nicht so auführlich aus.. vorallem was die capabilities betrifft:

*-bridge:0                                                                 
          description: Ethernet interface                                       
          product: MCP55 Ethernet                                               
          vendor: nVidia Corporation                                            
          physical id: 8                                                        
          bus info: pci@0000:00:08.0                                            
          logical name: eth0                                                    
          version: a2                                                           
          serial: 00:1b:fc:a1:1c:c7                                             
          width: 32 bits                                                        
          clock: 66MHz                                                          
          capabilities: bridge bus_master cap_list ethernet physical            
          configuration: broadcast=yes driver=forcedeth driverversion=0.61 latency=0 maxlatency=20 mingnt=1 module=forcedeth multicast=yes   

Rain_Maker

Anmeldungsdatum:
29. Juni 2006

Beiträge: 999

unsen schrieb:

@Rainmaker: diesen weg habe ich zu genüge probiert. kein erfolg, s.o.

Wohl kaum, denn der obige Parameter ist nichts anderes als ein "modprobe -r" beim Schlafen gehen und ein "modprobe" beim Aufwachen, siehe auch den Post von "CiRecT" das sind zwei äquivalente Wege das Selbe zu tun.

Nur wenn es mit einem einfachen Entladen/Neuladen nicht getan ist, dann kommt man um hooks nicht herum und damit kann man fast alles machen, vor allem auch, wenn eines der beliebten forcedeth-"Features" auftritt.

http://unixboard.de/vb3/showthread.php?t=36209

Ach ja noch was zu rmmod:

Der Befehl rmmod ist "dumm", weil es keine eventuell abhängigen Module entlädt, statt rmmod besser modprobe -r verwenden.

unsen

(Themenstarter)

Anmeldungsdatum:
2. September 2008

Beiträge: 133

Rain_Maker schrieb:

Wohl kaum, denn der obige Parameter ist nichts anderes als ein "modprobe -r" beim Schlafen gehen und ein "modprobe" beim Aufwachen, siehe auch den Post von "CiRecT" das sind zwei äquivalente Wege das Selbe zu tun.

ahaaa.. hätte man den forcedeth VOR dem suspend mit modprobe -r entladen und nach dem resume wieder laden sollen?

das war dann in den bisherigen threads zu dem thema missverständlich, bzw hörte sich eindeutig so an, als ob man das alles nach dem resume tun kann. in einem fall soll es auf diese weise sogar wieder zu einer erfolgreichen netzwerkverbindung gekommen sein.

Rain_Maker

Anmeldungsdatum:
29. Juni 2006

Beiträge: 999

Nicht zwingend, das muss eigentlich auch -natürlich nur zum ersten Test- nach dem Suspend gehen.

Ist nicht der erste Thread (egal wleche Distri) in dem es um solche Probleme geht und ich mitmische, bisher war ein Entladen/Laden des Moduls und anschliessender Neustart der Netzwerkdienste das Maximum, was nötig war um die Karte wieder zum Leben zu erwecken.

Der verlinkte Thread aus dem Unixboard sollte nur zeigen, welche davon nicht unbedingt abhängenden Probleme (dieses "Feature der sich ändernden MAC-Adresse, weil die Karte beim Initialisieren irgendwelchen Unsinn von such gibt, ist nur eine der Überraschungen, für diese Mistkarten gut sind) man mit den Hooks lösen kann/muss.

unsen

(Themenstarter)

Anmeldungsdatum:
2. September 2008

Beiträge: 133

sehr verwirrend für einen linux-neuling, alles..

nochmal: das netzwerk wacht jetzt ordentlich auf, nachdem ich in die /etc/pm/config.d/00sleep_module (was der richtige/updatesichere platz dafür wäre) eine zeile SUSPEND_MODULES="forcedeth" hinzugefügt habe.

trotzdem merkwürdig:

nach dem systemstart habe ich vom knetworkmanager ein applet in der systeminfo-leiste (grünes weltkugel-symbol), welches mir über meine wired-verbindungen keine informationen liefert und auch sonst von wenig nutzen scheint.

nach dem resume von S3 habe seit der änderung ein zusätzliches applet in der systeminfo-leiste, das auch anzeigt, dass eine verbindung hergestellt wird und eine IP-request durchgeführt.. wenn ich dort auf das gnome-style kontextmenü (es läuft eigentlich KDE4.1, aber muss ja nichts heißen) gehe, dann wird mir angezeigt, es handelt sich um das Network-Manager Applet 0.7.0. vor dem suspend war das jedenfalls noch nicht da, aber es tut seinen job und zeigt an, dass eine verbindung hergestellt wird. durch was dieses applet nach dem suspend jetzt zum leben erweckt wurde (der neugeladene forcedeth evtl.?) ich habe keine ahnung!

den knetworkmanager-prozess kann ich sogar killen und ein suspend-resume funktioniert immernoch mit automatischer wiederherstellung des netzwerkes. (ich bin mir fast sicher, ich habe den knetworkmanager auch schonmal deinstalliert - keine änderung des problems).

komisch auch, im kontextmenü des Network-Managers (L-klick) bekomme ich eine aktive verbindung auf eth1 und die inaktive eth0 (grau) und.. noch zwei weitere graue mit dem Text: "Wired Connection(Asustek Computer MCP55 Ethernet".. was die ausführliche Bezeichnung für meine Lan-Hardware auf dem mainboard wäre.. alles doppelt irgentwo!?

–-

wie dem auch sei - der hinweis auf pm-utils und hooks war sein geld wert.. ich hätte mir nur gewünscht, da was im ubuntu-wiki zu lesen. das sollte man vielleicht mal anregen, dass da eine kurzer abriss reinkommt, wie man bei unspezifischen problemen mit den sleep-modi verfahren kann..

Rain_Maker

Anmeldungsdatum:
29. Juni 2006

Beiträge: 999

unsen schrieb:

ich hätte mir nur gewünscht, da was im ubuntu-wiki zu lesen. das sollte man vielleicht mal anregen, dass da eine kurzer abriss reinkommt, wie man bei unspezifischen problemen mit den sleep-modi verfahren kann..

Die gesamte Community (und nicht nur Wikis) lebt vom Mitmachen, also warum machst Du das nicht selbst?

Greetz,

RM

thosch66

Avatar von thosch66

Anmeldungsdatum:
16. Juni 2007

Beiträge: 125

Wohnort: Berlin

unsen schrieb:

Mr. Natural schrieb:

Zuerst mit lsmod herausfinden, welchen Modulnamen die Netzwerkkarte hat (bei mir forcedeth) und diesen dann an der >entsprechenden Stelle (SUSPEND_MODULES) in die Datei /usr/lib/pm-tools/defaults eintragen:

# If you need to unload any modules to suspend/resume, add them here.
SUSPEND_MODULES="forcedeth"

Grüße und danke für die Hilfe! Matt

dake, das war#s auch bei mir!

anmerkung: die datei liegt unter pm-utils also: /usr/lib/pm-utils/defaults

in der datei wird auch darauf hingewiesen, dass man individuelle einstellungen in /etc/pm/config.d/ vornehmen soll. ich habe da eine datei 00sleep_module und werde mal testen, wie sich die einstellung dort verhält.. gerade keine zeit 😉

Wenn man es richtig schön machen möchte, dann spendiert man dem Fix/Workaround eine eigene Datei unter /etc/pm/config.d und verwendet folgende Zeile:

SUSPEND_MODULES="$SUSPEND_MODULES <modulname>"

Letzeres hat den Vorteil, dass durch das $SUSPEND_MODULES der evtl. vorhandene Inhalt der Variablen SUSPEND_MODULES nicht überschrieben wird, sondern ergänzt wird. Sonst könnte man sich ins Knie schießen, wenn bereits an anderer Stelle die Variable bereits gesetzt wurde. (Quelle: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/267339/comments/13 )

Gruß

Thomas

Antworten |