Discrepancies between /proc/cpuinfo and Dave J's x86info

Discrepancies between /proc/cpuinfo and Dave J's x86info

[Jordan]

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 <davej@suse.de>.

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

Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[H. Peter Anvin]

Followup to:  <3B4BC5C0.BDDC12A6@home.com>
By author:    Jordan <ledzep37@home.com>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Jonathan Lundell]

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.

Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[H. Peter Anvin]

Followup to:  <p05100358b771879535bc@[207.213.214.37]>
By author:    Jonathan Lundell <jlundell@pobox.com>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Jonathan Lundell]

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.

Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Dave Jones]

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

Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Hugh Dickins]

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

Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Dave Jones]

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--;
 	}
 }

[PATCH] Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Hugh Dickins]

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);
 	}
 }
 

Re: [PATCH] Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Dave Jones]

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

Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Jordan Breeding]

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

Re: [PATCH] Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Linus Torvalds]

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

Re: [PATCH] Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Jonathan Lundell]

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.

Re: [PATCH] Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[Dave Jones]

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

Re: [PATCH] Re: Discrepancies between /proc/cpuinfo and Dave J's x86i

[Kai Henningsen]

davej@suse.de (Dave Jones)  wrote on 11.07.01 in <Pine.LNX.4.30.0107111858110.1811-100000@Appserv.suse.de>:

> 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

Re: [PATCH] Re: Discrepancies between /proc/cpuinfo and Dave J's x86info

[H. Peter Anvin]

Followup to:  <p05100361b77232f67994@[207.213.214.37]>
By author:    Jonathan Lundell <jlundell@pobox.com>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>