On Wed, Nov 08, 2000 at 06:47:40PM +, Alan Cox wrote:
> Ok. Issue settled. So 'rep nop' is safe. Ok that can get into the spinlocks
> for 2.2.18
Just curious... What does "rep nop" actually accomplish, anyway?
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[
> On Wed, 8 Nov 2000, Alan Cox wrote:
>
> > What state does it leave the condition codes ? That matters.
>
> Alan, rep ; nop is one of the suggested 2 byte fillers in the Athon
> optimization guide; it's handled during instruction decode and is
> completely free. It also has no effect on K6s.
On Wed, Nov 08, 2000 at 06:21:54PM +, Alan Cox wrote:
> > > asm volatile("rep ; nop");
> > >
> > > (there's not much a "rep nop" _can_ do, after all - the most likely CPU
> > > extension would be to raise an "Illegal Opcode" fault).
> >
> > Just for the curious, this works on Athlo
On Wed, 8 Nov 2000, Alan Cox wrote:
> What state does it leave the condition codes ? That matters.
Alan, rep ; nop is one of the suggested 2 byte fillers in the Athon
optimization guide; it's handled during instruction decode and is
completely free. It also has no effect on K6s.
> > asm volatile("rep ; nop");
> >
> > (there's not much a "rep nop" _can_ do, after all - the most likely CPU
> > extension would be to raise an "Illegal Opcode" fault).
>
> Just for the curious, this works on Athlons. :)
What state does it leave the condition codes ? That matters
On Wed, Nov 08, 2000 at 10:10:45AM -0800, Linus Torvalds wrote:
>
> Now, I could imagine that Intel would select an instruction that didn't
> work on Athlon on purpose, but I really don't think they did. I don't
> have an athlon to test.
>
> It's easy enough to generate a test-program. If the f
> It won't fail on other CPU's. The bug is, as far as I can tell, in
> get_model_name(),
>
> cpuid(0x8001, &dummy, &dummy, &dummy, &(c->x86_capability));
Dave Jones fixed this one - for intel we don't use get_model_name() blindly
now. I can see how some earlier 2.2.18pre's would have b
On Wed, 8 Nov 2000, Alan Cox wrote:
> > unless that CPU is also SMP-capable). It's documented by intel these
> > days, and it works on all CPU's I've ever heard of, and it even makes
> > sense to me (*).
>
> Do the intel docs guarantee it works on i486 and higher, if so SMP athlon
> will be th
> unless that CPU is also SMP-capable). It's documented by intel these
> days, and it works on all CPU's I've ever heard of, and it even makes
> sense to me (*).
Do the intel docs guarantee it works on i486 and higher, if so SMP athlon
will be the only check needed for the SMP users. You work fo
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>
>rep;nop is a magic instruction on the PIV and possibly some PIII series CPUs
>[not sure]. As far as I can make out it naps momentarily or until bus
>activity thus saving power on spinlocks.
>From what I've heard, the reason I
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>
>Be careful with the intel patches. The ones I've seen so far tried to call the
>cpu 'if86' breaking several tools that do cpu model checking off uname. They
>didnt fix the 2GHz CPU limit, they use 'rep nop' in the locks which
> As for the 2.2.18 patch for correctly determining 2GHz and above, can
> it be easily merged into the 2.4.x kernel, and if so, what's the maximum
> clock speed that can be detected?
It should be easy yes. Its good to 100Ghz or so now ;)
-
To unsubscribe from this list: send the line "unsubscr
Alan,
As for 'rep nop', couldn't we add in the code, as an example:
#ifdef Pentium_4
rep nop
#endif
As for the 2.2.18 patch for correctly determining 2GHz and above, can
it be easily merged into the 2.4.x kernel, and if so, what's the maximum
clock speed that can be detected?
Regards,
-Fr
> are you saying that rep;nop is not needed in the spinlocks? (because they
> are for P4)
rep;nop is a magic instruction on the PIV and possibly some PIII series CPUs
[not sure]. As far as I can make out it naps momentarily or until bus
activity thus saving power on spinlocks.
The problem is 're
; <[EMAIL PROTECTED]>
Sent: Tuesday, November 07, 2000 4:13 AM
Subject: Re: Pentium 4 and 2.4/2.5
> > Not to worry, some of us are working with the 'I' guys to do proper P4
> > detection.
>
> Be careful with the intel patches. The ones I've seen so far tri
> Not to worry, some of us are working with the 'I' guys to do proper P4
> detection.
Be careful with the intel patches. The ones I've seen so far tried to call the
cpu 'if86' breaking several tools that do cpu model checking off uname. They
didnt fix the 2GHz CPU limit, they use 'rep nop' in the
> I noticed that Pentium 4 isn't an config option in 2.4.0-test10. Is
> someone working on a patch for the the kernel (if needed) to support the
> Pentium 4 after 2.4.0 is released?
And also for 2.2. 2.2.18pre18/19 should ident the CPU fine. A contributed patch
should also report the caches cor
On Sat, 4 Nov 2000, Frank Davis hissed:
> I noticed that Pentium 4 isn't an config option in 2.4.0-test10. Is
> someone working on a patch for the the kernel (if needed) to support the
> Pentium 4 after 2.4.0 is released?
from what i have read of the Pentium IV, the linux kernel will not need
a
Not to worry, some of us are working with the 'I' guys to do proper P4
detection.
Cheers,
On Sat, 4 Nov 2000, Frank Davis wrote:
> Hello,
> I noticed that Pentium 4 isn't an config option in 2.4.0-test10. Is
> someone working on a patch for the the kernel (if needed) to support the
> Pentium
Hello,
I noticed that Pentium 4 isn't an config option in 2.4.0-test10. Is
someone working on a patch for the the kernel (if needed) to support the
Pentium 4 after 2.4.0 is released?
Regards,
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
20 matches
Mail list logo