While trying to figure out what happened to make my two identical
processors show up differently in /proc/cpuinfo I noticed that they do
not appear differently in the x86info utility. Here is a copy of my
/proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 999.682
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse
bogomips : 1992.29
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 999.682
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse
bogomips : 1998.84
Notice that the cpuid level and bogomips values are reported to be
different, but look at the output of `x86info -a`:
x86info v1.3. Dave Jones 2001
Feedback to <[email protected]>.
Found 2 CPUs
eax in: 0, eax = 00000002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69
eax in: 1, eax = 00000686 ebx = 00000002 ecx = 00000000 edx = 0383fbff
eax in: 2, eax = 03020101 ebx = 00000000 ecx = 00000000 edx = 0c040882
Vendor ID: "GenuineIntel"; Max CPUID level 2
Intel-specific functions
Family: 6 Model: 8 Type 0 [Celeron / Pentium III (Coppermine) Original
OEM]
Stepping: 6
Reserved: 0
Feature flags 0383fbff:
FPU Floating Point Unit
VME Virtual 8086 Mode Enhancements
DE Debugging Extensions
PSE Page Size Extensions
TSC Time Stamp Counter
MSR Model Specific Registers
PAE Physical Address Extension
MCE Machine Check Exception
CX8 COMPXCHG8B Instruction
APIC On-chip Advanced Programmable Interrupt Controller present and
enabled
SEP Fast System Call
MTRR Memory Type Range Registers
PGE PTE Global Flag
MCA Machine Check Architecture
CMOV Conditional Move and Compare Instructions
FGPAT Page Attribute Table
PSE-36 36-bit Page Size Extension
MMX MMX instruction set
FXSR Fast FP/MMX Streaming SIMD Extensions save/restore
XMM Streaming SIMD Extensions instruction set
Instruction TLB: 4KB pages, 4-way set assoc, 32 entries
Instruction TLB: 4MB pages, fully assoc, 2 entries
Data TLB: 4KB pages, 4-way set assoc, 64 entries
L2 unified cache: Sectored, 32 byte cache line, 8 way set associative,
256K
Instruction cache: 16KB, 4-way set assoc, 32 byte line size
Data TLB: 4MB pages, 4-way set assoc, 8 entries
Data cache: 16KB, 2-way or 4-way set assoc, 32 byte line size
Erk, MCG_CTL not present!
eax in: 0, eax = 00000002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69
eax in: 1, eax = 00000686 ebx = 00000002 ecx = 00000000 edx = 0383fbff
eax in: 2, eax = 03020101 ebx = 00000000 ecx = 00000000 edx = 0c040882
Vendor ID: "GenuineIntel"; Max CPUID level 2
Intel-specific functions
Family: 6 Model: 8 Type 0 [Celeron / Pentium III (Coppermine) Original
OEM]
Stepping: 6
Reserved: 0
Feature flags 0383fbff:
FPU Floating Point Unit
VME Virtual 8086 Mode Enhancements
DE Debugging Extensions
PSE Page Size Extensions
TSC Time Stamp Counter
MSR Model Specific Registers
PAE Physical Address Extension
MCE Machine Check Exception
CX8 COMPXCHG8B Instruction
APIC On-chip Advanced Programmable Interrupt Controller present and
enabled
SEP Fast System Call
MTRR Memory Type Range Registers
PGE PTE Global Flag
MCA Machine Check Architecture
CMOV Conditional Move and Compare Instructions
FGPAT Page Attribute Table
PSE-36 36-bit Page Size Extension
MMX MMX instruction set
FXSR Fast FP/MMX Streaming SIMD Extensions save/restore
XMM Streaming SIMD Extensions instruction set
Instruction TLB: 4KB pages, 4-way set assoc, 32 entries
Instruction TLB: 4MB pages, fully assoc, 2 entries
Data TLB: 4KB pages, 4-way set assoc, 64 entries
L2 unified cache: Sectored, 32 byte cache line, 8 way set associative,
256K
Instruction cache: 16KB, 4-way set assoc, 32 byte line size
Data TLB: 4MB pages, 4-way set assoc, 8 entries
Data cache: 16KB, 2-way or 4-way set assoc, 32 byte line size
Erk, MCG_CTL not present!
999MHz processor (estimate).
According to Dave J's utility the cpu's appear to be exactly the same
just as the Intel boxes said when I bought them. What might be causing
these values to be different. And if the BIOS is setting things up
incorrectly then why does Dave J's utility show the correct values?
Thanks for any help.
Jordan
Followup to: <[email protected]>
By author: Jordan <[email protected]>
In newsgroup: linux.dev.kernel
>
> According to Dave J's utility the cpu's appear to be exactly the same
> just as the Intel boxes said when I bought them. What might be causing
> these values to be different. And if the BIOS is setting things up
> incorrectly then why does Dave J's utility show the correct values?
> Thanks for any help.
>
/proc/cpuinfo shows "cooked" values which may be modified by the
kernel, depending on what it knows about CPU errata or kernel
capabilities.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
At 9:27 PM -0700 2001-07-10, H. Peter Anvin wrote:
> > According to Dave J's utility the cpu's appear to be exactly the same
>> just as the Intel boxes said when I bought them. What might be causing
>> these values to be different. And if the BIOS is setting things up
>> incorrectly then why does Dave J's utility show the correct values?
>> Thanks for any help.
>>
>
>/proc/cpuinfo shows "cooked" values which may be modified by the
>kernel, depending on what it knows about CPU errata or kernel
>capabilities.
Max cpuid level doesn't get cooked by the kernel, though (at least
not in 2.4.6).
Level 3 is the Intel's CPU serial number "feature". Didn't Intel back
off on that? Maybe that has something to do with it, and perhaps the
utility is doing the cooking.
--
/Jonathan Lundell.
Followup to: <p05100358b771879535bc@[207.213.214.37]>
By author: Jonathan Lundell <[email protected]>
In newsgroup: linux.dev.kernel
>
> At 9:27 PM -0700 2001-07-10, H. Peter Anvin wrote:
> > > According to Dave J's utility the cpu's appear to be exactly the same
> >> just as the Intel boxes said when I bought them. What might be causing
> >> these values to be different. And if the BIOS is setting things up
> >> incorrectly then why does Dave J's utility show the correct values?
> >> Thanks for any help.
> >>
> >
> >/proc/cpuinfo shows "cooked" values which may be modified by the
> >kernel, depending on what it knows about CPU errata or kernel
> >capabilities.
>
> Max cpuid level doesn't get cooked by the kernel, though (at least
> not in 2.4.6).
>
> Level 3 is the Intel's CPU serial number "feature". Didn't Intel back
> off on that? Maybe that has something to do with it, and perhaps the
> utility is doing the cooking.
>
Actually, the kernel kills it if it detects it.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
At 9:44 PM -0700 2001-07-10, H. Peter Anvin wrote:
> > Level 3 is the Intel's CPU serial number "feature". Didn't Intel back
>> off on that? Maybe that has something to do with it, and perhaps the
>> utility is doing the cooking.
>>
>
>Actually, the kernel kills it if it detects it.
Not unconditionally, though. And (to the original question), it's not
clear why two CPUs would be treated differently.
--
/Jonathan Lundell.
On Tue, Jul 10, 2001 at 10:19:28PM -0500, Jordan wrote:
> cpuid level : 2
> cpuid level : 3
> According to Dave J's utility the cpu's appear to be exactly the same
> just as the Intel boxes said when I bought them. What might be causing
> these values to be different. And if the BIOS is setting things up
> incorrectly then why does Dave J's utility show the correct values?
> Thanks for any help.
This is a mystery to me. Rogier Wolff mentioned the same problem
a month or two back. At the time x86info had a bug that meant that
it was reading the same cpuid info from the same CPU twice in an
SMP box. This is fixed in 1.3 (or at least, should be).
This brings several questions.
1. Why does proc/cpuinfo think they are different.
2. Lowering from 3 -> 2 on a P3 happens when CPU serial number is
disabled. Is this not happening on the 2nd CPU? If not, why?
3. Why can't we see the discrepancy from userspace?
possibilities include
a. The CPUID /dev nodes are incorrectly numbered.
Can you check this, and make sure they have the right
minors ?
b. The CPUID driver cpu-scheduling is broken.
Unlikely, but possible, as afaik x86info is the only
program where you'd notice this difference.
hpa?
c. The CPU serial number disabling is done after the
/proc/cpuinfo creation. AFAIR this is not the case.
I'll check further into this after lunch.
regards,
Dave.
--
| Dave Jones. http://www.suse.de/~davej
| SuSE Labs
On Tue, 10 Jul 2001, Jordan wrote:
> While trying to figure out what happened to make my two identical
> processors show up differently in /proc/cpuinfo I noticed that they do
> not appear differently in the x86info utility. Here is a copy of my
> /proc/cpuinfo:
>
> processor : 0
> ...
> cpuid level : 2
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 mmx fxsr sse
> bogomips : 1992.29
>
> processor : 1
> ...
> cpuid level : 3
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 mmx fxsr sse
> bogomips : 1998.84
>
> Notice that the cpuid level and bogomips values are reported to be
> different ...
As others have said, cpuid level 3 corresponds to Processor Serial
Number enabled. I think what you have here is a machine on which
the BIOS has disabled PSN on the first CPU, but left it enabled on the
second CPU, and so the kernel has then disabled it on the second CPU.
Whereas arch/i386/kernel/setup.c clears its own copy of the Processor
Serial Number feature bit 18 (a.k.a. 0x40000 or "pn") when it "squashes"
the serial number, it doesn't re-evaluate cpuid_level, so still reports
the original 3. But if it tried cpuid 0 again, it would find that
max cpuid level has gone down to 2 - as x86info finds. No big deal.
And the bogomips difference has no significance: a timing loop
got fractionally different results when run on the two processors,
run it another time and they'd both come out different again.
Hugh
On Wed, 11 Jul 2001, Hugh Dickins wrote:
> As others have said, cpuid level 3 corresponds to Processor Serial
> Number enabled. I think what you have here is a machine on which
> the BIOS has disabled PSN on the first CPU, but left it enabled on the
> second CPU, and so the kernel has then disabled it on the second CPU.
I'll bet that's exactly what it is. Good work.
This patch (against 247pre6) should keep the cpuinfo in sync with the real
state of the CPU..
regards,
Dave.
--
| Dave Jones. http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux-247pre7/arch/i386/kernel/setup.c linux-dj/arch/i386/kernel/setup.c
--- linux-247pre7/arch/i386/kernel/setup.c Wed Jul 11 13:16:10 2001
+++ linux-dj/arch/i386/kernel/setup.c Wed Jul 11 13:18:27 2001
@@ -1994,6 +1994,7 @@
wrmsr(0x119,lo,hi);
printk(KERN_NOTICE "CPU serial number disabled.\n");
clear_bit(X86_FEATURE_PN, &c->x86_capability);
+ c->cpuid_level--;
}
}
On Wed, 11 Jul 2001, Dave Jones wrote:
>
> This patch (against 247pre6) should keep the cpuinfo in sync with the real
> state of the CPU..
Am I paranoid? I feel nervous about "c->cpuid_level--" inferring
what we expect to happen to it, would prefer to check it (below).
Hugh
--- linux-2.4.7-pre6/arch/i386/kernel/setup.c Wed Jul 11 11:23:22 2001
+++ linux/arch/i386/kernel/setup.c Wed Jul 11 15:02:17 2001
@@ -1994,6 +1994,7 @@
wrmsr(0x119,lo,hi);
printk(KERN_NOTICE "CPU serial number disabled.\n");
clear_bit(X86_FEATURE_PN, &c->x86_capability);
+ c->cpuid_level = cpuid_eax(0);
}
}
On Wed, 11 Jul 2001, Hugh Dickins wrote:
> Am I paranoid?
Probably :)
The Intel CPUs with PSN I've seen simply drop 1 level.
What other CPUs support this feature? ISTR Transmeta had it?
Do they behave the same?
> I feel nervous about "c->cpuid_level--" inferring
> what we expect to happen to it, would prefer to check it (below).
> + c->cpuid_level = cpuid_eax(0);
No biggie, either solution is fine with me.
regards,
Dave.
--
| Dave Jones. http://www.suse.de/~davej
| SuSE Labs
Dave Jones wrote:
>
> On Wed, 11 Jul 2001, Hugh Dickins wrote:
>
> > As others have said, cpuid level 3 corresponds to Processor Serial
> > Number enabled. I think what you have here is a machine on which
> > the BIOS has disabled PSN on the first CPU, but left it enabled on the
> > second CPU, and so the kernel has then disabled it on the second CPU.
>
> I'll bet that's exactly what it is. Good work.
>
> This patch (against 247pre6) should keep the cpuinfo in sync with the real
> state of the CPU..
>
> regards,
>
> Dave.
>
> --
> | Dave Jones. http://www.suse.de/~davej
> | SuSE Labs
>
> diff -urN --exclude-from=/home/davej/.exclude linux-247pre7/arch/i386/kernel/setup.c linux-dj/arch/i386/kernel/setup.c
> --- linux-247pre7/arch/i386/kernel/setup.c Wed Jul 11 13:16:10 2001
> +++ linux-dj/arch/i386/kernel/setup.c Wed Jul 11 13:18:27 2001
> @@ -1994,6 +1994,7 @@
> wrmsr(0x119,lo,hi);
> printk(KERN_NOTICE "CPU serial number disabled.\n");
> clear_bit(X86_FEATURE_PN, &c->x86_capability);
> + c->cpuid_level--;
> }
> }
It does keep everything in sync here. Thanks for the help.
Jordan
On Wed, 11 Jul 2001, Hugh Dickins wrote:
> On Wed, 11 Jul 2001, Dave Jones wrote:
> >
> > This patch (against 247pre6) should keep the cpuinfo in sync with the real
> > state of the CPU..
>
> Am I paranoid? I feel nervous about "c->cpuid_level--" inferring
> what we expect to happen to it, would prefer to check it (below).
I would much prefer this approach - along with a comment saying "disabling
the serial number may affect the cpuid level".
Done.
Linus
At 4:28 PM +0200 2001-07-11, Dave Jones wrote:
>On Wed, 11 Jul 2001, Hugh Dickins wrote:
>
>> Am I paranoid?
>
>Probably :)
>The Intel CPUs with PSN I've seen simply drop 1 level.
>What other CPUs support this feature? ISTR Transmeta had it?
>Do they behave the same?
>
>> I feel nervous about "c->cpuid_level--" inferring
>> what we expect to happen to it, would prefer to check it (below).
>> + c->cpuid_level = cpuid_eax(0);
>
>No biggie, either solution is fine with me.
HD's version has the advantage of not having to make assumptions
about how future CPUs might handle the level, and leaves open the
alternative possibility of leaving the level at 3 (or some future 4)
and just turning off the serial-number capability.
--
/Jonathan Lundell.
On Wed, 11 Jul 2001, Jonathan Lundell wrote:
> HD's version has the advantage of not having to make assumptions
> about how future CPUs might handle the level, and leaves open the
> alternative possibility of leaving the level at 3 (or some future 4)
> and just turning off the serial-number capability.
Given the PR disaster that the P3 serial number brought about,
I'd be surprised if Intel were to revisit that chapter of history :)
I see your point however.
regards,
Dave.
--
| Dave Jones. http://www.suse.de/~davej
| SuSE Labs
[email protected] (Dave Jones) wrote on 11.07.01 in <[email protected]>:
> Given the PR disaster that the P3 serial number brought about,
> I'd be surprised if Intel were to revisit that chapter of history :)
Though much of that has been bad PR handling, I think. It's not as if
Intel invented that feature - for example, every s390 system has one (and
so did the whole family at least since the /370, used for licenses, for
example), and everything living on ethernet is supposed to have a unique
MAC address. (Which *has* already been used in tracing authors of
malicious Windows software, I believe.)
OTOH, ISTR that under VM, it's possible to simulate the /370 etc. cpuid of
someone else. Which I know has been used to circumvent license
restrictions.
Then again, the US custom of using the SSN as a generic index would be
rather illegal over here, so that might change peoples attitudes to the
mere existance of those numbers - it does make a difference how big a
stick you can wield.
Not that any of this is important to Linux ...
MfG Kai
Followup to: <p05100361b77232f67994@[207.213.214.37]>
By author: Jonathan Lundell <[email protected]>
In newsgroup: linux.dev.kernel
>
> At 4:28 PM +0200 2001-07-11, Dave Jones wrote:
> >On Wed, 11 Jul 2001, Hugh Dickins wrote:
> >
> >> Am I paranoid?
> >
> >Probably :)
> >The Intel CPUs with PSN I've seen simply drop 1 level.
> >What other CPUs support this feature? ISTR Transmeta had it?
> >Do they behave the same?
> >
> >> I feel nervous about "c->cpuid_level--" inferring
> >> what we expect to happen to it, would prefer to check it (below).
> >> + c->cpuid_level = cpuid_eax(0);
> >
> >No biggie, either solution is fine with me.
>
> HD's version has the advantage of not having to make assumptions
> about how future CPUs might handle the level, and leaves open the
> alternative possibility of leaving the level at 3 (or some future 4)
> and just turning off the serial-number capability.
>
cpuid_level-- is wrong on at least one existing processor (Crusoe),
which doesn't have CPUID level 2 and therefore goes from 3 to 1.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>