ACPI-wakeup: "ungültiges Argument"

FireFly · 25. Dezember 2008

Hallo,

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

Code

echo 1230228000 >/sys/class/rtc/rtc0/wakealarm
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

dwud7g · 25. Dezember 2008

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

FireFly · 25. Dezember 2008

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

Tyger · 25. Dezember 2008

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

FireFly · 25. Dezember 2008

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

Code

void rtc_time_to_tm(unsigned long time, struct rtc_time *tm)
{
        unsigned int days, month, year;
        days = time / 86400;
        ....
        days -= (year - 1970) * 365
                + LEAPS_THRU_END_OF(year - 1)
                - LEAPS_THRU_END_OF(1970 - 1);
        if (days < 0) {
                year -= 1;
                days += 365 + LEAP_YEAR(year);
        ....
        }

Alles anzeigen

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

FireFly · 25. Dezember 2008

Soooo, bei mir gehts wieder.

Ich habe jetzt auf openSuSE 11.0 die Kernelpakete von openSuSE 11.1 eingespielt (Kernel 2.6.25.16 -> 2.6.27.7)

dwud7g · 25. Dezember 2008

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

talpa · 30. Dezember 2008

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

ACPI-wakeup: "ungültiges Argument"

Jetzt mitmachen!

Teilen