Using openhpi 2.14.0 with the oa-soap plugin, I have observed that on occasion after a blade is extracted and re-inserted, not all of the hotswap events are reported. Below is the result of a test I ran in which I pulled a blade and re-inserted it into the same bay. The output is the capture of the events generated by openhpid as reported by the hpi_shell utility with event logging enabled. You’ll see that the hot-swap transition from insertion-pending to active is never received. This leaves the resource in the insertion-pending state.
Event Type: HOTSWAP
From Resource: {SYSTEM_CHASSIS,50101}{SYSTEM_BLADE,4}
Event Resource ID: 5
Event Timestamp: 2009-05-07 13:51:44
Event Severity: CRITICAL
HotswapEvent:
HotSwapState: EXTRACTION_PENDING
PreviousHotSwapState: ACTIVE
Event Type: HOTSWAP
From Resource: {SYSTEM_CHASSIS,50101}{SYSTEM_BLADE,4}
Event Resource ID: 5
Event Timestamp: 2009-05-07 13:51:44
Event Severity: CRITICAL
HotswapEvent:
HotSwapState: INACTIVE
PreviousHotSwapState: EXTRACTION_PENDING
Event Type: HOTSWAP
From Resource: {SYSTEM_CHASSIS,50101}{SYSTEM_BLADE,4}
Event Resource ID: 5
Event Timestamp: 2009-05-07 13:52:39
Event Severity: OK
HotswapEvent:
HotSwapState: NOT_PRESENT
PreviousHotSwapState: INACTIVE
Event Type: HOTSWAP
From Resource: {SYSTEM_CHASSIS,50101}{SYSTEM_BLADE,4}
Event Resource ID: 5
Event Timestamp: 2009-05-07 13:56:39
Event Severity: OK
HotswapEvent:
HotSwapState: INSERTION_PENDING
PreviousHotSwapState: NOT_PRESENT
This does not occur every time, but seems to occur much more frequently if multiple blades are pulled and then re-inserted at the same time. My test enclosure was fully populated with 16 compute blades and 4 switches.
Patch by Mohan which fixes this problem.
Now the code is changed to take care of the out of order events. Patch attached to the defect is checked in.