Re: 256 apic id for amd64

[James Cleverdon <jamesclv@us.ibm.com>]

On Friday 07 January 2005 06:53 pm, YhLu wrote:
> I mean keep the bsp physical apic id using 0.
>
> YH

If you mean that Linux will require that the boot processor (BSP) will 
always have physical APIC ID == 0, then it is already too late for 
i386.  I've posted a message to the root of this thread on some example 
boxes with weird APIC numbering schemes that are in our lab.

I don't trust every single BIOS writer to _always_ make the BSP physical 
APIC ID 0 for x86-64 either.  Why do you wish to require this anyway?

It is far safer to make no assumptions about APIC numbering and just 
accept whatever the BIOS gives us in the MPS and/or ACPI tables.  A few 
simple arrays indexed by CPU number will reveal the physical and 
logical APIC IDs whenever we need them.

So, why should Linux care about any CPU's physical APIC ID?


> -----Original Message-----
> From: Mikael Pettersson [mailto:mikpe@csd.uu.se]
> Sent: Friday, January 07, 2005 6:38 PM
> To: YhLu; ak@muc.de
> Cc: Matt_Domsch@dell.com; discuss@x86-64.org; jamesclv@us.ibm.com;
> linux-kernel@vger.kernel.org; suresh.b.siddha@intel.com
> Subject: Re: 256 apic id for amd64
>
> On Fri, 7 Jan 2005 22:12:00 +0100, Andi Kleen wrote:
> >On Fri, Jan 07, 2005 at 01:14:24PM -0800, YhLu wrote:
> >> After keep the bsp using 0, the jiffies works well. Werid?
> >
> >Probably a bug somewhere.  But since BSP should be always
> >0 I'm not sure it is worth tracking down.
>
> I hope by "0" you're referring to a Linux kernel defined
> software value and _not_ what the HW or BIOS conjured up!
>
> Case in point: I was involved a while ago in tracking down
> and fixing a local APIC enumeration bug in the x86-32 (i386)
> kernel code, where the kernel failed miserably on some
> dual K7 boxes because (a) only one CPU socket was populated,
> (b) the BIOS assigned that CPU a non-zero ID, and (c) the
> kernel (apic.c) had a bug which triggered when BSP ID != 0.
>
> Never trust a BIOS to DTRT.
>
> /Mikael

-- 
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm