Hi again, Now it happened again, with my newly compiled kernel, I've attached the config file and dmesg for this kernel. Watching the /proc/interrupts with 10s apart after the "stop". [root@s151 root]# more /proc/interrupts CPU0 0: 66413955 local-APIC-edge timer 2: 0 XT-PIC cascade 9: 1 IO-APIC-level acpi 10: 0 IO-APIC-level ohci_hcd 14: 24 IO-APIC-edge ide0 20: 31244 IO-APIC-level aic7xxx 22: 19641795 IO-APIC-level eth0 NMI: 0 LOC: 67355837 ERR: 0 MIS: 0 [root@s151 root]# more /proc/interrupts CPU0 0: 66413955 local-APIC-edge timer 2: 0 XT-PIC cascade 9: 1 IO-APIC-level acpi 10: 0 IO-APIC-level ohci_hcd 14: 24 IO-APIC-edge ide0 20: 31244 IO-APIC-level aic7xxx 22: 19652139 IO-APIC-level eth0 NMI: 0 LOC: 67379568 ERR: 0 MIS: 0 And some 10-15 min later: [root@s151 root]# cat /proc/interrupts CPU0 0: 66413964 local-APIC-edge timer 2: 0 XT-PIC cascade 9: 1 IO-APIC-level acpi 10: 0 IO-APIC-level ohci_hcd 14: 24 IO-APIC-edge ide0 20: 31245 IO-APIC-level aic7xxx 22: 19754446 IO-APIC-level eth0 NMI: 0 LOC: 68366976 ERR: 0 MIS: 0 Last vmstat (and /proc/loadavg intermixed): (Rows like 3.48 1.70 2.12 2/114 13232 are loadavg, the other are linewrapped vmstats.) procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 0 686752 48412 59104 0 0 0 0 2112 898 19 1 80 3.48 1.70 2.12 2/114 13232 0 0 0 0 686832 48412 59104 0 0 0 0 2093 688 12 1 87 0 0 0 0 686768 48416 59104 0 0 0 140 1623 998 15 1 84 3.20 1.67 2.11 2/114 13235 0 0 0 0 686848 48416 59104 0 0 0 0 2128 960 16 1 83 3.20 1.67 2.11 2/114 13238 0 0 0 0 686912 48416 59104 0 0 0 0 1597 809 11 1 88 0 0 0 0 686880 48420 59104 0 0 0 22 2164 959 13 1 86 2.94 1.64 2.09 2/114 13241 0 0 0 0 686816 48420 59104 0 0 0 0 2089 748 14 1 85 2.94 1.64 2.09 2/114 13244 0 0 0 0 686640 48420 59104 0 0 0 0 2465 1170 20 21 59 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 0 649904 48420 59104 0 0 0 24 87091 90759 29 66 5 2.87 1.65 2.09 3/114 13247 Worth noticing is the extreme increase in interrupts and context switches on the last output line from vmstat, however if this is a true picture of what happened or not I cannot say. Maybe this is just a result of timing problems? However I see an increase in network activity just before the stop, the system goes from 2 Mbps output to about 55 Mbps on the last read. (Also read from this machine so I don't know about it's validity) cpuinfo, if useful is: [root@s151 root]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping : 9 cpu MHz : 2800.731 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips : 5505.02 Where can I see what the system is currently using as a timing source (TSC/HPET/PIT etc.)? Cheers, Niclas fre 2004-04-09 klockan 00.58 skrev john stultz: > On Thu, 2004-04-08 at 02:21, Niclas Gustafsson wrote: > > Hi, > > > > I'm running Linux 2.6.5 on a IBM xSeries 305 with a Intel P4 2.8Ghz. > > > > And something is very very wrong, I'm getting the following last > > messages in dmesg: > > > > ------ > > set_rtc_mmss: can't update from 52 to 0 > > set_rtc_mmss: can't update from 53 to 1 > > set_rtc_mmss: can't update from 54 to 2 > > set_rtc_mmss: can't update from 55 to 3 > > set_rtc_mmss: can't update from 56 to 4 > > set_rtc_mmss: can't update from 57 to 5 > > set_rtc_mmss: can't update from 58 to 6 > > Losing too many ticks! > > TSC cannot be used as a timesource. <4>Possible reasons for this are: > > You're running with Speedstep, > > You don't have DMA enabled for your hard disk (see hdparm), > > Incorrect TSC synchronization on an SMP system (see dmesg). > > ------ > > > > The problem seesm to be related to heavy loads. > > I experienced a similar problem yesterday. The machine completly hung > > after that and i had to cut the power to reboot it. Now however it is > > responsive and I can log on to it through ssh. > > > > Problem is that the clock stopped completly! - I've never seen anything > > like this before. > > > > Local time is about 11 am here and a time gives me: > > > > [root@s151 root]# date > > Thu Apr 8 03:51:21 CEST 2004 > > > > ...10 s later, using my wristwatch, not sleep 10 ;) > > > > [root@s151 root]# date > > Thu Apr 8 03:51:21 CEST 2004 > > > > > > Any ideas anyone, I'd really like to know why it is behaving this way. > > Huh. Very very odd. > > Does /proc/interrupts show timer ticks increasing? > Does setting the date change anything? > > Would you mind sending me your complete dmesg? > > I'll look into reproducing the error here if you can give me a better > description of what triggers it and how frequently you see the problem. > > thanks > -john > > >