ACPI-wakeup: "ungültiges Argument"

  • Hallo,


    seit ein paar Tagen bekomme ich beim Schreiben auf /sys/class/rtc/rtc0/wakealarm immer eine Fehlermeldung

    Code
    1. echo 1230228000 >/sys/class/rtc/rtc0/wakealarm
    2. echo: write error: Das Argument ist ungültig


    Selbstverständlich gibts dann kein Aufwachen per ACPI mehr :(


    HW scheint in Ordnung zu sein und seltsamerweise kann ich einige Zeiten doch schreiben, z.B. 1232228000 = "Sat Jan 17 22:33:20 2009". ein cat /sys/class/rtc/rtc0/wakealarm bringt dann aber 1200605600, was "Thu Jan 17 22:33:20 2008" entspricht.


    Ich nutze openSUSE 11.0 mit Kernel 2.6.25.16-0.1-default (64 Bit).
    Einen Leidensgenossen gibt es in linuxforen.de. Auch hier ist es Kernel 2.6.25, wenn auch 2.6.25-gentoo-r9.


    Woran könnte das liegen? Hat jemand schon mal sowas beobachtet? Ist das evtl. ein generelles Kernel-Problem? Was kann man dagegen machen?


    Schöne Bescherung
    FireFly

  • Ok, ist ja toll...


    Ich habe das Problem auch und zwar genau seit dem 21.12. Mein vdr schaltet sich normalerweise täglich ein, um Nachrichten aufzunehmen, irgendwann fahre ich ihn (oder er sich) dann wieder runter. Das Ganze läuft so seit Juli. Am 21. ging das plötzlich nicht, obwohl das System seit Wochen unverändert ist. Effekt war genau derselbe (write error auf /sys/class/rtc/rtc0/wakealarm). In syslog steht


    Dec 21 23:29:44 9of9 vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.acpiwakeup as shell script
    Dec 21 23:29:44 9of9 vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2008-12-22 18:55:00
    Dec 21 23:29:44 9of9 vdr-addon-acpiwakeup: Writing to /sys/class/rtc/rtc0/wakealarm
    Dec 21 23:29:44 9of9 vdr-addon-acpiwakeup: Writing to /sys/class/rtc/rtc0/wakealarm
    Dec 21 23:29:44 9of9 vdr-addon-acpiwakeup: No writeable /proc/acpi/alarm or /sys/class/rtc/rtc0/wakealarm found. ACPI needed!!!
    Dec 21 23:29:44 9of9 vdr-shutdown: Shutdown aborted by /usr/share/vdr/shutdown-hooks/S90.acpiwakeup with exitcode 1



    Kernel-Treiber sind geladen, alles sieht auf den ersten Blick ok aus:


    9of9:/var/log# lsmod | grep rtc
    rtc_cmos 10528 0
    rtc_core 17692 1 rtc_cmos
    rtc_lib 3072 1 rtc_core


    Mein System ist ein c't vdr 6.1, allerdings mit einem selbstgebauten Kernel (2.6.25.11). Nachdem ich mir keiner Schuld bewusst war ("... ich hab' nix gemacht...!"), habe ich auf irgendeine Art BIOS Problem getippt. CMOS Reset und eine neue BIOS Version haben aber nix geholfen.


    Mein Mainboard ist ein Gigabyte GA-MA78GM-S2H (rev.1.0), jetzt mir der neusten BIOS-Version F6D, davor hatte ich die Version F5.


    Momentan bin ich ratlos, mir ist nicht mal klar, ob es wirklich ein BIOS oder ein Kernel-Problem ist. Aber immerhin ist es ja schon mal interessant, dass das Symptom nicht nur bei mir auftritt.


    Tja... Und nun?
    gs

  • Zitat

    Original von dwud7g
    Momentan bin ich ratlos, mir ist nicht mal klar, ob es wirklich ein BIOS oder ein Kernel-Problem ist.


    Ich bin mir mittlerweile ziemlich sicher, dass es ein Kernel-Problem in rtc_time_to_tm() ist. Die o.a. Differenz sind genau 366 Tage, das deutet auf Probleme mit Bereichsgrenzen wie signed/unsigned etc hin.


    Im Changelog von Kernel 2.6.26 findet sich folgendes:

    • Date: Fri Jul 4 09:59:26 2008 -0700
      rtc: rtc_read_alarm() handles wraparound
    • Date: Mon May 12 14:02:24 2008 -0700
      rtc: rtc_time_to_tm: use unsigned arithmetic

    Und im Changelog von Kernel 2.6.27:

    • Date: Tue Sep 2 14:36:05 2008 -0700
      rtc_time_to_tm: fix signed/unsigned arithmetic

    Und im Changelog von Kernel 2.6.28:

    • Date: Thu Nov 6 12:53:18 2008 -0800
      rtc: fix handling of missing tm_year data when reading alarms


    Sieht so aus, als sollte es mit 2.6.27 funktionieren, aber das müsste man ausprobieren.


    Ich werde erst mal als Quick'n'dirty-Lösung auf nvram-wakeup umstellen, damit ich überhaupt was habe...


    FireFly

  • Yay, /me too. Aus heiterem Himmel hat mein VDR aufgehört, sich automatisch runterzufahren - mit den gleichen Symptomen wie bei euch. Inzwischen hab ich den Kernel auf 2.6.18 gedowngradet, womit die drängendsten Probleme gelöst wären. Vor einem Update auf >= 2.6.26 muss ich warnen, da es mit 2.6.26 gleich das nächste ACPIWakeup Problem gibt - der Rechner wacht gar nicht mehr auf. Zu dem Thema gibt es hier auch den ein oder anderen Thread und auch Bugeinträge bei Debian und kernel.org. Lösung bzw. Workaround ist in dem Fall, den Bootparameter "hpet=disable" mitzugeben, aber ich glaube, das funktioniert auch erst ab einer bestimmten Kernelversion (2.6.28-rcX oder so). Meine Debian-Installation hat momentan nur 2.6.18 und 2.6.26 im Angebot, von daher fahr ich mit 2.6.18 erstmal sicher.


    Cya, Ed

  • Ist ja auch kein Wunder, wenn man sich den Code in drivers/rtc/rtc-lib.c aus Kernel 2.6.25 ansieht:


    days kann als unsigned int nie kleiner Null werden ...

  • Ja, bei mir auch!


    Da ich mir den Aufwand (und das Risiko) sparen wollte, deswegen auf einen neuen Kernel umzusteigen, habe ich den "pragmatischen" Weg gewählt: Unter http://linux.sourcearchive.com…10/rtc-lib_8c-source.html ist zu sehen, wie das entsprechende Code-Stück in 2.6.27 aussieht (days als int, statt als unsigned int). Die zwei geänderten Zeilen sieht man besser unter http://lkml.org/lkml/2008/9/3/255. Mit dieser Änderung habe ich meinen 2.6.25er Kernel neu übersetzt und das Ergebnis sieht soweit gut aus...

  • Heissen Dank für den Tipp, wird gleich mal mit meinem 2.6.26er Kernel getestet.


    so long,


    talpa.


    Zitat

    Original von dwud7g
    Da ich mir den Aufwand (und das Risiko) sparen wollte, deswegen auf einen neuen Kernel umzusteigen, habe ich den "pragmatischen" Weg gewählt: Unter http://linux.sourcearchive.com…10/rtc-lib_8c-source.html ist zu sehen, wie das entsprechende Code-Stück in 2.6.27 aussieht (days als int, statt als unsigned int). Die zwei geänderten Zeilen sieht man besser unter http://lkml.org/lkml/2008/9/3/255. Mit dieser Änderung habe ich meinen 2.6.25er Kernel neu übersetzt und das Ergebnis sieht soweit gut aus...