linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ahmed S. Darwish" <darwish.07@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	LKML <linux-kernel@vger.kernel.org>,
	lguest@ozlabs.org, akpm <akpm@linux-foundation.org>,
	Jeremy Fitzhardinge <jeremy@xensource.com>
Subject: Re: [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation
Date: Fri, 29 Feb 2008 02:32:24 +0200	[thread overview]
Message-ID: <20080229003224.GA18821@ubuntu> (raw)
In-Reply-To: <20080225001816.GA2933@ubuntu>

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


  reply	other threads:[~2008-02-29  0:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24 15:55 [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation Ahmed S. Darwish
2008-02-24 16:18 ` Ingo Molnar
2008-02-24 16:26   ` Ahmed S. Darwish
2008-02-25  0:18     ` Ahmed S. Darwish
2008-02-29  0:32       ` Ahmed S. Darwish [this message]
2008-02-29 19:58         ` Ingo Molnar
2008-03-04  6:37           ` Rusty Russell
2008-03-04 12:06           ` Rusty Russell
2008-03-04 12:07           ` [PATCH 1/2] x86: If we cannot calibrate the TSC, we panic Rusty Russell
2008-03-04 12:11             ` [PATCH 2/2] lguest: sanitize the clock Rusty Russell
2008-03-04 12:55 ` [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation Rusty Russell
2008-03-04 15:11   ` Ahmed S. Darwish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080229003224.GA18821@ubuntu \
    --to=darwish.07@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jeremy@xensource.com \
    --cc=lguest@ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).