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
.06.41
I'm guessing it started with this commit:
2022.02.23.17.28.31 mrg
src/external/mit/xorg/server/drivers/xf86-video-ati/Makefile 1.7
--
Andreas Gustafsson, g...@gson.org
.02.16.23.30.10
--
Andreas Gustafsson, g...@gson.org
ild a historic version from the affected time range.
This is also going to be an ongoing pitfall for anyone building
historic versions, for example when bisecting.
--
Andreas Gustafsson, g...@gson.org
he
testbed, you can expect a reduced level of automated testing service.
Also, you may want to be on the lookout for this failure mode in your
own builds (or the cleanup after them).
--
Andreas Gustafsson, g...@gson.org
/build.log.tail
--
Andreas Gustafsson, g...@gson.org
2032
Logs:
http://releng.NetBSD.org/b5reports/i386/commits-2021.11.html#2021.11.25.03.08.05
The sparc port is also broken; it installs but panics when booting the installed
system.
--
Andreas Gustafsson, g...@gson.org
mpvnode_if.c,v
1.37
2021.10.20.03.13.14 thorpej src/sys/sys/vnode_if.h,v 1.108
Logs can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2021.10.html#2021.10.20.03.26.20
--
Andreas Gustafsson, g...@gson.org
: stopped in /tmp/build/2021.09.25.21.26.04-i386/src
> ERROR: Failed to make release
since this commit:
> 2021.09.25.21.26.03 maya
> src/distrib/common/bootimage/Makefile.installimage,v 1.10
> 2021.09.25.21.26.03 maya src/distrib/sets/sets.subr,v 1.197
> 2021.09.25.
.22.29.11/build.log.tail
--
Andreas Gustafsson, g...@gson.org
-users/2021/07/24/msg041311.html
--
Andreas Gustafsson, g...@gson.org
bed but still need to deploy it on babylon5.
--
Andreas Gustafsson, g...@gson.org
kernel/t_umountstress (98/899): 2 test cases
fileop:
The latest test run on b5 has hung but not timed out yet; when it
does, the log will appear here:
http://releng.netbsd.org/b5reports/i386/commits-2021.07.html#2021.07.01.04.25.51
--
Andreas Gustafsson, g...@gson.org
Martin Husemann wrote:
> All regressions I am aware of have been fixed now.
At least i386 still hangs while running the ATF tests as of source
date 2021.07.01.04.25.51.
--
Andreas Gustafsson, g...@gson.org
[ 148.2200843] syscall() at netbsd:syscall+0x17c
[ 148.2395535] --- syscall (number 6) ---
[ 148.2395535] b405b597:
[ 148.2395535] cpu0: End traceback...
Logs:
http://releng.netbsd.org/b5reports/i386/commits-2021.06.html#2021.06.13.00.11.17
amd64 is also affected.
--
Andreas Gustafsson, g...@netbsd.org
all ports.
Logs:
http://releng.netbsd.org/b5reports/i386/commits-2021.05.html#2021.05.27.08.41.35
--
Andreas Gustafsson, g...@gson.org
to anoncvs from Finland frequently
break in the middle of a transfer, though I'm using rsync rather than
cvs. I have an admins@ ticket open about this since a couple of years
ago (#160795).
--
Andreas Gustafsson, g...@gson.org
n of integer expressions of different signedness: 'long int'
and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
239 | if (n < h)
| ^
--
Andreas Gustafsson, g...@gson.org
/commits-2021.01.html#2021.01.16.23.51.51
--
Andreas Gustafsson, g...@gson.org
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
org/b5reports/i386/commits-2020.12.html#2020.12.07.08.31.07
--
Andreas Gustafsson, g...@gson.org
/usr.bin/make/unit-tests/opt-keep-going-multiple.mk
= end of 2 extra files ===
Logs:
http://releng.netbsd.org/b5reports/i386/commits-2020.12.html#2020.12.07.01.32.04
--
Andreas Gustafsson, g...@gson.org
mcneill src/sys/dev/acpi/spic_acpi.c,v 1.7
> 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/wb_acpi.c,v 1.6
--
Andreas Gustafsson, g...@gson.org
ate ?
--
./usr/bin/gdbserver
= end of 1 extra files ===
--
Andreas Gustafsson, g...@gson.org
/unit-tests/objdir-writable.mk
= end of 2 extra files ===
Logs at:
http://releng.netbsd.org/b5reports/i386/commits-2020.11.html#2020.11.13.09.56.53
--
Andreas Gustafsson, g...@gson.org
The build is still failing, but now with a different error:
nbmake[5]: "/tmp/build/2020.11.13.08.33.07-i386/src/external/ofl/Makefile"
line 3: Malformed conditional (${MKX11} != "no")
--
Andreas Gustafsson, g...@gson.org
.48 nia
src/external/public-domain/sqlite/lib/sqlite3.pc.in,v 1.3
2020.11.08.21.56.48 nia src/usr.sbin/makemandb/Makefile,v 1.10
--
Andreas Gustafsson, g...@gson.org
se 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
nia wrote:
> It should be fixed already.
It's not, it's now failing earlier in the build:
http://releng.netbsd.org/b5reports/i386/commits-2020.10.html#2020.10.29.16.35.33
--
Andreas Gustafsson, g...@gson.org
> > | Should be fixed.
> > Is fixed, thanks.
> Thanks for the fixes.
The wgetch test case is still failing:
http://releng.netbsd.org/b5reports/i386/2020/2020.10.28.03.21.25/test.html#lib_libcurses_t_curses_wgetch
--
Andreas Gustafsson, g...@gson.org
[Manually forwarded as the automated notifications are temporarily
disabled while new hardware is being tested]
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
lib/libcurses/t_curses:addch
[Manually forwarded as the automated notifications are temporarily
disabled while new hardware is being tested]
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date
075220720bf7e 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
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
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#2
11.07.27
They are still failing as of source date 2020.10.13.21.27.18.
--
Andreas Gustafsson, g...@gson.org
1.34
2020.10.03.18.54.18 martin src/usr.sbin/sysinst/part_edit.c 1.18
2020.10.03.18.54.18 martin src/usr.sbin/sysinst/partitions.h 1.17
2020.10.03.20.34.06 rillig src/distrib/sets/lists/tests/mi 1.937
--
Andreas Gustafsson, g...@gson.org
is the best clue to look for since it will
> always be present.
It is not present in this recent log extract:
http://releng.netbsd.org/b5reports/i386/2020/2020.09.27.13.59.24/build.log.tail
I also checked the full log, and it's not there, either.
--
Andreas Gustafsson, g...@gson.org
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
a -current built from source date 2020.08.16.00.24.41,
running on real amd64 hardware.
--
Andreas Gustafsson, g...@gson.org
it would generally be
better to revert the commit immediately and later re-commit a correct
version rather than leaving things broken during the entire process of
reproducing and fixing the issue.
--
Andreas Gustafsson, g...@gson.org
/commits-2020.08.html#2020.08.14.09.06.15
Please revert the commit.
--
Andreas Gustafsson, g...@gson.org
ut the builds
and the sparc tests still use as much CPU as before. So the overall
throughput of the server has increased, but by a smaller factor than
the latency of the i386 and amd64 tests.
--
Andreas Gustafsson, g...@gson.org
f PR 43997, but now fail to detect that they
are running under qemu).
--
Andreas Gustafsson, g...@gson.org
1.04.05-i386/tools/bin/i486--netbsdelf-ld:
trap.o: in function `trap':
trap.c:(.text+0xe27): undefined reference to `x86_cpu_is_lcall'
--
Andreas Gustafsson, g...@gson.org
/chacha
= end of 1 extra files ===
--
Andreas Gustafsson, g...@gson.org
The build is still broken as of source date 2020.07.19.16.22.44:
http://releng.netbsd.org/b5reports/i386/commits-2020.07.html#2020.07.19.16.22.44
--
Andreas Gustafsson, g...@gson.org
on one, the dmesg output contains no "com" entry.
--
Andreas Gustafsson, g...@gson.org
Running the usb host in polled mode however is quite a bit simpler than
> doing the device part (where you have to obey timings from the host).
Why would acting as a device be needed?
--
Andreas Gustafsson, g...@gson.org
ent biggest stack usages
there are about six functions which use over 3KiB local stack, and
about a dozen between 2-3 KiB, so pushing this further needs more work
if desired
compile tested on amd64, i386, sparc64, sparc, powerpc (evbppc - BookE),
m68k (mac68k)
--
Andreas Gustafsson, g...@gson.org
o
That would be counter to my principle of testing with default settings.
--
Andreas Gustafsson, g...@gson.org
both human and robotic users if error messages
consistently included the word "error", or if there was some other easy
way of identifying them in the build log.
--
Andreas Gustafsson, g...@gson.org
make, we want to die quietly.
Also when we read an abort token we call dieQuietly telling we
want to die quietly.
This behavior is suppressed by -dj or
setting .MAKE.DIE_QUIETLY=no
Reviewed by: christos
--
Andreas Gustafsson, g...@gson.org
e 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
--
m...@netbsd.org wrote:
> Yes, I believe joerg and spz are changing the conversion from
> cvs->??->git to hg->git, to match what will be done once we stop using
> CVS.
Has there been a formal decision choosing hg over git?
--
Andreas Gustafsson, g...@gson.org
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
ports 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
9577.58 user 9602.81 sys
> > 2020.03.22.19.56.072363.06 real 9482.36 user 7614.66 sys
One more with the same settings:
2020.04.09.11.10.072210.82 real 9435.36 user 4388.02 sys
That's a great reduction in system time in the last few weeks.
--
Andreas Gustafsson, g...@gson.org
ts.
Can you please file a PR (about the messages being printed and
confusing people for a decade now, not about the tests being broken)?
--
Andreas Gustafsson, g...@gson.org
.html#failed-tcs-summary
--
Andreas Gustafsson, g...@gson.org
ou're so inclined.
Is this just "lockstat build.sh ...", or are there some specific lockstat
options I should use?
PS. I would prefer that you prioritize fixing the fallout from the
changes you have already made so far over making further changes.
--
Andreas Gustafsson, g...@gson.org
involving machmode.h:
http://releng.netbsd.org/b5reports/i386/2019/2019.11.26.08.38.19/build.log.tail
http://releng.netbsd.org/b5reports/i386/2020/2020.03.15.15.58.24/build.log.tail
Someone please fix.
--
Andreas Gustafsson, g...@gson.org
.65 real 10309.00 user 11618.57 sys
2020.03.17.22.03.412419.52 real 9577.58 user 9602.81 sys
2020.03.22.19.56.072363.06 real 9482.36 user 7614.66 sys
--
Andreas Gustafsson, g...@gson.org
run the 24-core tests with these disabled for comparison.
--
Andreas Gustafsson, g...@gson.org
--
Andreas Gustafsson, g...@gson.org
or=imp\
licit-function-declaration]
if (sig == SIGFPE && !are_fpu_exceptions_supported())
^~~~
are_fpu_exceptions_supporter
--
Andreas Gustafsson, g...@gson.org
t 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
6/commits-2020.03.html#2020.03.03.08.56.05
Would it be too much to ask that imports of entire new subsystems like
this be at least build tested with "build.sh release"?
--
Andreas Gustafsson, g...@gson.org
our responsibility,
and if so, whose?
--
Andreas Gustafsson, g...@gson.org
processes around
55020 dbregs_dr?_dont_inherit_lwp test cases fail on real hardware
55032 rump/rumpkern/t_vm:uvmwait test case now fails
What can be done?
--
Andreas Gustafsson, g...@gson.org
.c:1171:16:
error: comparison of integer expressions of different signedness: 'int32_t'
{aka 'int'} and 'unsigned int' [-Werror=sign-compare]
for (i = 0; i < sizeof(data); i++)
^
--
Andreas Gustafsson, g...@gson.org
ttp://releng.netbsd.org/b5reports/i386/commits-2020.02.html#2020.02.27.03.25.08
--
Andreas Gustafsson, g...@gson.org
ype 'void *' used in arithmetic [-Werror=pointer-arith]
buf->address = (void *)(dmah->vaddr + offset);
^
--
Andreas Gustafsson, g...@gson.org
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
cceeding 27 times is not all that unlikely.
--
Andreas Gustafsson, g...@gson.org
for each function it
appears in
*** [core_elf32.o] Error code 1
--
Andreas Gustafsson, g...@gson.org
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
nd traceback...
This is from:
http://www.gson.org/netbsd/bugs/build/i386-linuxhost/2019/2019.12.15.23.13.33/test.log
There's also:
http://releng.netbsd.org/b5reports/i386/2019/2019.12.15.22.50.51/install.log
http://releng.netbsd.org/b5reports/sparc64/2019/2019.12.16.00.03.50/install.log
first run after the bug was introduced, which would mean these
commits are innocent.
--
Andreas Gustafsson, g...@gson.org
1.6
2019.12.12.22.55.20 pgoyette src/sys/sys/param.h 1.624
For logs, see:
http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2019.12.html#2019.12.12.22.55.20
--
Andreas Gustafsson, g...@gson.org
();
^
sysctl_create
cc1: all warnings being treated as errors
*** [kern_module.o] Error code 1
and the sparc build is also failing with a similar error.
--
Andreas Gustafsson, g...@gson.org
.55.58
Could everyone please refrain from committing new kernel-crashing bugs
until the test infrastructure has recovered from the previous round?
--
Andreas Gustafsson, g...@netbsd.org
19.12.05.03.21.17 riastradh src/sys/kern/subr_pserialize.c 1.16
2019.12.05.03.21.29 riastradh src/sys/kern/subr_pserialize.c 1.17
2019.12.05.03.21.42 riastradh src/external/cddl/osnet/sys/sys/opentypes.h 1.5
--
Andreas Gustafsson, g...@netbsd.org
processors may or may
not be a coincidence.
Please help find and fix the offending commit(s); until that is done,
there can be very little automated testing of new commits.
--
Andreas Gustafsson, g...@gson.org
en it is turned off, and about 14 minutes when it is turned
> on. Just a thought.)
FWIW, these tests were run with hyperthreading disabled.
--
Andreas Gustafsson, g...@gson.org
th lockstat?
I'd rather leave that to someone else, and to a separate thread. All
the test results presented in this thread were produced with the same
options so that they can be meaningfully compared, and running new
tests with different options would only confuse things.
--
Andreas Gustafsson, g...@gson.org
Jaromír Doleček wrote:
> I wonder also if we could try enabling vm.ubc_direct on the build machine?
Using 2019.11.14.13.58.22 sources:
with default settings:
4612.56 real 16896.10 user 9325.87 sys
with vm.ubc_direct = 1:
4615.95 real 16819.96 user 9416.13 sys
--
Andr
Mateusz Guzik wrote:
> Can you get a kernel-side flamegraph?
Done, using sources from 2019.11.14.13.58.22:
http://www.gson.org/netbsd/bugs/system-time/fg.svg
--
Andreas Gustafsson, g...@gson.org
Michael van Elst wrote:
> g...@gson.org (Andreas Gustafsson) writes:
>
> >mitigations, which I guess is not really surprising. But the 12% net
> >increase from jemalloc and the 7% increase from vfs_vnode.c 1.63 seem
> >to call for closer investigation.
>
> Is th
vfs_vnode.c 1.63 seem
to call for closer investigation.
--
Andreas Gustafsson, g...@gson.org
Patrick Welche wrote:
> I have been running with vm.ubc_direct=1 and feeling a speedup and no
> inconveniences on multicore systems. What are thoughts on having it as
> a default?
No such option is documented, hence the question makes no sense.
--
Andreas Gustafsson, g...@gson.org
PR 53561.
--
Andreas Gustafsson, g...@gson.org
:
commit 2019.11.01.13.04.22 rin src/sys/uvm/uvm_map.c 1.366
--
Andreas Gustafsson, g...@gson.org
and the fix was 1.182.
As for the increased system time taken by release builds, it has
happened in multiple steps. I have bisected the largest increases,
but analyzing and writing up the results for current-users is still
on my "to do" list.
--
Andreas Gustafsson, g...@gson.org
christos src/sys/dev/pci/satalink.c 1.57
--
Andreas Gustafsson, g...@gson.org
and bisect the other bug.
--
Andreas Gustafsson, g...@gson.org
/build_8.log: 4488.49 real 16670.79 user
9279.25 sys
Does anyone happen to know which commits caused and/or fixed this?
This information could save me a couple of days of bisection run time.
--
Andreas Gustafsson, g...@gson.org
ebug/lib/libzpool.so.0.0.debug
= end of 8 extra files ===
*** [checkflist] Error code 1
--
Andreas Gustafsson, g...@gson.org
./usr/share/man/man8/mount_zfs.8
end of 2 missing files ==
--
Andreas Gustafsson, g...@gson.org
in an 'else' statement
[-Werror=empty-body]
icp, slot_id, 0, 0);
--
Andreas Gustafsson, g...@gson.org
1 - 100 of 272 matches
Mail list logo
