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 \___ http://www.mrc-bsu.cam.ac.uk
> 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
> > 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 \___ http://www.mrc-bsu.cam.ac.uk
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
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
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
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
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
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
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
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
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 [email protected]
>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.
http://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...
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 - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
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
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
Followup to: <[email protected]>
By author: Dave Jones <[email protected]>
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
--
<[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]>