My Toshiba laptop (running stock Red Hat 7.2, kernel 2.4.7-10)
appears to suffer from a power management-related time hiccup: when
I boot in low-power mode, then switch to high-power mode,
time goes backwards by 10ms several times a second.
According to the thread
Subject: [PATCH]: allow notsc option for buggy cpus
From: Anton Blanchard <[email protected]>
Date: 2001-03-10 0:58:29
http://marc.theaimsgroup.com/?l=linux-kernel&m=98418670406359&w=2
this can be fixed by disabling the TSC option, but there
ought to be a runtime fix. Was a runtime fix ever put
together for this situation?
FWIW, the system is a Toshiba Satellite 2805, and /proc/cpuinfo reports
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 746.342
cache size : 256 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 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 1490.94
when booted in high power mode; when booted in low power mode,
/proc/cpuinfo changes as follows:
7c7
< cpu MHz : 746.342
---
> cpu MHz : 383.295
18c18
< bogomips : 1490.94
---
> bogomips : 750.38
- Dan
p.s. there were three other (unresolved?) threads about similar
time problems, but I don't think I'm suffering from these.
Subject: gettimeofday question
From: Russell King <[email protected]>
Date: 2001-03-03 12:49:04
http://marc.theaimsgroup.com/?l=linux-kernel&m=98362388532220&w=2
Subject: 40ms/10ms error in do_gettimeofday()
From: Bernard Imbert <[email protected]>
Date: 2000-04-04 10:15:57
http://marc.theaimsgroup.com/?l=linux-kernel&m=95484334731324&w=2
Subject: problems with do_slow_gettimeoffset()
From: Jason Sodergren <[email protected]>
Date: 2000-03-30 22:35:36
http://marc.theaimsgroup.com/?l=linux-kernel&m=95445682624501&w=2
On Sun, Feb 17, 2002 at 08:34:20AM -0800, Dan Kegel wrote:
> My Toshiba laptop (running stock Red Hat 7.2, kernel 2.4.7-10)
> appears to suffer from a power management-related time hiccup: when
> I boot in low-power mode, then switch to high-power mode,
> time goes backwards by 10ms several times a second.
> According to the thread
> Subject: [PATCH]: allow notsc option for buggy cpus
> From: Anton Blanchard <[email protected]>
> Date: 2001-03-10 0:58:29
> http://marc.theaimsgroup.com/?l=linux-kernel&m=98418670406359&w=2
> this can be fixed by disabling the TSC option, but there
> ought to be a runtime fix. Was a runtime fix ever put
> together for this situation?
All the IBM thinkpads we have in the office have exactly this problem.
The major symptom is that ALT-TAB goes wrong in the sawfish window
manager oddly!
I made a patch to fix this (this is its first outing). It stops
do_gettimeofday reporting a time less than it reported last time.
This isn't fixing the root cause of the problem which is interactions
between the BIOS power management and the kernel I believe, but it
does fix the problem and is really quite cheap so perhaps might be
appropriate for the main kernel.
I'd be interested to know if it fixes your problem too!
--- linux/arch/i386/kernel/time.c.orig Sat Dec 22 10:08:04 2001
+++ linux/arch/i386/kernel/time.c Wed Jan 23 09:14:56 2002
@@ -28,6 +28,10 @@
* 1998-12-24 Copyright (C) 1998 Andrea Arcangeli
* Fixed a xtime SMP race (we need the xtime_lock rw spinlock to
* serialize accesses to xtime/lost_ticks).
+ * 2002-01-22 Nick Craig-Wood
+ * Fix do_gettimeofday so that the time offset definitely won't
+ * cause the clock to go backwards as observed previously on IBM
+ * thinkpads with variable clock rate
*/
#include <linux/errno.h>
@@ -267,9 +271,23 @@
{
unsigned long flags;
unsigned long usec, sec;
+ static unsigned long old_usec;
+ static unsigned long old_jiffies = ~1UL;
read_lock_irqsave(&xtime_lock, flags);
usec = do_gettimeoffset();
+ /* make sure we don't let the time offset go backwards to fix
+ machines with variable clock rates like the IBM thinkpad -
+ Nick Craig-Wood */
+ if (jiffies == old_jiffies) {
+ if (usec < old_usec)
+ usec = old_usec;
+ else
+ old_usec = usec;
+ } else {
+ old_jiffies = jiffies;
+ old_usec = usec;
+ }
{
unsigned long lost = jiffies - wall_jiffies;
if (lost)
--
Nick Craig-Wood
[email protected]
> This isn't fixing the root cause of the problem which is interactions
> between the BIOS power management and the kernel I believe, but it
> does fix the problem and is really quite cheap so perhaps might be
do_gettimeofday is still going to give strange results - and consider
the case where you boot slow and speed up...
If you can give me the DMI strings for the affected boxes I can add
them to the DMi tables (see ftp://ftp.linux.org.uk/pub/linux/alan/DMI*)
Nick Craig-Wood wrote:
>
> On Sun, Feb 17, 2002 at 08:34:20AM -0800, Dan Kegel wrote:
> > My Toshiba laptop (running stock Red Hat 7.2, kernel 2.4.7-10)
> > appears to suffer from a power management-related time hiccup: when
> > I boot in low-power mode, then switch to high-power mode,
> > time goes backwards by 10ms several times a second.
> > According to the thread
> > Subject: [PATCH]: allow notsc option for buggy cpus
> > From: Anton Blanchard <[email protected]>
> > Date: 2001-03-10 0:58:29
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=98418670406359&w=2
> > this can be fixed by disabling the TSC option, but there
> > ought to be a runtime fix. Was a runtime fix ever put
> > together for this situation?
>
> All the IBM thinkpads we have in the office have exactly this problem.
> The major symptom is that ALT-TAB goes wrong in the sawfish window
> manager oddly!
>
> I made a patch to fix this (this is its first outing). It stops
> do_gettimeofday reporting a time less than it reported last time.
I see a minor problem here...what happens if you want to reset your clock (for
whatever purpose) to a previous time?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
Alan Cox wrote:
>
> > This isn't fixing the root cause of the problem which is interactions
> > between the BIOS power management and the kernel I believe, but it
> > does fix the problem and is really quite cheap so perhaps might be
>
> do_gettimeofday is still going to give strange results - and consider
> the case where you boot slow and speed up...
>
> If you can give me the DMI strings for the affected boxes I can add
> them to the DMi tables (see ftp://ftp.linux.org.uk/pub/linux/alan/DMI*)
ftp://ftp.linux.org.uk/pub/linux/alan/DMI/dmidecode.c works properly
on my desktop machine, but on the affected laptop it just repeatedly
prints out
DMI 2.3 present.
44 structures occupying 1330 bytes.
DMI table at 0x17FF0000.
dmi: read: Illegal seek
and doesn't say anything interesting. Both machines are running
vanilla Red Hat 7.2, I think. Shall I try it with vanilla 2.4.18-rc1?
- Dan
> DMI 2.3 present.
> 44 structures occupying 1330 bytes.
> DMI table at 0x17FF0000.
> dmi: read: Illegal seek
Eep I don't deal with DMI tables that high in memory.
On Mon, Feb 18, 2002 at 04:54:23PM -0500, Chris Friesen wrote:
> Nick Craig-Wood wrote:
> > I made a patch to fix this (this is its first outing). It stops
> > do_gettimeofday reporting a time less than it reported last time.
>
> I see a minor problem here...what happens if you want to reset your clock (for
> whatever purpose) to a previous time?
Sorry that was a simplified explanation above. If you examine the
patch you'll see that it can only change the time by < 1 jiffy (10ms).
However this is the interval wrongly estimated by the CPU's timer
(because the laptop's clock rate is not what the kernel thinks it is).
Ie, shouldn't be a problem.
--
Nick Craig-Wood
[email protected]
Nick Craig-Wood wrote:
>
> On Mon, Feb 18, 2002 at 04:54:23PM -0500, Chris Friesen wrote:
> > Nick Craig-Wood wrote:
> > > I made a patch to fix this (this is its first outing). It stops
> > > do_gettimeofday reporting a time less than it reported last time.
> >
> > I see a minor problem here...what happens if you want to reset your clock (for
> > whatever purpose) to a previous time?
>
> Sorry that was a simplified explanation above.
Ooops, my bad (should've read the patch more closely). Time offsets can't go
backwards if jiffies stays the same. As long as jiffies is changed, then the
patch has no effect. Got it.
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Mon, Feb 18, 2002 at 09:50:44PM +0000, Alan Cox wrote:
> > This isn't fixing the root cause of the problem which is interactions
> > between the BIOS power management and the kernel I believe, but it
> > does fix the problem and is really quite cheap so perhaps might be
>
> do_gettimeofday is still going to give strange results - and consider
> the case where you boot slow and speed up...
This isn't a perfect fix certainly. Stopping time going backwards
stops the major application breakage though.
> If you can give me the DMI strings for the affected boxes I can add
> them to the DMi tables (see ftp://ftp.linux.org.uk/pub/linux/alan/DMI*)
[sent via private email]
--
Nick Craig-Wood
[email protected]