Re: Automated report: NetBSD-current/i386 test failure
On Fri, Oct 13, 2023 at 05:11:47PM +0300, Andreas Gustafsson wrote: > Even though some of the test failures were reported as an excessive > number of separate emails and attributed to the wrong commit, the > failures themselves are real. Indeed, on my real hardware tests the jumps are impressive: https://netbsd.org/~martin/evbearmv7hf-atf/ goes from 12 failures on 2023-10-04 to 551 failures on 2023-10-12 https://netbsd.org/~martin/evbarm-atf/ goes from 70 failures on 2023-10-06 to 242 failures on 2023-10-12 I stopped running tests untill this is solved. Martin
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v4v6_esp_cast128cbc > > The above test failed in each of the last 4 test runs, and passed in > at least 26 consecutive runs before that. > > The following commits were made between the last successful test and > the first failed test: > > 2023.10.12.17.18.38 riastradh > src/crypto/external/bsd/heimdal/Makefile.inc 1.11 (etc) Sorry about the multitude of automated reports, some of which (such as the one quoted above) pointed at the wrong commit. What happened is that a commit by ad@ caused a large number of tests to start failing randomly, and because the failures are random and numerous and today is Friday the 13th, some of the tests happened to fail for the first time only after some later commit, and then also happened to fail several times in a row. This resulted in a pattern of a long stretch of successes followed by several failures in a row. This looks very much the same as a deterministic failure introduced by the later commit, and the testbed mistook it as such. Even though some of the test failures were reported as an excessive number of separate emails and attributed to the wrong commit, the failures themselves are real. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
Date:Sat, 27 May 2023 20:26:06 - (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Perhaps add a flag to the mount command to not do the realpath check? No longer needed, hannken@ provided a fix for the tests. I didn't consider that one as a real possibility as it seems to be a bit crude (and it was never mount that had the issue, just mount_ffs, as that's what the tests which needed to work when realpath() was failing were using.) kre
Re: Automated report: NetBSD-current/i386 test failure
In article <1617.1685135...@jacaranda.noi.kre.to>, Robert Elz wrote: > >I'll keep looking, and see if there is a reasonable path forward, which >allows rump's bizarre etfs to function as needed, without completely >breaking normal unix pathname resolution semantics. Perhaps add a flag to the mount command to not do the realpath check? christos
Re: Automated report: NetBSD-current/i386 test failure
Date:Fri, 26 May 2023 02:29:05 + (UTC) From:NetBSD Test Fixture Message-ID: <168506814541.4954.15559262820055138...@babylon5.netbsd.org> | The newly failing test cases are: | | fs/nfs/t_rquotad:get_nfs_be_1_both | fs/nfs/t_rquotad:get_nfs_be_1_group | fs/nfs/t_rquotad:get_nfs_be_1_user | fs/nfs/t_rquotad:get_nfs_le_1_both | fs/nfs/t_rquotad:get_nfs_le_1_group | fs/nfs/t_rquotad:get_nfs_le_1_user | lib/librumphijack/t_tcpip:nfs | lib/librumphijack/t_vfs:cpcopy | lib/librumphijack/t_vfs:ln_nox | lib/librumphijack/t_vfs:mv_nox | lib/librumphijack/t_vfs:paxcopy All those failures are caused by the same thing (when one is fixed, all will be, effectively) This change: | 2023.05.25.17.37.05 kre src/sbin/mount/pathadj.c,v 1.4 made it happen. That's the one that causes the mount_xxx programs to exit(1) if realpath(3) fails on one of the pathnames - that of the block device (or equivalent), or that of the mount point. Some of the mount_xxx programs only have the mount point, that distinction isn't important here. What these programs do, is mount_ffs /dk /somewhere The /somewhere isn't the issue, it is /dk /dk (in this rump environment has been set up via the -d arg to rump_server which sets up a drivespec - a pseudo kind of device that maps rump kernel space into real filesystem space. Of itself that would be OK, but all this uses rump's magic etfs filesystem, which allows paths to be resolved, a reference to /dk will work (in rump) but the file doesn't actually exist in the root directory (in this instance) and if that directory is read, /dk will not be found. This is a problem for realpath() which is entrusted with checking the path passed in, to make sure it is in canonical form, which the mount_xxx programs rely upon, so that users can use any workable name for what they want to mount, but the mounts will always mount the same thing, using the canonical paths. Since /dk doesn't really exist, even though it can be resolved, realpath(3) has a problem, and fails. That always happened - but until recently, that failure was non fatal, and the mount programs simply ignored it. In general that's not safe, as was pointed out in a recent thread (or two) bad things can happen. realpath(3) is defined as char *realpath(char *path, char *canon) (typically using different names for the args, but for here, those work well.) That takes path, and fills in the buffer passed in via canon with the canonical form of path. It then returns canon. If it fails, it returns NULL - in the POSIX spec, what is in canon then is undefined (applications must not use it). But in NetBSD we define it, it is the path that failed (more or less a prefix of what would be the canonical path, if only there wasn't an error). In our case, that will be /dk - as that's the path that realpath() cannot find to verify. Until this past week, pathadj() in the mount_xxx program would have written an error (warning) to stderr - which the tests carefully simply ignore, and them the mount_xxx program would have simply assumed that the path filled in was complete, and good, and gone ahead and used it. Since that's what the test wants to happen, and it actually works, as when the mount() sys call looks up /dk the etfs magic makes that work, and the lookup (and mount) succeeds. Now when pathadj() sees realpath fail, and since it is not permitted to fail, it simply exits (exit(1)) and that causes the test to fail. Right now, I'm not sure what to do about this - magic paths which resolve, but don't appear in the filesystem, aren't something that anyone needs to deal with. Reverting the pathadj() change, just so these tests go back to succeeding is the wrong thing to do - real uses of mount_xxx not involving rump, should get the protection this provides. For now these tests are just going to have to keep failing - if anyone is concerned about that, by all means either disable them, or make them skip, to avoid counting as failures. I'll keep looking, and see if there is a reasonable path forward, which allows rump's bizarre etfs to function as needed, without completely breaking normal unix pathname resolution semantics. If there doesn't seem to be any good solution, then some kind of rump specific hack in pathadj() might be required, to make things keep running the old way when doing this kind of mount. That's truly ugly, but doable -- I am hoping for a better solution than that, but don't see it yet. Note that this is 100% rump self-inflicted pain - this issue will not, in any way, affect the way any real system behaves. Note also that we can't just change the test to ignore this error value from exit(), as when that happens, the mount is no longer being attempted - it simply isn't done at all. That would be fatal for the tests which are counting upon the mount succeeding. kre
Re: Automated report: NetBSD-current/i386 test failure
NetBSD Test Fixture wrote: > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > lib/libc/net/t_protoent:protoent > > The above test failed in each of the last 4 test runs, and passed in > at least 26 consecutive runs before that. > > The following commits were made between the last successful test and > the failed test: > > 2022.11.28.02.46.58 jschauma src/etc/protocols,v 1.32 Reverted to the previous version until I know why the test failed. -Jan
Re: Automated report: NetBSD-current/i386 test failure
Date:Sat, 12 Mar 2022 23:35:47 + (UTC) From:NetBSD Test Fixture Message-ID: <164712814771.10628.11343290967506895...@babylon5.netbsd.org> | The newly failing test cases are: | lib/libc/stdlib/t_hsearch:hsearch_basic It is possible those might all be fixed now. kre
Re: Automated report: NetBSD-current/i386 test failure
This test still fails as: kqueue: [5.986468s] Failed: dir/b did not receive NOTE_LINK Can you please take a look? Thanks, rin On 2021/10/21 5:43, NetBSD Test Fixture wrote: This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: fs/tmpfs/t_link:kqueue The above test failed in each of the last 4 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2021.10.20.03.08.16 thorpej src/sys/coda/coda_vnops.c,v 1.116 2021.10.20.03.08.17 thorpej src/sys/fs/msdosfs/msdosfs_vnops.c,v 1.107 2021.10.20.03.08.17 thorpej src/sys/fs/nilfs/nilfs_vnops.c,v 1.45 2021.10.20.03.08.17 thorpej src/sys/fs/ptyfs/ptyfs_vnops.c,v 1.67 2021.10.20.03.08.17 thorpej src/sys/fs/puffs/puffs_vnops.c,v 1.223 2021.10.20.03.08.17 thorpej src/sys/fs/sysvbfs/sysvbfs_vnops.c,v 1.68 2021.10.20.03.08.17 thorpej src/sys/fs/tmpfs/tmpfs_rename.c,v 1.11 2021.10.20.03.08.17 thorpej src/sys/fs/tmpfs/tmpfs_subr.c,v 1.114 2021.10.20.03.08.17 thorpej src/sys/fs/tmpfs/tmpfs_vnops.c,v 1.148 2021.10.20.03.08.17 thorpej src/sys/fs/udf/udf_rename.c,v 1.14 2021.10.20.03.08.17 thorpej src/sys/fs/udf/udf_vnops.c,v 1.117 2021.10.20.03.08.17 thorpej src/sys/fs/union/union_vnops.c,v 1.79 2021.10.20.03.08.17 thorpej src/sys/fs/unionfs/unionfs_vnops.c,v 1.17 2021.10.20.03.08.18 thorpej src/sys/fs/v7fs/v7fs_vnops.c,v 1.32 2021.10.20.03.08.18 thorpej src/sys/kern/vfs_vnode.c,v 1.128 2021.10.20.03.08.18 thorpej src/sys/kern/vfs_vnops.c,v 1.224 2021.10.20.03.08.18 thorpej src/sys/kern/vnode_if.sh,v 1.72 2021.10.20.03.08.18 thorpej src/sys/kern/vnode_if.src,v 1.83 2021.10.20.03.08.18 thorpej src/sys/miscfs/deadfs/dead_vnops.c,v 1.66 2021.10.20.03.08.18 thorpej src/sys/miscfs/genfs/genfs.h,v 1.38 2021.10.20.03.08.18 thorpej src/sys/miscfs/genfs/genfs_rename.c,v 1.6 2021.10.20.03.08.18 thorpej src/sys/miscfs/genfs/genfs_vnops.c,v 1.216 2021.10.20.03.08.18 thorpej src/sys/miscfs/genfs/layer_vnops.c,v 1.72 2021.10.20.03.08.18 thorpej src/sys/miscfs/umapfs/umap_vnops.c,v 1.62 2021.10.20.03.08.18 thorpej src/sys/nfs/nfs_bio.c,v 1.200 2021.10.20.03.08.18 thorpej src/sys/nfs/nfs_kq.c,v 1.32 2021.10.20.03.08.18 thorpej src/sys/nfs/nfs_vnops.c,v 1.321 2021.10.20.03.08.18 thorpej src/sys/rump/librump/rumpvfs/rumpfs.c,v 1.166 2021.10.20.03.08.18 thorpej src/sys/sys/event.h,v 1.49 2021.10.20.03.08.18 thorpej src/sys/sys/vnode.h,v 1.298 2021.10.20.03.08.19 thorpej src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c,v 1.76 2021.10.20.03.08.19 thorpej src/lib/libc/sys/kqueue.2,v 1.55 2021.10.20.03.08.19 thorpej src/sys/ufs/chfs/chfs_vnops.c,v 1.46 2021.10.20.03.08.19 thorpej src/sys/ufs/ext2fs/ext2fs_readwrite.c,v 1.78 2021.10.20.03.08.19 thorpej src/sys/ufs/ext2fs/ext2fs_rename.c,v 1.12 2021.10.20.03.08.19 thorpej src/sys/ufs/ext2fs/ext2fs_vnops.c,v 1.136 2021.10.20.03.08.19 thorpej src/sys/ufs/lfs/lfs_rename.c,v 1.25 2021.10.20.03.08.19 thorpej src/sys/ufs/lfs/lfs_vnops.c,v 1.340 2021.10.20.03.08.19 thorpej src/sys/ufs/lfs/ulfs_readwrite.c,v 1.28 2021.10.20.03.08.19 thorpej src/sys/ufs/lfs/ulfs_vnops.c,v 1.55 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_acl.c,v 1.3 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_extern.h,v 1.88 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_readwrite.c,v 1.127 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_rename.c,v 1.14 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_vnops.c,v 1.260 2021.10.20.03.08.19 thorpej src/tests/kernel/kqueue/t_vnode.c,v 1.2 2021.10.20.03.09.45 thorpej src/sys/sys/param.h,v 1.705 2021.10.20.03.13.14 thorpej src/sys/kern/vnode_if.c,v 1.115 2021.10.20.03.13.14 thorpej src/sys/rump/include/rump/rumpvnode_if.h,v 1.37 2021.10.20.03.13.14 thorpej src/sys/rump/librump/rumpvfs/rumpvnode_if.c,v 1.37 2021.10.20.03.13.14 thorpej src/sys/sys/vnode_if.h,v 1.108 2021.10.20.03.26.20 thorpej src/lib/libc/sys/kqueue.2,v 1.56 2021.10.20.05.00.37 rillig src/usr.bin/indent/indent.c,v 1.140 2021.10.20.05.00.37 rillig src/usr.bin/indent/indent.h,v 1.39 2021.10.20.05.00.37 rillig src/usr.bin/indent/io.c,v 1.98 2021.10.20.05.07.08 rillig src/usr.bin/indent/indent.c,v 1.141 2021.10.20.05.14.21 rillig src/tests/usr.bin/indent/opt_bacc.c,v 1.4 2021.10.20.05.14.21 rillig src/usr.bin/indent/indent.c,v 1.142 2021.10.20.05.14.21 rillig src/usr.bin/indent/indent.h,v 1.40 2021.10.20.05.14.21 rillig src/usr.bin/indent/io.c,v 1.99 2021.10.20.05.14.21 rillig src/usr.bin/indent/pr_comment.c,v 1.80 2021.10.20.05.26.46 rillig src/usr.bin/indent/indent.c,v 1.143 2021.10.20.05.26.46 rillig src/usr.bin/indent/indent.h,v 1.41 2021.10.20.05.26.46 rillig
Re: Automated report: NetBSD-current/i386 test failure
On 07.02.2021 01:33, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: usr.bin/make/t_make:archive usr.bin/make/t_make:cmdline I will take care of these. Roland
Re: Automated report: NetBSD-current/i386 test failure
On Sun, Jan 17, 2021 at 08:03:20PM +0200, Andreas Gustafsson wrote: > The cause of the 1000+ new test failures has now been narrowed down to > the following commit: > > 2021.01.16.23.50.49 chs src/sys/rump/librump/rumpkern/rump.c,v 1.352 > 2021.01.16.23.51.50 chs src/sys/arch/arm/arm/psci.c,v 1.5 > 2021.01.16.23.51.50 chs src/sys/conf/files,v 1.1278 > 2021.01.16.23.51.51 chs src/sys/lib/libkern/arch/hppa/bcopy.S,v 1.16 > 2021.01.16.23.51.51 chs src/sys/lib/libkern/libkern.h,v 1.141 > 2021.01.16.23.51.51 chs src/sys/sys/cdefs.h,v 1.156 > 2021.01.16.23.51.51 chs src/sys/sys/queue.h,v 1.76 > > Logs: > > > http://releng.netbsd.org/b5reports/i386/commits-2021.01.html#2021.01.16.23.51.51 > > -- > Andreas Gustafsson, g...@gson.org thanks for pointing that out, it should be fixed now. -Chuck
Re: Automated report: NetBSD-current/i386 test failure
The cause of the 1000+ new test failures has now been narrowed down to the following commit: 2021.01.16.23.50.49 chs src/sys/rump/librump/rumpkern/rump.c,v 1.352 2021.01.16.23.51.50 chs src/sys/arch/arm/arm/psci.c,v 1.5 2021.01.16.23.51.50 chs src/sys/conf/files,v 1.1278 2021.01.16.23.51.51 chs src/sys/lib/libkern/arch/hppa/bcopy.S,v 1.16 2021.01.16.23.51.51 chs src/sys/lib/libkern/libkern.h,v 1.141 2021.01.16.23.51.51 chs src/sys/sys/cdefs.h,v 1.156 2021.01.16.23.51.51 chs src/sys/sys/queue.h,v 1.76 Logs: http://releng.netbsd.org/b5reports/i386/commits-2021.01.html#2021.01.16.23.51.51 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
Yesterday, the NetBSD Test Fixture wrote: > The newly failing test case is: > > rump/rumpkern/t_vm:busypage This one is still failing. The rump kernel panics with: [ 1.1400050] panic: kernel diagnostic assertion "(pg->flags & PG_FAKE) == 0" failed: file "/tmp/build/2020.12.07.10.02.51-i386/src/lib/librump/../../sys/rump/librump/rumpkern/vm.c", line 710 A full log and backtrace is at: http://releng.netbsd.org/b5reports/i386/2020/2020.12.07.10.02.51/test.html#rump_rumpkern_t_vm_busypage -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > lib/libm/t_fmod:fmod > [...] > 2020.08.23.06.12.52 rillig src/usr.bin/make/buf.c,v 1.36 [...] False alarm - it looks like testbed has somehow managed to dig up an old test failure from August that has already been fixed. Sorry about that, and I will make some changes to keep it from happening again. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure (l2tp)
On 23/10/2020 08:25, Andreas Gustafsson wrote: Roy Marples wrote: This is rump crashing and I don't know why. If the rump kernel crashes in the test, that likely means the real kernel will crash in actual use. I can't get a backtrace to tell me where the problem is. I managed to get one this way: sysctl -w kern.defcorename="/tmp/%n.core" cd /usr/tests/net/if_l2tp ./t_l2tp l2tp_basic_ipv4overipv4 gdb rump_server /tmp/rump_server.core It looks like this: Thanks for that, it should now be fixed. Roy
Re: Automated report: NetBSD-current/i386 test failure (l2tp)
Roy Marples wrote: > This is rump crashing and I don't know why. If the rump kernel crashes in the test, that likely means the real kernel will crash in actual use. > I can't get a backtrace to tell me where the problem is. I managed to get one this way: sysctl -w kern.defcorename="/tmp/%n.core" cd /usr/tests/net/if_l2tp ./t_l2tp l2tp_basic_ipv4overipv4 gdb rump_server /tmp/rump_server.core It looks like this: (gdb) bt #0 0x752206d751ea in _lwp_kill () from /usr/lib/libc.so.12 #1 0x752206d756e5 in abort () at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/libc/stdlib/abort.c:74 #2 0x7522076088bf in rumpuser_exit (rv=rv@entry=-1) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/librumpuser/rumpuser.c:236 #3 0x7522082c2b74 in cpu_reboot (howto=, bootstr=) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/librump/../../sys/rump/librump/rumpkern/emul.c:429 #4 0x75220827b08d in kern_reboot (howto=4, bootstr=0x0) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/librump/../../sys/rump/../kern/kern_reboot.c:73 #5 0x752208279efe in vpanic ( fmt=0x752205ea5428 "kernel %sassertion \"%s\" failed: file \"%s\", line %d ", ap=0x75220319fc88) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/librump/../../sys/rump/../kern/subr_prf.c:290 #6 0x75220825f298 in kern_assert (fmt=) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/librump/../../sys/rump/../lib/libkern/kern_assert.c:51 #7 0x752205e9fa7d in if_percpuq_enqueue (ipq=0x0, m=0x752208061650) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/sys/rump/net/lib/libnet/../../../../net/if.c:911 #8 0x752204a03801 in in_l2tp_input (eparg=, proto=, off=20, m=0x752208061858) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/sys/rump/net/lib/libl2tp/../../../../netinet/in_l2tp.c:349 #9 in_l2tp_input (m=0x752208061858, off=20, proto=, eparg=) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/sys/rump/net/lib/libl2tp/../../../../netinet/in_l2tp.c:249 #10 0x752205e75097 in encap4_input (m=0x752208061858, off=20, proto=115) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/sys/rump/net/lib/libnet/../../../../netinet/ip_encap.c:357 #11 0x752205e7d465 in ip_input (ifp=, m=) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/sys/rump/net/lib/libnet/../../../../netinet/ip_input.c:821 #12 ipintr (arg=) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/sys/rump/net/lib/libnet/../../../../netinet/ip_input.c:412 #13 0x7522082c265c in sithread (arg=) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/librump/../../sys/rump/librump/rumpkern/intr.c:180 #14 0x7522082bf52e in threadbouncer (arg=0x75220883bac0) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/librump/../../sys/rump/librump/rumpkern/threads.c:90 #15 0x75220720bf7e in pthread__create_tramp (cookie=0x7522085a4800) at /tmp/build/2020.10.22.11.21.42-amd64-debug/src/lib/libpthread/pthread.c:560 #16 0x752206c91dc0 in ?? () from /usr/lib/libc.so.12 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure (l2tp)
Hi Andreas On 22/10/2020 09:00, Andreas Gustafsson wrote: Hi Roy, On Oct 16, the NetBSD Test Fixture wrote: The newly failing test cases are: net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv4 net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv6 net/if_l2tp/t_l2tp:l2tp_basic_ipv6overipv4 net/if_l2tp/t_l2tp:l2tp_basic_ipv6overipv6 net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_ah_hmacsha512 net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_ah_null net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_esp_null net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_esp_rijndaelcbc net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_ah_hmacsha512 net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_ah_null net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_esp_null net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_esp_rijndaelcbc net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_ah_hmacsha512 net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_ah_null net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_esp_null net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_esp_rijndaelcbc net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_ah_hmacsha512 net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_ah_null net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_esp_null net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_esp_rijndaelcbc These are still failing as of 2020.10.21.15.12.15, and the commit that triggered the failures has now been identified: 2020.10.15.02.54.10 roy src/sys/net/if_l2tp.c 1.44 For logs, see http://www.gson.org/netbsd/bugs/build/amd64/commits-2020.10.html#2020.10.15.02.54.10 This is rump crashing and I don't know why. I can't get a backtrace to tell me where the problem is. Roy
Re: Automated report: NetBSD-current/i386 test failure (l2tp)
Hi Roy, On Oct 16, the NetBSD Test Fixture wrote: > The newly failing test cases are: > > net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv4 > net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv6 > net/if_l2tp/t_l2tp:l2tp_basic_ipv6overipv4 > net/if_l2tp/t_l2tp:l2tp_basic_ipv6overipv6 > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_ah_hmacsha512 > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_ah_null > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_esp_null > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_transport_esp_rijndaelcbc > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_ah_hmacsha512 > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_ah_null > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_esp_null > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv4_tunnel_esp_rijndaelcbc > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_ah_hmacsha512 > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_ah_null > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_esp_null > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_esp_rijndaelcbc > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_ah_hmacsha512 > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_ah_null > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_esp_null > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_tunnel_esp_rijndaelcbc These are still failing as of 2020.10.21.15.12.15, and the commit that triggered the failures has now been identified: 2020.10.15.02.54.10 roy src/sys/net/if_l2tp.c 1.44 For logs, see http://www.gson.org/netbsd/bugs/build/amd64/commits-2020.10.html#2020.10.15.02.54.10 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
On 2020/10/22 12:06, Chuck Silvers wrote: On Wed, Oct 21, 2020 at 08:30:17PM +0900, Rin Okuyama wrote: On 2020/10/21 20:10, Andreas Gustafsson wrote: Two days ago, the NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: sbin/resize_ffs/t_grow:grow_16M_v0_8192 sbin/resize_ffs/t_grow:grow_16M_v1_16384 sbin/resize_ffs/t_grow:grow_16M_v2_32768 sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536 sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096 sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192 sbin/resize_ffs/t_shrink:shrink_24M_16M_v0_32768 sbin/resize_ffs/t_shrink:shrink_24M_16M_v1_65536 sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v0_4096 sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v1_8192 These are still failing as of source date 2020.10.21.06.36.10, and the commit that triggered the failures has now been identified: 2020.10.18.18.22.29 chs src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39 2020.10.18.18.22.29 chs src/sys/uvm/uvm_page.c 1.248 2020.10.18.18.22.29 chs src/sys/uvm/uvm_pager.c 1.130 Logs from real amd64 hardware are at: http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2020.10.html#2020.10.18.18.22.29 This seems due to src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39; tests pass if only this commit is reverted in librumpvfs.so. I committed a fix for this just now. thanks for pointing it out. The tests now pass for me. Thank you for quick fix! rin
Re: Automated report: NetBSD-current/i386 test failure
On Wed, Oct 21, 2020 at 08:30:17PM +0900, Rin Okuyama wrote: > On 2020/10/21 20:10, Andreas Gustafsson wrote: > > Two days ago, the NetBSD Test Fixture wrote: > > > This is an automatically generated notice of new failures of the > > > NetBSD test suite. > > > > > > The newly failing test cases are: > > > > > > sbin/resize_ffs/t_grow:grow_16M_v0_8192 > > > sbin/resize_ffs/t_grow:grow_16M_v1_16384 > > > sbin/resize_ffs/t_grow:grow_16M_v2_32768 > > > sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536 > > > sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096 > > > sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192 > > > sbin/resize_ffs/t_shrink:shrink_24M_16M_v0_32768 > > > sbin/resize_ffs/t_shrink:shrink_24M_16M_v1_65536 > > > sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v0_4096 > > > sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v1_8192 > > > > These are still failing as of source date 2020.10.21.06.36.10, and the > > commit that triggered the failures has now been identified: > > > >2020.10.18.18.22.29 chs src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39 > >2020.10.18.18.22.29 chs src/sys/uvm/uvm_page.c 1.248 > >2020.10.18.18.22.29 chs src/sys/uvm/uvm_pager.c 1.130 > > > > Logs from real amd64 hardware are at: > > > > > > http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2020.10.html#2020.10.18.18.22.29 > > This seems due to src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39; > tests pass if only this commit is reverted in librumpvfs.so. I committed a fix for this just now. thanks for pointing it out. -Chuck
Re: Automated report: NetBSD-current/i386 test failure
On 2020/10/21 20:10, Andreas Gustafsson wrote: Two days ago, the NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: sbin/resize_ffs/t_grow:grow_16M_v0_8192 sbin/resize_ffs/t_grow:grow_16M_v1_16384 sbin/resize_ffs/t_grow:grow_16M_v2_32768 sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536 sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096 sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192 sbin/resize_ffs/t_shrink:shrink_24M_16M_v0_32768 sbin/resize_ffs/t_shrink:shrink_24M_16M_v1_65536 sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v0_4096 sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v1_8192 These are still failing as of source date 2020.10.21.06.36.10, and the commit that triggered the failures has now been identified: 2020.10.18.18.22.29 chs src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39 2020.10.18.18.22.29 chs src/sys/uvm/uvm_page.c 1.248 2020.10.18.18.22.29 chs src/sys/uvm/uvm_pager.c 1.130 Logs from real amd64 hardware are at: http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2020.10.html#2020.10.18.18.22.29 This seems due to src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39; tests pass if only this commit is reverted in librumpvfs.so. Thanks, rin
Re: Automated report: NetBSD-current/i386 test failure
Two days ago, the NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > sbin/resize_ffs/t_grow:grow_16M_v0_8192 > sbin/resize_ffs/t_grow:grow_16M_v1_16384 > sbin/resize_ffs/t_grow:grow_16M_v2_32768 > sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536 > sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096 > sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192 > sbin/resize_ffs/t_shrink:shrink_24M_16M_v0_32768 > sbin/resize_ffs/t_shrink:shrink_24M_16M_v1_65536 > sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v0_4096 > sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v1_8192 These are still failing as of source date 2020.10.21.06.36.10, and the commit that triggered the failures has now been identified: 2020.10.18.18.22.29 chs src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39 2020.10.18.18.22.29 chs src/sys/uvm/uvm_page.c 1.248 2020.10.18.18.22.29 chs src/sys/uvm/uvm_pager.c 1.130 Logs from real amd64 hardware are at: http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2020.10.html#2020.10.18.18.22.29 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
On 16/10/2020 15:54, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/if_wg/t_basic:wg_basic_ipv6_over_ipv4 net/if_wg/t_basic:wg_basic_ipv6_over_ipv6 net/if_wg/t_basic:wg_payload_sizes_ipv6_over_ipv4 net/if_wg/t_basic:wg_payload_sizes_ipv6_over_ipv6 These should now be fixed. Roy
Re: Automated report: NetBSD-current/i386 test failure
On 14/10/2020 07:15, Andreas Gustafsson wrote: On Oct 8, the NetBSD Test Fixture wrote: The newly failing test cases are: net/carp/t_basic:carp_handover_ipv4_halt_carpdevip net/carp/t_basic:carp_handover_ipv4_halt_nocarpdevip net/carp/t_basic:carp_handover_ipv4_ifdown_carpdevip net/carp/t_basic:carp_handover_ipv4_ifdown_nocarpdevip net/carp/t_basic:carp_handover_ipv6_halt_carpdevip net/carp/t_basic:carp_handover_ipv6_ifdown_carpdevip These were fixed on Oct 8, but then broken again on Oct 12: http://releng.netbsd.org/b5reports/i386/commits-2020.10.html#2020.10.12.11.07.27 Fixed here: https://mail-index.netbsd.org/source-changes/2020/10/14/msg122921.html Note, if `ident /sbin/ifconfig | grep ifconfig.c` shows revision r1.243 - r1.247 then ifconfig will likely crash with this change on carp interfaces. This has been resolved in r1.248 Roy
Re: Automated report: NetBSD-current/i386 test failure
On Oct 8, the NetBSD Test Fixture wrote: > The newly failing test cases are: > > net/carp/t_basic:carp_handover_ipv4_halt_carpdevip > net/carp/t_basic:carp_handover_ipv4_halt_nocarpdevip > net/carp/t_basic:carp_handover_ipv4_ifdown_carpdevip > net/carp/t_basic:carp_handover_ipv4_ifdown_nocarpdevip > net/carp/t_basic:carp_handover_ipv6_halt_carpdevip > net/carp/t_basic:carp_handover_ipv6_ifdown_carpdevip These were fixed on Oct 8, but then broken again on Oct 12: http://releng.netbsd.org/b5reports/i386/commits-2020.10.html#2020.10.12.11.07.27 They are still failing as of source date 2020.10.13.21.27.18. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
On 23/09/2020 11:42, NetBSD Test Fixture wrote: This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: net/if/t_ifconfig:ifconfig_options The above test failed in each of the last 4 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.09.23.02.09.18 roy src/sbin/ifconfig/ifconfig.8,v 1.120 2020.09.23.02.09.18 roy src/sbin/ifconfig/ifconfig.c,v 1.244 2020.09.23.02.32.04 roy src/usr.sbin/ifwatchd/ifwatchd.c,v 1.44 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.09.html#2020.09.23.02.32.04 Fixed. Roy
Re: Automated report: NetBSD-current/i386 test failure
On 20/09/2020 04:40, Robert Elz wrote: Date:Sun, 20 Sep 2020 04:02:45 +0100 From:Roy Marples Message-ID: <51d2f8dc-d059-5eae-9899-5c91539d1...@marples.name> | The test case just needed fixing. That is not uncommon after changes elsewhere. | The ping to an invalid address caused the ARP entry to enter INCOMPLETE -> | WAITDELETE state and this hung over into the next test casing this entry | to take too long to validty resolve. Why? If a failed ARP (or ND) causes problems for a later request (incl of the same addr) which should work (that is, any problems at all, including delays) then I'd consider the implementation broken (not the test). RFC 7048 expands that consistent failures expontentialy backoff. Because the server is not reset the backoff may bleed into subsequet tests for the same address which why this test was sometimes failing. | The solution is after a deliberate fail And if it wasn't a deliberate fail? Perhaps being just a fraction of a second too quick, and attempting a ping (or ssh, or something) just before the destination becomes reachable (either because it was down, unconfigured, or the net link between then wasn't functional), and ATF timings on an emulated environment cannot be that precise. See PR 43997 for more details. | to remove the ARP entry for the address if the user doing this isn't root, and cannot just remove ARP entries? Maybe I'm misunderstanding the actual scenario, but it seems to me that things aren't working as well now as they were before (the timing in the qemu tests hasn't changed recently - not since the nvmm version started being used - but before the arp implementation change, it used to work reliably). By reliably you mean that a successful ARP resoltion lasts for 20 minutes which we don't have any tests for? If anything the tests we have are more reliable than before as I have not adjusted any timings. Roy
Re: Automated report: NetBSD-current/i386 test failure
Date:Sun, 20 Sep 2020 04:02:45 +0100 From:Roy Marples Message-ID: <51d2f8dc-d059-5eae-9899-5c91539d1...@marples.name> | The test case just needed fixing. That is not uncommon after changes elsewhere. | The ping to an invalid address caused the ARP entry to enter INCOMPLETE -> | WAITDELETE state and this hung over into the next test casing this entry | to take too long to validty resolve. Why? If a failed ARP (or ND) causes problems for a later request (incl of the same addr) which should work (that is, any problems at all, including delays) then I'd consider the implementation broken (not the test). | The solution is after a deliberate fail And if it wasn't a deliberate fail? Perhaps being just a fraction of a second too quick, and attempting a ping (or ssh, or something) just before the destination becomes reachable (either because it was down, unconfigured, or the net link between then wasn't functional), and | to remove the ARP entry for the address if the user doing this isn't root, and cannot just remove ARP entries? Maybe I'm misunderstanding the actual scenario, but it seems to me that things aren't working as well now as they were before (the timing in the qemu tests hasn't changed recently - not since the nvmm version started being used - but before the arp implementation change, it used to work reliably). | This fixes all the test case fallout from the ARP -> ND merge and has now | survived several test runs. Yes, I have been watching, and I saw that. | The ND cache expiration test which intermittently fails is based on exact | timings. A future patch will add jitter to NS, will cause this test to | fail more. Ideas on how to solve it welcome. Some of the tests make unsupportable assumptions, that just happen to work when initially created. That one might be one of those, in which case we need to look and see what assertions can be made about the state at various times, and make sure that the test only attempts to verify things that ought be true - cache expiration is one of the harder ones to deal with, as generally that just happens whenever the kernel (or whatever is holding the cache - the kernel here) decides that now would be a useful time. Sometimes there the right way is not to test whether the entry has gone from the cache, but whether it is either gone, or in a state where it could vanish any time (eg: lifetime has decremented to 0 or whatever). Not always possible - some things that should happen just aren't possible to reliably test in an automated framework like this - some cache entries just "go away eventually", but the test cannot just wait for "eventually" to occur, especially, as is often the case, how long that takes depends naturally upon other activity, and in the test, there is none. kre
Re: Automated report: NetBSD-current/i386 test failure
On 13/09/2020 23:10, Robert Elz wrote: Date:Sun, 13 Sep 2020 22:14:00 +0100 From:Roy Marples Message-ID: | >| > net/arp/t_arp:arp_proxy_arp_pub | >| > net/arp/t_arp:arp_proxy_arp_pubproxy | > | > Those two are still failing. | | Works fine on my box. | Can you say how they are failing? See: http://releng.netbsd.org/b5reports/i386/2020/2020.09.13.15.27.25/test.html#net_arp_t_arp_arp_proxy_arp_pub The test case just needed fixing. Basically the issue was that the test kernel was slow but the test cases were fast. The ping to an invalid address caused the ARP entry to enter INCOMPLETE -> WAITDELETE state and this hung over into the next test casing this entry to take too long to validty resolve. The solution is after a deliberate fail to remove the ARP entry for the address and ignore the exit code if the entry has naturally expired / been removed. This fixes all the test case fallout from the ARP -> ND merge and has now survived several test runs. The ND cache expiration test which intermittently fails is based on exact timings. A future patch will add jitter to NS, will cause this test to fail more. Ideas on how to solve it welcome. Roy
Re: Automated report: NetBSD-current/i386 test failure
Date:Sun, 13 Sep 2020 22:14:00 +0100 From:Roy Marples Message-ID: | >| > net/arp/t_arp:arp_proxy_arp_pub | >| > net/arp/t_arp:arp_proxy_arp_pubproxy | > | > Those two are still failing. | | Works fine on my box. | Can you say how they are failing? See: http://releng.netbsd.org/b5reports/i386/2020/2020.09.13.15.27.25/test.html#net_arp_t_arp_arp_proxy_arp_pub kre
Re: Automated report: NetBSD-current/i386 test failure
On 13/09/2020 22:07, Robert Elz wrote: Date:Sun, 13 Sep 2020 20:06:45 +0100 From:Roy Marples Message-ID: <9e977478-d209-2dbb-49d9-3fa9acd25...@marples.name> | > net/arp/t_arp:arp_cache_expiration_10s | > net/arp/t_arp:arp_cache_expiration_5s Those two are "fixed" (if you can call deleted fixed). I call them "replaced". arp_cache_expiration is the mirror of the ndp equivalent. | > net/arp/t_arp:arp_command That looks OK now. | > net/arp/t_arp:arp_proxy_arp_pub | > net/arp/t_arp:arp_proxy_arp_pubproxy Those two are still failing. Works fine on my box. Can you say how they are failing? Roy
Re: Automated report: NetBSD-current/i386 test failure
Date:Sun, 13 Sep 2020 20:06:45 +0100 From:Roy Marples Message-ID: <9e977478-d209-2dbb-49d9-3fa9acd25...@marples.name> | > net/arp/t_arp:arp_cache_expiration_10s | > net/arp/t_arp:arp_cache_expiration_5s Those two are "fixed" (if you can call deleted fixed). | > net/arp/t_arp:arp_command That looks OK now. | > net/arp/t_arp:arp_proxy_arp_pub | > net/arp/t_arp:arp_proxy_arp_pubproxy Those two are still failing. kre
Re: Automated report: NetBSD-current/i386 test failure
On 12/09/2020 22:57, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/arp/t_arp:arp_cache_expiration_10s net/arp/t_arp:arp_cache_expiration_5s net/arp/t_arp:arp_command net/arp/t_arp:arp_proxy_arp_pub > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > net/arp/t_arp:arp_proxy_arp_pubproxy These should now be fixed Roy
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture reported this test failure twice: > net/net/t_unix:sockaddr_un_local_peereid Sorry about the duplicate report. The testbed is now using Python 3 and that appears to have broken the duplicate suppression. I'll fix it. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
Hi, On 2020/06/19 21:04, Martin Husemann wrote: On Fri, Jun 19, 2020 at 08:56:32PM +0900, Rin Okuyama wrote: I will make these tests (and similar ones in kernel/t_trapsignal) skipped on QEMU, if there's no objection. No objections from me. Could you file a qemu bug for this, please? Thank you for your comment. I can reproduce the problem on QEMU 5.0.0. I will send a report to them. Thanks, rin
Re: Automated report: NetBSD-current/i386 test failure
On Fri, Jun 19, 2020 at 08:56:32PM +0900, Rin Okuyama wrote: > I will make these tests (and similar ones in kernel/t_trapsignal) skipped on > QEMU, if there's no objection. No objections from me. Could you file a qemu bug for this, please? Thanks! Martin
Re: Automated report: NetBSD-current/i386 test failure
This seems due to QEMU bug, as also observed in tests/lib/libc/gen/t_siginfo:sigfpe_flt, see: http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/gen/t_siginfo.c#rev1.20 Actually, these tests pass on (1) VirtualBox, and (2) real hardware under amd64 kernel with COMPAT_NETBSD32. I will make these tests (and similar ones in kernel/t_trapsignal) skipped on QEMU, if there's no objection. Thanks, rin On 2020/06/19 19:31, Rin Okuyama wrote: I will examine this. Thanks, rin On 2020/06/19 19:28, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:traceme_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_crash_fpe lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_crash_fpe lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitid:traceme_crash_fpe lib/libc/sys/t_ptrace_waitid:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitid:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_crash_fpe lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_crash_fpe lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_signalmasked_crash_fpe The above tests failed in each of the last 4 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.06.17.08.23.18 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.29 2020.06.17.08.42.16 rin src/tests/lib/libc/sys/t_ptrace_signal_wait.h,v 1.2 2020.06.17.08.42.16 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.30 2020.06.17.09.11.13 msaitoh src/sys/dev/pci/ixgbe/ixgbe.c,v 1.231 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html#2020.06.17.09.11.13
Re: Automated report: NetBSD-current/i386 test failure
I will examine this. Thanks, rin On 2020/06/19 19:28, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:traceme_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait3:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait4:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_crash_fpe lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait6:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_crash_fpe lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_wait:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitid:traceme_crash_fpe lib/libc/sys/t_ptrace_waitid:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitid:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_crash_fpe lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_vfork_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_vfork_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitpid:traceme_vfork_signalmasked_crash_fpe lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_crash_fpe lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_signalignored_crash_fpe lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_signalmasked_crash_fpe The above tests failed in each of the last 4 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.06.17.08.23.18 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.29 2020.06.17.08.42.16 rin src/tests/lib/libc/sys/t_ptrace_signal_wait.h,v 1.2 2020.06.17.08.42.16 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.30 2020.06.17.09.11.13 msaitoh src/sys/dev/pci/ixgbe/ixgbe.c,v 1.231 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html#2020.06.17.09.11.13
Re: Automated report: NetBSD-current/i386 test failure
> On 16. Jun 2020, at 12:42, NetBSD Test Fixture wrote: > > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > >fs/vfs/t_full:nfs_fillfs [snip] >2020.06.14.23.38.25 kamil src/sys/rump/include/rump/rump.h,v 1.72 This commit seems to be the cause ... -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig signature.asc Description: Message signed with OpenPGP
Re: Automated report: NetBSD-current/i386 test failure
> On Jun 8, 2020, at 10:33 AM, Jason Thorpe wrote: > > >> On Jun 8, 2020, at 10:02 AM, NetBSD Test Fixture wrote: >> >> This is an automatically generated notice of new failures of the >> NetBSD test suite. >> >> The newly failing test cases are: >> >> net/if/t_ifconfig:ifconfig_description >> sbin/gpt/t_gpt:backup_2part > > I think this is just a matter of these test-cases needing to be updated to > reflect a change from base-16 to base-10 (or vice-versa) in the serialized > output. In any case, I'll investigate and fix it up. These are now both fixed. -- thorpej
Re: Automated report: NetBSD-current/i386 test failure
> On Jun 8, 2020, at 10:02 AM, NetBSD Test Fixture wrote: > > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > >net/if/t_ifconfig:ifconfig_description >sbin/gpt/t_gpt:backup_2part I think this is just a matter of these test-cases needing to be updated to reflect a change from base-16 to base-10 (or vice-versa) in the serialized output. In any case, I'll investigate and fix it up. -- thorpej
Re: Automated report: NetBSD-current/i386 test failure
Fixed, thanks! christos > On May 22, 2020, at 4:15 AM, Andreas Gustafsson wrote: > > Christos, > > On May 18, the NetBSD Test Fixture wrote: >> The newly failing test cases are: >> >>atf/atf-c/detail/fs_test:mkdtemp_err >>atf/atf-c/detail/fs_test:mkstemp_err >>bin/cp/t_cp:dir_to_dir >>fs/vfs/t_unpriv:ext2fs_owner >>fs/vfs/t_unpriv:ext2fs_times > (etc) > > Most of these are now fixed, but bin/cp/t_cp:dir_to_dir is still failing > as of source date 2020.05.21.20.43.23: > > > http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2020/2020.05.21.20.43.23/test.html#bin_cp_t_cp_dir_to_dir > > -- > Andreas Gustafsson, g...@gson.org signature.asc Description: Message signed with OpenPGP
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > dev/audio/t_audio:AUDIO_ERROR_RDWR > dev/audio/t_audio:AUDIO_ERROR_WRONLY [and many more] That message got stuck somewhere (moderation?) for three days, and those particular failures have already been fixed. There are still plenty of other test cases failing, though, 79 of them at last count: http://releng.netbsd.org/b5reports/i386/2020/2020.04.27.02.54.42/test.html#failed-tcs-summary -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
There are actually now more than 2,000 failing test cases in total, but the email message reporting most of them has failed to appear on current-users, perhaps because of its size. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
Date:Fri, 24 Apr 2020 19:59:31 + (UTC) From:NetBSD Test Fixture Message-ID: <158775837076.23438.17159050926672197...@babylon5.netbsd.org> | The newly failing test cases are: | | usr.bin/printf/t_builtin:A_floats | usr.bin/printf/t_command:A_floats Those should be fixed already. kre
Re: Automated report: NetBSD-current/i386 test failure
On Sat, Apr 18, 2020 at 10:32:18AM +0300, Andreas Gustafsson wrote: > The NetBSD Test Fixture sent three reports listing the following > groups of commits, respectively: > > >2020.04.16.14.39.58 joerg src/lib/libc/gen/pthread_atfork.c,v 1.13 > >2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/rtld.c,v 1.204 > >2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/rtld.h,v 1.139 > >2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/symbols.map,v 1.3 > > >2020.04.16.18.20.46 msaitoh src/sys/dev/pci/pcidevs,v 1.1406 > >2020.04.16.18.21.12 msaitoh src/sys/dev/pci/pcidevs.h,v 1.1394 > >2020.04.16.18.21.12 msaitoh src/sys/dev/pci/pcidevs_data.h,v 1.1393 > >2020.04.16.18.32.29 msaitoh src/sys/dev/pci/ichsmb.c,v 1.67 > >2020.04.16.18.51.47 pgoyette src/share/man/man4/man4.x86/imcsmb.4,v 1.8 > >2020.04.16.18.56.04 pgoyette src/share/man/man4/man4.x86/imcsmb.4,v 1.9 > >2020.04.16.19.23.50 bouyer src/sys/arch/xen/xen/Attic/xen_clock.c,v 1.1 > > >2020.04.16.15.47.19 christos > > src/external/gpl3/binutils/dist/ld/emultempl/elf.em,v 1.2 > >2020.04.16.15.58.13 jdolecek > > src/sys/external/mit/xen-include-public/dist/xen/include/public/io/blkif.h,v > > 1.2 > >2020.04.16.16.38.43 jdolecek src/sys/arch/xen/xen/xbd_xenbus.c,v 1.116 > >2020.04.16.17.18.27 nat src/sys/dev/ic/rtwnreg.h,v 1.3 > >2020.04.16.17.18.27 nat src/sys/dev/usb/if_urtwn.c,v 1.86 > > The latter two reports are spurious, and the commits listed in them > have nothing to do with the breakage. The reason for the spurious > reports is that a large number of t_ptrace_wait* test cases started > failing with the commit listen in the first report, but are not failing > in every run. Tests that happened to pass in the first run and fail > four times in a row after that got reported one commit too late, etc. AFAICT the tests are bad. They fail significantly more often when compiled with optimisations than without, strongly suggesting race conditions involved. The original change here certainly changes the timing and I am aware of one potential bug in it, but that bug is most definitely not exercised by the test cases. Joerg
Re: Automated report: NetBSD-current/i386 test failure
On Sat, Apr 18, 2020 at 01:09:52AM +, NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > lib/libc/sys/t_ptrace_wait4:fork10 > lib/libc/sys/t_ptrace_wait4:fork2 > lib/libc/sys/t_ptrace_wait4:fork4 > lib/libc/sys/t_ptrace_wait4:fork6 > lib/libc/sys/t_ptrace_wait4:fork8 > lib/libc/sys/t_ptrace_wait4:fork_singalmasked > lib/libc/sys/t_ptrace_wait4:unrelated_tracer_fork16 > lib/libc/sys/t_ptrace_wait6:fork14 > lib/libc/sys/t_ptrace_wait6:fork4 > lib/libc/sys/t_ptrace_wait6:fork_singalmasked > lib/libc/sys/t_ptrace_wait6:unrelated_tracer_fork14 > lib/libc/sys/t_ptrace_wait6:unrelated_tracer_fork2 > lib/libc/sys/t_ptrace_wait6:unrelated_tracer_fork4 > lib/libc/sys/t_ptrace_waitid:fork14 > lib/libc/sys/t_ptrace_waitid:fork2 > lib/libc/sys/t_ptrace_waitid:fork4 > lib/libc/sys/t_ptrace_waitid:fork6 > lib/libc/sys/t_ptrace_waitid:fork8 > lib/libc/sys/t_ptrace_waitid:fork_singalmasked > lib/libc/sys/t_ptrace_waitid:unrelated_tracer_fork10 > lib/libc/sys/t_ptrace_waitid:unrelated_tracer_fork12 > lib/libc/sys/t_ptrace_waitid:unrelated_tracer_fork8 > lib/libc/sys/t_ptrace_waitpid:fork10 > lib/libc/sys/t_ptrace_waitpid:fork12 > lib/libc/sys/t_ptrace_waitpid:fork14 > lib/libc/sys/t_ptrace_waitpid:fork16 > lib/libc/sys/t_ptrace_waitpid:fork2 > lib/libc/sys/t_ptrace_waitpid:fork4 > lib/libc/sys/t_ptrace_waitpid:fork6 > lib/libc/sys/t_ptrace_waitpid:fork8 > lib/libc/sys/t_ptrace_waitpid:fork_singalignored > lib/libc/sys/t_ptrace_waitpid:fork_singalmasked > lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_fork2 > lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_fork8 > > The above tests failed in each of the last 4 test runs, and passed in > at least 26 consecutive runs before that. > > The following commits were made between the last successful test and > the failed test: > > 2020.04.16.14.39.58 joerg src/lib/libc/gen/pthread_atfork.c,v 1.13 > 2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/rtld.c,v 1.204 > 2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/rtld.h,v 1.139 > 2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/symbols.map,v 1.3 Working on it. Joerg
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture sent three reports listing the following groups of commits, respectively: >2020.04.16.14.39.58 joerg src/lib/libc/gen/pthread_atfork.c,v 1.13 >2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/rtld.c,v 1.204 >2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/rtld.h,v 1.139 >2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/symbols.map,v 1.3 >2020.04.16.18.20.46 msaitoh src/sys/dev/pci/pcidevs,v 1.1406 >2020.04.16.18.21.12 msaitoh src/sys/dev/pci/pcidevs.h,v 1.1394 >2020.04.16.18.21.12 msaitoh src/sys/dev/pci/pcidevs_data.h,v 1.1393 >2020.04.16.18.32.29 msaitoh src/sys/dev/pci/ichsmb.c,v 1.67 >2020.04.16.18.51.47 pgoyette src/share/man/man4/man4.x86/imcsmb.4,v 1.8 >2020.04.16.18.56.04 pgoyette src/share/man/man4/man4.x86/imcsmb.4,v 1.9 >2020.04.16.19.23.50 bouyer src/sys/arch/xen/xen/Attic/xen_clock.c,v 1.1 >2020.04.16.15.47.19 christos > src/external/gpl3/binutils/dist/ld/emultempl/elf.em,v 1.2 >2020.04.16.15.58.13 jdolecek > src/sys/external/mit/xen-include-public/dist/xen/include/public/io/blkif.h,v > 1.2 >2020.04.16.16.38.43 jdolecek src/sys/arch/xen/xen/xbd_xenbus.c,v 1.116 >2020.04.16.17.18.27 nat src/sys/dev/ic/rtwnreg.h,v 1.3 >2020.04.16.17.18.27 nat src/sys/dev/usb/if_urtwn.c,v 1.86 The latter two reports are spurious, and the commits listed in them have nothing to do with the breakage. The reason for the spurious reports is that a large number of t_ptrace_wait* test cases started failing with the commit listen in the first report, but are not failing in every run. Tests that happened to pass in the first run and fail four times in a row after that got reported one commit too late, etc. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > fs/puffs/t_basic:root_chrdev > fs/puffs/t_basic:root_fifo > fs/puffs/t_basic:root_lnk (etc) These are already reported in kern/55146 as the automated report was delayed until kern/54786 got fixed. Some but not all of the failures reported are already fixed; a more up-to-date list of the tests still failing is at http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2020/2020.04.06.20.26.16/test.html#failed-tcs-summary -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
On 31/03/2020 12:22, NetBSD Test Fixture wrote: The newly failing test case is: usr.bin/infocmp/t_terminfo:basic This error in infocmp is now fixed. Roy
Re: Automated report: NetBSD-current/i386 test failure
Probably mine - working on it On Wed, 18 Mar 2020, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: dev/sysmon/t_swsensor:alarm_sensor dev/sysmon/t_swsensor:entropy_interrupt_sensor dev/sysmon/t_swsensor:entropy_polled_sensor dev/sysmon/t_swsensor:limit_sensor dev/sysmon/t_swsensor:simple_sensor The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.03.16.20.07.44 ad src/sys/uvm/pmap/pmap_pvt.c,v 1.10 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/if_xennet_xenbus.c,v 1.89 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/xennet_checksum.c,v 1.5 2020.03.16.20.49.22 jdolecek src/sys/arch/xen/xen/xennetback_xenbus.c,v 1.77 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/include/xennet_checksum.h,v 1.2 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/if_xennet_xenbus.c,v 1.90 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/xennet_checksum.c,v 1.6 2020.03.16.20.51.36 jdolecek src/sys/arch/xen/xen/xennetback_xenbus.c,v 1.78 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_mod.c,v 1.12 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_sysctl.c,v 1.45 2020.03.16.21.20.09 pgoyette src/sys/compat/linux/common/linux_sysctl.h,v 1.7 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_mod.c,v 1.13 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_sysctl.c,v 1.18 2020.03.16.21.20.09 pgoyette src/sys/compat/linux32/common/linux32_sysctl.h,v 1.5 2020.03.16.21.20.09 pgoyette src/sys/dev/acpi/acpi_cpu.c,v 1.52 2020.03.16.21.20.09 pgoyette src/sys/dev/pci/ubsec.c,v 1.48 2020.03.16.21.20.09 pgoyette src/sys/dev/sysmon/swsensor.c,v 1.16 2020.03.16.21.20.09 pgoyette src/sys/dev/sysmon/swwdog.c,v 1.22 2020.03.16.21.20.09 pgoyette src/sys/fs/adosfs/advfsops.c,v 1.79 2020.03.16.21.20.09 pgoyette src/sys/fs/autofs/autofs_vfsops.c,v 1.10 2020.03.16.21.20.09 pgoyette src/sys/fs/cd9660/cd9660_vfsops.c,v 1.95 2020.03.16.21.20.10 pgoyette src/sys/fs/filecorefs/filecore_vfsops.c,v 1.83 2020.03.16.21.20.10 pgoyette src/sys/fs/msdosfs/msdosfs_vfsops.c,v 1.133 2020.03.16.21.20.10 pgoyette src/sys/fs/nilfs/nilfs_vfsops.c,v 1.26 2020.03.16.21.20.10 pgoyette src/sys/fs/ptyfs/ptyfs_vfsops.c,v 1.58 2020.03.16.21.20.10 pgoyette src/sys/fs/smbfs/smbfs_vfsops.c,v 1.109 2020.03.16.21.20.10 pgoyette src/sys/fs/udf/udf_vfsops.c,v 1.78 2020.03.16.21.20.10 pgoyette src/sys/fs/union/union_vfsops.c,v 1.81 2020.03.16.21.20.10 pgoyette src/sys/kern/sys_aio.c,v 1.47 2020.03.16.21.20.10 pgoyette src/sys/kern/sys_mqueue.c,v 1.46 2020.03.16.21.20.10 pgoyette src/sys/kern/vfs_wapbl.c,v 1.106 2020.03.16.21.20.11 pgoyette src/sys/miscfs/fdesc/fdesc_vfsops.c,v 1.94 2020.03.16.21.20.11 pgoyette src/sys/miscfs/kernfs/kernfs_vfsops.c,v 1.99 2020.03.16.21.20.11 pgoyette src/sys/miscfs/nullfs/null_vfsops.c,v 1.97 2020.03.16.21.20.11 pgoyette src/sys/miscfs/overlay/overlay_vfsops.c,v 1.69 2020.03.16.21.20.11 pgoyette src/sys/miscfs/procfs/procfs_vfsops.c,v 1.103 2020.03.16.21.20.11 pgoyette src/sys/miscfs/umapfs/umap_vfsops.c,v 1.102 2020.03.16.21.20.11 pgoyette src/sys/net/bpf.c,v 1.236 2020.03.16.21.20.11 pgoyette src/sys/netinet/accf_http.c,v 1.10 2020.03.16.21.20.11 pgoyette src/sys/nfs/nfs_vfsops.c,v 1.240 2020.03.16.21.20.12 pgoyette src/sys/opencrypto/crypto.c,v 1.113 2020.03.16.21.20.12 pgoyette src/sys/secmodel/bsd44/bsd44.h,v 1.7 2020.03.16.21.20.12 pgoyette src/sys/secmodel/bsd44/secmodel_bsd44.c,v 1.17 2020.03.16.21.20.12 pgoyette src/sys/secmodel/extensions/secmodel_extensions.c,v 1.12 2020.03.16.21.20.12 pgoyette src/sys/secmodel/overlay/secmodel_overlay.c,v 1.14 2020.03.16.21.20.12 pgoyette src/sys/secmodel/securelevel/secmodel_securelevel.c,v 1.34 2020.03.16.21.20.12 pgoyette src/sys/secmodel/securelevel/securelevel.h,v 1.5 2020.03.16.21.20.12 pgoyette src/sys/secmodel/suser/secmodel_suser.c,v 1.52 2020.03.16.21.20.12 pgoyette src/sys/secmodel/suser/suser.h,v 1.3 2020.03.16.21.20.12 pgoyette src/sys/ufs/ext2fs/ext2fs_vfsops.c,v 1.217 2020.03.16.21.20.12 pgoyette src/sys/ufs/ffs/ffs_vfsops.c,v 1.366 2020.03.16.21.20.13 pgoyette src/sys/ufs/lfs/lfs_vfsops.c,v 1.377 2020.03.16.21.20.13 pgoyette src/sys/ufs/mfs/mfs_vfsops.c,v 1.114 2020.03.16.21.20.13 pgoyette src/sys/ufs/ufs/ufs_dirhash.c,v 1.40 2020.03.16.22.02.37 macallan src/sys/arch/powerpc/oea/ofw_rascons.c,v 1.14 2020.03.16.22.02.37 macallan src/sys/arch/powerpc/oea/ofw_rasconsvar.h,v 1.3 2020.03.17.00.30.17 ad src/sys/uvm/uvm_page_array.c,v 1.5 2020.03.17.00.50.12 fox src/external/cddl/osnet/lib/libdtrace/Makefile,v 1.27 2020.03.17.00.54.03 fox
Re: Automated report: NetBSD-current/i386 test failure
This morning, the NetBSD Test Fixture wrote: > The newly failing test case is: > > net/if_ipsec/t_ipsec_natt:ipsecif_natt_transport_rijndaelcbc > > The above test failed in each of the last 3 test runs, and passed in > at least 27 consecutive runs before that. > > The following commits were made between the last successful test and > the failed test: > > 2020.03.04.22.00.03 ad src/sys/arch/x86/x86/pmap.c,v 1.362 > 2020.03.04.22.07.08 christos src/external/bsd/Makefile,v 1.68 > 2020.03.04.22.09.00 christos src/distrib/sets/lists/base/mi,v 1.1231 > 2020.03.04.22.09.00 christos src/distrib/sets/lists/debug/mi,v 1.296 > 2020.03.04.22.24.46 fcambus src/share/misc/inter.phone,v 1.32 > 2020.03.04.22.56.08 jmcneill src/external/bsd/Makefile,v 1.69 I'm not sure what happened here. The ipsecif_natt_transport_null and ipsecif_natt_transport_rijndaelcbc test cases both failed in the same three consecutive tests which seems unlikely to be a coincidence, but whatever it was, it appears to have been resolved as they have both passed twice since then. Here are the outcomes of the last 40 runs for the two test cases with "-" meaning success and "X" meaning failure: XX-X--X-X--XXX-- net/if_ipsec/t_ipsec_natt:ipsecif_natt_transport_null -X-XXX-- net/if_ipsec/t_ipsec_natt:ipsecif_natt_transport_rijndaelcbc -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > The newly failing test case is: > > net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_ah_null > > The above test failed in each of the last 3 test runs, and passed in > at least 27 consecutive runs before that. The fourth test run passed, so this looks like another random occurrcence made more likely by the high frequency of ipsec test failures reported in PR 54897. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > The newly failing test case is: > > net/ipsec/t_ipsec_tunnel:ipsec_tunnel_ipv4_ah_keyedmd5 > > The above test failed in each of the last 3 test runs, and passed in > at least 27 consecutive runs before that. > > The following commits were made between the last successful test and > the failed test: > > 2020.01.28.07.43.42 martin src/usr.sbin/sysinst/partitions.c,v 1.10 > 2020.01.28.07.47.26 skrll src/sys/arch/arm/mainbus/cpu_mainbus.c,v 1.17 > 2020.01.28.08.09.19 martin src/sys/dev/fdt/fdtbus.c,v 1.32 > 2020.01.28.09.23.15 ad src/lib/libpthread/pthread.c,v 1.158 This is probably unrelated to the commits listed. As reported in PR 54897, many IPSEC tests are failing randomly since Feb 15, and with so many randomly failing tests, one of them failing three times in a row after succeeding 27 times is not all that unlikely. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
On Wed, Jan 29, 2020 at 02:45:22AM +, NetBSD Test Fixture wrote: > The newly failing test case is: > > lib/libpthread/t_detach:pthread_detach ... > 2020.01.27.20.50.05 ad src/lib/libpthread/pthread.c,v 1.157 Wrong error code from the kernel (ESRCH vs EINVAL) worked around with pthread.c 1.158 and will be fixed properly soon. Andrew
Re: Automated report: NetBSD-current/i386 test failure
The remaining failures should be fixed by: 1.181 src/sys/rump/librump/rumpkern/vm.c Cheers, Andrew On Thu, Jan 02, 2020 at 01:26:42PM +, Andrew Doran wrote: > I think this is likely fixed already but will take a look now. > > Andrew > > On Thu, Jan 02, 2020 at 08:35:09AM +, NetBSD Test Fixture wrote: > > > This is an automatically generated notice of new failures of the > > NetBSD test suite. > > > > The newly failing test cases are: > > > > fs/ffs/t_miscquota:log_unlink > > fs/ffs/t_miscquota:log_unlink_remount > > fs/ffs/t_miscquota:npsnapshot_unconf_user > > fs/ffs/t_miscquota:npsnapshot_user > > fs/ffs/t_miscquota:psnapshot_unconf_user > > fs/ffs/t_miscquota:psnapshot_user > > fs/ffs/t_quota2_1:quota_1000_O1_be > > fs/ffs/t_quota2_1:quota_1000_O1_le > > fs/ffs/t_quota2_1:quota_1000_O2_be > > fs/ffs/t_quota2_1:quota_1000_O2_le > > fs/ffs/t_quota2_1:quota_40_O1_be > > fs/ffs/t_quota2_1:quota_40_O1_le > > fs/ffs/t_quota2_1:quota_40_O1_log > > fs/ffs/t_quota2_1:quota_40_O2_be > > fs/ffs/t_quota2_1:quota_40_O2_le > > fs/ffs/t_quota2_1:quota_40_O2_log > > fs/ffs/t_quota2_remount:quota_10_O1_be > > fs/ffs/t_quota2_remount:quota_10_O1_le > > fs/ffs/t_quotalimit:herit_defq_le_1_group > > fs/ffs/t_quotalimit:herit_defq_le_1_group_log > > fs/ffs/t_quotalimit:herit_defq_le_1_user > > fs/ffs/t_quotalimit:herit_defq_le_1_user_log > > fs/ffs/t_quotalimit:herit_idefq_le_1_group_log > > fs/ffs/t_quotalimit:herit_idefq_le_1_user_log > > fs/ffs/t_quotalimit:inolimit_le_1_group > > fs/ffs/t_quotalimit:inolimit_le_1_group_log > > fs/ffs/t_quotalimit:inolimit_le_1_user > > fs/ffs/t_quotalimit:inolimit_le_1_user_log > > fs/ffs/t_quotalimit:limit_le_1_group > > fs/ffs/t_quotalimit:limit_le_1_group_log > > fs/ffs/t_quotalimit:limit_le_1_user > > fs/ffs/t_quotalimit:limit_le_1_user_log > > fs/ffs/t_quotalimit:sinolimit_le_1_group > > fs/ffs/t_quotalimit:sinolimit_le_1_user > > fs/ffs/t_quotalimit:slimit_le_1_group > > fs/ffs/t_quotalimit:slimit_le_1_user > > fs/ffs/t_snapshot:snapshot > > fs/ffs/t_snapshot:snapshotstress > > fs/ffs/t_snapshot_log:snapshot > > fs/ffs/t_snapshot_log:snapshotstress > > fs/ffs/t_snapshot_v2:snapshot > > fs/ffs/t_snapshot_v2:snapshotstress > > fs/ffs/t_update_log:updaterwtolog > > fs/ffs/t_update_log:updaterwtolog_async > > fs/msdosfs/t_snapshot:snapshot > > fs/msdosfs/t_snapshot:snapshotstress > > fs/vfs/t_full:ext2fs_fillfs > > fs/vfs/t_full:tmpfs_fillfs > > fs/vfs/t_io:ext2fs_extendfile > > fs/vfs/t_io:ext2fs_extendfile_append > > fs/vfs/t_io:ext2fs_holywrite > > fs/vfs/t_io:ext2fs_overwrite512 > > fs/vfs/t_io:ext2fs_overwrite64k > > fs/vfs/t_io:ext2fs_overwrite_trunc > > fs/vfs/t_io:ext2fs_read_after_unlink > > fs/vfs/t_io:ext2fs_read_fault > > fs/vfs/t_io:ext2fs_shrinkfile > > fs/vfs/t_io:ext2fs_wrrd_after_unlink > > fs/vfs/t_io:ffs_extendfile > > fs/vfs/t_io:ffs_extendfile_append > > fs/vfs/t_io:ffs_holywrite > > fs/vfs/t_io:ffs_overwrite512 > > fs/vfs/t_io:ffs_read_after_unlink > > fs/vfs/t_io:ffs_read_fault > > fs/vfs/t_io:ffs_shrinkfile > > fs/vfs/t_io:ffs_wrrd_after_unlink > > fs/vfs/t_io:ffslog_extendfile > > fs/vfs/t_io:ffslog_extendfile_append > > fs/vfs/t_io:ffslog_holywrite > > fs/vfs/t_io:ffslog_overwrite512 > > fs/vfs/t_io:ffslog_read_after_unlink > > fs/vfs/t_io:ffslog_read_fault > > fs/vfs/t_io:ffslog_shrinkfile > > fs/vfs/t_io:ffslog_wrrd_after_unlink > > fs/vfs/t_io:nfs_extendfile > > fs/vfs/t_io:nfs_extendfile_append > > fs/vfs/t_io:nfs_holywrite > > fs/vfs/t_io:nfs_overwrite512 > > fs/vfs/t_io:nfs_read_after_unlink > > fs/vfs/t_io:nfs_read_fault > > fs/vfs/t_io:nfs_shrinkfile > > fs/vfs/t_io:nfs_wrrd_after_unlink > > fs/vfs/t_io:p2k_ffs_extendfile > > fs/vfs/t_io:p2k_ffs_extendfile_append > > fs/vfs/t_io:p2k_ffs_holywrite > > fs/vfs/t_io:p2k_ffs_overwrite512 > > fs/vfs/t_io:p2k_ffs_read_after_unlink > > fs/vfs/t_io:p2k_ffs_read_fault > > fs/vfs/t_io:p2k_ffs_shrinkfile > > fs/vfs/t_io:p2k_ffs_wrrd_after_unlink > > fs/vfs/t_io:tmpfs_extendfile > > fs/vfs/t_io:tmpfs_extendfile_append > > fs/vfs/t_io:tmpfs_holywrite > > fs/vfs/t_io:tmpfs_overwrite512 > > fs/vfs/t_io:tmpfs_overwrite64k > > fs/vfs/t_io:tmpfs_overwrite_trunc > > fs/vfs/t_io:tmpfs_read_after_unlink > > fs/vfs/t_io:tmpfs_read_fault > > fs/vfs/t_io:tmpfs_shrinkfile > > fs/vfs/t_io:tmpfs_wrrd_after_unlink > > fs/vfs/t_mtime_write:ext2fs_mtime_update_on_write > > fs/vfs/t_mtime_write:ffs_mtime_update_on_write > > fs/vfs/t_mtime_write:ffslog_mtime_update_on_write > > fs/vfs/t_mtime_write:nfs_mtime_update_on_write > > fs/vfs/t_mtime_write:p2k_ffs_mtime_update_on_write > >
Re: Automated report: NetBSD-current/i386 test failure
I think this is likely fixed already but will take a look now. Andrew On Thu, Jan 02, 2020 at 08:35:09AM +, NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > fs/ffs/t_miscquota:log_unlink > fs/ffs/t_miscquota:log_unlink_remount > fs/ffs/t_miscquota:npsnapshot_unconf_user > fs/ffs/t_miscquota:npsnapshot_user > fs/ffs/t_miscquota:psnapshot_unconf_user > fs/ffs/t_miscquota:psnapshot_user > fs/ffs/t_quota2_1:quota_1000_O1_be > fs/ffs/t_quota2_1:quota_1000_O1_le > fs/ffs/t_quota2_1:quota_1000_O2_be > fs/ffs/t_quota2_1:quota_1000_O2_le > fs/ffs/t_quota2_1:quota_40_O1_be > fs/ffs/t_quota2_1:quota_40_O1_le > fs/ffs/t_quota2_1:quota_40_O1_log > fs/ffs/t_quota2_1:quota_40_O2_be > fs/ffs/t_quota2_1:quota_40_O2_le > fs/ffs/t_quota2_1:quota_40_O2_log > fs/ffs/t_quota2_remount:quota_10_O1_be > fs/ffs/t_quota2_remount:quota_10_O1_le > fs/ffs/t_quotalimit:herit_defq_le_1_group > fs/ffs/t_quotalimit:herit_defq_le_1_group_log > fs/ffs/t_quotalimit:herit_defq_le_1_user > fs/ffs/t_quotalimit:herit_defq_le_1_user_log > fs/ffs/t_quotalimit:herit_idefq_le_1_group_log > fs/ffs/t_quotalimit:herit_idefq_le_1_user_log > fs/ffs/t_quotalimit:inolimit_le_1_group > fs/ffs/t_quotalimit:inolimit_le_1_group_log > fs/ffs/t_quotalimit:inolimit_le_1_user > fs/ffs/t_quotalimit:inolimit_le_1_user_log > fs/ffs/t_quotalimit:limit_le_1_group > fs/ffs/t_quotalimit:limit_le_1_group_log > fs/ffs/t_quotalimit:limit_le_1_user > fs/ffs/t_quotalimit:limit_le_1_user_log > fs/ffs/t_quotalimit:sinolimit_le_1_group > fs/ffs/t_quotalimit:sinolimit_le_1_user > fs/ffs/t_quotalimit:slimit_le_1_group > fs/ffs/t_quotalimit:slimit_le_1_user > fs/ffs/t_snapshot:snapshot > fs/ffs/t_snapshot:snapshotstress > fs/ffs/t_snapshot_log:snapshot > fs/ffs/t_snapshot_log:snapshotstress > fs/ffs/t_snapshot_v2:snapshot > fs/ffs/t_snapshot_v2:snapshotstress > fs/ffs/t_update_log:updaterwtolog > fs/ffs/t_update_log:updaterwtolog_async > fs/msdosfs/t_snapshot:snapshot > fs/msdosfs/t_snapshot:snapshotstress > fs/vfs/t_full:ext2fs_fillfs > fs/vfs/t_full:tmpfs_fillfs > fs/vfs/t_io:ext2fs_extendfile > fs/vfs/t_io:ext2fs_extendfile_append > fs/vfs/t_io:ext2fs_holywrite > fs/vfs/t_io:ext2fs_overwrite512 > fs/vfs/t_io:ext2fs_overwrite64k > fs/vfs/t_io:ext2fs_overwrite_trunc > fs/vfs/t_io:ext2fs_read_after_unlink > fs/vfs/t_io:ext2fs_read_fault > fs/vfs/t_io:ext2fs_shrinkfile > fs/vfs/t_io:ext2fs_wrrd_after_unlink > fs/vfs/t_io:ffs_extendfile > fs/vfs/t_io:ffs_extendfile_append > fs/vfs/t_io:ffs_holywrite > fs/vfs/t_io:ffs_overwrite512 > fs/vfs/t_io:ffs_read_after_unlink > fs/vfs/t_io:ffs_read_fault > fs/vfs/t_io:ffs_shrinkfile > fs/vfs/t_io:ffs_wrrd_after_unlink > fs/vfs/t_io:ffslog_extendfile > fs/vfs/t_io:ffslog_extendfile_append > fs/vfs/t_io:ffslog_holywrite > fs/vfs/t_io:ffslog_overwrite512 > fs/vfs/t_io:ffslog_read_after_unlink > fs/vfs/t_io:ffslog_read_fault > fs/vfs/t_io:ffslog_shrinkfile > fs/vfs/t_io:ffslog_wrrd_after_unlink > fs/vfs/t_io:nfs_extendfile > fs/vfs/t_io:nfs_extendfile_append > fs/vfs/t_io:nfs_holywrite > fs/vfs/t_io:nfs_overwrite512 > fs/vfs/t_io:nfs_read_after_unlink > fs/vfs/t_io:nfs_read_fault > fs/vfs/t_io:nfs_shrinkfile > fs/vfs/t_io:nfs_wrrd_after_unlink > fs/vfs/t_io:p2k_ffs_extendfile > fs/vfs/t_io:p2k_ffs_extendfile_append > fs/vfs/t_io:p2k_ffs_holywrite > fs/vfs/t_io:p2k_ffs_overwrite512 > fs/vfs/t_io:p2k_ffs_read_after_unlink > fs/vfs/t_io:p2k_ffs_read_fault > fs/vfs/t_io:p2k_ffs_shrinkfile > fs/vfs/t_io:p2k_ffs_wrrd_after_unlink > fs/vfs/t_io:tmpfs_extendfile > fs/vfs/t_io:tmpfs_extendfile_append > fs/vfs/t_io:tmpfs_holywrite > fs/vfs/t_io:tmpfs_overwrite512 > fs/vfs/t_io:tmpfs_overwrite64k > fs/vfs/t_io:tmpfs_overwrite_trunc > fs/vfs/t_io:tmpfs_read_after_unlink > fs/vfs/t_io:tmpfs_read_fault > fs/vfs/t_io:tmpfs_shrinkfile > fs/vfs/t_io:tmpfs_wrrd_after_unlink > fs/vfs/t_mtime_write:ext2fs_mtime_update_on_write > fs/vfs/t_mtime_write:ffs_mtime_update_on_write > fs/vfs/t_mtime_write:ffslog_mtime_update_on_write > fs/vfs/t_mtime_write:nfs_mtime_update_on_write > fs/vfs/t_mtime_write:p2k_ffs_mtime_update_on_write > fs/vfs/t_mtime_write:tmpfs_mtime_update_on_write > fs/vfs/t_ro:ext2fs_attrs > fs/vfs/t_ro:ext2fs_createlink > fs/vfs/t_ro:ext2fs_fileio > fs/vfs/t_ro:ext2fs_rmfile > fs/vfs/t_ro:ffs_attrs > fs/vfs/t_ro:ffs_createlink > fs/vfs/t_ro:ffs_fileio > fs/vfs/t_ro:ffs_rmfile > fs/vfs/t_ro:ffslog_attrs > fs/vfs/t_ro:ffslog_createlink > fs/vfs/t_ro:ffslog_fileio >
Re: Automated report: NetBSD-current/i386 test failure
On Wed, Dec 18, 2019 at 01:27:32PM +, Andrew Doran wrote: > On Wed, Dec 18, 2019 at 08:25:15AM +, NetBSD Test Fixture wrote: > > > This is an automatically generated notice of new failures of the > > NetBSD test suite. > > > > The newly failing test cases are: > > > > fs/vfs/t_full:lfs_fillfs > > fs/vfs/t_io:lfs_extendfile > > fs/vfs/t_io:lfs_extendfile_append > > fs/vfs/t_io:lfs_holywrite > > fs/vfs/t_io:lfs_overwrite512 > > fs/vfs/t_io:lfs_overwrite64k > > fs/vfs/t_io:lfs_overwrite_trunc > > fs/vfs/t_io:lfs_read_after_unlink > > fs/vfs/t_io:lfs_read_fault > > fs/vfs/t_io:lfs_shrinkfile > > fs/vfs/t_io:lfs_wrrd_after_unlink > > fs/vfs/t_mtime_write:lfs_mtime_update_on_write > > fs/vfs/t_union:lfs_basic > > fs/vfs/t_vfsops:lfs_tfilehandle > > fs/vfs/t_vnops:lfs_fcntl_getlock_pids > > fs/vfs/t_vnops:lfs_fcntl_lock These should be fixed with revision 1.18 of src/sys/ufs/lfs/lfs_pages.c. Andrew
Re: Automated report: NetBSD-current/i386 test failure
Andrew Doran wrote: > > sbin/resize_ffs/t_grow:grow_16M_v1_16384 > > sbin/resize_ffs/t_grow:grow_16M_v2_32768 > > sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536 > > sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096 > > sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192 > > sbin/resize_ffs/t_shrink:shrink_24M_16M_v0_32768 > > sbin/resize_ffs/t_shrink:shrink_24M_16M_v1_65536 > > sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v0_4096 > > sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v1_8192 > > Hmm, I wonder I this is a rump issue. In any case I'll take a look into the > failures this evening. Looks like the resize_ffs failures have been fixed already: http://www.gson.org/netbsd/bugs/build/i386-baremetal/commits-2019.12.html#2019.12.17.18.59.39 The lfs ones are still failing. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
On Wed, Dec 18, 2019 at 08:25:15AM +, NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > fs/vfs/t_full:lfs_fillfs > fs/vfs/t_io:lfs_extendfile > fs/vfs/t_io:lfs_extendfile_append > fs/vfs/t_io:lfs_holywrite > fs/vfs/t_io:lfs_overwrite512 > fs/vfs/t_io:lfs_overwrite64k > fs/vfs/t_io:lfs_overwrite_trunc > fs/vfs/t_io:lfs_read_after_unlink > fs/vfs/t_io:lfs_read_fault > fs/vfs/t_io:lfs_shrinkfile > fs/vfs/t_io:lfs_wrrd_after_unlink > fs/vfs/t_mtime_write:lfs_mtime_update_on_write > fs/vfs/t_union:lfs_basic > fs/vfs/t_vfsops:lfs_tfilehandle > fs/vfs/t_vnops:lfs_fcntl_getlock_pids > fs/vfs/t_vnops:lfs_fcntl_lock Unsurprising. I had to spend a couple of hours fiding & fixing an aincent bug in LFS to get the tests to pass beore commit. > sbin/resize_ffs/t_grow:grow_16M_v1_16384 > sbin/resize_ffs/t_grow:grow_16M_v2_32768 > sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536 > sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096 > sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192 > sbin/resize_ffs/t_shrink:shrink_24M_16M_v0_32768 > sbin/resize_ffs/t_shrink:shrink_24M_16M_v1_65536 > sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v0_4096 > sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v1_8192 Hmm, I wonder I this is a rump issue. In any case I'll take a look into the failures this evening. Cheers, Andrew
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > The newly failing test case is: > > sbin/resize_ffs/t_grow:grow_16M_v0_8192 > > The above test failed in each of the last 4 test runs, and passed in > at least 36 consecutive runs before that. > > The following commits were made between the last successful test and > the failed test: > > 2019.12.15.23.13.33 uwe src/lib/libpthread/pthread_rwlock.c,v 1.35 > 2019.12.16.00.03.50 jmcneill src/sys/arch/aarch64/aarch64/efi_machdep.c,v > 1.5 > 2019.12.16.00.03.50 jmcneill src/sys/arch/arm/arm/efi_runtime.c,v 1.3 > 2019.12.16.00.03.50 jmcneill src/sys/arch/arm/arm/efi_runtime.h,v 1.3 There was a second report that showed several other resize_ffs test cases already failing before these commits were made, so it seems likely that this particular test case just happened to randomly pass in the first run after the bug was introduced, which would mean these commits are innocent. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
Fixed in: src/tests/lib/libc/sys/t_ptrace_wait.c r.1.141 src/tests/lib/libc/sys/t_ptrace_wait.h r.1.18 On 12.11.2019 18:34, Paul Goyette wrote: > I've confirmed that these failures occur with builds from before > my most recent changes. So, as Kamil indicated (and Joerg on > IRC), it ain't my fault! > > On Tue, 12 Nov 2019, Paul Goyette wrote: > >> Hmmm, this might be my fault. Checking/bisecting now... >> >> On Tue, 12 Nov 2019, NetBSD Test Fixture wrote: >> >>> This is an automatically generated notice of new failures of the >>> NetBSD test suite. >>> >>> The newly failing test cases are: >>> >>>   lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals >>>   lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit >>>   lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals >>>   lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit >>>   lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals >>>   lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit >>>   lib/libc/sys/t_ptrace_wait:thread_concurrent_signals >>>   lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit >>>   lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit >>>   lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals >>>   lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit >>> >>> The above tests failed in each of the last 3 test runs, and passed in >>> at least 27 consecutive runs before that. >>> >>> Between the last successful test and the failed test, a total of 10064 >>> revisions were committed, by the following developers: >>> >>>   christos >>>   chs >>>   gutteridge >>>   hannken >>>   jdolecek >>>   jmcneill >>>   joerg >>>   kamil >>>   maxv >>>   mlelstv >>>   mrg >>>   msaitoh >>>   nisimura >>>   pgoyette >>>   roy >>>   sevan >>>   tnn >>>   yamaguchi >>> >>> Log files can be found at: >>> >>>   >>> http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 >>> >>> >>> !DSPAM:5dca6d0b256033292947347! >>> >>> >> >> ++--+---+ >> | Paul Goyette  | PGP Key fingerprint: | E-mail addresses: | >> | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | >> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org  | >> ++--+---+ >> > > ++--+---+ > | Paul Goyette  | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org  | > ++--+---+ signature.asc Description: OpenPGP digital signature
Re: Automated report: NetBSD-current/i386 test failure
I've confirmed that these failures occur with builds from before my most recent changes. So, as Kamil indicated (and Joerg on IRC), it ain't my fault! On Tue, 12 Nov 2019, Paul Goyette wrote: Hmmm, this might be my fault. Checking/bisecting now... On Tue, 12 Nov 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait:thread_concurrent_signals lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. Between the last successful test and the failed test, a total of 10064 revisions were committed, by the following developers: christos chs gutteridge hannken jdolecek jmcneill joerg kamil maxv mlelstv mrg msaitoh nisimura pgoyette roy sevan tnn yamaguchi Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 !DSPAM:5dca6d0b256033292947347! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
The problem is in ATF tests with assumptions that are no longer valid. We are working on this. The right fix is to improve the tests. On 12.11.2019 13:53, Paul Goyette wrote: > Hmmm, this might be my fault. Checking/bisecting now... > > On Tue, 12 Nov 2019, NetBSD Test Fixture wrote: > >> This is an automatically generated notice of new failures of the >> NetBSD test suite. >> >> The newly failing test cases are: >> >>   lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals >>   lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit >>   lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals >>   lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit >>   lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals >>   lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit >>   lib/libc/sys/t_ptrace_wait:thread_concurrent_signals >>   lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit >>   lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit >>   lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals >>   lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit >> >> The above tests failed in each of the last 3 test runs, and passed in >> at least 27 consecutive runs before that. >> >> Between the last successful test and the failed test, a total of 10064 >> revisions were committed, by the following developers: >> >>   christos >>   chs >>   gutteridge >>   hannken >>   jdolecek >>   jmcneill >>   joerg >>   kamil >>   maxv >>   mlelstv >>   mrg >>   msaitoh >>   nisimura >>   pgoyette >>   roy >>   sevan >>   tnn >>   yamaguchi >> >> Log files can be found at: >> >>   >> http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 >> >> >> !DSPAM:5dca6d0b256033292947347! >> >> > > ++--+---+ > | Paul Goyette  | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org  | > ++--+---+ signature.asc Description: OpenPGP digital signature
Re: Automated report: NetBSD-current/i386 test failure
On Tue, 12 Nov 2019, Kamil Rytarowski wrote: The problem is in ATF tests with assumptions that are no longer valid. We are working on this. The right fix is to improve the tests. Oh, good - not my fault after all! Thanks! On 12.11.2019 13:53, Paul Goyette wrote: Hmmm, this might be my fault.?? Checking/bisecting now... On Tue, 12 Nov 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait:thread_concurrent_signals lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. Between the last successful test and the failed test, a total of 10064 revisions were committed, by the following developers: christos chs gutteridge hannken jdolecek jmcneill joerg kamil maxv mlelstv mrg msaitoh nisimura pgoyette roy sevan tnn yamaguchi Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 !DSPAM:5dca6d0b256033292947347! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)?? | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
Hmmm, this might be my fault. Checking/bisecting now... On Tue, 12 Nov 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait:thread_concurrent_signals lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. Between the last successful test and the failed test, a total of 10064 revisions were committed, by the following developers: christos chs gutteridge hannken jdolecek jmcneill joerg kamil maxv mlelstv mrg msaitoh nisimura pgoyette roy sevan tnn yamaguchi Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 !DSPAM:5dca6d0b256033292947347! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
On 12.11.2019 09:26, NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals > lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit > lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals > lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit > lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals > lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit > lib/libc/sys/t_ptrace_wait:thread_concurrent_signals > lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit > lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit > lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals > lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit > > The above tests failed in each of the last 3 test runs, and passed in > at least 27 consecutive runs before that. > > Between the last successful test and the failed test, a total of 10064 > revisions were committed, by the following developers: > > christos > chs > gutteridge > hannken > jdolecek > jmcneill > joerg > kamil > maxv > mlelstv > mrg > msaitoh > nisimura > pgoyette > roy > sevan > tnn > yamaguchi > > Log files can be found at: > > > http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 > Looking into: thread_concurrent_signals. There are assumption in the ATF tests that are no longer valid and there is need to change the code to be more flexible to LWP ids. signature.asc Description: OpenPGP digital signature
Re: Automated report: NetBSD-current/i386 test failure
Sorry, I misread the logs - it was the wait4 variant of the test that succeeded in the test run after the wait6 one failed. In any case, this simply looks like flaky/racy tests, or ptrace(), (and certainly unrelated to the listed commits). kre
Re: Automated report: NetBSD-current/i386 test failure
Date:Fri, 18 Oct 2019 15:14:04 + (UTC) From:NetBSD Test Fixture Message-ID: <157141164388.24477.1554860029123...@babylon5.netbsd.org> | The newly failing test case is: | | lib/libc/sys/t_ptrace_waitid:tracer_sysctl_lookup_without_duplicates While that test looks flaky, that is, to have some kind of race (sometimes it works, sometimes it doesn't): | The above test failed in each of the last 3 test runs, and passed in | at least 21 consecutive runs before that. I don't see that in the test logs - it failed the time reported, and succeeded in the previous and following runs. It failed then immediately succeeded (next run) just before that as well (so no 21 successful runs before, and no 3 successive failures either). Andreas, any idea what happened there? kre
Re: Automated report: NetBSD-current/i386 test failure
On 21.09.2019 18:18, Robert Elz wrote: > Date:Sat, 21 Sep 2019 15:40:49 + (UTC) > From:NetBSD Test Fixture > Message-ID: <156908044959.2857.11788397410553967...@babylon5.netbsd.org> > > | The newly failing test cases are: > | > | fs/vfs/t_ro:ext2fs_attrs > | fs/vfs/t_ro:ffs_attrs > | fs/vfs/t_ro:ffslog_attrs > | fs/vfs/t_ro:msdosfs_attrs > | fs/vfs/t_ro:nfs_attrs > | fs/vfs/t_ro:nfsro_attrs > | fs/vfs/t_ro:sysvbfs_attrs > | fs/vfs/t_ro:udf_attrs > | fs/vfs/t_ro:v7fs_attrs > > I think this is probably now fixed - but just recently and there are > several more test runs to complete before one with the likely fix will > be seen. > > kre > Thanks for addressing it! signature.asc Description: OpenPGP digital signature
Re: Automated report: NetBSD-current/i386 test failure
Date:Sat, 21 Sep 2019 15:40:49 + (UTC) From:NetBSD Test Fixture Message-ID: <156908044959.2857.11788397410553967...@babylon5.netbsd.org> | The newly failing test cases are: | | fs/vfs/t_ro:ext2fs_attrs | fs/vfs/t_ro:ffs_attrs | fs/vfs/t_ro:ffslog_attrs | fs/vfs/t_ro:msdosfs_attrs | fs/vfs/t_ro:nfs_attrs | fs/vfs/t_ro:nfsro_attrs | fs/vfs/t_ro:sysvbfs_attrs | fs/vfs/t_ro:udf_attrs | fs/vfs/t_ro:v7fs_attrs I think this is probably now fixed - but just recently and there are several more test runs to complete before one with the likely fix will be seen. kre
Re: Automated report: NetBSD-current/i386 test failure
On Mon, Aug 26, 2019 at 03:13:29AM +, NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > net/if_ipsec/t_ipsec_pfil:ipsecif_pfil_esp_null > net/if_ipsec/t_ipsec_pfil:ipsecif_pfil_esp_rijndaelcbc > net/npf/t_npf:npf_bpf > net/npf/t_npf:npf_conn > net/npf/t_npf:npf_nbuf > net/npf/t_npf:npf_state > > The above tests failed in each of the last 3 test runs, and passed in > at least 27 consecutive runs before that. > > The following commits were made between the last successful test and > the failed test: > > 2019.08.24.12.33.25 maxv src/sys/compat/linux/common/linux_socket.c,v > 1.146 > 2019.08.24.12.33.25 maxv src/sys/compat/linux/common/linux_socket.h,v 1.24 > 2019.08.24.12.58.24 hannken > src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c,v 1.51 > 2019.08.24.12.59.05 hannken > src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c,v 1.52 > 2019.08.24.12.59.34 hannken > src/external/cddl/osnet/dist/uts/common/fs/zfs/dnode.c,v 1.8 > 2019.08.24.13.20.52 rmind src/lib/libnpf/Makefile,v 1.11 > 2019.08.24.13.20.52 rmind src/lib/npf/mod.mk,v 1.8 > 2019.08.24.13.20.52 rmind src/libexec/identd/Makefile,v 1.18 > 2019.08.24.13.20.52 rmind src/usr.sbin/npf/npfctl/Makefile,v 1.14 > 2019.08.24.13.20.52 rmind src/usr.sbin/npf/npfd/Makefile,v 1.7 > > Log files can be found at: > > > http://releng.NetBSD.org/b5reports/i386/commits-2019.08.html#2019.08.24.13.20.52 This also broke the build for aarch64, hppa and sun2. 10:49 i think the problem is that we'll have to make it -lnpf -lnv 10:50 with the private library objdir added to the -L path or similar see: http://releng.netbsd.org/cgi-bin/builds.cgi ... but maybe some of that will have been fixed in the mean time before you get to dealing with this. Martin
Re: Automated report: NetBSD-current/i386 test failure
On Thu, 8 Aug 2019, Paul Goyette wrote: I am investigating... This should be fixed by sys/kern/kern_module.c rev 1.138 On Thu, 8 Aug 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: modules/t_builtin:busydisable The above test failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2019.08.07.00.38.01 pgoyette src/sys/dev/ccd.c,v 1.180 2019.08.07.00.38.02 pgoyette src/sys/dev/iscsi/iscsi_main.c,v 1.31 2019.08.07.00.38.02 pgoyette src/sys/dev/usb/usbnet.c,v 1.7 2019.08.07.00.38.02 pgoyette src/sys/kern/kern_module.c,v 1.137 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_ipc.c,v 1.40 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_msg.c,v 1.75 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_sem.c,v 1.98 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_shm.c,v 1.137 2019.08.07.00.38.02 pgoyette src/sys/miscfs/genfs/layer_vfsops.c,v 1.52 2019.08.07.00.38.02 pgoyette src/sys/sys/module.h,v 1.47 2019.08.07.00.38.02 pgoyette src/sys/sys/msg.h,v 1.28 2019.08.07.00.38.02 pgoyette src/sys/sys/sem.h,v 1.34 2019.08.07.00.38.02 pgoyette src/sys/sys/shm.h,v 1.53 2019.08.07.00.39.23 pgoyette src/sys/sys/param.h,v 1.603 2019.08.07.01.09.49 roy src/lib/libc/sys/read.2,v 1.37 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.08.html#2019.08.07.01.09.49 !DSPAM:5d4bb60467481808415646! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
I am investigating... On Thu, 8 Aug 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: modules/t_builtin:busydisable The above test failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2019.08.07.00.38.01 pgoyette src/sys/dev/ccd.c,v 1.180 2019.08.07.00.38.02 pgoyette src/sys/dev/iscsi/iscsi_main.c,v 1.31 2019.08.07.00.38.02 pgoyette src/sys/dev/usb/usbnet.c,v 1.7 2019.08.07.00.38.02 pgoyette src/sys/kern/kern_module.c,v 1.137 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_ipc.c,v 1.40 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_msg.c,v 1.75 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_sem.c,v 1.98 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_shm.c,v 1.137 2019.08.07.00.38.02 pgoyette src/sys/miscfs/genfs/layer_vfsops.c,v 1.52 2019.08.07.00.38.02 pgoyette src/sys/sys/module.h,v 1.47 2019.08.07.00.38.02 pgoyette src/sys/sys/msg.h,v 1.28 2019.08.07.00.38.02 pgoyette src/sys/sys/sem.h,v 1.34 2019.08.07.00.38.02 pgoyette src/sys/sys/shm.h,v 1.53 2019.08.07.00.39.23 pgoyette src/sys/sys/param.h,v 1.603 2019.08.07.01.09.49 roy src/lib/libc/sys/read.2,v 1.37 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.08.html#2019.08.07.01.09.49 !DSPAM:5d4bb60467481808415646! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > lib/libc/sys/t_ptrace_waitpid:tracer_sysctl_lookup_without_duplicates > > The above test failed in each of the last 3 test runs, and passed in > at least 22 consecutive runs before that. This test case has been failing randomly in the past and none of the commits in the report look relevant, so it probably just happened to pass 22 times and then fail 3 times in a row by pure chance rather than being triggered by any recent commit. The random failures still ought to be fixed, of course. Many other ptrace related tests are also failing randomly on the testbed, and at least one of the failures can be easily reproduced on real hardware (PR 54377). -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
On 21.06.2019 18:09, NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > fs/vfs/t_vnops:ext2fs_rename_dir > fs/vfs/t_vnops:ext2fs_rename_reg_nodir > fs/vfs/t_vnops:ffs_rename_dir > fs/vfs/t_vnops:ffs_rename_reg_nodir > fs/vfs/t_vnops:ffslog_rename_dir > fs/vfs/t_vnops:ffslog_rename_reg_nodir > fs/vfs/t_vnops:lfs_rename_dir > fs/vfs/t_vnops:lfs_rename_reg_nodir > fs/vfs/t_vnops:msdosfs_rename_dir > fs/vfs/t_vnops:msdosfs_rename_reg_nodir > fs/vfs/t_vnops:nfs_rename_dir > fs/vfs/t_vnops:p2k_ffs_rename_dir > fs/vfs/t_vnops:p2k_ffs_rename_reg_nodir > fs/vfs/t_vnops:puffs_rename_dir > fs/vfs/t_vnops:puffs_rename_reg_nodir > fs/vfs/t_vnops:sysvbfs_rename_reg_nodir > fs/vfs/t_vnops:tmpfs_rename_dir > fs/vfs/t_vnops:tmpfs_rename_reg_nodir > fs/vfs/t_vnops:udf_rename_dir > fs/vfs/t_vnops:udf_rename_reg_nodir > fs/vfs/t_vnops:v7fs_rename_dir > fs/vfs/t_vnops:v7fs_rename_reg_nodir > lib/libc/sys/t_mknod:mknod_stat > > The above tests failed in each of the last 3 test runs, and passed in > at least 27 consecutive runs before that. > > Between the last successful test and the failed test, a total of 8607 > revisions were committed, by the following developers: > > christos > hkenken > isaki > kamil > martin > mrg > pgoyette > uki > wiz > > Log files can be found at: > > > http://releng.NetBSD.org/b5reports/i386/commits-2019.06.html#2019.06.20.12.14.46 > Should be fixed with: Module Name:src Committed By: kamil Date: Fri Jun 21 14:58:32 UTC 2019 Modified Files: src/sys/kern: vfs_syscalls.c Log Message: Restore ability to create regular files with mknod(2) This behavior is requested in ATF tests. To generate a diff of this commit: cvs rdiff -u -r1.531 -r1.532 src/sys/kern/vfs_syscalls.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. signature.asc Description: OpenPGP digital signature
Re: Automated report: NetBSD-current/i386 test failure
On 03.05.2019 11:20, NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > lib/libc/sys/t_ptrace_wait3:bytes_transfer_alignment_piod_read_auxv > lib/libc/sys/t_ptrace_wait4:bytes_transfer_alignment_piod_read_auxv > lib/libc/sys/t_ptrace_wait6:bytes_transfer_alignment_piod_read_auxv > lib/libc/sys/t_ptrace_wait:bytes_transfer_alignment_piod_read_auxv > lib/libc/sys/t_ptrace_waitid:bytes_transfer_alignment_piod_read_auxv > lib/libc/sys/t_ptrace_waitpid:bytes_transfer_alignment_piod_read_auxv > > The above tests failed in each of the last 3 test runs, and passed in > at least 27 consecutive runs before that. > Fixed in t_ptrace_wait.c r. 1.120. > The following commits were made between the last successful test and > the failed test: > > 2019.05.01.23.44.16 kamil src/tests/lib/libc/sys/t_ptrace_wait.c,v 1.118 > 2019.05.02.00.23.01 kamil src/sys/kern/sys_ptrace_common.c,v 1.52 > 2019.05.02.00.34.06 kamil src/tests/lib/libc/sys/t_ptrace_wait.c,v 1.119 > > Log files can be found at: > > > http://releng.NetBSD.org/b5reports/i386/commits-2019.05.html#2019.05.02.00.34.06 > signature.asc Description: OpenPGP digital signature
Re: Automated report: NetBSD-current/i386 test failure
On 02.05.2019 01:54, NetBSD Test Fixture wrote: > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > usr.bin/gdb/t_regress:pie > Addressed in sys_ptrace_common.c 1.5 It looks like a bug in GDB, but for now I will keep it as it is and revisit later. > The above test failed in each of the last 3 test runs, and passed in > at least 27 consecutive runs before that. > > The following commits were made between the last successful test and > the failed test: > > 2019.04.30.20.50.30 kamil src/sys/kern/sys_ptrace_common.c,v 1.49 > 2019.04.30.20.55.41 kre src/sys/net/if_dl.h,v 1.28 > 2019.04.30.20.56.32 kre src/sys/net/dl_print.c,v 1.6 > > Log files can be found at: > > > http://releng.NetBSD.org/b5reports/i386/commits-2019.04.html#2019.04.30.20.56.32 > signature.asc Description: OpenPGP digital signature
Re: Automated report: NetBSD-current/i386 test failure
Date:Tue, 30 Apr 2019 21:58:19 + (UTC) From:NetBSD Test Fixture Message-ID: <155666149938.7910.2797000443449332...@babylon5.netbsd.org> | The newly failing test cases are: | | sys/net/t_print:dl_print | sys/net/t_print:sdl_print These should be fixed now. kre
Re: Automated report: NetBSD-current/i386 test failure
Date:Mon, 29 Apr 2019 12:02:10 +0300 From:Valery Ushakov Message-ID: <20190429090210.gd11...@pony.stderr.spb.ru> | E.g. in sys/arch/sh3/include/adcreg.h Yes, I noticed many uses in arch/* ... I sampled a bunch of them, and was mostly finding "old" style uses... So thanks for that, and good that it is correct! | PS: The way the one in sys/mman.h is formatted is a crime against | humanity :) No disagreement ... feel free to fix! kre
Re: Automated report: NetBSD-current/i386 test failure
On Mon, Apr 29, 2019 at 10:29:43 +0700, Robert Elz wrote: > I've done some searching (not exhaustive for sure) and the only > thing I can find that uses 'F' in our tree that I can find is > (which provided the newly added example in snprintb.3) > which is missing that final NUL after the F field - and which I > suspect is the motivation for the "off by one" fix. I rememeber writing some. E.g. in sys/arch/sh3/include/adcreg.h #define SH7709_ADCR_BITS \ "\177\020" "F\06\02\0" ":\03TRGE\0" "b\05SCAN\0" PS: The way the one in sys/mman.h is formatted is a crime against humanity :) -uwe
Re: Automated report: NetBSD-current/i386 test failure
Thanks! christos > On Apr 28, 2019, at 10:33 PM, Robert Elz wrote: > >Date:Mon, 29 Apr 2019 08:58:43 +0700 >From:Robert Elz >Message-ID: <17972.1556503...@jinx.noi.kre.to> > > | I know what is happening with that, and I will fix... > | > | The problem relates to a difference of opinion/misunderstanding > | of the 'F' (new style) format operator > | > | The man page says... > | > | Describes a multi-bit field like `f', but just extracts the value > | > | and when we look at 'f', what it says is ... > | > |Describes a multi-bit field [] > |The remaining characters are printed ... > | > | If F is just like f then it needs "remaining characters" even though > | the F format doesn't use them. > > Upon reflection, I'm inclined to instead leave the fixed code the > way it is, and change the ATF tests to use it that way (omitting the > noise bytes after F format that it currently supplies for this purpose). > > kre
Re: Automated report: NetBSD-current/i386 test failure
Date:Mon, 29 Apr 2019 09:33:59 +0700 From:Robert Elz Message-ID: <22739.1556505...@jinx.noi.kre.to> | Upon reflection, I'm inclined to instead [...] And upon further reflection, and noticing this sentence in the snprintb() man page (snprintb.3) Finally, each field is delimited by a NUL (`\0') character. which should include the F field - for consistency if nothing else, even though for that one there is nothing to delimit. I've done some searching (not exhaustive for sure) and the only thing I can find that uses 'F' in our tree that I can find is (which provided the newly added example in snprintb.3) which is missing that final NUL after the F field - and which I suspect is the motivation for the "off by one" fix. So, I'm going back to my original plan, except that snprintb.3 doesn't need as much fixing as I thought it might, but needs an update. Further, the test that caught this is dumb, and has data between the F field data and the terminating \0 (which the code conveniently ignores) but which really should not be there - it would inhibit perhaps extending the F format with more data if that were ever useful. kre
Re: Automated report: NetBSD-current/i386 test failure
Date:Mon, 29 Apr 2019 08:58:43 +0700 From:Robert Elz Message-ID: <17972.1556503...@jinx.noi.kre.to> | I know what is happening with that, and I will fix... | | The problem relates to a difference of opinion/misunderstanding | of the 'F' (new style) format operator | | The man page says... | | Describes a multi-bit field like `f', but just extracts the value | | and when we look at 'f', what it says is ... | | Describes a multi-bit field [] | The remaining characters are printed ... | | If F is just like f then it needs "remaining characters" even though | the F format doesn't use them. Upon reflection, I'm inclined to instead leave the fixed code the way it is, and change the ATF tests to use it that way (omitting the noise bytes after F format that it currently supplies for this purpose). kre
Re: Automated report: NetBSD-current/i386 test failure
Date:Sun, 28 Apr 2019 21:50:45 + (UTC) From:NetBSD Test Fixture Message-ID: <155648824563.27186.9065778287415893...@babylon5.netbsd.org> | The newly failing test case is: | | lib/libutil/t_snprintb:snprintb I know what is happening with that, and I will fix... The problem relates to a difference of opinion/misunderstanding of the 'F' (new style) format operator The man page says... Describes a multi-bit field like `f', but just extracts the value and when we look at 'f', what it says is ... Describes a multi-bit field [] The remaining characters are printed ... If F is just like f then it needs "remaining characters" even though the F format doesn't use them. That's the cause of the apparent "off by one" which seemed to be causing the first : or = to be ignored ... it was being ignored because it was being treated as those unused "remaining characters". Since I doubt the objective right now is to alter how F format has worked for a long time (eg: in the tests) I will restore the "off by one" after which it all magically works again. I will also change the new doc to indicate explicitly that these remaining characters must be given (just the terminating \0 works). Then I'll add some ATF tests for the new stuff. kre
Re: Automated report: NetBSD-current/i386 test failure
Fixed, thanks! christos > On Apr 7, 2019, at 8:32 AM, Rin Okuyama wrote: > > On 2019/04/07 1:00, Andreas Gustafsson wrote: >> Christos Zoulas wrote: >>> Must be, but I can't reproduce it, can you run gdb on the core file? >> No need to go hunting or a core, simply running "date" with no >> arguments will reproduce it. Doing that under gdb shows: >> (gdb) where >> #0 0xac643b67 in ?? () from /lib/libc.so.12 >> #1 0xac644496 in strftime_lz () from /lib/libc.so.12 >> #2 0xac6444f2 in strftime_z () from /lib/libc.so.12 >> #3 0xac64454b in strftime () from /lib/libc.so.12 >> #4 0x00846af8 in main () >> I'll get you a backtrace with debug symbols later. > > Hi, > > Segmentation fault occurs depending on /etc/localtime: > > % sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime > % date > Sun Apr 7 21:19:05 JST 2019 > % sudo ln -sf /usr/share/zoneinfo/UTC /etc/localtime > % date > zsh: segmentation fault (core dumped) date > > Also, it does not take place if strftime.c,v 1.43 is reverted > (regardless of whether v 1.44 is applied or not). > > Backtrace is attached below. > > Thanks, > rin > --- > % gdb date date.core > GNU gdb (GDB) 8.0.1 > ... > [New process 1] > Core was generated by `date'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x6fe6496ba120 in _add (ptlim=0x6fe64a0d1400 "", >pt=0x6fe64a0d1015 '\245' ..., >str=0x1 ) >at /build/src/lib/libc/time/strftime.c:740 > 740 /build/src/lib/libc/time/strftime.c: No such file or directory. > (gdb) bt > #0 0x6fe6496ba120 in _add (ptlim=0x6fe64a0d1400 "", >pt=0x6fe64a0d1015 '\245' ..., >str=0x1 ) >at /build/src/lib/libc/time/strftime.c:740 > #1 _fmt (sp=, format=0x1a2c0276f "Z %Y", >format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y", >t=t@entry=0x6fe649a0f460, pt=0x6fe64a0d1015 '\245' ..., >pt@entry=0x6fe64a0d1000 "+Sun Apr 7 12:19:13 ", '\245' times>..., ptlim=ptlim@entry=0x6fe64a0d1400 "", > warnp=warnp@entry=0x7f7fff48f4cc, >loc=) at /build/src/lib/libc/time/strftime.c:548 > #2 0x6fe6496baa1a in _strftime_lz (sp=, >s=s@entry=0x6fe64a0d1000 "+Sun Apr 7 12:19:13 ", '\245' times>..., maxsize=maxsize@entry=1024, >format=format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y", >t=t@entry=0x6fe649a0f460, loc=) >at /build/src/lib/libc/time/strftime.c:152 > #3 0x6fe6496baa41 in _strftime_z (sp=, >s=s@entry=0x6fe64a0d1000 "+Sun Apr 7 12:19:13 ", '\245' times>..., maxsize=maxsize@entry=1024, >format=format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y", >t=t@entry=0x6fe649a0f460) at /build/src/lib/libc/time/strftime.c:132 > #4 0x6fe6496baa84 in strftime ( >s=0x6fe64a0d1000 "+Sun Apr 7 12:19:13 ", '\245' ..., >maxsize=1024, format=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y", >t=0x6fe649a0f460) at /build/src/lib/libc/time/strftime.c:708 > #5 0x0001a2c020a5 in main (argc=, argv=) >at /build/src/bin/date/date.c:157 > (gdb) q > %
Re: Automated report: NetBSD-current/i386 test failure
On 2019/04/07 1:00, Andreas Gustafsson wrote: Christos Zoulas wrote: Must be, but I can't reproduce it, can you run gdb on the core file? No need to go hunting or a core, simply running "date" with no arguments will reproduce it. Doing that under gdb shows: (gdb) where #0 0xac643b67 in ?? () from /lib/libc.so.12 #1 0xac644496 in strftime_lz () from /lib/libc.so.12 #2 0xac6444f2 in strftime_z () from /lib/libc.so.12 #3 0xac64454b in strftime () from /lib/libc.so.12 #4 0x00846af8 in main () I'll get you a backtrace with debug symbols later. Hi, Segmentation fault occurs depending on /etc/localtime: % sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime % date Sun Apr 7 21:19:05 JST 2019 % sudo ln -sf /usr/share/zoneinfo/UTC /etc/localtime % date zsh: segmentation fault (core dumped) date Also, it does not take place if strftime.c,v 1.43 is reverted (regardless of whether v 1.44 is applied or not). Backtrace is attached below. Thanks, rin --- % gdb date date.core GNU gdb (GDB) 8.0.1 ... [New process 1] Core was generated by `date'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x6fe6496ba120 in _add (ptlim=0x6fe64a0d1400 "", pt=0x6fe64a0d1015 '\245' ..., str=0x1 ) at /build/src/lib/libc/time/strftime.c:740 740 /build/src/lib/libc/time/strftime.c: No such file or directory. (gdb) bt #0 0x6fe6496ba120 in _add (ptlim=0x6fe64a0d1400 "", pt=0x6fe64a0d1015 '\245' ..., str=0x1 ) at /build/src/lib/libc/time/strftime.c:740 #1 _fmt (sp=, format=0x1a2c0276f "Z %Y", format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y", t=t@entry=0x6fe649a0f460, pt=0x6fe64a0d1015 '\245' ..., pt@entry=0x6fe64a0d1000 "+Sun Apr 7 12:19:13 ", '\245' ..., ptlim=ptlim@entry=0x6fe64a0d1400 "", warnp=warnp@entry=0x7f7fff48f4cc, loc=) at /build/src/lib/libc/time/strftime.c:548 #2 0x6fe6496baa1a in _strftime_lz (sp=, s=s@entry=0x6fe64a0d1000 "+Sun Apr 7 12:19:13 ", '\245' ..., maxsize=maxsize@entry=1024, format=format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y", t=t@entry=0x6fe649a0f460, loc=) at /build/src/lib/libc/time/strftime.c:152 #3 0x6fe6496baa41 in _strftime_z (sp=, s=s@entry=0x6fe64a0d1000 "+Sun Apr 7 12:19:13 ", '\245' ..., maxsize=maxsize@entry=1024, format=format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y", t=t@entry=0x6fe649a0f460) at /build/src/lib/libc/time/strftime.c:132 #4 0x6fe6496baa84 in strftime ( s=0x6fe64a0d1000 "+Sun Apr 7 12:19:13 ", '\245' ..., maxsize=1024, format=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y", t=0x6fe649a0f460) at /build/src/lib/libc/time/strftime.c:708 #5 0x0001a2c020a5 in main (argc=, argv=) at /build/src/bin/date/date.c:157 (gdb) q %
Re: Automated report: NetBSD-current/i386 test failure
Christos Zoulas wrote: > Must be, but I can't reproduce it, can you run gdb on the core file? No need to go hunting or a core, simply running "date" with no arguments will reproduce it. Doing that under gdb shows: (gdb) where #0 0xac643b67 in ?? () from /lib/libc.so.12 #1 0xac644496 in strftime_lz () from /lib/libc.so.12 #2 0xac6444f2 in strftime_z () from /lib/libc.so.12 #3 0xac64454b in strftime () from /lib/libc.so.12 #4 0x00846af8 in main () I'll get you a backtrace with debug symbols later. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
Must be, but I can't reproduce it, can you run gdb on the core file? christos > On Apr 6, 2019, at 3:52 AM, Andreas Gustafsson wrote: > > NetBSD Test Fixture wrote: >> This is an automatically generated notice of new failures of the >> NetBSD test suite. >> >> The newly failing test cases are: >> >>atf/tools/atf-run_test:broken_results > [...] > > Looking at the log for the first failing test, "date" is dumping core: > > > http://releng.netbsd.org/b5reports/i386/2019/2019.04.05.07.29.24/test.html#atf_tools_atf-run_test_broken_results > > Maybe it's the libc/time changes, but I can't easily verify that > because they were committed while the build was broken. > -- > Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > atf/tools/atf-run_test:broken_results [...] Looking at the log for the first failing test, "date" is dumping core: http://releng.netbsd.org/b5reports/i386/2019/2019.04.05.07.29.24/test.html#atf_tools_atf-run_test_broken_results Maybe it's the libc/time changes, but I can't easily verify that because they were committed while the build was broken. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
In article <23645.7935.238592.235...@guava.gson.org>, Andreas Gustafsson wrote: >The NetBSD Test Fixture wrote: >> The newly failing test cases are: >> >> dev/raidframe/t_raid:raid1_comp0fail >> dev/raidframe/t_raid:raid1_compfail >> dev/raidframe/t_raid:raid1_normal >> dev/raidframe/t_raid:raid5_compfail >> dev/raidframe/t_raid:raid5_normal > >This was a duplicate report, sorry about that. These test failures >have alrady been fixed. I was really scratching my head there, thanks... christos
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > The newly failing test cases are: > > dev/raidframe/t_raid:raid1_comp0fail > dev/raidframe/t_raid:raid1_compfail > dev/raidframe/t_raid:raid1_normal > dev/raidframe/t_raid:raid5_compfail > dev/raidframe/t_raid:raid5_normal This was a duplicate report, sorry about that. These test failures have alrady been fixed. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > The newly failing test cases are: > > lib/libc/sys/t_ptrace_wait3:dbregs_dr0_dont_inherit_execve > lib/libc/sys/t_ptrace_wait3:dbregs_dr0_dont_inherit_lwp (etc, more than 300 failing test cases) These are also failing on real i386 hardware, but not on amd64. Looks like the problem started with these commits: >2019.01.13.10.01.07 maxv src/sys/arch/x86/include/dbregs.h,v 1.8 >2019.01.13.10.01.07 maxv src/sys/arch/x86/x86/dbregs.c,v 1.13 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > > usr.bin/c++/t_asan_poison:poison > usr.bin/c++/t_asan_poison:poison_pic > usr.bin/cc/t_asan_poison:poison > usr.bin/cc/t_asan_poison:poison_pic At first glance this looked like a duplicate report, but I now think what actually happened was that these four test cases were fixed and then quickly broken again, and the second report incorrectly identified the commits leading to the first failure rather than the second, because when a test passes just a few times and then fails again, it's hard to tell if it's because it was fixed and re-broken or just unreliable. The correct set of commits for the second failure is: 2018.12.28.19.54.36 thorpej src/tests/rump/kernspace/kernspace.h 1.8 2018.12.28.19.54.36 thorpej src/tests/rump/kernspace/threadpool.c 1.4 2018.12.28.19.54.36 thorpej src/tests/rump/rumpkern/t_threadpool.c 1.2 2018.12.28.20.12.35 christos src/lib/csu/common/crt0-common.c 1.23 2018.12.28.20.43.25 christos src/external/gpl3/binutils/dist/ld/configure.tgt 1.31 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > sbin/gpt/t_gpt:migrate_disklabel This was a false alarm - sorry about that. Looks like the testbed used some idle time to fill in a gap in the test history from November, and accidentally rediscovered a test failure that had already been fixed. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
Michael van Elst wrote: > I have reverted that part of the commit that introduced that change. > Lets find out if that makes the test succeed in the testbed again (it > always succeeded here on real hardware). Then fix the test. Reverting did make the lib/libc/sys/t_sendmmsg/sendmmsg_basic test succeed on the i386 testbed again. FWIW, it was also failing on real hardware for me: http://www.gson.org/netbsd/bugs/build/i386-baremetal/commits-2018.11.html#2018.11.28.19.46.22 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
On Fri, Nov 30, 2018 at 03:43:23PM +0100, Martin Husemann wrote: > This test has hung for me (untill atf timeout) on some machines (e.g. > single core arm) since several weeks, I think the test code is buggy. While the test is buggy, the bug was triggered by the changed scheduler behaviour. I have reverted that part of the commit that introduced that change. Lets find out if that makes the test succeed in the testbed again (it always succeeded here on real hardware). Then fix the test. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Automated report: NetBSD-current/i386 test failure
On Fri, Nov 30, 2018 at 03:16:00PM +0200, Andreas Gustafsson wrote: > The NetBSD Test Fixture wrote: > > This is an automatically generated notice of a new failure of the > > NetBSD test suite. > > > > The newly failing test case is: > > > > lib/libc/sys/t_sendmmsg:sendmmsg_basic This test has hung for me (untill atf timeout) on some machines (e.g. single core arm) since several weeks, I think the test code is buggy. Martin
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > This is an automatically generated notice of a new failure of the > NetBSD test suite. > > The newly failing test case is: > > lib/libc/sys/t_sendmmsg:sendmmsg_basic Sorry about the duplicate reports about this, that was an error on my part which should now be fixed. But on the bright side, the last duplicate had the problem narrowed down to a single commit: > 2018.11.28.19.46.22 mlelstv src/sys/kern/kern_synch.c,v 1.321 > 2018.11.28.19.46.22 mlelstv src/sys/sys/lwp.h,v 1.180 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 test failure
Date:Mon, 19 Nov 2018 01:07:17 + (UTC) From:NetBSD Test Fixture Message-ID: <154258963726.7846.5173440576646830...@babylon5.netbsd.org> | The newly failing test case is: | bin/sh/t_patterns:case_matching This is expected - the failures are from newly added subtests that test a (rare and unusual) bug - the fix is already committed. kre
Re: Automated report: NetBSD-current/i386 test failure
Robert Elz wrote: > | The newly failing test case is: > | > | sbin/gpt/t_gpt:migrate_disklabel [...] > That leaves mrg's gcc changes, and if gcc has started generating bad code for > (the fairly simple source that is) fdisk (or for dd, which makes a filesys > image via a copy from /dev/zero), then I wonder how the system even > gets close to running, that would be truly bizarre. Bizarre or not, comparing the generated code of validate_bootsel() in fdisk.c between a working and a failing version, it's gone from 235 to 178 bytes in size. It's a bit hard to follow, but it looks like the whole "Check the menu strings are printable" loop has been optimized away and effectively turned into "return 3". The expression mbs->mbrbs_nametab[0][i] is accessing the second row of a two-dimensional array by overstepping the first. I suspect gcc may be considering this to have undefined behavior and taking that as license to optimize the whole thing away. Anyway, this discussion should be moved into a PR. -- Andreas Gustafsson, g...@gson.org
