Debian liest Hardware Zeit inkorrekt

[spiralnebelverdreher]

(Und wenn's einmal geht, kann das auch Zufall sein, Probier das ruhig zwei, drei mal aus)

Es war leider wirklich nur Zufall,dass es vorhin geklappt hat.

Habe soeben (nach ca. 7,5 Stunden im Suspend Modus) Debian wieder aufgerufen, und die Systemzeit steht auf ...

Muss nicht unbedingt Zufall sein, dieses Ergebnis.
Ein Erklärungsansatz könnte eine schwache BIOS-Batterie sein, die intern durch einen Kondensator gepuffert wird um die Daten über das Auswechseln der Batterie hin zu erhalten (also einige Minuten). Diese Konstruktion kenne ich von einigen Mainboards - manche haben sogar einen Jumpersteckplatz um den Kondensator kurzzuschließen und so das Vergessen zu beschleunigen. Solange der Rechner am Stromnetz ist, wird der Kondensator immer aufgeladen sein und 10 Minuten nach Suspend kann der noch ausreichend geladen sein.
Aus der Beobachtung, dass die BIOS Uhr im ausgeschalteten Zustand einwandfrei weiter läuft müsste man dann aber annehmen, dass die Uhr mit der schlechten Batterie noch läuft, wogegen das BIOS wegen der schlechten Batterie Datenverluste erleidet. Bin jetzt kein BIOS Spezialist, aber von der Realisierung her kann das durchaus getrennt sein, obwohl alles in einem Chip-Gehäuse wohnt.
Hilfreich ist, dass es sich anscheinend immer um ganze Stunden Zeitdifferenz handelt . Das deutet auf einen Fehler in der Umrechnung oder Speicherung der Sekunden-seit-irgendwas in eine menschenlesbare Uhrzeit hin. 64h in der Zukunft könnte durch ein einziges gekipptes Bit entstehen. Könnte also auch schlicht defekte HW sein.

Edit:
Mal spekuliert: Das BIOS hat eine Uhr, die einfach Sekunden hochzählt und sich diesen Integerwert merkt. Wenn beim händischen Stellen der Uhr im BIOS dieser Zähler auf 0 gesetzt wird und gleichzeitig der eingegebene Datum/Uhrzeitwert gespeichert wird, dann kann das BIOS die aktuelle Uhrzeit immer durch Addition berechnen. Wenn aber der Basiswert wackelt, dann kommt halt dieses falsche Ergebnis raus.

[MSfree]

Ein Erklärungsansatz könnte eine schwache BIOS-Batterie sein.

Meiner Erfahrung nach führt eine leere BIOS-Batterie zum Zurücksetzen der Uhrzeit auf irgendeine herstellerspezifische Anfangsuhrzeit, z.B. 1.1.2000. In die Zukunft hat mich dabei noch nie eine BIOS-Uhr versetzt.

[spiralnebelverdreher]

Ein Erklärungsansatz könnte eine schwache BIOS-Batterie sein.

Meiner Erfahrung nach führt eine leere BIOS-Batterie zum Zurücksetzen der Uhrzeit auf irgendeine herstellerspezifische Anfangsuhrzeit, z.B. 1.1.2000. In die Zukunft hat mich dabei noch nie eine BIOS-Uhr versetzt.

Ebend! Da die Zeit in die Zukunft springt und das auch anscheinend immer um ganze Stunden, kann eine leere BIOS Batterie nicht alleinige Ursache sein.

Wenn ich aus Linux die HArdwarezeit abrufe (hwclock -D), steht da mit korrektem Datum eine Uhrzeit von 89:18:23

Die 89 Stunden deuten doch auf im Speicher veränderte Daten hin, denn bei normaler Ausführung der Zeitberechnung wäre ja ab 23:59:59 auch das Tagesdatum hochegzählt worden.

[NAB]

root@Michas-BigAsus:/home/michael# date
So 12. Jun 16:13:10 CEST 2016
root@Michas-BigAsus:/home/michael#

(also genau 64 Stunden in der Zukunft).

Nö, vom 9. Jun, 8 Uhr sind das 3 Tage (72 Stunden) plus 8 Stunden ... also auch wieder genau 80 Stunden. Diesmal allerdings ohne irgendwelche AM/PM-Verdrehung.

Ich kriege über dieses komische AM/PM-Zeitformat nichts heraus, von dem cosmac sprach. Wart mal ab, ob er noch was dazu zu sagen hat.

Aber für mich sieht es wieder nach der Vermutung aus, die ich schon auf der ersten Seite des Threads äußerte ... das Mainboard gibt die RTC-Zeit in einem Format aus, das Linux nicht kennt. Das führt zu Zeitsprüngen 80 Stunden in die Zukunft - Nachmittags anscheinend mit einer Verdrehung von PM zu AM.

Das erste, was ich da ausprobieren würde, wäre das neue BIOS, das rendegast gefunden hat:
viewtopic.php?f=12&t=161067&start=15#p1093952

Sonst BIOS-Reset, CMOS-Reset oder mal ins BIOS gucken, ob du das Zeitformat da umstellen kannst.

Und was sagt denn nun

Code: Alles auswählen

cat /proc/driver/rtc

?

Die Ausgabe von

Code: Alles auswählen

dmesg | grep rtc

wäre eventuell auch interessant.

[cosmac]

Ich hätte gedacht, dass das Zeitformat (24h oder 12h AM/PM) nur etwas mit der Darstellung zu tun hat, aber nicht mit der Berechnung von Zeit im System.

Ja und nein. Der klassische RTC-Chip im PC ist wohl für bessere Radiowecker o.ä. entworfen worden. Deshalb zählt er intern nicht einfach die Sekunden, also binär, sondern dezimal ("BCD") - so, wie es für die Wecker-Anzeige mit 4 oder 6 Ziffern gebraucht wird. Er hat quasi 6 getrennte Zähler für die Uhrzeit (und ein paar für's Datum), die bis 2, 3, 5, 9, 5, 9 zählen. Für die Amerikaner muss er nicht ganz so weit zählen, aber Mittags und um Mitternacht die AM/PM-Anzeige umschalten. Das dafür nötige Bit hat man einfach in den Stunden-Zehner-Zähler gepackt. Der kennt dadurch die Zählerstände 0, 1, 8 und 9 (im AM/PM-Betrieb) bzw. 0, 1 und 2 (normalerweise).

Der Kernel liest also praktisch die Uhrzeit von der "Anzeige" ab und rechnet sie in Sekunden um, date berechnet aus den Sekunden wieder die Uhrzeit und gibt sie als Text aus. Das BIOS könnte sich die Umrechnerei sparen und die einzelnen Ziffern aus der RTC direkt anzeigen. hwclock und ähnliche Programme gehen evt. einen Mittelweg. Prinzipiell könnte ein Programm alle RTC-Betriebsarten richtig ausgewerten, aber wie vollständig ist das jeweils programmiert?

Wenn das tatsächlich die Ursache des Problems sein sollte, ist das doch wiklich ein Bug, oder ?

Wenn irgendein BIOS die 24-Stunden vs. AM/PM Umschaltung anbietet, sicher. NAB schrieb ja, dass der Kernel mindestens binär und BCD unterscheidet, also ist das Problem nicht völlig unbekannt.

Zumal ich definitiv bei der Debian Installation nirgendwo spezifiziert hatte, dass Zeiten als 12h AM/PM berechnet werden.

Das wäre ja auch eine BIOS-Einstellung, da sollte sich Debian nicht einmischen.

Das ist ja bisschen so, als würde man ein Auto bauen, bei dem die Gewinde alle metrisch sind und man dann versucht, Bolzen mit Zoll-Massen reinzuschrauben. Also das kann doch von den Debian Entwicklern nicht so beabsichtigt worden sein.

Ich finde, es ist eher so, dass der Kernel Gewinde hat, in die metrische und imperiale(?) Schrauben passen

Wenn ich aus Linux die HArdwarezeit abrufe (hwclock -D), steht da mit korrektem Datum eine Uhrzeit von 89:18:23

Die 89 Stunden deuten doch auf im Speicher veränderte Daten hin, denn bei normaler Ausführung der Zeitberechnung wäre ja ab 23:59:59 auch das Tagesdatum hochegzählt worden.

Im Speicher der RTC... Dieses sieht doch so aus, dass hwclock direkt das anzeigt, was es aus der RTC liest. Wenn daraus Sekunden berechnet werden, erfolgt ja auch der Tagesübertrag. Es ist übrigens offiziell so, dass dabei illegale Zeiten stillschweigend konvertiert werden, siehe man mktime.

Ganz neugierige suchen sich ein "datasheet MC146818".

[NAB]

Der kennt dadurch die Zählerstände 0, 1, 8 und 9 (im AM/PM-Betrieb) bzw. 0, 1 und 2 (normalerweise).

8 und 9 stehen dann für PM? Also ab 12 Uhr Mittags (00 PM) würde da dann 80 Uhr stehen, bis 21 Uhr (09 PM = 89), und ab 22 Uhr (10 PM) steht dann da 90 Uhr? Das würde die 80-Stunden-Sprünge Nachmittags sehr gut erklären.

Das erklärt aber noch nicht, was bei micha81929 um 8 Uhr morgens passiert ist. Da müsste der Kernel ja beim Aufwachen eine 88 statt einer 08 gelesen haben.

Spannend ist auch, was passiert, wenn der Kernel versucht, die Hardware-Uhr zu stellen ... aber eigentlich auch erst ab Nachmittag. Ab 12 Uhr schreibt es Uhrzeiten, die das BIOS als illegal erkennen könnte und vielleicht "korrigiert".

hmmm ... micha81929 hat den Rechner heute um 00:30 in den Standby versetzt und um 08:30 wieder aufgeweckt. Falls der Kernel aus irgendeinem Grund der Meinung ist, doch eine UTC-Zeit in BIOS zu schreiben, statt der local time, dann wäre 22:30 geschrieben worden ... da könnte sonstwas passiert sein ...

[cosmac]

Der kennt dadurch die Zählerstände 0, 1, 8 und 9 (im AM/PM-Betrieb) bzw. 0, 1 und 2 (normalerweise).

8 und 9 stehen dann für PM? Also ab 12 Uhr Mittags (00 PM) würde da dann 80 Uhr stehen, bis 21 Uhr (09 PM = 89), und ab 22 Uhr (10 PM) steht dann da 90 Uhr? Das würde die 80-Stunden-Sprünge Nachmittags sehr gut erklären.

Im Prinzip ja, aber Null Uhr gibt's nicht, die RTC zählt so:

Code: Alles auswählen

Stunden-  Stunden-
Zehner     Einer
   0             1   AM
   0             2   AM
         ...
   0             9   AM
   1             0   AM
   1             1   AM
   1             2   AM
   8             1   PM
   8             2   PM
         ...
   8             9   PM
   9             0   PM
   9             1   PM
   9             2   PM
   0             1   AM

Das erklärt aber noch nicht, was bei micha81929 um 8 Uhr morgens passiert ist. Da müsste der Kernel ja beim Aufwachen eine 88 statt einer 08 gelesen haben.

Das muss nicht der Kernel gewesen, ich tippe eher auf hwclock. Aber die 80 passt bei der Gelegenheit garnicht

Spannend ist auch, was passiert, wenn der Kernel versucht, die Hardware-Uhr zu stellen ... aber eigentlich auch erst ab Nachmittag. Ab 12 Uhr schreibt es Uhrzeiten, die das BIOS als illegal erkennen könnte und vielleicht "korrigiert".

Stimmt, falls die RTC wirklich im AM/PM-Betrieb läuft, kann alles mögliche passieren. Bei manchen Chips sagt das Datenblatt dazu "führt zu undefiniertem Verhalten". Alles nicht überzeugend...

[NAB]

Im Prinzip ja, aber Null Uhr gibt's nicht, die RTC zählt so:

Das wird ja immer spannender ...

Wenn ich diesen miserablen Scan richtig entziffere:
http://html.alldatasheet.com/html-pdf/1 ... 46818.html
(Seite 12)
dann zählt er im AM/PM-Modell von 01 bis 12 (AM) und 81 bis 92 (PM) und im 24-Stunden-Modell von 00 bis 23. Da würde man eher 79 statt 80 Stunden Differenz erwarten. Allerdings müsste er dann heute früh um 00:30 eine "00" in das AM/PM-Modell geschrieben haben, und dann wären wir wieder beim "undefined".

Das muss nicht der Kernel gewesen,

Ich wollt jetzt nicht diskutieren, ob util-linux zum Kernel gehört, aber die Erkennungs- und Ansprechlogik scheint in rtc_cmos zu stecken. hwclock verlässt sich darauf, dass der Kernel das schon richtig macht.

Nachdem ich nun weiß, dass AM/PM gar kein dritter Modus neben Binary und BCD ist, hab ich noch mal in den Treibercode geschaut, und in rtc_cmos diese kleine Perle entdeckt:

Code: Alles auswählen

704         /* FIXME:
705          * <asm-generic/rtc.h> doesn't know 12-hour mode either.
706          */
707         if (is_valid_irq(rtc_irq) && !(rtc_control & RTC_24H)) {
708                 dev_warn(dev, "only 24-hr supported\n");
709                 retval = -ENXIO;
710                 goto cleanup1;
711         }

cleanup1 macht dann Folgendes:

Code: Alles auswählen

759 cleanup1:
760         cmos_rtc.dev = NULL;
761         rtc_device_unregister(cmos_rtc.rtc);

beendet also anscheinend die Zusammenarbeit mit der RTC, wenn diese im AM/PM-Modus läuft.
http://lxr.free-electrons.com/source/dr ... rtc-cmos.c

Das sieht für mich so aus, als ob der Kernel bei micha81929 nicht erkennt, dass die Uhr im AM/PM-Modus läuft. Das ist entweder ein Fehler im Treiber oder im Mainboard bzw. BIOS.

[micha81929]

Das wird ja immer spannende

Hallo NAB, Cosmac und spiralnebelverdreher,

Vielen Dank dass Ihr in den Tiefen des Systems nach einer Lösung des Problems sucht.

Der aktuelle Stand sieht so aus:

Beim Booten über Grub übernimmt Debian jetzt immer die richtige Zeit/Datum aus dem BIOS (egal ob das Vor- oder Nachmittag passiert).
Wenn ich aber für ein paar Sekunden in den Suspend-Modus gehe und dann wieder zurück, springt die Zeit (nach meiner REchnung) um 68 h in die Zukunft (zum Beispiel jetzt gerade von aktuell 22:54, 10.6.16 auf 18:54 am 13.06.16)

michael@Michas-BigAsus:~$ date
Mo 13. Jun 18:54:12 CEST 2016
michael@Michas-BigAsus:~$

Nach meiner Rechnung sind das doch 68 Stunden, oder ? Wenn ich mehrmals in Suspend und wieder zurück gehe, bleibt es bei diesen +68 Stunden.
Wenn ich den Rechner runterfahre und Linux neu boote, übernimmt das System aus dem BIOS die korrekte Zeit als Systemzeit. Deshalb spricht m.M. nach immer noch alles dafür, das das BIOS o.k. ist.
Ich bin erstmal froh, dass die Sprünge in der Debian-Systemzeit jetzt nicht mehr ins BIOS geschrieben werden.

Ich werde mal in den nächsten Tagen / Wochen Debian von Wheezy auf Jessie upgraden und hoffen, dass der Bug dann weg ist. Ein Kollege, der Debian schon lange benutzt hat mir erklärt, dass es neben dem Suspend-Modus auch noch einer Hibernating-Modus gibt. Weiss jemand von Euch zufällig, wo Debian die aktuellen Daten ablegt, wenn es in Suspend geht, und die es dann bei Wiederaufwecken ins System schreibt ?

Gruss Micha

[micha81929]

Hier habe ich eine Bemerkung vom Grossmeister himself (Linus Thorvald) gefunden, der etwas über Magic Numbers, suspend mode und Problem mit der Systenzeit schreibt:

"
Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
using this trace option.

As the clock keeps ticking it is also essential that the reboot is done
quickly after the resume failure. The trace option does not use the seconds
or the low order bits of the minutes of the RTC, but a too long delay will
corrupt the magic value."

Der volle text steht hier https://www.kernel.org/doc/Documentatio ... /s2ram.txt

[NAB]

springt die Zeit (nach meiner REchnung) um 68 h in die Zukunft (zum Beispiel jetzt gerade von aktuell 22:54, 10.6.16 auf 18:54 am 13.06.16)

Als du es Vormittags ausprobiert hast, waren es 80 Stunden. Nachmitags sind es 68. Die 12 Stunden Differenz am Nachmittag könnten sich dadurch ergeben, dass er das 22:54 als 10:54 PM liest, und das PM einfach weglässt - bzw, aus "10:54 PM" dann "10:54 plus 80 Stunden" macht.

Du könntest am Wochenende mal ein paar weitere Tests am Vormittag machen, ob sich das mit den 80 Stunden bestätigt. Die "kritischen" Zeiten um Mittag und Mitternacht herum solltest du dabei aussparen.

Das sähe dann nämlich alles danach aus, dass er ein AM/PM-Format falsch (oder gar nicht) erkennt und die von cosmac erwähnten 80 Stunden Plus draufhaut.

Und Jessie wär natürlich auch ne gute Idee ...

Hier habe ich eine Bemerkung vom Grossmeister himself (Linus Thorvald) gefunden, der etwas über Magic Numbers

Beachte den Kontext. Diese Magic Number wird nur im Debug-Modus benutzt. Dort wird die RTC-Uhr absichtlich missbraucht. Das hat nichts mit deinem Problem zu tun.

Einzig hilfreich ist der Hinweis auf den NTP-Client ... aber das wusstest du auch schon vorher.

[spiralnebelverdreher]

Hier habe ich eine Bemerkung vom Grossmeister himself (Linus Thorvald) gefunden, der etwas über Magic Numbers, suspend mode und Problem mit der Systenzeit schreibt:

"
Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
using this trace option.

As the clock keeps ticking it is also essential that the reboot is done
quickly after the resume failure. The trace option does not use the seconds
or the low order bits of the minutes of the RTC, but a too long delay will
corrupt the magic value."

Der volle text steht hier https://www.kernel.org/doc/Documentatio ... /s2ram.txt

Das ist ja interessant. Wenn ich deinen Link recht verstehe soll das Modul pm_trace irgendwas persistent wegschreiben (möglicherweise zu einem späten Zeitpunkt, wenn Dateisysteme schon ausgehängt sind) und hat sich dafür die Real Time Clock ausgesucht. Da kann man ja etwas an Info unterbringen, weil die Uhrzeit mit AM/PM und dem von cosmac beschrieben Nummernschema ja die Stundeninformation teilweise redundant speichert.

Aus dem Text wird aber nicht klar, wann und durch wen diese Trace-Option gesetzt wird und dieser Mechanismus zuschlägt. Der von Torvalds beschriebene Korrekturweg (nimm ntp-Zeit um Uhrezit wieder gerade zu biegen) schlägt in deinem Fall aber fehl (siehe ntp-Log), weil die Zeitdifferenz RTC <-> ntp größer als 1000s ist. Also muss beim Aufwachen aus Suspend hier ein robusterer Modus her, der auch größere Zeitdifferenzen akzeptiert.

Ich verstehe aber nicht, wieso dieses Problem nicht schon viel früher / viel häufiger aufgefallen ist. Hast du beim Aufwachen aus Suspend irgendwelche Probleme mit Netzwerkverbindungen? Hast du mal in irgendwelchen Config-dateien einen hohen debug-Level eingestellt?

[micha81929]

In diesem threat steht eigentlich das gleiche:
Clock shifted to the future after suspend/resume
https://bbs.archlinux.org/viewtopic.php?id=173487

Naja, wenigstens habe ich nicht mehr das Gefühl als Phantast zu gelten. Aber auf dem Threat (von 2014) hat auch niemand die Ursache des Problemes gefunden. Der einzge Vorschlag besteht darin, ein Script zu erstellen dass nach jedem suspend/resume wieder eine Korrektur von -68 Stunden zu machen.

[NAB]

Na, der führt es doch auch direkt auf ein BIOS-Update zurück.

Hier hast du übrigens noch einen Bericht darüber:
http://www.linlap.com/asus_k52dr
(aber auch keine weiteren Informationen)

[micha81929]

Na, der führt es doch auch direkt auf ein BIOS-Update zurück.
Hier hast du übrigens noch einen Bericht darüber:
http://www.linlap.com/asus_k52dr
(aber auch keine weiteren Informationen)

Hallo NAB, vielen für den Link, der tatsächlich das gleiche beschreibt. Also sieht das so aus, dass man mit dem Bug leben muss, solange es nicht eine neue Debian version gibt, die den Asus (mit AMD Athlon II P320 Dual-Core Processor, Motherboard weiss ich nicht ) kompatibel macht mit der suspend/resume Prozedur. Es macht mich allerdings nicht sehr hoffnungsvoll, wenn man liest dass dieser Bug schon seit mehreren Jahren bekannt ist und in Foren diskutiert wird, aber bis heute niemand eine grundlegende Lösung dagegen gefunden hat (ich habe auch aus dieser Diskusionhttps://bbs.archlinux.org/viewtopic.php?id=173487nicht entnehmen können, dass man mit einem BIOS update die Sache in den Griff bekommt).
Vielen Dank nochmals allen, die sich in diesem Threat mehrere Tage mit den teils widersprüchlichen Befunden auseinandergesetzt haben.

beste Grüsse
Micha

[NAB]

micha81929, der Threaderöffner im Archlinux-Forum berichtet, dass das Problem bei ihm nach einem BIOS-Update, Linux-Update und Grafiktreiber-Update anfing. Das Linux- und Grafiktreiber-Update konnte er rückgängig machen ... das hat das Problem allerdings nicht beseitigt. Somit bleibt das BIOS-Update als Ursache.

Nun klingt es nicht vertrauenserweckend, wenn ein BIOS-Update das Problem erst verursacht ... aber da es bei dir schon da ist, hast du durch ein BIOS-Update nicht viel zu verlieren.

Und stimmt ... gute Beobachtung! Alle vier (mit dir) beobachteten Fälle scheinen ein Board mit AMD Phenom II einzusetzen. Ein Grund mehr, es mit einem BIOS-Update zu versuchen ... das bringt nämlich auch aktuelle Firmware für die Bauteile auf dem Mainboard mit.

Und drei von vier Fällen erwähnen, dass sie Windows im Dual-Boot betreiben ... eventuell verstellt Windows hier auch irgendwas, was einen Reboot überlebt. Derartige Probleme hatte ich schon mit Grafik- und Netzwerkkarten. Kurz den Stromstecker zu ziehen, und dann Linux zu booten, müsste dann einen Unterschied machen.

Relativ neu ist für mich die Erkenntnis, dass das Problem nur bei einem Suspend auftritt ... das war aus deinen ersten Beschreibungen nicht so klar ersichtlich. Meinst du, das war schon immer so?

[micha81929]

Relativ neu ist für mich die Erkenntnis, dass das Problem nur bei einem Suspend auftritt ... das war aus deinen ersten Beschreibungen nicht so klar ersichtlich. Meinst du, das war schon immer so?

Es trat auf jeden Fall immer dann auf, wenn das System nach 30 min Inaktivität automatisch in den Suspend Modus ging. Und weil es ja ursprünglich dann auch die BIOS Zeit verstellt hat, hat dann auch kein Rebooten mehr geholfen. Ich hatte niemals versucht, Debian komplett runter- und gleich wieder hochzufahren. Dann wäre es möglicherweise aufgefallen, dass es nur bei Suspend/Resume passiert. Das ist mir erst im Laufe der Fehlersuche hier im Forum klar geworden.
Ich werde mal ein BIOS update versuchen, weiss aber nicht wann ich dazu komme.

Gruss, Micha

[NAB]

Ja, mach das!

Dass irgendwelche Geräte, bzw. deren Treiber, einen Suspend nicht fehlerfrei überstehen, passiert unter Linux leider öfter. Ich hab aber noch nie gehört, dass die RTC-Uhr davon betroffen sei. Üblicher Weise besteht die Lösung dann darin, den fehlerhaften Treiber vor dem Suspend zu entladen, und nach dem Suspend neu zu laden. Den zugehörigen Treiber finde ich bei mir aber mit einem

Code: Alles auswählen

lsmod | grep rtc

gar nicht ... der scheint nicht permanent zu laufen. Ich kann ihn mit

Code: Alles auswählen

modprobe rtc_cmos

ohne Fehler laden ... direkt danach ist er wieder verschwunden.

Ach, was sagt eigentlich

Code: Alles auswählen

hwclock --directisa

bei dir, sowohl wenn die Uhr richtig geht, als auch, wenn sie verstellt ist?

[spiralnebelverdreher]

Na, der führt es doch auch direkt auf ein BIOS-Update zurück.
Hier hast du übrigens noch einen Bericht darüber:
http://www.linlap.com/asus_k52dr
(aber auch keine weiteren Informationen)

Hallo NAB, vielen für den Link, der tatsächlich das gleiche beschreibt. Also sieht das so aus, dass man mit dem Bug leben muss, solange es nicht eine neue Debian version gibt, die den Asus (mit AMD Athlon II P320 Dual-Core Processor, Motherboard weiss ich nicht ) kompatibel macht mit der suspend/resume Prozedur. ...

Auch wenn du den Bug erst mal nicht weg bekommst: Was spricht dagegen gleich nach dem Aufwachen explizit die RTC Uhr neu zu stellen mit dem Befehl

Code: Alles auswählen

 ntpd -q -g    (an der passenden Stelle in einem resume-Skript)

oder in der Konfiguration deines ntp-Daemons statt der defaultmäßig tolerierten Differenz von 1000s einfach 81 Stunden einzustellen? Dann ist der Bug noch da, wirkt aber nicht lange nach in deinem System.

[micha81929]

Immer noch ein totales Durcheinander mit der Systemzeit:

root@Michas-BigAsus:/home/michael# hwclock -D
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1465421566 seconds after 1969
Last calibration done at 1465421566 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/06/16 90:56:02
Hw clock time : 2016/06/19 18:56:02 = 1466355362 seconds since 1969
So 19 Jun 2016 18:56:02 CEST -0.104839 seconds
root@Michas-BigAsus:/home/michael# date
Mi 22. Jun 02:56:47 CEST 2016
root@Michas-BigAsus:/home/michael#

Ich bin ratlos

[spiralnebelverdreher]

Ändert ein beherztes (mit root rechten ausgeführt)

Code: Alles auswählen

ntpd -q -g  

etwas an dieser Situation?

[NAB]

Immer noch ein totales Durcheinander mit der Systemzeit

Warum sollte sich auch was ändern, wenn du nichts änderst. Oder hast du?

[Taomon]

Mir half folgendes.

Code: Alles auswählen

dpkg-reconfigure tzdata

und danach

Code: Alles auswählen

timedatectl set-local-rtc 0

Allerdings läuf bei mir kein ntp

Code: Alles auswählen

root@Taomon:/home/alex# timedatectl 
      Local time: So 2016-06-26 19:35:52 CEST
  Universal time: So 2016-06-26 17:35:52 UTC
        RTC time: So 2016-06-26 17:35:52
       Time zone: Europe/Berlin (CEST, +0200)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  So 2016-03-27 01:59:59 CET
                  So 2016-03-27 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  So 2016-10-30 02:59:59 CEST
                  So 2016-10-30 02:00:00 CET

Seitdem keine Probleme mehr.

Gruß Taomon