ACPI Laptop schaltet nicht ab

[Voyager_MP]

Hi, ich habe den effect das das notbook (Sony BX!97XP) kernel 2.6.1X nicht abschaltet.
zumindest die meiste Zeit nicht.

Hat einer eine Idee wie ich herausbekommen kann woran es liegt ?

[Six]

Du kannst entweder in den ACPI-Events rumfuhrwerken oder es mal mit APM versuchen. APM ist zwar nicht so dolle für die anderen Stromsparfeatures, aber abschalten klappt dafür meistens

[Voyager_MP]

wie soll ich mir denn die acpi events anschauen ?
APM ist keine lösung.

[Six]

wie soll ich mir denn die acpi events anschauen ?
APM ist keine lösung.

In /etc/acpi findest du alle definierten ACPI-Events. Die Kandidaten für power-down sind die Events mit power*. Normalerweise ist das powerbtn.sh. Fehlt der, so haben wir die Wurzel allen Übels bereits gefunden, evtl. hilft das nachinstallieren von Laptop-spezifischen Events. Bei Debian sind, glaube ich, Pakete für IBM, ASUS und Toshiba dabei.

Sind die Events jedoch vorhanden, dann wird's knifflig.

[Weyoun]

gib entweder mal modprobe acpi oder modprobe apm ein und versuch dann mal, deinen Rechner herrunterzufahren.

Wir bräuchten aber noch ein paar Informationen: Was bedeutet "die meiste Zeit nicht"?
Wie siehts zum Schluss aus, wenn du den Rechner herrunterfährst(init 0, shutdown -h now)?

[Voyager_MP]

Also acpid und die scipte sind da, das problem ist ja nicht, das das laptop nicht per powerkonpf drücken herunterfährt, sonder habe ich den effect, das wenn ich halt eingebe, fährt es runter (ohne fehler) und dann geht der TFT aus, und das wars Lüfter laufen weiter und platte auch.
Machmal geht er aber auch richtig aus, ich finde halt kein muster,

Daher meine frage. Gibt es irgendeine möglichkeit zu loggen welches module oder was der kernel da zu letzt mach.

[Six]

Also acpid und die scipte sind da, das problem ist ja nicht, das das laptop nicht per powerkonpf drücken herunterfährt, sonder habe ich den effect, das wenn ich halt eingebe, fährt es runter (ohne fehler) und dann geht der TFT aus, und das wars Lüfter laufen weiter und platte auch.
Machmal geht er aber auch richtig aus, ich finde halt kein muster,

halt alleine sollte das Gerät garnicht ausschalten. Die Optionen

Code: Alles auswählen

halt -p 
oder 
poweroff

sind dafür zuständig. Worauf bezieht sich dein Kommentar?

Daher meine frage. Gibt es irgendeine möglichkeit zu loggen welches module oder was der kernel da zu letzt mach.

Naheliegenderweise loggt ACPI seine Aktivitäten nach /var/log/acpi.

[Voyager_MP]

ok, halt ist bei mir ein alias auf halt -p ...

Naheliegender weise logt acpi leider nicht nach /var/log/acpi
acpid logt nach /var/log/acpid

wenn der acpid runterfährt hörts auf mit dem loggen. somit hilf mir das gar nix...

Ich will die letzen events des kernels dumpen bevor er unten ist.

[Six]

Hmh, sowohl klog als auch syslog stoppen halt ein wenig vor dem letzten Kernelaktivitäten. Ich sehe da wenig Chancen über einen normalen Logger ranzukommen.

Was gehen könnte wäre einen Kernel mit Debugging-Infos zu kompilieren. Der schreibt dir als letzte Amtshandlung einen Dump. Oder du machst es in UML. Siehe hier: http://user-mode-linux.sourceforge.net/debugging.html

Alternativ könnte vielleicht auch der NLKD helfen, der ist neuerdings frei. Ich kenne mich aber nicht damit aus.

[Voyager_MP]

auf die idee, den kernel mit debug infos zu kompilieren bin ich auch schon gekommen und habe ich auch gemacht, wie erzeuge ich denn einen dump ?

[Six]

Der Kernel schreibt die Debugging Info direkt ins syslog (auch ohne Dämon). Also solltest du es /var/log/syslog* finden.

[Voyager_MP]

kann doch nicht sein, die partionen werden entmountet, wie soll der denn dann in ein file schreiben ?

[comes]

es reicht nich den acpid laufen zu lassen

wenn das acpi modul nicht geladen ist, geht der schönste rechner nicht von alleine aus...

[Six]

kann doch nicht sein, die partionen werden entmountet, wie soll der denn dann in ein file schreiben ?

Guter Punkt.

[Voyager_MP]

natürlich sind die acpi module geladen ... bitte leute

[rendegast]

Du könntest mal den Inhalt von /proc/acpi/dsdt überprüfen.
Durch Dekompilieren mit iasl
http://acpi.sourceforge.net/dsdt/index.php
http://acpi.sourceforge.net/download.html
http://packages.debian.org/iasl
und anschliessendes Kompilieren

Code: Alles auswählen

cat /proc/acpi/dsdt > dsdt.aml ; iasl -d dsdt.aml > dsdt.asl ; iasl -tc dsdt.asl

Vielleicht geben die dabei auftretenden error-Meldungen Hinweise auf schlechte ACPI.

[apulix]

Laut http://acpi.sourceforge.net/documentati ... klist.html gibt es kritische Probleme mit Sonys DSDT, vielleicht liegt es tatsächlich daran.

[rendegast]

kann doch nicht sein, die partionen werden entmountet, wie soll der denn dann in ein file schreiben ?

zBsp Meldungen an eine Konsole oder einen Drucker am seriellen oder parallelen Port ausgeben.

[Voyager_MP]

dsdt habe ich schon gefixed, waren aber keine errors sondern nur ein paar warnings drin, naja, selbst die sind jetzt weg, nur bekomme ich die neue dsdt nicht geladen, (kernel ist bereits gepatched)

wie bekomme ich

zBsp Meldungen an eine Konsole

hin ?

[Voyager_MP]

problem ist gelößt, FIREFOX reagiert irgendwie mit meinem ACPI ;(

Firefox runter Galeon drauf schon gehts

[Voyager_MP]

leider zu früh gefreut, also, sobald ich ein wenig mit debian arbeite, und dann herunterfahre, geht er nicht aus.

boote ich log mich ein und fahre direkt wieder runter, geht er aus.

Hat einer eine Idee ??

[garibaldi]

Vielleicht hilft folgende kernel option:

Code: Alles auswählen

acpi=force

[rendegast]

Hallo,

ist eine Verzweiflungsidee, vielleicht:
in meinem rc0.d stoppt K90syslogd 9 Skripte vor S40umountfs.
Lenke doch mal den LOG-Output in eine Probe-Partition, fuer die syslog nicht beendet wird und und die nicht unmounted wird.
Das S90halt-Skript kannst Du dann modifizieren oder ein eigenes dazwischenschieben:
lsof, lsmod, ps usw. nochmal anzeigen/schreiben lassen.
sync, sleep und hoffen, dass dabei etwas herauskommt.
(Ich denke dabei an einen Dump-"zu-Fuss")
Die nötigen Programme/Bibliotheken kannst Du ja auf diese Partition kopieren.

Eine Modifikation dieser Idee:
Nach jedem Skript in rc0.d ein solches Dumpskript einschalten um Schritt für Schritt zu sehen, was das System macht.

[Voyager_MP]

hab acpi in debug versetzt, kann damit irgendeiner was anfangen und mir was dazu erklären.

Code: Alles auswählen

Jun 13 11:14:02 mp kernel:   exdump-0792 [1962] [6940] ex_dump_operands      : ************* Operand Stack Contents (Opcode [Acquire], 2 Operands)
Jun 13 11:14:02 mp kernel:   exdump-0494 [1962] [6940] ex_dump_operand       : ef29445c Integer 0000000000001388
Jun 13 11:14:02 mp kernel:   exdump-0494 [1962] [6940] ex_dump_operand       : c17d045c Mutex
Jun 13 11:14:02 mp kernel:   exdump-0806 [1962] [6940] ex_dump_operands      : ************* Operand Stack dump from dswexec(426), after ex_resolve_operands
Jun 13 11:14:02 mp kernel: exoparg2-0499 [1962] [6941] ex_opcode_2A_0T_1R    : ----Entry Acquire
Jun 13 11:14:02 mp kernel: utobject-0096 [1962] [6942] ut_create_internal_obj: ----Entry Integer
Jun 13 11:14:02 mp kernel: utobject-0311 [1962] [6943] ut_allocate_object_des: ----Entry
Jun 13 11:14:02 mp kernel: utobject-0326 [1962] [6943] ut_allocate_object_des: ef294f4c Size 28
Jun 13 11:14:02 mp kernel: utobject-0328 [1962] [6943] ut_allocate_object_des: ----Exit- ef294f4c
Jun 13 11:14:02 mp kernel: utobject-0144 [1962] [6942] ut_create_internal_obj: ----Exit- ef294f4c
Jun 13 11:14:02 mp kernel:  exmutex-0147 [1962] [6942] ex_acquire_mutex      : ----Entry c17d045c
Jun 13 11:14:02 mp kernel: exsystem-0194 [1962] [6943] ex_system_acquire_mute: ----Entry c17d045c
Jun 13 11:14:02 mp kernel: exsystem-0071 [1962] [6944] ex_system_wait_semapho: ----Entry
Jun 13 11:14:02 mp kernel:      osl-0761 [1962] [6945] os_wait_semaphore     : ----Entry
Jun 13 11:14:02 mp kernel:      osl-0770 [1962] [6945] os_wait_semaphore     : Waiting for semaphore[dfffc8a0|1|0]
Jun 13 11:14:02 mp kernel:      osl-0822 [1962] [6945] os_wait_semaphore     : Failed to acquire semaphore[dfffc8a0|1|0], AE_TIME
Jun 13 11:14:02 mp kernel:      osl-0829 [1962] [6945] os_wait_semaphore     : ----Exit- ****Exception****: AE_TIME
Jun 13 11:14:02 mp kernel:  exutils-0126 [1962] [6945] ex_exit_interpreter   : ----Entry
Jun 13 11:14:02 mp kernel:  utmutex-0285 [1962] [6945] ut_release_mutex      : Thread 1962 releasing Mutex [ACPI_MTX_Execute]
Jun 13 11:14:02 mp kernel:      osl-0841 [1962] [6946] os_signal_semaphore   : ----Entry
Jun 13 11:14:02 mp kernel:      osl-0850 [1962] [6946] os_signal_semaphore   : Signaling semaphore[dfffcb80|1]
Jun 13 11:14:02 mp kernel:      osl-0854 [1962] [6946] os_signal_semaphore   : ----Exit- AE_OK
Jun 13 11:14:02 mp kernel:  utmutex-0344 [1962] [6945] ut_release_mutex      : Thread 1962 released Mutex [ACPI_MTX_Execute]
Jun 13 11:14:02 mp kernel:  exutils-0133 [1962] [6945] ex_exit_interpreter   : ----Exit-
Jun 13 11:14:02 mp kernel:      osl-0761 [1962] [6945] os_wait_semaphore     : ----Entry
Jun 13 11:14:02 mp kernel:      osl-0770 [1962] [6945] os_wait_semaphore     : Waiting for semaphore[dfffc8a0|1|5000]
Jun 13 11:14:02 mp kernel: 

Code: Alles auswählen

Failed to acquire semaphore[dfffc8a0|1|0], AE_TIME

macht mir sorgen.

Code: Alles auswählen

DSDT=Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 32 Optimizations

Edit by Snoopy:
Code-Tags für die Leserlichkeit eingefügt.