I mean keep the bsp physical apic id using 0.
YH
-----Original Message-----
From: Mikael Pettersson [mailto:[email protected]]
Sent: Friday, January 07, 2005 6:38 PM
To: YhLu; [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]
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
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:[email protected]]
> Sent: Friday, January 07, 2005 6:38 PM
> To: YhLu; [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> 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