Thanks,
installed that in the test env, after a manual reboot I got:
$ uname -a
Linux autopkgtest 4.15.0-34-generic #38~lp1736390Commit12064551Reverted SMP Thu Sep 13 13:28:33 UTC i686 i686 i686 GNU/Linux
The change is persistent into the autopkgtest:
autopkgtest [05:11:17]: testbed running kernel: Linux 4.15.0-34-generic #38~lp1736390Commit12064551Reverted SMP Thu Sep 13 13:28:33 UTC
The test kernel works fine where the other one failed.
To be sure I ran it multiple times and with different cpu options enables in KVM (e.g. to also run the DPDK tests which need sse3).
But they all worked, no crash.
That said - yes reverting that change seems to be the solution.
Yet for what was it needed and what would break if it is reverted?
Add a new optional conntrack action attribute OVS_CT_ATTR_EVENTMASK,
which can be used in conjunction with the commit flag
(OVS_CT_ATTR_COMMIT) to set the mask of bits specifying which
conntrack events (IPCT_*) should be delivered via the Netfilter
netlink multicast groups. Default behavior depends on the system
configuration, but typically a lot of events are delivered. This can be
very chatty for the NFNLGRP_CONNTRACK_UPDATE group, even if only some
types of events are of interest.
Netfilter core init_conntrack() adds the event cache extension, so we
only need to set the ctmask value. However, if the system is
configured without support for events, the setting will be skipped due
to extension not being found.
That is odd, I thought in the past we had identified an Ubuntu-sauce patch, but that is a normal upstream change.
I'd hope that other are affected as well and this is fixed, or could it be that we are affected by 1206455 due to some Ubuntu-sauce?
For the sake of checking if latest upstream (no sauce and 4.19-rc3) might be better I ran the latest mainline kernel.
autopkgtest [05:21:50]: testbed running kernel: Linux 4.19.0-041900rc3-generic #201809120832 SMP Wed Sep 12 12:47:16 UTC 2018
But that is crashing still.
@James: can you estimate what we loose on non-i386 when reverting that change for now?
@Joseph: what would we do now, report upstream - if so what exactly a description and link sent to the author and the ML as we don#t have a fix yet?
Thanks,
installed that in the test env, after a manual reboot I got:
$ uname -a mmit12064551Rev erted SMP Thu Sep 13 13:28:33 UTC i686 i686 i686 GNU/Linux
Linux autopkgtest 4.15.0-34-generic #38~lp1736390Co
The change is persistent into the autopkgtest: mmit12064551Rev erted SMP Thu Sep 13 13:28:33 UTC
autopkgtest [05:11:17]: testbed running kernel: Linux 4.15.0-34-generic #38~lp1736390Co
The test kernel works fine where the other one failed.
To be sure I ran it multiple times and with different cpu options enables in KVM (e.g. to also run the DPDK tests which need sse3).
But they all worked, no crash.
That said - yes reverting that change seems to be the solution.
Yet for what was it needed and what would break if it is reverted?
commit 120645513f55a4a c5543120d9e7992 5d30a0156f
Author: Jarno Rajahalme <email address hidden>
Date: Fri Apr 21 16:48:06 2017 -0700
openvswitch: Add eventmask support to CT action.
Add a new optional conntrack action attribute OVS_CT_ ATTR_EVENTMASK, CT_ATTR_ COMMIT) to set the mask of bits specifying which CONNTRACK_ UPDATE group, even if only some
which can be used in conjunction with the commit flag
(OVS_
conntrack events (IPCT_*) should be delivered via the Netfilter
netlink multicast groups. Default behavior depends on the system
configuration, but typically a lot of events are delivered. This can be
very chatty for the NFNLGRP_
types of events are of interest.
Netfilter core init_conntrack() adds the event cache extension, so we
only need to set the ctmask value. However, if the system is
configured without support for events, the setting will be skipped due
to extension not being found.
That is odd, I thought in the past we had identified an Ubuntu-sauce patch, but that is a normal upstream change.
I'd hope that other are affected as well and this is fixed, or could it be that we are affected by 1206455 due to some Ubuntu-sauce?
For the sake of checking if latest upstream (no sauce and 4.19-rc3) might be better I ran the latest mainline kernel.
autopkgtest [05:21:50]: testbed running kernel: Linux 4.19.0- 041900rc3- generic #201809120832 SMP Wed Sep 12 12:47:16 UTC 2018
But that is crashing still.
@James: can you estimate what we loose on non-i386 when reverting that change for now?
@Joseph: what would we do now, report upstream - if so what exactly a description and link sent to the author and the ML as we don#t have a fix yet?