Most of the features of NATview will work right "out of the box" – this is how the software was designed and how it is intended to be used. Nevertheless there are situations where even NATview needs some assistance from the user. The hot swap configuration may be such a thing.
Why is this so?
It has something to do with different MCH firmware versions and the way that they provide the hot swap state of the FRU devices.
A short review of the MCH firmware history might lead to a better understanding about what is going wrong here.
The early MCH firmware versions up and including release 2.17.13 did provide no means to read out the current M-state of FRU. The only tools at hand were the mandatory hot swap sensor of the FRU plus the SEL events for the state changes. The hot swap sensor provided the status of the hot swap leaver: if it was pulled out or pushed in. Together with the overall status of the FRU NATview was able to assume these three M-states:
M0 | FRU removed |
M1 | FRU inserted, hot swap handle is pulled |
M4 | FRU fully operational, hot swap handle is pushed in |
This hot swap sensor had the sensor type 0xf2.
The whole thing changed with release 2.17.14 when the carrier provided (logical) hot swap sensors for every FRU device. First these sensors were grouped together under FRU 0 (the carrier FRU). Now it was the problem for the system software to assign the correct carrier hot swap sensor to its appropriate FRU device. This has been finally solved by assigning the same Entity ID and Entity Instance ID to the new hot swap sensors as has been to the FRU Device Locator Records. That way the (host) system software can attach the new hot swap sensors to the right FRU device as it does with the rest of the sensors.
The new hot swap sensors value is not the status of a hot swap handle but an M-state bit field that looks like this:
Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
undef. | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
This new hot swap sensor has the sensor type 0xf0.
NATview now needs to know which sensor type it shall use tro determine the M-state of the FRU devices. It is capable to read out the MCH firmware release major and minor version, but it cannot read out the subminor version.
(This is actually a limitation of the IPMI specification.)
It also knows that all MCH firmware releases up to version 2.16 used hot swap sensor type 0xf2. It finally knows that all MCH firmware releases starting with 2.18 provide the better new hot swap sensor type 0xf0.
Tricky are all releases with version 2.17.x – for these releases it is up to the NATview user to configure the software correctly. This is done in the IPMI settings:
These are the correct settings for the different MCH firmware releases:
MCH firmware release | Hot Swap Sensor Type |
≤ 2.17.13 | 0xf2 |
≥ 2.17.14 | 0xf0 |