On Sat, 3 May 2008, jamal wrote:
quoted text
>  =======================
> Code: 8d 74 26 00 8d bc 27 00 00 00 00 55 89 c2 8b 40 04 89 e5 f6 40 0c
> 01 74 32 8b 82 60 02 00 00 0f ae 00 0f ba 60 02 07 73 02 db e2 <0f> 1f
> 00 90 8d b4 26 00 00 00 00 89 f6 8b 42 04 83 60 0c fe 0f

This looks bad.

  0f ae 00		fxsave (%eax)
  0f ba 60 02 07       	btl    $0x7,0x2(%eax)
  73 02                	jae    (skip fnclex)
  db e2                	fnclex 
  0f 1f 00             	nopl   (%eax)

 ^^^^ This is a P4+ instruction. So it's not surprising that the P2
 chokes. The question is where this comes from.

we have:
#define P6_NOP3 ".byte 0x0f,0x1f,0x00\n"

So the alternatives code applies the wrong nop padding for your
CPU. This was probably introduced with commit
32c464f5d9701db45bc1673288594e664065388e. 

Jan, are you sure that P3 knows the P6 NOPs ? AFAICT its P4, but I
have to dig up the manuals.

Jamal, does the following patch solve your problem ? Please provide
also output of /proc/cpuinfo.

Thanks,
	tglx
---

--- linux-2.6.orig/arch/x86/kernel/alternative.c
+++ linux-2.6/arch/x86/kernel/alternative.c
@@ -158,7 +158,6 @@ static const struct nop {
 	{ X86_FEATURE_K8, k8_nops },
 	{ X86_FEATURE_K7, k7_nops },
 	{ X86_FEATURE_P4, p6_nops },
-	{ X86_FEATURE_P3, p6_nops },
 	{ -1, NULL }
 };
 
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/