Hi William,
Could you see if this series fixes it?
http://openvswitch.org/pipermail/dev/2016-May/071190.html
Thanks,
Daniele
2016-05-17 9:04 GMT-07:00 William Tu :
> Hi Joe,
>
> I did a quick try and the error is still there.
>
> Regards,
> William
>
> On Mon, May 16, 2016 at 8:09 PM, Joe Str
Hi Joe,
I did a quick try and the error is still there.
Regards,
William
On Mon, May 16, 2016 at 8:09 PM, Joe Stringer wrote:
> Hi William, could you try this fix? (I'm getting hard failures on
> those OVN tests on my dev box, likely something unrelated..)
>
> http://patchwork.ozlabs.org/patch
Hi William, could you try this fix? (I'm getting hard failures on
those OVN tests on my dev box, likely something unrelated..)
http://patchwork.ozlabs.org/patch/622833/
On 14 May 2016 at 17:13, William Tu wrote:
> Hi Ben,
>
> Thanks, I applied diff below. Unfortunately it makes no difference.
>
Hi Ben,
Thanks, I applied diff below. Unfortunately it makes no difference.
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -402,7 +402,7 @@ udpif_create(struct dpif_backer *backer, struct dpif
*dpif)
atomic_init(&udpif->n_flows, 0);
atomic_init(&udpif->n_flow
That's a really weird one.
This is for an unusual code path: it's an OpenFlow packet-out, that gets
executed via dpif_netdev, which causes recirculation, which installs a
new datapath flow. I wonder whether somehow this bypasses a normal
initialization step through some weirdness.
Does it make a
Hi,
Valgrind testcase 2029: ovn -- 3 HVs, 3 LS, 3 lports/LS, 1 LR reports
acquiring an uninitialized mutex_lock at ovs_mutex_lock(&umap->mutex). It
seems that udpif_create() already initializes all the mutex_lock of
udpif->ukeys. I have no clue about how to solve it. Any comments are
appreciated.
