Arch Linux

Suspend to RAM

fs4000

Hallo,
ich hab zwar schon einige Erfahrung mit STR unter Linux, aber auf meinem Rechner hier wollt das nie richtig funktionieren. Deshalb wollt ich mal fragen, ob euch noch irgendwas einfällt.
Also es ist so, egal mit was ich den Rechner in den Standby schalte (s2ram, pm-utils, hibernate-script oder echo -n mem > /sys/power/state), schaltet er sich auch ordnungsgemäß aus, das Problem kommt erst beim Wieder-Einschalten. Dann kommt nämlich nicht wieder der alte Bildschirm, sondern nach etwa 1-2 Sek. mehr als beim normalen Einschalten das BIOS und der Rechner fährt hoch, als sei nix gewesen. Ob mit X oder ohne macht dabei keinen Unterschied, ich habe auch bereits die acpi_sleep Bootoptionen s3_bios und s3_mode versucht, half aber nix.
Bei meinen anderen Distributionen, die ich hatte, war es immer genauso. Suspend to Disk hingegen funktioniert tadellos.
Also hat irgend jemand eine Idee? Vielen Dank!

fs4000

Ich habe mich eben noch ein wenig mit DSDTs rumgeschlagen und hab mal meine "ausgebessert" soweit ich das überhaupt verstehe. 😉 Also ich hatte mal 10 Errors und 2 Warnings, die sind jetzt alle weg.
Also wenn mir hier keiner dringlichst davon abrät, diese DSTD zu laden, dann binde ich sie mal in die initcpio ein und hoffe dass nix schlimmes passiert. 😃

Ne ganz nette Anleitung gibts hier: http://forums.gentoo.org/viewtopic.php?t=122145

Also ich kanns ja echt nicht verstehen, wie man so kaputten Müll (BIOS mit fehlerhafter ACPI-Implementierung) eigentlich verkaufen kann. Naja, Microsoft machts ja genauso. <laugh>

Jetzt habe ich gerade noch ein ganz anderes Problem entdeckt:
Ich wollte, wie vorgeschlagen, mal mit acpi_os_name="Microsoft Windows XP" booten. Da gibts aber ne schöne Fehlermeldung von Initcpio:

:: Loading Initramfs
export: 44: XP": bad variable name

Und dann halt noch kernel panic - ...

[gelöscht]

iasl würde ich auch nicht ganz vertrauen!
ich hatte zb. mit ältere iasl ver.??? keine errors und paar Warnungen und mit neure iasl mehrere errors und mehrere Warnungen... (das war aber vor ca. 2 jahre...)

Also ich kanns ja echt nicht verstehen, wie man so kaputten Müll (BIOS mit fehlerhafter ACPI-Implementierung) eigentlich verkaufen kann. Naja, Microsoft machts ja genauso.

und wieso funktioniert dann STR unter Windows ohne Probleme?
naja, nix gegen Linux bzw. gegen Linux-Kernel, aber da hat sich ACPI seit jahren nicht verbessert bzw. Die Kernel Entwickler scheint das sehr kompliziert zu sein....

ich würde an deine stelle custom-DSDT entfernen und mit PM-UTILS versuchen bzw. so PM-UTILS so konfigurieren das er vor STR erst manche dienste beendet, dann treibe (wie wlan, sound u.s.w), dann tty1 wechselt und erst dann soll dein PC in STR gehen... wie du das machst steht glaube ich in wiki.

fs4000

Ja wenn ich das nicht schon alles versucht hätte. Ich habs schon versucht im single-user-mode, mit init=/bin/bash (das geht bei Arch leider nicht), in Runlevel 3, in X, mit und ohne Framebuffer und das auch noch mit einigen Distributionen, aber immer dasselbe Problem.
Ich hab inzwischen sogar mal den Kernel mit Suspend-Debug-Funktionen gebaut, die ham nur absolut nix herausgefunden. Ich weiß echt nicht, was da beim Einschalten schiefläuft, aber viel kann Linux irgendwie nichmehr machen, wenn das überhaupt mal kurz wieder zum Leben erweckt wird.
Falls es euch interessiert, das Board ist ein MSI KT4V-L mit aktuellstem AMI-BIOS:
http://global.msi.com.tw/index.php?func=proddesc&prod_no=505&maincat_no=1&cat2_no=&cat3_no=
Und wie gesagt, es geht mit Windows 98 SE, ME, 2000 und XP, wobei 98 ne ganze Weile braucht, bis der Rechner wieder wach ist.

[gelöscht]

quote:

"und wieso funktioniert dann STR unter Windows ohne Probleme?
naja, nix gegen Linux bzw. gegen Linux-Kernel, aber da hat sich ACPI seit jahren nicht verbessert bzw. Die Kernel Entwickler scheint das sehr kompliziert zu sein...."

Falsch!
STR funktioniert unter Windows ohne Probleme da die meisten (oder alle) Hardwareanbieter ihren ACPI-Table mit dem Microsoft Compiler bauen. Dieser baut absichtlich Fehler ein (d.h. er hält sich nicht an den Standard, der u.a. von Microsoft verabschiedet wurde), damit Offene Betriebssysteme mit ACPI Probleme bekommen.

Das ganze ist ein alter Hut, wurde damals von Bill G. Persönlich so angeleiert...

siehe dazu auch:

http://www.golem.de/0704/51686.html
http://de.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface

Den Link zu der Confidential-Email von Bill G. in der er vorschlägt absichtlich vom Standard abzuweichen finde ich leider nichtmehr :/

MFG

[gelöscht]

Nachtrag: Wenn man eine gefixte DSDT mit den von Intel zur verfügung gestellten Werkzeugen assembliert funktioniert ACPI unter linux ohne Probleme (Intel ist auch in der "Task force" zur verabschiedung des ACPI-Standards gewesen - nur hält intel im Gegensatz zu MS eigene Standards ein).

MfG

fs4000

Also schonmal Danke für eure Unterstützung. Ich hab eben noch den Kernel hier getestet: http://www.archlinux.org/packages/12552/
2.6.25.rc5 mit acpi-patches, also sogut wie das Aktuellste, was die Linux Entwicklung derzeit hergibt, oder?
Funktioniert leider immer noch nicht. 🙁
Aber mir bleibt ja noch meine gepatchte DSDT. Ich werd mal versuch die zu laden, auch wenn man ja etwas davor gewarnt wird, dadran rumzuspielen.

fs4000

Also so richtig will das irgendwie nicht klappen. Der Kernel läd die DSDT zwar:

Mar 26 20:58:33 atelco ACPI: Core revision 20070126
Mar 26 20:58:33 atelco ACPI: Looking for DSDT in initramfs... successfully read 12503 bytes from /DSDT.aml.
Mar 26 20:58:33 atelco ACPI: Table DSDT replaced by host OS
Mar 26 20:58:33 atelco ACPI: DSDT 00000000, 30D7 (r1    VIA   VIA_K7     1000 INTL 20061109)

aber acpidump liefert mir trotzdem noch die alte. Ist das normal?
Und Suspend geht natürlich immer noch nicht.