ct VDR 6 Problem mit ACPI wakeup

  • Ich benutze Kernel 2.6.23.8


    Es gibt mittlerweile eine alternative Möglichkeit die rtc des Computers anzusteuern. Bei mir heisst das neue Modul rtc_cmos. Da das alte Modul ein laden des neuen verhindert kann man es entweder nicht mit in den Kernel kompilieren oder man muss es blacklisten, dazu einen Eintrag 'blacklist rtc' in die /etc/modprobe.d/blacklist eintragen.


    Wenn das neue Modul erfolgreich geladen wurde steht in etwa so etwas in in der dmesg:

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


    Man hat damit auch eine neue Verzeichnisstruktur unter /sys/class/rtc/.
    Nun muss man dem ACPI_Wakeup Skript noch mitteilen, wo der neue Wecker ist. In /etc/vdr/vdr-addon-acpiwakeup.conf folgendes ändern:
    ACPI_ALARM=/sys/class/rtc/rtc0/wakealarm


    In /usr/share/vdr/shutdown-hooks muss auch noch einiges verändert werden.
    Zum Einen wird die Zeit bei der neuen Methode in Sekunden erwartet. Da dies das gleiche Format ist, wie der VDR es ausgibt, ist eine Konversion per TimeToString nicht mehr nötig. Also die Stellen mit TIME_TO_SET=`TimeToString $TIMER` durch TIME_TO_SET=$TIMER ersetzen. Das neue System erlaubt kein Setzen der Zeit wenn schon ein Timer existiert, deshalb muss dieser vorher gelöscht werden.
    Dazu vor der Zeile "echo TIME_TO_SET >$ACPI_ALARM" ein "echo 0 >$ACPI_ALARM" einfügen. Da mit der neuen Methode ein zweimaliges Setzen eh nicht möglich ist, habe ich die zweite echo-Zeile noch auskommentiert.


    Ich hoffe, du kommst damit ans Ziel.
    Was mir bei meinen Tests noch aufgefallen ist: Wenn man in die /sys/class/rtc/rtc0/wakealarm einen Wert einträgt, wird er vom Modul irgendwie umgerechnet. Also ein 'cat' liefert einen anderen Wert als man per 'echo' reingeschrieben hat. Aber es funktioniert!
    Wenn das bei dir funktioniert, können wir vielleicht Tobi bitten, eine kleine Änderung am offiziellen addon vorzunehmen um dies für alle zur Verfügung zu stellen.

  • guten tach


    also, die einrichtung lief wie von dir beschrieben.


    ich nutze vdr-1.4.7. gibt diese version die aufwachzeit schon im korrekten format an?


    rtc_cmos lies sich auch laden:


    Nov 22 12:35:07 vdr2 kernel: rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
    Nov 22 12:35:07 vdr2 kernel: rtc0: alarms up to one month



    jedoch steht im log :


    Nov 22 11:33:48 vdr2 vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.acpiwakeup as shell script
    Nov 22 11:33:48 vdr2 vdr-addon-acpiwakeup: Current ACPI alarm time:
    Nov 22 11:33:48 vdr2 vdr-addon-acpiwakeup: Setting ACPI alarm time to:
    Nov 22 11:33:48 vdr2 vdr-addon-acpiwakeup: New ACPI alarm time:
    Nov 22 11:33:48 vdr2 vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.custom




    meine /usr/share/vdr/shutdown-hooks/s90.acpi-wakeup.sh:
    #!/bin/sh
    #
    # VDR shutdown hook for ACPI - Tobias Grimm <vdr@e-tobi.net>
    # --------------------------
    #
    # This shutdown hook sets the wakeup time for the next timer using
    # ACPI.
    #


    # read arguments for acpi-wakeup from conf-file
    . /etc/vdr/vdr-addon-acpiwakeup.conf


    # take care of UTC setting
    if [ -f /etc/default/rcS ]; then
    UTC=$(egrep "^[^#]*UTC=" /etc/default/rcS | tail -n1 | cut -d= -f2)
    fi


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


    # Defaults:
    [ -z "$ACPI_ENABLED" ] && export ACPI_ENABLED="yes"
    [ -z "$ACPI_ALARM" ] && export ACPI_ALARM="/proc/acpi/alarm"
    [ -z "$ACPI_REGULAR_DAYS" ] && export ACPI_REGULAR_DAYS="0"
    [ -z "$ACPI_REGULAR_TIME" ] && export ACPI_REGULAR_TIME="00:00"
    [ -z "$ACPI_START_AHEAD" ] && export ACPI_START_AHEAD="5"


    LOG="logger -t vdr-addon-acpiwakeup "
    TIMER=$1
    WAKEUP_FILE="/var/cache/vdr/acpiwakeup.time"


    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);")
    }



    if [ $ACPI_ENABLED = "yes" ]; then
    # check if we should wake up before the next timer:
    if [ $ACPI_REGULAR_DAYS -gt 0 ]; then
    REGULAR_TIMER=$(date -d "$ACPI_REGULAR_TIME" +%s)
    if [ $REGULAR_TIMER -lt $(date +%s) ] ; then
    REGULAR_TIMER=$(($REGULAR_TIMER + 24 * 60 * 60))
    fi
    if [ $TIMER -eq 0 ] || [ $TIMER -gt 0 -a $REGULAR_TIMER -lt $TIMER ] ; then
    TIMER=$REGULAR_TIMER
    fi
    fi
    if [ $TIMER -gt 0 ]; then
    TIMER=$(($TIMER - 60 * $ACPI_START_AHEAD))
    fi
    if [ $TIMER -gt 0 ] && [ $TIMER -lt $((`date +%s` + 5 * 60)) ]; then
    $LOG "Can not set wakeup time less than 5 minutes ahead."
    echo "ABORT_MESSAGE=\"Wakeup in less than 5 minutes, aborting!\""
    exit 1
    else
    # set the wakeup time
    if [ -e $ACPI_ALARM ]; then
    if [ $TIMER -eq 0 ]; then
    # no wakeup - I don't really now right now, how to disable
    # the wakeup !!!!
    TIMER=$((`date +%s` - 5 * 60))
    TIME_TO_SET=$TIMER else
    # convert time_t to YYYY-MM-DD HH:MM:SS
    TIME_TO_SET=$TIMER
    fi


    # now set the wakeup time:
    $LOG "Current ACPI alarm time: `cat $ACPI_ALARM`"
    $LOG "Setting ACPI alarm time to: $TIME_TO_SET"
    echo 0 >$ACPI_ALARM
    echo $TIME_TO_SET >$ACPI_ALARM


    # Set it once more - some boards require this!
    # echo $TIME_TO_SET >$ACPI_ALARM
    $LOG "New ACPI alarm time: `cat $ACPI_ALARM`"


    # remember wakeup time for stop script
    echo $TIME_TO_SET >$WAKEUP_FILE
    else
    $LOG "$ACPI_ALARM not found. ACPI needed!!!"
    echo "ABORT_MESSAGE=\"ACPI not installed, shutdown aborted!\""
    exit 1
    fi
    fi
    else
    $LOG "ACPIWakeup functionality is disabled"
    fi



    muss ich da evtl oben bei den defaults noch das "/proc/acpi/alarm" ändern? zeigte bei nem test keine auswirkung.


    seltsam


    grüße martin

  • mir ist grad aufgefallen dass acpid mit dem exp ct 2.6.22-2-486 kernel


    bei mir auf meinem commell lv-671 mitx pentium m board probleme macht.


    acpid liefert folgendes:


    acpid: can't open /proc/acpi/event: Device or resource busy



    lsof /proc/acpi/event:


    COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
    acpid 2163 root 3r REG 0,3 0 4026531906 /proc/acpi/event



    hat da vielleicht jemand nen tip zu?

  • Die 1.4.7 benutze ich auch.
    Dass im Log gar nichts ankommt ist komisch. Ich habe in deinem Skript ertmal keinen Fehler gefunden. Es scheint, als ob deine time_to_set Variable leer ist. Denn zumindest "Setting ACPI alarm time to:" ist unabhängig von der neuen wakeup-Position.
    Probiere doch mal in dem Skript an verschiedene Stellen ein echo $TIMER bzw. $TIME_TO_SET einzufügen und das Skript von hand per /usr/share/vdr/shutdown-hooks/s90.acpi-wakeup.sh 111 `date +%s` zu starten. Irgendwo scheint die Variable gelöscht zu werden.
    Wenn ich zu hause bin kann ich ja mal mein skript posten, auch wenn ich auf den ersten Blick keinen Unterschied sehe.

  • hallo


    also hier der test:


    habe die 2 echos je 2 mal nach schleifen eingefügt:


    root@vdr2:~# /usr/share/vdr/shutdown-hooks/S90.acpiwakeup 111 `date +%s`
    -189



    root@vdr2:~# /usr/share/vdr/shutdown-hooks/S90.acpiwakeup 1000 `date +%s` ABORT_MESSAGE="Wakeup in less than 5 minutes, aborting!"



    root@vdr2:~# /usr/share/vdr/shutdown-hooks/S90.acpiwakeup 11 `date +%s`
    -289


    root@vdr2:~#



    grüße

  • Ok, zum einen hatte ich dir das falsche geschrieben. Ich ging davon aus, dass die Kommandozeilenparameter bei 0 anfangen zu zählen. Daher dachte ich den ersten Parameter auf irgendetwas setzen zu müssen. Das Kommando zum Testen sollte jetzt jedenfalls heissen /usr/share/vdr/shutdown-hooks/S90.acpiwakeup $((`date +%s` + 400)), dies setzt eine Aufwachzeit in 400Sek.


    Ich habe aber trotzdem den Fehler im Skript gefunden: In Zeile der Zeile "TIME_TO_SET=$TIMER else" muss das else in einer neuen Zeile beginnen, dann klappt es auch.

  • ok


    das skript schaut jetzt so aus:


    #!/bin/sh
    #
    # VDR shutdown hook for ACPI - Tobias Grimm <vdr@e-tobi.net>
    # --------------------------
    #
    # This shutdown hook sets the wakeup time for the next timer using
    # ACPI.
    #


    # read arguments for acpi-wakeup from conf-file
    . /etc/vdr/vdr-addon-acpiwakeup.conf


    # take care of UTC setting
    if [ -f /etc/default/rcS ]; then
    UTC=$(egrep "^[^#]*UTC=" /etc/default/rcS | tail -n1 | cut -d= -f2)
    fi


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


    # Defaults:
    [ -z "$ACPI_ENABLED" ] && export ACPI_ENABLED="yes"
    [ -z "$ACPI_ALARM" ] && export ACPI_ALARM="/proc/acpi/alarm"
    [ -z "$ACPI_REGULAR_DAYS" ] && export ACPI_REGULAR_DAYS="0"
    [ -z "$ACPI_REGULAR_TIME" ] && export ACPI_REGULAR_TIME="00:00"
    [ -z "$ACPI_START_AHEAD" ] && export ACPI_START_AHEAD="5"


    LOG="logger -t vdr-addon-acpiwakeup "
    TIMER=$1
    WAKEUP_FILE="/var/cache/vdr/acpiwakeup.time"


    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);")
    }



    if [ $ACPI_ENABLED = "yes" ]; then
    # check if we should wake up before the next timer:
    if [ $ACPI_REGULAR_DAYS -gt 0 ]; then
    REGULAR_TIMER=$(date -d "$ACPI_REGULAR_TIME" +%s)
    if [ $REGULAR_TIMER -lt $(date +%s) ] ; then
    REGULAR_TIMER=$(($REGULAR_TIMER + 24 * 60 * 60))
    fi
    if [ $TIMER -eq 0 ] || [ $TIMER -gt 0 -a $REGULAR_TIMER -lt $TIMER ] ; then
    TIMER=$REGULAR_TIMER
    fi


    fi
    if [ $TIMER -gt 0 ]; then
    TIMER=$(($TIMER - 60 * $ACPI_START_AHEAD))
    fi
    if [ $TIMER -gt 0 ] && [ $TIMER -lt $((`date +%s` + 5 * 60)) ]; then
    $LOG "Can not set wakeup time less than 5 minutes ahead."
    echo "ABORT_MESSAGE=\"Wakeup in less than 5 minutes, aborting!\""
    exit 1
    else
    # set the wakeup time
    if [ -e $ACPI_ALARM ]; then
    if [ $TIMER -eq 0 ]; then
    # no wakeup - I don't really now right now, how to disable
    # the wakeup !!!!
    TIMER=$((`date +%s` - 5 * 60))
    TIME_TO_SET=$TIMER
    else
    # convert time_t to YYYY-MM-DD HH:MM:SS
    TIME_TO_SET=$TIMER
    fi
    # now set the wakeup time:



    $LOG "Current ACPI alarm time: `cat $ACPI_ALARM`"
    $LOG "Setting ACPI alarm time to: $TIME_TO_SET"
    echo 0 >$ACPI_ALARM
    echo $TIME_TO_SET >$ACPI_ALARM


    # Set it once more - some boards require this!
    # echo $TIME_TO_SET >$ACPI_ALARM
    $LOG "New ACPI alarm time: `cat $ACPI_ALARM`"


    # remember wakeup time for stop script


    echo $TIME_TO_SET >$WAKEUP_FILE
    else
    $LOG "$ACPI_ALARM not found. ACPI needed!!!"
    echo "ABORT_MESSAGE=\"ACPI not installed, shutdown aborted!\""
    exit 1
    fi
    fi
    else
    $LOG "ACPIWakeup functionality is disabled"
    fi


    /usr/share/vdr/shutdown-hooks/S90.acpiwakeup $((`date +%s` + 650))



    cat /sys/class/rtc/rtc0/wakealarm liefert jedoch nichts zurück. die datei ist leer.

  • Also ich backe mir meine Kernel selbst. Da der 2.6.22 bei mir nicht funktionierte hatte ich es beim 2.6.23 das erste mal probiert. Kann sein, dass in der 2.6.22 noch etwas anders war. Bei mir bleibt die Datei auch ohne Fehlermeldung leer wenn ich eine ungültige Zeit eingebe. Also vielleicht hilft dir ein frischer Kernel 2.6.23, ist wirklich nicht schwer.


    Wo genau hast du denn deinen Kernel her, dann würde ich den auch mal testen?


  • Hallo zusammen,


    das Problem habe ich auch. Die Uhrzeit wird richtig eingetragen und das Datum nicht.
    Ich habe die /usr/share/vdr/shutdown-hooks/S90.acpiwakeup
    um ein paar log-Ausgaben erweitert. Das Datum wird richtig geschrieben und ist auch am Ende des Scriptes korrekt in /proc/acpi/alarm gespeichert. Anscheinend wird es beim Runterfahren überschrieben. HWCLOCKACCESS=NO hat nichts genützt.


    Schuld zu sein scheint mir das Script /etc/init.d/hwclock.sh, aber sicher bin ich mir nicht.


    Weiß jemand eine Lösung? Ich habe in langer Kleinarbeit meinen VDR 6 soweit hinbekommen, dass er einigermaßen läuft und will nicht alles neu machen.


    Danke.


    GBruno

    Hardware:
    Desktop: Intel Core i5, 4x3,2 GHz, ASUS-Mainboard HL 97 plus, Festplatte Hybrid-S-ATA 2TB, 16 GB RAM, DVB-Sky-USB-Stick (DVB-T2), LG-4120B Brenner, VDR 2.4.8 (selbst kompiiiert, Ubuntu 20.04.2),
    Wohnzimmer: ASUS-Mainboard F2A85-V Pro, AMD A10 (?), 1TB-HD, 8 GB Speicher, Technotrend 4100 Budget (DVB-S), Prozessor-Grafik HD7660D, VDR 2.4.1 von XUbuntu 20.04.2).

    Einmal editiert, zuletzt von GBruno ()

  • Hallo GBruno,


    das passiert, wenn das Board nicht dafür geeignet ist. Je nach ACPI-Implemation im Bios kann das Board meist mindestens zu einer bestimmten Uhrzeit wecken, dann wird auch nur die Uhrzeit abgespeichert. Die Besseren können es auch zu einem bestimmten Tag innerhalb des nächsten Monats oder auch zu einem bestimmten Datum abspeichern.
    Für dein Problem gibt es diese Optionen mit den regular_days in der Konfiguration. Das kannst du z.B. auf täglich 5:00 stellen und einen cron-job anlegen, der z.B. Wartungssachen o.ä. (tvmovie-update...) um diese Zeit macht und den Rechner wieder abschaltet. Wenn man das nicht macht, hat man das Problem, falls ein timer für übermorgen anliegt, er morgen angeht und erst nach Stunden wieder automatisch ausgeht.


    Alternativ könntest du auch mal einen neueren Kernel probieren (s.o.). Bei mir kann ich seit dem Kernel 2.6.23 über die rtc-Methode bis zu einem Jahr in die Zukunft programmieren.

  • Zitat

    Original von ecki
    /proc/acpi/alarm ist deprecated und wird in neueren Kerneln nicht mehr unterstützt. Dies läuft jetzt über das rtc-device und ist an einer anderen Stelle. Ich bin letztens auch von nvram wieder auf diese Schiene umgestiegen. Das ACPI-shutdown Skript habe ich entsprechend angepasst, in den letzten 2 Wochen hat es auch zuverlässig funktioniert. Die gute Sache ist, seit der Umstellung funktioniert mein board bis zu ein Jahr in die Zukunft (vorher max 24h). Ich bin grad noch unterwegs, poste aber sobald ich zu hause bin mal die Änderungen.


    Hallo Ecki,


    danke füre Deine Antwort - es scheint wirklich am Mainboard zu liegen. ACPI vergisst das Datum, auch wenn ich vor dem Herunterfahren den VDR abschalte. Merkwürdigerweise tritt dies bei einem älteren Mainboard (ASUS K8N-E Deluxe) nicht auf.


    Könntest Du ein paar Angaben machen, wo ich etwas zum rtc-Device finde bzw. auch Dein geändertes Shutdown-Script schicken?


    Danke.


    GBruno

    Hardware:
    Desktop: Intel Core i5, 4x3,2 GHz, ASUS-Mainboard HL 97 plus, Festplatte Hybrid-S-ATA 2TB, 16 GB RAM, DVB-Sky-USB-Stick (DVB-T2), LG-4120B Brenner, VDR 2.4.8 (selbst kompiiiert, Ubuntu 20.04.2),
    Wohnzimmer: ASUS-Mainboard F2A85-V Pro, AMD A10 (?), 1TB-HD, 8 GB Speicher, Technotrend 4100 Budget (DVB-S), Prozessor-Grafik HD7660D, VDR 2.4.1 von XUbuntu 20.04.2).

  • Hallo GBruno,


    bin grad nicht zu hause. Das Skript ist im Prinzip aber das von demartin gepostete. Zu den rtc-sachen kann ich dir leider nicht allzu viel sagen. Da das alles scheinbar noch recht neu ist, findet man nicht allzu viele Informationen. Du kannst ja mal nach wakealarm googeln. Die relevanten Dinge hatte ich aber oben schon mal geschrieben.


    Soweit ich weiss brauchst du, um das alles nutzen zu können, einen Kernel >2.6.22. Scheinbar hast du Glück, wir haben ähnliche Hardware. Ich habe einen Pundit P1-AH2, da ist ein fast identisches Board zu deinem drin, wenn ich mich recht erinnere. Wenn du willst, kann ich dir heute abend mal meinen Kernel mailen, falls du nicht selber kompilieren willst.

  • Hallo Leutz,


    habe versucht eure Tips umzusetzten nur das Ding geht nicht an :(
    Manuelles Zeit setzen klappt nur die Übergabe vom VDR an ACPI scheint nicht zu klappen.


    Findet sich jemand hilfsbereites ;) ?


    GLG

    <-- Der Ehrgeiz gibt zu letzt auf. -->


    - ASUS P2-M2A690G / 2x2,2Ghz / 2GB RAM /250 GB / FF-Karte TT S2300 / VDR 1.6.0-2 ctvdr8 - ct-Distri v7.0 und Debian v5.0 - 2.6.28
    - ACER 5520 - VDR 1.6.0-2 - Debian v5.0 Lenny - 2.6.28-2 - XINELIBOUT
    :portal4

Jetzt mitmachen!

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