Wakeup nach 5 Minuten - acpiwakeup problem mit /sys/class/rtc/rtc0/wakealarm ?

  • Hi,


    also da kommt (leider) das raus, was man erwarten würde:


    Written to /proc/acpi/alarm : 2008-06-10 19:30:00


    Das war die korrekte Aufwachzeit in UTC, aber er startet nicht.
    Das gleiche Eregbnis im Log liefert auch 0.0.8, nur dass er halt da aufwacht.


    Aber egal, wenn das nur mich betrifft, dann nehm ich halt vorerst die 0.0.8.


    Danke!


    Grüße
    Günther

    c't VDR v6, vdr 1.6.0, Kernel 2.6.24, P3 Tualatin Celeron 1400 @1GHz, Asus TUSL-2c, ACPI on, APIC on, FS 1.3 DVB-S FF, Skystar 2c

  • Was ich total verschwitzt habe, ist dass die Aufwachzeit beim Runterfahern nochmal in einem Init-Skript gesetzt wird. Das Init-Skript liest die Zeit aus einer Datei und und in der Stand seit der letzten Änderung fälschlicher Weise der Timstamp statt das lesbaren Formats. Darfst also mir die Schuld geben!


    Eine neu Version ist online.


    Tobias

  • Ja, das war's! Funktioniert jetzt.


    Danke schön!


    Grüße
    Günther

    c't VDR v6, vdr 1.6.0, Kernel 2.6.24, P3 Tualatin Celeron 1400 @1GHz, Asus TUSL-2c, ACPI on, APIC on, FS 1.3 DVB-S FF, Skystar 2c

  • Hallo Tobi,


    danke für deine Mühe das Script immer mehr anzupassen.
    Du hast es nun soweit verfeinert das es vor der Vollendung steht ;)


    Mehrere Versionen habe ich ausprobiert und das Script umgeschrieben das es geht und nun hast du alle Dinge komplett eingearbeitet.


    BESTEN DANK


    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

    Edited 8 times, last by hightower ().

  • Sorry, dies ist ein Fehler; der Editor hat nicht richtig funktioniert!!

    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).

    Edited once, last by GBruno ().


  • Hallo zusammen,


    ich habe eine mögliche Erklärung für das fehlerhafte Verhalten beim Bestimmen der Zeitzone UTC oder localtime:
    Das Script S90.acpiwakeup in /usr/share/vdr/shutdownhooks hat etwa in der Zeile 33 einen Fehler:
    if [$UTC = "yes" ] then ....
    Hier sind die Spaces vor und nach dem "=" zuviel und verhindern das korrekte Auslesen der /etc/default/rcS. Dies kann man erkennen, wenn man den Wert der Variablen $TIMEZONE sich z. B. mit echo ... anzeigen lässt: bleibt immer auf "localtime", ganz gleich, was in der rcS steht.


    Bei mir hat das Entfernen der Spaces geholfen, aber die übrigen Probleme leider nicht beseitigt (kommt später).


    Übrigens: dieser Fehler war in der Version 6.0 nicht mehr vorhanden, jetzt ist er aber wieder da!


    Grüße


    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).

    Edited 2 times, last by GBruno ().

  • Quote

    Originally posted by Tobi
    Was ich total verschwitzt habe, ist dass die Aufwachzeit beim Runterfahern nochmal in einem Init-Skript gesetzt wird. Das Init-Skript liest die Zeit aus einer Datei und und in der Stand seit der letzten Änderung fälschlicher Weise der Timstamp statt das lesbaren Formats. Darfst also mir die Schuld geben!


    Eine neu Version ist online.


    Tobias


    Hallo Tobias und VDR-Gemeinde,


    erstmal auch von mir große Anerkennung für Deine Arbeit. Ich habe aber noch einige Fragen:


    1. Oben schreibst Du von einem init-Script, das die Aufwachzeit beim Runterfahren noch einmal setzt. Ich habe in das Script S90.acpiwakeup verschiedene "echo ... >> logfile.log"- Befehle eingebaut; demnach wird die Aufwachzeit in /proc/acpi/alarm korrekt geschrieben, das heißt mit Jahr, Monat, Tag, Stunde und Minute, z. B. "2008-08-03 12:00". Nach dem Neustart kommt mit cat /proc/acpi/alarm nur noch "2008-00-00 12:00", d. h. Monat und Tag fehlen. Kann das an dem genannten init-Script liegen? Welches ist das und wo finde ich es?


    2. Im Script S90.acpiwakeup wird als WAKEUP_FILE /var/cache/vdr/acpiwakeup.time angegeben, Diese Datei wird bei mir aber nicht angelegt, bzw. ich habe es nur einmal mit einer Testversion hingekriegt. Muss die Datei von vornherein immer da sein?


    3. Obwohl ich jetzt eine Kernelversion >2.6.22 benutze (z. B. 2.6.23 und 2.6.25) bekomme ich das im Wiki erwähnte Device /sys/class/rtc/rtc0 nicht, natürlich auch nicht die die Datei "wakealarm". Stattdessen habe ich wie früher auch /proc/acpi/alarm/..., ganz gleich, an welchem PC ich welchen Kernel starte. Ich war doch ziemlich enttäuscht, weil ich gehofft hatte, dass das Problem mit den fehlenden Daten für Monat und Tag dann gelöst wäre.


    Kannst Du / Könnt Ihr mir helfen? Danke im Voraus.



    Grüße


    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,


    zu 1) das liegt nicht an dem script, sondern dein Board kann nicht Tag und Monat speichern. Statt "echo ... >> logfile.log", probier mal ein "cat /proc/acpi/... >>logfile.log" im shutdown hook, dann dürfte es sofort schon nicht korrekt drinstehen, so war jedenfalls das Verhalten bei mir.


    zu 2) Die Datei wird vom shutdown-hook angelegt und beim Starten des Rechners wieder gelöscht. Du musst also schnell sein, um sie sehen zu können, oder aber das Abschalten des Rechners kurz verhindern.


    zu 3) Schau mal hier.
    Es gibt 2 Module für die rtc in den neuen Kernels. Zuerst wird das alte (rtc) geladen, wenn dies geladen wurde, funktioniert das neue (rtc_cmos) nicht. Nur das neuere stellt dir rtc0 bereit. Wenn du die Kernel selbst bäckst, am besten das alte Modul in der Konfiguration rausschmeissen und das neue aktivieren oder einen Eintrag 'blacklist rtc' in die /etc/modprobe.d/blacklist eintragen, damit der alte nicht geladen wird. Wenn denn das neue Modul existiert sollte es auch geladen werden.

  • [Hallo Ecki,
    danke für Deine schnelle Antwort. Ich schreibe meinen Text unter Deinen:


    Quote

    Originally posted by ecki
    Hallo GBruno,


    zu 1) das liegt nicht an dem script, sondern dein Board kann nicht Tag und Monat speichern. Statt "echo ... >> logfile.log", probier mal ein "cat /proc/acpi/... >>logfile.log" im shutdown hook, dann dürfte es sofort schon nicht korrekt drinstehen, so war jedenfalls das Verhalten bei mir.


    Das habe ich gemacht. Der Wert ist beim Auslesen korrekt.


    Quote

    zu 2) Die Datei wird vom shutdown-hook angelegt und beim Starten des Rechners wieder gelöscht. Du musst also schnell sein, um sie sehen zu können, oder aber das Abschalten des Rechners kurz verhindern.


    Aha, so ist das. Wofür wird die Datei denn gebraucht? Übrigens lasse ich mir auch das mit meinem "Log-File" anzeigen, der Wert ist auch korrekt.


    Quote

    zu 3) Schau mal hier.
    Es gibt 2 Module für die rtc in den neuen Kernels. Zuerst wird das alte (rtc) geladen, wenn dies geladen wurde, funktioniert das neue (rtc_cmos) nicht. Nur das neuere stellt dir rtc0 bereit. Wenn du die Kernel selbst bäckst, am besten das alte Modul in der Konfiguration rausschmeissen und das neue aktivieren oder einen Eintrag 'blacklist rtc' in die /etc/modprobe.d/blacklist eintragen, damit der alte nicht geladen wird. Wenn denn das neue Modul existiert sollte es auch geladen werden.


    Das muss ich mir erstmal genauer ansehen. Auf alle Fälle habe ich die rtc-Module core und cmos nicht. Das würde mich auch nicht weiter stören, wenn die alte Mimik richtig funktionieren würde.


    Ich kopiere hier mal einen Auszug aus meinem "Echo-Log" hinein, damit Du Dir ein Bild machen kannst. Ich habe alle Variablen geloggt, die mir unklar waren:


    ************* date
    Wert von /proc/acpi/alarm beim Start # beim Hochfahren Echo im Init-Script
    2008-00-00 17:24:13
    -------------------------------
    $TIME_FUNCTION$= gmtime # wegen Fehler im Script S90.acpi...
    $1= #### Leer, weil keine Aufnahme programmiert
    TIME_TO_SET= 2008-08-03 18:19:32 ,$1=
    TIME_TO_SET2= 2008-08-03 18:19:32 ,$?= 0
    Wert von /proc/acpi/alarm ##cat /proc/acpi/alarm beim Herunterfahren (des VDR?)
    2008-08-03 18:19:32
    WakeUpFile
    2008-08-03 18:19:32 ## ist cat /var/cache/vdr/acpiwakeup.timer
    -------------------------------
    $TIME_FUNCTION$= gmtime
    $1=1217847600 ## mit gesetztem Timer
    TIME_TO_SET= 2008-08-04 10:55:00 ,$1= 1217847300
    TIME_TO_SET2= 2008-08-04 10:55:00 ,$?= 0
    Wert von /proc/acpi/alarm
    2008-08-04 10:55:00
    WakeUpFile
    2008-08-04 10:55:00
    ************* date
    Wert von /proc/acpi/alarm beim Start
    2008-00-00 10:55:00
    ************* date
    Wert von /proc/acpi/alarm beim Start
    2008-00-00 10:55:00


    Ich hoffe, dass dies einiges klarer macht. Insbesondere kann mein Board das richtige Datum mit dem S90.acpiwakeup-Script speichern, es ist nur beim Hochfahren falsch. Deshal vermute ich, dass noch ein anderes, von Tobi erwähntes Script mitmischt.


    Grüße


    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 Ecki,


    ich habe gerade mal im VDR-Wiki (ACPI Wakeup) nachgelesen. Dort steht, dass man den "Erfolg" des Timers mit cat /proc/driver/rtc kontrollieren kann.


    Das habe ich getan: Dort wird unter ALARM nur hh:mm:ss gespeichert, aber kein Datum! (Bzw. nur das aktuelle). Wenn man dies nicht ändern kann, werden alle Versuche, Tage im Voraus zu programmieren, wohl scheitern. Das gilt für die alte als auch für die neue Methode.


    Oder weißt Du einen Rat?


    Grüße


    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).

    Edited once, last by GBruno ().

  • Hallo GBruno,


    zu 1) Es ist schon knapp ein Jahr her, dass ich mich mit dem ACPI-alarm beschüftigt hatte. Kann durchaus sein, dass es direkt nach dem reinschreiben noch korrekt stand. Ich denke aber, dass bei meinem Board sofort das Datum verschwunden ist.


    zu 2) Bei vielen Boards gibt es das Problem, dass wenn man die BIOS-Zeit mit der Systemzeit beim Herunterfahren per hwclock aktualisiert (wie es sinnvoll ist und auch standardmäßig von Debian gemacht wird), die gesetzte Aufwachzeit ignoriert wird. Die Skripte vom VDR können die aber normalerweise nur vor dem hwclock setzen. Diese temporäre Datei ist eine elegante Möglichkeit, dass der Aufwachzeitpunkt nach dem hwclock in einem shutdown-skript stattfindet und somit auf allen Boards funktioniert.


    zu 3) Hat eigentlich das Aufwachen mit deinem Board per ACPI für mehr als 24h im voraus schon mal geklappt? Die Unterstützung ist je nach board (und bios) sehr unterschiedlich.
    Bei mir hat die wakealarm-Methode Besserung gebracht. Ich weiss nicht, ob bei den aktuellen Live-CD's wie Knoppix das entsprechende Modul dabei ist. Du kannst ja testweise mal booten und ein 'dmesg |grep rtc' eingeben. Bei mir kommt folgende Ausgabe auf dem aktuellen System:


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

  • Hallo Ecki,


    ich schreibe wieder unter Deinen Text, geht schneller.


    Quote

    Originally posted by ecki
    Hallo GBruno,


    zu 1) ....
    zu 2) Bei vielen Boards gibt es das Problem, dass wenn man die BIOS-Zeit mit der Systemzeit beim Herunterfahren per hwclock aktualisiert (wie es sinnvoll ist und auch standardmäßig von Debian gemacht wird), die gesetzte Aufwachzeit ignoriert wird. Die Skripte vom VDR können die aber normalerweise nur vor dem hwclock setzen. Diese temporäre Datei ist eine elegante Möglichkeit, dass der Aufwachzeitpunkt nach dem hwclock in einem shutdown-skript stattfindet und somit auf allen Boards funktioniert.


    Bei mir habe ich in dem Script rcS den Hardwarezugriff auf die System-Clock deaktiviert, weil es so empfohlen wurde.

    Quote


    zu 3) Hat eigentlich das Aufwachen mit deinem Board per ACPI für mehr als 24h im voraus schon mal geklappt? Die Unterstützung ist je nach board (und bios) sehr unterschiedlich.


    Soweit ich weiß, nicht. Das Wiki und auch das Portal schweigen sich aber darüber aus :(

    Quote


    Bei mir hat die wakealarm-Methode Besserung gebracht. Ich weiss nicht, ob bei den aktuellen Live-CD's wie Knoppix das entsprechende Modul dabei ist. Du kannst ja testweise mal booten und ein 'dmesg |grep rtc' eingeben. Bei mir kommt folgende Ausgabe auf dem aktuellen System:


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


    Wie gesagt, diese Module habe ich bei meinem Kernel 2.6.23 und 2.6.25_amd64 nicht. Es würde wahrscheinlich (lt. Wiki) auch nichts ändern, weil das Problem ja in "/proc/driver/rtc" bzw. im BIOS zu liegen scheint. Bei mir jedenfalls kann man nach Aufrufen des BIOS beim rtc-Alarm-Screen auch nur eine Uhrzeit, aber kein Datum eingeben. Wenn rtc0 bis zu einem Jahr speichern könnte, wäre das natürlich toll. Eine aktuelle Knoppix-CD muss ich mir erst besorgen - wäre das eine dauerhafte Lösung?


    Wie kommt man hier weiter??? Ich bin ratlos. Vielleicht weiß sonst ein Profi aus der VDR-Gemeinde Rat.



    Grüße


    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).

    Edited once, last by GBruno ().

  • Hi,


    ich hatte ähnliche Probleme. Lag an der Konfiguration meines
    vanilla Kernels. Mit dem Distri Kerneln gings. Das brachte mich auf
    die Spur.


    Es fehlten Teile aus dem ACPI Support.
    Es sollte beim dmesg auf jeden Fall
    ACPI: (supports S0 S1 S3 S4 S5)
    ACPI: RTC can wake from S4
    erscheinen.


    cat /sys/power/state sollte
    standby mem disk
    ergeben.


    CPU Hotplug Support muss auch an sein.


    Gruss,
    Thomas

  • Hallo GBruno,


    ich backe mir meine Kernel immer selbst, weiss nicht wie die Konfig des Distri-Kernels ist. Vielleicht schicke ich dir einfach mal meinen Kernel als .deb per Mail. Dann kannst du ja mal testen, ob das Modul bei dir weiterhilft.

  • Hallo Ecki,


    das wäre ganz nett, wenn Du mir Deinen Kernel per Mail schicken würdest, ich komme einfach nicht weiter. Deb-Paket wäre prima. Sind da auch Wireless-Module (ath_pci etc.) dabei?


    Meine Adresse: g.bruno@t-online.de


    Vielen Dank und Grüße



    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).

    Edited 2 times, last by GBruno ().


  • Hallo Thomas,


    ich habe mir gerade mal die Installations-CD vom c't-VDR 6.2 angesehen, da sind mehrere Kernel drauf. Welchen meinst Du? In den Verzeichnissen mit den Modulen unter .../main habe ich nichts gefunden, was nach rtc_cmos o. ä. aussah. Bin aber kein Profi.


    Grüße


    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,


    völlig andere Baustelle. Ich habe auf einem Fedora 9 System
    installiert. Deshalb meinte ich auch die dort vorhandenen
    Distri Kernel. Mit dem ct-vdr gar nicht zu vergleichen. Darin
    haben sie ja alles an, was es gibt.


    Nur eben ich nicht, mit meinem vanilla kernel. Das war dann
    auch der Grund und ebenfalls der Unterschied.


    Gruss, Thomas

  • Quote

    Original von ecki
    Hallo GBruno,


    ich backe mir meine Kernel immer selbst, weiss nicht wie die Konfig des Distri-Kernels ist. Vielleicht schicke ich dir einfach mal meinen Kernel als .deb per Mail. Dann kannst du ja mal testen, ob das Modul bei dir weiterhilft.


    Hallo Ecki,


    vielen Dank für Deinen Kernel. Ich habe ihn auf meinem PC mit einem Athlon 64X2 und einem einfachen Athlon 64 getestet. Nur auf dem X2 ist er gelaufen; auf dem einfachen Athlon 64 hängte er sich mit der Meldung "runaway loop modprobe binfmt-464c" auf - ein solches Modul gibt es aber unter /lib/modules/... nicht; deshalb denke ich, dass es etwas mit dem 2-Kern-Prozessor zu tun hat. Das Modul "rtc" wurde immer noch geladen und musste mit rmmod von Hand entfernt werden, dann konnte man rtc_cmos laden.


    Jetzt habe ichmich fast eine Woche mit dem Kompilieren eines neuen Kernels beschäftigt, nach der Anleitung von WilderIgel ([Anleitung] Debian 4.0 (Etch) Kernelupdate von kernel.org + Module für lirc + cdfs (+ hg-dvb)), die sehr brauchbar ist. Ich habe als Quelle von www.kernel.org die letzte Version 2.6.25.15 genommen, und heute funktioniert alles, wie es soll.


    Wichtig ist, dass man in der Datei .config den Eintrag CONFIG_RTC (unter Non 8250 serial port support) inaktiviert und im Abschnitt "rtc-Interfaces" die Einträge mit CONFIG_INTERF_* aktiviert. Weiteres findet man in der Hilfe bei make menuconfig.


    Leider wird rtc_cmos nicht automatisch geladen; deshalb habe ich es in eine Datei unter /etc/rcboot eingetragen (nicht am Ende, da ging es nicht!). Heute jedenfalls ist er richtig zur eingestellten Zeit aufgewacht; der Test über mehr als 24 Std. läuft noch.


    Das Schwierigste ist ja die Einstellung der über 3.600 Parameter in der .config; deshalb hänge ich mein Exemplar mal an (vor dem Testen entpacken (sonst konnte ich nicht hochladen) und in .config umbenennen).


    Übrigens konnte ich auch zum ersten Mal den Madwifi-Treiber für Atheros-Wireless-Chipsätze für amd_64 kompilieren, geht nur mit der Version madwifi-0.9.4.tar.gz (bei sourceforge.net)


    Probleme habe ich noch mit dem Framebuffer-Device (nvidiafb und fbtv) und mit dem Kernel-Parameter für die Bildschirm-Auflösung (vga=0x314 wird nicht akzeptiert).


    Erstmal vielen Dank für Deine Hilfe


    GBruno

    Files

    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).

    Edited 3 times, last by GBruno ().

  • Hallo zusammen,


    hier erste Erfahrungen mit dem oben beschriebenen Kernel-Neubau: das device /sys/class/rtc/rtc0 erscheint jetzt richtig, auch "spontan" nach dem Booten. Auch den ">24 Std. Test" hat das System bestanden und ist nach ca. 30 Std. korrekt zum Aufnehmen hochgefahren. /proc/sys/driver/rtc zeigt beim "Alarm-Datum" zwar nur Sternchen; das scheint aber nichts auszumachen.
    Allerdings läuft der VDR unter der Kernel-version 2.6.25.15 ziemlich instabil - mal geht's, mal nicht. Das liegt - soweit ich es herausfinden konnte - am Handling der "events", hier für die on-board-irc-Schnittstelle (Fernbedienung) meiner Sat-Karte von Hauppauge. Manchmal findet das System das event nicht und der VDR startet dauernd neu. Ich werde wohl zur letzten stabilen Version 2.6.25.2 zurückkehren (am Wochenende).
    Der madwifi-Treiber für meine WLan-Karte (Atheros-Chipsatz) läuft übrigens einwandfrei.
    Grüße
    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).

    Edited 2 times, last by GBruno ().

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!