OK, I'll look closer.
On Thu, Dec 13, 2018 at 12:13:16PM +1300, Josh Bailey wrote:
> Just tried it - frustratingly, this seems to cause the vswitchd disappears
> with status 0/no coredump scenario.
>
> 2018-12-12T23:07:01.485Z|2|daemon_unix(monitor)|INFO|pid 23736 died,
> exit status 0, exiti
Just tried it - frustratingly, this seems to cause the vswitchd disappears
with status 0/no coredump scenario.
2018-12-12T23:07:01.485Z|2|daemon_unix(monitor)|INFO|pid 23736 died,
exit status 0, exiting
I ran with vlog DBG and it didn't seem to print anything more than that.
What a puzzle!
Thanks for testing.
I discovered that this exact patch causes another problem. I posted a
slight revision without that issue. Would you mind re-testing? Thanks
a lot.
The new version is here:
https://patchwork.ozlabs.org/patch/1012261/
On Tue, Dec 11, 2018 at 12:35:15PM +1300, Josh Bailey wro
Yes sir. That fixes it - vswitchd no longer crashes.
Thanks,
On Tue, Dec 11, 2018 at 12:31 PM Ben Pfaff wrote:
> Here's a more specific patch that, if my hypothesis is correct, would
> solve the issue.
>
> diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c
> index 7c0f16b321f1..ebee5817710e 10
Here's a more specific patch that, if my hypothesis is correct, would
solve the issue.
diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c
index 7c0f16b321f1..ebee5817710e 100644
--- a/ofproto/connmgr.c
+++ b/ofproto/connmgr.c
@@ -1493,7 +1493,7 @@ ofconn_receives_async_msg(const struct ofconn *ofc
I tried this patch on top of 2.10.1.
vswitchd now crashes with status 0 so no coredump when I run the original
repro scenario (we can reproduce the problem on two different machines).
2018-12-10T21:33:30.934Z|2|daemon_unix(monitor)|INFO|pid 4829 died,
exit status 0, exiting
A bad pointer so
Probably, this is a different issue. My guess is that the connection in
question doesn't have an OpenFlow protocol at the moment. We've dealt
with problems like this before, see e.g. commit 903f6c4f8a9b ("connmgr:
Fix vswitchd abort when a port is added and the controller is down").
Either that f
The problem happens with OpenFlow 1.0 and 1.3. I am not aware of any
possibility that Ryu could be configured to use an unsupported version, and
even if so I would imagine OVS would reject the connection at the Hello
stage.
On Tue, Dec 11, 2018, 09:16 Flavio Leitner
> Looks like you're using an u
Looks like you're using an unsupported OpenFlow protocol:
https://github.com/openvswitch/ovs/blob/5f361a2a320717c46289fc30d65a186f2f5d3ba0/lib/ofp-protocol.c#L123
I see that you are configuring a controller in OVS and you are
running Ryu, maybe it's using the wrong protocol version?
fbl
On Tue
Certainly:
2018-12-04 21:23:59 josh #1 0x7f870edf9801 in __GI_abort () at
abort.c:79
2018-12-04 21:23:59 josh #2 0x5634f368e0a8 in
ofputil_protocol_to_ofp_version (protocol=) at
lib/ofp-protocol.c:123
2018-12-04 21:23:59 josh #3 0x5634f36890ae in
ofputil_encode_port_status (ps=ps@
On Wed, Dec 05, 2018 at 12:11:28PM +1300, Josh Bailey via discuss wrote:
> Hello OVS colleagues,
>
> vswitchd appears to crash handling a port add/mod. Please see following to
> reproduce.
>
> Run two Ryu OF controllers:
>
> $ ryu-manager --ofp-tcp-listen-port 6653 --ofp-listen-host 127.0.0.1
>
Hello OVS colleagues,
vswitchd appears to crash handling a port add/mod. Please see following to
reproduce.
Run two Ryu OF controllers:
$ ryu-manager --ofp-tcp-listen-port 6653 --ofp-listen-host 127.0.0.1
--verbose --app-lists ryu.app.simple_switch_stp
$ ryu-manager --ofp-tcp-listen-port 6654
12 matches
Mail list logo
