Re: 2.6.27-rc4-git1: Reported regressions from 2.6.26

Linus Torvalds
2008-08-24T18:52:06Z

On Sat, 23 Aug 2008, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11354
> Subject : AMD Elan regression with 2.6.27-rc3
> Submitter : Sean Young <sean-hENCXIMQXOg@public.gmane.org>
> Date : 2008-08-15 18:37 (9 days old)
> References : http://marc.info/?l=linux-kernel&m=121882578430056&w=4

Peter? Ingo? Alok?

This _looks_ like it might be due to "x86: merge the TSC cpu-freq code"
thing by Alok, where we do this:

+static struct notifier_block time_cpufreq_notifier_block = {
+ .notifier_call = time_cpufreq_notifier
+};
+
+static int __init cpufreq_tsc(void)
+{
+ cpufreq_register_notifier(&time_cpufreq_notifier_block,
+ CPUFREQ_TRANSITION_NOTIFIER);
+ return 0;
+}

but that's just _insane_ if the CPU doesn't even support TSC to begin
with. Also, in the actual time_cpufreq_notifier(), we do:

if (cpu_has(&cpu_data(freq->cpu), X86_FEATURE_CONSTANT_TSC))
return 0;

and this is stupid because:

(a) if the CPU has no TSC at all, then it sure as hell won't have a
_constant_ one, so we'll actually continue into the function.

(b) and why the hell is this done at run-time in the notifier, and not in
the "cpufreq_tsc" init function? If anybody mixes totally different
kinds of CPU's in SMP, they deserve whatever they want.

so why is the patch not something like the appended?

Sean, does this make any difference for you?

Linus

---
arch/x86/kernel/tsc.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 46af716..9bed5ca 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -325,6 +325,10 @@ static struct notifier_block time_cpufreq_notifier_block = {

static int __init cpufreq_tsc(void)
{
+ if (!cpu_has_tsc)
+ return 0;
+ if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC))
+ return 0;
cpufreq_register_notifier(&time_cpufreq_notifier_block,
CPUFREQ_TRANSITION_NOTIFIER);
return 0;