nvram und ct-VDR3

    hi,


    ... ich bin' schon wieder...
    hab schon überall gesucht, aber nix passendes gefunden.


    wenn ich nvram-wakeup --debug eingebe, bekomme ich den hinweis
    rtc_date (0x7F) is beyond the end of nvram
    hier war schon mal sowas...


    beim ctvdr2 hatte ich keine probleme! das board wird auch richtig erkannt - aber es kommt halt der fehler und der hinweis, ich soll doch --drirectisa als option nehmen.
    jetzt hab ich gelesen, dass das nachteile hat (wenn gleichzeitig ins bios geschrieben wird).


    was kann ich tun damit es ohne ---directisa funzt???

    cu
    fossy
    -----------------------------------------------------------------
    VDR1: pentium m, aopen i855gmem-lfs / hauppauge nexus 2.2, technisat skystar2 / (im silverstone lascala lc11m-s) / debian lenny / e-tobi --> vdr 1.6.0 / kernel 2.6.28-etobi.3-686
    VDR2: D945GSEJT mit 2GB RAM + ... (budget) / debian lenny / e-tobi --> vdr 1.6.0 /
    -----------------------------------------------------------------
    meine klitzekleine homepage :arme hier

    ... noch die logdatei


    cu
    fossy
    -----------------------------------------------------------------
    VDR1: pentium m, aopen i855gmem-lfs / hauppauge nexus 2.2, technisat skystar2 / (im silverstone lascala lc11m-s) / debian lenny / e-tobi --> vdr 1.6.0 / kernel 2.6.28-etobi.3-686
    VDR2: D945GSEJT mit 2GB RAM + ... (budget) / debian lenny / e-tobi --> vdr 1.6.0 /
    -----------------------------------------------------------------
    meine klitzekleine homepage :arme hier

    Hi
    das in der nvram-wakeup.conf könnte helfen:


    Adressen über 0x71 sind möglich?



    ja, wobei die drei rtc_* Werte zu rtc_time=ON zusammengefasst werden muessen


    Wobei die zu posten vielleicht hilfreich gewesen währe


    Gruss Ulf

    Samsung UE43RU7479U, Antec Fusion Black, Prime A320m-k, Ryzen3 3200G, 2* DVB-T2,
    Yavdr-ansible auf Ubuntu Server 22.04

    hi,


    nunja, bisher hab ich die nvram-wakeup.conf ja garnicht gebraucht...


    hab jetzt mal wie in der bsp-conf die werte aus dem debug eingetragen...
    mit der option --directisa setzt er zwar den timer und fährt runter aber der rechner startet nicht zur angegebenen zeit :(

    cu
    fossy
    -----------------------------------------------------------------
    VDR1: pentium m, aopen i855gmem-lfs / hauppauge nexus 2.2, technisat skystar2 / (im silverstone lascala lc11m-s) / debian lenny / e-tobi --> vdr 1.6.0 / kernel 2.6.28-etobi.3-686
    VDR2: D945GSEJT mit 2GB RAM + ... (budget) / debian lenny / e-tobi --> vdr 1.6.0 /
    -----------------------------------------------------------------
    meine klitzekleine homepage :arme hier

    hi,


    irgendwo hab ich was gelesen von "kernel neu übersetzten"...
    kann es daran liegen???

    cu
    fossy
    -----------------------------------------------------------------
    VDR1: pentium m, aopen i855gmem-lfs / hauppauge nexus 2.2, technisat skystar2 / (im silverstone lascala lc11m-s) / debian lenny / e-tobi --> vdr 1.6.0 / kernel 2.6.28-etobi.3-686
    VDR2: D945GSEJT mit 2GB RAM + ... (budget) / debian lenny / e-tobi --> vdr 1.6.0 /
    -----------------------------------------------------------------
    meine klitzekleine homepage :arme hier

    Moin!


    Seit Tagen suche ich nach einer Lösung für dasselbe Problem.


    Ich habe 2 ctvdr Partitionen auf einer Platte auswählbar über lilo.
    Die ctvdr1 wacht einwandfrei auf (und ist bis auf gelegentliche Hänger und den
    bekannten Restart bei Aufnahmebeginn im laufenden Betrieb absolut solide).
    Die ctvdr3 (3.04) setzt die Wakeup Zeit einwandfrei, wacht dann aber nicht
    auf.


    Nach langem Testen denke ich wir suchen an der völlig falschen Ecke.


    Meine Analyse bis hier:


    nvram-wakeup funktioniert einwandfrei, wenngleich etwas unterschiedlich auf
    den beiden Instanzen:


    (Das P2B wird ohne /etc/nvram-wakeup.conf unterstützt. guess-helper hat kein
    brauchbares file erzeugt, als ich es vor einem guten halben Jahr mit ctvdr1
    ausprobiert habe,weil mein P2B-S zunächst nicht erkannt wurde. Ich hab mir
    dann das binary gepatcht (P2B-F --> P2B-S). Es funktioniert seitdem einwandfrei.).


    Unter ctvdr1 kann nvram-wakeup mit oder ohne --directisa benutzt werden.
    Beides führt zu erfolgreichem wakeup.


    Unter ctvdr3 kann nvram-wakeup nur mit --directisa benutzt werden, setzt die
    Zeit aber einwandfrei. Ohne --directisa gehts deshalb nicht, weil das nvram
    vom System als 114 bytes lang gesehen wird, bei ctvdr1 aber als 128 bytes
    lang. (siehe output von "nvram-wakeup --debug" oder "cat /dev/nvram | wc
    -c").


    Daß die Zeit einwandfrei gesetzt wurde, kann mit "cat_nvram INTEL
    > /tmp/nvram.test" gecheckt werden:
    Alarmzeit: Tag (offset 0x7f, die untersten 7 bit)
    Stunde (offset 0x77)
    Minute (offset 0x75)
    Sekunde(offset 0x73)
    Uhrzeit: Stunde (offset 0x76)
    Minute (offset 0x74)
    Sekunde(offset 0x72)
    Jedes "Halbbyte" ist für sich als Dezimalzahl zu lesen, z.B. in einem
    hex-Editor.


    Nachdem in Bezug auf den geschriebenen nvram Inhalt kein Unterschied
    zwischen ctvdr1 und ctvdr3 feststellbar war, dann heute abend ein ganz
    anderer Testansatz:


    System anschalten, im BIOS von Hand eine Startzeit eintragen, die z.B. 10
    Minuten in der Zukunft liegt, Sytem booten in ctvdr3. Nach dem Hochfahren
    auf einer Konsole einloggen und mit shutdown -h 0 runterfahren und abwarten:
    Kein Erwachen!
    Dasselbe nochmal mit ctvdr1: normales Aufwachen!
    Das solange mit zufälliger Auswahl von ctvdr1 oder ctvdr3 wiederholen, bis
    der Effekt glaubhaft ist. Beim Hochfahren ggf. jeweils im BIOS checken, daß die
    eingetragene Startzeit noch vorhanden ist. Das heißt dann mindestens, daß
    beim Runterfahren - wie hier gewünscht - nicht die Zeit passend zum nächsten
    Timerevent eingetragen wurde.


    Erkenntnis: Es hat garnichts mit nvram-wakeup zu tun, sondern mit der Art
    und Weise, wie die System runtergefahren werden.


    Weitere Analyse tut not. Wer hat Ideen oder neue Erkenntnisse?

    Boogieman


    (P2B-S, PII450, 256MB, Samsung200GB, 2xTT1.5, 1xDVB-T)

    hi,


    ... und danke für die bestätigung!
    sowas in der art hab ich auch festgestellt.
    ... und es gibt hier im vorum noch andere die das problem haben!!! (z. b. hier


    tja, ich schätze mal, dass die entwickler eigentlich den bessten überblick haben sollten, was denn so geändert worden ist...


    ich bin jedenfalls mit meinem latein am ende - es läuft kein nvram.
    (hab auch mal acpi-wakeup ausprobiert - das selbe ergebnis. zeit wird gesetzt aber es wird nicht zur angegebenen zeit gestartet...)

    cu
    fossy
    -----------------------------------------------------------------
    VDR1: pentium m, aopen i855gmem-lfs / hauppauge nexus 2.2, technisat skystar2 / (im silverstone lascala lc11m-s) / debian lenny / e-tobi --> vdr 1.6.0 / kernel 2.6.28-etobi.3-686
    VDR2: D945GSEJT mit 2GB RAM + ... (budget) / debian lenny / e-tobi --> vdr 1.6.0 /
    -----------------------------------------------------------------
    meine klitzekleine homepage :arme hier

    Hallo erstmal!


    Schön, dass ich kein Einzelfall bin ;)
    Schade, dass es noch keine Lösung gibt.


    Boogieman
    Ich hab zwar eben in meinem eigenen Thread geschrieben, dass ich
    einen grundsätzlichen Fehler in nvram vermute, aber nach Deinen
    Ausführungen scheint dem ja nicht so.


    Kann man eigentlich nvram 0.97-x auch bei der "alten" ct Version nutzen.
    Weil dann könnte man Deinen Verdacht bestätigen, nämlich
    dann wenn es dort funktionieren würde.


    na ja...kommt Zeit, kommt Rad...äh. Rat.


    gruss
    josh

    VDR-Server: EPIA M1000,256MB,1x 16GB CF Card, Video VZ per NFS,TT-DVB-s 1.6, easyvdr 1.0, im ex-Medi@portal-Gehäuse,Crystalfontz LCD (128x64),nur via LAN.
    im WoZi: ZOTAC ION, 2 GB, 1x 40GB SSD, Windows XP, xbmc, Logitech Harmony 885

    Ich habe diesen Thread nicht gesehen, da er nicht im NVRAM-Bereich war. Danke an ULF fuer den Link.


    Dein board wird von nvram-wakeup richtig erkannt und auch die richtige Konfiguration genutzt.
    Da das standard-nvram-modul des Kernels nur 114 der 128 bytes des unteren NVRAM zur Verfuegung stellt,
    muss man entweder die --directisa Option benutzen oder den Kernel-Treiber fuer nvram patchen.
    Ich nehme an, dass letzteres bei einer der ct-VDR-versionen der Fall war.


    zu dem Reboot-Problem:

    Zitat

    von Boogieman
    System anschalten, im BIOS von Hand eine Startzeit eintragen, die z.B. 10
    Minuten in der Zukunft liegt, Sytem booten in ctvdr3. Nach dem Hochfahren
    auf einer Konsole einloggen und mit shutdown -h 0 runterfahren und abwarten:
    Kein Erwachen!


    perfekt beobachtet. Das ist das "Zweite Reboot-Problem", wie in der README.reboot beschrieben.

    Hi
    Update auf Sarge /vdr3 wird gemacht wenn die CD als Image zum Download da ist oder als c't Heftcd.
    Bloss nicht hetzen lassen Peter
    DANKE FÜR EURE TOLLLE ARBEIT.
    Gruss Ulf

    Samsung UE43RU7479U, Antec Fusion Black, Prime A320m-k, Ryzen3 3200G, 2* DVB-T2,
    Yavdr-ansible auf Ubuntu Server 22.04

    Ich habe mal einen Kernel mit gepatchtem nvram gebaut. Das Modul hängt an. Einfach das Original sichern (mv /lib/modules/2.4.27-ctvdr-1/kernel/drivers/char/nvram.o /root/) und das entpackte Anhängsel nach /lib/modules/2.4.27-ctvdr-1/kernel/drivers/char kopieren und anschließend depmod aufrufen. Das ist etwas ungewöhnlich, scheint aber zu klappen -- dennoch kann ich nicht ausschließen, dass der Modultausch Folgefehler hat. Danke an die Mutigen ;) für Rückmeldungen, ob es mit dem aktualisierten Modul klappt.


    Aktualisierter Kernel folgt.


    Peter

    Moin!


    Hab da Modul eingebaut. (Das System läuft noch ;) )


    /dev/nvram ist jetzt wieder 128 Zeichen lang und nvram-wakeup
    tuts wieder ohne --directisa


    Wie leider erwartet, ändert das an dem Wakeup Problem (Typ 2)
    überhaupt nichts.


    Ich könnte nun natürlich zur Tagesordnung übergehen und den kurzen reboot
    einbauen. Fände ich aber ganz schön unsportlich.


    Meine beiden Systeme (ct VDR 1.x und 3.04) werden beide mit
    "apm=power-off noapic acpi=off" gestartet.
    ctvdr1 wacht normal auf, ctvdr3 nicht.


    Ich hoffe, daß ich hier "Mitstreiter" (oder noch besser Kernelexperten als
    Vorreiter) finde bei der Suche (vermutlich) nach dem entscheidenden Unterschied
    zwischen den Kerneln
    2.4.24-ctvdr-2 (der ersten ct VDR Distribution) und
    2.4.27-ctvdr-1 (auf der die ct VDR 3.04 läuft)


    Kann doch eigentlich nur ne Kleinigkeit sein. Was kann ich an Anhaltspunkten
    liefern, das die Suche voranbringt? Remotezugriff auf meinen Rechner ist
    wegen "keine Flatrate" und "nur Modemzugang" nicht praktikabel.

    Boogieman


    (P2B-S, PII450, 256MB, Samsung200GB, 2xTT1.5, 1xDVB-T)

    Einmal editiert, zuletzt von Boogieman ()

    hi,


    ich kann die aussage von boogieman bestätigen!


    nvram funzt mit dem modul jetzt wie gewohnt (danke peter :) ), allerdings startet das system nicht zur genannten zeit :(

    cu
    fossy
    -----------------------------------------------------------------
    VDR1: pentium m, aopen i855gmem-lfs / hauppauge nexus 2.2, technisat skystar2 / (im silverstone lascala lc11m-s) / debian lenny / e-tobi --> vdr 1.6.0 / kernel 2.6.28-etobi.3-686
    VDR2: D945GSEJT mit 2GB RAM + ... (budget) / debian lenny / e-tobi --> vdr 1.6.0 /
    -----------------------------------------------------------------
    meine klitzekleine homepage :arme hier

    hi,


    apm=realmode-power-off funzt auch nicht :(
    (das system schaltet sich nicht ab!

    cu
    fossy
    -----------------------------------------------------------------
    VDR1: pentium m, aopen i855gmem-lfs / hauppauge nexus 2.2, technisat skystar2 / (im silverstone lascala lc11m-s) / debian lenny / e-tobi --> vdr 1.6.0 / kernel 2.6.28-etobi.3-686
    VDR2: D945GSEJT mit 2GB RAM + ... (budget) / debian lenny / e-tobi --> vdr 1.6.0 /
    -----------------------------------------------------------------
    meine klitzekleine homepage :arme hier

    Moin!


    fossy's Aussage kann ich bestätigen: Rechner fährt sauber runter, aber Netzteil bleibt an.


    Noch übler: Ich hab mal kurz eben die reboot Variante einbauen wollen, als Übergangslösung. Ergebnis: Reboot erfolgt, Runterfahren und poweroff klappt (apm=power-off), aufwachen tut er trotzdem nicht.


    Wäre zu erwarten, daß der "poweroff-kernel" hilft, oder richtet sich der nur an die acpi Variante (die bei mir wg. "zu altem BIOS" nicht funktioniert)?

    Boogieman


    (P2B-S, PII450, 256MB, Samsung200GB, 2xTT1.5, 1xDVB-T)

    Moin!


    Der vorgeschlagene Test ergibt keine Überraschungen:


    boot_ctvdrX halt reboot_ctvdrY wakeup?
    3 ja nein nein
    3 nein 1 ja
    3 nein 3 nein
    1 ja nein ja
    1 nein 1 ja
    1 nein 3 nein
    (wie macht man denn hier Tabellen?????????)


    Meine Schlussfolgerungen weiterhin:
    nvram-wakeup setzt die Wakeupzeit einwandfrei. Es gibt hier keine
    Unterschiede zwischen ct VDR 1.x und 3.04.
    Wird das System mit 3.04 zum poweroff gebracht erfolgt in keinem Fall ein
    wakeup. Ich vermute, daß es Unterschiede im Kernel oder einen Kernelmodul gibt,
    was dazu führt, daß "halt -p" unterschiedlich abgearbeitet wird.


    Die Suche geht weiter ...


    (Debugging Tips sind willkommen. Mein nächster Schritt ist wohl jetzt
    erstmal, aus der 3.04 Variante ein "Minimalst System" zu machen, das zum
    frühest möglichen Zeitpunkt im Bootvorgang ein poweroff auslöst. Erwartung wäre,
    daß auch so kein wakeup erfolgt.)

    Boogieman


    (P2B-S, PII450, 256MB, Samsung200GB, 2xTT1.5, 1xDVB-T)

    3 Mal editiert, zuletzt von Boogieman ()

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden