[gelöst]: Wheezy: Neuerdings kein Awake aus suspend-to-ram

[chmeyer]

Hallo allerseits,

mein Wheezy-Rechner wacht neuerdings nicht mehr ordnungsgemäß aus dem suspend-to-ram (Gnome3: Bereitschaft) auf.
Der Rechner fängt zwar an zu brummen und die Beleuchtung des Monitors geht an, aber es kommt kein Anmeldefenster mehr, lediglich der Cursor ist oben links zu sehen.
Mit Strg-Alt kann ich zwar auf ein anderes virtuelles Terminal umschalten und den Benutzernamen (root) eingeben, doch nach der Entertaste und noch vor dem Passwort friert das System komplett ein frage ich mich, ob das beim System ankommt, denn <Enter> funktioniert nur noch wie <LF> im Texteditor, das System scheint die Eingaben nicht zu verarbeiten. Es kommt auch keine Passwortabfrage und die gedrückten Zeichen erscheinen einfach auf dem Bildschirm.
SysRQ funktioniert, doch dann hängt der Rechner bei der ersten BIOS-Meldung und möchte unbedingt kalt gestartet werden.

1. Idee: Hardwarefehler: Gab es früher schonmal, Prime95 und memtest86+ laufen jetzt aber ohne Probleme zu finden.
2. Idee: Softwareupdate? pm-suspend.log notiert das letzte "Awake": Mon Mar 11 22:28:31 CET 2013, am nächsten Morgen ging es nicht mehr. In dem Zeitraum habe ich laut dpkg.log und apt/history.log keine Programme installiert.
3. Idee: Zerstörte Config? Im entsprechenden Zeitraum hatte ich versucht mit gdb einem LibreOffice oder X bug auf die Spur zu kommen und dabei wiederholt X abgeschossen. Aber sämtliche in dieser Zeit geänderten Dateien (gnome-search-tool) liegen in /home (Browsercache). lost+found von / und /home sind leer.

Hat jemand noch eine Idee? pm-tools habe ich schon neu installiert.
Habe ich irgendwelche logs vergessen?
Warum klappt die Bereitschaft zuerst wunderbar und dann plötzlich nicht mehr?

Viele Grüße
Christian

EDIT: 17.3. Korrektur und genauere Beschreibung des Verhaltens auf VT*

[zoe]

Hi,

klappt es, wenn du /usr/sbin/pm-suspend als root ausführst?

[chmeyer]

Hallo zoe,
danke für die Nachfrage.
Nein, auch /usr/sbin/pm-suspend als root führt genau zu dem beschriebenen Verhalten. Suspend klappt, aufwachen nicht.

Christian

[zoe]

Und wenn du davor die X-Sitzung stoppst und dann auf einem tty in Suspend gehst? Noch so eine Idee wäre, X zu stoppen, nach Runlevel 1 zu wechseln und es dann nochmal zu versuchen.

[chmeyer]

Danke für den Hinweis. Auch nach "init 1" das gleiche Problem.
Immerhin gab es hier eine Fehlermeldung vor dem Suspend, die auch noch beim fehlerhaften "aufwachen" noch zu lesen war:
[abc.xyz] ata3: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x7
[abc.xyz] ata3: SError: { HostInt }

Ein wenig google: Kernelbugs, SATA-Verbindungskabel, Staub an den Kontakten, ...?
Probehalber habe ich alle USB Geräte abgezogen, und voilla: es geht wieder!

Merkwürdig ist nur, das dieser Fehler plötzlich aufgetreten ist, die USB Geräte sind schon länger am Rechner.
Im Moment habe ich meinen Fritz-WLAN-Stick v2 in Verdacht. Er hat neben dem WLAN auch noch eine zweite Funktion nämlich USB-Speicher mit dem Windowstreiber (statt CD und für Linux nicht nutzbar).
Ich werde es noch eine Weile beobachten und dann (hoffentlich) den Thread als "gelöst" markieren.

Vorerst vielen Dank für Deine Hilfe!

Christian

[zoe]

https://ata.wiki.kernel.org/index.php/L ... r_messages Hast du das gefunden?

[chmeyer]

Mit neu angeschlossenem WLAN-Stick ist der Rechner jetzt wieder einmal hängengeblieben und zweimal ordnungsgemäß aufgewacht, ohne WLAN-Stick gab es bisher keinen "Hänger".

Nein, die Adresse kannte ich noch nicht.
Es ist also ein "Host bus adapter internal error" des ATA Geräts auf Port 3. Spricht also gegen einen Fehler der USB Geräte.

$ lspci | grep ATA
00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode]

Port 1 und 2 sind (laut Gnome Laufwerksverwaltung) Festplatte und CD-ROM. Intern habe ich weiter nichts, Port 3 und 4 sollten frei sein:
# dmesg | grep ata3
[ 1.534922] ata3: SATA max UDMA/133 abar m1024@0xfebf7c00 port 0xfebf7e00 irq 22
[ 1.852183] ata3: SATA link down (SStatus 0 SControl 300)
Wenn ich das richtig verstehe, dann sieht das auch der SATA Controller so.
Irgendwie spricht ein nicht vorhandenes Gerät ja auch gegen Staub oder einen Wackelkontakt am Stecker.

Oder sollte es doch ein "Host bus adapter internal error" des ganzen Controllers sein? Aber dann: Warum Port 3?
Dein Link sagt auch zu "internal error": "Hardware flagged an impossible condition, most likely due to software misprogramming.", was ja wieder alles Mögliche denkbar macht, wie etwa Fehler in libata. pm-suspend, Kernel, ... .


Christian

[zoe]

Na ja, dachte, dass das vielleicht beim Übersetzen hilft. . . Habe mich jetzt mal noch ein bisschen schlauer gelesen. In /etc/pm/config.d kann man wohl eine Datei modules (o. ä.) anlegen, mit der man verschiedene Module vor dem Suspend entladen kann, vielleicht kannst du das damit beheben. Ungefähr dieser Inhalt:

Code: Alles auswählen

SUSPEND_MODULES="ehci_hcd uhci_hcd ohci_hcd usbcore"

aber ohne Gewähr.

[chmeyer]

Hab vielen Dank für Deine Hinweise zoe,

Deine Anregung mit /etc/pm/config.d habe ich nicht mehr ausprobiert, weil mein Rechner im Moment (ohne WLAN Stick) wunderbar fuinktioniert, das scheint also tatsächlich die Ursache gewesen zu sein.
Zum Glück ist der PC auch noch per Kabel angebunden, so das ich auf WLAN verzichten kann und den Stick halt nur bei Bedarf einstecke. Das ist im Moment die einfachste Löung für mich. Trotzdem war es wieder einmal interessant etwas mehr vom (manchmal merkwürdigen) Innenleben des Rechners zu erfahren.

Danke.

Christian