Messages in this thread | | | Date | Sun, 23 Jul 2006 04:46:37 -0700 | From | Andrew Morton <> | Subject | Re: REGRESSION: the new i386 timer code fails to sync CPUs |
| |
On Sun, 23 Jul 2006 10:16:04 +0200 Matthias Urlichs <smurf@smurf.noris.de> wrote:
> > Are you able to compare the present bootlog with the 2.6.17 bootlog? > > > Sure. The diff says: > > checking TSC synchronization across 4 CPUs: > +CPU#0 had 748437 usecs TSC skew, fixed it up. > +CPU#1 had 748437 usecs TSC skew, fixed it up. > +CPU#2 had -748437 usecs TSC skew, fixed it up. > +CPU#3 had -748437 usecs TSC skew, fixed it up. > Brought up 4 CPUs > -migration_cost=4000,8000 > +migration_cost=85,1724 > > ... but apparently, that skew is not corrected. > > These numbers do match the difference in observed "date" outputs.
From this I'll assume that
- CPU0 and CPU1 share a TSC and CPU2 and CPU3 share another TSC.
- write_tsc() simply doesn't work on this machine.
- Earlier kernels weren't able to modify the TSC either.
- Earlier kernels didn't use the TSC as a time source whereas this one does, hence the problems which you're observing.
Some or all of the below might be wrong, but I don't think so:
I assume that booting with clock=pit or clock=pmtmr fixes it?
It would be useful to check your 2.6.17 boot logs, see if we can work out what 2.6.17 was using for a clock source.
We need to fix that "fixed it up" message because it just ain't so.
The new clocksouce code needs to detect this and to mark the TSC source as unstable, or otherwise unusable.
We _could_ fix the TSC skew up, by adjusting the rdtsc output by the tsc_values[] entry wherever we read the TSC.
It would of course be better to make write_tsc() work. I wonder why it doesn't?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |