Re: 256 apic id for amd64
From: James Cleverdon (jamesclv_at_us.ibm.com)
Date: 01/11/05
- Previous message: Mike Waychison: "Re: [patch] Per-sb s_all_inodes list"
- In reply to: YhLu: "RE: 256 apic id for amd64"
- Next in thread: Siddha, Suresh B: "Re: 256 apic id for amd64"
- Reply: Siddha, Suresh B: "Re: 256 apic id for amd64"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: YhLu <YhLu@tyan.com> Date: Mon, 10 Jan 2005 16:42:41 -0800
Greetings YH,
That patch will cause phys_proc_id[] to contain incorrect information
for IBM x366 systems. There is a reason why phys_pkg_id() indirects
through the subarch table -- it does so because cpuid returns stale
data when the APIC ID registers are rewritten by the x366 BIOS. The
BIOS must rewrite those registers as part of system probing and
configuration (i.e. Nocona chips can't latch all 8 bits of APIC ID at
reset time, and we will need all 8 bits real soon).
Personally, I don't have any problem with replacing the non-power-of-2
code with "hweight32(c->x86_num_cores - 1)", but folks at Intel have
been very insistent that it may be needed in the future. Maybe Suresh
can speak up about Intel's interests here.
On Monday 10 January 2005 11:41 am, YhLu wrote:
> Please refer the patch.
>
> Regards
>
> YH
--
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Mike Waychison: "Re: [patch] Per-sb s_all_inodes list"
- In reply to: YhLu: "RE: 256 apic id for amd64"
- Next in thread: Siddha, Suresh B: "Re: 256 apic id for amd64"
- Reply: Siddha, Suresh B: "Re: 256 apic id for amd64"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
