Hi Ben, It might be harmless, but it is followed by tons of similar errors and why errors anyway?. Also, there is not a single such error on the first start of controller. Only when I kill the fist instance and start it again those error occur and the switch is acting erratically. Removing the dp interface in between also does not help.
Any ideas? Andreas ----- Original Message ----- > On Wed, Oct 19, 2011 at 01:23:53PM +0200, Andreas Schultz wrote: > > Hi all, > > > > Upon further investigation it turns out the the dpif_linux_open() > > sequence > > is broken somewhere. The flow of netlink messages simply makes no > > sence at > > all. > > > > first we get an create attempt, which is expected to fail since the > > DP already exists: > > Oct 19 11:07:52|00014|netlink_socket|DBG|nl_sock_recv__ (Success): > > nl(len:60, type=2(error), flags=0, seq=4e9ef0dc, > > pid=25535(25535:0)) error(-17(File exists), in-reply-to(nl(len:40, > > type=33(ovs_datapath), flags=d[REQUEST][ACK][ECHO], seq=4e9ef0dc, > > pid=25535(25535:0)))) > > Oct 19 11:07:52|00015|netlink_socket|DBG|received NAK error=17 > > (File exists) > > > > now it tries OVS_DP_CMD_GET: > > Oct 19 > > 11:07:52|00016|netlink_socket|DBG|nl_sock_transact_multiple__ > > (Success): nl(len:32, type=33(ovs_datapath), > > flags=d[REQUEST][ACK][ECHO], seq=4e9ef0dd, > > pid=25535(25535:0)),genl(cmd=3,version=1) > > Oct 19 11:07:52|00017|netlink_socket|DBG|nl_sock_recv__ (Success): > > nl(len:84, type=33(ovs_datapath), flags=0, seq=4e9ef0dd, > > pid=25535(25535:0)),genl(cmd=1,version=1) > > > > and succeeds. So far so good... > > > > Next step is to flush any old flows: > > Oct 19 > > 11:07:52|00018|netlink_socket|DBG|nl_sock_transact_multiple__ > > (Success): nl(len:24, type=35(ovs_flow), flags=5[REQUEST][ACK], > > seq=4e9ef0de, pid=25535(25535:0)),genl(cmd=2,version=1) > > > > send that to the kernel... > > > > and the kernel give us a netlink error report for the > > OVS_DP_CMD_GET that was already ACKed OK: > > Oct 19 11:07:52|00019|netlink_socket|DBG|nl_sock_recv__ (Success): > > nl(len:36, type=2(error), flags=0, seq=4e9ef0dd, > > pid=25535(25535:0)) error(0, in-reply-to(nl(len:32, > > type=33(ovs_datapath), flags=d[REQUEST][ACK][ECHO], seq=4e9ef0dd, > > pid=25535(25535:0)))) > > Oct 19 11:07:52|00020|netlink_socket|DBG|ignoring unexpected seq > > 0x4e9ef0dd > > > > I have verified above sequence with strace and the decoded netlink > > messages where indeed send to and received from the kernel. So it > > is not a buffering issue in the controller. > > This is a red herring. It's very common for a Netlink request to > have > two replies when the ACK flag is set, because the kernel > unconditionally > sends an "error" reply after the command implementation itself sends > any > reply of its own. We just ignore the second reply in userspace; it's > harmless. > -- -- Dipl. Inform. Andreas Schultz _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
