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/
This archive was generated by hypermail 2b29 : Mon Jan 15 2001 - 21:00:41 EST