You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Thursday, December 25th 2008, 9:22am

ACPI-wakeup: "ungültiges Argument"

Hallo,

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

Source code

1
2
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

2

Thursday, December 25th 2008, 11:32am

RE: ACPI-wakeup: "ungültiges Argument"

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

3

Thursday, December 25th 2008, 1:47pm

RE: ACPI-wakeup: "ungültiges Argument"

Quoted

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

Trainee

Posts: 107

Location: Bielefeld

Occupation: Softwareentwickler

  • Send private message

4

Thursday, December 25th 2008, 2:30pm

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

5

Thursday, December 25th 2008, 3:02pm

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

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
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);
        ....
        }

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

6

Thursday, December 25th 2008, 9:12pm

Soooo, bei mir gehts wieder. :bounce1 :bounce2 :bounce3 :bounce5

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

7

Thursday, December 25th 2008, 10:32pm

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/documenta…_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

Intermediate

Posts: 363

Location: Mannheim

  • Send private message

8

Tuesday, December 30th 2008, 10:31am

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

so long,

talpa.

Quoted

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/documenta…_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...

My Stuff

VDR-Server · D3417B - Celeron G3900 · DD Cine S2 V6 & DuoFlex S2 · 16 TB Archiv · Ubuntu 14.04 · vdr 2.2
VDR-Client 1 · Wetek Play · OpenELEC 6.0.3
VDR-Client 2 · Aopen i915HFS · GeForce 760 · Pentium M 745 · 250 GB System · yaVDR 0.3.2 - 2.0.6 · @Loewe Xemix 9006

Immortal Romance Spielautomat