Hi Gavin,
On 03/03/09 19:06, Gavin Maltby wrote:
Hi Tom,
Tom Pothier wrote:
Currently we plan to use the PRI to only enumerate to the base board
level; then call chip.so to enumerate chip/core/strand and memory
topology.
... but chip.so relies on the hacky xml and enumerator method trick to
write FRU labels for CPU and DIMM - would we be able to elimanate that?
The goal is to get FRU labels for CPU and DIMM from SMBIOS; and to move
away from xml trickery :-) .
There's another wrinkle here that is difficult to address. chip.so
constructs a chip/core/strand topo using the info passed up from
the kernel (/dev/fm). The chip node instance numbers come from
what the kernel has chosen as that chip id in cpuid.c; this comes
from the InitialApicId CPUID info.
On AMD Opteron systems the chip component of the InitialApicId is the
NodeId that was assigned by BIOS (I think BSP is node 0 out of reset
while all ASP are node 7; the BSP then writes to the NodeId registers
of the ASPs with the node id it chooses for them). In this way the
NodeId (ultimately topo chip instance number) is not a physical
thing - i.e., not hardwired. HT requires that nodes are numbered
contiguously from 0.
So .. why is that important? Well on systems like the X4600 the
nodeid of a cpu module is dependent on the total number of
modules present. So module B might be nodeid 1 in an
8 chip config, but nodeid 3 in a 4 chip config (exact
assignments forgotten). Thus if module B is bad and
we start to collect some evidence we'll be serd'ing
on chipid 3 on a 4 chip system but then continue
on chipid 1 if the system config is upgraded to 8 chips.
Similarly on the A2F blades they can have 2 or 4 chip
present - node 1 maps to two different chips there too.
With this new enumerator we'll have serial numbers to differentiate
processor sockets/chips.
So we really need to determine instance numbers by
physical position - in most cases today that is the case
but it is defeated on X4600 and A2F. On Intel systems
including, I believe, QuickPath systems the InitialApicId
is a physically-derived value so no problem there.
For this project we're starting the process (a proposal has been sent
about in Sun) to amend the SMBIOS to extend the Type 4 structure to
include the APIC IDs of each strand of the processor socket/chip.
In our SMBIOS requirements document we've required that the order of the
Type 4 structures be the same as the physical ordering of the processor
socket/chips they describe.
Since it's the BIOS that assigns the NodeIDs, and knows about the APIC
IDs, we should have fairly high confidence that we're describing the
correct processor.
thx,
-t
Thanks
Gavin
_______________________________________________
fm-discuss mailing list
fm-discuss@opensolaris.org
