On Wed, 8 Dec 1999, Rich Payne wrote:
>Now this value comes from hwrpb->nr_processors, which seems to be related
>to the INIT_HWRPB struct in aboot (am I even close here ?)
The interesting line is:
CPUs probed 2 active 2 map 0x3 IPIs 4351976
And the "probed" number is a number in function of the hwrpb informations
(and it's always <= hwrpb->nr_processors).
"active" instead means how many CPU are actively running (so the number of
"probed" CPUs that we are been able to activate).
The map in all kernels is wrong. I just fixed that problem here. Basically
the map shows the plain cpu_present_mask variable and cpu_present_mask
_must_ be relative to the number of CPU really activated, while it was set
in function of the "probed" cpus.
>So I guess the question is does anybody know why this is reporting 2 on
>SMP Tsunami machines? regardless of what's really there?
It means the hwrpb says 2. But you must not look at the "probed"
information, but you should look at the "active" information. The probed
information is not interesting at all from userspace.
>P.S. In case your interested, this all start with a problem of somebody
>porting some code over to AlphaLinux, they wanted to know the # of CPUs in
>the box so tried get_nprocs() and get_nprocs_conf() both of which return 0
>on Alpha as they seem to parse /proc/cpuinfo and count the number of
>instances of the word 'processor'. So the Alphas are always running with 0
>CPUs!
Ehh, "unfortunately" the format is very different. Maybe they should parse
/proc/stat. /proc/stat has a fixed format enforced in the common code:
andrea@alpha:~ > cat /proc/stat | egrep 'cpu[0-9]+' | wc -l
2
Andrea