(hm, google says i'm not the only one seeing this, so...)
On Sun, 2007-03-18 at 00:32 +0100, Thomas Gleixner wrote:
> Maxim,
>
> On Sun, 2007-03-18 at 01:00 +0200, Maxim wrote:
> > >Mar 14 00:22:23 MAIN kernel: [ 2.072931] checking TSC synchronization [CPU#0 -> CPU#1]:
> > >Mar 14 00:22:23 MAIN kernel: [ 2.092922] Measured 72051818872 cycles TSC warp between CPUs, turning off
> >
> > ^ This one I don't think is related to NO_HZ, maybe it is hardware
> > problem, but it exist without NO_HZ
>
> The TSC is checked for synchronization between the CPUs. It's nothing to
> worry about. We switch off the TSC and use a different clocksource.
>
> Is this after resume ? If yes, then something (probably BIOS) is
> fiddling with the TSC of one CPU when the resume happens.
My P4 box has the same "problem", which is remedied by..
diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c
index 9125efe..7b74969 100644
--- a/arch/x86/kernel/tsc_sync.c
+++ b/arch/x86/kernel/tsc_sync.c
@@ -46,7 +46,7 @@ static __cpuinit void check_tsc_warp(void)
cycles_t start, now, prev, end;
int i;
- start = get_cycles_sync();
+ start = last_tsc = get_cycles_sync();
/*
* The measurement runs for 20 msecs:
*/
..whacking the ancient last_tsc before entering test loop. Question is,
is there a good reason to disable the TSC once it's been stepped upon by
BIOS? Are there any ill effects to be awaited by ignoring this BIOS
artifact? All seems just fine here.
-Mike
--
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
