On Mon, Jul 20, 2026 at 4:22 PM Ilya Maximets <[email protected]> wrote: > > On 7/20/26 3:03 PM, David Marchand wrote: > > On Mon, 20 Jul 2026 at 12:48, Dmitry Mityugov via discuss > > <[email protected]> wrote: > >> > >> Hi, > >> > >> It seems that test 1262 ("ofproto-dpif - fragment handling - > >> reassembly") is flaky, and when run on an ARM machine and with > >> --enable-shared configure parameter, it almost always fails. It also > >> sometimes fails on x86 machines and on ARM machines without > >> --enable-shared. Running `make check TESTSUITEFLAGS=--recheck` usually > >> fixes these random failures. > >> > >> To reliably reproduce the problem, this command can be used, on an ARM > >> machine: > >> > >> make distclean ; ./boot.sh && ./configure --enable-shared && make -j9 > >> && make check RECHECK=yes TESTSUITEFLAGS=-j8 > >> > >> I used Orange Pi 6 Plus and Rock Pi 5b ARM machines to reproduce this, > >> with Arch Linux (kernel 7.x) and Armbian (kernel 6.18). I'm attaching > >> relevant files. Please let me know if I can help further. > > > > From the logs, we are missing a flow in the dump: > > -recirc(),in_port(90),packet_type(ns=0,id=0),eth(src=22:22:22:22:22:22),eth_type(0x0800),ipv4(src=2.2.2.2/248.0.0.0,proto=6,frag=first), > > packets:0, bytes:0, actions:ct(commit,zone=10),recirc() > > > > > > This flow is a consequence of receiving the first fragment: > > 2026-07-20T10:29:34.952Z|00121|unixctl|DBG|received request > > netdev-dummy/receive["p90","1111111111112222222222220800450001d4123420004006dead020202020101010100020001000000000000000050020000a9da00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"], > > id=0 > > > > And the flow dump happens at: > > 2026-07-20T10:29:46.280Z|00393|unixctl|DBG|received request > > dpctl/dump-flows[], id=0 > > > > So my guess is that the "first" flow expired after 10s, probably due > > to some external activity on the system running the test. > > > > Looking at my recent change, I lazily copied some printf that seems to > > take a long time. > > Beside that, I think, the test should stop the time as well in the > beginning. Though this affects the stats reported on the flows, > which is likely a sign of a different race in this test as well. > > Best regards, Ilya Maximets. > > > > > Could you try this diff: > > > > $ git diff > > diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at > > index 02b4a02be1..64d73f6734 100644 > > --- a/tests/ofproto-dpif.at > > +++ b/tests/ofproto-dpif.at > > @@ -5489,7 +5489,7 @@ m4_define([GEN_IP_FRAGS], > > AT_CHECK([ovs-ofctl compose-packet --bare "${flow_first}"], [0], > > [stdout]) > > hdr=$(cat stdout) > > ip_len=$(printf '%04x' $((20 + frag_len))) > > - payload=$(printf '0%.0s' $(seq $(( (frag_len - 20) * 2 )))) > > + payload=$(printf "%0$(( (frag_len - 20) * 2 ))d" 0) > > AT_CHECK([echo ${hdr}${payload} \ > > | sed > > "s/^\(.\{32\}\).\{12\}\(.\{4\}\).\{4\}/\1${ip_len}12342000\2dead/"], > > [0], [stdout]) > > @@ -5498,7 +5498,7 @@ m4_define([GEN_IP_FRAGS], > > AT_CHECK([ovs-ofctl compose-packet --bare "${flow_later}"], [0], > > [stdout]) > > hdr=$(cat stdout) > > ip_len=$(printf '%04x' $((20 + frag_len))) > > - payload=$(printf '0%.0s' $(seq $(( frag_len * 2 )))) > > + payload=$(printf "%0$(( frag_len * 2 ))d" 0) > > for i in $(seq 1 61); do > > frag_off=$(printf '%04x' $((0x2000 + i * frag_len / 8))) > > AT_CHECK([echo ${hdr}${payload} \ > > @@ -5508,7 +5508,7 @@ m4_define([GEN_IP_FRAGS], > > done > > > > ip_len=$(printf '%04x' $((40 + frag_len / 2))) > > - payload=$(printf '0%.0s' $(seq $((frag_len + 40)))) > > + payload=$(printf "%0$((frag_len + 40))d" 0) > > frag_off=$(printf '%04x' $((62 * frag_len / 8))) > > AT_CHECK([echo ${hdr}${payload} \ > > | sed > > "s/^\(.\{32\}\).\{12\}\(.\{4\}\).\{4\}/\1${ip_len}1234${frag_off}\2dead/"], > > @@ -5567,7 +5567,7 @@ dnl Make sure all four packets are counted > > properly in the coverage. > > AT_CHECK([ovs-appctl coverage/show | grep -c "^ipf.*total: 2"], [0], [2 > > ]) > > > > -zero1208=$(printf '0%.0s' $(seq 2416)) > > +zero1208=$(printf '%02416d' 0) > > dnl Test that reassembled packets flow. > > AT_CHECK([ovs-appctl netdev-dummy/receive p90 "0021853763af > > 0026b98cb0f9 0800 4500 04c4 0002 2000 40 06 8ff7 ac11370d ac11370b dnl > > 0000 0001 00000000 00000000 50 10 8000 604c 0000 dnl
Yes, it seems the patch fixes the problem. Thank you! -- Dmitry _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
