On Fri, 7 Dec 2007, Stefano Brivio wrote: > This patch fixes a regression introduced by: > > commit bb29ab26863c022743143f27956cc0ca362f258c > Author: Ingo Molnar <[EMAIL PROTECTED]> > Date: Mon Jul 9 18:51:59 2007 +0200 > > This caused the jiffies counter to leap back and forth on cpufreq changes > on my x86 box. I'd say that we can't always assume that TSC does "small > errors" only, when marked unstable. On cpufreq changes these errors can be > huge.
Hmrpf. sched_clock() is used for the time stamp of the printks. We need to find some better solution other than killing off the tsc access completely. Ingo ??? Thanks, tglx > The original bug report can be found here: > http://bugzilla.kernel.org/show_bug.cgi?id=9475 > > > Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]> > > --- > > diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c > index 9ebc0da..d29cd9c 100644 > --- a/arch/x86/kernel/tsc_32.c > +++ b/arch/x86/kernel/tsc_32.c > @@ -98,13 +98,8 @@ unsigned long long native_sched_clock(void) > > /* > * Fall back to jiffies if there's no TSC available: > - * ( But note that we still use it if the TSC is marked > - * unstable. We do this because unlike Time Of Day, > - * the scheduler clock tolerates small errors and it's > - * very important for it to be as fast as the platform > - * can achive it. ) > */ > - if (unlikely(!tsc_enabled && !tsc_unstable)) > + if (unlikely(!tsc_enabled)) > /* No locking but a rare wrong value is not a big deal: */ > return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ); > > > -- > Ciao > Stefano > -- 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/