3. X86 EREPORT GENERATION
On x86 systems, ereport detector and resource fmri are hard-coded to
motherboard/chip/core/strand. This is in contrast to what the the x86
Generic
FMA Topology Enumerator proposes to create
(chassis/baseboard/chip/core/strand).
This project will produce a common set of data where both x86 ereport
detectors as well as the x86 topo provider gathers it's data. This
will ensure
the ereport detector and FRU fmri are always in sync.
I hate to suggest it, but something aking to the PCI fabric-xlate
functionality may
help here. Our detector is some chip/core/strand but we may not
know the instance numbers in the kernel, especially early in boot.
We can't use cpuid as it is meaningless in xVM, and pretty meaningless
when you manually browse ereport logs. So if cpu/mem ereports
detected at a cpu simply note the ApicId of the detector
(readily available both natively and xVM) then when we
receive the ereport in userland we can rewrite the detector
to the correct chip/core/strand based on ApicId match.
This could require the topology snapshot stuff (for
ereports replayed over a panic during which the
hardware configuration changes).
We did discuss this area with Scott a few weeks back, but I don't think we
got to a resolution. Building the hc-scheme enumeration into the kernel
drivers
doesn't seem right and would have limitations on what information is
available
in kernel context particularly in early boot or under XVM.
Using a cpu scheme detector (as we used to do on sparc) would avoid this
problem. Eversholt would automatically convert to hc sheme by querying topo
(no need for a xlate module). As Gavin says without topo snapshot
support this
could go wrong if the hardware config was changed over a panic reboot (does
that actually work in the existing code either though?), and we might
have to
extend cpu sheme for XVM to include ApicId instead of/as well as cpuid.
Theoretically another option would be to put the serial number in the
ereport
instead of a "detector" fmri - that's what is done for disks, but as we
don't have
serial numbers for cpus that doesn't really help.
4. TOPOLOGY CHANGES
The x86 Generic FMA Topology Enumerator will be installed on a i86pc
class
system as:
$ROOT/usr/platform/i86pc/lib/fm/topo/plugins/x86pi.so
>
The i86pc XML topology map will be modified to invoke the x86pi.so
enumerator.
The existing i86pc XML topology map will be moved to a "legacy" map.
Prepending chassis/baseboard instead of motherboard may well have
issues for existing diagnosis state - serd engines not yet fired
(will die off in time and be cleaned up), cached faults etc.
We don't really have a good answer for change of topology
like this - so look out for one!
That's only a problem if currently supported platforms are converted to
use the
new topology. Is that the plan? Or would they all continue to use the
"legacy" map
and only new platforms would use the new mechanism?
Steve
_______________________________________________
fm-discuss mailing list
fm-discuss@opensolaris.org
