Wakeup nach 5 Minuten - acpiwakeup problem mit /sys/class/rtc/rtc0/wakealarm ?

Hi,

also da kommt (leider) das raus, was man erwarten würde:

Written to /proc/acpi/alarm : 2008-06-10 19:30:00

Das war die korrekte Aufwachzeit in UTC, aber er startet nicht.
Das gleiche Eregbnis im Log liefert auch 0.0.8, nur dass er halt da aufwacht.

Aber egal, wenn das nur mich betrifft, dann nehm ich halt vorerst die 0.0.8.

Danke!

Grüße
Günther

Du hast mich auf ne Idee gebracht - ich glaub, ich weiss wo das Problem liegt... moment...

Was ich total verschwitzt habe, ist dass die Aufwachzeit beim Runterfahern nochmal in einem Init-Skript gesetzt wird. Das Init-Skript liest die Zeit aus einer Datei und und in der Stand seit der letzten Änderung fälschlicher Weise der Timstamp statt das lesbaren Formats. Darfst also mir die Schuld geben!

Eine neu Version ist online.

Tobias

Ja, das war's! Funktioniert jetzt.

Danke schön!

Grüße
Günther

Hallo Tobi,

danke für deine Mühe das Script immer mehr anzupassen.
Du hast es nun soweit verfeinert das es vor der Vollendung steht

Mehrere Versionen habe ich ausprobiert und das Script umgeschrieben das es geht und nun hast du alle Dinge komplett eingearbeitet.

BESTEN DANK

GLG

Sorry, dies ist ein Fehler; der Editor hat nicht richtig funktioniert!!

Zitat

Originally posted by Ioannis

Hmmm, sicher?

Ich würde mal sagen "date" interpretiert das übergebene Datum so wie die Timezone (TZ) des Systems eingestellt ist. Mehr info dazu gibts mittels kommando "info date".

Code

Normally, dates are interpreted using the rules of the current time zone, which in turn are specified by the `TZ' environment variable, or
by a system default if `TZ' is not set.

Habt ihr denn ausser der "UTC" Einstellung auch mittels "tzconfig" oder "tzselect" Programm die Zeitzone richtig konfiguriert (Europe/Berlin)?

Alles anzeigen

Hallo zusammen,

ich habe eine mögliche Erklärung für das fehlerhafte Verhalten beim Bestimmen der Zeitzone UTC oder localtime:
Das Script S90.acpiwakeup in /usr/share/vdr/shutdownhooks hat etwa in der Zeile 33 einen Fehler:
if [$UTC = "yes" ] then ....
Hier sind die Spaces vor und nach dem "=" zuviel und verhindern das korrekte Auslesen der /etc/default/rcS. Dies kann man erkennen, wenn man den Wert der Variablen $TIMEZONE sich z. B. mit echo ... anzeigen lässt: bleibt immer auf "localtime", ganz gleich, was in der rcS steht.

Bei mir hat das Entfernen der Spaces geholfen, aber die übrigen Probleme leider nicht beseitigt (kommt später).

Übrigens: dieser Fehler war in der Version 6.0 nicht mehr vorhanden, jetzt ist er aber wieder da!

Grüße

gbruno

Zitat

Originally posted by Tobi
Was ich total verschwitzt habe, ist dass die Aufwachzeit beim Runterfahern nochmal in einem Init-Skript gesetzt wird. Das Init-Skript liest die Zeit aus einer Datei und und in der Stand seit der letzten Änderung fälschlicher Weise der Timstamp statt das lesbaren Formats. Darfst also mir die Schuld geben!

Eine neu Version ist online.

Tobias

Hallo Tobias und VDR-Gemeinde,

erstmal auch von mir große Anerkennung für Deine Arbeit. Ich habe aber noch einige Fragen:

1. Oben schreibst Du von einem init-Script, das die Aufwachzeit beim Runterfahren noch einmal setzt. Ich habe in das Script S90.acpiwakeup verschiedene "echo ... >> logfile.log"- Befehle eingebaut; demnach wird die Aufwachzeit in /proc/acpi/alarm korrekt geschrieben, das heißt mit Jahr, Monat, Tag, Stunde und Minute, z. B. "2008-08-03 12:00". Nach dem Neustart kommt mit cat /proc/acpi/alarm nur noch "2008-00-00 12:00", d. h. Monat und Tag fehlen. Kann das an dem genannten init-Script liegen? Welches ist das und wo finde ich es?

2. Im Script S90.acpiwakeup wird als WAKEUP_FILE /var/cache/vdr/acpiwakeup.time angegeben, Diese Datei wird bei mir aber nicht angelegt, bzw. ich habe es nur einmal mit einer Testversion hingekriegt. Muss die Datei von vornherein immer da sein?

3. Obwohl ich jetzt eine Kernelversion >2.6.22 benutze (z. B. 2.6.23 und 2.6.25) bekomme ich das im Wiki erwähnte Device /sys/class/rtc/rtc0 nicht, natürlich auch nicht die die Datei "wakealarm". Stattdessen habe ich wie früher auch /proc/acpi/alarm/..., ganz gleich, an welchem PC ich welchen Kernel starte. Ich war doch ziemlich enttäuscht, weil ich gehofft hatte, dass das Problem mit den fehlenden Daten für Monat und Tag dann gelöst wäre.

Kannst Du / Könnt Ihr mir helfen? Danke im Voraus.

Grüße

GBruno

Hallo GBruno,

zu 1) das liegt nicht an dem script, sondern dein Board kann nicht Tag und Monat speichern. Statt "echo ... >> logfile.log", probier mal ein "cat /proc/acpi/... >>logfile.log" im shutdown hook, dann dürfte es sofort schon nicht korrekt drinstehen, so war jedenfalls das Verhalten bei mir.

zu 2) Die Datei wird vom shutdown-hook angelegt und beim Starten des Rechners wieder gelöscht. Du musst also schnell sein, um sie sehen zu können, oder aber das Abschalten des Rechners kurz verhindern.

zu 3) Schau mal hier.
Es gibt 2 Module für die rtc in den neuen Kernels. Zuerst wird das alte (rtc) geladen, wenn dies geladen wurde, funktioniert das neue (rtc_cmos) nicht. Nur das neuere stellt dir rtc0 bereit. Wenn du die Kernel selbst bäckst, am besten das alte Modul in der Konfiguration rausschmeissen und das neue aktivieren oder einen Eintrag 'blacklist rtc' in die /etc/modprobe.d/blacklist eintragen, damit der alte nicht geladen wird. Wenn denn das neue Modul existiert sollte es auch geladen werden.

[Hallo Ecki,
danke für Deine schnelle Antwort. Ich schreibe meinen Text unter Deinen:

Zitat

Originally posted by ecki
Hallo GBruno,

zu 1) das liegt nicht an dem script, sondern dein Board kann nicht Tag und Monat speichern. Statt "echo ... >> logfile.log", probier mal ein "cat /proc/acpi/... >>logfile.log" im shutdown hook, dann dürfte es sofort schon nicht korrekt drinstehen, so war jedenfalls das Verhalten bei mir.

Das habe ich gemacht. Der Wert ist beim Auslesen korrekt.

Zitat

zu 2) Die Datei wird vom shutdown-hook angelegt und beim Starten des Rechners wieder gelöscht. Du musst also schnell sein, um sie sehen zu können, oder aber das Abschalten des Rechners kurz verhindern.

Aha, so ist das. Wofür wird die Datei denn gebraucht? Übrigens lasse ich mir auch das mit meinem "Log-File" anzeigen, der Wert ist auch korrekt.

Zitat

zu 3) Schau mal hier.
Es gibt 2 Module für die rtc in den neuen Kernels. Zuerst wird das alte (rtc) geladen, wenn dies geladen wurde, funktioniert das neue (rtc_cmos) nicht. Nur das neuere stellt dir rtc0 bereit. Wenn du die Kernel selbst bäckst, am besten das alte Modul in der Konfiguration rausschmeissen und das neue aktivieren oder einen Eintrag 'blacklist rtc' in die /etc/modprobe.d/blacklist eintragen, damit der alte nicht geladen wird. Wenn denn das neue Modul existiert sollte es auch geladen werden.

Das muss ich mir erstmal genauer ansehen. Auf alle Fälle habe ich die rtc-Module core und cmos nicht. Das würde mich auch nicht weiter stören, wenn die alte Mimik richtig funktionieren würde.

Ich kopiere hier mal einen Auszug aus meinem "Echo-Log" hinein, damit Du Dir ein Bild machen kannst. Ich habe alle Variablen geloggt, die mir unklar waren:

************* date
Wert von /proc/acpi/alarm beim Start # beim Hochfahren Echo im Init-Script
2008-00-00 17:24:13
-------------------------------
$TIME_FUNCTION$= gmtime # wegen Fehler im Script S90.acpi...
$1= #### Leer, weil keine Aufnahme programmiert
TIME_TO_SET= 2008-08-03 18:19:32 ,$1=
TIME_TO_SET2= 2008-08-03 18:19:32 ,$?= 0
Wert von /proc/acpi/alarm ##cat /proc/acpi/alarm beim Herunterfahren (des VDR?)
2008-08-03 18:19:32
WakeUpFile
2008-08-03 18:19:32 ## ist cat /var/cache/vdr/acpiwakeup.timer
-------------------------------
$TIME_FUNCTION$= gmtime
$1=1217847600 ## mit gesetztem Timer
TIME_TO_SET= 2008-08-04 10:55:00 ,$1= 1217847300
TIME_TO_SET2= 2008-08-04 10:55:00 ,$?= 0
Wert von /proc/acpi/alarm
2008-08-04 10:55:00
WakeUpFile
2008-08-04 10:55:00
************* date
Wert von /proc/acpi/alarm beim Start
2008-00-00 10:55:00
************* date
Wert von /proc/acpi/alarm beim Start
2008-00-00 10:55:00

Ich hoffe, dass dies einiges klarer macht. Insbesondere kann mein Board das richtige Datum mit dem S90.acpiwakeup-Script speichern, es ist nur beim Hochfahren falsch. Deshal vermute ich, dass noch ein anderes, von Tobi erwähntes Script mitmischt.

Grüße

GBruno

Hallo Ecki,

ich habe gerade mal im VDR-Wiki (ACPI Wakeup) nachgelesen. Dort steht, dass man den "Erfolg" des Timers mit cat /proc/driver/rtc kontrollieren kann.

Das habe ich getan: Dort wird unter ALARM nur hh:mm:ss gespeichert, aber kein Datum! (Bzw. nur das aktuelle). Wenn man dies nicht ändern kann, werden alle Versuche, Tage im Voraus zu programmieren, wohl scheitern. Das gilt für die alte als auch für die neue Methode.

Oder weißt Du einen Rat?

Grüße

GBruno

Hallo GBruno,

zu 1) Es ist schon knapp ein Jahr her, dass ich mich mit dem ACPI-alarm beschüftigt hatte. Kann durchaus sein, dass es direkt nach dem reinschreiben noch korrekt stand. Ich denke aber, dass bei meinem Board sofort das Datum verschwunden ist.

zu 2) Bei vielen Boards gibt es das Problem, dass wenn man die BIOS-Zeit mit der Systemzeit beim Herunterfahren per hwclock aktualisiert (wie es sinnvoll ist und auch standardmäßig von Debian gemacht wird), die gesetzte Aufwachzeit ignoriert wird. Die Skripte vom VDR können die aber normalerweise nur vor dem hwclock setzen. Diese temporäre Datei ist eine elegante Möglichkeit, dass der Aufwachzeitpunkt nach dem hwclock in einem shutdown-skript stattfindet und somit auf allen Boards funktioniert.

zu 3) Hat eigentlich das Aufwachen mit deinem Board per ACPI für mehr als 24h im voraus schon mal geklappt? Die Unterstützung ist je nach board (und bios) sehr unterschiedlich.
Bei mir hat die wakealarm-Methode Besserung gebracht. Ich weiss nicht, ob bei den aktuellen Live-CD's wie Knoppix das entsprechende Modul dabei ist. Du kannst ja testweise mal booten und ein 'dmesg |grep rtc' eingeben. Bei mir kommt folgende Ausgabe auf dem aktuellen System:

rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one year, y3k

Hallo Ecki,

ich schreibe wieder unter Deinen Text, geht schneller.

Zitat

Originally posted by ecki
Hallo GBruno,

zu 1) ....
zu 2) Bei vielen Boards gibt es das Problem, dass wenn man die BIOS-Zeit mit der Systemzeit beim Herunterfahren per hwclock aktualisiert (wie es sinnvoll ist und auch standardmäßig von Debian gemacht wird), die gesetzte Aufwachzeit ignoriert wird. Die Skripte vom VDR können die aber normalerweise nur vor dem hwclock setzen. Diese temporäre Datei ist eine elegante Möglichkeit, dass der Aufwachzeitpunkt nach dem hwclock in einem shutdown-skript stattfindet und somit auf allen Boards funktioniert.

Bei mir habe ich in dem Script rcS den Hardwarezugriff auf die System-Clock deaktiviert, weil es so empfohlen wurde.

Zitat

zu 3) Hat eigentlich das Aufwachen mit deinem Board per ACPI für mehr als 24h im voraus schon mal geklappt? Die Unterstützung ist je nach board (und bios) sehr unterschiedlich.

Soweit ich weiß, nicht. Das Wiki und auch das Portal schweigen sich aber darüber aus

Zitat

Bei mir hat die wakealarm-Methode Besserung gebracht. Ich weiss nicht, ob bei den aktuellen Live-CD's wie Knoppix das entsprechende Modul dabei ist. Du kannst ja testweise mal booten und ein 'dmesg |grep rtc' eingeben. Bei mir kommt folgende Ausgabe auf dem aktuellen System:

rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one year, y3k

Wie gesagt, diese Module habe ich bei meinem Kernel 2.6.23 und 2.6.25_amd64 nicht. Es würde wahrscheinlich (lt. Wiki) auch nichts ändern, weil das Problem ja in "/proc/driver/rtc" bzw. im BIOS zu liegen scheint. Bei mir jedenfalls kann man nach Aufrufen des BIOS beim rtc-Alarm-Screen auch nur eine Uhrzeit, aber kein Datum eingeben. Wenn rtc0 bis zu einem Jahr speichern könnte, wäre das natürlich toll. Eine aktuelle Knoppix-CD muss ich mir erst besorgen - wäre das eine dauerhafte Lösung?

Wie kommt man hier weiter??? Ich bin ratlos. Vielleicht weiß sonst ein Profi aus der VDR-Gemeinde Rat.

Grüße

GBruno

Hi,

ich hatte ähnliche Probleme. Lag an der Konfiguration meines
vanilla Kernels. Mit dem Distri Kerneln gings. Das brachte mich auf
die Spur.

Es fehlten Teile aus dem ACPI Support.
Es sollte beim dmesg auf jeden Fall
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: RTC can wake from S4
erscheinen.

cat /sys/power/state sollte
standby mem disk
ergeben.

CPU Hotplug Support muss auch an sein.

Gruss,
Thomas

Hallo GBruno,

ich backe mir meine Kernel immer selbst, weiss nicht wie die Konfig des Distri-Kernels ist. Vielleicht schicke ich dir einfach mal meinen Kernel als .deb per Mail. Dann kannst du ja mal testen, ob das Modul bei dir weiterhilft.

Hallo Ecki,

das wäre ganz nett, wenn Du mir Deinen Kernel per Mail schicken würdest, ich komme einfach nicht weiter. Deb-Paket wäre prima. Sind da auch Wireless-Module (ath_pci etc.) dabei?

Meine Adresse: g.bruno@t-online.de

Vielen Dank und Grüße

GBruno

Zitat

Original von tomglx
Hi,

ich hatte ähnliche Probleme. Lag an der Konfiguration meines
vanilla Kernels. Mit dem Distri Kerneln gings. Das brachte mich auf
die Spur.

.....
Gruss,
Thomas

Alles anzeigen

Hallo Thomas,

ich habe mir gerade mal die Installations-CD vom c't-VDR 6.2 angesehen, da sind mehrere Kernel drauf. Welchen meinst Du? In den Verzeichnissen mit den Modulen unter .../main habe ich nichts gefunden, was nach rtc_cmos o. ä. aussah. Bin aber kein Profi.

Grüße

GBruno

Hallo GBruno,

völlig andere Baustelle. Ich habe auf einem Fedora 9 System
installiert. Deshalb meinte ich auch die dort vorhandenen
Distri Kernel. Mit dem ct-vdr gar nicht zu vergleichen. Darin
haben sie ja alles an, was es gibt.

Nur eben ich nicht, mit meinem vanilla kernel. Das war dann
auch der Grund und ebenfalls der Unterschied.

Gruss, Thomas

Zitat

Original von ecki
Hallo GBruno,

ich backe mir meine Kernel immer selbst, weiss nicht wie die Konfig des Distri-Kernels ist. Vielleicht schicke ich dir einfach mal meinen Kernel als .deb per Mail. Dann kannst du ja mal testen, ob das Modul bei dir weiterhilft.

Hallo Ecki,

vielen Dank für Deinen Kernel. Ich habe ihn auf meinem PC mit einem Athlon 64X2 und einem einfachen Athlon 64 getestet. Nur auf dem X2 ist er gelaufen; auf dem einfachen Athlon 64 hängte er sich mit der Meldung "runaway loop modprobe binfmt-464c" auf - ein solches Modul gibt es aber unter /lib/modules/... nicht; deshalb denke ich, dass es etwas mit dem 2-Kern-Prozessor zu tun hat. Das Modul "rtc" wurde immer noch geladen und musste mit rmmod von Hand entfernt werden, dann konnte man rtc_cmos laden.

Jetzt habe ichmich fast eine Woche mit dem Kompilieren eines neuen Kernels beschäftigt, nach der Anleitung von WilderIgel ([Anleitung] Debian 4.0 (Etch) Kernelupdate von kernel.org + Module für lirc + cdfs (+ hg-dvb)), die sehr brauchbar ist. Ich habe als Quelle von www.kernel.org die letzte Version 2.6.25.15 genommen, und heute funktioniert alles, wie es soll.

Wichtig ist, dass man in der Datei .config den Eintrag CONFIG_RTC (unter Non 8250 serial port support) inaktiviert und im Abschnitt "rtc-Interfaces" die Einträge mit CONFIG_INTERF_* aktiviert. Weiteres findet man in der Hilfe bei make menuconfig.

Leider wird rtc_cmos nicht automatisch geladen; deshalb habe ich es in eine Datei unter /etc/rcboot eingetragen (nicht am Ende, da ging es nicht!). Heute jedenfalls ist er richtig zur eingestellten Zeit aufgewacht; der Test über mehr als 24 Std. läuft noch.

Das Schwierigste ist ja die Einstellung der über 3.600 Parameter in der .config; deshalb hänge ich mein Exemplar mal an (vor dem Testen entpacken (sonst konnte ich nicht hochladen) und in .config umbenennen).

Übrigens konnte ich auch zum ersten Mal den Madwifi-Treiber für Atheros-Wireless-Chipsätze für amd_64 kompilieren, geht nur mit der Version madwifi-0.9.4.tar.gz (bei sourceforge.net)

Probleme habe ich noch mit dem Framebuffer-Device (nvidiafb und fbtv) und mit dem Kernel-Parameter für die Bildschirm-Auflösung (vga=0x314 wird nicht akzeptiert).

Erstmal vielen Dank für Deine Hilfe

GBruno

Hallo zusammen,

hier erste Erfahrungen mit dem oben beschriebenen Kernel-Neubau: das device /sys/class/rtc/rtc0 erscheint jetzt richtig, auch "spontan" nach dem Booten. Auch den ">24 Std. Test" hat das System bestanden und ist nach ca. 30 Std. korrekt zum Aufnehmen hochgefahren. /proc/sys/driver/rtc zeigt beim "Alarm-Datum" zwar nur Sternchen; das scheint aber nichts auszumachen.
Allerdings läuft der VDR unter der Kernel-version 2.6.25.15 ziemlich instabil - mal geht's, mal nicht. Das liegt - soweit ich es herausfinden konnte - am Handling der "events", hier für die on-board-irc-Schnittstelle (Fernbedienung) meiner Sat-Karte von Hauppauge. Manchmal findet das System das event nicht und der VDR startet dauernd neu. Ich werde wohl zur letzten stabilen Version 2.6.25.2 zurückkehren (am Wochenende).
Der madwifi-Treiber für meine WLan-Karte (Atheros-Chipsatz) läuft übrigens einwandfrei.
Grüße
GBruno