Hallo Christian, zunächst wünsche ich Dir und allen hier ein frohes und gesundes neues Jahr! Christian Pubanz (GMX) schrieb:
Am Freitag, 21. Dezember 2007 16:09:12 schrieb Martin Burnicki: Hallo Martin,
hoffe, du hattest ein schönes Weihnachtsfest!
Ja, danke. Ich hoffe, Du auch. [...]
könnte mir durchaus vorstellen, dass der Kernel-speziell mit DIESEM Mainboard- nicht klarkommt. Schließlich ist es ja ein älteres Modell, wie bereits erwähnt. Ich fürchte, das ist der Fall. Die Frage ist, ob das Grundproblem im Kernel oder an der Hardware liegt. Wenn z.B. der Timer-Takt aus Energiespargründen rauf und runtergeschaltet wird, aber der kernel bekommt die Umschaltung nicht korrekt mit, weil das (ACPI-) BIOS einen Fehler hat, dann hat ntpd kaum eine Chance, vernünftige Korrekturen anzubringen.
Hmm...
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. Vielleicht zeigt Du mal die Ausgabe von: # grep -i "clock\|tsc\|acpi_pm" /var/log/boot.msg 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. Bei mir sieht die Ausgabe z.B. so aus: # date -u; ntpdate -q ptbtime1.ptb.de Mi Jan 2 09:26:09 UTC 2008 server 192.53.103.108, stratum 1, offset 0.000919, delay 0.04536 2 Jan 10:26:09 ntpdate[29113]: adjust time server 192.53.103.108 offset 0.000919 sec # date -u; ntpdate -q ptbtime1.ptb.de Mi Jan 2 09:28:37 UTC 2008 server 192.53.103.108, stratum 1, offset 0.000067, delay 0.04355 2 Jan 10:28:37 ntpdate[29168]: adjust time server 192.53.103.108 offset 0.000067 sec Natürlich ist eine wiederholte Anfrage in so kurzem Zeitabstand wie oben nicht besonders aussagekräftig. Besser wäre die Ausgabe nach 1 Stunde, nach 2 Stunden, ... [...]
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. Bitte kommentiere auch (wenigstenst zunächst) noch alle "restrict"-Zeilen in Deiner ntp.conf aus, bevor Du weitere Versuche mit ntpd startest ... Viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org