Hi,
we have a computer here, that behaves very strange, from one second to
another the clock changes to about 1h in the future. In the next "real"
second the time is normal again.
Well, I first thought that is might be a X problem, but after running a loop
over "date", it really seems that the system clock is affected. Then I
thought it might be a conflict with the hardware clock, but after resetting
it to the system time, the problem was still there.
The only clock that doesn't seem to be affected is the realtime clock (at
least not when doing a loop of cat over the proc-file).
The problem is, that this time jumps cause the Xserver to enable its
screensaver (and several other small problems).
System is: Athlon 650 on VIA board with linux-2.4.17 (unpatched)
So has anyone an idea what to do, I'm thinking about a BIOS update (but don't
really believe that it will help). Or is it possible to patch the kernel that
it uses the realtime clock (could anyone of you send me this patch, if it is
possible, please??).
Of course, I can give further information, if needed.
Thanks in advance, Bernd
On Wed, 27 Mar 2002, Bernd Schubert wrote:
> Hi,
>
> we have a computer here, that behaves very strange, from one second to
> another the clock changes to about 1h in the future. In the next "real"
> second the time is normal again.
> Well, I first thought that is might be a X problem, but after running a loop
> over "date", it really seems that the system clock is affected. Then I
> thought it might be a conflict with the hardware clock, but after resetting
> it to the system time, the problem was still there.
>
> The only clock that doesn't seem to be affected is the realtime clock (at
> least not when doing a loop of cat over the proc-file).
>
> The problem is, that this time jumps cause the Xserver to enable its
> screensaver (and several other small problems).
>
> System is: Athlon 650 on VIA board with linux-2.4.17 (unpatched)
>
The same thing happened to me on an Athlon 600 on a KM133 chipset.
I ran a vanilla 2.4.18 and after upgrading to 2.4.19 the problem never
occured again.
Hope it helps for you to!
Cheers!
/Adam @ MadSci.se
> So has anyone an idea what to do, I'm thinking about a BIOS update (but don't
> really believe that it will help). Or is it possible to patch the kernel that
> it uses the realtime clock (could anyone of you send me this patch, if it is
> possible, please??).
>
>
> Of course, I can give further information, if needed.
>
> Thanks in advance, Bernd
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-=-=-=-=-=-=-=-=-=-=-=-=-
Adam Johansson
Developer @ MadSci AB
Phone: +46 (0)18 606462
ICQ: 58187935
http://www.madsci.se
-=-=-=-=-=-=-=-=-=-=-=-=-
>
> The same thing happened to me on an Athlon 600 on a KM133 chipset.
> I ran a vanilla 2.4.18 and after upgrading to 2.4.19 the problem never
> occured again.
>
> Hope it helps for you to!
>
> Cheers!
> /Adam @ MadSci.se
>
Hello Adam,
thank you very much for your help. Though I don't like using pre-kernels
I'll make an exception on this time.
Thanks again,
Bernd
Adam Johansson <[email protected]> wrote:
> The same thing happened to me on an Athlon 600 on a
> KM133 chipset.
> I ran a vanilla 2.4.18 and after upgrading to 2.4.19
> the problem never
> occured again.
I have expirienced those strange screensaver
activations
with 2.4.19-pre2-ac4 as well. I don't know about my
system clock, but I've never send it much attention
anyhow.
Regards,
Jim
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Ihre E-Mail noch individueller? - http://domains.yahoo.de
There is a hardware bug on some via 686a systems where the RTC appears
automagically change it's programmed value.
A patch was originally made against 2.4.2, and some version of this
appears to be applied to current kernels (I don't have a vanilla
2.4.17 to check against). Look in arch/i386/kernel/time.c for mention
of 686a.
It appears to only be used if the kernel's not compiled with
CONFIG_X86_TSC though, so if you have that defined you may not see the
problem at all...
Mark
On Wed, 27 Mar 2002, Bernd Schubert wrote:
> Date: Wed, 27 Mar 2002 16:28:35 +0100
> From: Bernd Schubert <[email protected]>
> To: [email protected]
> Subject: time jumps
>
> Hi,
>
> we have a computer here, that behaves very strange, from one second to
> another the clock changes to about 1h in the future. In the next "real"
> second the time is normal again.
> Well, I first thought that is might be a X problem, but after running a loop
> over "date", it really seems that the system clock is affected. Then I
> thought it might be a conflict with the hardware clock, but after resetting
> it to the system time, the problem was still there.
>
> The only clock that doesn't seem to be affected is the realtime clock (at
> least not when doing a loop of cat over the proc-file).
>
> The problem is, that this time jumps cause the Xserver to enable its
> screensaver (and several other small problems).
>
> System is: Athlon 650 on VIA board with linux-2.4.17 (unpatched)
>
>
> So has anyone an idea what to do, I'm thinking about a BIOS update (but don't
> really believe that it will help). Or is it possible to patch the kernel that
> it uses the realtime clock (could anyone of you send me this patch, if it is
> possible, please??).
>
>
> Of course, I can give further information, if needed.
>
> Thanks in advance, Bernd
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
+-------------------------------------------------------------------------+
Mark Cooke The views expressed above are mine and are not
Systems Programmer necessarily representative of university policy
University Of Birmingham URL: http://www.sr.bham.ac.uk/~mpc/
+-------------------------------------------------------------------------+
On Wednesday 27 March 2002 18:33, Mark Cooke wrote:
> There is a hardware bug on some via 686a systems where the RTC appears
> automagically change it's programmed value.
>
> A patch was originally made against 2.4.2, and some version of this
> appears to be applied to current kernels (I don't have a vanilla
> 2.4.17 to check against). Look in arch/i386/kernel/time.c for mention
> of 686a.
>
> It appears to only be used if the kernel's not compiled with
> CONFIG_X86_TSC though, so if you have that defined you may not see the
> problem at all...
>
> Mark
>
Ah, thank you very much. I'll try this first.
Thanks, Bernd
Hi,
after changing from 'CONFIG_X86_TSC=n' to 'CONFIG_X86_TSC=y' the problem
still exists, so I'm going to try some other suggestions.
But nevertheless, thanks for your help,
Bernd
On Wednesday 27 March 2002 18:33, Mark Cooke wrote:
> There is a hardware bug on some via 686a systems where the RTC appears
> automagically change it's programmed value.
>
> A patch was originally made against 2.4.2, and some version of this
> appears to be applied to current kernels (I don't have a vanilla
> 2.4.17 to check against). Look in arch/i386/kernel/time.c for mention
> of 686a.
>
> It appears to only be used if the kernel's not compiled with
> CONFIG_X86_TSC though, so if you have that defined you may not see the
> problem at all...
>
> Mark
On Wed, Apr 03, 2002 at 01:32:05PM +0200, Bernd Schubert wrote:
> after changing from 'CONFIG_X86_TSC=n' to 'CONFIG_X86_TSC=y' the problem
> still exists, so I'm going to try some other suggestions.
> On Wednesday 27 March 2002 18:33, Mark Cooke wrote:
> > There is a hardware bug on some via 686a systems where the RTC appears
> > automagically change it's programmed value.
> >
> > A patch was originally made against 2.4.2, and some version of this
> > appears to be applied to current kernels (I don't have a vanilla
> > 2.4.17 to check against). Look in arch/i386/kernel/time.c for mention
> > of 686a.
> >
> > It appears to only be used if the kernel's not compiled with
> > CONFIG_X86_TSC though, so if you have that defined you may not see the
> > problem at all...
The workaround below by Vojtech Pavlik has fixed this issue on my
system (I've a VIA based Abit KT7 and under heavy disk I/O between two
IDE channels the timer goes mad):
Re: [PATCH] VIA timer fix was removed?
From: Vojtech Pavlik ([email protected])
Date: Mon Nov 12 2001 - 16:58:32 EST
http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.1/0951.html
If you see the message in your logs then congratulations: you hit (one
of) the VIA bug(s) ;)
--
Best regards,
Pierre Lombard