Posts by GBruno

    Wie erwähnt, habe ich die Li-Batterie durch eine brandneue ersetzt. Keine Änderung.

    Im Ampere-Messmodus testen, möchte ich nicht, weil dann die Batterie sehr schnell leer ist. Widerstand ist dann ~0 Ohm = Kurzschluss!

    Die Prüfung der Elkos geht über meine Fähigkeiten.

    Wenn da etwas kaputt sein sollte, dürfte rtcwake -m disk ... doch auch nicht gehen, oder?

    Hallo,

    ich habe neue Erkenntnisse. Nachdem

    Code
    rtcwake -m no --date +10min
    poweroff

    nicht funktionierte, habe ich


    Code
    rtcwake -m disk --date +10min

    versucht. Das geht. Der PC wacht auf wie versprochen. Warum ist das so? Jetzt habe ich doch den Verdacht auf ein Hardware-Problem. ("battery_status: dead" obwohl sie gut ist) Oder?

    Wie komme ich da weiter?

    Meine Scripts (Codes habe ich gerade nicht zur Hand) habe ich entsprechend umgeschrieben, funktioniert, wacht richtig auf und nimmt mit Timer auf. Aber jetzt lässt sich der PC nicht mehr über VDR abschalten. Da muss ich noch etwas tun.

    Danke weiterhin für Eure Hilfe.

    Hallo,


    inzwischen experimentiere ich mit dem Kernel 5.13.0-40, aber ohne Erfolg.

    In lspci wird die Karte als SAA7160 von Philips-Semiconductors angezeigt. Deswegen meinte ich, die Treiber saa716x würden passen. Tun sie ja auch, sie werden mit modprobe geladen. Nur an das Modul "tt_s2_4100_drv" komme ich nicht dran, ohne das es nicht geht. Versuche zu kompilieren mit dem Kernel 5.13.0-40 schlugen fehl. Soll laut Hersteller Technotrend auch nur bis Kernel 4.4.x funktionieren. Ich habe wie gesagt noch einen alten Kernel 3.13.11 installiert, damit geht es gut.

    Hallo,


    die Module beim Booten zu laden ist ganz einfach: in die Datei /etc/modules eintragen (ohne *.ko, als root), und sie sind da.


    Aber es funktioniert immer noch nicht: es fehlt ein Modul "tt_s2_4100_drv" oder etwas Analoges, das unter meinem alten Kernel 3.13.11 (modifiziert) geladen wird. Gibt es das auch für den Kernel 5.13.0-40 auch?


    MfG GBruno

    Hallo,

    ich habe den Fehler im Script saa716x-1.0.0(1) gefunden: die Datei make.sh ist nicht als ausführbar gekennzeichnet. Anschließend lief es so lalal.


    Auf meinem VDR-Rechner habe ich das originale Script saa716x-1.0.0 ausprobiert. Es lief, aber die Module saa716x_budget und saa716xhybrid sind nachher nicht auffindbar, obwohl sie in make.log aufgeführt sind. Das Script löscht zuviel. Dann habe ich alle Zeilen mit "rm ..." deaktiviert und es ging.

    make.log hänge ich an, falls es von Interesse ist.


    Nur werden jetzt die Module nicht automatisch beim Hochfahren geladen. modprobe saa716x... geht. Wie bekomme ich das System dazu, die Module gleich zu laden?

    Hallo,


    ich habe das Script in dkms-saa716x.zip und dkms-saa716x (2).zip)ausprobiert. Bei dkms build -m saa716x -v 1.0.0 bekomme ich diese Fehlermeldungen:


    Kernel preparation unnecessary for this kernel. Skipping...

    Building module: cleaning build area...(bad exit status: 126) './make.sh' --batch --kernel 5.15.0-67-generic --dest modules...(bad exit status: 126) ERROR


    (dkms apport): binary package for saa716x: 1.0.0 not found Error!


    Bad return status for module build on kernel: 5.15.0-67-generic (x86_64)


    Consult /var/lib/dkms/saa716x/1.0.0/build/make.log for more information.


    Da steht:


    DKMS make.log for saa716x-1.0.0 for kernel 5.15.0-67-generic (x86_64)


    Sa 11. Mär 18:28:18 CET 2023


    /usr/sbin/dkms: Zeile 80: ./make.sh: Keine Berechtigung


    obwohl ich das Script als root ausgeführt habe.


    Was ist da los? Kann jemand helfen?Grüße GBruno

    Hallo,

    ich habe ein paar Nachmittage versucht, das obige Skript auszuführen. Es geht gar nicht. Die Pfade stimmen nicht. Nachdem ich sie manuell angepasst und dann auch den patch anwenden konnte, gelangte ich bis zur make-Anweisung. Aber make findet Dateien nicht, die eindeutig vorhanden sind (gesucht mit locate). Was mache ich falsch? Ich habe das Script schließlich im / (root)-Verzeichnis als user root ausgeführt - half aber nichts. Unter welchem Ubuntu wurde das Script getestet? Es gibt da von Version zu Version doch erhebliche Unterschiede. Z. B. läuft k3b nicht unter Ubntu 20.04.x aber unter Mate 20.04.x

    Meine Installation: Xubuntu 20.04.5, Kernel 5.13.0-40-generic. Von den headers habe ich 2 Versionen unter /usr/src: einmal linux-headers-5.13.0(-40)-generic und linux-hwe-headers-5.13.0. Welcher ist der Richtige? Oder könnte jemand für mich die Module kompilieren (mit der genannten Konstellation) und mir irgendwie zukommen lassen? Danke.

    Quote

    na ja, ohne Strom kann der Rechner sich ja auch nicht einschalten

    Natürlich habe ich den Strom ca. 3 Std. vor dem Timer wieder eingeschaltet.


    Quote

    Was nicht funktionieren wird ist, dass das Board die Aufwachzeit bei Stromausfall behält. Das habe ich noch bei keinem Board erlebt - trotz voller 3V-Lithium-Batterie


    Das ist ein guter Hinweis, wusste ich nicht. Ich dachte, das CMOS-Ram behält alles. Die übrigen Einstellungen sind ja noch da.

    Hallo jrie,

    Code
    cat /proc/driver/rtc
    alarm_IRQ    : yes

    Das ist in Ordnung.

    Aber ich bin auf der Suche nach IRQ's auf ACPI gestoßen. Da gibt es einen Kernel-Parameter "acpi=force". Den habe ich in die

    Code
    /etc/default/grub

    eingetragen. Danach hat der PC erstmal einen Fehlstart hingelegt, nach reboot hat es wirklich funktioniert! :) Mit localtime und VDR-Timer. Zumindest einmal, ich muss es noch weiter beobachten. Die Zeiteinstellung lese ich jetzt aus der /etc/adjustime aus. Geht prima.


    Wie das passieren konnte, ist mir unklar, vielleicht bei einem der Updates von Ubuntu. Ich habe das über 10 Jahre nicht gebraucht. Mal sehen.

    Hallo,


    wieder Probleme mit acpi-wakeup:

    Dein Script (gekürzt) funktioniert bei mir nicht:

    Bash
    #!/bin/bash
    hwclock --systohc --utc
    DEV=/sys/class/rtc/rtc0/wakealarm
    
    nextboot=$(($1 - 300 ))  # Start 5 minutes earlier
    echo 0 > $DEV
    echo $nextboot > $DEV"
    #svdrpsend plug softhdcuvid deta
    #svdrpsend plug softhddevice deta
    poweroff


    Das manuelle Schreiben in /sys/class/rtc/rtc0/wakealarm funktioniert problemlos, auch die Anzeige von cat /proc/driver/rtc ist korrekt. Nach poweroff fährt das Biest aber nicht hoch. Ich habe alles probiert, CMOS zurück gesetzt, Batterie gemessen, alle Karten ausgebaut. Nichts hilft. Jetzt denke ich, es könnte am alarm_irq liegen, dass der irgendwie nicht richtig konfiguriert ist, also die IRQ's, die dem CMOS zugeordnet sind. Komme ich da weiter?


    Allerdings teste ich meist im Recovery-Modus, weil das ganze Hochfahren des VDR zu lange dauert. Aber auch dann geht nichts. Im Shutdown-Protokoll steht immer batt_status: dead, obwohl das nicht stimmt.

    Hi,

    Habe ich gemacht, ändert nichts. Das Problem ist wie gesagt, der Befehl "eval" in der shutown-Routine in /us/lib/vdr. Der Befehl macht aus der/den Eingaben und Ausgaben eines evtl. Befehls einen String, den er dann wieder als Befehl interpretiert. Ist die Ausgabe irgendein Text, kommt die Fehlermeldung xxx . not found.


    der Befehl "eval" ist als schwierig bekannt. Bisher habe ich keine Möglichkeit gefunden, die Pseudo-Befehle zu kaschieren.

    Man kann es mal testen mit

    Code
    eval echo 'Beim_Abschalten:_' & "$(cat /proc/driver/rtc | grep alrm)"


    MfG GBruno

    Hallo,

    ich habe noch ein anderes Problem: ich möchte gern, dass der Alarm beim Herunterfahren des VDR als Message angezeigt wird. Dachte, ich ändere einfach die S90.custom in shutdown-hooks.


    Als Ausgabe bekomme ich einen Fehler "no: command not found".


    Das liegt daran, dass

    Code
    cat /proc/driver/rtc

    im Script /usr/lib/vdr/shutdown.sh mit dem Befehl "eval" ausfgeführt wird, der alles, alles als bash-Befehl interpretiert.

    Code
    root@Tower-ssd:/etc/vdr/shutdown-hooks# echo 'Beim_Abschalten:_' & "$(cat /proc/driver/rtc | grep alrm)"
    [1] 6083
    Beim_Abschalten:_
    alrm_time    : 16:40:00
    alrm_date    : 2022-12-19
    alrm_pending    : no: Befehl nicht gefunden.

    Das führt bei der letzten Ausgabe von

    Code
    cat /proc/driver/rtc | grep alrm

    zu dem o. g. Fehler, exit code 127. Ich habe viel probiert, aber keine Lösung.

    Ist zwar nicht so wichtig, es interessiert mich aber.

    Danke MfG GBruno

    Quote

    Das kann mit cat /proc/driver/rtc getestet werden, was durch manuellen Neustart ins andere System sich ändert.

    Die Alarm-Time bleibt gleich, das Datum wird um einen Tag hoch gesetzt.


    Ich habe ein kleines Script "Timer_setzen" für mein Ubuntu 20.04.5 geschrieben, das zu funktionieren scheint

    Bash
    #!/bin/bash
    echo "############################################################"
    cat /ssdp2/var/cache/vdr/acpiwakeup.time > /sys/class/rtc/rtc0/wakealarm
    
    logger -t vdrtimer $(cat /ssdp2/var/cache/vdr/acpiwakeup.time)
    
    echo "TIMER wird gesetzt!!"
    echo "############################################################"
    sleep 5

    Dazu muss es in /etc/init.d gestellt und ausführbar gemacht werden und nach /etc/rc6.d verlinkt werden mit dem Praefix "K99" siehe



    PS (23.12.22): So einfach ist es nicht. Das Script wird beim Herunterfahren nicht ausgeführt, nur von Hand. Init-Scripte sind kompliziert :(


    https://ccm.net/computing/linu…p-and-shutdown-on-ubuntu/


    /ssdp2 ist der Einhängepunkt der SSD mit dem VDR 2.6.x

    Einige Zeilen sind nur zur Kontrolle der Funktion, können wahrscheinlich weg.