Athlon /proc/cpuinfo anomaly [minor]

Athlon /proc/cpuinfo anomaly [minor]

[Alastair Stevens]

Just a minor point: my infamous and improbable dual Athlon XP 1800+
system is now running happily under 2.4.15-pre7, but there's a slight
anomaly in the /proc/cpuinfo reporting.

CPU0 is labelled as an "AMD Athlon(tm) MP Processor 1800+", as expected.
CPU1 is instead labelled just "AMD Athlon(tm) Processor".

All other parameters are reported as identical between the two CPUs.

I know there have been some /proc/cpuinfo changes on various
architectures recently, so maybe this is related. Am I missing
something, or shouldn't they be reported as the same?

Cheers
Alastair

o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Alastair Stevens           \ \
MRC Biostatistics Unit      \ \___________ 01223 330383
Cambridge UK                 \___ www.mrc-bsu.cam.ac.uk

Re: Athlon /proc/cpuinfo anomaly [minor]

[Alan Cox]

> CPU0 is labelled as an "AMD Athlon(tm) MP Processor 1800+", as expected.
> CPU1 is instead labelled just "AMD Athlon(tm) Processor".

Those strings are read directly out of the CPU. Mine for example says

cpu family      : 6
model           : 1
model name      : AMD-K7(tm) Processor
stepping        : 1

Alan

Re: Athlon /proc/cpuinfo anomaly [minor]

[Alastair Stevens]

> > CPU0 is labelled as an "AMD Athlon(tm) MP Processor 1800+", as expected.
> > CPU1 is instead labelled just "AMD Athlon(tm) Processor".
>
> Those strings are read directly out of the CPU.
> Alan

Hmmm, case of a suspicious CPU then? I haven't physically looked at it,
but all the correct XP flags (such as "sse") are reported, so it must be
the real thing.

Perhaps one is a certified MP processor, and the other (ahem) isn't...?

Cheers
Alastair

o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Alastair Stevens           \ \
MRC Biostatistics Unit      \ \___________ 01223 330383
Cambridge UK                 \___ www.mrc-bsu.cam.ac.uk

Re: Athlon /proc/cpuinfo anomaly [minor]

[Jens Axboe]

On Wed, Nov 21 2001, Alan Cox wrote:
> > CPU0 is labelled as an "AMD Athlon(tm) MP Processor 1800+", as expected.
> > CPU1 is instead labelled just "AMD Athlon(tm) Processor".
> 
> Those strings are read directly out of the CPU. Mine for example says
> 
> cpu family      : 6
> model           : 1
> model name      : AMD-K7(tm) Processor
> stepping        : 1

No there is a bug there, I can confirm that mine does the same (ie
second athlon is not reported with correct model name)

-- 
Jens Axboe

Re: Athlon /proc/cpuinfo anomaly [minor]

[Dave Jones]

On Wed, 21 Nov 2001, Jens Axboe wrote:

> No there is a bug there, I can confirm that mine does the same (ie
> second athlon is not reported with correct model name)

Interesting. But they are definitly the same CPU models ?
x86info -a info please ? (pub/people/davej on ftp.suse.com)

Could be your BIOS isn't setting up 2nd CPU name string.
Harmless, but dumb.  If this is the case, I wonder what else
it forgets to do.

regards,
Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Athlon /proc/cpuinfo anomaly [minor]

[Jens Axboe]

On Wed, Nov 21 2001, Dave Jones wrote:
> On Wed, 21 Nov 2001, Jens Axboe wrote:
> 
> > No there is a bug there, I can confirm that mine does the same (ie
> > second athlon is not reported with correct model name)
> 
> Interesting. But they are definitly the same CPU models ?
> x86info -a info please ? (pub/people/davej on ftp.suse.com)
> 
> Could be your BIOS isn't setting up 2nd CPU name string.
> Harmless, but dumb.  If this is the case, I wonder what else
> it forgets to do.

Weee

[root@bart x86info-1.5]# ./x86info -a | grep "name string"
Processor name string: AMD Athlon(tm) MP Processor 1700+
Processor name string: AMD Athlon(tm) MP Processor 1700+
[root@bart x86info-1.5]# ./x86info -a | grep "name string"
Processor name string: AMD Athlon(tm) Processor
Processor name string: AMD Athlon(tm) Processor
[root@bart x86info-1.5]# ./x86info -a | grep "name string"
Processor name string: AMD Athlon(tm) MP Processor 1700+
Processor name string: AMD Athlon(tm) MP Processor 1700+
[root@bart x86info-1.5]# ./x86info -a | grep "name string"
Processor name string: AMD Athlon(tm) MP Processor 1700+
Processor name string: AMD Athlon(tm) MP Processor 1700+

-- 
Jens Axboe

Re: Athlon /proc/cpuinfo anomaly [minor]

[Dave Jones]

On Wed, 21 Nov 2001, Jens Axboe wrote:

> [root@bart x86info-1.5]# ./x86info -a | grep "name string"
> Processor name string: AMD Athlon(tm) MP Processor 1700+
> Processor name string: AMD Athlon(tm) MP Processor 1700+
> [root@bart x86info-1.5]# ./x86info -a | grep "name string"
> Processor name string: AMD Athlon(tm) Processor
> Processor name string: AMD Athlon(tm) Processor

Thanks. Looks like I was right, your BIOS isn't doing
the 'right thing' for CPU 2. Cest la vie.

(The "Sometimes returns different results" bug fixed in CVS,
 release later today btw)

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Athlon /proc/cpuinfo anomaly [minor]

[Jens Axboe]

On Wed, Nov 21 2001, Dave Jones wrote:
> On Wed, 21 Nov 2001, Jens Axboe wrote:
> 
> > [root@bart x86info-1.5]# ./x86info -a | grep "name string"
> > Processor name string: AMD Athlon(tm) MP Processor 1700+
> > Processor name string: AMD Athlon(tm) MP Processor 1700+
> > [root@bart x86info-1.5]# ./x86info -a | grep "name string"
> > Processor name string: AMD Athlon(tm) Processor
> > Processor name string: AMD Athlon(tm) Processor
> 
> Thanks. Looks like I was right, your BIOS isn't doing
> the 'right thing' for CPU 2. Cest la vie.

Strange, I was pretty sure that earlier 2.4.x got it right. Oh well.

-- 
Jens Axboe

Re: Athlon /proc/cpuinfo anomaly [minor]

[Dave Jones]

On Wed, 21 Nov 2001, Jens Axboe wrote:

> Strange, I was pretty sure that earlier 2.4.x got it right. Oh well.

*shrug* As we don't do any setting of this string, all I can guess
at is that the new seqfile based /proc/cpuinfo code is stricter
about getting the info from the right CPU than the older code was.

Though I'm not sure why, as the older code just read from the
per-CPU structs anyway.  Most odd.

regards,
Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Athlon /proc/cpuinfo anomaly [minor]

[Matthew Sell]

The results of "dmesg" on my dual-Athlon show a (rather comical) 
discrepancy, it's not a big deal - just funny (to me)....

I was just wondering if this was a similar behavior to the earlier posts on 
this topic:


Intel MultiProcessor Specification v1.4
     Virtual Wire compatibility mode.
OEM ID: TYAN     Product ID: GUINNESS     APIC at: 0xFEE00000
Processor #1 Pentium(tm) Pro APIC version 16
Processor #0 Pentium(tm) Pro APIC version 16
I/O APIC #2 Version 17 at 0xFEC00000.
Processors: 2


Intel machine check reporting enabled on CPU#0.
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
CPU0: AMD Athlon(tm) Processor stepping 04
per-CPU timeslice cutoff: 731.77 usecs.


Intel machine check reporting enabled on CPU#1.
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
CPU1: AMD Athlon(tm) Processor stepping 04
Total of 2 processors activated (5564.00 BogoMIPS).


         - Matt



At 01:19 PM 11/21/2001 +0100, Dave Jones wrote:
>On Wed, 21 Nov 2001, Jens Axboe wrote:
>
> > Strange, I was pretty sure that earlier 2.4.x got it right. Oh well.
>
>*shrug* As we don't do any setting of this string, all I can guess
>at is that the new seqfile based /proc/cpuinfo code is stricter
>about getting the info from the right CPU than the older code was.
>
>Though I'm not sure why, as the older code just read from the
>per-CPU structs anyway.  Most odd.
>
>regards,
>Dave.
>
>--
>| Dave Jones.        http://www.codemonkey.org.uk
>| SuSE Labs
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/



Matthew Sell
Programmer
On Time Support, Inc.
www.ontimesupport.com
(281) 296-6066

Join the Metrology Software discussion group METLIST!
http://www.ontimesupport.com/cgi-bin/mojo/mojo.cgi


"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler

Many thanks for this tagline to a fellow RGVAC'er...

Re: Athlon /proc/cpuinfo anomaly [minor]

[Stefan Smietanowski]

Jens Axboe wrote:

> On Wed, Nov 21 2001, Alan Cox wrote:
> 
>>>CPU0 is labelled as an "AMD Athlon(tm) MP Processor 1800+", as expected.
>>>CPU1 is instead labelled just "AMD Athlon(tm) Processor".
>>>
>>Those strings are read directly out of the CPU. Mine for example says
>>
>>cpu family      : 6
>>model           : 1
>>model name      : AMD-K7(tm) Processor
>>stepping        : 1
>>
> 
> No there is a bug there, I can confirm that mine does the same (ie
> second athlon is not reported with correct model name)

Have you actually verified it by switching the cpu's around? That should 
be the first to do.

// Stefan

Re: Athlon /proc/cpuinfo anomaly [minor]

[Dave Jones]

On Wed, 21 Nov 2001, Alan Cox wrote:

> > CPU0 is labelled as an "AMD Athlon(tm) MP Processor 1800+", as expected.
> > CPU1 is instead labelled just "AMD Athlon(tm) Processor".
> Those strings are read directly out of the CPU. Mine for example says
> model name      : AMD-K7(tm) Processor

Better yet.. They're programmed by the BIOS.

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Athlon /proc/cpuinfo anomaly [minor]

[Stuart Young]

At 11:19 AM 21/11/01 +0000, Alastair Stevens wrote:
> > > CPU0 is labelled as an "AMD Athlon(tm) MP Processor 1800+".
> > > CPU1 is instead labelled just "AMD Athlon(tm) Processor".
> >
> > Those strings are read directly out of the CPU.
>
>Hmmm, case of a suspicious CPU then? I haven't physically looked at it,
>but all the correct XP flags (such as "sse") are reported, so it must be
>the real thing.
>
>Perhaps one is a certified MP processor, and the other (ahem) isn't...?

Tried swapping the processors around?

If it's processor dependent, that'll show it. If it's code, it'll be the same.


AMC Enterprises P/L    - Stuart Young
First Floor            - Network and Systems Admin
3 Chesterville Rd      - sgy@amc.com.au
Cheltenham Vic 3192    - Ph:  (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755

Re: Athlon /proc/cpuinfo anomaly [minor]

[Zwane Mwaikambo]

hmm i've always been under the impression that those strings are hard
encoded into the CPU so even if we're on a motherboard/bios which doesn't
"support" that particular CPU we can do a cpuid and get the same string.

Regards,
	Zwane Mwaikambo

Re: Athlon /proc/cpuinfo anomaly [minor]

[Dave Jones]

On Thu, 22 Nov 2001, Zwane Mwaikambo wrote:

> hmm i've always been under the impression that those strings are hard
> encoded into the CPU so even if we're on a motherboard/bios which doesn't
> "support" that particular CPU we can do a cpuid and get the same string.

It likely has a less descriptive hardware default, but it can be
(and is advised to be for bios writers) overridden in software.

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Athlon /proc/cpuinfo anomaly [minor]

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.33.0111221552260.20788-100000@Appserv.suse.de>
By author:    Dave Jones <davej@suse.de>
In newsgroup: linux.dev.kernel
>
> On Thu, 22 Nov 2001, Zwane Mwaikambo wrote:
> 
> > hmm i've always been under the impression that those strings are hard
> > encoded into the CPU so even if we're on a motherboard/bios which doesn't
> > "support" that particular CPU we can do a cpuid and get the same string.
> 
> It likely has a less descriptive hardware default, but it can be
> (and is advised to be for bios writers) overridden in software.
> 

No, the defaults are in the CPU if the CPU is recent enough.

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