linux-kernel - Re: REGRESSION: the new i386 timer code fails to sync CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 23 Jul 2006 04:46:37 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Matthias Urlichs <smurf@...rf.noris.de>
Cc:	linux-kernel@...r.kernel.org, johnstul@...ibm.com,
	torvalds@...l.org, bunk@...sta.de, lethal@...ux-sh.org,
	hirofumi@...l.parknet.co.jp
Subject: Re: REGRESSION: the new i386 timer code fails to sync CPUs

On Sun, 23 Jul 2006 10:16:04 +0200
Matthias Urlichs <smurf@...rf.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/