Zeit verstellt sich von selbst

rtg said:
Wäre als deamon immerhin eine Verbesserung des aktuellen Zustandes :)
Click to expand...
Ja, aber etwas übertrieben. Wenn die Hardware-Clock richtig läuft, reicht ja erstmal ein regelmässiges "hwclock --hctosys" um die Systemuhr zu syncronisieren.

huschi.
 
Also der ntpd kann da nichts mehr ausrichten. Nachdem heute früh die Zeit wieder über eine Stunde in der Zukunft lag, habe ich im Logfile was interessantes gefunden:
Code: 
Feb 14 03:37:41 neo kernel: warning: many lost ticks.
...
Feb 14 03:37:41 neo kernel: Your time source seems to be instable or some driver is hogging interupts
Feb 14 03:37:41 neo kernel: rip acpi_processor_idle+0x149/0x349
Kann das jetzt ein Hardwarefehler sein oder schießt da ein Treiber quer?

Wie mir scheint, läuft die Softwareuhr immer mal kurzzeitig aus dem Ruder und dann versucht der Kernel die Tick-Rate anzupassen. Danach läuft die Uhr aber komplett falsch. Kann man dem Kernel dieses Anpassen irgendwie austreiben?
 
netspy said:
Your time source seems to be instable or some driver is hogging interupts
Click to expand...
Google spuckt zu dieser Fehlermeldung einiges aus.
Es scheint mir, als würde dieses Problem vorallem auf AMD-64er-CPUs bestehen. Meist im zusammenhang mit IDE-Treibern.

Als Lösungen wurden folgende Bootparameter vorgeschlagen:
a) noacpi
b) acpi=off
c) noacpi acpi=off
d) no_timer_check

Vorallem d) scheint wohl der erfolgreichste Parameter zu sein.

huschi.
 
Huschi said:
Als Lösungen wurden folgende Bootparameter vorgeschlagen:
a) noacpi
b) acpi=off
c) noacpi acpi=off
Click to expand...
Werd ich mal ausprobieren. Danke.

Huschi said:
d) no_timer_check

Vorallem d) scheint wohl der erfolgreichste Parameter zu sein.
Click to expand...
Ne, ich schrieb ja schon, dass ich den ausprobiert habe. Das bring leider keine Besserung.
 
Huschi said:
Als Lösungen wurden folgende Bootparameter vorgeschlagen:
a) noacpi
b) acpi=off
c) noacpi acpi=off
d) no_timer_check
Click to expand...
Bringt leider alles nichts. Schon 10 Minuten nach dem Neustart kam wieder diese Meldung:
Code: 
Feb 14 13:11:17 neo kernel: Losing some ticks... checking if CPU frequency changed.
Feb 14 13:12:13 neo kernel: warning: many lost ticks.
Feb 14 13:12:13 neo kernel: Your time source seems to be instable or some driver is hogging interupts
Feb 14 13:12:13 neo kernel: rip 0x2aaaad0150b5
Dann gings wieder in die Zukunft. :mad:
 
Also ein Sytem das evt. für den 64iger nciht richtig konfiguriert ist, oder Module die sich stören - oder aber eine defekte CPU oder ein Boardproblem das den CPU Takt nciht stabil hält ?

Wird immer interessanter diese Problem...

JPsy
 
An ein Problem mit einem falschen Kernel habe ich auch schon gedacht. Wie ich ja schon sagte, war auf dem Server ursprünglich SUSE 9.3/64 drauf und ich habe mittels apt SUSE 10.0/64 darüber installiert. Hatte scheinbar auch alles wunderbar geklappt. Das Zeitproblem habe ich leider erst mitbekommen, als der Server schon online war.

Momentan sieht es in /boot so aus:
Code: 
  25116 2005-10-30 23:31 config-2.6.14-051030b
  25116 2005-11-15 13:03 config-2.6.14-051115a
  25116 2005-12-07 12:11 config-2.6.14.3-051207a
  21374 2005-09-23 07:59 config-amd64-2.6.12.4-sis190-050808a
1003105 2005-10-30 23:40 System.map-2.6.14-051030b
1028384 2005-11-15 13:13 System.map-2.6.14-051115a
1032636 2005-12-07 12:20 System.map-2.6.14.3-051207a
     24 2006-01-27 17:31 vmlinuz -> vmlinuz-2.6.14.3-051207a
1858828 2005-10-30 23:40 vmlinuz-2.6.14-051030b
1917140 2005-11-15 13:13 vmlinuz-2.6.14-051115a
1923627 2005-12-07 12:20 vmlinuz-2.6.14.3-051207a
2248505 2005-09-23 07:56 vmlinuz-amd64-2.6.12.4-sis190-050808a

Aktiv ist also vmlinuz-2.6.14.3-051207a. Wo der her kommt, weiß ich gar nicht so genau, da bei SUSE 10.0/apt doch eigentlich nur 2.6.13er drin sind und ich kernel-of-the-day nicht mit eingebunden habe. vmlinuz-amd64-2.6.12.4-sis190 ist vermutlich der Original-Kernel, da in den 1und1 Rootservern ein SiS-Controler drin ist.

Soll ich mal versuchen, mit dem Original-Kernel zu booten? Mein Problem ist halt, dass das der Server schon live ist und ich mir da jetzt keine großen Ausfallzeiten mehr leisten kann.
 
netspy said:
Mein Problem ist halt, dass das der Server schon live ist und ich mir da jetzt keine großen Ausfallzeiten mehr leisten kann.
Click to expand...
Glaubst Du das Zeitproblem wäre besser? ;)
Die Recory-Console von 1und1 ist ganz in Ordnung.
Du kannst also einmal den Kernel umschalten und zurück switchen innerhalb von ca. 20 Minuten wenn Du weißt was Du tust.

huschi.
 
Huschi said:
Glaubst Du das Zeitproblem wäre besser? ;)
Click to expand...
Na ja, außer Problemen mit meiner Statistik und einem heiß laufenden Cronjob ist es erst mal nicht so tragisch.

Nun mal zur Absicherung, zum Testen reicht es doch, wenn ich in der lilo.conf jetzt folgendes ändere / ergänze...

Code: 
default=amd64

...

image=/boot/vmlinuz-amd64-2.6.12.4-sis190-050808a
        label=amd64
        append="console=tty0 console=ttyS0,57600 panic=30

... und lilo aufrufe?
 
IMHO ist es besser den aktuell laufenden Kernel erst mal als default zu lassen und mit "lilo -R amd64" den zu testenden Kernel nur einmalig bei nächsten Reboot zu starten. Wenn der funktioniert kannst du den Defaultwert anpassen (lilo aufrufen nicht vergessen), wenn nicht reicht ein reboot oder 30 Sekunden Wartezeit nach der Kernelpanic aus damit dein alter Kernel wieder startet. Damit mußt du nicht auf die Rettungskonsole warten wenn was schief läuft :)
 
HornOx said:
IMHO ist es besser den aktuell laufenden Kernel erst mal als default zu lassen und mit "lilo -R amd64" den zu testenden Kernel nur einmalig bei nächsten Reboot zu starten.
Click to expand...
Danke für den Tipp. Heute Nacht werde ich es dann mal damit versuchen.

ps: kennt jemand eine fertige Kernel-Config für 1und1 Rootserver? Im RootForum.de habe ich schon was in der Art gefunden aber so ganz sicher bin ich mir da nicht. Ansonsten muss ich dort mal nachfragen.
 
netspy said:
...
Ansonsten muss ich dort mal nachfragen.
...
Click to expand...

Hmmm, viel Glück - habe bisher kein arroganteres Forum gesehen (bzw. User/Mods/Admins) als im Rootforum, da kommt man sich vor als dürfe man nur als Profi fragen stellen - und als Profi brauch ich wohl kaum noch ein Forum...


...bin froh das ich hierher gefunden habe.

Sry wegen Offtopic... cya JPsy
 
Habe heute Nacht mal den Original-Kernel gebootet und nachdem alles gut aussah als Default-Kernel eingetragen. Leider war doch nicht alles so gut wie ich dachte. Offenbar bricht der Server jetzt unter Last sofort zusammen und endet dann mit einer Kernel-Panic. Ich hatte ihn ca. 2 Uhr gebootet und ca. 8 Uhr (als der Betrieb anfing) fingen auch die Panic an. Auf der seriellen Konsole (in warn steht weniger) sieht das so aus:
Code: 
PGD 0 
Oops: 0000 [7] SMP 
CPU 1 
Pid: 2710, comm: httpd2-prefork Not tainted 2.6.12.4-sis190-050808a
RIP: 0010:[<ffffffff8015bbaf>] <ffffffff8015bbaf>{set_slab_attr+95}
RSP: 0018:ffff81011ff9b9b0  EFLAGS: 00010093
RAX: ffffffff7fffffff RBX: ffff810107d2a080 RCX: 0000000000000018
RDX: ffff810107d2a000 RSI: ffff810107d2a080 RDI: ffff81011ffb0480
RBP: ffff81011ffb0480 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff810107d2a000
R13: 0000000000000080 R14: ffff81011ffb0528 R15: 0000000000000003
FS:  00002aaaac207a00(0000) GS:ffffffff8061e2c0(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000025b0 CR3: 0000000109760000 CR4: 00000000000006e0
Process httpd2-prefork (pid: 2710, threadinfo ffff8101097ac000, task ffff81010960e2f0)
Stack: ffffffff8015bd03 0000002000000000 000000000000001b ffff81011fe38a00 
       ffff81011ffb0480 ffff81011ffb04c8 ffff81011ffb0528 0000000000000020 
       ffffffff8015bf2b 0000000000000000 

Call Trace: <IRQ> <ffffffff8015bd03>{cache_grow+243} <ffffffff8015bf2b>{cache_alloc_refill+427}
       <ffffffff8015c216>{kmem_cache_alloc+54} <ffffffff803af32f>{dst_alloc+47}
       <ffffffff803bdafc>{ip_route_output_slow+1260} <ffffffff80272d4e>{strlcpy+78}
       <ffffffff803b5efd>{nf_hook_slow+125} <ffffffff803bde29>{ip_route_output_flow+41}
       <ffffffff803d997b>{tcp_v4_route_req+251} <ffffffff803eff01>{__ip_conntrack_find+17}
       <ffffffff803f8147>{ip_nat_used_tuple+39} <ffffffff803d9a48>{tcp_v4_send_synack+40}
       <ffffffff80280bcf>{secure_tcp_sequence_number+111} <ffffffff803d9fe8>{tcp_v4_conn_request+1160}
       <ffffffff803d2541>{tcp_rcv_state_process+129} <ffffffff803da78b>{tcp_v4_do_rcv+187}
       <ffffffff803dad6a>{tcp_v4_rcv+1402} <ffffffff803bf4b5>{ip_local_deliver+389}
       <ffffffff803bfa13>{ip_rcv+1139} <ffffffff8040dab0>{packet_rcv_spkt+608}
       <ffffffff803abbde>{netif_receive_skb+366} <ffffffff802e3e71>{tg3_rx+833}
       <ffffffff802e4013>{tg3_poll+163} <ffffffff803abde6>{net_rx_action+134}
       <ffffffff80139f31>{__do_softirq+113} <ffffffff80139fe5>{do_softirq+53}
       <ffffffff8010e1d7>{apic_timer_interrupt+99}  <EOI> <ffffffff80417071>{__down_read+49}
       <ffffffff80417071>{__down_read+49} <ffffffff801329ff>{mm_release+47}
       <ffffffff8013701f>{exit_mm+63} <ffffffff80137aa7>{do_exit+327}
       <ffffffff8010f245>{die+69} <ffffffff8010f6bf>{do_invalid_op+159}
       <ffffffff801581db>{free_pages+267} <ffffffff80165110>{handle_mm_fault+304}
       <ffffffff80272991>{__up_read+33} <ffffffff80120589>{do_page_fault+601}
       <ffffffff8015734a>{prep_new_page+90} <ffffffff8010e329>{error_exit+0}
       <ffffffff801581db>{free_pages+267} <ffffffff8018fff1>{sys_getcwd+529}
       <ffffffff8010d92a>{system_call+126} 

Code: 49 8b 89 b0 25 00 00 76 07 b8 00 00 00 80 eb 0a 48 b8 00 00 
RIP <ffffffff8015bbaf>{set_slab_attr+95} RSP <ffff81011ff9b9b0>
CR2: 00000000000025b0
 <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
 <0>Rebooting in 30 seconds..

Neu gebootet hat er aber nicht. Nach einem Booten über das 1unu1 Interface lief der Server nur ein paar Sekunden und brach dann wieder zusammen.

Einmal habe ich auch diese Meldung gesehen:

Code: 
Kernel BUG at "mm/page_alloc.c":972
invalid operand: 0000 [1] SMP

In warn steht diese Zeile auch öfters drin:

Code: 
kernel: Pid: 2677, comm: httpd2-prefork Not tainted 2.6.12.4-sis190-050808a

Kann da der für SUSE 10.0 kompilierte Apache evtl. nicht mit dem Kernel für SUSE 9.3 zusammenarbeiten oder ist das nur Zufall, weil der Apache halt am meisten gefordert wir? Mit dem Kernel für SUSE 10.0 läuft der Server erst mal wieder, hat aber auch wieder das ursprüngliche Problem mit der falschen Zeit.

Irgendwie habe ich immer mehr einen Hardwarefehler im Verdacht, was natürlich sehr bitter wäre.
 
So, nach langem Googlen habe ich noch die Kernel-Parameter clock=pmtmr (Uhr über Power-Management) und clock=pit (???) gefunden. Damit scheint das Problem jetzt wirklich halbwegs behoben zu sein (ist egal, welchen Parameter man nimmt). Die Uhr läuft zwar nicht sonderlich genau (ca. 1 sek/min) aber damit kann ich leben.

Falls jemandem noch eine bessere Lösung einfallen sollte oder sogar den genauen Grund für das Zeitproblem auf einem Dual Core AMD Opteron 175 kennt, kann er das gerne noch posten. Ansonsten danke ich schon mal allen, die hier geholfen haben.

Netspy
 
netspy said:
So, nach langem Googlen habe ich noch die Kernel-Parameter clock=pmtmr (Uhr über Power-Management) und clock=pit (???) gefunden.
Click to expand...
Welchen Parameter nutzt Du denn jetzt? pmtmr oder pit?
(PIT = Programmable Interrupt Timer)
PIT sollte eigendlich die selben Probleme wie der default-Wert TSC machen, da es um den selben Interupt-Tick geht. TSC approximiert lediglich die Zeitspanne zwischen den Ticks um eine genauere Zeit (bis zu millisekunden) zu erhalten.

PS:
Natürlich: Gratulation!!!

huschi.
 
Last edited by a moderator:
Huschi said:
Welchen Parameter nutzt Du denn jetzt? pmtmr oder pit?
(PIT = Programmable Interrupt Timer)
Click to expand...
Hab beide ausprobiert und bei beiden ähnliche Abweichungen festgestellt. Momentan nutze ich pmtmr, da dies wie es scheint ein klein wenig genauer ist. Momentan beträgt da die Abweichung 5 Sekunden bei 20 Minuten.

Huschi said:
PIT sollte eigendlich die selben Probleme wie der default-Wert TSC machen, da es um den selben Interupt-Tick geht. TSC approximiert lediglich die Zeitspanne zwischen den Ticks um eine genauere Zeit (bis zu millisekunden) zu erhalten.
Click to expand...
Wahrscheinlich ist ja aber die approximierte Zeitspanne für die extreme Abweichung verantwortlich, weshalb PIT nicht diese Zeitsprünge mit sich bringt.
 
kernel-of-the-day

Laut 1und1 Support kommt das Zeitproblem vom Kernel und soll in 2.6.16rc5 behoben sein. Nun wollte ich den über apt aus kernel-of-the-day installieren, komme da aber irgendwie nicht zurecht. Ich hab zwar schon einige Anleitungen gefunden aber das funktioniert alles nicht. kernel-of-the-day habe ich in die sources.list eingetragen aber ich kann machen was ich will, die 2.6.16rc5 wird einfach nicht installiert.

Ich will jetzt kein extra Thread aufmachen aber kann mir jemand kurz erklären, wie ich am einfachsten einen neuen Kernel installiere (meine alter soll aber zur Sicherheit noch drauf bleiben)?
 
Kernel 2.6.16rc5

FYI: kernel-of-the-day funktioniert nicht mit SUSE 10.0, da dort zu viele unlösbare Abhängigkeiten in den Paketen sind. Hab mir den Kernel 2.6.16rc5 jetzt selber kompiliert und damit ist das Zeitproblem jetzt gelöst. :)
 
You must log in or register to reply here.
Back
Top