Re: [PATCH] i386/setup.c cpuinfo notsc

["H. Peter Anvin" <hpa@transmeta.com>]

Hugh Dickins wrote:
> 
> That's how "notsc" used to behave, but since 2.4.0-test11
> "notsc" has left "tsc" in /proc/cpuinfo.  setup.c has a bogus
> "#ifdef CONFIG_TSC" which should be "#ifndef CONFIG_X86_TSC".
> 
> HPA, Maciej and I discussed that around 5 Dec 2000; but HPA
> was of Andrea's persuasion, that we should not mask caps out
> of (real CPU entries in) /proc/cpuinfo, so we made no change.
> 
> In discussion we found a more worrying error in the SMP case:
> boot_cpu_data is supposed to be left with those x86_capabilities
> common to all CPUs, but the code to do so was unaware that
> boot_cpu_data is overwritten in booting each CPU.  Even if all
> CPUs have the same features, I imagine the Linux-defined ones
> (CXMMX, K6_MTRR, CYRIX_ARR, CENTAUR_MCR) were unintentionally
> masked out of the final boot_cpu_data.
> 
> The patch below fixes both those issues, and also clears
> "pse" from /proc/cpuinfo in the same way if "mem=nopentium".
> Tempted to rename "tsc_disable" to "disable_x86_tsc", but resisted.
> 
> I think there are still anomalies in the Cyrix and Centaur TSC
> handling - shouldn't dodgy_tsc() check Centaur too?  shouldn't
> we set X86_CR4_TSD wherever we clear X86_FEATURE_TSC? - but I
> don't have those CPUs to test, I'm wary of disabling TSC since
> finding RH7.0 installed on i686 needs rdtsc to run /sbin/init,
> and even if they are wrong then "notsc" corrects the situation:
> not 2.4.1 material.
> 

I would personally prefer to export the global flags separately from the
per-CPU flags.  Not only is it more correct, it would help catch these
kinds of bugs!!!

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/