ACPI oddity

ACPI oddity

[Bill Davidsen]

On a HT system, why does ACPI recognize CPU0 and CPU1, refer to them as 
such in dmesg, and then call them CPU1 and CPU2 in /proc/acpi/processor?

In uni kernels the single processor is CPU0.

This is a 2.6.10 kernel, the machine has been up since then. I have 
other 2.6 machines and other SMP and/or HT machines, but all of the HT 
machines running 2.6 are behind a hard firewall except one.

It's running the ASUS P4P800 board which is why I looked, BIOS 1086.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

RE: ACPI oddity

[Brown, Len]

>On a HT system, why does ACPI recognize CPU0 and CPU1, refer 
>to them as such in dmesg

This is the Linux CPU number. ie the namespace where 0
is the boot processor and the others are numbered in
the order that they were started.

> and then call them CPU1 and CPU2 in 
>/proc/acpi/processor?

These are arbitrary device identifiers written
by the BIOS developer and foolishly advertised
to the user by Linux.  The BIOS writer could have
also called them ABC9 and XYZ4 and it would be
equally valid.

We're planning to get rid of all the ACPI stuff
in /proc and move to sysfs.  At that time we'll
use device identifies that are deterministic,
like cpu%d that /sys/devices/system uses today.

cheers,
-Len

Re: ACPI oddity

[Bill Davidsen]

Brown, Len wrote:
>>On a HT system, why does ACPI recognize CPU0 and CPU1, refer 
>>to them as such in dmesg
> 
> 
> This is the Linux CPU number. ie the namespace where 0
> is the boot processor and the others are numbered in
> the order that they were started.
> 
> 
>>and then call them CPU1 and CPU2 in 
>>/proc/acpi/processor?
> 
> 
> These are arbitrary device identifiers written
> by the BIOS developer and foolishly advertised
> to the user by Linux.  The BIOS writer could have
> also called them ABC9 and XYZ4 and it would be
> equally valid.

Which explains why they are CPU1 and CPU2 on ASUS and CPU0 and CPU1 on 
another system. I was hoping I had found something for the person who 
was having problems with the P4P800 mobo, but looks like it's not here.
> 
> We're planning to get rid of all the ACPI stuff
> in /proc and move to sysfs.  At that time we'll
> use device identifies that are deterministic,
> like cpu%d that /sys/devices/system uses today.

Whatever, it's cosmetic and there seem to be more important problems 
with APIC than /proc vs. /sys.

Thanks for the clarification.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me