Am Mittwoch, 2. Januar 2008 11:28:32 schrieb Martin Burnicki:
Hallo Christian, Hallo Martin,
zunächst wünsche ich Dir und allen hier ein frohes und gesundes neues Jahr! vielen Dank, dir und allen anderen auch (noch). Kam (mal wieder) erst jetzt zum Ausprobieren. Bitte meine Langsamkeit vielmals zu entschuldigen... [...]
Habe heute morgen einen Beitrag im User-Forum von Fujitsu-Siemens verfasst, die Problematik dargestellt und gefragt, ob jemand mir nähere technische Infos zu dem in meinem Mainboard verarbeiteten Timer-Quarz geben kann.
(siehe http://support.fujitsu-siemens.de/forum/viewtopic.php?t=27483)
Leider ist ja aus dem technischen Handbuch das ja nicht so ersichtlich!
"Der Quarz" an sich wird nicht das Problem sein, sondern eher der Chipsatz, dessen Taktfrequenz heruntergeschaltet wird, um Energie zu sparen und dadurch die Akku-Laufzeit zu erhöhen.
Stell Dir vor, der Timer läuft normalerweise mit 1000 Takten pro Sekunde, d.h. nach jeweils 1000 Takten muß die Software-Uhr des Kernels 1 Sekunde hinzuaddieren. Wenn jetzt die Timer-Taktrate auf 800 Takte/s heruntergesetzt wird, um Energie zu sparen, muß der Kernel das mitbekommen, damit er weiß, dass bereits nach 800 Takten eine neue Sekunde beginnt.
Wenn der Linux-Kernel die Umschaltungen nicht korrekt mitbekommt, zählt er die Sekunde weiterhin erst nach 1000 Takten weiter, d.h. die Software-Uhr geht viel zu langsam.
Die Werte oben sind natürlich nur ein Beispiel, um das Problem zu verdeutlichern.
Der Grund, warum der Kernel das nicht mitbekommt, kann entweder im Kernel liegen, wenn der Chipsatz des Laptop nich vollständig bzw. korrekt unterstützt wird. Andererseits kann auch eine fehlerhafte bzw. unvollständige Implementierung des (ACPI-) BIOS des Rechners schuld sein. Ja, auf meinen Beitrag im Forum von FSC kam so eine ähnliche Antwort... Da hab ich wohl eine ungünstige Wortwahl gewählt...
Vielleicht zeigt Du mal die Ausgabe von: # grep -i "clock\|tsc\|acpi_pm" /var/log/boot.msg Büdde:
<6>Time: tsc clocksource has been installed. <6>Real Time Clock Driver v1.12ac <6>intel8x0_measure_ac97_clock: measured 53708 usecs <6>intel8x0: clocking to 49937 doneSetting up the hardware clock<notice>killproc: kill(1082,29)
Daraus sollte ersichtlich sein, welchen Timer der Kernel für die Systemzeit verwendet. (siehe https://bugzilla.novell.com/show_bug.cgi?id=350981)
Du könntest auch mal sehen, ob die Systemzeit auch wegläuft, wenn ntpd nicht läuft.
Also zunächst ntpd anhalten und die Systemzeit mit ntpdate hart setzen:
rcntp stop date -u; ntpdate ptbtime1.ptb.de
Dann den laptop einige Stunden laufen lassen und mit ntpdate prüfen, wie weit die Systemzeit weggedriftet ist. Wichtig ist hier der zusätzliche Parameter "-q" für "query only", damit nur die Zeitdifferenz angezeigt wird, ohne die Systemzeit zu setzen:
date -u; ntpdate -q ptbtime1.ptb.de
Das "date -u" gibt vorher noch die aktuelle Systemzeit aus, dann kann man in der Historie der Konsolenmeldungen sehen, wieviel Zeit zwischen den Aufrufen vergangen i st.
Hab ich gemacht, anbei eine TXT-Datei mit zwei Ergebnissen. Dummerweise habe ich bei dem einen Test vergessen, dass -q zu verwenden, so dass die Systemzeit anschließend korrigiert wurde. Aber bei dem zweiten Ergebnis kann man ganz eindrucksvoll sehen, dass, auch wenn der NTPD nicht läuft, die Zeit "wegläuft"...
[...]
Dann neu Booten und den Rechner ein paar Stunden laufen lassen. Zwischendurch kannst Du kontrollieren, ob eine Datei /tmp/loopstats angelegt wird, und was drinsteht. Auch ein "ntpq -p" zwischendurch kann nicht schaden.
Hab ich gemacht-läuft nicht! :-(
Anbei findet sich meine NTP.conf-habe die entsprechenden Zeilen genau so ersetzt, wie du beschrieben hast...
Schaue ständig ins /tmp-Verzeichnis-bisher ist leider noch keine loopstats-Datei aufgetaucht;auch keine versteckte...
:-(
Schau mal in Deine /var/log/messages. Da steht zyklisch:
ntpd[3359]: can't open /tmp/loopstats.20071227: Permission denied
Das sieht so aus, als ob Apparmor das Erstellen der Datei verhindert. Entweder muß das Apparmor-Profil für ntpd so geändert werden, dass ntpd in /tmp/ schreiben darf, oder Du kannst Apparmor einfach deaktivieren: Temporär über "rcapparmor stop" oder dauerhaft über yast2->NovellApparmor->Apparmor-Kontrolleiste->Checkbox "Enable Apparmor" deaktivieren. Ja, das war der Fehler! Ich muss gestehen, dass ich manche Sachen bei Linux nicht kenne bzw. nicht weiß, für was die eigentlich genau da sind-aber als ich "Apparmor" dauerhaft deaktiviert hatte, erschien auch die loopstats-Datei, die ich ebenfalls anhänge.
Bitte kommentiere auch (wenigstenst zunächst) noch alle "restrict"-Zeilen in Deiner ntp.conf aus, bevor Du weitere Versuche mit ntpd startest ... Hab ich auch gemacht-sicher ist sicher...
Vielleicht kommen wir ja mit diesen neuen Erkenntnissen endlich auf die richtige Spur des Problems...;-) Viele Grüße und einen guten Wochenstart! Christian