Hi,
Dale Ghent wrote:
> So I've been watching with some degree of fascination as to what's
> been going on in the usr/src/lib/fm/topo/maps/ corner of onnv-gate and
> would like to learn more about this stuff.
Rob Johnston can tell all here.
> What I understand so far, is that topo maps basically provide hints to
> FMA (via libtopo) about the nature of a specific system. Hard drives,
> bays, maintenance indicator lights, PSUs, temp sensors, fans, and so
> on. I guess this information enables fmd to, say, toggle on a x4540's
> maintenance lamp when some sort of fault is detected? I also see some
> references to IPMI.
That's correct. For fault diagnosis we need to understand what hardware
we have, how it is interconnected etc. Solaris did/does have another
technology for showing what is there - picl, but that involved
rather too little automated discovery and instead lots of brute-force
platform description and was not in a form suitable for expressing
diagnosis anyway.
So with libtopo v2 the emphasis is on automatic discovery and construction
of topology, via topology enumerators which are modules written in C
working to the enumerator API. Initially the map files really only
had the task of electing which enumerators to run for a given
platform type.
Since then we've begun to use the maps to provide some clues for things
we can't automate from the enumerators. Typically this has been
necessary on x86 platforms where the extant standards don't supply
all the information we need, or lack the correlation info required to
tie it to particular resources. We're trying to push some of these
requirements down to our BIOS/ILOM groups and eventually to standards,
but for now the maps provide a workaround clue such as:
- how, for a given set of platforms, to generate a dimm FRU label
given the chip and dimm instance numbers (expressed as a formatter
such as "CPU %d DIMM %d" and a choice of enumerator-provided
method to calculate the correct substitutions)
- what disk bays does this chassis have built in to it? Disk fma
is pretty much ready to go on any platform once you can tell
it what is there.
- given a dimm topology node what is the tag that ILOM refers to it
by in the fru data repository so that we can go there and
grab the serial and part number (rather than having to encode
i2c maps for the platform on the OS)
All of these will be automated some day, when we can get everyone
speaking the same or compatible language.
The other use has been to correct/override firmware when it has a bug in things
like slot labelling.
> I'm wondering if someone could shed some light on what maps generally
> accomplish. Also, could maps be generated for any system (say, a Dell
> PE1950, assuming that libtopo knows its running on a particular x86
> via what smbios reports) ?
Yes this can be done. The maps are the easy bit - it's obtaining the
raw data and interpreting it that can be tricky. So we could
easily add an entry for the Dell system you mention so that
it elects a dimm fru labelling method, and chances are
that it can use an existing method with perhaps a different
format string. But to really confirm which dimm topo node
corresponds to which physical dimm slot we need to know the
chip-select line routing on the motherboard, so we need
the board schematics.
Cheers
Gavin
_______________________________________________
fm-discuss mailing list
fm-discuss@opensolaris.org
