Please refer the patch.
Regards
YH
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
On Mon, Jan 10, 2005 at 11:41:02AM -0800, YhLu wrote:
> Please refer the patch.
That's unreadable. Can you generate against a recent BK snapshot
(2.6.10 + latest from ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/)
and use diff -u ?
-Andi
On Mon, Jan 10, 2005 at 04:42:41PM -0800, James Cleverdon wrote:
> 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.
IA32 SDM vol3 section 7.7.5 talks about the recommended way of computing
physical processor package id. Current kernel code which is doing this,
can definitely be made more readable. I will do that when ever I get
a chance.
thanks,
suresh
On Mon, Jan 10, 2005 at 07:28:47PM -0800, Siddha, Suresh B wrote:
> Current kernel code which is doing this,
> can definitely be made more readable. I will do that when ever I get
> a chance.
That would be nice yes.
-Andi