[fm-discuss] Proposal: libtopo eumeration of power supplies and fans via IPMI

[Scott Davenport]

On Tue, 2008-01-08 at 12:43 -0800, Cynthia McGuire wrote:
> 
> Eric Schrock wrote:
> 
> > It would certainly be nice to move 'motherboard' under the chassis as
> > well as the 'bay' nodes, but I know in the past it has been inferred
> > that doing so will break existing diagnoses.  Is it allowable to
> > rearrange the topology in this fashion?
> 
> Interface-wise, you may restructure the topology.  The path elements and 
> their construction is not considered an interface (or ARC'd) according 
> to the FMRI specification.  However, (as you noted) making such a change 
> could break diagnosis if the DE makes assumptions about the hc path.
> 
> For x64: CPU, mem and PCIE should all be fine as they use eft rules that 
> elide the 'motherboard' portion anyway.  (Check with Gavin and Stephen 
> Hanson to be sure).  I'm not sure about the disk diagnosis engine.
> 
> On SPARC: I'm almost certain there is software (DE or other) that 
> depends on the path construction.

Correct. On SPARC, at least in sun4v, the CPU/Mem DE manually constructs
FMRIs when producing suspect lists. It has internal knowledge of what
the FRU and ASRU FMRIs should be for a particular platform. If 'chassis'
were pre-pended, the DE would need to be updated as well.

The IO diag rules on SPARC are in EFT, and those should still work fine.
An example is the topology between a T2000 and T5120 are different, but
both use the fire.esc rules. All works because the relative arrangement
of hostbridge/pciexrc is the same.

-scott

> > 
> >>> Each component that is directly under the chassis will be assigned a FRU
> >>> matching its resource.  
> >> What does this statement mean?  Are you saying that the FRU property for 
> >> a topo node directly under 'chassis' will be equal to the resource 
> >> property?  What does the FRU label property look like?
> >>
> >> Components within an association will default to
> >>> the FRU of their parent, unless they have associated FRU locator
> >>> records, in which case they will have a distinct FRU matching their
> >>> resource.
> >> The paragraphs above use the acronym, FRU, to mean FRU label and FRU 
> >> FMRI.  Both of which are properties for a give topo node.  Please be 
> >> clear about which you're talking about.
> > 
> > In these statements the term FRU refers to the FMRI, not the label.
> > We're not 100% sure on what to use for the label, but the default will
> > likely be a per-chassis incremented counter of the form "FAN %d" and
> > "PSU %d".  Unfortunately, there is no label property available via IPMI.
> > We could use a heuristic that would work for Sun ILOM platforms
> > ("ft0.fm1.fru" -> "ft0.fm1"), but the naming of SDR records is
> > arbitrary.  We could also do "FM %d FAN %d" instead of the global
> > identifier, which is probably closer to what would be silkscreened on
> > the chassis.
> > 
> > When dealing with fanmodules and fans, the following would be a
> > reasonable topology:
> > 
> > 	hc:///chassis=0/fanmodule=0
> > 	    FRU: hc:///chassis=0/fanmodule=0
> > 	    label: FM 0
> > 
> > 	hc:///chassis=0/fanmodule=0/fan=0
> > 	    FRU: hc:///chassis=0/fanmodule=0
> > 	    label: FM 0 FAN 0
> > 
> > 	hc:///chassis=0/fanmodule=0/fan=1
> > 	    FRU: hc:///chassis=0/fanmodule=0
> > 	    label: FM 0 FAN 1
> > 
> > 	hc:///chassis=0/fanmodule=1
> > 	    FRU: hc:///chassis=0/fanmodule=1
> > 	    label: FM 0
> > 
> 
> Are there (silk-screened) labels assigned on the physical machines?  Is 
> it possible to track the components by some serial ID or other identity 
> information?
> 
> Cindi
> _______________________________________________
> fm-discuss mailing list
> fm-discuss at opensolaris.org