Sleep/Hibernate auf dem Dell E6400

wbwb · 4 Mai 2011

Hallo,
ich versteh' nicht warum die Mädels und Jungs von openSUSE es einfach nicht hinbringen ihrer geneigten Nutzerschaft ein ein-für-allemal stabiles Sleep/Hibernate anzubieten. Das ist dermaßen zum :zensur: !!!
Sorry ... zur Sache:

Ich habe hier einen schon ca. 2 Jahre alten DELL E6400. Auf dem lief bis vor 4 Wochen eine SuSE 11.1. Damit hatte ich up-times von mehreren Wochen mit x-fachem und völlig stabilen sleep u./o. hibernate. Warum ich das Ding überhaupt noch gebootet habe weiß ich nicht.

Jetzt läuft genau auf demselben Gerät, mit derselben Hardware (bis auf eine neue Platte), eine SuSE 11.4 und seitdem kommt die Kiste erratisch und ca. nach jedem 2-4ten mal, sowohl nach dem suspend to RAM als auch nach dem suspend to Disk nicht mehr hoch: nach dem Wiedereinschalten kommt es nicht mehr zum Start vom Windowsmanager, sondern ich bekomme nur die boot-Konsole zu sehen. Auf der steht:
WARNING: Number of errors:0, skipped probes: xxx
(xxx ist irgendeine Zahl) und dann hängt die Kiste = regiert nicht mehr auf die Tastatur.
In diesem Zustand helfen dann nur noch Magic SysRq keys wenn man nicht einfach auf den 'Aus'-Knopf drücken möchte.

Ich habe meine /var/log/messages zwischen dem Beginn des suspend to RAM und einem solchen 'Aufhängen' des Systems auf http://nopaste.info/2d7b4194c6.html abgelegt. (Nach der letzten Zeile des Posts sieht man im log nur, dass ich anfange die Magic SysRq keys zu nutzen um das System zu killen.)

Kann jemand daraus ablesen warum das Aufwachen aus Sleep/Hibernate bei mir nicht klappt. Weitere Infos die helfen gebe ich natürlich auch gern noch.
Danke,
wbwb

spoensche · 4 Mai 2011

wbwb schrieb:
Hallo,
ich versteh' nicht warum die Mädels und Jungs von openSUSE es einfach nicht hinbringen ihrer geneigten Nutzerschaft ein ein-für-allemal stabiles Sleep/Hibernate anzubieten. Das ist dermaßen zum :zensur: !!![/code]

Sie bieten stabiles Hibernating und können nichts dafür, wenn du es nicht oder nicht richtig konfiguriert hast oder die Ursache möglicherweise folgendes ist:

Code:

# May 4 18:00:45 dell1 kernel: [29907.648886] ACPI handle has no context! # May 4 18:00:45 dell1 kernel: [29907.650014] ACPI handle has no context!

Poste mal die Ausgabe von

Code:

dmesg | grep -i error

und von

Code:

grep -i error /var/log/pm-suspend.log

wbwb · 4 Mai 2011

hmmm,

willst Du die errs aus dmesg und pm-suspend.log von irgendeinem x-beliebigen boot und suspend Vorgang sehen oder muss ich erst wieder so einen 'Aufwach-Crash' produzieren und dann pm-suspend.log unmittelbar danach hernehmen?

Ich frage deshalb, weil die Kiste nach dem letzten Crash jetzt schon wieder einmal erfolgreich suspend-ed worden ist und weil:
1) der output von grep -i error /var/log/pm-suspend.log im Moment leer ist und
2) der von dmesg | grep -i error nur einen error hat, der aber wohl nix mit Sleep/Hibernate zu tun hat, nämlich

Code:

[  417.680840] packagekitd[8085]: segfault at 40530 ip 00007f1703d8046d sp 00007f16ff560a50 error 6 in libzypp.so.810.2.1[7f170398d000+4ca000]

Außerdem

spoensche schrieb:
Ursache möglicherweise

Code:

# May 4 18:00:45 dell1 kernel: [29907.648886] ACPI handle has no context! # May 4 18:00:45 dell1 kernel: [29907.650014] ACPI handle has no context!

Kannst Du mir bitte diesbezüglich etwas mehr sagen? Welches/r ACPI handle/r? Kann man aus dieser Meldung mehr machen?

spoensche schrieb:
Sie ... können nichts dafür, wenn du es nicht oder nicht richtig konfiguriert hast

was/wo/wie könnte ich als einfaches kleines Member-Pinguinchen Sleep/Hibernate "konfigurieren"? Es sei denn das installieren einer 11.4 gilt auch schon als konfigurieren

. Ich bin froh wenn mir die Gurus hier helfen den Fehler loszuwerden.

Danke,
wbwb

wbwb · 4 Mai 2011

Noch ein Zusatz:

spoensche schrieb:
Ursache möglicherweise

Code:

# May 4 18:00:45 dell1 kernel: [29907.648886] ACPI handle has no context! # May 4 18:00:45 dell1 kernel: [29907.650014] ACPI handle has no context!

also ich habe mal

Code:

find . -name '*' -exec grep -l "ACPI handle has no context!" '{}' \;

über die Kernel-Quellen laufen lassen.
Da gibt es nur eine einzige Funktion, nämlich
int acpi_pm_device_sleep_state(struct device *dev, int *d_min_p)
in
/usr/src/linux-2.6.37.6-0.5/drivers/acpi/sleep.c
die genau diese Message auswirft. Wenn man nun ein wenig Google-t, dann bekommt man zumindest hier
http://thread.gmane.org/gmane.linux.acpi.devel/41197/focus=41198 die Aussage:

gmane.linux.acpi.devel schrieb:
Most likely, the messages are from acpi_pm_device_sleep_state(), which on some
buses (PCI for one example) is called for all devices regardless of whether or
not they have the corresponding ACPI devices. If they don't, this message is
printed and it's a KERN_DEBUG message. It's totally harmless.

???
wbwb

spoensche · 5 Mai 2011

Poste mal die Ausgabe von

Code:

pm-is-supported --hibernate

wbwb · 5 Mai 2011

Code:

~>pm-is-supported --hibernate
~>

d.h. kein output

josef-wien · 5 Mai 2011

[i schrieb:
manpage[/i] von pm-is-supported"]The result of the test for a certain powermanagement state is defined by the following exit codes.

Code Diagnostic
0 State available.
1 State NOT available.

Code:

pm-is-supported --hibernate ; echo $?

wbwb · 6 Mai 2011

ok., dann eben so:

Code:

~>pm-is-supported --hibernate ; echo $?
0
~>pm-is-supported --suspend ; echo $?
0
~>pm-is-supported --suspend-hybrid ; echo $?
0

spoensche · 12 Mai 2011

Versuch mal folgendes:

Lege mal die Datei /etc/pm/config.d/00sleep_module mit folgendem Inhalt an:

Code:

SLEEP_MODULE=uswsusp

Danach führst du mal

Code:

pm-suspend-hybrid

aus.

wbwb · 29 Mai 2011

Hallo,
dieser Thread besteht hoffentlich immer noch(!?) - ich musste nur erst einmal Bedingungen schaffen, so dass ich in einer Situation in der der E6400 nicht richtig aufwacht jeweils einen andern Rechner 'griffbereit' habe mit dem ich dann per SSH auf den E6400 komme. Die Hoffnung wäre, dass dann hier jemand 'weiter weiß' ....

Bisher nur folgendes: wenn der E6400 nicht aufwacht (also genau in dem Zustand ist, den ich am Anfang des Threads geschildert habe) und ich mich dann von außen einlogge, dann steht Xorg mit 100% CPU Last im top. (Die Xorg logs in /var/log sagen mir als Einfach-Pinguin nicht so viel.)

Jetzt meine Frage: wenn der Laptop das nächste Mal nicht aufwacht möchte ich hier einen möglich vollständigen Satz von Infos aus dem Ding posten. Was sollte ich da alles reinpacken?

wbwb · 29 Mai 2011

Hallo,
ich bin jetzt nicht mehr ganz sicher ob die Problematik immer noch in diesen Teil des Forums gehört (wenn nein, dann bitte sagen wohin) - der Thread hat hier halt angefangen ...

Also hier schon mal den letzten tail von Xorg.0.log nachdem das Problem aufgetreten ist:

Code:

~> tail Xorg.0.log
[  3389.473] (**) Option "xkb_rules" "evdev"
[  3389.473] (**) Option "xkb_model" "evdev"
[  3389.473] (**) Option "xkb_layout" "de"
[  3389.473] (**) Option "xkb_variant" "nodeadkeys"
[  4857.592] (II) config/udev: removing device IR-receiver inside an USB DVB receiver
[  4857.592] (II) IR-receiver inside an USB DVB receiver: Close
[  4857.593] (II) UnloadModule: "evdev"
[  4872.861] (II) Open ACPI successful (/var/run/acpid.socket)
[  4872.980] (II) NVIDIA(0): Setting mode "CRT-0:nvidia-auto-select@1280x1024+0+0"
[  4880.338] (EE) NVIDIA(0): WAIT: (E, 0, 0x887d, 0)

wenn man nach der letzten Zeile, also diesen xorg error Googelt, dann bekommt man 'Einiges'. Bin aber nicht sicher ob das auf meinem Fall zutrifft. Ich finde da im wesentlichen zwei Sachen: Das eine bezieht sich i.d. Tat auf Systeme die nach dem Sleep/Hibernate oder nach Screensaver-Einschalten nicht wieder hochkommen. Das Problem scheint da das DPMS zu sein. Bei mir ist aber:

Code:

~> less Xorg.0.log | grep DPMS
[   244.225] (II) Loading extension DPMS                                                                                       
[   246.491] (==) NVIDIA(0): DPMS enabled

Das sieht nicht nach einem Problem aus? Dann scheint es da noch im Zusammenhang mit 'iommu' und Virtualisierung im BIOS enabled ein Problem zu geben, dass im Xorg.0.log über die Keys DMAR/DRHD irgendwie(?) zu erkennen sein soll(?). Das scheint aber nur Fälle zu betreffen, bei denen der XServer schon beim Booten nicht startet. Das ist bei mir nicht der Fall. Anyway, steht in meiner Xorg.0.log dazu folgendes

Code:

~> less Xorg.0.log | grep DMAR
[    0.000000] ACPI: DMAR 00000000df460400 000B0 (v01 DELL    M09     27D80B15 ASL  00000061)                                  
[    0.013094] DMAR: Host address width 36                                                                                     
[    0.013096] DMAR: DRHD base: 0x000000fed10000 flags: 0x0                                                                    
[    0.013108] DMAR: DRHD base: 0x000000fed13000 flags: 0x1                                                                    
[    0.013115] DMAR: RMRR base: 0x000000dfbe7000 end: 0x000000dfbfffff                                                         
[    0.013117] DMAR: No ATSR found                                                                                             
[    0.279203] DMAR: Forcing write-buffer flush capability                                                                     
[    0.279204] DMAR: Disabling IOMMU for graphics on this chipset

Das sagt mir nichts?

Dazu auch nochmal: an der Hardware und am BIOS meines Laptops habe ich nichts verändert. Nur aus der SuSE 11.1 ist eine 11.4 geworden. Unter der 11.1 hatte ich auch schon einen Nvidia Treiber und kein Problem. (Virtualisierung ist in meinem BIOS auch seit der 11.1 enabled, weil die VirtualBox das braucht).

Ansonsten gibt es in Xorg.0.log nur noch eine err-msg, die aber schon beim Booten auftritt, also unabhängig davon ob die Kiste beim Sleep/Hibernate einfriert oder nicht:

Code:

~> less Xorg.0.log | grep \(EE\)
(EE) HID 04f3:0103: failed to initialize for relative axes.

Hilfe wäre wirklich sehr willkommen, wbwb

spoensche · 29 Mai 2011

wbwb schrieb:
Bisher nur folgendes: wenn der E6400 nicht aufwacht (also genau in dem Zustand ist, den ich am Anfang des Threads geschildert habe) und ich mich dann von außen einlogge, dann steht Xorg mit 100% CPU Last im top. (Die Xorg logs in /var/log sagen mir als Einfach-Pinguin nicht so viel.)
Jetzt meine Frage: wenn der Laptop das nächste Mal nicht aufwacht möchte ich hier einen möglich vollständigen Satz von Infos aus dem Ding posten. Was sollte ich da alles reinpacken?

Interessant ist die Ausgabe von:

Code:

 egrep "EE|WW" /var/log/Xorg.0.log

Code:

 cat /var/log/pm*.log

Code:

ps aux

Edit:
Poste mal die Ausgabe von

Code:

hwinfo --gfxcard

. Deine xorg.conf ist auch hilfreich.

wbwb · 15 Juli 2011

spoensche schrieb:
Interessant ist die Ausgabe von:

Code:

egrep "EE|WW" /var/log/Xorg.0.log cat /var/log/pm*.log ps aux hwinfo --gfxcard

Siehe
http://nopaste.info/2678c90cab.html
http://nopaste.info/3e32236b45.html
http://nopaste.info/b1ad1fa526.html
http://nopaste.info/9b44889278.html

spoensche schrieb:
Deine xorg.conf ist auch hilfreich.

Seit X11R7 habe ich keinen xorg.conf file mehr wie früher, aber ich kann nvidia-settings dazu veranlassen einen ad-hoc xorg.conf file zu schreiben. Siehe http://nopaste.info/576d0252e6.html

Ich möchte noch einmal betonen, dass es immer wieder der gleiche Fehler im Xorg log ist, mit dem sich der X-Server verabschiedet, wenn die Maschine nach den Sleep/Hibernate nur bis zum eingefrorenen Konsolen-Log-in hochfährt, nämlich:

Code:

(EE) NVIDIA(0): WAIT: (E, 0, 0x887d, 0)

Weiß jemand zu diesem Fehler mehr als das, was ich hier am 29. Mai schon gepostet hatte?

(Der andere Xorg error "failed to initialize for relative axes." erscheint auch bei erfolgreichen Boot/Sleep/Hibernate Vorgängen.)

wbwb

Sleep/Hibernate auf dem Dell E6400

wbwb

Hacker

spoensche

Moderator

wbwb

Hacker

wbwb

Hacker

spoensche

Moderator

wbwb

Hacker

josef-wien

Ultimate Guru

wbwb

Hacker

spoensche

Moderator

wbwb

Hacker

wbwb

Hacker

spoensche

Moderator

wbwb

Hacker