[Fwd: Re: [suse-laptop] powersave daemon lässt sich nicht starten]
kurzer Nachtrag: Jetzt haengt sich das System beim Hochfahren auf. Zwar erhaelt man eine Fehlermeldung, dass der resume file successful gelesen wurde. Danach gibt es jedoch "double fault"s fuer gdt und tss, die anscheinend das Einfrieren verursachen. Soweit ich erkekken kann, sind das keine Module, die etwa entladen werden müssten. Nach dem Regulaeren Hochfahren mit "noresume" ist in /var/log/messages nichts Verdächtiges zu erkennen. Auch die Datei swsusp.log zeigt keine Fehlermeldung und endet mit: Memory info: total used free shared buffers cached Mem: 637076 297208 339868 0 35180 129052 -/+ buffers/cache: 132976 504100 Swap: 1044184 0 1044184 Damit hat sich dann auch die Frage erübrigt, ob der Swapbereich zu klein wäre. Nun ist guter Rat teuer?? -Arne Stefan Behlert wrote:
Moin,
On May 05, 04 15:19:45 +0200, Arne Biastoch wrote:
Hi,
Stefan Behlert wrote:
[...]
sorry, hier hatte ich etwas gemixt. Aber zur Frage: Beim suspend-to-disk (S4) erscheint der Textbildschirm, das System stoppt tasks, entlaedt Module und versucht dann in den Suspend-Zustand zu gehen. Das funktioniert aber nicht und der Rechner geht automatisch wieder in seinen urspruenglichen Zustand. Ich habe im Verdacht, dass die Netzwerkkarte im Spiel sein koennte. In /var/log/messages sehe ich:
[...] Ja, trag mal tg3 in die Liste in POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND= in /etc/sysconfig/powersave/common ein. Das tg3 sollte zwar das suspend nicht beeinträchtigen, aber ohne das einzutragen geht dein Netzwerk hinterher nimmer.
Interessant wären die Dateien /var/log/swsusp.log und /var/lib/swsusp-state. (Trivial Frage: Deine swap-Partition ist gross genug für deinen Speicherinhalt?)
Kurze Nachfrage: Warum geht denn das suspend-to-ram nicht? Ich dachte immer, das waere eher einfacher zu realisieren als suspend-to-disk.
Nein. Hängt mit Initialisierung von Geräten durch das BIOS zusammen.
Achja, ich lese die Liste, bitte spare die Kopie an mich...auch wenn ich da zweimal lese wird's nicht besser :)
-Arne
Stefan
-- *** please note new Institute name and Email address *** Dr. Arne Biastoch Leibniz-Institut für Meeresforschung IFM-GEOMAR FB1 Climate Dynamics phone: ++49 431 600-4013 Duesternbrooker Weg 20 fax : ++49 431 600-1515 24105 Kiel, Germany email: abiastoch@ifm-geomar.de http://www.ifm-geomar.de http://biastoch.de -- *** please note new Institute name and Email address *** Dr. Arne Biastoch Leibniz-Institut für Meeresforschung IFM-GEOMAR FB1 Climate Dynamics phone: ++49 431 600-4013 Duesternbrooker Weg 20 fax : ++49 431 600-1515 24105 Kiel, Germany email: abiastoch@ifm-geomar.de http://www.ifm-geomar.de http://biastoch.de
On May 05, 04 21:09:45 +0200, Arne Biastoch wrote:
kurzer Nachtrag: Jetzt haengt sich das System beim Hochfahren auf. Zwar erhaelt man eine Fehlermeldung, dass der resume file successful gelesen wurde. Danach gibt es jedoch "double fault"s fuer gdt und tss, die anscheinend das Einfrieren verursachen. Soweit ich erkekken kann, sind das keine Module, die etwa entladen werden müssten.
Nach dem Regulaeren Hochfahren mit "noresume" ist in /var/log/messages nichts Verdächtiges zu erkennen. Auch die Datei swsusp.log zeigt keine Fehlermeldung und endet mit:
Memory info: total used free shared buffers cached Mem: 637076 297208 339868 0 35180 129052 -/+ buffers/cache: 132976 504100 Swap: 1044184 0 1044184
Damit hat sich dann auch die Frage erübrigt, ob der Swapbereich zu klein wäre.
Nun ist guter Rat teuer??
Wie gesagt, schick doch mal die genannten Dateien (/var/log/swsusp.log /var/lib/swsusp-state). Komplett. Würde evtl. einiges leichter machen. Die sind naemlich dafür da, sowas zu finden :) Beim Hochfahren aufhängen deutet immer auf Module die entladen werden müssen hin. In der Defaultmaessig mit ausgelieferten /etc/sysconfig/powersave/common stehen sicherlich nicht alle betroffenen Module, nur die, die bereits bekannt sind. Stefan
-Arne
-- Stefan Behlert
On Wed, May 05, 2004 at 09:09:45PM +0200, Arne Biastoch wrote:
kurzer Nachtrag: Jetzt haengt sich das System beim Hochfahren auf. Zwar erhaelt man eine Fehlermeldung, dass der resume file successful gelesen wurde. Danach gibt es jedoch "double fault"s fuer gdt und tss, die anscheinend das Einfrieren verursachen. Soweit ich erkekken kann, sind das keine Module, die etwa entladen werden müssten.
Zeig mir die /var/log/swsusp.log. Ich möchte fast wetten, daß ein AGP-Modul geladen ist. Wenn nicht, ist die swsusp.log noch interessanter, denn dann hast du ein anderes suspend-verhinderndes Modul geladen.
Nach dem Regulaeren Hochfahren mit "noresume" ist in /var/log/messages nichts Verdächtiges zu erkennen. Auch die Datei swsusp.log zeigt keine Fehlermeldung und endet mit:
Womit fängt sie an? Bzw: welche Module waren geladen?
Damit hat sich dann auch die Frage erübrigt, ob der Swapbereich zu klein wäre.
Wäre der Swap zu klein, würde der suspend fehlschlagen und die Maschine einfach weiterlaufen.
Nun ist guter Rat teuer??
Nein. Ich bin mir sicher, daß deine Maschine ein "böses" Modul geladen hat. BTW: vergiss suspend-to-ram (s3) erstmal, das wird so bald nicht gehen. Genauer gesagt: suspend geht schon, aber mit dem resume wirst du schwierigkeiten haben. -- Stefan Seyfried
Stefan Seyfried wrote:
Wäre der Swap zu klein, würde der suspend fehlschlagen und die Maschine einfach weiterlaufen.
Das passiert bei mir übrigens recht häufig (bei 512 MB Hauptspeicher und ca. 1GB Swap) schon bei relativ wenig laufenden Programmen. Kann man da noch irgendwas konfigurieren, dass Suspend vorher Speicher freiräumt? Tschüss, Stefan Rüping -- *VORSICHT* Meine Nachrichten könnten Ironie enthalten.
Moin, On May 07, 04 12:26:24 +0200, Stefan Rueping wrote:
Stefan Seyfried wrote:
Wäre der Swap zu klein, würde der suspend fehlschlagen und die Maschine einfach weiterlaufen.
Das passiert bei mir übrigens recht häufig (bei 512 MB Hauptspeicher und ca. 1GB Swap) schon bei relativ wenig laufenden Programmen. Kann man da noch irgendwas konfigurieren, dass Suspend vorher Speicher freiräumt?
hm, was meinst du mit 'relativ häufig'? Jedes zweite Mal, einaml alle 10 Versuche? Ich höre so einen Fall zum ersten Mal, daher zwei Fragen: Bist Du sicher, dass es am swap und vielem Speicher liegt, und nicht an was anderem? Oder anders geragt: Wieviel swap belegst Du denn? Das Problem kann auch sein, wenn der Rechner nicht genug Speicher 'am Stück' freiräumen kann/findet, dann scheitert der Suspend auch. Stefan
Tschüss,
Stefan Rüping
-- Stefan Behlert
Stefan Behlert wrote:
hm, was meinst du mit 'relativ häufig'? Jedes zweite Mal, einaml alle 10 Versuche?
Hmm, schwer zu sagen, ich benutze Suspend jetzt seit einer Woche und in der Zeit ist es mir drei- oder viermal passiert. Also nicht sehr häufig, aber ich kann mich eben auch nicht darauf verlassen, dass der Rechner auch runterfährt, wenn Suspend einmal läuft. Jedenfalls ist das Suspend in diesen Fällen mit der Meldung gescheitert, dass nicht genügend Speicher frei ist, ohne dass ich speicherintensive Anwendungen laufen hätte. Naja, ich werde mal die Augen offenhalten und wenn das das nächste Mal passiert ein paar mehr Informationen sichern. Ich wollte erstmal nur hören,ob es vielleicht noch Konfigurationsmöglichkeiten gibt, die man mal ausprobieren könnte. Tschüss, Stefan Rüping -- *VORSICHT* Meine Nachrichten könnten Ironie enthalten.
On Fri, May 07, 2004 at 01:09:52PM +0200, Stefan Rueping wrote:
Naja, ich werde mal die Augen offenhalten und wenn das das nächste Mal passiert ein paar mehr Informationen sichern. Ich wollte erstmal nur hören,ob es vielleicht noch Konfigurationsmöglichkeiten gibt, die man mal ausprobieren könnte.
Hm, bisher nicht. Ein Tip zum debugging: mit Strg-Alt-F1 auf Konsole 1 wechseln, dann mit "Alt-Links" auf Konsole 63 - dort sind die Suspend- Meldungen zu sehen. Dummerweise können nicht alle suspend-Meldungen ins syslog geschrieben werden, aber dort sollten sie stehen. -- Stefan Seyfried
participants (4)
-
Arne Biastoch -
Stefan Behlert -
Stefan Rueping -
Stefan Seyfried