osaf/services/saf/immsv/immd/immd_cb.h | 3 ++
osaf/services/saf/immsv/immd/immd_main.c | 36 ---
osaf/services/saf/immsv/immd/immd_mds.c | 20 -
3 files changed, 53 insertions(+), 6 deletions(-)
IMMD will wait for intro message from veterans an
Summary: imm: Wait for veterans when IMMD starts [#1698]
Review request for Trac Ticket(s): 1698
Peer Reviewer(s): Zoran, Neel
Pull request to:
Affected branch(es): 5.0
Development branch: 5.0
Impacted area Impact y/n
Docs
Hi Lennart,
Thanks for you finding. In future I think we need to add more ntftest
cases for using NTF API in threads concurrently. We had a few.
I will publish next version patch
Thanks,
Minh
On 09/03/16 22:57, Lennart Lund wrote:
> Hi Minh,
>
> I found a function checkNtfServerState() that rea
Hi Praveen
Thanks for PoC patch, I have been reading your patch, and here is my
understanding, please correct me if I am wrong.
The approach of the patch in general is trying to pretend there's no
headless gap, the operations before headless will resume after SC comes
back.
To achieve this, nod
Ack for the series.
Regards, Vu.
>-Original Message-
>From: Minh Hon Chau [mailto:minh.c...@dektech.com.au]
>Sent: Tuesday, March 01, 2016 2:30 PM
>To: lennart.l...@ericsson.com; praveen.malv...@oracle.com;
>vu.m.ngu...@dektech.com.au; minh.c...@dektech.com.au
>Cc: opensaf-devel@lists.sou
Hi Minh,
I found a function checkNtfServerState() that read the global ntfa_ntfsv_state
variable. This function does not protect the variable with a mutex. The
corresponding ntfa_update_ntfsv_state() is called when mutex is locked but the
checkNtfServerState() is not, this is not thread safe.
Ack for the series with minor comments below:
-Most of the information of README must go in PR doc especially
unavailability of old alarms through reader APIs after headless state is
observed.
-I think recovery of clients must be done as early as possible after
first controller joins. For this
Good that you provided the description.
Ack,
Mathi.
- vu.m.ngu...@dektech.com.au wrote:
> osaf/libs/agents/saf/lga/lga_mds.c | 42
> -
> 1 files changed, 36 insertions(+), 6 deletions(-)
>
>
> The log agent on defaul branch (5.0) was not backward compat
osaf/services/saf/amf/amfd/sg_nway_fsm.cc | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
After the nway application AMF entities are created, active amfd calls
avd_sg_nway_si_assign
function to assign any unassigned SI but all SUs are locked so no SI are
assigned
and the FSM is still
Summary: amfd: do not checkpoint the nway sg fsm in case of no change [#1697]
Review request for Trac Ticket(s): #1697
Peer Reviewer(s): Hans, Gary, Nagu, Praveen
Pull request to: Hans
Affected branch(es): all
Development branch: default
Impacted area Impact
I just realized that the symptoms you see could be caused by using a too
old "patch" tool. Please try either with a newer version of the "patch"
command, or by using Mercurial for applying the patches (e.g. "hg
qimport patch_file.diff; hg qpush").
regards,
Anders Widell
On 03/09/2016 10:39 AM,
Hi!
The patches are based on changeset 7290:b4e2c14d222b which was the most
recent changeset on the default branch when the patches were sent out.
If necessary, you may have to go back to that changeset. Alse, please
check that you have applied the RDE patches in the correct order:
1) rde: Con
12 matches
Mail list logo
