daily CVS update output
Updating src tree: P src/bin/ksh/Makefile P src/crypto/external/bsd/netpgp/bin/netpgpverify/Makefile P src/crypto/external/bsd/netpgp/lib/verify/Makefile P src/crypto/external/bsd/openssh/bin/sftp/Makefile P src/distrib/utils/zcat/Makefile P src/external/bsd/atf/lib/tools/Makefile P src/external/bsd/flex/bin/Makefile P src/external/bsd/ipf/bin/ipf/Makefile P src/external/bsd/ipf/bin/ipftest/Makefile P src/external/bsd/libpcap/lib/Makefile P src/external/bsd/ntp/Makefile.inc P src/external/bsd/pdisk/bin/Makefile P src/external/bsd/pkg_install/Makefile.inc P src/games/backgammon/common_source/Makefile P src/games/hunt/huntd/Makefile P src/lib/libbz2/Makefile P src/lib/libnpf/libnpf.3 P src/lib/libnpf/npf.c P src/lib/libnpf/npf.h P src/lib/libz/Makefile P src/share/mk/bsd.own.mk P src/sys/arch/aarch64/aarch64/locore.S P src/sys/arch/arm/arm32/cpu.c P src/sys/conf/copts.mk P src/sys/dev/i2c/ds1307.c P src/sys/dev/ic/ahcisata_core.c P src/sys/dev/ic/ahcisatavar.h P src/sys/external/bsd/drm2/i915drm/files.i915drmkms P src/sys/external/bsd/drm2/nouveau/files.nouveau P src/sys/external/bsd/drm2/radeon/files.radeon P src/sys/external/bsd/drm2/ttm/files.ttm P src/sys/external/isc/atheros_hal/conf/files.ath_hal P src/sys/kern/kern_rndq.c P src/sys/lib/libkern/Makefile.compiler-rt P src/sys/modules/ath_hal/Makefile P src/sys/modules/i915drmkms/Makefile P src/sys/modules/pf/Makefile P src/sys/modules/radeondrm/Makefile P src/sys/modules/savagedrm/Makefile P src/sys/modules/viadrmums/Makefile P src/sys/modules/zlib/Makefile P src/sys/net/npf/npf_conn.c P src/sys/net/npf/npf_ctl.c P src/sys/net/npf/npf_if.c P src/sys/net/npf/npf_impl.h P src/sys/net/npf/npf_ruleset.c P src/sys/rump/kern/lib/libz/Makefile P src/tests/kernel/Makefile P src/tests/lib/libc/misc/Makefile P src/tests/lib/libc/ssp/Makefile P src/usr.bin/make/Makefile P src/usr.bin/newsyslog/Makefile P src/usr.bin/rdist/Makefile P src/usr.bin/stat/Makefile P src/usr.bin/systat/Makefile P src/usr.bin/telnet/Makefile P src/usr.sbin/npf/npfctl/npf.conf.5 P src/usr.sbin/npf/npfctl/npf_build.c P src/usr.sbin/npf/npfctl/npf_parse.y P src/usr.sbin/npf/npfctl/npf_scan.l P src/usr.sbin/npf/npfctl/npfctl.8 P src/usr.sbin/npf/npfctl/npfctl.c P src/usr.sbin/npf/npfctl/npfctl.h P src/usr.sbin/npf/npftest/npftest.conf P src/usr.sbin/quotacheck/Makefile P src/usr.sbin/sysinst/Makefile.inc P src/usr.sbin/syslogd/Makefile Updating xsrc tree: Killing core files: Updating release-7 src tree (netbsd-7): U doc/CHANGES-7.3 P sys/netbt/hci.h P sys/netbt/hci_event.c Updating release-7 xsrc tree (netbsd-7): Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.2 P external/mit/expat/lib/libexpat/Makefile P sys/netbt/hci.h P sys/netbt/hci_event.c Updating release-8 xsrc tree (netbsd-8): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 43416289 Sep 30 03:11 ls-lRA.gz
Re: 9.0-BETA panic
On 29/09/2019 21:54, Mike Pumford wrote: Was doing a pkgsrc build under jenkins and got the following panic: [ 14305.111922] panic: kernel diagnostic assertion "semcnt >= 0" failed: file "/ work/netbsd/9-stable/src/sys/kern/kern_uidinfo.c", line 241 [ 14305.111922] cpu5: Begin traceback... [ 14305.111922] vpanic() at netbsd:vpanic+0x160 [ 14305.111922] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 [ 14305.111922] chgsemcnt() at netbsd:chgsemcnt+0x56 [ 14305.111922] ksem_release() at netbsd:ksem_release+0x6a [ 14305.111922] ksem_close_fop() at netbsd:ksem_close_fop+0x49 [ 14305.111922] closef() at netbsd:closef+0x6d [ 14305.111922] fd_close() at netbsd:fd_close+0x1f4 [ 14305.121926] sys__ksem_destroy() at netbsd:sys__ksem_destroy+0x9c [ 14305.121926] syscall() at netbsd:syscall+0x181 [ 14305.121926] --- syscall (number 255) --- [ 14305.121926] 7b40fce3ee6a: [ 14305.121926] cpu5: End traceback... Bit more info. Kernel build time (which also represents the source tree checkout time): NetBSD trigati.mudcovered.org.uk 9.0_BETA NetBSD 9.0_BETA (GENERIC) #0: Sat Sep 28 09:56:10 BST 2019 buil...@trigati.mudcovered.org.uk:/work/netbsd/.jenkins/workspace/NetBSD-9-amd64-build/obj.amd64/sys/arch/amd64/compile/GENERIC amd64 Packages being compiled were for 8.1_STABLE in a pkg_comp1 chroot environment. Can't tell which package was being compiled at the time of death as I couldn't retrieve the jenkins build log. I'm re-running the same build to see if it happens again. Mike
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2019.09.29.18.51.08 rmind src/usr.sbin/npf/npfctl/npf_build.c,v 1.52 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.09.html#2019.09.29.18.51.08
9.0-BETA panic
Was doing a pkgsrc build under jenkins and got the following panic: [ 14305.111922] panic: kernel diagnostic assertion "semcnt >= 0" failed: file "/ work/netbsd/9-stable/src/sys/kern/kern_uidinfo.c", line 241 [ 14305.111922] cpu5: Begin traceback... [ 14305.111922] vpanic() at netbsd:vpanic+0x160 [ 14305.111922] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 [ 14305.111922] chgsemcnt() at netbsd:chgsemcnt+0x56 [ 14305.111922] ksem_release() at netbsd:ksem_release+0x6a [ 14305.111922] ksem_close_fop() at netbsd:ksem_close_fop+0x49 [ 14305.111922] closef() at netbsd:closef+0x6d [ 14305.111922] fd_close() at netbsd:fd_close+0x1f4 [ 14305.121926] sys__ksem_destroy() at netbsd:sys__ksem_destroy+0x9c [ 14305.121926] syscall() at netbsd:syscall+0x181 [ 14305.121926] --- syscall (number 255) --- [ 14305.121926] 7b40fce3ee6a: [ 14305.121926] cpu5: End traceback...
Automated report: NetBSD-current/i386 build failure
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 2019.09.29.17.00.29. An extract from the build.sh output follows: CC=/tmp/bracket/build/2019.09.29.17.00.29-i386/tools/bin/i486--netbsdelf-gcc /tmp/bracket/build/2019.09.29.17.00.29-i386/tools/bin/nbmkdep -f t_rwlock.d.tmp -- -std=gnu99 --sysroot=/tmp/bracket/build/2019.09.29.17.00.29-i386/destdir -I/tmp/bracket/build/2019.09.29.17.00.29-i386/src/tests/lib/libpthread/../.. /tmp/bracket/build/2019.09.29.17.00.29-i386/src/tests/lib/libpthread/t_rwlock.c && mv -f t_rwlock.d.tmp t_rwlock.d --- dependall-usr.sbin --- /tmp/bracket/build/2019.09.29.17.00.29-i386/tools/lib/gcc/i486--netbsdelf/7.4.0/../../../../i486--netbsdelf/bin/ld: npfctl.o: in function `.L176': npfctl.c:(.text.startup+0xc13): undefined reference to `npfctl_table_getbyname' /tmp/bracket/build/2019.09.29.17.00.29-i386/tools/lib/gcc/i486--netbsdelf/7.4.0/../../../../i486--netbsdelf/bin/ld: npfctl.c:(.text.startup+0xc64): undefined reference to `npfctl_load_table' collect2: error: ld returned 1 exit status *** [npfctl] Error code 1 nbmake[8]: stopped in /tmp/bracket/build/2019.09.29.17.00.29-i386/src/usr.sbin/npf/npfctl 1 error The following commits were made between the last successful build and the failed build: 2019.09.29.16.58.35 rmind src/usr.sbin/npf/npfctl/npfctl.8,v 1.22 2019.09.29.16.58.35 rmind src/usr.sbin/npf/npfctl/npfctl.c,v 1.62 2019.09.29.16.58.35 rmind src/usr.sbin/npf/npfctl/npfctl.h,v 1.50 2019.09.29.17.00.29 rmind src/sys/net/npf/npf_conn.c,v 1.30 2019.09.29.17.00.29 rmind src/sys/net/npf/npf_if.c,v 1.11 2019.09.29.17.00.29 rmind src/sys/net/npf/npf_impl.h,v 1.80 2019.09.29.17.00.29 rmind src/sys/net/npf/npf_ruleset.c,v 1.49 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.09.html#2019.09.29.17.00.29
Re: time(1) reporting corrupted system time
Michael van Elst wrote: > First there was a change to precent that user/system time are decreasing > in kern-resource.c 1.180. But it shouldn't be related to negative numbers. > > Additionally a possible underflow of user/system time was fixed in > kern_resource.c 1.182. This prevents negative numbers, but IIRC this > would only happen for very small values, not when values already > accumulated to a few thousand seconds. Thanks. I think what happened is that 1.180 caused the bug, and 1.182 fixed it. In any case, I think I now have what I need to back-port the fix and bisect the other bug. -- Andreas Gustafsson, g...@gson.org
Re: Build failed on fresh sources
On Sun, 29 Sep 2019, Christos Zoulas wrote:
Sure, but the question is why are you getting errors in the first place.
They should have been downgraded to warnings by -Wno-error-foo.
Something in /etc/mk.conf perhaps?
christos
On Sep 29, 2019, at 3:18 AM, Greywolf wrote:
On Sat, Sep 28, 2019 at 3:48 AM Christos Zoulas wrote:
We've chosen not to fix the fallthrough warnings in 3rd party code, but
we instead have changed the default setting to not produce errors. Have
you made any changes to the compilation environment that caused those to
become errors again?
christos
No, sir, I have not -- fresh sources, no environment variables set (I
only set them for full release builds).
Can this be overridden with a subsequent -Wno-{something}, or something similar?
--
--*greywolf;
!DSPAM:5d90be4e77492061013659!
++--+---+
| 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: Build failed on fresh sources
Sure, but the question is why are you getting errors in the first place.
They should have been downgraded to warnings by -Wno-error-foo.
christos
> On Sep 29, 2019, at 3:18 AM, Greywolf wrote:
>
> On Sat, Sep 28, 2019 at 3:48 AM Christos Zoulas wrote:
>
>> We've chosen not to fix the fallthrough warnings in 3rd party code, but
>> we instead have changed the default setting to not produce errors. Have
>> you made any changes to the compilation environment that caused those to
>> become errors again?
>>
>> christos
>
>
> No, sir, I have not -- fresh sources, no environment variables set (I
> only set them for full release builds).
>
> Can this be overridden with a subsequent -Wno-{something}, or something
> similar?
>
>
> --
> --*greywolf;
time(1) reporting corrupted system time
Hi all, I'm trying to run a bisection to determine why builds hosted on recent versions of NetBSD seem to be taking significantly more system time than they used to, building the same thing. My efforts are hampered by time(1) reporting corrupted system times on certain past versions of -current: 2017.01.01.03.06.06/build_8.log: 3562.32 real 15806.10 user 4893.62 sys 2018.05.21.10.28.13/build_8.log: 4250.22 real 16835.23 user 608742554440425.55 sys 2019.01.30.20.20.36/build_8.log: 4228.25 real 16801.48 user 700976274808841.24 sys 2019.09.27.08.57.12/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
re: Build failed on fresh sources
> ../../../../external/bsd/drm2/dist/drm/i915/intel_ddi.c -o intel_ddi.o
makeoptions i915drmkms "CWARNFLAGS.intel_ddi.c"+="${${ACTIVE_CC} ==
gcc && ${HAVE_GCC:U0} == 7:? -Wno-error=implicit-fallthrough :}"
this is missing from your build some how.
do you have HAVE_GCC set to something not 7?
.mrg.
Re: Build failed on fresh sources
On Sat, Sep 28, 2019 at 3:48 AM Christos Zoulas wrote:
> We've chosen not to fix the fallthrough warnings in 3rd party code, but
> we instead have changed the default setting to not produce errors. Have
> you made any changes to the compilation environment that caused those to
> become errors again?
>
> christos
No, sir, I have not -- fresh sources, no environment variables set (I
only set them for full release builds).
Can this be overridden with a subsequent -Wno-{something}, or something similar?
--
--*greywolf;
