osaf/services/saf/immsv/immd/immd_db.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
With the 2PBE patches applied and 2PBE configured, if si_swap:
immadm -o 7 safSi=SC-2N,safApp=OpenSAF
is attempted twice, then the second time will cause the new active SC to reboot.
This was caused by the cb->is_loading variable being initialized to true at
both active and standby SC, whwn it should only have been set to true in
the active. When true also in the standby it is not set to false by loading
completed. When the standby becomes active, it will not mbcp fevs messages
to new standby, despite that loading was done a long time ago. Next si swap
causes the new new active to start sending fevs messages way below the
expected fevs number. This causes the new new standby to crash.
diff --git a/osaf/services/saf/immsv/immd/immd_db.c
b/osaf/services/saf/immsv/immd/immd_db.c
--- a/osaf/services/saf/immsv/immd/immd_db.c
+++ b/osaf/services/saf/immsv/immd/immd_db.c
@@ -258,7 +258,9 @@ uint32_t immd_cb_db_init(IMMD_CB *cb)
cb->mRim = SA_IMM_INIT_FROM_FILE;
cb->mIs2Pbe = false;
cb->m2PbeCanLoad = true;
- cb->is_loading = true;
+ if(cb->ha_state == SA_AMF_HA_ACTIVE) {
+ cb->is_loading = true;
+ }
return (NCSCC_RC_SUCCESS);
}
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
