Bug 450694

Description of problem:
The ipr_init command, an IPR user space daemon saves the adapter configuration
set by the ipr_config utility so that the adapter status can be restored
if a bad adapter needs to be replaced.

Unlike other adapter attributes, the preferred primary attribute can be changed
autonomously by the adapter firmware. When ipr_init finds that the preferred
primary attribute does not match the value set by ipr_config, it restores the
attribute value.

In a HA configuration with two systems when the ipr_init on host#1 restores the
prefferred primary attribute, it will cause a failover and change the
prefferred primary attribute on the adapter in host#2. When the ipr_init on
host#2 detects the prefferred primary attribute is changed and restores the
attribute, a failover happens again. The prefferred primary attribute will
ping/pong between the two hosts and cause an infinite failover loop between the two.

Since the preferred primary attribute is not solely controlled by ipr_config,
ipr_init should not restore its value. Instead, it should always re-read it
from the adapter. The ipr_init code in iprutils will be changed to implement
this change.

Version-Release number of selected component (if applicable):
2.2.8

How reproducible:
100%

Steps to Reproduce:
1. Requires two partitions equipped with SAS IOA adapters (572A cadet or 572B
squib) in two seperate partitions configured in a Dual Controller HA environment.
2. On partition A use iprconfig option 7 to work with adapters to set the SAS
adapter as the preferred primary. Wait a few minutes to allow any failover to
take place.
3. On partition B repeat the step to set it's SAS ioa adapter to be
the preferred primary. Both are now set as the preferred primary.

Actual results:
The systems will continuely failover to each other, as each IOA tries to assert
it's preferred primary status. 

Expected results:
No failover loop.

Additional info:
This can be triggered in practise for e.g. when a failed card (that had the
preferred primary attribute set) is replaced. Since the firmware will have moved
the attribute to the other host's adapter, replacing the adapter and having
ipr_init restore the attribute on the replaced adapter will trigger the same
looping failover behavior.

This is fixed upstream in iprutils 2.2.9.