ACPI mit Gigabyte GA-7VRXP

  • Hallo,


    ich möchte mein betagtes Gigabyte GA-7VRXP zum aufwachen via ACPI bewegen.


    Folgendes habe ich gemacht:


    Code
    dmesg|grep -i acpi


    Ausgabe hierfür:

    Code
    ACPI: RTC can wake from S4
     ...  
    rtc0: alarms up to one year


    Dann habe ich folgendes versucht (lt. ACPI Wakeup


    Code
    echo 0 > /sys/class/rtc/rtc0/wakealarm
    date +%s -d "Tue Dec 02 20:39:00 MET 2010" > /sys/class/rtc/rtc0/wakealarm
    poweroff


    Code
    cat /proc/driver/rtc

    zeigt dann eine Aufwachzeit um 20:34:00 an.
    Das sieht eigentlich gut aus für mich.


    Auch mit einem anschließenden Reboot konnte ich den Rechner nicht zum automatischen Aufwachen bewegen.


    Dabei hatte ich die BIOS Uhr einmal auf UTC stehen, das andere Mal auf locale Zeit.


    Beide Male haben nicht zum erhoften Starten des Rechners geführt.
    Zu beobachten ist bei Absetzen des Kommandos, dass die LED für den Betriebszustand des Rechners dabei an ist (irgendein Schlafmodus). Ansonsten ist diese erloschen wenn der Rechner heruntergefahren ist.


    Meine BIOS Einstellungen sehen wie folgt aus:


    BIOS FEATURES SETUP


    * Interrupt Mode: APIC (PIC)



    Hier würde ich denken das die Einstellung OK so ist.


    Die IRQ sind wohl nicht relevant, habe sie aber der Vollständigkeit heit halber aufgeführt.
    POWER MANAGEMENT SETUP


    * ACPI Standby State: S1/POS (S3/STR)
    * USB Dev. Wakeup From S3: Disabled
    * Suspend Time Out (Min): Dis.
    * IRQ3: Monitor
    * IRQ: Mon.
    * IRQ5: Ignore
    * IRQ7: Mon.
    * IRQ9: Ign.
    * IRQ10: Ign.
    * IRQ11: Ign.
    * IRQ13: Ign.
    * IRQ14: Mon.
    * IRQ15: Ign.
    * Soft-Off by Power Button: Instant Off (Suspend)
    * AC Back Function: Soft-Off (Full-On, Memory)
    * Modem Ring/Wake On Lan: Ena.
    * PME Event Wake Up: Ena.
    * Keyboard Wakeup From: S1(Suspend) (S1/S3; S1/S3/S4/S5)
    * PS/2 Mouse Wakeup From: S1(Suspend) (S1/S3; S1/S3/S4/S5)
    * Resume On RTC Alarm: Dis.


    Dazu muss ich sagen, dass mein Board ca. 10 JAhre alt sein wird.


    Theoretisch könnte das Board ACPI tauglich sein (trotz des Alters), aber irgendwie gelingt mir keine Annäherung.


    Was könnte ich noch tun ?

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

    Einmal editiert, zuletzt von VDRFirtie ()

  • Scheint wohl nicht so trivial zu sein :)


    Wenn ich

    Code
    find /proc/acpi/alarm

    abgebe, dann erhalte ich leider nicht

    Code
    /proc/acpi/alarm

    .


    ACPI support ist installiert.


    Meine /etc/default/rcS sieht wie folgt aus:


    Code
    TMPTIME=0 
    SULOGIN=no 
    DELAYLOGIN=no 
    UTC=yes 
    VERBOSE=no 
    FSCKFIX=no 
    RAMRUN=no 
    RAMLOCK=no 
    HWCLOCKACCESS=no 
    HWCLOCKPARS="--directisa"


    Mache ich nur einen Fehler beim testen, oder unterstützt mein Board tatsächlich kein ACPI ?

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

    Einmal editiert, zuletzt von VDRFirtie ()

  • Hallo,


    ich habe nun dem Kernel folgendes Parameter übergeben:

    Code
    hpet=disable


    Code
    kernel          /vmlinuz-2.6.26-2-686 root=/dev/hda2 ro hpet=disable


    Danach nochmals folgendes abgesetzt:


    Code
    echo 0 > /sys/class/rtc/rtc0/wakealarm
    date +%s -d "Sat Dec 04 11:20:00 MET 2010" > /sys/class/rtc/rtc0/wakealarm
    poweroff


    Aber auch hier konnte ich nach dem Absetzen des wakealarms keine

    Code
    /proc/acpi/alarm

    Datei finden, geschweige denn das der Rechner sich eingeschaltet hätte.


    Sollte unter Debian doch die gleiche Datei sein, oder ?


    Code
    cat /proc/driver/rtc

    gibt eine Aufwachzeit 5 min. vor der abgesetzten Zeit an.
    Das wäre für mich auch erst einmal richtig.


    Was mir aufgefallen ist nach dem übergeben des Kernel Parameters: Die Status LED leuchtet nicht mehr wie zuvor. Da scheine ich wirklich etwas deaktiviert zu haben.


    Was kann ich noch versuchen ?


    Keiner eine Idee ?


    Wenn alles Stricke reißen, dann müsste ich mir ein anders Board zulegen, welches ACPI unterstützt.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Ok, letzter Versuch:


    Code
    sudo sh -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"
    sudo sh -c "echo `date '+%s' -d '+ 5 minutes'` > /sys/class/rtc/rtc0/wakealarm"
    cat /sys/class/rtc/rtc0/wakealarm


    check mit:


    Code
    cat /proc/driver/rtc


    Code
    shutdown -h now


    Code
    UTC=no

    und im BIOS auf lokal gestellt.

    Code
    hpet=disable


    LED am Tower signalisiert einen suspend oder standby Modus (das weiß ich nicht so genau).


    Ergebnis: Rechner wacht nicht auf !


    OK, Entweder ich mache etwas grundliegend falsch, oder das Board unterstützt ACPI nicht, oder das Board ist zu alt !


    Könnt Ihr mir ein Board empfehlen welches ACPI Out of the Box unterstützt, zu meinen IDE-HDD`s passt und für DVB-T ausreicht ?
    Sollte in einen ATX Tower mit ATX Netzteil passen, zumindest vorüberghend ... und nicht so teuer sollte es sein. Nach Möglichkeit auch gebraucht.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Habe noch einen Beitrag gefunden, der auf einen Artikel [1] verweist, in dem folgendes geschrieben steht:


    Zitat

    Wer den PC rechtzeitig per ACPI zur nächsten Aufnahme aufwecken möchte (Paket vdr-addon-acpiwakeup), der muss in jedem Fall Kernel 2.6.28 installieren. Zudem finden Sie auch für den Kernel 2.6.28 ein entsprechendes Debian-Paket mit den Liplianin-Treibern auf der Heft-DVD, falls Ihnen die Standard-Treiber des Kernels nicht ausreichen.


    Da ich aber

    Code
    2.6.26-2-686

    benutze, könnte das vielleicht ein Problem sein, oder bezieht sich das nur auf den ctVDR ?


    [1] http://www.heise.de/ct/artikel…x-auf-Empfang-292096.html

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Versuchs doch mal so:


    http://vdr-portal.de/board/thread.php?threadid=101913


    Hab zwar ein anderes Gigabyte Board, aber es geht bei mir. Eventuell mal alle Einstellungen im BIOS zurücksetzen.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • OK, danke !


    Das Problem was ich sehe: Ich habe grundsätzlich alle Kommandos als root abgesetzt.
    Ein Problem mit den Rechten kann das eigentlich nicht sein.
    Zumal dies alles unabhängig vom VDR gewesen ist (Brückenzeit, etc. ).


    Werde aber trotzdem mal das Script versuchen und auch die Rechte für wakealarm auf 666 anpassen, da mein VDR auch als User läuft.


    Seit dem ich mit ACPI, NVRAM und set_timer probiert habe, schaltet der VDR sich leider auch nach einer Aufnahme nicht mehr ab.


    Bei dem Shutdown blicke ich ohne hin nicht wirklich durch, da dies über die S90customer Datei gelöst wird. Auch die Regelung über die Hooks ist mir nicht wirklich klar.


    Wo werden welche Scripe platziert, werden wodurch ausgelöst, ....


    Der Kernel wäre noch eine Idee, aber lt. VDR Wiki sollte es da kein Problem geben.


    Was mir auch ein wenig merkwürdig vorkommt:

    Code
    $powersave -S

    ergibt leider nicht

    Code
    ACPI


    Habe eher die Vermutung das tatsächlich das Board zu alt ist.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Hallo,


    ich habe die Rechte auf wakealarm versuchsweise geändert. Kein Erfolg !
    Hätte mich auch gewundert.


    Was mich aber stutzig macht, dass der VDR auf poweroff (auf der Tastatur bei mir "v") nicht mehr reagiert.


    Ich habe alles was mit shutdown zu tun hat gecheckt, Rechte geändert, ... aber der VDR lässt sich nicht mehr zu einem shutdown bewegen.
    Folglich schaltet dieser auch bei Aufnahmen nicht mehr ab.


    Was könnte ich noch machen, damit der VDR wieder anschaltet ?


    Ich habe auch das shutdown script aus dem Beitrag versuchsweise installiert, aber damit will der VDR auch nicht.


    Auch wenn ich den VDR als root betreibe, also das frontend via xinelibputout, dann wird das nix.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

Jetzt mitmachen!

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