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.
>
>>> 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@opensolaris.org
