Fwd: Re: [suse-laptop] 9.3: Tecra 8000: suspend-to-disk
Hallo Hans-Dieter, I'm back. :-) Habe mir nun doch etwas schneller eine neue Festplatte zugelegt. War auch allerhoechste Zeit. Beim Sichern derselben blieb er einige Male stehen. Konnte allerdings nach einem ^C erneut weitermachen. Leider konnte ich alles ausser meiner Home-Directory nicht mehr gebrauchen, weil Softlinks nicht als solche sondern als Files mit 0 Bytes und mit 000 als Permission gespeichert wurden. Ich hatte mit tar -cpf - bin etc ... | ssh user@savehost "cd /home/Notebook && \ tar -xpvf -" die Daten uebertragen. Bis jetzt hat das immer funktioniert. Nun ja, nicht weiter schlimm. Habe halt neu installiert. Bin jetzt wieder am Thema suspend-to-disk. Habe es gestern zu Hause 2 Mal aus X11 heraus probiert und beim Hochfahren ist er jedesmal stehen geblieben. Jedesmal woanders. In 'messages' habe ich nichts gefunden (bei DEBUG=16). Ein powersave -U aus init 3 heraus und zurueck hat funktioniert, allerdings dann ein init 5 ging schief. (???) Nun heute im Buero hat's ploetzlich funktioniert. X11 -> powersave -U -> X11 ein paar mal nacheinander (Hmmm, ??) Allerdings bleibt er danach beim Runterfahren haengen. Die X-Tools werden noch geschlossen, dann bleibt der Mauszeiger unverrueckbar am Bildschirm und nichts tut sich mehr. Die [A] LED zwischen Bildschirm und Tastatur blinkt nur langsam vor sich hin. Koennte meine Aenderung bezueglich crypt. Partition der Grund sein? Ich habe es von 'Einbinden beim Boot' auf 'Einbinden von Hand' geaendert. Allerdings sollte sich das auch auf den inti-3-Fall auswirken. Hast Du da irgendwelche Erkenntnisse ? Gruss Werner
Am Mittwoch, 27. Juli 2005 08:29 schrieb Werner Franke:
Bin jetzt wieder am Thema suspend-to-disk. Habe es gestern zu Hause 2 Mal aus X11 heraus probiert und beim Hochfahren ist er jedesmal stehen geblieben. Jedesmal woanders. In 'messages' habe ich nichts gefunden (bei DEBUG=16).
Merkwuerdig, wenn ich POWERSAVED_DEBUG auf 16 setze, ist mein syslog (/var/log/messages) mit Meldungen gefuellt. Setze mal auf 11, dann siehst Du Warnings, Error und jede Menge Infos, die Dir weiterhelfen sollten. (nicht vergessen rcpowersaved restart unter root zu geben). Sollten keine diesbezueglichen Meldungen vorhanden sein, stimmt irgendetwas nicht, entweder der Logg-Mechanismus oder die Powersave Scipte. Biite pruefen, da hier Hinweise zu Fehlern zu erkennen sein sollten.
Ein powersave -U aus init 3 heraus und zurueck hat funktioniert,
- Wie ist der Status Deines System? - Patch fuer snd.ko installiert? - Directory /sys/devices/platform/snd_generic_pm.0 nicht mehr vorhanden? - Keine Fehler im syslog der Art ALSA sound/core/menory.c:71: Not freed snd_alloc_ ...? - Scripts mit vbetool entsprechend /usr/share/doc/packages/powersave/contrib installiert ? - Funktioniert auch powersave -u (suspend2ram) im runlevel 3 einwandfrei ? Das sollte reproduzierbar einwandfrei ohne Fehler laufen, vorher hat hat das unter X11 keinen Zweck.
allerdings dann ein init 5 ging schief. (???)
Was genau waren die Fehler?
Nun heute im Buero hat's ploetzlich funktioniert.
X11 -> powersave -U -> X11
ein paar mal nacheinander (Hmmm, ??) Allerdings bleibt er danach beim Runterfahren haengen. Die X-Tools werden noch geschlossen, dann bleibt der Mauszeiger unverrueckbar am Bildschirm und nichts tut sich mehr.
Was heisst runterfahren, Shutdown ? Welcher Windowmanager laeuft, KDE ? Wenn ja, versuche mal einen anderen Windowmanager. Ich benutze icewm. Schalte zurueck auf Console 1 und mach dann powersave -U. Nach Restore zurueck auf Console 7, geht das ? Was zeigen die Systemmeldungen hierbei. Siehe auch die Logs in /var/log/suspend2ram.log
Die [A] LED zwischen Bildschirm und Tastatur blinkt nur langsam vor sich hin.
Kann im Handbuch zu diesem Blinken leider nichts finden, habe das aber selbst auch schon erlebt. Der Rechner scheint in dem Fall total verstoert und nur durch Powerreset wieder zu beleben zu sein.
Koennte meine Aenderung bezueglich crypt. Partition der Grund sein? Ich habe es von 'Einbinden beim Boot' auf 'Einbinden von Hand' geaendert. Allerdings sollte sich das auch auf den inti-3-Fall auswirken.
Kann ich nichts zu sagen. Aber mach die Gegenprobe und versuche, ob es ohne crypt funktioniert. Gruss Dieter
Hallo Dieter, Am Donnerstag, 4. August 2005 14:26 schrieb Hans-Dieter Schenk:
Am Mittwoch, 27. Juli 2005 08:29 schrieb Werner Franke:
Bin jetzt wieder am Thema suspend-to-disk. Habe es gestern zu Hause 2 Mal aus X11 heraus probiert und beim Hochfahren ist er jedesmal stehen geblieben. Jedesmal woanders. In 'messages' habe ich nichts gefunden (bei DEBUG=16).
Merkwuerdig, wenn ich POWERSAVED_DEBUG auf 16 setze, ist mein syslog (/var/log/messages) mit Meldungen gefuellt. Setze mal auf 11, dann siehst Du Warnings, Error und jede Menge Infos, die Dir weiterhelfen sollten. (nicht vergessen rcpowersaved restart unter root zu geben). Sollten keine diesbezueglichen Meldungen vorhanden sein, stimmt irgendetwas nicht, entweder der Logg-Mechanismus oder die Powersave Scipte. Biite pruefen, da hier Hinweise zu Fehlern zu erkennen sein sollten.
Sorry, ich habe mich missverstaendlich ausgedrueckt. Natuerlich sind viele Meldungen bezueglich powersave im Syslog, aber keine, die ich als Fehler idenifizieren konnte.
Ein powersave -U aus init 3 heraus und zurueck hat funktioniert,
- Wie ist der Status Deines System? - Patch fuer snd.ko installiert?
JA
- Directory /sys/devices/platform/snd_generic_pm.0 nicht mehr vorhanden? Nicht vorhanden
- Keine Fehler im syslog der Art ALSA sound/core/menory.c:71: Not freed snd_alloc_ ...? Keine Fehler
- Scripts mit vbetool entsprechend /usr/share/doc/packages/powersave/contrib installiert ? Nein, da ich suspend-to-ram erst mal nicht brauche. Mein Accu haelt nur ca 20 minuten. Arbeite also immer mit externer Stromquelle.
- Funktioniert auch powersave -u (suspend2ram) im runlevel 3 einwandfrei ? Nicht probiert wegen Punkt darueber. Ausserdem weiss ich nicht, wie ich den Rechner daraus wieder erwecke. Mangels Zeit habe ich allerdings auch nicht danach gesucht.
Das sollte reproduzierbar einwandfrei ohne Fehler laufen, vorher hat hat das unter X11 keinen Zweck.
allerdings dann ein init 5 ging schief. (???)
Was genau waren die Fehler?
Das weiss ich nicht mehr.
Nun heute im Buero hat's ploetzlich funktioniert.
X11 -> powersave -U -> X11
ein paar mal nacheinander (Hmmm, ??) Allerdings bleibt er danach beim Runterfahren haengen. Die X-Tools werden noch geschlossen, dann bleibt der Mauszeiger unverrueckbar am Bildschirm und nichts tut sich mehr.
Was heisst runterfahren, Shutdown ?
Ja. Runterfahren in KDE (shutdown -h). Wie ich schon in der anschliessenden Mail geschrieben habe ist der '/opt/kde3/bin/kdm' das Problem. Er laesst sich nicht mehr beenden. Ein 'kill <Process-ID-von-kdm>' zeigt den gleichen schon beschriebenen Effekt. Allerdings, ich weiss nicht ob Du's missverstanden hast, der Rechner bleibt erst beim anschliessenden 'normalen Shutdown' haengen. Nach einem Suspend-to-disk. Suspend-to-disk selbst funktioniert ein paar mal nacheinander (hab's 2 mal probiert) auch mit X, dem KDE und /opt/kde3/bin/kdm.
Welcher Windowmanager laeuft, KDE ? Wenn ja, versuche mal einen anderen Windowmanager. Ich benutze icewm.
Den habe ich nicht installiert. Aber auch beim fvwm wird der 'kdm' benutzt, so dass das Ergebnis das gleiche sein duerfte. Habe statt dessen mal den 'gdm' in /etc/sysconfig/displaymanager eingetragen. Danach wird zwar der 'xdm' verwendet, aber mit dem habe ich dann unter laufendem KDE ein 'powersave -U' gemacht. Abgeschaltet hat er sich, aber beim anschliessenden Hochfahren blieb er beim Aufbauen der Windows in X haengen. Nur [A] hat geblinkt. Der funktioniert also noch weniger.
Schalte zurueck auf Console 1 und mach dann powersave -U. Nach Restore zurueck auf Console 7, geht das ? Ist zwar etwas anderes als Du beschrieben hast:
init 3 login als root powersave -U -> führt's aus und schaltet ab Einschalten -> lande wieder an der gleichen Stelle wie bei 'powersave -U' init 5 -> Startet KDE Abmelden -> wie gehabt. Rechner haengt. ==> Auch ein Starten vom kdm NACH einem erfolgreichem Suspend endet darin, dass beim anschliessenden Herunterfahren der kdm haengt. Ich habe auch festgestellt, dass nach einem Suspend2Disk das Netzwerk nicht mehr funktionierte. Jedenfalls hat der PC vom DHCP Server keine IP bekommen. Habe da aber nicht naeher geforscht, sondern neu gebootet.
Was zeigen die Systemmeldungen hierbei. Siehe auch die Logs in /var/log/suspend2ram.log
Habe nichts (fuer mich) besonderes in /var/log/suspend2ram.log gefunden. Nach suspend: Resuming: nichts Reloading modules: ohci1394 video1394 uhci_hdc Restarting services: nichts Remounting filesystems: not necessary.
Die [A] LED zwischen Bildschirm und Tastatur blinkt nur langsam vor sich hin.
Kann im Handbuch zu diesem Blinken leider nichts finden, habe das aber selbst auch schon erlebt. Der Rechner scheint in dem Fall total verstoert und nur durch Powerreset wieder zu beleben zu sein.
Koennte meine Aenderung bezueglich crypt. Partition der Grund sein? Ich habe es von 'Einbinden beim Boot' auf 'Einbinden von Hand' geaendert. Allerdings sollte sich das auch auf den inti-3-Fall auswirken.
Kann ich nichts zu sagen. Aber mach die Gegenprobe und versuche, ob es ohne crypt funktioniert.
Ich habe inzwischen des Crypt aus den Boot-Process entfernt und in die fstab umgezogen, damit ich es auf dem Desktop benutzen kann. Keine Verbesserung (Habe auch keine erwartet). Gruss Werner PS: Bin erst am Montag wieder im Büro und kann eMails lesen.
Am Donnerstag, 4. August 2005 15:41 schrieb Werner Franke:
- Funktioniert auch powersave -u (suspend2ram) im runlevel 3 einwandfrei ?
Nicht probiert wegen Punkt darueber. Ausserdem weiss ich nicht, wie ich den Rechner daraus wieder erwecke. Mangels Zeit habe ich allerdings auch nicht danach gesucht.
Bei suspend2ram schaltet der Rechner aus und die Runlampe blinkt im 3 Sekunden Rhythmus. Erweckt wird der Rechner einfach durch Einschalten mit dem Powerswitch. Das System ist in etwa 10 Sekunden wieder betriebsbereit. Deshalb fuer Testzwecke auch bei defektem Akku empfehlenswert.
Allerdings, ich weiss nicht ob Du's missverstanden hast, der Rechner bleibt erst beim anschliessenden 'normalen Shutdown' haengen. Nach einem Suspend-to-disk. Suspend-to-disk selbst funktioniert ein paar mal nacheinander (hab's 2 mal probiert) auch mit X, dem KDE und /opt/kde3/bin/kdm.
Ich fasse zusammen, damit ich das richtig verstande habe: suspend2disk funktioniert einwandfrei, auch bei X, auch mehr als zweimal hintereinander, also beliebig oft ? Nicht funktioniert das Runterfahren des Rechners aus dem Menue des kdm und zwar wenn vorher ein suspend/resume Zyklus durchlaufen wurde. Nach einem normalen Bootvorgang geht das Runterfahren ohne Probleme. Ein killall kdm aus einer alphanumerischen Konsole (Ctrl/Alt/F1) funktioniert ebenfalls nicht (unter den eben angefuehrten Bedingungen). Das gleiche trifft fuer xdm zu. Ansonsten lauft das X bzw KDE einwandfrei. Bei meinem System kann ich diese Probleme nicht beobachten, so dass ich Dir hier nicht weiterhelfen kann. Ich sehe auch keinen Zusammenhang zwischen powersave und kdm/xdm, der zu diesem Fehler fuehren koennte (Screensaver ?). Als Hinweis: der kdm kann auch mit -nodaemon und -debug n Argumenten gestartet werden. Ueberpruefe auch Deine X- und kdm-Konfiguration. Da der xdm ebenfalls betroffen ist, glaube ich aber, das es an etwas anderem liegt. Was ist, wenn Du X im Runlevel 3 mit startx startest (also ohne kdm oder xdm). Geht dann das Shutdown bzw halt ? Vielleicht helfen Dir diese Hinweise weiter.
Welcher Windowmanager laeuft, KDE ? Wenn ja, versuche mal einen anderen Windowmanager. Ich benutze icewm.
Unzutreffender Hinweis von mir, da ja wie ich annehme, das Shutdown aus dem Menue des Loginmanagers erfolgt und damit ein Windowmanager noch nicht am Zuge ist.
Ich habe auch festgestellt, dass nach einem Suspend2Disk das Netzwerk nicht mehr funktionierte. Jedenfalls hat der PC vom DHCP Server keine IP bekommen. Habe da aber nicht naeher geforscht, sondern neu gebootet.
Geht bei mir. Probiere nach dem Resume das Netz neu zu initialisieren durch rcnetwork restart. Wenn das dann ok ist, ergaenze in der Datei /etc/sysconfig/powersave/sleep fuer POWERSAVE_SUSPEND2DISK_RESTART_SERVICES network (und alsasound) . Gruss Dieter
Hallo Dieter, Am Samstag, 6. August 2005 19:55 schrieb Hans-Dieter Schenk:
Am Donnerstag, 4. August 2005 15:41 schrieb Werner Franke:
- Funktioniert auch powersave -u (suspend2ram) im runlevel 3 einwandfrei ?
Nicht probiert wegen Punkt darueber. Ausserdem weiss ich nicht, wie ich den Rechner daraus wieder erwecke. Mangels Zeit habe ich allerdings auch nicht danach gesucht.
Bei suspend2ram schaltet der Rechner aus und die Runlampe blinkt im 3 Sekunden Rhythmus. Erweckt wird der Rechner einfach durch Einschalten mit dem Powerswitch. Das System ist in etwa 10 Sekunden wieder betriebsbereit. Deshalb fuer Testzwecke auch bei defektem Akku empfehlenswert.
Danke. Werde mich erst mal mehr auf suspend-to-disk konzentrieren. Ich moechte suspend-to-disk ja hauptsaechlich desswegen, weil der PC schneller unten und wieder oben ist.
Allerdings, ich weiss nicht ob Du's missverstanden hast, der Rechner bleibt erst beim anschliessenden 'normalen Shutdown' haengen. Nach einem Suspend-to-disk. Suspend-to-disk selbst funktioniert ein paar mal nacheinander (hab's 2 mal probiert) auch mit X, dem KDE und /opt/kde3/bin/kdm.
Ich fasse zusammen, damit ich das richtig verstande habe: suspend2disk funktioniert einwandfrei, auch bei X, auch mehr als zweimal hintereinander, also beliebig oft ? Mehr als 2 Mal hintereinander hab's ich nicht gemacht.
Nicht funktioniert das Runterfahren des Rechners aus dem Menue des kdm und zwar wenn vorher ein suspend/resume Zyklus durchlaufen wurde. Nach einem normalen Bootvorgang geht das Runterfahren ohne Probleme. Ein killall kdm aus einer alphanumerischen Konsole (Ctrl/Alt/F1) funktioniert ebenfalls nicht (unter den eben angefuehrten Bedingungen). Das gleiche trifft fuer xdm zu. Ansonsten lauft das X bzw KDE einwandfrei.
Ja. Alles richtig.
Bei meinem System kann ich diese Probleme nicht beobachten, so dass ich Dir hier nicht weiterhelfen kann. Ich sehe auch keinen Zusammenhang zwischen powersave und kdm/xdm, der zu diesem Fehler fuehren koennte (Screensaver ?). Als Hinweis: der kdm kann auch mit -nodaemon und -debug n Argumenten gestartet werden. Ueberpruefe auch Deine X- und kdm-Konfiguration. Da der xdm ebenfalls betroffen ist, glaube ich aber, das es an etwas anderem liegt.
Es koennte ein Schmutzeffekt sein, der sich hier auswirkt ? Vielleicht sollte ich noch dazu sagen, dass ich mich nicht sooo im Detail von Linux und dem System auskenne. Also bitte nicht wundern bei manchen unqualifizierten Aussagen :-)
Was ist, wenn Du X im Runlevel 3 mit startx startest (also ohne kdm oder xdm). Geht dann das Shutdown bzw halt ?
Bezueglich 'startx' siehe weiter unten.
Vielleicht helfen Dir diese Hinweise weiter.
Welcher Windowmanager laeuft, KDE ? Wenn ja, versuche mal einen anderen Windowmanager. Ich benutze icewm.
Unzutreffender Hinweis von mir, da ja wie ich annehme, das Shutdown aus dem Menue des Loginmanagers erfolgt und damit ein Windowmanager noch nicht am Zuge ist.
Nein. Der Shutdown erfolgte aus laufendem X + KDE. Nach einem S2D lande ich ja wieder dort, wo ich dies gestartet hatte. Einen S2D wenn der Loginmanager gerade aktiv ist, hatte ich nicht ausprobiert. Momentan habe ich einen automatischen Login eingestellt. Auch wenn das bei einem Notebook sicherheitstechnisch bedenklich ist.
Ich habe auch festgestellt, dass nach einem Suspend2Disk das Netzwerk nicht mehr funktionierte. Jedenfalls hat der PC vom DHCP Server keine IP bekommen. Habe da aber nicht naeher geforscht, sondern neu gebootet.
Geht bei mir. Probiere nach dem Resume das Netz neu zu initialisieren durch rcnetwork restart. Wenn das dann ok ist, ergaenze in der Datei /etc/sysconfig/powersave/sleep fuer POWERSAVE_SUSPEND2DISK_RESTART_SERVICES network (und alsasound) .
Ich habe den PC nun mal in den Runlevel 3 gestertet, mich eingeloggt und 'startx' aufgerufen. KDE hat problemlos gestartet. Danach 'powersave -U' als 0815-User. Macht er und schaltet sich ab. Einschalten. Startet und landed in KDE, dort, wo ich Suspend2Disk abgesetzt hatte. Das Kommando '/sbin/ifconfig eth0' zeigt mir, dass er zwar IP Adresse hat, aber 'ping <anderer Rechner>' bringt kein Ergebnis. Bei 'ping anderere-IP' bringt 'Destination Host Unreachable'. (wfranke notebook tcsh) [46] /sbin/route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 123.246.111.0 0.0.0.0 255.255.254.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 123.246.111.1 0.0.0.0 UG 0 0 0 eth0 (wfranke notebook tcsh) [47] /sbin/ifconfig eth0 eth0 Protokoll:Ethernet Hardware Adresse 00:10:A4:F6:A2:AE inet Adresse:123.246.111.65 Bcast:123.246.111.255 Maske:255.255.254.0 inet6 Adresse: fe80::210:a4ff:fef6:a2ae/64 Gültigkeitsbereich:Verbindung UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1008 errors:0 dropped:0 overruns:0 frame:0 TX packets:195 errors:1 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:132325 (129.2 Kb) TX bytes:55812 (54.5 Kb) Interrupt:3 Basisadresse:0x300 Danach als 'root' 'rcnetwork restart'. --> Es dauert kurz, dann steht der PC und [A] blinkt. Nach dem anschliessenden Wiederhochfahren habe ich in /var/log/messages folgendes am Ende gefunden: su: (to root) wfranke on /dev/pts/4 ==> als root eingeloggt und 'rcnetwork' dhcpcd[5259]: terminating on signal 15 modify_resolvconf: restored /etc/resolv.conf.saved.by.dhcpcd.eth0 to /etc/resolv.conf kernel: eth0: media 10Base2, silicon revision 4 kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: transmit timed out kernel: scheduling while atomic: kscd/0x00000100/6402 kernel: [<c02d0b79>] schedule+0x4d9/0x590 kernel: [<c01166e4>] activate_task+0x54/0x70 kernel: [<c02d12d6>] schedule_timeout+0x56/0xb0 kernel: [<c0121ba0>] process_timeout+0x0/0x10 kernel: [<ccddad0c>] hardreset+0x3c/0x70 [xirc2ps_cs] kernel: [<ccddad66>] do_reset+0x26/0x3e0 [xirc2ps_cs] kernel: [<ccdda87e>] do_tx_timeout+0x2e/0x80 [xirc2ps_cs] kernel: [<c0276ae0>] dev_watchdog+0x0/0x90 kernel: [<c0276b5b>] dev_watchdog+0x7b/0x90 kernel: [<c012191a>] run_timer_softirq+0xba/0x180 kernel: [<c0134b32>] handle_IRQ_event+0x32/0x70 kernel: [<c011e153>] __do_softirq+0x43/0xa0 kernel: [<c011e1d6>] do_softirq+0x26/0x30 kernel: [<c010528d>] do_IRQ+0x3d/0x60 kernel: [<c0103cba>] common_interrupt+0x1a/0x20 kernel: [<c016007b>] sys_rename+0xeb/0x210 kernel: [<c01d4544>] __copy_from_user_ll+0x4/0x60 kernel: [<c016219c>] sys_select+0x26c/0x4d0 kernel: [<c01611b6>] do_ioctl+0x46/0x60 kernel: [<c011d935>] sys_gettimeofday+0x25/0x60 kernel: [<c0102c49>] sysenter_past_esp+0x52/0x79 kernel: scheduling while atomic: kscd/0x00000100/6402 kernel: [<c02d0b79>] schedule+0x4d9/0x590 kernel: [<c02d12d6>] schedule_timeout+0x56/0xb0 kernel: [<c0121ba0>] process_timeout+0x0/0x10 kernel: [<ccddad0c>] hardreset+0x3c/0x70 [xirc2ps_cs] kernel: [<ccddad66>] do_reset+0x26/0x3e0 [xirc2ps_cs] Das geht noch etliche Zeilen so weiter kernel: [<c011e1d6>] do_softirq+0x26/0x30 kernel: [<c010528d>] do_IRQ+0x3d/0x60 kernel: [<c0103cba>] common_interrupt+0x1a/0x20 kernel: eth0: media 10Base2, silicon revision 4 kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: transmit timed out kernel: scheduling while atomic: kicker/0x00000100/6374 kernel: [<c02d0b79>] schedule+0x4d9/0x590 und er dann abbricht. Ob das allerdings mit dem Stillstand zu tun hat, bin ich nicht sicher. Um weitere Infos zu bekommen, habe ich den als naechstes beschriebenen Weg mehrmals gemacht und auch dort obige Zeilen im syslog gefunden OHNE dass der PC dann stand. Der Stillstand mit 'rcnetwork restart' ist aber reproduzierbar. Wenn ich in POWERSAVE_SUSPEND2DISK_RESTART_SERVICES auch 'network' einbaue, dann steht der PC kurze Zeit nach dem Suspend2Disk, wenn er wieder oben ist. ------------------------------------------- Das Ganze habe ich danach nochmal so gemacht, jedoch diesmal nicht rcnetwork sondern die X-Session ueber den Abmelde-Knopf in KDE beendet und ueber Ctrl+Alt+Del den PC heruntergefahren. Hat funktioniert. Allerdings habe ich folgende Fehlermeldung beim runterfahren gesehen: (Aus /var/log/boot..omsg) ardmgr[3437]: executing: 'modprobe -r xirc2ps_cs 2>&1' cardmgr[3437]: + FATAL: Module xirc2ps_cs is in use. cardmgr[3437]: modprobe exited with status 1 cardmgr[3437]: executing: 'modprobe -r serial_cs 2>&1' cardmgr[3437]: + FATAL: Module serial_cs is in use. cardmgr[3437]: modprobe exited with status 1 done Shutting down PCMCIA <notice>killproc: kill(3437,15) cardmgr[3437]: exiting FATAL: Module pcmcia is in use. FATAL: Module yenta_socket is in use. FATAL: Module rsrc_nonstatic is in use. FATAL: Module pcmcia_core is in use. failed --------------- Ein 'reboot' in einem xterm unter laufenden X+KDE hat funktioniert (mit obigen Fehlern). Vielleicht sagt Dir das etwas und Du hast noch eine Idee. Wenn nicht, sollten wir hier abbrechen. Ich moechte Deine Gedult nicht ueber die Massen beanspruchen. Es waere schon wenn es funktioniert s2d hätte, aber irgenwas mauert. Danke und Grüsse Werner
Hallo Werner,
Geht bei mir. Probiere nach dem Resume das Netz neu zu initialisieren durch rcnetwork restart. Wenn das dann ok ist, ergaenze in der Datei /etc/sysconfig/powersave/sleep fuer POWERSAVE_SUSPEND2DISK_RESTART_SERVICES network (und alsasound) .
habe ich auf meinem Desktop-PC auch so gemacht und es hat nicht funktioniert. Daher habe ich mir ein SHELL-Script "suspend2disk.sh" gebaut: ... SUSPEND="alsasound network" RESUME="network alsasound" for i in ${SUSPEND}; do /etc/init.d/$i stop done powersave -U for i in ${RESUME}; do /etc/init.d/$i start done ... cinternet --stop (oder so ähnlich) cinternet --start (oder so ähnlich) cinternet --dialin (oder so ähnlich) ... und plötzlich hat es funktioniert ;-)
Ich habe den PC nun mal in den Runlevel 3 gestertet, mich eingeloggt und 'startx' aufgerufen. KDE hat problemlos gestartet. Danach 'powersave -U' als 0815-User. Macht er und schaltet sich ab. Einschalten. Startet und landed in KDE, dort, wo ich Suspend2Disk abgesetzt hatte. Das Kommando '/sbin/ifconfig eth0' zeigt mir, dass er zwar IP Adresse hat, aber 'ping <anderer Rechner>' bringt kein Ergebnis. Bei 'ping anderere-IP' bringt 'Destination Host Unreachable'.
Daher mache ich nach suspend2disk stop, start, dialin. Seitdem geht es. Die IP-Adresse ist bei mir nach suspend2disk sowieso nicht dieselbe wie davor.
Ich moechte Deine Gedult nicht ueber die Massen beanspruchen. Es waere schon wenn es funktioniert s2d hätte, aber irgenwas mauert.
Nicht aufgeben ;-) Gruß, Dejan -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++
Hallo Dejan, Dieter, Am Dienstag, 9. August 2005 15:19 schrieb Dejan Hrubenja:
Hallo Werner,
Geht bei mir. Probiere nach dem Resume das Netz neu zu initialisieren durch rcnetwork restart. Wenn das dann ok ist, ergaenze in der Datei /etc/sysconfig/powersave/sleep fuer POWERSAVE_SUSPEND2DISK_RESTART_SERVICES network (und alsasound) .
habe ich auf meinem Desktop-PC auch so gemacht und es hat nicht funktioniert. Daher habe ich mir ein SHELL-Script "suspend2disk.sh" gebaut:
... SUSPEND="alsasound network" RESUME="network alsasound"
for i in ${SUSPEND}; do /etc/init.d/$i stop done
powersave -U
for i in ${RESUME}; do /etc/init.d/$i start done ... cinternet --stop (oder so ähnlich) cinternet --start (oder so ähnlich) cinternet --dialin (oder so ähnlich) ...
und plötzlich hat es funktioniert ;-)
Bringt leider nichts. Beim Starten des Netzwerkes, wenn er eine IP vom DHCP haben will, stoppt der PC. In dem xterm, in dem ich '/etc/init.d/network start' gemacht hatte, sehe ich noch seine Bemühungen mit dem DHCP. Uebrigends: Das Problem mit 'kdm' ist plötzlich weg. Wenn ich den PC nun ganz normal in Runlevel 5 hochfahren lasse, mit automatischem Login und KDE als WM, danach einen Suspend2Disk mache und ihn, nachdem er wieder oben ist ganz normal über den Ausschaltknopf in KDE runterfahren lasse, macht er keine Probleme mehr. Aenderungen: - Bildschirmsaver auf 'leeren Bildschirm' - gestern Kernel aktualisiert auf ' Was allerdings der Bildschirmschoner damit zu tun haben koennte weiss ich nicht. Der ist beim S2D doch ueberhaupt nicht aktiv. Und ich habe jetzt herausgefunden, warum letztens der Suspend2Disk plötzlich überhaupt funktionierte (Mail vom: 27.07.2005 08:29). Der PC war ja immer beim Aufwachen aus dem Suspend hängen geblieben. Nun, das ist jetzt wieder der Fall. Ich habe zwei Profile mit SCPM definiert (Home und Firma). Um das Problem mit dem Netzwerk weiter zu testen, habe ich mal wieder auf mein Home-Profil mit fester IP umgeschaltet. Nun bleibt er wieder meim Aufwachen aus S2D hängen. Scheint also am Netzwerk zu liegen. Ich will den PC in den Urlaub mitnehmen und da wäre mir S2D besonders wichtig. Eventuell hilft es mir, wenn ich ein drittes Profil OHNE Netzwerk einrichte und das dann benutze. Grüsse Werner
Hallo Werner, hallo Dejan, Am Donnerstag, 11. August 2005 11:11 schrieb Werner Franke:
for i in ${SUSPEND}; do /etc/init.d/$i stop done
powersave -U
for i in ${RESUME}; do /etc/init.d/$i start done
Im Prinzip machen die Powersave Scripte das genau so (siehe /usr/lib/powersave/scripts/sleep_helper_functions.
... cinternet --stop (oder so ähnlich) cinternet --start (oder so ähnlich) cinternet --dialin (oder so ähnlich) ...
und plötzlich hat es funktioniert ;-)
War denn vor dem Suspend ein cinternet --start .. gegeben worden (sonst sollte ein cinternet --stop keinen Sinn machen)? Vor einem Shutdown oder Suspend wuerde ich empfehlen, eine ppp Verbindung zu trennen.
Bringt leider nichts. Beim Starten des Netzwerkes, wenn er eine IP vom DHCP haben will, stoppt der PC. In dem xterm, in dem ich '/etc/init.d/network start' gemacht hatte, sehe ich noch seine Bemühungen mit dem DHCP.
Was sind die Bemuehungen ? Er sollte sich im Hintergrund bemuehen, aber ansonsten weitermachen.
Uebrigends: Das Problem mit 'kdm' ist plötzlich weg. Wenn ich den PC nun ganz normal in Runlevel 5 hochfahren lasse, mit automatischem Login und KDE als WM, danach einen Suspend2Disk mache und ihn, nachdem er wieder oben ist ganz normal über den Ausschaltknopf in KDE runterfahren lasse, macht er keine Probleme mehr.
Aenderungen: - Bildschirmsaver auf 'leeren Bildschirm'
Interessante Fragen. Ich habe gar kein KDE laufen (sondern icewm). Trotzdem kommt bei mir nach dem Resume der Screensaver vom KDE mit der Lockfunktion zur Wirkung. Der Powersave Daemon scheint die Shell Scripte in /usr/lib/powersave aufzurufen. Nur da sehe ich im Script do_screen_saver entsprechenden Code (Aufruf von xlock oder xscreensave-command u.a. in Abhaengigkeit vom verwendeten Window System mit entsprechenden Argumenten). Hinweis, wenn nicht schon bereits von Dir so gemacht: Den Bildschirmschoner kannst Du mit der Konfigurationsvariable $POWERSAVE_SCREENSAVER_BLANKONLY=yes auf leeren Bildschirm schalten. Aber bei mir geht es auch mit der Default Einstellung no einwandfrei.
- gestern Kernel aktualisiert auf '
Auf welchen Kernel ? Version kommt bei mir nicht an. Meine Aussagen beziehen sich auf Kernel 2.6.11.4-21.7. Nach anderen Postings zu urteilen gibt es eine neue powersave Version (irgendetwas mit 10). Ein Aufruf von rpm -qi powersave gibt mir die Version 0.9.25. Werde mich um die neue Version die naechsten Tage kuemmern.
Und ich habe jetzt herausgefunden, warum letztens der Suspend2Disk plötzlich überhaupt funktionierte (Mail vom: 27.07.2005 08:29). Der PC war ja immer beim Aufwachen aus dem Suspend hängen geblieben.
Nun, das ist jetzt wieder der Fall.
Ich habe zwei Profile mit SCPM definiert (Home und Firma). Um das Problem mit dem Netzwerk weiter zu testen, habe ich mal wieder auf mein Home-Profil mit fester IP umgeschaltet. Nun bleibt er wieder meim Aufwachen aus S2D hängen.
Scheint also am Netzwerk zu liegen.
Untersuche die Unterschied zwischen Deinen beiden Konfigurationen, in dem Du die eine Version Stueck fuer Stueck (soweit moeglich) in die andere ueberfuehrst. Ich habe ohne Probleme meinen Laptop im Dienst unter dhcp, allerdings mit einer statischen IP-Adresse betrieben. Fuer zu Hause habe ich den Laptop auf feste Adresse umgeschaltet, nicht ueber SCPM sondern durch selbstgestricktes Script.
Ich will den PC in den Urlaub mitnehmen und da wäre mir S2D besonders wichtig. Eventuell hilft es mir, wenn ich ein drittes Profil OHNE Netzwerk einrichte und das dann benutze.
Wenn Du kein Netz (Internetzugang ueber Modem) im Urlaub benoetigst, bietet sich das an. Einen schoenen Urlaub und weiteren Erfolg Gruss Dieter
Grüsse Werner
Hallo Dieter, Am Donnerstag, 11. August 2005 15:49 schrieb Hans-Dieter Schenk:
Hallo Werner, hallo Dejan,
[...]
Bringt leider nichts. Beim Starten des Netzwerkes, wenn er eine IP vom DHCP haben will, stoppt der PC. In dem xterm, in dem ich '/etc/init.d/network start' gemacht hatte, sehe ich noch seine Bemühungen mit dem DHCP.
Was sind die Bemuehungen ? Er sollte sich im Hintergrund bemuehen, aber ansonsten weitermachen.
Ja. In diesem Fall hatte ich das LAN Kabel ausgestoepselt gehabt.
Uebrigends: Das Problem mit 'kdm' ist plötzlich weg. Wenn ich den PC nun ganz normal in Runlevel 5 hochfahren lasse, mit automatischem Login und KDE als WM, danach einen Suspend2Disk mache und ihn, nachdem er wieder oben ist ganz normal über den Ausschaltknopf in KDE runterfahren lasse, macht er keine Probleme mehr.
Aenderungen: - Bildschirmsaver auf 'leeren Bildschirm'
Interessante Fragen. Ich habe gar kein KDE laufen (sondern icewm). Trotzdem kommt bei mir nach dem Resume der Screensaver vom KDE mit der Lockfunktion zur Wirkung. Der Powersave Daemon scheint die Shell Scripte in /usr/lib/powersave aufzurufen. Nur da sehe ich im Script do_screen_saver entsprechenden Code (Aufruf von xlock oder xscreensave-command u.a. in Abhaengigkeit vom verwendeten Window System mit entsprechenden Argumenten). Hinweis, wenn nicht schon bereits von Dir so gemacht: Den Bildschirmschoner kannst Du mit der Konfigurationsvariable $POWERSAVE_SCREENSAVER_BLANKONLY=yes auf leeren Bildschirm schalten. Aber bei mir geht es auch mit der Default Einstellung no einwandfrei.
Ich habe bei mir "yes" eingetragen.
- gestern Kernel aktualisiert auf '
Auf welchen Kernel ? Version kommt bei mir nicht an.
Kein Wunder, ich hatte es vergessen einzutragen. 2.6.11.4-21.8
Meine Aussagen beziehen sich auf Kernel 2.6.11.4-21.7. Nach anderen Postings zu urteilen gibt es eine neue powersave Version (irgendetwas mit 10). Ein Aufruf von rpm -qi powersave gibt mir die Version 0.9.25. Werde mich um die neue Version die naechsten Tage kuemmern. Ich habe die gleiche Version.
Und ich habe jetzt herausgefunden, warum letztens der Suspend2Disk plötzlich überhaupt funktionierte (Mail vom: 27.07.2005 08:29). Der PC war ja immer beim Aufwachen aus dem Suspend hängen geblieben.
Nun, das ist jetzt wieder der Fall.
Ich habe zwei Profile mit SCPM definiert (Home und Firma). Um das Problem mit dem Netzwerk weiter zu testen, habe ich mal wieder auf mein Home-Profil mit fester IP umgeschaltet. Nun bleibt er wieder meim Aufwachen aus S2D hängen.
Scheint also am Netzwerk zu liegen.
Untersuche die Unterschied zwischen Deinen beiden Konfigurationen, in dem Du die eine Version Stueck fuer Stueck (soweit moeglich) in die andere ueberfuehrst. Ich habe ohne Probleme meinen Laptop im Dienst unter dhcp, allerdings mit einer statischen IP-Adresse betrieben. Fuer zu Hause habe ich den Laptop auf feste Adresse umgeschaltet, nicht ueber SCPM sondern durch selbstgestricktes Script.
Ich will den PC in den Urlaub mitnehmen und da wäre mir S2D besonders wichtig. Eventuell hilft es mir, wenn ich ein drittes Profil OHNE Netzwerk einrichte und das dann benutze.
Wenn Du kein Netz (Internetzugang ueber Modem) im Urlaub benoetigst, bietet sich das an.
Einen schoenen Urlaub und weiteren Erfolg
Wenn's geht, dann Antworte bitte nicht mehr auf diese Mail, sondern auf die andere von mir (11.08.2005 15:49:12) bzw. auf den Zusatz, den ich dazu gleich noch schreiben werde. Ich moechte vermeiden, dass sich der Thread noch mehr verzweigt. Eventuell Teile von dieser Mail in die Antwort uebernehmen. Gruss Werner
On Thu, Aug 11, 2005 at 03:49:51PM +0200, Hans-Dieter Schenk wrote:
Aenderungen: - Bildschirmsaver auf 'leeren Bildschirm'
Interessante Fragen. Ich habe gar kein KDE laufen (sondern icewm). Trotzdem kommt bei mir nach dem Resume der Screensaver vom KDE mit der Lockfunktion zur Wirkung. Der Powersave Daemon scheint die Shell Scripte in /usr/lib/powersave aufzurufen. Nur da sehe ich im Script do_screen_saver entsprechenden Code (Aufruf von xlock oder xscreensave-command u.a. in Abhaengigkeit vom verwendeten Window System mit entsprechenden Argumenten). Hinweis, wenn nicht schon bereits von Dir so gemacht: Den Bildschirmschoner kannst Du mit der Konfigurationsvariable $POWERSAVE_SCREENSAVER_BLANKONLY=yes auf leeren Bildschirm schalten. Aber bei mir geht es auch mit der Default Einstellung no einwandfrei.
wenn du kpowersave verwendest, dann sperrt kpowersave den Bildschirm (oder auch nicht, abhängig von der kpowersave-Konfiguration) und was du in die Variable einträgst, wird ignoriert. Das steht auch so im Kommentar über der Variable IIRC.
Auf welchen Kernel ? Version kommt bei mir nicht an. Meine Aussagen beziehen sich auf Kernel 2.6.11.4-21.7. Nach anderen Postings zu urteilen gibt es eine neue powersave Version (irgendetwas mit 10). Ein Aufruf von rpm -qi powersave gibt mir die Version 0.9.25. Werde mich um die neue Version die naechsten Tage kuemmern.
Achtung, die wird nur auf SUSE 10.0 funktionieren, auf 9.3 nicht mehr (dbus, hal und evtl. auch kernel der 9.3 sind zu alt).
Ich habe zwei Profile mit SCPM definiert (Home und Firma). Um das Problem mit dem Netzwerk weiter zu testen, habe ich mal wieder auf mein Home-Profil mit fester IP umgeschaltet. Nun bleibt er wieder meim Aufwachen aus S2D hängen.
Scheint also am Netzwerk zu liegen.
ich würde mal das Netzwerkkartenmodul vor dem suspend entladen. -- Stefan Seyfried
Hallo Werner, Am Dienstag, 9. August 2005 13:46 schrieb Werner Franke:
Danke. Werde mich erst mal mehr auf suspend-to-disk konzentrieren. Ich moechte suspend-to-disk ja hauptsaechlich desswegen, weil der PC schneller unten und wieder oben ist.
Dann musst Du Suspend2Ram waehlen, S2R ist wesentlich schneller als S2D, benoetigt allerdings etwas Strom.
Es koennte ein Schmutzeffekt sein, der sich hier auswirkt ?
Nach Deinen weiteren Beobachtungen, die Du beschreibst, scheint mir hier ein Zusammenhang mit der Netwerkkonfiguration vorzuliegen.
Ich habe den PC nun mal in den Runlevel 3 gestertet, mich eingeloggt und 'startx' aufgerufen. KDE hat problemlos gestartet. Danach 'powersave -U' als 0815-User. Macht er und schaltet sich ab. Einschalten. Startet und landed in KDE, dort, wo ich Suspend2Disk abgesetzt hatte.
Dies bedeutet doch, dass das generelle S2D (und ich nehme an auch S2R) funktionieren.
Das Kommando '/sbin/ifconfig eth0' zeigt mir, dass er zwar IP Adresse hat, aber 'ping <anderer Rechner>' bringt kein Ergebnis. Bei 'ping anderere-IP' bringt 'Destination Host Unreachable'.
(wfranke notebook tcsh) [46] /sbin/route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 123.246.111.0 0.0.0.0 255.255.254.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 123.246.111.1 0.0.0.0 UG 0 0 0 eth0
Wo kommt der erste Eintrag (192.168.0.0) her? Die drei anderen Eintrage sind OK. Mir kommt der Verdacht, dass hier noch etwas zusaetzlich laeuft, was bislang noch nicht angesprochen wurde und evt. die Ursache der Probleme ist. Generell wuerde ich empfehlen, beim Shutdown oder Suspend, ob durch Befehl oder Schliessen des Deckels, eine ppp Internetanbindung vorher zu trennen.
su: (to root) wfranke on /dev/pts/4 ==> als root eingeloggt und 'rcnetwork' dhcpcd[5259]: terminating on signal 15 modify_resolvconf: restored /etc/resolv.conf.saved.by.dhcpcd.eth0 to /etc/resolv.conf kernel: eth0: media 10Base2, silicon revision 4 kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: transmit timed out
Diesen Eintrag im Syslog kenne ich von der SuSE9.2. War durch rcnetwork restart zu beheben. In 9.3 taucht dieser Eintrag nicht mehr auf. Alles was bei Dir an weiteren Meldungen kommt, ist ein Stack Dump, der mit der Meldung des NETDEV WATCHDOG zusammenhaengt.
kernel: scheduling while atomic: kscd/0x00000100/6402 kernel: [<c02d0b79>] schedule+0x4d9/0x590 kernel: [<c01166e4>] activate_task+0x54/0x70
Wenn ich in POWERSAVE_SUSPEND2DISK_RESTART_SERVICES auch 'network' einbaue, dann steht der PC kurze Zeit nach dem Suspend2Disk, wenn er wieder oben ist. -------------------------------------------
Was das oben beobachtete nur bestaetigt, denn die PowersaveScipte machen nichts anderes als rcnetwork stop und nach dem Resume rcnetwork start.
Das Ganze habe ich danach nochmal so gemacht, jedoch diesmal nicht rcnetwork sondern die X-Session ueber den Abmelde-Knopf in KDE beendet und ueber Ctrl+Alt+Del den PC heruntergefahren. Hat funktioniert. Allerdings habe ich folgende Fehlermeldung beim runterfahren gesehen: (Aus /var/log/boot..omsg)
ardmgr[3437]: executing: 'modprobe -r xirc2ps_cs 2>&1' cardmgr[3437]: + FATAL: Module xirc2ps_cs is in use. cardmgr[3437]: modprobe exited with status 1 cardmgr[3437]: executing: 'modprobe -r serial_cs 2>&1' cardmgr[3437]: + FATAL: Module serial_cs is in use. cardmgr[3437]: modprobe exited with status 1 done Shutting down PCMCIA <notice>killproc: kill(3437,15) cardmgr[3437]: exiting
FATAL: Module pcmcia is in use. FATAL: Module yenta_socket is in use. FATAL: Module rsrc_nonstatic is in use. FATAL: Module pcmcia_core is in use. failed ---------------
Diese Meldungen kommen nur dann, wenn vorher mal ein S2D gegeben wurde, also Bedingungen, wie beim killall kdm Problem? Dies bestaetigt meinen Verdacht, dass irgendetwas noch das Interface eth0 belegt. Alle anderen in use Meldungen sind eine Folge, dass der xirc2ps nicht frei gegeben werden kann. Wo das Module serial_cs allerdings herkommt ist mir unklar. Betreibts Du auch eine Modemkarte oder ist Deine Xircom Karte ein Kombi Modul (dass allerdings nach den Kommentaren im Source Code von xirc2ps nicht unterstuetzt wird ? Wenn Du vor dem Suspend ein lsmod | grep xirc2ps machts, muesste eine 0 (bedeutet durch kein weiteres Module benutzt) am Ende der Zeile stehen.
Vielleicht sagt Dir das etwas und Du hast noch eine Idee. Wenn nicht, sollten wir hier abbrechen. Ich moechte Deine Gedult nicht ueber die Massen beanspruchen. Es waere schon wenn es funktioniert s2d hätte, aber irgenwas mauert.
Noch folgende Hinweise zum BIOS meines TECRAs, denen Du nachgehen solltest (ESC druecken unmittelbar nach dem Einschalten): BIOS Version 8.20 PC-CARD Controller Mode steht bei mir auf CardBus/16 Bit. Deine XIRCOM Karte scheint kein Cardbus Module zu sein. Aber probiere hier mal die zwei alternativen Einstellungen. Frag ruhig weiter, vielleicht haben ja auch andere ein paar Ideen zu Deinem Problemfall. Ich habe keine Flatrate und bin deshalb nur alle paar Tage im Netz. Meine Antworten kommen deshalb immer etwas verzoegert. Gruss Dieter
Hallo Dieter, schau Dir bitte auch meine Antwort auf die Mail von Dejan Hrubenja an. Da steht einiges was auch für Dich ist. Am Donnerstag, 11. August 2005 14:26 schrieb Hans-Dieter Schenk:
Hallo Werner,
Am Dienstag, 9. August 2005 13:46 schrieb Werner Franke:
Danke. Werde mich erst mal mehr auf suspend-to-disk konzentrieren. Ich moechte suspend-to-disk ja hauptsaechlich desswegen, weil der PC schneller unten und wieder oben ist.
Dann musst Du Suspend2Ram waehlen, S2R ist wesentlich schneller als S2D, benoetigt allerdings etwas Strom.
Na wenn ich mit S2D im Vergleich zum normalen Booten anschaue, dann ist S2D schon sehr viel schneller. Aber S2R ist noch nicht vergessen ;-)
Nach Deinen weiteren Beobachtungen, die Du beschreibst, scheint mir hier ein Zusammenhang mit der Netwerkkonfiguration vorzuliegen.
Sehe ich auch so. Siehe auch andere Mail.
Ich habe den PC nun mal in den Runlevel 3 gestertet, mich eingeloggt und 'startx' aufgerufen. KDE hat problemlos gestartet. Danach 'powersave -U' als 0815-User. Macht er und schaltet sich ab. Einschalten. Startet und landed in KDE, dort, wo ich Suspend2Disk abgesetzt hatte.
Dies bedeutet doch, dass das generelle S2D (und ich nehme an auch S2R) funktionieren.
Das Kommando '/sbin/ifconfig eth0' zeigt mir, dass er zwar IP Adresse hat, aber 'ping <anderer Rechner>' bringt kein Ergebnis. Bei 'ping anderere-IP' bringt 'Destination Host Unreachable'.
(wfranke notebook tcsh) [46] /sbin/route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 123.246.111.0 0.0.0.0 255.255.254.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 123.246.111.1 0.0.0.0 UG 0 0 0 eth0
Wo kommt der erste Eintrag (192.168.0.0) her? Die drei anderen Eintrage sind OK. Mir kommt der Verdacht, dass hier noch etwas zusaetzlich laeuft, was bislang noch nicht angesprochen wurde und evt. die Ursache der Probleme ist. Generell wuerde ich empfehlen, beim Shutdown oder Suspend, ob durch Befehl oder Schliessen des Deckels, eine ppp Internetanbindung vorher zu trennen.
Da hat keine existiert. Hätte ich wahrscheinlich eh' gemacht. Nur wie komme drauf woher 192.168.0.0 kommt ? Wie ich in der anderen Mail beschrieben habe, habe ich 2 SCPM Profile Home und Firma. Und das Firmen-Profil habe ich vom Home-Profil abgeleitet. Und meine feste IP im Home-Profil ist 192.168.0.5. Könnte da was zurückgeblieben sein ? Wenn ja, wie bekomme ich's weg ? Um dazu nachzusehen, habe ich vom aktuellen Profil 'Keine_IP' nach 'Firma', das auf DHCP eingestellt ist, gewechselt. Irgendwas stimmt da nicht. Er sollte da ja jetzt alles so umgestellt haben und auch das Network Restartet haben. Ich habe sicherheitshalber nochmal gemacht 'rcnetwork restart'. Nur was er mir dabei erzählt ist Unfug (?). Da ich momentan nicht auf den PC komme, muss ich's abschreiben (teilweise): Shutting down ... ... Setting up network interface: lo ... eth0 device: Xircom CEM56 Ethernet/Modem eth0 configuration: eth0-id ... eth0 (DHCP) . . . . IP/Netmask 123.246.111.65 / 255.255.254.0 eth0 IP address 192.168.0.5/24 modem0 ... modem0 Startmode is 'manual' Wieso DHCP UND 192.168.0.5 ??? Wenn ich mir die Settings von der Netzwerkkarte in YAST ansehe, steht alles auf DHCP und ich sehe nirgends was von 192... [...]
Diese Meldungen kommen nur dann, wenn vorher mal ein S2D gegeben wurde, also Bedingungen, wie beim killall kdm Problem? Dies bestaetigt meinen Verdacht, dass irgendetwas noch das Interface eth0 belegt. Alle anderen in use Meldungen sind eine Folge, dass der xirc2ps nicht frei gegeben werden kann. Wo das Module serial_cs allerdings herkommt ist mir unklar. Betreibts Du auch eine Modemkarte oder ist Deine Xircom Karte ein Kombi Modul (dass allerdings nach den Kommentaren im Source Code von xirc2ps nicht unterstuetzt wird ?
Ja die Xircom hat auch ein Modem drin, was sogar problemlos funktioniert. Ich hab's als modem0 eingerichtet und auch schon mal ausprobiert. Mit Kinternet. Bei all meinen Suspend Versuchen, war es allerdings nie in Benutzung. Soll heissen ich habe nie eine Verbindung hergestellt. Was SUSE da im Hintergrund dazu laufen hat, weiss ich nicht.
Wenn Du vor dem Suspend ein lsmod | grep xirc2ps machts, muesste eine 0 (bedeutet durch kein weiteres Module benutzt) am Ende der Zeile stehen.
lsmod | grep xirc2ps xirc2ps_cs 17936 1 pcmcia 24072 6 serial_cs,xirc2ps_cs pcmcia_core 47024 5 serial_cs,xirc2ps_cs,pcmcia,yenta_socket,\ rsrc_nonstatic [...]
Noch folgende Hinweise zum BIOS meines TECRAs, denen Du nachgehen solltest (ESC druecken unmittelbar nach dem Einschalten):
BIOS Version 8.20 PC-CARD Controller Mode steht bei mir auf CardBus/16 Bit. Deine XIRCOM Karte scheint kein Cardbus Module zu sein. Aber probiere hier mal die zwei alternativen Einstellungen.
Mache ich. Gruss Werner
Hallo Dieter, Zusatz... Am Donnerstag, 11. August 2005 15:49 schrieb Werner Franke:
Hallo Dieter,
[...]
(wfranke notebook tcsh) [46] /sbin/route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 123.246.111.0 0.0.0.0 255.255.254.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 123.246.111.1 0.0.0.0 UG 0 0 0 eth0
Wo kommt der erste Eintrag (192.168.0.0) her? Die drei anderen Eintrage sind OK. Mir kommt der Verdacht, dass hier noch etwas zusaetzlich laeuft, was bislang noch nicht angesprochen wurde und evt.
[...]
Shutting down ... ... Setting up network interface: lo ... eth0 device: Xircom CEM56 Ethernet/Modem eth0 configuration: eth0-id ... eth0 (DHCP) . . . . IP/Netmask 123.246.111.65 / 255.255.254.0 eth0 IP address 192.168.0.5/24 modem0 ... modem0 Startmode is 'manual'
Wieso DHCP UND 192.168.0.5 ??? Wenn ich mir die Settings von der Netzwerkkarte in YAST ansehe, steht alles auf DHCP und ich sehe nirgends was von 192...
Habe mir nun mal die Dateien in /etc/sysconfig/network angeschaut und '192.168' darin gesucht. War in 'ifcfg-eth-id-00:...' noch enthalten. Bin dann wieder in YAST -> Netzwerkkarte rein und siehe da, es war zwar der Radio-Button 'DHCP' aktiv, aber in den Feldern fuer die 'feste IP' noch die 192-er Nummern enthalten. Nachdem ich das alles entfernt hatte und abgespeichert hatte sieht die Ausgabe von 'rcnetwork restart' so aus wie ich es erwarten wuerde. Nichts mehr von 192.168.0.5. Und /sbin/route -n bringt nun: 123.246.111.0 0.0.0.0 255.255.254.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 123.246.111.1 0.0.0.0 UG 0 0 0 eth0
[...]
Diese Meldungen kommen nur dann, wenn vorher mal ein S2D gegeben wurde, also Bedingungen, wie beim killall kdm Problem? Dies bestaetigt meinen Verdacht, dass irgendetwas noch das Interface eth0 belegt. Alle anderen in use Meldungen sind eine Folge, dass der xirc2ps nicht frei gegeben werden kann. Wo das Module serial_cs allerdings herkommt ist mir unklar. Betreibts Du auch eine Modemkarte oder ist Deine Xircom Karte ein Kombi Modul (dass allerdings nach den Kommentaren im Source Code von xirc2ps nicht unterstuetzt wird ?
Ja die Xircom hat auch ein Modem drin, was sogar problemlos funktioniert. Ich hab's als modem0 eingerichtet und auch schon mal ausprobiert. Mit Kinternet. Bei all meinen Suspend Versuchen, war es allerdings nie in Benutzung. Soll heissen ich habe nie eine Verbindung hergestellt. Was SUSE da im Hintergrund dazu laufen hat, weiss ich nicht.
Wenn Du vor dem Suspend ein lsmod | grep xirc2ps machts, muesste eine 0 (bedeutet durch kein weiteres Module benutzt) am Ende der Zeile stehen.
lsmod | grep xirc2ps xirc2ps_cs 17936 1 pcmcia 24072 6 serial_cs,xirc2ps_cs pcmcia_core 47024 5 serial_cs,xirc2ps_cs,pcmcia,yenta_socket,\ rsrc_nonstatic
[...]
Noch folgende Hinweise zum BIOS meines TECRAs, denen Du nachgehen solltest (ESC druecken unmittelbar nach dem Einschalten):
BIOS Version 8.20 PC-CARD Controller Mode steht bei mir auf CardBus/16 Bit. Deine XIRCOM Karte scheint kein Cardbus Module zu sein. Aber probiere hier mal die zwei alternativen Einstellungen.
'Auto-Selected' brachte keine Aenderung und bei 'PCIC Compatible' wird kein Interface mehr gefunden. Hab's wieder auf 'Auto-Selected' gestellt. Alle meine letzten Aenderungen haben aber keine Aenderung an den Symtomen gezeigt. Profil Firma (mit DHCP): Nach einem S2D hat der PC zwar noch eine IP (aus: /sbin/ifconfig eth0), aber ein 'ping' zu einem externen Host funktioniert nicht mehr. Bei einem 'rcnetwork start' (vorher ein 'stop') bleibt er stehen wenn eth0 (DHCP) . . als Output kommt. ping zu eigenen IP geht. Ich habe mich gerade mit einem Kollegen unterhalten, der sich mit Netzwerk besser auskennt und zu dem folgenden Schluss gekommen: Nach einem S2D hat der Xircom keinen Interrupt mehr. Bei 'ifconfig eth0' fehlt die entsprechende letzte Zeile in der Ausgabe und bei 'dmesg' lassen die Kernelmeldungen kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: transmit timed out : : kernel: [<c011e1d6>] do_softirq+0x26/0x30 kernel: [<c010528d>] do_IRQ+0x3d/0x60 auch darauf schliessen. (die 'letzte Zeile' mit dem IRQ in 'ifconfig eth0' fehlt jedoch nicht immer nach einem S2D) ifconfig eth0 eth0 Protokoll:Ethernet Hardware Adresse 00:B0:D0:5F:37:11 inet Adresse:123.246.107.117 Bcast:123.246.107.255 Maske:255.255.254.0 inet6 Adresse: fe80::2b0:d0ff:fe5f:3711/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:173 errors:0 dropped:0 overruns:0 frame:0 TX packets:61 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:20026 (19.8 Kb) TX bytes:7532 (7.3 Kb) Interrupt:3 Basisadresse:0x300 <<<===== Ein entlanden der zustaendigen Kernelmodule geht auch nicht. Wahrseinlich weil sie fest im Kernel eingebaut sind (?). Jedenfalls sind sie immer in Use. Auf jeden Fall ist die Anzahl der RX- und TX bytes vor und nach dem S2D gleich und veraendern sich nicht mehr (aufgrund der Ausgaben von 'ifconfig eth0') Hast Du eine Netzwerkkarte in Deinem Tecra und wenn ja funktioniert die ? Habe jetzt mal ein S2R ausprobiert. Ist ja noch 'n Tick ;-) schneller. Kommt auch wieder hoch. Netzwerk geht dann auch nicht. Bei einem S2R muss doch der PC dann dauernd unter Spannung sein, da ja das RAM noch mit Strom versorgt werden muss ? Und der Bildschirm ist nach dem Aufwachen gelockt. Kann man das auch irgendwie abschalten ? Der Mauszeiger ist dann nämlich erst mal einige Zeit weg, bis irgendwann dann das Fenster für's Passwort hochkommt. Das irritiert mich etwas. Ich habe mal die Xircom mit der von einem anderen Tecra ausgetauscht und als DHCP neu eingerichtet. Gleicher Effekt bei S2D. Noch eine andere Frage: Benutzt Du die Video-Out Buchse an der Rueckseite um auf einem TV ein Bild zu sehen ? Wenn ja, wie hast Du das mit der Auflösung gemacht ? Bei 1024x768 wird ja nur ein kleiner Teil dargestellt. Auf eine 720x576 in der xorg.conf kann ich jedoch nicht umschalten. Antwort bitte per PM, da es ja mit dem Thread nichts zu tun hat. Wenn Du was dazu weisst, mache ich lieber noch einen weiteren auf... Gruss Werner
Hallo Werner, Am Freitag, 12. August 2005 12:58 schrieb Werner Franke:
Nach einem S2D hat der Xircom keinen Interrupt mehr. Bei 'ifconfig eth0' fehlt die entsprechende letzte Zeile in der Ausgabe und bei 'dmesg' lassen die Kernelmeldungen
kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: transmit timed out
kernel: [<c011e1d6>] do_softirq+0x26/0x30 kernel: [<c010528d>] do_IRQ+0x3d/0x60
auch darauf schliessen. (die 'letzte Zeile' mit dem IRQ in 'ifconfig eth0' fehlt jedoch nicht immer nach einem S2D) ifconfig eth0 eth0 Protokoll:Ethernet Hardware Adresse 00:B0:D0:5F:37:11 inet Adresse:123.246.107.117 Bcast:123.246.107.255 Maske:255.255.254.0 inet6 Adresse: fe80::2b0:d0ff:fe5f:3711/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:173 errors:0 dropped:0 overruns:0 frame:0 TX packets:61 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:20026 (19.8 Kb) TX bytes:7532 (7.3 Kb) Interrupt:3 Basisadresse:0x300 <<<=====
Ein entlanden der zustaendigen Kernelmodule geht auch nicht. Wahrseinlich weil sie fest im Kernel eingebaut sind (?).
Nein das sind alles Module, die bei Bedarf geladen worden sind. Sie sind deshalb in use, weil das xircom Modul noch belegt ist und zwar durch den Cardmanager. Ziehe die Karte raus und Du (bzw S2D) kannst das Modul entladen (siehe auch Antwort von Stefan Seyfried).
Hast Du eine Netzwerkkarte in Deinem Tecra und wenn ja funktioniert die ?
Ja einwandfrei, ich habe ein Cardbus Modell 3CXFE575CT, das das Modul 3x59x.ko laedt. Das Netz funktioniert auch mit S2D und S2R einwandfrei. Dieses Modul benutzt nicht das Modul pcmcia.ko und ist auch nicht auf den cardmgr angewiesen. Beim Rausziehen der Karte oder Reinschieben piepst es auch nicht. D.h. dies Modul reagiert vollkommen anders als meine Modemkarte (D-LINK DM-560), die ich im zweiten Slot stecken habe. Diese Karte laedt zusaetzlich das pcmcia Modul und benoetigt den Cardmanager. Sie piepst auch beim Reinstecken (2 x) und Rausziehen (1x). Aber sie zickt beim Booten. Wenn die Karte eingesteckt ist und ich manuell oder das pcmcia Startscript den Cardmanager laedt, bleibt der Rechner haengen. Wenn der Cardmanager gestartet wird, wenn die Karte rausgezogen ist und ich sie nach dem Start reinstecke ist alles OK. Das Verhalten beim Betrieb mit minicom ist allerdings wiederrum nicht immer nachvollziehbar (manchmal keine oder wirre Reaktion auf AT-Befehle). Bezueglich S2D verhaelt sie sich fast genau so, wie Deine Netzkarte, z.B. kann ich unter minicom nach dem resume keine AT Antworten bekommen, so als wenn die Karte kein Interrupt mehr verarbeitet. (setserial zeigt allerdings immer noch IRQ 10 an). Da hilft auch kein Entfernen der Karte und Entladen des Moduls serial_cs. Folgerung nach meinem Verstaendnis: Es gibt zwei unterschiedliche Kartenmodule: PCMCIA und CARDBUS, 16-Bit und 32 Bit, 5V und 3.3 V (?). Die einen funktionieren, die anderen haben Probleme. Siehe auch Aussage von Stefan bez. PCMCIA Schrott. Allerdings muss ich sagen, dass die eben beschriebenen Probleme mit der Modemkarte bei einem KNOPPIX-System nicht auftreten. Zu Deinem Problem: Du scheinst eine Art von Karte zu haben, die meiner Modemkarte gleicht. Im folgenden einige Ausdrucke meiner Konfiguration: Befehl: cardctl status Socket 0: 5V 16-bit PC Card function 0: [ready], [bat dead], [bat low] Socket 1: 3.3V CardBus card function 0: [ready] Befehl: cardctl info Socket 0: Vcc 5.0V Vpp1 0.0V Vpp2 0.0V interface type is "memory and I/O" irq 10 [exclusive] [level] speaker output is enabled function 0: config base 0xff80 option 0x5f status 0x08 pin 0x00 io 0x03e8-0x03ef [8bit] Socket 1: Vcc 3.3V Vpp1 3.3V Vpp2 3.3V interface type is "cardbus" irq 11 [exclusive] [level] function 0: Befehl: ifconfig eth0 Link encap:Ethernet HWaddr 00:00:86:5B:DC:B8 inet addr:192.168.0.173 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::200:86ff:fe5b:dcb8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:74 errors:0 dropped:0 overruns:0 frame:0 TX packets:50 errors:0 dropped:0 overruns:0 carrier:10 collisions:0 txqueuelen:1000 RX bytes:8723 (8.5 Kb) TX bytes:9240 (9.0 Kb) Interrupt:11 Base address:0x4800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:222 errors:0 dropped:0 overruns:0 frame:0 TX packets:222 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:17910 (17.4 Kb) TX bytes:17910 (17.4 Kb) Befehl: setserial /dev/modem /dev/modem, UART: 16550A, Port: 0x03e8, IRQ: 10 Befehl: cat /proc/interrupts CPU0 0: 4306143 XT-PIC timer 1: 6474 XT-PIC i8042 2: 0 XT-PIC cascade 5: 201 XT-PIC OPL3-SA2 7: 1 XT-PIC parport0 8: 2 XT-PIC rtc 9: 261 XT-PIC acpi 11: 529 XT-PIC yenta, yenta, uhci_hcd, eth0 12: 104387 XT-PIC i8042 14: 30308 XT-PIC ide0 15: 37420 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0 Interessant, dass hier der IRQ 10 der Modem Karte nicht auftaucht. ???? Befehl: lsmod Module Size Used by serial_cs 9608 1 snd_pcm_oss 58016 0 snd_mixer_oss 19072 1 snd_pcm_oss snd_seq_midi 9632 0 snd_seq_midi_event 7680 1 snd_seq_midi snd_opl3_synth 15620 0 snd_seq_instr 8192 1 snd_opl3_synth snd_seq_midi_emul 7424 1 snd_opl3_synth snd_seq 53264 5 snd_seq_midi,snd_seq_midi_event,snd_opl3_synth,snd_seq_instr,snd_seq_midi_emul snd_ainstr_fm 2560 1 snd_opl3_synth snd_opl3sa2 16100 0 snd_opl3_lib 11136 2 snd_opl3_synth,snd_opl3sa2 snd_hwdep 9248 1 snd_opl3_lib snd_cs4231_lib 25216 1 snd_opl3sa2 snd_mpu401_uart 7552 1 snd_opl3sa2 snd_rawmidi 25120 2 snd_seq_midi,snd_mpu401_uart snd_seq_device 8716 5 snd_seq_midi,snd_opl3_synth,snd_seq,snd_opl3_lib,snd_rawmidi snd_pcm 94216 3 snd_pcm_oss,snd_opl3sa2,snd_cs4231_lib snd_timer 24708 4 snd_seq,snd_opl3_lib,snd_cs4231_lib,snd_pcm snd 60548 17 snd_pcm_oss,snd_mixer_oss,snd_seq_midi,snd_seq_midi_event,snd_opl3_synth,snd_seq_instr,snd_seq_midi_emul,snd_seq,snd_opl3sa2,snd_opl3_lib,snd_hwdep,snd_cs4231_lib,snd_mpu401_uart,snd_rawmidi,snd_seq_device,snd_pcm,snd_timer uhci_hcd 30480 0 bluetooth 47492 0 dazuko 55792 6 toshiba_acpi 5908 2 cryptoloop 3584 0 aes_i586 39296 0 speedstep_lib 4228 0 freq_table 4612 0 thermal 14216 0 processor 24120 1 thermal fan 4996 0 button 7184 0 battery 10244 0 ac 5380 0 nfsd 95304 5 exportfs 5632 1 nfsd nvram 8328 0 autofs4 17540 2 ipv6 237696 12 usbserial 28264 0 pcmcia 24328 5 serial_cs 3c59x 39720 0 mii 4992 1 3c59x edd 10208 0 evdev 9088 0 joydev 9792 0 sg 36384 0 st 37916 0 sr_mod 16676 0 i2c_piix4 8592 0 i2c_core 22032 1 i2c_piix4 usbcore 109272 3 uhci_hcd,usbserial yenta_socket 21256 4 rsrc_nonstatic 10368 1 yenta_socket pcmcia_core 47408 4 serial_cs,pcmcia,yenta_socket,rsrc_nonstatic sd_mod 18192 0 scsi_mod 126024 4 sg,st,sr_mod,sd_mod dm_mod 56700 0 parport_pc 38468 1 lp 11204 0 parport 34120 2 parport_pc,lp soundcore 9056 1 snd snd_page_alloc 10244 2 snd_cs4231_lib,snd_pcm reiserfs 243824 1 ide_cd 38020 0 cdrom 36768 2 sr_mod,ide_cd ide_disk 16768 3 piix 10116 0 [permanent] ide_core 120532 3 ide_cd,ide_disk,piix
Habe jetzt mal ein S2R ausprobiert. Ist ja noch 'n Tick ;-) schneller. Kommt auch wieder hoch. Netzwerk geht dann auch nicht. Bei einem S2R muss doch der PC dann dauernd unter Spannung sein, da ja das RAM noch mit Strom versorgt werden muss ?
Richtig, aber nur fuer das RAM und das haelt je nach Ladungsstand Deines Akkus mehrere Tage, wobei auch mein Akku nicht mehr nach 4 Jahren die volle Kapazitaet bringt.
Und der Bildschirm ist nach dem Aufwachen gelockt. Kann man das auch irgendwie abschalten ?
Unter KDE kannst Du das durch die Konfiguration von kpowersave beeinflussen. Unter anderen Windowsystemen (ich benutze icewm) ist mir das nur durch Manipulation des Scripts /usr/lib/powersave/do_screen_saver geglueckt. Dort gibt es eine Funktion xlock_screen_saver, deren Inhalt auskommentiert wird, also nur das return 0 belassen. Dann kommt der Resume ohne dass der Screen gelockt ist, wieder hoch. Dieses Script und wahrscheinlich noch andere Mechanismen scheinen bei KDE nicht angesprochen zu werden und durch KDE eigenen Code ersetzt zu sein (Dies steigert meine Abneigung gegen KDE noch mehr).
Der Mauszeiger ist dann nämlich erst mal einige Zeit weg, bis irgendwann dann das Fenster für's Passwort hochkommt. Das irritiert mich etwas.
Schlage eine beliebige Taste an (z.B. ALT) und das Fenster kommt.
Ich habe mal die Xircom mit der von einem anderen Tecra ausgetauscht und als DHCP neu eingerichtet. Gleicher Effekt bei S2D.
Gleicher Typ ? Versuch mal einen anderen Typ aufzutreiben.
Noch eine andere Frage: Benutzt Du die Video-Out Buchse an der Rueckseite um auf einem TV ein Bild zu sehen ?
keine Erfahrung. Gruss Dieter
Hallo Dieter, Stefan, Am Montag, 15. August 2005 12:52 schrieb Hans-Dieter Schenk:
Hallo Werner,
Am Freitag, 12. August 2005 12:58 schrieb Werner Franke:
Nach einem S2D hat der Xircom keinen Interrupt mehr. Bei 'ifconfig eth0' fehlt die entsprechende letzte Zeile in der Ausgabe und bei 'dmesg' lassen die Kernelmeldungen
kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: transmit timed out
kernel: [<c011e1d6>] do_softirq+0x26/0x30 kernel: [<c010528d>] do_IRQ+0x3d/0x60
auch darauf schliessen. (die 'letzte Zeile' mit dem IRQ in 'ifconfig eth0' fehlt jedoch nicht immer nach einem S2D) ifconfig eth0 eth0 Protokoll:Ethernet Hardware Adresse 00:B0:D0:5F:37:11 inet Adresse:123.246.107.117 Bcast:123.246.107.255 Maske:255.255.254.0 inet6 Adresse: fe80::2b0:d0ff:fe5f:3711/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:173 errors:0 dropped:0 overruns:0 frame:0 TX packets:61 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:20026 (19.8 Kb) TX bytes:7532 (7.3 Kb) Interrupt:3 Basisadresse:0x300 <<<=====
Ein entlanden der zustaendigen Kernelmodule geht auch nicht. Wahrseinlich weil sie fest im Kernel eingebaut sind (?).
Nein das sind alles Module, die bei Bedarf geladen worden sind. Sie sind deshalb in use, weil das xircom Modul noch belegt ist und zwar durch den Cardmanager. Ziehe die Karte raus und Du (bzw S2D) kannst das Modul entladen (siehe auch Antwort von Stefan Seyfried).
Ja. So funktionierts. Karte rausziehen, Netzwerk wird entfernt und die Kernel Module entfernt, Suspend2{Disk|Ram}, Hochfahren, Karte wieder reinstecken, Netzwerk wird wieder installiert und funktioniert auch. Na das war eine schwere Geburt. Vielen herzlichen Dank nochmal. Grüsse Werner
On Thu, Aug 11, 2005 at 03:49:12PM +0200, Werner Franke wrote:
Da hat keine existiert. Hätte ich wahrscheinlich eh' gemacht. Nur wie komme drauf woher 192.168.0.0 kommt ? Wie ich in der anderen Mail beschrieben habe, habe ich 2 SCPM Profile Home und Firma. Und das Firmen-Profil habe ich vom Home-Profil abgeleitet. Und meine feste IP im Home-Profil ist 192.168.0.5. Könnte da was zurückgeblieben sein ? Wenn ja, wie bekomme ich's weg ?
schau dir mal /etc/sysconfig/network/ifcfg-eth* an, evtl. steht da noch was drin, was nicht (mehr) hineingehört.
Wenn Du vor dem Suspend ein lsmod | grep xirc2ps machts, muesste eine 0 (bedeutet durch kein weiteres Module benutzt) am Ende der Zeile stehen.
lsmod | grep xirc2ps xirc2ps_cs 17936 1 pcmcia 24072 6 serial_cs,xirc2ps_cs pcmcia_core 47024 5 serial_cs,xirc2ps_cs,pcmcia,yenta_socket,\ rsrc_nonstatic
Ziehe die Karte doch vor dem suspend einfach raus und stecke sie _nach_ dem resume wieder rein. PC-Card ist einfach 16bit-ISA-Legacy-Schrott (sorry), der broken by design ist und IMHO mit 2.6er kerneln noch nie so richtig funktioniert hat (zumindest was suspend und resume angeht). -- Stefan Seyfried
participants (4)
-
Dejan Hrubenja -
Hans-Dieter Schenk -
Stefan Seyfried -
Werner Franke