lkml.org 
[lkml]   [2008]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: i387/FPU init issues...
On Sat, 3 May 2008, Ingo Molnar wrote:
> * jamal <hadi@cyberus.ca> wrote:
>
> > > we have:
> > > #define P6_NOP3 ".byte 0x0f,0x1f,0x00\n"
> >
> > Dang - I feel i should have saved myself all that git bisecting
> > and just posted the oops ;->
>
> your bisection was still very useful - it pinpointed the NOPs - the
> assembly code around the NOP changed so a different length NOP was
> patched in => which did not work on your CPU. So thanks for that! The
> fix is already in x86.git (we'll update the commit log).
>
> > > 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 ?
> >
> > Indeed it does - thanks.
>
> great. So this NOP is indeed not generally known to all "P6 and later"
> CPUs. (the PII)

Looks like. My analysis was wrong, as I got the P6 vs. PII/PIII
confused :) Damn unintutive numbering, I thought ARM is worse but I'm
not so sure anymore.

But the oops clearly identified that instruction sequence. So for now
we remove the X86_FEATURE_P3 -> P6_NOPS to be on the safe side.

Thanks,
tglx


\
 
 \ /
  Last update: 2008-05-03 19:43    [W:0.080 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site