On Tue, May 16, 2017 at 12:07:38PM +0800, ychen wrote:
> I can reproduce this problem with the script supported by vguntaka in both
> ovs version 2.5 and ovs version 2.6.
>
> 1. Add bridge
>
> ovs-vsctl add-br br0
>
>
>
> 2. Add vm port
>
> ovs-vsctl add-port br0 tap0 – set
I can reproduce this problem with the script supported by vguntaka in both ovs
version 2.5 and ovs version 2.6.
1. Add bridge
ovs-vsctl add-br br0
2. Add vm port
ovs-vsctl add-port br0 tap0 – set interface tap0 type=internal
ip netns add ns0
ip link set dev tap0 netns ns0
Confirmed, can be easily reproduced using described method.
Using ovs 2.6.2
On 01/23/2017 11:58 PM, Vidyasagara Guntaka via dev wrote:
Hi Ben,
We could reproduce this with the latest version 2.6.1. When we compiled the
code, we removed -O2 from CFLAGS. This seems to make it happen more
Hi Ben,
We could reproduce this with the latest version 2.6.1. When we compiled the
code, we removed -O2 from CFLAGS. This seems to make it happen more
frequently. With the following script running, the error starts happening
within a few seconds and then continues to happen after every few
If you can come up with simple reproduction instructions that work for
me, I'm happy to track this down. It's probably something very simple.
On Tue, Jan 17, 2017 at 08:50:20AM -0800, Vidyasagara Guntaka wrote:
> This issue happened on our in-use systems and we were trying to find a way
> to
This issue happened on our in-use systems and we were trying to find a way
to move forward avoiding this issue so that we do not have to upgrade OVS
on thousands of our hypervisors causing down time. Our debugging did help
us avoid the issue for now by installing an explicit rule to to drop
It would be more helpful to have a simple reproduction case.
Why haven't you tried a newer version from branch-2.5?
On Tue, Jan 17, 2017 at 07:59:05AM -0800, Vidyasagara Guntaka wrote:
> Hi Ben,
>
> Here i is more debug information related to this incident (still using
> version 2.5.0):
>
>
Hi Ben,
Here i is more debug information related to this incident (still using version
2.5.0):
Summary :
We think that there is some race condition involved in processing OF Controller
connections and Packet miss processing in ovs-vswitchd.
Reasoning :
Please consider the following GDB
Thanks for the quick follow up Ben,
So we'll indeed try against latest versions to rule out the possibility of
a bug that has been fixed already although I could not find any commit with
such mention. We'll report back here.
At this moment, we can reproduce over and over within minutes. We've
On Thu, Jan 12, 2017 at 03:54:42PM -0500, Samuel Jean via dev wrote:
> It seems that shelling out to ovs-ofctl very quickly can lead to bug where
> it reports an OFPT_ERROR.
>
> We were able to constantly reproduce within minutes of running the above
> flow modifications on Unbutu.
>
> Any help,
Hi,
It seems that shelling out to ovs-ofctl very quickly can lead to bug where
it reports an OFPT_ERROR.
We were able to constantly reproduce within minutes of running the above
flow modifications on Unbutu.
Any help, hints or guidance would be appreciated. I'd be happy to pursue
some
11 matches
Mail list logo