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, 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
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
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
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
> It won't fail on other CPU's. The bug is, as far as I can tell, in
> get_model_name(),
>
> cpuid(0x8001, , , , &(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 blown up, but
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
> 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
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
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
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 is
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 Intel
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 for
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 the only
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 blown up,
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
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.
Take
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 Athlons. :)
What
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.
Ok.
> 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
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,
> 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
; <[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 tried to call
the
> 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
> 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
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
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
: 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 tried to call
the
cpu 'if86' breaking several tools that do cpu model check
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 'rep
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,
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
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
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
>
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
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
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 4
39 matches
Mail list logo
