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

    Hallo,
    mein VDR (1.6.0-1 TOBIs vdr-experimental muiltipatch frisch upgradet) startet 5 Minuten nach dem Shutdown wieder durch, egal ob mit der Fernbedienung ausgelöst, oder nach 2h inaktivität.
    Das heißt der Rechner läuft rund um die Uhr und ich weiß gar nicht seit wann er das schon so macht.
    Es lief (also er schlief) schonmal ganz normal, aber dadurch, dass er sich ja für 5min tot stellt hab ich gar nicht gemerkt, ab wann sich das geändert hat.


    Weiß jemand woran das liegen kann?


    hier der entsprechende Auszug aus dem syslog:



    ich hab eine zusätzliche LOG-Zeile in den S90-acpiwakeup eingefügt, der mir zeigt, welche Zahl wirklich wohin geschrieben wird, das ist diese Ausgabe hier:

    Code
    May 20 19:23:26 vdr vdr-addon-acpiwakeup: echo 1211298600 >/sys/class/rtc/rtc0/wakealarm


    Aber leider hat mir das auch nicht geholfen (ich kann auch nicht überprüfen, od die '1211298600' richtig ist.


    hier noch meine vdr-addon-acpiwakeup.conf


    Danke schonmal !!

    Laut log soll der nächste timer

    Code
    May 20 19:23:26 vdr vdr: [2503] next timer event at Tue May 20 19:55:00 2008

    sein.
    Diese Zeit wird auch an

    Code
    May 20 19:23:26 vdr vdr: [2503] executing '/usr/lib/vdr/vdr-shutdown.wrapper 1211306100 1894 506 "Radio~Hörspiel~Charlies Himmelfahrt" 1'

    übergeben.
    Aber dann kommt 8 Zeilen später:

    Code
    May 20 19:23:26 vdr vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2008-05-20 17:50:00

    d.h. die Aufwachzeit liegt in der Vergangenheit!


    Zitat

    ich hab eine zusätzliche LOG-Zeile in den S90-acpiwakeup eingefügt, der mir zeigt, welche Zahl wirklich wohin geschrieben wird, das ist diese Ausgabe hier:


    Was genau hast du eingebaut/geändert?
    Ich würde die scripte erstmal wieder in den Originalzustand bringen und dann noch mal testen und den syslog posten (am besten mit einem timer der 3h in der Zukunft liegt).

    Mein VDR: LinVDR 0.7 + MT, ASROCK K7VM4, Duron 1000@500, 128 MB RAM, Samsung SP1604+SP2014, Medion 4688, TT 1.3 + Skystar 2.6D

    Zwei Stunden Versatz riecht verdächtig nach UTC.


    Ich vermute mal in

    Code
    /etc/default/rcS


    steht UTC=yes und Dein BIOS läuft in Echtzeit?
    Damit UTC funktioniert muss die Zeit im BIOS um zwei Stunden versetzt laufen.


    Code
    hwclock --systohc --utc

    macht das direkt von console aus.

    VDR1: AMD Sempron 2200+, KT600-A, 2TB HDD, TT DVB-T 1.2, 2x Avermedia AverTV DVB-T 771, Debian Linux etch 2.6.21.4 (ct4), VDR 1.4.7-2 (Tobi/TomG), touchTFT, atmo, Wakü

    VDR2: Intel Celeron Core 440, P5VD2-X, 2.5TB HDD, TT DVB-S 1.5, 3x Avermedia AverTV DVB-T 771, Debian Linux etch 2.6.25.10 (ct6.1), VDR 1.6.0-6 (Tobi/TomG), touchTFT

    Das mit den UTC hört sich gut an, aber leider hat der Befehl nicht geholfen.


    ich hab jetzt wieder mit einen original S90-acpiwakeup-Skript einen Timer überprüft, der weiter in der Zukunft liegt, und Tatsache, er schläft länger als nur 5min, ist aber trotzdem 2h zu früh wach.


    Ich nutze auch die wakealarm Methode der neuen Kernel und habe seit dem update dasselbe Problem, dass der VDR 2h zu zeitig aufwacht. Mein board läuft auch auf UTC (in /etc/default/rcS ist UTC=yes).
    Vor dem update hatte ich eine selbstmodifizierte Version des acpiwakeup Skripts genutzt. Da hat alles geklappt. Also habe ich mal die Änderungen verglichen. Bei mir hatte ich die timetostring-Methode einfach auskommentiert und habe den timestamp direkt geschrieben. Offenbar kommt es durch die Umwandlung von timestamp zu string und wieder zurück zu dieser Zeitdifferenz von 2h.


    Ich habe im neuen Skript jetzt mal die doppelte Umwandlung auskommentiert und werde morgen mal schauen, ob damit das Aufwachen zur richtigen Zeit klappt.

    Boss666: ich hab in meinem System eigentlich kein ntp eingerichtet, da ich keinen dauerhaft erreichbaren ntp-Server angeben könnte. Das wirds dann wohl nicht sein.


    ecki: wie war denn die Änderung genau? ich hab es so verstanden:


    Code
    TIME_TO_SET=`TimeToString $TIMER`    
geändert in
TIME_TO_SET=$TIMER


    oder anders?

    Lord Ray: Ja, genau so war's. Damit ist er heute auch zur richtigen Zeit aufgewacht. Dann musst du natürlich beim Setzen der Weckzeit in der Funktion Setwakeuptimegt2623 (oder so ähnlich, hab grad keinen Zugriff auf den vdr) die Rückumwandlung von String zu Timestamp ('date...') auch auskommentieren.

    Okay, so scheints zu laufen.


    ich hab den Script so geändert:



    Damit wird die TimeToString Funktion für die ältere Wakeup-Variante (/proc/acpi/alarm) durchgeführt, ich weiß nicht, ob es dort auch Probleme gibt.
    Ist das nun ein allgemeines Problem des original-Scripts oder betrifft das nur uns 2? Müßte man Tobi informieren?

    Sieht gut aus, so wollte ich das auch machen, um beide Varianten zu unterstützen. Nur das stop-script und wakeup-file habe ich mir noch nicht angeschaut.
    Ich denke mal, das müsste alle mit nem neueren Kernel bei denen das Bios auf UTC läuft betreffen. In diesem Fall kümmert sich scheinbar der Kernel selbst darum, dass die Zeit übersetzt wird. Oder läuft das bios nicht auf utc, obwohl es in /etc/default/rcS eingestellt ist. Wie bekommt man das raus?

    Weiß nicht, ich dachte ich stelle das BIOS mit

    Code
    hwclock --systohc --utc


    auf UTC bertieb ein.
    Oder übergebe ich nur die aktuelle Zeit mit dem Hinweis, dass es als UTC zu interpretieren ist, und das BIOS adaptiert das, je nachdem was dort eingestellt ist?


    ich muß mal im 'man hwclock' nachlesen glaub ich..

    Hallo,


    das BIOS (du meinst die Hardwareuhr) kannst du nicht auf UTC einstellen. Du kannst nur Linux so einstellen, dass er die Hardwareuhr auf UTC stellt. Dies geht bei Debian wie beschrieben mit /etc/default/rcS utc=yes. Ein init.d Script sorgt dann beim runterfahren mit einem hwclock-Befehl für das Setzen der Uhrzeit. In der Hardwareuhr die UTC-Zeit laufen zu lassen ist empfehlenswert, weil die Hardwareuhr dann keine Sommer/Winterzeitumstellung machen muss (kann sie ja auch nicht). Linux kann aber aus der UTC-Zeit beim Hochfahren eindeutig die lokale Zeit bestimmen.


    Also hast du eigentlich nur das Problem die lokale Aufweckzeit für die Hardwareuhr in UTC umzurechnen. Das sollte mit dem date-Befehl zu machen sein.
    z.B. UTCTIME_IN_SEC = `date -u $LOCALTIME_IN_SEC +%s` oder so ähnlich.


    Tschüß Frank

    Es funktioniert aber erst dann richtig bei mir, wenn diese Passage im acpiwakeup skript explizit nicht durchgeführt wird.


    wie gesagt,
    ich hab diesen Code:

    Code
    echo "`date -d \"$1\" +%s`" >$WAKEALARM


    durch diesen

    Code
    echo $1 >$WAKEALARM


    ersetzt, und dann gings.


    naja, etwas mehr wars ja schon, denn bei Variante 1 ist $1 ein String und in Variante 2 ein Timestamp.



    Es muß ja irgendwie an der TimeToString funktion liegen:

    Code
    TimeToString()
{
    echo $(perl -e "(\$s,\$mi,\$h,\$d,\$mo,\$y,\$t,\$t,\$t)=\
    $TIME_FUNCTION($1); printf(\"%04d-%02d-%02d %02d:%02d:%02d\",\
    \$y+1900,\$mo+1,\$d,\$h,\$mi,\$s);")
}


    von wo die 2h differenz herkommen, aber davon versteh ich zu wenig um sicher was sagen zu können


    ...
    vorher wird hier

    Code
    if [ "$UTC" = "yes" ]; then
    TIME_FUNCTION="gmtime"
else
    TIME_FUNCTION="localtime"
fi


    ja erstmal festgelegt, dass gmtime als funktion verwendet wird, aber dass ist sicher eine perl-funktion, denn mit 'man gmtime' komme ich nicht weiter

    ... oder ist es mglw so, dass vdr an den acpiwakeup schon die UTC-Zeit übergibt, und dann wird nachher von der TimeToString Funktion diese Zeit als localtime interpretiert und nochmal in UTC umgewandelt, dann aber in eine falsche UTC?

    Okay, ich denke ich versteh nun das Problem.


    Zuerst wird in der TimeToString Funktion mit dem Befehl gmtime aus dem UTC-TimeStamp ein Datum in Textform erstellt.


    als nächstes wird in SetWakeupTimeKernelGte2_6_23
    dieser Text mittels

    Code
    echo "`date -d \"$1\" +%s`" >$WAKEALARM

    wieder in einen Timestamp zurück gerechnet.
    Das Problem ist nur, dass die date Funktion das übergebene Datum als CEST interpretiert und es nochmals in UTC umgewandelt zurück gibt.


    wenn ich nun den Skript an dieser stelle ändere und date mitteile, dass das Datum schon UTC ist, dann läufts einwandfrei:

    Code
    echo "`date -d \"$1 UTC\" +%s`" >$WAKEALARM

    Ich denke, selbst wenn das System nicht auf UTC läuft, müßte der date-Funktion an dieser Stelle vorgegaukelt werden dass das übergebene Datum ein UTC Datum sei, da es sonst auch wieder ein UTC Datum ausgibt und in einem CEST-System wäre das ja auch nicht korrekt. In den MAN von date steht jedenfalls nicht, dass es die zeit je nach dem, welches System die Systemzeit verwendet unterschiedliche Ergebnisse liefert.

    Zitat

    Original von Lord Ray
    Das Problem ist nur, dass die date Funktion das übergebene Datum als CEST interpretiert und es nochmals in UTC umgewandelt zurück gibt.


    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)?

    Ja, mein System ist auf Europe/Berlin configuriert.
    Das ist ja auch das Problem. 'Date' interpretiert es als LocalTime (UTC plus Zeitzohne als Text) und gibt UTC (ohne Zeitzohne als Zahlenwert) zurück. Die Umwandlung in UTC (ohne Zeitzohne) ist aberschon in TimeToString passiert (Localtime bzw UTC plus Zeitzohne als Zahl -> UTC ohne Zeitzohne als Text).


    Vielleicht benutze ich auch nicht die richtigen Begrifft: GMT UTC Localtime CEST was auch immer, das verwirrt mich etwas.


    So oder so ähnlich versteh ich es auf jedenfall. ;)

    Zitat

    Original von Tobi
    Sorry, hat etwas gedauert, aber ich hab jetzt eine aktualisierte Version von vdr-addon-acpiwakeup online.


    Danke für die Hinweise!


    Tobias


    Hallo Tobias,


    ich fürchte fast, dass sich in der Version 0.0.9 jetzt ein Fehler für alte Kernel eingeschlichen hat (also für die /proc/acpi/alarm Variante).
    Die 0.0.8 funktioniert bei mir einwandfrei, bei der 0.0.9 wacht er nicht auf und cat /proc/acpi/alarm liefert etwas wie "2009-06-00 **:22:00", wobei die Sternchen manchmal auch an anderen Stellen stehen.
    Bei mir ist UTC=yes (und passt auch zur BIOS-Uhr).


    Der wesentliche Unterschied von 8 zu 9 ist ja das Verschieben der Date-zu-String-Umwandlung in die Subroutinen - bin leider kein Shell-Experte, um da dem Problem weiter auf die Spur kommen zu können.


    Danke+Gruß
    Günther

    c't VDR v6, vdr 1.6.0, Kernel 2.6.24, P3 Tualatin Celeron 1400 @1GHz, Asus TUSL-2c, ACPI on, APIC on, FS 1.3 DVB-S FF, Skystar 2c

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden