yeah, I can only reproduce it on my VM setup by running command like this:
for i in `seq 1 1000`; do make check TESTSUITEFLAGS=12 1>/dev/null
2>file_make_check; if cat file_make_check | grep "ERROR: 1 test was run";
then echo FAIL; break; fi; done
and wait a long time.
But the issue is valid. L
Curious. I can't seem to reproduce the occasional fault in my VM
setup. I'm happy to fold in the change that you suggested though Alex.
(Incremental below)
diff --git a/tests/cfm.at b/tests/cfm.at
index 620e3e0..fe6778a 100644
--- a/tests/cfm.at
+++ b/tests/cfm.at
@@ -90,12 +90,9 @@ CFM_VSCTL_LIST
Thanks for the detail, I'll look into it.
On 12 December 2013 21:50, Alex Wang wrote:
> Yes, I could reproduce it on my VM setup,
>
> It is the timing issue again, if the p1 starts sending ccm first, it will
> have flap count = 0.
>
> If p1 receives ccm from p0 first, it will go to [rdi] and then
Yes, I could reproduce it on my VM setup,
It is the timing issue again, if the p1 starts sending ccm first, it will
have flap count = 0.
If p1 receives ccm from p0 first, it will go to [rdi] and then []. so it
will have flap count = 2.
I think the safest way is to drop the "CFM_VSCTL_LIST_IFACE
This patch occasionally fails the cfm flap count test for me. Can
either of you reproduce it?
Ethan
On Thu, Dec 12, 2013 at 5:52 PM, Joe Stringer wrote:
> Currently, every time a monitoring port is added or reconfigured, the
> main thread notifies the monitoring thread to wake up immediately us
Currently, every time a monitoring port is added or reconfigured, the
main thread notifies the monitoring thread to wake up immediately using
monitor_seq. When adding a large number of ports at once, this causes
contention as the threads fight over access to the monitor heap---one
thread adding new
