[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200803042307.51645.rusty@rustcorp.com.au>
Date: Tue, 4 Mar 2008 23:07:50 +1100
From: Rusty Russell <rusty@...tcorp.com.au>
To: Ingo Molnar <mingo@...e.hu>
Cc: "Ahmed S. Darwish" <darwish.07@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>, lguest@...abs.org,
akpm <akpm@...ux-foundation.org>,
Jeremy Fitzhardinge <jeremy@...source.com>
Subject: [PATCH 1/2] x86: If we cannot calibrate the TSC, we panic.
The current tsc_init() clears the TSC feature bit if the TSC khz
cannot be calculated, causing us to panic in
arch/x86/kernel/cpu/bugs.c check_config(). We should simply mark it
unstable.
Frankly, someone should take an axe to this code. mark_tsc_unstable()
not only marks it unstable, but sets tsc_enabled to 0, which seems
redundant but is actually important here because means it won't be
used by sched_clock() either. Perhaps a tristate enum "UNUSABLE,
UNSTABLE, OK" would be clearer, and separate mark_tsc_unstable() and
mark_tsc_broken() functions?
Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
diff -r f9a80502dc46 arch/x86/kernel/tsc_32.c
--- a/arch/x86/kernel/tsc_32.c Tue Mar 04 21:06:41 2008 +1100
+++ b/arch/x86/kernel/tsc_32.c Tue Mar 04 22:55:10 2008 +1100
@@ -394,13 +394,15 @@ void __init tsc_init(void)
int cpu;
if (!cpu_has_tsc)
- goto out_no_tsc;
+ return;
cpu_khz = calculate_cpu_khz();
tsc_khz = cpu_khz;
- if (!cpu_khz)
- goto out_no_tsc;
+ if (!cpu_khz) {
+ mark_tsc_unstable("could not calculate TSC khz");
+ return;
+ }
printk("Detected %lu.%03lu MHz processor.\n",
(unsigned long)cpu_khz / 1000,
@@ -433,9 +435,4 @@ void __init tsc_init(void)
tsc_enabled = 1;
clocksource_register(&clocksource_tsc);
-
- return;
-
-out_no_tsc:
- setup_clear_cpu_cap(X86_FEATURE_TSC);
}
--
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/
Powered by blists - more mailing lists