lkml.org 
[lkml]   [2006]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Back to the Future ? or some thing sinister ?
Chaitanya Hazarey wrote:
>
> We have got a machine, lets say X , make is IBM and the CPU is Intel
> Pentium 4 2.60 GHz. Its running a 2.6.13.1 Kernel and previously,
> 2.6.27-4 Kernel the distribution is Debian Sagre.
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Pentium(R) 4 CPU 2.60GHz
> stepping : 9
> cpu MHz : 2591.888
> 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
> xtpr
> bogomips : 5188.79
>
>
>
>
> The problem is that, after a some time ( fuzzy , but I think like 2
> hours ) of inactivity or because of some esoteric factor which triggers
> a state in which the time on the machine starts going around in a loop.
> if I do cat /proc/uptime, it goes 4 ticks ahead and again rewinds back
> to the starting count ( not zero, but the moment in time when the event
> was triggred. )
>
> The problem seems to be specific to the 2.6 series of kernel, not the
> 2.4 series.
>
> I would like to know how to go about the debugging of the problem, and
> that which specific part of the kernel will be directly interacting with
> the rtc / system clock.

Look into upgrading the BIOS on that machine; I've had similar
problems on a IBM P4 workstation that were fixed in this way.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-09 05:05    [from the cache]
©2003-2011 Jasper Spaans