Re: 256 apic id for amd64

[Andi Kleen <ak@muc.de>]

On Mon, Jan 10, 2005 at 10:32:42AM -0800, Yinghai Lu wrote:
> Resend
> 
> Andi, 
> 
> I want to repeat the request:
> Please consider to compute the phy_proc_id with x86_apicid (or the initial
> apic id).

Not sure what you want me to do exactly. 

The phys_proc_id[] array? First that isn't really used for anything and then 
it is filled from CPUID 1 anyways. Or phys_pkg_id()? That uses cpuid too.

If you think something is wrong best you send a patch that makes it 
clear what you're talking about.
> 
> The reason is 
> Phy_proc_id will be used in smpboot.c to produce cpu_siblings_map.
> 
> The two systems I mentioned really exist.
> System 1. 8 ways dual core opteron system and with 3 io apic.
> System 2. 4 ways dual core opteron system and with 15 io apic (7 amd 8131
> and 1 amd 8111).
> 
> We have to lift the apicid of cpus to make io apic to use 0-15.

I don't understand why you want to do that. The IO-APIC and the local APIC ID 
space should separate as far as I know, so you could use 0 for both a CPU 
and an IO-APIC. But in theory it should work anyways even with an BSP 
CPU ID != 0.

> Case 1: lift core0/node0 to use 16, and core1/node0 to use 17.....
> Case 2: core0/node0-->0, core1/node0-->1, core0/node1-->18,
> core1/node1-->19...
> Case 3: core0/node0-->0, core1/node0-->17, core0/node1-->18,
> core1/node1-->19...
> 
> Case 1 will make jiffies not happy and it will hang on calibrate_dalay. (
> jiffies is not changing).

That's because it needs physical APIC mode to handle CPU IDs >7, and that is
 not implemented in the flat case. I added it now, but you likely don't need 
it anyways.

-Andi