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? 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. 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. Thanks Gavin _______________________________________________ fm-discuss mailing list fm-discuss@opensolaris.org
