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.02.17.04.57.09 kamil src/tests/lib/libc/sys/t_ptrace_wait.c,v 1.90 2019.02.17.05.06.16 nonaka src/sys/arch/x86/x86/lapic.c,v 1.70 2019.02.17.05.21.49 kamil src/tests/lib/libc/sys/t_ptrace_wait.c,v 1.91 2019.02.17.05.29.08 mrg src/distrib/sets/lists/comp/md.sparc64,v 1.208 2019.02.17.05.29.08 mrg src/etc/mtree/Attic/NetBSD.compat.mips64eb,v 1.2 2019.02.17.05.29.08 mrg src/etc/mtree/Attic/NetBSD.compat.mips64el,v 1.2 2019.02.17.05.29.08 mrg src/etc/mtree/Makefile,v 1.40 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.compat.mips64,v 1.1 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.dist.aarch64,v 1.6 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.dist.arm,v 1.1 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.dist.ia64,v 1.1 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.dist.mips,v 1.1 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.dist.powerpc,v 1.1 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.dist.sh3,v 1.1 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.dist.sparc,v 1.1 2019.02.17.05.29.08 mrg src/etc/mtree/NetBSD.dist.sparc64,v 1.12 2019.02.17.05.32.35 rin src/sys/arch/usermode/modules/syscallemu/Makefile,v 1.6 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.02.html#2019.02.17.05.32.35
Re: problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD
Please show us more details, like: - kernel messages how the devices attach - maybe kernel messages from somewhere else (FreeBSD?) You can use ktrace on the daemon process to see the communication it does via the serial device. First important part: which device node is it opening? E.g. it could be using /dev/ttyU0 instead of /dev/dtyU0 and block on missing "carrier" or something (but details depend on what the program wants to do and how the device behaves). Maybe the tty settings have not been ported to NetBSD properly. Martin
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.02.17.04.19.39.
An extract from the build.sh output follows:
rip_call < sce->sce_user_end) ||
^
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/arch/usermode/modules/syscallemu/syscallemu_x86.c:67:33:
error: comparison between signed and unsigned integer expressions
[-Werror=sign-compare]
(rip_call + frame->tf_err >= sce->sce_user_start &&
^~
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/arch/usermode/modules/syscallemu/syscallemu_x86.c:68:33:
error: comparison between signed and unsigned integer expressions
[-Werror=sign-compare]
rip_call + frame->tf_err < sce->sce_user_end)) {
^
--- dependall-solaris ---
--- xdr.d ---
#create solaris/xdr.d
CC=/tmp/bracket/build/2019.02.17.04.19.39-i386/tools/bin/i486--netbsdelf-gcc
/tmp/bracket/build/2019.02.17.04.19.39-i386/tools/bin/nbmkdep -f xdr.d.tmp --
-std=gnu99 -I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/common/include
-DDIAGNOSTIC --sysroot=/tmp/bracket/build/2019.02.17.04.19.39-i386/destdir
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/sys
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/common/acl
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/common
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/uts/common/zmod
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/uts/common
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/sys/sys
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/common/include -DDIAGNOSTIC
-nostdinc -I. -I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sy
s/modules/solaris -isystem /tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys
-isystem /tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/arch -isystem
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../common/include -D_KERNEL
-D_LKM -D_MODULE -DSYSCTL_INCLUDE_DESCR
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/uts/common/rpc/xdr.c
&& mv -f xdr.d.tmp xdr.d
--- dependall-dm ---
/tmp/bracket/build/2019.02.17.04.19.39-i386/tools/bin/nbctfconvert -L
VERSION dm_ioctl.o
--- dependall-../arch/usermode/modules/syscallemu ---
cc1: all warnings being treated as errors
*** [syscallemu_x86.o] Error code 1
nbmake[8]: stopped in
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/arch/usermode/modules/syscallemu
1 error
The following commits were made between the last successful build and
the failed build:
2019.02.17.03.57.31 rin src/sys/modules/Makefile.inc,v 1.7
2019.02.17.04.05.41 rin src/sys/modules/Makefile.inc,v 1.8
2019.02.17.04.05.41 rin src/sys/modules/accf_httpready/Makefile,v 1.3
2019.02.17.04.05.41 rin src/sys/modules/acpiacad/Makefile,v 1.4
2019.02.17.04.05.41 rin src/sys/modules/acpibat/Makefile,v 1.5
2019.02.17.04.05.41 rin src/sys/modules/acpibut/Makefile,v 1.4
2019.02.17.04.05.41 rin src/sys/modules/acpicpu/Makefile,v 1.7
2019.02.17.04.05.41 rin src/sys/modules/acpidalb/Makefile,v 1.3
2019.02.17.04.05.41 rin src/sys/modules/acpifan/Makefile,v 1.3
2019.02.17.04.05.42 rin src/sys/modules/acpilid/Makefile,v 1.4
2019.02.17.04.05.42 rin src/sys/modules/acpipmtr/Makefile,v 1.3
2019.02.17.04.05.42 rin src/sys/modules/acpitz/Makefile,v 1.4
2019.02.17.04.05.42 rin src/sys/modules/acpiverbose/Makefile,v 1.5
2019.02.17.04.05.42 rin src/sys/modules/acpivga/Makefile,v 1.3
2019.02.17.04.05.42 rin src/sys/modules/acpiwdrt/Makefile,v 1.2
2019.02.17.04.05.42 rin src/sys/modules/acpiwmi/Makefile,v 1.4
2019.02.17.04.05.42 rin src/sys/modules/adosfs/Makefile,v 1.2
2019.02.17.04.05.42 rin src/sys/modules/aibs/Makefile,v 1.5
2019.02.17.04.05.42 rin src/sys/modules/aio/Makefile,v 1.2
2019.02.17.04.05.42 rin src/sys/modules/amdsmn/Makefile,v 1.2
2019.02.17.04.05.43 rin src/sys/modules/amdtemp/Makefile,v 1.2
2019.02.17.04.05.43 rin src/sys/modules/amdzentemp/Makefile,v 1.2
2019.02.17.04.05.43 rin src/sys/modules/apple_smc/Makefile,v 1.3
2019.02.17.04.05.43 rin src/sys/modules/apple_smc_acpi/Makefile,v 1.2
2019.02.17.04.05.43 rin src/sys/modules/apple_smc_fan/Makefile,v 1.2
2019.02.17.04.05.43 rin src/sys/modules/apple_smc_temp/Makefile,v 1.2
2019.02.17.04.05.43 rin src/sys/modules/asus/Makefile,v 1.3
2019.02.17.04.05.43 rin src/sys/modules/ati_pcigart/Makefile,v 1.2
2019.02.17.04.05.43 rin src/sys/modules/au8522/Makefile,v 1.2
2019.02.17.04.05.43 rin src/sys/modules/audio/Makefile,v 1.3
2019.02.17.04.05.43 rin src/sys/modules/autofs/Makefile,
re: README: gcc 7 switch coming to a port near you!
matthew green writes: > Andreas Gustafsson writes: > > Some days ago, matthew green wrote: > > > hopefully the sparc testbed will fix itself now. > > > > It did, but MIPS is suffering from what looks like the same issue > > yeah - i commited the hack for it already, but i think i've just > found all the real fixes -- upstream's version of joerg's patch > to gcc/varasm.c plus additional fixes. > > with this, crtbegin.o has a read-only .eh_frame, and libstdc++ > builds sanely. > > i'll be running some local tests before reverting any crunchgen > changes, so hold off any ramdisk etc size bumps for now. OK, i believe all these problems are resolved, as is the problem wiz reported about mpd. i'll probably switch the 32 bit arm ports soon. that will leave: hppa (untested, builds), ia64 and powerpc64 (both have build issues so aren't testable), m68k (maybe ready?), sh3 (builds, not heavily tested), and vax (has a probelm with dynamic binaryes, but static and /rescue work), of the ports that currently build. riscv is also up and coming toolchain and userland. .mrg.
re: mac68k kern-INSTALL vs GCC7?
"John D. Baker" writes: > On Fri, 15 Feb 2019, John D. Baker wrote: > > > On Fri, 15 Feb 2019, Jaromir Dolecek wrote: > > > > > Maybe something like this? > > > > > > https://www.netbsd.org/~jdolecek/mac68k_intr_gcc7.diff > > > > With this the build succeeds. > > > > Will check Matthew Green's version after the next round of updates. > > This also allows -current mac68k build to complete with -V HAVE_GCC=7. > > (Don't know why his email addressed to me and Cc:ed to current-users > hasn't reached me--only saw it in current-users.) yeah - this is the only m68k build breaking change i didn't commit already because i was wanting a tester. all the other m68k ports should build and maybe work. amiga had reasonable atf results i believe. .mrg.
daily CVS update output
Updating src tree: P src/external/gpl3/gcc/lib/libgcc/arch/m68000/defs.mk P src/external/gpl3/gcc/lib/libgomp/arch/aarch64/config.h P src/external/gpl3/gcc/lib/libgomp/arch/alpha/config.h P src/external/gpl3/gcc/lib/libgomp/arch/arm/config.h P src/external/gpl3/gcc/lib/libgomp/arch/armeb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earm/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmeb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmhf/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmhfeb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv4/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv4eb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv6/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv6eb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv6hf/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv6hfeb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv7/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv7eb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv7hf/config.h P src/external/gpl3/gcc/lib/libgomp/arch/earmv7hfeb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/hppa/config.h P src/external/gpl3/gcc/lib/libgomp/arch/i386/config.h P src/external/gpl3/gcc/lib/libgomp/arch/m68k/config.h P src/external/gpl3/gcc/lib/libgomp/arch/mips64eb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/mips64el/config.h P src/external/gpl3/gcc/lib/libgomp/arch/mipseb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/mipsel/config.h P src/external/gpl3/gcc/lib/libgomp/arch/powerpc/config.h P src/external/gpl3/gcc/lib/libgomp/arch/sh3eb/config.h P src/external/gpl3/gcc/lib/libgomp/arch/sh3el/config.h P src/external/gpl3/gcc/lib/libgomp/arch/sparc/config.h P src/external/gpl3/gcc/lib/libgomp/arch/sparc64/config.h P src/external/gpl3/gcc/lib/libgomp/arch/vax/config.h P src/external/gpl3/gcc/lib/libgomp/arch/x86_64/config.h P src/external/gpl3/gcc/lib/libstdc++-v3/Makefile P src/external/gpl3/gcc/lib/libstdc++-v3/arch/aarch64/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/alpha/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/arm/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/armeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earm/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmhf/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmhfeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4eb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6eb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6hf/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6hfeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7eb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7hf/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7hfeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/hppa/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/i386/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68k/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/mips64eb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/mips64el/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/mipseb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/mipsel/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/powerpc/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/sh3eb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/sh3el/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/sparc/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/sparc64/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/vax/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64/c++config.h P src/external/gpl3/gcc/usr.bin/gcc/arch/aarch64/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/alpha/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/arm/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/arm/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/arm/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/armeb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/armeb/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/armeb/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhfeb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4eb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6eb/configargs.h P src/exter
Re: mac68k kern-INSTALL vs GCC7?
On Fri, 15 Feb 2019, John D. Baker wrote: > On Fri, 15 Feb 2019, Jaromir Dolecek wrote: > > > Maybe something like this? > > > > https://www.netbsd.org/~jdolecek/mac68k_intr_gcc7.diff > > With this the build succeeds. > > Will check Matthew Green's version after the next round of updates. This also allows -current mac68k build to complete with -V HAVE_GCC=7. (Don't know why his email addressed to me and Cc:ed to current-users hasn't reached me--only saw it in current-users.) -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: current fails to boot on VirtualBox
(to finish what I intended to say above) and the break apparently is not directly connected to the newly introduced Hyper-V devices in GENERIC, which came to my mind earlier. On Sun, 17 Feb 2019 at 00:00, Chavdar Ivanov wrote: > > I can confirm that the fix suggested in > https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53984 works > for me, reverting src/sys/arch/x86/x86/lapic.c to 1.68 gets me > % uname -a > NetBSD marge.lorien.lan 8.99.34 NetBSD 8.99.34 (GENERIC) #1: Sat Feb > 16 23:52:16 GMT 2019 > sysbuild@ymir:/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 > > (I was hit by the mpd not being able to start, but that was discussed > elsewhere). > > On Sat, 16 Feb 2019 at 21:59, Chavdar Ivanov wrote: > > > > Thanks, I will try the suggested fix after the build completes. > > > > On Sat, 16 Feb 2019 at 21:42, Cherry G.Mathew wrote: > > > > > > Chavdar Ivanov writes: > > > > > > > Mine is 8.99.34 from 09/02/2019, self build, works just fine. I'll > > > > build a new kernel now to compare. > > > > > > > > > > Just FYI in case this is relevant and can help you with bisecting: > > > > > > https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53984 > > > > > > > > > -- > > > ~cherry > > > > > > > > -- > > > > > > -- > --
Re: current fails to boot on VirtualBox
I can confirm that the fix suggested in https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53984 works for me, reverting src/sys/arch/x86/x86/lapic.c to 1.68 gets me % uname -a NetBSD marge.lorien.lan 8.99.34 NetBSD 8.99.34 (GENERIC) #1: Sat Feb 16 23:52:16 GMT 2019 sysbuild@ymir:/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 (I was hit by the mpd not being able to start, but that was discussed elsewhere). On Sat, 16 Feb 2019 at 21:59, Chavdar Ivanov wrote: > > Thanks, I will try the suggested fix after the build completes. > > On Sat, 16 Feb 2019 at 21:42, Cherry G.Mathew wrote: > > > > Chavdar Ivanov writes: > > > > > Mine is 8.99.34 from 09/02/2019, self build, works just fine. I'll > > > build a new kernel now to compare. > > > > > > > Just FYI in case this is relevant and can help you with bisecting: > > > > https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53984 > > > > > > -- > > ~cherry > > > > -- > --
Re: current fails to boot on VirtualBox
Thanks, I will try the suggested fix after the build completes. On Sat, 16 Feb 2019 at 21:42, Cherry G.Mathew wrote: > > Chavdar Ivanov writes: > > > Mine is 8.99.34 from 09/02/2019, self build, works just fine. I'll > > build a new kernel now to compare. > > > > Just FYI in case this is relevant and can help you with bisecting: > > https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53984 > > > -- > ~cherry --
Re: current fails to boot on VirtualBox
I am still building, but my guess is that some clever clogs has added Microsoft Hyper-V devices to GENERIC: .. % cvs diff -r 1.515 -r 1.516 GENERIC 19-02-16 - 21:52:48 Index: GENERIC === RCS file: /cvsroot/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.515 retrieving revision 1.516 diff -r1.515 -r1.516 1c1 < # $NetBSD: GENERIC,v 1.515 2019/01/01 08:09:30 maya Exp $ --- > # $NetBSD: GENERIC,v 1.516 2019/02/15 08:54:01 nonaka Exp $ 25c25 < #ident"GENERIC-$Revision: 1.515 $" --- > #ident"GENERIC-$Revision: 1.516 $" 89a90 > hyperv0 at cpu0 # Microsoft Hyper-V 1082a1084,1091 > # Hyper-V devices > vmbus*at acpi?# Hyper-V VMBus > hvn* at vmbus? # Hyper-V NetVSC > hvs* at vmbus? # Hyper-V StorVSC > hvheartbeat* at vmbus? # Hyper-V Heartbeat > hvshutdown* at vmbus? # Hyper-V Shutdown > hvtimesync* at vmbus? # Hyper-V Timesync > One cannot run Hyper-V and VirtualBox on the same machine - if you enable Hyper-V, VirtualBox stops working. Obviously this still doesn't mean this is the reason, but is likely. ] On Sat, 16 Feb 2019 at 21:37, Chavdar Ivanov wrote: > > Mine is 8.99.34 from 09/02/2019, self build, works just fine. I'll > build a new kernel now to compare. > > On Sat, 16 Feb 2019 at 21:12, Ron Georgia wrote: > > > > Same here. Fails to boot on both my workstation and laptop, fell back to > > 8.99.33 > > > > On 2/16/19, 3:15 PM, "Arto Huusko" > behalf of arm...@gmail.com> wrote: > > > > Hello, > > > > it seems latest -current amd64 kernel no longer boots on VirtualBox. > > > > Booting GENERIC from > > > > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201902161050Z/amd64/binary/kernel/ > > > > stops after detecting CPUs and acpiacad0. After CPU detection there is > > ERROR: 3591 cycle TSC drift observed. > > > > CPU is AMD Ryzen 5 1500X. > > > > I can break into ddb, bt command on all CPUs shows they are in > > idle_loop. > > It makes no difference if I configure only one CPU for VirtualBox. > > > > bt for cpu 0: > > ddb backtrace > > --- interrupt > > x86_stihlt > > acpicpu_cstate_idle_enter > > acpicpu_cstate_idle > > idle_loop > > > > bt for cpu1: > > x86_stihlt > > acpicpu_cstate_idle_enter > > acpicpu_cstate_idle > > cpu_hatch > > md_root_setconf > > > > > > Booting with -2 switch (no ACPI) gets a bit further, but then has other > > problems > > detecting devices. > > > > However a few days old GENERIC from > > > > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201902131540Z/amd64/binary/kernel/ > > > > does boot successfully. (But vioif is broken again, ifconfig just hangs) > > > > > > A lot older kernel (8.99.18, I don't have the exact date) works without > > problems. > > > > > > Arto > > > > > > > > > -- > --
Re: current fails to boot on VirtualBox
Chavdar Ivanov writes: > Mine is 8.99.34 from 09/02/2019, self build, works just fine. I'll > build a new kernel now to compare. > Just FYI in case this is relevant and can help you with bisecting: https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53984 -- ~cherry
Re: current fails to boot on VirtualBox
Mine is 8.99.34 from 09/02/2019, self build, works just fine. I'll build a new kernel now to compare. On Sat, 16 Feb 2019 at 21:12, Ron Georgia wrote: > > Same here. Fails to boot on both my workstation and laptop, fell back to > 8.99.33 > > On 2/16/19, 3:15 PM, "Arto Huusko" of arm...@gmail.com> wrote: > > Hello, > > it seems latest -current amd64 kernel no longer boots on VirtualBox. > > Booting GENERIC from > > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201902161050Z/amd64/binary/kernel/ > > stops after detecting CPUs and acpiacad0. After CPU detection there is > ERROR: 3591 cycle TSC drift observed. > > CPU is AMD Ryzen 5 1500X. > > I can break into ddb, bt command on all CPUs shows they are in idle_loop. > It makes no difference if I configure only one CPU for VirtualBox. > > bt for cpu 0: > ddb backtrace > --- interrupt > x86_stihlt > acpicpu_cstate_idle_enter > acpicpu_cstate_idle > idle_loop > > bt for cpu1: > x86_stihlt > acpicpu_cstate_idle_enter > acpicpu_cstate_idle > cpu_hatch > md_root_setconf > > > Booting with -2 switch (no ACPI) gets a bit further, but then has other > problems > detecting devices. > > However a few days old GENERIC from > > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201902131540Z/amd64/binary/kernel/ > > does boot successfully. (But vioif is broken again, ifconfig just hangs) > > > A lot older kernel (8.99.18, I don't have the exact date) works without > problems. > > > Arto > > > --
Re: current fails to boot on VirtualBox
Same here. Fails to boot on both my workstation and laptop, fell back to 8.99.33 On 2/16/19, 3:15 PM, "Arto Huusko" wrote: Hello, it seems latest -current amd64 kernel no longer boots on VirtualBox. Booting GENERIC from http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201902161050Z/amd64/binary/kernel/ stops after detecting CPUs and acpiacad0. After CPU detection there is ERROR: 3591 cycle TSC drift observed. CPU is AMD Ryzen 5 1500X. I can break into ddb, bt command on all CPUs shows they are in idle_loop. It makes no difference if I configure only one CPU for VirtualBox. bt for cpu 0: ddb backtrace --- interrupt x86_stihlt acpicpu_cstate_idle_enter acpicpu_cstate_idle idle_loop bt for cpu1: x86_stihlt acpicpu_cstate_idle_enter acpicpu_cstate_idle cpu_hatch md_root_setconf Booting with -2 switch (no ACPI) gets a bit further, but then has other problems detecting devices. However a few days old GENERIC from http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201902131540Z/amd64/binary/kernel/ does boot successfully. (But vioif is broken again, ifconfig just hangs) A lot older kernel (8.99.18, I don't have the exact date) works without problems. Arto
Re: gcc7 AMD kernel fails to boot
On Wed, Feb 13, 2019 at 09:14:51PM +, Patrick Welche wrote: > On Tue, Feb 12, 2019 at 04:52:20PM +, Patrick Welche wrote: > > On Tue, Feb 12, 2019 at 09:45:14AM +, Patrick Welche wrote: > > > On Tue, Feb 12, 2019 at 07:22:26PM +1100, matthew green wrote: > > > > hmm. can you try a kernel built with build.sh kernel=? ie, the > > > > "cross compiler" toos, vs. the compiler in /usr/bin. > > > > build.sh didn't help... building a pkgsrc/gcc6 now... > > Probably a false alarm: did a fresh cvs checkout and built GENERIC using > gcc 7. That kernel booted. Actually - apparently nothing to do with gcc 7, but a bug that got fixed. With head, my ryzen freezes early on during rc. I tried a bisect back to Feb 11, and saw the freeze early in kernel start which caused this thread. At the moment: bad : bad2257e Sat Feb 16 16:20:50 2019 + good: 9851c0f8 Thu Feb 14 13:27:59 2019 + bad : 1a015e8b Mon Feb 11 20:40:18 2019 + P
problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD
This is not necessarily limited to NetBSD-CURRENT, though the problem exists there (that’s where I reproduced it). I’m happy to take it elsewhere or offline — I just couldn’t figure out where the right eyes might see it. Please point me elsewhere if I’m not in the right spot. Short story: I have two different USB devices that expose a USB CDC modem interface (BTW, my USB vocabulary is rusty — I don’t mean “interface” to carry any technical baggage). These devices work fine when talking to Linux, Mac OS X, and FreeBSD. But NetBSD doesn’t (on two different systems — Raspberry Pi and amd64 VMWare virtual machine). I haven’t been able to debug why yet. I was asking here to see if anyone might be willing to help me. Longer story: I’m trying to get Thread (http://www.threadgroup.org/) radios working with NetBSD, using OpenThread’s stack (http://openthread.io). I’m using two different chipsets (Silicon Labs EFR32 and Nordic NRF52840), and both demonstrate the problem. I’ve built and flashed OpenThread binaries that run on the devices themselves. There’s a host system component (wpantund, available at https://github.com/openthread/wpantund), which opens the serial port and communicates with the device. wpantund does some other stuff, like using the tun(4) device to proxy the OpenThread 6LowPAN stack through the kernel, etc. And wpantund is a bear to compile — it uses a bunch of C++ boost stuff. But I’ve built it on Linux, Mac OS X, FreeBSD and NetBSD. wpantund works fine everywhere except NetBSD (on both Raspberry Pi and my VMWare VM), and the part that’s failing is communication with the device over the USB CDC modem — wpantund thinks it is making read requests to the kernel, but I can’t tell if those ever go out to USB. Certainly wpantund never seems to get any data back — but I don’t know if it’s simply never getting anything over USB, or it’s not making it through the kernel. My gut says there’s something weird about the umodem/ucom driver. I tried other USB serial devices (when I plug my Raspberry Pi into a NetBSD VM, it shows up as a different kind of serial port — uftdi/ucom — and that works fine). I don’t have access to a USB sniffer, though I’m trying to see if I can come by one. (I’ve thought about getting a BeagleBone Black and using https://github.com/dominicgs/USBProxy and WireShark, but I was worried it might not work that well. I don’t want to shell out for an expensive sniffer/analyzer, but if someone can loan one or provide me some time with one — I’m in the Bay Area — let me know. Advice on this front is welcome. I haven’t yet looked to see if there’s good USB debugging in the kernel — as I’m using current, it seemed part of kernhist, which is pretty new to me.) Anyone here interested in getting these USB CDC devices that work elsewhere to work with NetBSD? I’m technical enough, and can build and test kernels and even debug a bit on my own. But I’m not a USB expert and it’s gonna take a fair bit of time to come backup to speed — if someone else is an expert, I’d love some guidance. Thanks! Rob
current fails to boot on VirtualBox
Hello, it seems latest -current amd64 kernel no longer boots on VirtualBox. Booting GENERIC from http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201902161050Z/amd64/binary/kernel/ stops after detecting CPUs and acpiacad0. After CPU detection there is ERROR: 3591 cycle TSC drift observed. CPU is AMD Ryzen 5 1500X. I can break into ddb, bt command on all CPUs shows they are in idle_loop. It makes no difference if I configure only one CPU for VirtualBox. bt for cpu 0: ddb backtrace --- interrupt x86_stihlt acpicpu_cstate_idle_enter acpicpu_cstate_idle idle_loop bt for cpu1: x86_stihlt acpicpu_cstate_idle_enter acpicpu_cstate_idle cpu_hatch md_root_setconf Booting with -2 switch (no ACPI) gets a bit further, but then has other problems detecting devices. However a few days old GENERIC from http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201902131540Z/amd64/binary/kernel/ does boot successfully. (But vioif is broken again, ifconfig just hangs) A lot older kernel (8.99.18, I don't have the exact date) works without problems. Arto
Re: build error with MKX11MOTIF=yes in mk.conf
> MKX11MOTIF=yes This is the first time that I hear of this make variable :) I'd file a PR. -- Benny
Re: mac68k kern-INSTALL vs GCC7?
In article <4559.1550263...@splode.eterna.com.au>, matthew green wrote: >this is my preferred change vs jarmoir's. please test it. > > https://www.netbsd.org/~mrg/mac68k-intr.diff > >i was also planning on adding an assert that MAX_INAME_LENGTH is >less than (eintrnames - intrnames). I would use sizeof() in the memcpy. christos
