NVRAM mit Asus P5A und ct-vdr 3.06

    Hallo zusammen!


    Habe heute den neuen ct-vdr in der aktuellsten Version (3.06) und aktualisiert mit jigdo installiert. Danach funktioniert NVRAM-Wackup nicht mehr. Früher mit dem ct-vdr 2 konnte ich problemlos mit --directisa arbeiten. Jetzt wacht er einfach nicht mehr auf. Laut ct-changelog sollte dieser Fehler aber in der Version 3.06 behoben sein, da dort ein Kernelpatch für den Zugriff auf höhere Speicherbereiche fehlte.


    Hat jemand eine Ahnung, wie ich das ganze gelöst kriege? Oder ein anderer Ansatz: wie prüfe ich, ob Zugriff auf die Speicherbereiche möglich ist (also der Kernelpatch auch wirklich enthalten ist)?


    gabe

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

    Vielleicht noch als Hilfe die Debug-Ausgabe von NVRAM. Setze mit dem Aufruf die Aufwachzeit auf 11 Minuten:


    Scheint soweit eigentlich okay zu sein, oder?

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

    Hi,
    dieses Board hatte ich früher auch. Es brauchte damals einen patch in nvram, da der Tag oberhalb von der Adresse 128 angesiedelt ist.

    Grüße, Dieter :)

    Na soweit ich die ct-vdr-changelog verstanden habe, soll dieser Patch ja bei der Version 3.06 enthalten sein. Habe aber auch von vielen anderen gelesen, dass sie ähnliche Probleme mit nvram-wakeup und ct-vdr 3 haben, aber hab noch keine Lösung gefunden.


    Habe auch mal folgendes probiert:
    1. Aufwachzeit mit nvram-wakeup setzen
    2. shutdown -r now für Reboot
    3. manuell ausgeschalten mit Knopf am PC
    -> Aufwachen funktionierte


    Ein anderer Versuch:
    1. Aufwachzeit mit nvram-wakeup setzen
    2. shutdown -r now für Reboot
    3. nach dem Reboot shutdown -h now für Ausschalten
    -> Aufwachen funktionierte nicht


    Das Ergebnis habe ich auch schon in anderen Threads gelesen: Scheint also an der Art und Weise zu liegen, wie Linux den Rechner ausschaltet. Hat sich da irgendwas geändert??? Weiß jemand, wie man da eventuell andere "Methoden" testen könnte?


    Bin für jede Hilfe dankbar,
    gabe

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

    Das ganze scheint ein Problem vom APM im Kernel zu sein. Habe mir mal den Power-Off-Kernel installiert und dann folgenden Test manuel gemacht:


    1. Aufwachzeit mit nvram-wakeup setzen
    2. shutdown -r now für Reboot
    3. im Lilo Power-Off-Kernel gebootet
    -> Aufwachen funktionierte


    Vergleicht man die Kernel-Versionen so ist der Power-Off ein 2.4.18 und der ct-vdr-Kernel ein 2.4.27 (oder so ähnlich)


    Jedenfalls arbeiten beide mit dem APM-Power-Off, aber rufen unterschiedliche Effekte hervor. Das klassische Reboot-Problem von NVRAM ist es auch nicht, weil ich mit dem ct-vdr 2 keinerlei Reboot benötigte. Außerdem bringt ein Reboot auch nichts, wenn ich den 2.4.27-Kernel boote und dann ausschalten lasse. Dann funktioniert das aufwachen trotzdem nicht.


    Also bleibt nur der Umweg über den Reboot mit dem Power-Off-Kernel. Dazu muss man in der Datei /usr/share/vdr/shutdown-hooks/S90.nvram-wakeup noch das manuelle ausführen des Reboots eintragen. Einfach bei "case $PIPESTATUS in" für den Fall 0 einfach noch

    Code
    echo "SHUTDOWNCMD=\"$SPECIALSHUTDOWN\""

    einfügen und den dafür notwendigen Parameter

    Code
    SPECIALSHUTDOWN="lilo -R PowerOff ; shutdown -r now"

    in /etc/vdr/vdr-nvram-wakeup.conf eintragen.


    Falls jemand noch einen besseren Weg findet, würde ich mich freuen, darüber informiert zu werden,
    gabe

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

    Einmal editiert, zuletzt von gabe ()

    Hallo Gabe,
    das P5A braucht keinen Reboot wie Du ja bereits beschrieben hast.
    Ich hatte damals kernel 2.4.27 (und ältere). In Grub war noch apm=on, acpi=off oder so ähnlich angegeben.
    Guess sagte damals dass ich nvram patchen müsste, habe aber die Details vergessen (irgendwas mit addr > 128).
    Funktioniert es wenn Du von Hand das nvram-wakeup startest? Wird es in das CMOS ram geschrieben?

    Grüße, Dieter :)

    Zitat

    Original von gabe
    ... Version 3.06 behoben sein, da dort ein Kernelpatch für den Zugriff auf höhere Speicherbereiche fehlte.


    Hat jemand eine Ahnung, wie ich das ganze gelöst kriege? Oder ein anderer Ansatz: wie prüfe ich, ob Zugriff auf die Speicherbereiche möglich ist (also der Kernelpatch auch wirklich enthalten ist)?


    wenn man --directisa benutzt, ist kein Kernel-Patch notwendig.


    es scheint so, als ob der bei c't VDR 3.06 verwendete Kernel, oder besser gesagt, die im Kernel verwendete version des ACPI-Treibers, deinen Rechner "zu gut" schlafen legt.


    das wurde hier schon diskutiert.


    Einfach in /etc/vdr/vdr-nvram-wakup.conf aus nvram-wakeup 0-97-4:


    FORCE_REBOOT="yes"

    Also nochmal zusammengefasst: mit und ohne --directisa wird die Zeit völlig richtig gesetzt. Also der Zugriff auf die Speicherbereiche ist möglich. Außerdem müsste er dann bei einem Testlauf auch eine Fehlermeldung bringen. Gestartet habe ich NVRAM immer über die Konsole (also von Hand). Wenn es da klappt, kann ich das dann ohne Probleme in das VDR-Addon einbauen.


    Starten tue ich meinen normalen VDR mit

    Code
    apm=poweroff noapic acpi=off


    in der lilo.conf (ja, ich hab danach auch lilo ausgeführt). Also mit ACPI und zu fest schlafen legen hat das nichts zu tun. Schlafen wird der übers APM gelegt. Aber das war bei meinem ct-vdr 2 auch so.


    Ein Reboot bringt in dem Sinne überhaupt nichts. Wenn ich VDR wieder normal boote und dann ausschalten lasse, wacht er auch nicht mehr auf. Wenn ich ihn aber gleich nach dem Reboot während der BIOS-Meldungen mit dem Gehäuseschalter ausschalte, dann wacht er zur angegebenen Zeit ohne Probleme auf. Weiterhin kann ich mit dem Shutdown-Kernel der ct-VDR-Distribution den Rechner auch ausschalten lassen und er wacht erfolgreich auf.


    Zusammenfassend: Ja, mein Rechner schläft zu "tief" ein, wenn ich ihm im normalen VDR-Betrieb ausschalten lasse. Der einzigste Unterschied zwischen Poweroff-Kernel und VDR-Kernel ist die Version: Poweroff v2.4.18 und VDR v.2.4.27. Ob es genau am Kernel liegt oder an einer kleinen Änderung in dem APM-Modul ... keine Ahnung.


    Wie gesagt, ich habe es jetzt so eingerichtet, dass ich den Reboot für den Poweroff-Kernel erzwinge und dann funktioniert es auch. Mich würde aber interessieren, was in diesem anders gemacht wird als im normalen Kernel und ob man das vielleicht in den normalen Kernel auch übernehmen kann um den unnötigen Reboot zu umgehen.


    Die Option FORCE_REBOOT="yes" für die /etc/vdr/vdr-nvram-wakup.conf kannte ich noch nicht. Werde ich aber mal ausprobieren, damit ich mir vielleicht den Hack im Shutdown-Hook des NVRAM-Addons sparen kann. Habe aber noch nvram-wakeup v0.97-1 oder v0.97-3. Geht es dort auch? Habe auf der Projektseite auch noch keine Version 0.97-4 gefunden.


    Danke für eure Bemühungen,
    gabe

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

    Zitat

    Original von gabe
    Also nochmal zusammengefasst: mit und ohne --directisa wird die Zeit völlig richtig gesetzt. Also der Zugriff auf die Speicherbereiche ist möglich. Außerdem müsste er dann bei einem Testlauf auch eine Fehlermeldung bringen.


    ja, das ist richtig. Da du oben was von einem Patch geschrieben hast, wollte ich das als Fehlerquelle ausschliessen, denn mit --directisa braucht man diesen patch nicht.


    Zitat

    Gestartet habe ich NVRAM immer über die Konsole (also von Hand). Wenn es da klappt, kann ich das dann ohne Probleme in das VDR-Addon einbauen.


    das ist auch richtig.


    Zitat

    Starten tue ich meinen normalen VDR mit

    Code
    apm=poweroff noapic acpi=off


    in der lilo.conf (ja, ich hab danach auch lilo ausgeführt). Also mit ACPI und zu fest schlafen legen hat das nichts zu tun. Schlafen wird der übers APM gelegt.


    ok. ich hatte angenommen, dass du (wie bei der c't Distri default ist) ACPI benutzt.
    ich korrigiere meine Aussage zu "APM legt deinen Rechner zu fest schlafen"
    in diesem Falle koennte ein eifaches "apm=realmode_poweroff" statt "apm=poweroff" schon helfen.


    Zitat

    Ein Reboot bringt in dem Sinne überhaupt nichts.


    das ist auch richtig: ein normaler reboot bringt nichts. Aber wie du schon oben beschrieben hast, hast du als SPECIALSHUTDOWN den Befehl "lilo -R PowerOff ; shutdown -r now" eingebaut.
    bei einem erzwungenen reboot wird eben dieser Befehl ausgefuehrt, so dass
    kein "normaler" reboot stattfindet, sondern ein reboot in den PowerOff-Kernel.


    Zitat

    Wie gesagt, ich habe es jetzt so eingerichtet, dass ich den Reboot für den Poweroff-Kernel erzwinge und dann funktioniert es auch.


    das hast du mit der Zeile

    Code
    SHUTDOWNCMD=$SPECIALSHUTDOWN


    im Falle "0" gemacht.


    Zitat

    Die Option FORCE_REBOOT="yes" für die /etc/vdr/vdr-nvram-wakup.conf kannte ich noch nicht. Werde ich aber mal ausprobieren, damit ich mir vielleicht den Hack im Shutdown-Hook des NVRAM-Addons sparen kann.


    genau das wird dadurch erreicht.


    Zitat

    Habe aber noch nvram-wakeup v0.97-1 oder v0.97-3. Geht es dort auch? Habe auf der Projektseite auch noch keine Version 0.97-4 gefunden.


    nein, erst ab -4. Die muesste auf Tobis seite zu finden sein...

    Danke für die vielen Zustimmungen, aber ich wollte eigentlich nur nochmal festhalten, wie der Stand ist. Aber wenigstens bin ich mit der Meinung nicht alleine.


    Für mich steht fest: an nvram-wakeup selber liegt es nicht. Das ist ein fantastisches Programm und funktioniert ohne Probleme.


    Mit der Option apm=realmode_poweroff habe ich auch schon erfolglos probiert, aber ich habe da auch so viele verschiedene Schreibweisen gefunden: realmode_poweroff, realmode-poweroff und real-mode-poweroff. Weis jetzt nicht genau, ob ich es schon mit Unterstrich probiert habe. Teste ich aber nochmal. In welcher Doku könnte man nachlesen, welche Schreibweise richtig ist? (bin bei Linux noch nicht so lange dabei)


    Die neue Version 0.94-4 hab ich jetzt auch bei e-tobi gefunden. Für alle, die nach was ähnlichem suchen: http://www.e-tobi.net/vdr/sarge/testing/binary/backports/


    Bye, gabe

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

    Zitat

    Original von gabe
    ... viele verschiedene Schreibweisen gefunden: realmode_poweroff, realmode-poweroff und real-mode-poweroff. Weis jetzt nicht genau, ob ich es schon mit Unterstrich probiert habe.


    Auszug aus arch/i386/kernel/apm.c:


    also ist es egal, ob man Unter- oder Bindestrich nimmt. allerdings ist real-mode-poweroff nicht richtig.

    Hab es gestern Abend nochmal probiert, aber auch ein realmode_poweroff hat nichts bewirkt. Also bleibt wohl nur der Umweg über den Poweroff-Kernel. Das Debian-Paket mit NVRAM-wakeup 0.97-4 ließ sich aber problemlos installieren und FORCE_REBOOT=yes arbeitet perfekt.


    Danke für deine Bemühungen. Ist zwar nicht die perfekte Lösung, aber besser als mein Hack.
    Bye, gabe!

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

    Das Problem hat sich jetzt gelöst. Habe den neuen Kernel von ct-VDR 4 eingespielt (siehe hier) und schon funktioniert NVRAM-Wackup wieder ohne Reboot. Ist jetzt Kernel 2.4.30. Wieß nicht, ob es an der neueren Version liegt oder daran, dass ct jetzt einen Standard Kernel von Kernel.org mit LinuxTV-Patches verwendet anstatt den Debian-Kernel zu patchen.


    Bye, gabe!

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden