[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080229003224.GA18821@ubuntu>
Date: Fri, 29 Feb 2008 02:32:24 +0200
From: "Ahmed S. Darwish" <darwish.07@...il.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Rusty Russell <rusty@...tcorp.com.au>,
LKML <linux-kernel@...r.kernel.org>, lguest@...abs.org,
akpm <akpm@...ux-foundation.org>,
Jeremy Fitzhardinge <jeremy@...source.com>
Subject: Re: [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index
calculation
Hi Ingo/x86-folks,
On Mon, Feb 25, 2008 at 02:18:16AM +0200, Ahmed S. Darwish wrote:
...
>
> This thread's main bug no longer appears. There's a new bug though,
> but it looks nicer than the original ugly bug!.
>
> The new bug does *not* appear in mainline with the same patch. It's
> a panic, but this time on the _guest_ side (which is the same host's
> kernel).
>
> [ 0.023996] CPU: Intel(R) Pentium(R) M processor 1500MHz stepping 05
> [ 0.023996] Kernel panic - not syncing: Kernel compiled for Pentium+, requires TSC feature!
> [ 0.023996] Pid: 0, comm: swapper Not tainted 2.6.25-rc2-00815-g3db3a05 #64
>
The bug appeared in mainline due to the latest x86 merge. The commit
that caused the bug is not faulty though:
commit 12c247a6719987aad65f83158d2bb3e73c75c1f5
x86: fix boot failure on 486 due to TSC breakage
1. arch/x86/kernel/tsc_32.c:tsc_init() sees !cpu_has_tsc,
so bails and calls setup_clear_cpu_cap(X86_FEATURE_TSC).
2. include/asm-x86/cpufeature.h:setup_clear_cpu_cap(bit) clears
the bit in boot_cpu_data and sets it in cleared_cpu_caps
3. arch/x86/kernel/cpu/common.c:identify_cpu() XORs all caps
in with cleared_cpu_caps
HOWEVER, at this point c->x86_capability correctly has TSC
Off, cleared_cpu_caps has TSC On, so the XOR incorrectly
sets TSC to On in c->x86_capability, with disastrous results.
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f86a3c4..a38aafa 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -504,7 +504,7 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
/* Clear all flags overriden by options */
for (i = 0; i < NCAPINTS; i++)
- c->x86_capability[i] ^= cleared_cpu_caps[i];
+ c->x86_capability[i] &= ~cleared_cpu_caps[i];
Now the commit fixed everything, and x86_capability shows the right
thing (TSC = off).
On the lguest _guest_ side, 'cpu_has_tsc' is _always_ false (due to
lguest using his own clocksource ?), thus a guest with a pentium+
cpu always panics with:
#ifdef CONFIG_X86_TSC
if (!cpu_has_tsc)
panic("Kernel compiled for Pentium+, requires TSC feature!");
#endif
In older kernels (2.6.23), the problem was also hidden using 'tsc_disable':
tsc.c:
if (!cpu_has_tsc || tsc_disable)
tsc_disable = 1;
bug.c:
#ifdef CONFIG_X86_TSC
if (!cpu_has_tsc && !tsc_disable)
panic("Kernel compiled for Pentium+, requires TSC feature!");
#endif
I've tried solving the problem with several tweaks including something like:
/* If we're running on a pentium+, fake an enabled TSC to bypass
* kernel checks for processor bugs (see x86/cpu/bugs.c) */
if (boot_cpu_data.x86 >= 5)
setup_force_cpu_cap(X86_FEATURE_TSC);
with no luck at all.
Any idea how to solve this problem in a right/mergeable way ?
Thank you,
--
"Better to light a candle, than curse the darkness"
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
--
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