Re: huge clock drift?
Le Thu, Jul 07, 2005 at 11:15:10PM +0200, Kurt Roeckx écrivait/wrote:
> On Thu, Jul 07, 2005 at 10:52:12PM +0200, Basile STARYNKEVITCH wrote:
> > Hello
> > On my new MSI S270 with a Turion, self-compiled kernel 2.6.13-rc2, the
> > clock (as reported by date, ie gettimeofday call) is drifting
> > consuderably: in less than 7 hours, the date (an ntpdate is setting it
> > at boot time) has drifted by -12758 seconds
> Which is about 3.5 hours. It looks like your clock goes 50% too
> > But the hardware clock (as reported by hwclock) is still right.
> > The cpu frequency is adjusted by cpufreqd
> So I guess the clock runs at half the speed? This looks like a
> kernel bug to me.
Actually, it is. The clock has a double rate. Apparently, the irq line
for clock is shared by IO-APIC-edge
% rdate -p hector; grep timer /proc/interrupts; sleep 30; \
rdate -p hector; grep timer /proc/interrupts
Sun 10 Jul 2005 11:40:50 AM CEST
0: 2309959 IO-APIC-edge timer
Sun 10 Jul 2005 11:41:05 AM CEST
0: 2339979 IO-APIC-edge timer
As you can see, for a 30 seconds sleep asked, 30020 (about 30K) timer
interrupts have been processed, which is consistent with a 1000 HZ
tick rate, but the actual time (as gotten by rdate on hector, my
desktop PC on the same nearly silent ethernet network) elapsed was 15
This seems to be a known bug for ATI200 chipset:
similar to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152630
Apparently, the bug appears on every 2.6 (from 2.6.9 to 2.6.13-rc2)
kernel I use, both debian-image or compiled by me.
booting with 'noapic' on the command line will be an acceptable
workaround for now. http://lkml.org/lkml/2005/4/6/206 might be a
patch... I did not tested it yet.
BTW, did you notice that
is an empty patch (bunzip2 it and you get an empty file)?
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
8, rue de la Faïencerie, 92340 Bourg La Reine, France