ACPI Wakeup für Debian Woody?

hi,
also damit das /proc/acpi kommt musst du acpi aktivieren (wohl beim booten). tipp mal "dmesg" ein um zu sehen was der kernel so über ACPI zu sagen hat.

ich bin gerade selbiges am testen (auch woody), glaube aber das es an meinem board liegt[uralt intel board aus aldi-rechner]. auf jeden fall startet der rechner nicht.

Ooops, bin total verkehrt hier

hi,
du hast wohl ein ähnliches probelm wie ich ... das system ist zu alt.
probier mal mit den parametern "acpi=force pci=noacpi" zu starten.

Zitat

Original von FeXXX
Muss ich da nicht erst was installieren oder so?
Brauch ich keine Binarys oder so was?

für was denn?

Zitat

wo soll ich das eintragen?

beim boot-prompt (also lilo oder grub)

Moin moin,

FeXXX
unterstützt denn Dein Mainboard kein nvram-wakeup ?
Ansonsten kann ich vorallem bei alten Mainboards keinen Vorteil von ACPI entdecken. Sieht natürlich anders aus, wenn das Mainboard bzw. der verwendete Chipsatz auf ACPI und APIC angewiesen ist, aber danach sieht es bei Deinem Mainboard ja nun nicht wirklich aus.

Um aber Deinen Testdrang nicht zu sehr zu bremsen, die append Zeile Deiner /etc/lilo.conf sollte in etwa so aussehen:

append = "apm=off acpi=force pci=noacpi"

Den Aufruf von lilo nicht vergessen.

slime
Das die Rechner unter c't-VDR (Woody) mit ACPI-Wakeup nicht mehr zeitgerecht starten geht mir leider genauso

Zu Testzwecken benutze ich dazu LinVDR 0.5, nur um festzustellen das in diesen Testfällen abschalten,Alarmzeit setzen und aufwachen problemlos funktionieren.

Das nachinstallieren von acpid, anpassen von /etc/acpi/... sowie /etc/modules ist ja kein Problem. (button.o usw. ist ja bei den Modulen zum vmlinuz-2.4.21-i586-cdv bereits dabei)

Setzen der Alarmzeit mittels echo "2004-02-11 02:00:00" >/proc/acpi/alarm
klappt ebenfalls ohne das die Rechner unmittelbar neustarten

Nur auf das aufwachen kann ich lange warten ...
Die Unterschiede zwischen den verschiedenen debian-Varianten scheinen wohl leider etwas tiefer zu liegen
mfG

@ Delaney

Funktioniert das nvram-wakeup bei deinem P5A mit dem aktualisierten c't-Kernel? Ich hab hier ein P5A-B und das kriege ich damit nicht zum laufen. Wenn ich die Werte mit guess ermittle, bekomme ich immer die Meldung:
nvram-wakeup: addr_stat (0xFF) is beyond the end of nvram...

Siehe auch hier

ciao,
Kurt

Zitat

Original von Delaney
Nur auf das aufwachen kann ich lange warten ...
Die Unterschiede zwischen den verschiedenen debian-Varianten scheinen wohl leider etwas tiefer zu liegen
mfG

klappt denn auf deinem rechner das wakeup mit linvdr und mit debian nicht? du meints also das es an der software liegt?

Moin,
kuba
nö, mein P5A aus der sig läuft so wie es da steht
angefangen vor ca. 2 Jahren und entsprechend selbst übersetzt.

Die Meldung von guess hatte ich bestimmt auch, bin dann nach den Erläuterungen in der Readme.mb von nvram-wakeup vorgegangen:
> In <kernel-src>/drivers/char/nvram.c change the line
> #define NVRAM_BYTES 128-RTC_FIRST_BYTE
> to
> #define NVRAM_BYTES 128

und danach den Kernel neu übersetzt ...

Getestet (c't vdr oder LinVDR) wird immer auf anderen Rechnern
mfG

Zitat

Original von slime
klappt denn auf deinem rechner das wakeup mit linvdr und mit debian nicht? du meints also das es an der software liegt?

Ja genau, getestet auf mehreren _nicht_ P5A-Boards die kein nvram-wakeup unterstützen (gibt z.T. gar keine BIOS-Einstellungen fürs aufwecken).
Für die Tests mit c't-VDR benutze ich den vmlinuz-2.4.21-i586-cdv Kernel und den neueren 2.4.24 ct-Kernel obwohl da doch glatt xfs fehlt
Die Unterschiede scheinen in der Art des Abschaltens zu liegen.
Werde in dieser Richtung weiter suchen und mir mal halt.c ansehen.
mfG

Moin,
am verwendeten Kernel liegts mit dem aufwachen über ACPI auch nicht.
Ich war irgendwie der irrigen Ansicht LinVDR würde nicht auf debian woody basieren Aber mit dem lesen klappts noch
Also kurzerhand mal den 2.4.23 und die module von LinVDR in c't-VDR zu Testzwecken eingebaut. Leider keine Verbesserung
Bei poweroff und halt (bzw. shutdown) zu suchen brachte auch nichts. Was sich allerdings sehr deutlich unterscheidet sind die "init-skripte".
Warum "busybox poweroff" unter c't-VDR nichts macht, noch nichtmal Fehlermeldungen ist mir allerdings schleierhaft.
mfG

hi,
was steht denn bei linvdr in der poweroff.pl drin?
ich hab das bisher immer mit einem "echo 5 > /proc/acpi/sleep" gemacht um den rechner auszumachen. gibt es da noch andere möglichkeiten?

Moin,

Zitat

Original von slime
was steht denn bei linvdr in der poweroff.pl drin?
ich hab das bisher immer mit einem "echo 5 > /proc/acpi/sleep" gemacht um den rechner auszumachen. gibt es da noch andere möglichkeiten?

Bei LinVDR wird "busybox poweroff" benutzt und auf die Idee acpi/sleep mal zu testen bin ich noch gar nicht gekommen, Danke.
Aber meinen Störenfried was das zeitgerechte Aufwachen angeht habe ich mit HWCLOCKACCESS=no in der /etc/default/rcS entfernt.
Ich habe zwar auch testweise mal die runlevellinks gekürzt, schätze aber der Eintrag in rcS ist ausreichend. Bestätigungen sind willkommen.
Jetzt muss ich "nur" noch diese neuen shutdown hooks zur Mitarbeit überreden ...
mfG

Hi Delaney,

was aus dem Thread nicht so genau hervorgeht, aber mich brennend interessiert, da ich auch LinVDR auf einem P5A laufen habe, ist, ob denn Dein Rechner auch tatsächlich aufwacht. Und wenn ja, fährst Du ihn über busybox runter, oder mit echo 5 > sleep?

Meiner fährt brav runter, wacht aber nur über die Powertaste wieder auf. :-(((

Grüßle
Marillion

Moin,

Zitat

Original von Marillion
was aus dem Thread nicht so genau hervorgeht, aber mich brennend interessiert, da ich auch LinVDR auf einem P5A laufen habe, ist, ob denn Dein Rechner auch tatsächlich aufwacht. Und wenn ja, fährst Du ihn über busybox runter, oder mit echo 5 > sleep?

naja, in meinem zweiten Beitrag in diesem Thread kann man schon lesen, das auf meinem P5A nur das in der sig. stehende SuSE läuft
Und in Verbindung mit nvram-wakeup wacht der auch wieder zum gewünschtem Tag auf
Runtergefahren wird entsprechend distributionstypisch mit "shutdown -h now". Ein "echo 5 > sleep" würde ohnehin nur eine Datei mit Inhalt 5 anlegen.
Aber auch mit echo "irgendwas" >/proc/acpi/(alarm|sleep) wäre ich etwas vorsichtig, Boards bei denen ACPI mehr schlecht als recht vorhanden ist, wie z.B. diese P5As, können recht allergisch auf solche Schreibzugriffe reagieren. Das zeigt sich dann z.B. in unmittelbarem Ausschalten des Rechners ohne erst "umständlich" Dateisysteme abzumelden ...
mfG

Hi!

Bei mir läuft die ctdistri mit kernel 2.4.24 auf einem ASUS Tusl2c Motherboard. ACPI ist aktiviert; Herunterfahren über den vdr klappte von Anfang an und mittels eines shutdown-hooks, der die gewünschte Aufwachzeit nach /proc/acpi/alarm schreibt, klappt auch das Aufwachen.

Falls diese Kombination jemand interessiert, kann ich das auch mal detaillierter beschreiben.

Grüße
Günther

Moin,

Zitat

Original von tdsandme
ACPI ist aktiviert; Herunterfahren über den vdr klappte von Anfang an und mittels eines shutdown-hooks, der die gewünschte Aufwachzeit nach /proc/acpi/alarm schreibt, klappt auch das Aufwachen.

Falls diese Kombination jemand interessiert, kann ich das auch mal detaillierter beschreiben.

Ja, sehr gerne.
Ich bin bisher bei den shutdown-hooks hängengeblieben, die bei mir grundsätzlich alle Ergänzungen übergehen. Um dem dann auf den Grund zu gehen muss ich allerdings auch erst noch die Kernelquellen zum ctvdr-2.4.24-2 mit xfs patchen usw. da ich sonst ein ziemlich leeres /video0 vorfinde
mfG

Ok - also hier meine Erläuterung:

(Übrigens Dank an die ct und tobi - das war die erste vdr-installation, die ich mit erträglichem Aufwand zum Laufen gebracht habe!
Und danke auch an die anderen Poster hier und sonstwo, aus deren Tipps ich mir das hier zusammengesucht habe.)

Also zuerst habe ich mir die ctvdr-Distri von einer Boot-CD installiert.
Dabei hab ich lilo nicht in den MBR installiert, sondern lt. Anleitung in das Windows-Boot-Menü integriert.

Danach habe ich mit apt-get (nach einigen Irr- und Umwegen das kernel-image 2.4.24 ctvdr 2 installiert, und zwar MIT ACPI, also keine Startparameter wie "noacpi" verwendet.
Ob der richtige Kernel läuft, kann man mit uname -a (es war doch -a?) herausfinden.
Bei meiner Konfiguration musste ich dafür z.B. lilo.bin und die links neu erzeugen - siehe howto von zrox hier im Forum.
Ob ACPI läuft kann man mit "ls /proc/acpi" testen, da muss z.B. sleep oder alarm gelistet werden.

Ansonsten habe ich nix gepatcht oder kompiliert und verwende die "ct"-Version vom vdr (Eintrag in /etc/apt/sources.list wie bei heise beschrieben).

Wie gesagt fuhr der Rechner beim Druck auf Fernbedienung "Power" bzw. beim Aufruf des entsprechenden OSD-Befehls einwandfrei runter ohne dass ich was ändern mußte.
Dagegen haben die Versuche mit "echo 1 >/proc/acpi/sleep" den Standby zu erreichen nicht funktioniert, lediglich bei "echo 5" fährt die Kiste sofort runter (und ich bin froh, dass dann nicht mehr stundenlang die Dateisysteme repariert werden ;-).

Aber das Abschalten klappt ja eh schon, daher macht das nichts.
Zum Wiederaufwachen muss man prinzipiell einfach nur die Aufwachzeit nach /proc/acpi/alarm schreiben, etwa so:
echo 2004-02-23 19:20:00 >/proc/acpi/alarm

Damit das funktioniert, mußte ich im Bios das Aufwachen aktivieren. Bei meinem Board (ASUS TUSL-2C) gibt es (unter Power) drei Möglichkeiten: Disabled, By Date, Every Day. Da proc/acpi/alarm zumindest bei mir den Tag nicht berücksichtigt, habe ich every day eingestellt. Das hat den Nachteil, dass der Rechner dann jeden Tag mindestens einmal startet - falls das stört, sollte man sich mal die nvram-wakeup Methode anschauen.

Nachdem das im Bios eingestellt ist, kann man auch gleich testen ob es funktioniert, indem man dort eine Uhrzeit angibt und dann den Rechner herunterfährt (ganz normal ausschalten - Softoff - S5). Man sollte vermeiden, nach dem Stellen der Uhrzeit Windows zu starten, da das evt. die Zeiteinstellung verändert (hab ich selbst noch nicht getestet).

Wenn der Rechner jetzt NICHT zur eingestellten Uhrzeit startet, kann man sich leider das Weiterlesen sparen.

Anschließend testet man das Aufwachen auch nochmal manuell mit /proc/acpi/alarm. Dazu Linux booten und in einer Konsole wie oben beschrieben "echo 2004-02-23 19:20:00 >/proc/acpi/alarm" eingeben. Danach den Rechner am besten mit der Fernbedienung oder OSD-Menü herunterfahren.
Startet er jetzt auch zur angegebenen Zeit, dann sollte auch das wakeup script funktionieren.

Mein ctvdr war so konfiguriert, dass der VDR beim Herunterfahren das Script /usr/sbin/shutdownvdr von tobi aufruft. Ich gehe davon aus, dass das bei allen (ct-)Installationen der Fall ist.
Hinweis: Das Script wird nur aufgerufen, wenn man den Rechner über den VDR runterfährt und nicht über Ctrl-Alt-Del oder shutdown oder so.
Dieses Script ist gut dokumentiert und sucht in dem Verzeichnis /usr/share/vdr/shutdown-hooks nach Script-Dateien mit Namen shutdown*.*.sh, also z.B. mein Script shutdown01.alarm.sh:

#!/bin/sh


NOW=$((`date +%s`))
if [ $1 -gt $NOW ]
then
	TM=`expr $1 - 120`
	/usr/share/vdr/shutdown-hooks/time2alarm.pl $TM >/proc/acpi/alarm
	/usr/share/vdr/shutdown-hooks/time2alarm.pl $TM >/video/alarm.txt
	cat /proc/acpi/alarm >>/video/alarm.txt
fi

Dabei wird als Parameter $1 der Zeitpunkt (in Sekunden seit 1.1.1970) übergeben, zu dem die nächste Aufnahme stattfinden soll (die Parameter sind im VDR Handbuch dokumentiert).
Das Script testet jetzt, ob der Zeitpunkt in der Zukunft liegt. Wenn ja, zieht es 120 sec davon ab (zum Booten) und schreibt es mit Hilfe von time2alarm.pl (s.u.) nach /proc/acpi/alarm. Außerdem wird der berechnete Zeitpunkt zu Debugzwecken direkt und zusätzlich der wieder aus /proc/acpi/alarm ausgelesene nach /Video/Alarm.txt geschrieben.

time2alarm.pl sieht so aus:

#!/usr/bin/perl


require "ctime.pl";
if ($#ARGV >= 0) {
    $time = shift(@ARGV);
    }
else {
    die "Usage: time2alarm number\n";}


($a, $b, $c, $d, $e, $f, $g, $h, $i) = localtime($time);
printf "%04d-%02d-%02d %02d:%02d:%02d\n", $f + 1900, $e + 1, $d, $c, $b, $a;

Das ist ein perl-script, dass ich im Internet gefunden und angepasst habe, um die übergebenen Sekunden in das notwendige Datumsformat umzurechnen.

Beide Scripte muss man mit "chmod +x" ausführbar machen.

Das war's. Mögliche Probleme sind vielleicht, dass der vdr-Prozess nicht das Recht hat, nach /proc/acpi/alarm zu schreiben, aber beim ctvdr scheint das zu klappen. Außerdem hab ich mir geschenkt, die 120 sec bei "if [ $1 -gt $NOW ]" zu berücksichtigen, aber shutdownvdr erlaubt das Herunterfahren eh nicht mehr in den letzten 10 min vor der Aufnahme.

Um zu testen, ob shutdown01.alarm.sh überhaupt ausgeführt wird, kann man
a) die Datei /Video/alarm.txt prüfen
b) in das Script am Ende die Zeile "EXITCODE=1" einfügen, dann wird der Shutdown grundsätzlich abgebrochen, was auch zeigt, dass das Script zum Zuge kommt.

Schöne Grüße
Günther