daily CVS update output
Updating src tree: P src/bin/kill/kill.1 P src/bin/kill/kill.c P src/bin/sh/jobs.c P src/distrib/sets/lists/xcomp/mi P src/external/mit/xorg/include/xorgproto/Makefile P src/sys/arch/alpha/alpha/prom.c P src/sys/arch/amd64/conf/GENERIC P src/sys/arch/pmax/conf/GENERIC P src/usr.bin/make/arch.c P src/usr.bin/make/compat.c P src/usr.bin/make/dir.c P src/usr.bin/make/for.c P src/usr.bin/make/job.c P src/usr.bin/make/lst.c P src/usr.bin/make/lst.h P src/usr.bin/make/main.c P src/usr.bin/make/make.c P src/usr.bin/make/make.h P src/usr.bin/make/meta.c P src/usr.bin/make/nonints.h P src/usr.bin/make/parse.c P src/usr.bin/make/str.c P src/usr.bin/make/suff.c P src/usr.bin/make/targ.c P src/usr.bin/make/var.c P src/usr.bin/make/unit-tests/directive-ifmake.exp P src/usr.bin/make/unit-tests/directive-ifmake.mk P src/usr.sbin/puffs/mount_9p/Makefile Updating xsrc tree: P xsrc/external/mit/libX11/dist/ChangeLog P xsrc/external/mit/libX11/dist/configure P xsrc/external/mit/libX11/dist/configure.ac P xsrc/external/mit/libX11/dist/include/X11/XKBlib.h P xsrc/external/mit/libX11/dist/man/XCreateGC.man P xsrc/external/mit/libX11/dist/modules/im/ximcp/imRmAttr.c P xsrc/external/mit/libX11/dist/modules/om/generic/omGeneric.c P xsrc/external/mit/libX11/dist/src/GetStCmap.c P xsrc/external/mit/libX11/dist/src/xkb/XKBBind.c Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.1 P sys/arch/alpha/alpha/prom.c P sys/dev/nvmm/nvmm.c P sys/dev/nvmm/nvmm_ioctl.h P sys/dev/nvmm/x86/nvmm_x86.c P sys/dev/nvmm/x86/nvmm_x86_svm.c P sys/dev/nvmm/x86/nvmm_x86_svmfunc.S P sys/dev/nvmm/x86/nvmm_x86_vmx.c P sys/dev/nvmm/x86/nvmm_x86_vmxfunc.S Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 44982786 Aug 31 03:11 ls-lRA.gz
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Aug 24, 2020, at 1:32 PM, Chavdar Ivanov wrote: > On Mon, 24 Aug 2020 at 15:08, Robert Nestor wrote: >> >> >> On Aug 23, 2020, at 1:57 PM, Chavdar Ivanov wrote: >> >>> On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: I received a couple of messages off list that suggested a few things and it prompted me to try investigating further with just components found in NetBSD. This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting them with qemu using -nvmm and the OVMF binaries currently in pkgsrc with the following: qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ >>> >>> -accel nvmm >>> -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ >>> >>> the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but >>> perhaps this is a typo. Anyway. I have no idea about this particular >>> way of specifying the bios; anyway, with >>> >>> >>> -bios /usr/pkg/share/ovmf/OVMFX64.fd \ >>> >>> it boots just fine. Otherwise I get the same crash as you. >>> >>> -device ich9-ahci,id=sata \ -device ide-cd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso This produces an immediate “failed to start VCPU” and results in a core dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: >>> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ -device ich9-ahci,id=sata \ -device ide-hd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img And it provides the same results - “failed to start VCPU” and a core dump. Removing the “-accel=nvmm” from both of the scripts allows the boot to proceed, but the OVMF code fails to find the CD or HD image and boot falls back to attempting to boot over the network. This appears to be a bug in the version of OVMF found in pkgsrc which is based on stable2018. Replacing the OVMF with binaries obtained from a build of stable202005 fixes the disk access issue and the boot then succeeds brining up the NetBSD installer. I then proceeded to do two installations of NetBSD under qem; one using the defaults for an MBR setup and one for a GPT setup. The resulting MBR disk doesn’t boot under qemu; the GPT disk does boot however. In the case of the MBR disk it appears the problem is that OVMF can’t find the disk or anything bootable on it. I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and PR-55582 for the OVMF issue. >> >> Indeed, using the OVMFX64.fd file as a -bios parameter does eliminate the >> NVMM crash and it does boot up the NetBSD CD ISO file. From there I was >> able to do two installations of NetBSD, one specifying an MBR partition >> setup and one with GPT taking the defaults for both. However, neither of >> the created disk image files will boot with the OVMFX64.fd file. Using a >> newer version from a stable202005 OVMF build and one from a build done in >> the last week or so does boot up the GPT created disk image but not the >> newly created MBR disk image. > > I haven't tried an MBR installation, but my GPT one boots just fine > with OVMFX86 - > > qemu-system-x86_64 \ >-m 3072 \ >-machine q35 \ >-accel nvmm \ >-device qemu-xhci \ >-device usb-tablet \ >-device usb-mouse \ >-k en-gb \ >-smp 2 \ >-net tap,fd=3 3<>/dev/tap1 \ >-boot menu=on \ >-vnc :1 \ >-net nic \ >-bios /usr/pkg/share/ovmf/OVMFX64.fd \ >-drive format=raw,file=/dev/zvol/rdsk/tank/ztest > > This is the system I installed yesterday on a fresh zvol, it boots > fine. As I have said previously, the same system can't boot if I use X > server / gtk output - it boots only if I use vnc. So there is a > problem, but I can't figure out who to blame in this case Did a bit more digging on this and came up with a couple of things. It appears the MBR boot failure may be caused by not having the CSM code enabled in the version of OVMF being used. I had some limited success using a version of OVMF that was built with CSM support which builds in a copy of SeaBIOS. This type of build for OVMF doesn’t appear to be recommended though as it requires a lot of mode switching between 16 bit and 32/64 bit mode that
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Aug 24, 2020, at 1:32 PM, Chavdar Ivanov wrote: > On Mon, 24 Aug 2020 at 15:08, Robert Nestor wrote: >> >> >> On Aug 23, 2020, at 1:57 PM, Chavdar Ivanov wrote: >> >>> On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: I received a couple of messages off list that suggested a few things and it prompted me to try investigating further with just components found in NetBSD. This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting them with qemu using -nvmm and the OVMF binaries currently in pkgsrc with the following: qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ >>> >>> -accel nvmm >>> -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ >>> >>> the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but >>> perhaps this is a typo. Anyway. I have no idea about this particular >>> way of specifying the bios; anyway, with >>> >>> >>> -bios /usr/pkg/share/ovmf/OVMFX64.fd \ >>> >>> it boots just fine. Otherwise I get the same crash as you. >>> >>> -device ich9-ahci,id=sata \ -device ide-cd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso This produces an immediate “failed to start VCPU” and results in a core dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: >>> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ -device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ -drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ -device ich9-ahci,id=sata \ -device ide-hd,bus=sata.0,drive=disk \ -drive id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img And it provides the same results - “failed to start VCPU” and a core dump. Removing the “-accel=nvmm” from both of the scripts allows the boot to proceed, but the OVMF code fails to find the CD or HD image and boot falls back to attempting to boot over the network. This appears to be a bug in the version of OVMF found in pkgsrc which is based on stable2018. Replacing the OVMF with binaries obtained from a build of stable202005 fixes the disk access issue and the boot then succeeds brining up the NetBSD installer. I then proceeded to do two installations of NetBSD under qem; one using the defaults for an MBR setup and one for a GPT setup. The resulting MBR disk doesn’t boot under qemu; the GPT disk does boot however. In the case of the MBR disk it appears the problem is that OVMF can’t find the disk or anything bootable on it. I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and PR-55582 for the OVMF issue. >> >> Indeed, using the OVMFX64.fd file as a -bios parameter does eliminate the >> NVMM crash and it does boot up the NetBSD CD ISO file. From there I was >> able to do two installations of NetBSD, one specifying an MBR partition >> setup and one with GPT taking the defaults for both. However, neither of >> the created disk image files will boot with the OVMFX64.fd file. Using a >> newer version from a stable202005 OVMF build and one from a build done in >> the last week or so does boot up the GPT created disk image but not the >> newly created MBR disk image. > > I haven't tried an MBR installation, but my GPT one boots just fine > with OVMFX86 - > > qemu-system-x86_64 \ >-m 3072 \ >-machine q35 \ >-accel nvmm \ >-device qemu-xhci \ >-device usb-tablet \ >-device usb-mouse \ >-k en-gb \ >-smp 2 \ >-net tap,fd=3 3<>/dev/tap1 \ >-boot menu=on \ >-vnc :1 \ >-net nic \ >-bios /usr/pkg/share/ovmf/OVMFX64.fd \ >-drive format=raw,file=/dev/zvol/rdsk/tank/ztest > > This is the system I installed yesterday on a fresh zvol, it boots > fine. As I have said previously, the same system can't boot if I use X > server / gtk output - it boots only if I use vnc. So there is a > problem, but I can't figure out who to blame in this case Did a bit more digging on this and came up with a couple of things. It appears the MBR boot failure may be caused by not having the CSM code enabled in the version of OVMF being used. I had some limited success using a version of OVMF that was built with CSM support which builds in a copy of SeaBIOS. This type of build for OVMF doesn’t appear to be recommended though as it requires a lot of mode switching between 16 bit and 32/64 bit mode that
Re: NetBSD bug/misbehavior in vdprintf
hello. I'm pretty sure fpritf can return an error that means there was an i/o error or that something about the underlying file descriptor needs investigating. -Brian On Aug 29, 8:25am, Rob Newberry wrote: } Subject: Re: NetBSD bug/misbehavior in vdprintf } >>> NetBSD's implementation of vdprintf makes a special check -- if the } >>> descriptor is in non-blocking mode, it needs to be a regular file (I } >>> think I read that code correctly). But it apparently doesn't have this } >>> check problem for vfprintf. I think it's been there a long time (since } >>> the introduction of vdprintf), but it makes vdprintf behave differently } >>> than vfprintf. In my view, "vfprintf( FILE, ...)" and "vdprintf( } >>> fileno( FILE ), ... )" ought to behave the same -- but they don't (on } >>> NetBSD) if "fileno( FILE )" has been marked non-blocking and it's not a } >>> regular file. } >> } >> You are right, it should work and I removed the test. } > } > Isn't the situation a bit more complicated? Normally, stdio will ensure } > data isn't just lost for non-blocking sockets on the blocking condition. } > But I don't think the whole dprintf interface allows dealing with error } > conditions in any sane way. } } Is the interface any different for fprintf than dprintf? Does fprintf (by virtue of having a FILE* instead of just a descriptor) have the ability to deal with those errors better? } } } >-- End of excerpt from Rob Newberry
xen-tools 4.13.1 build failure
Hi, Trying to build xentools-4.13.1 under -current: gcc -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.7 -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/X11R7/include -D_XOPEN_SOURCE_EXTENDED=1 -I/usr/pkg/include/ncurses -DPIC -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.7 -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/X11R7/include -D_XOPEN_SOURCE_EXTENDED=1 -I/usr/pkg/include/ncurses -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .subdirs-all.d -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .subdir-all-libs.d -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .subdirs-all.d -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .subdir-all-evtchn.d -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .build.d -Werror -Wmissing-prototypes -I./include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/libs/toollog/include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/libs/toolcore/include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/include -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .netbsd.opic.d -Werror -Wmissing-prototypes -I./include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/libs/toollog/include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/libs/toolcore/include -I/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/libs/evtchn/../../../tools/include -fPIC -c -o netbsd.opic netbsd.c netbsd.c:30:10: fatal error: xen/xenio3.h: No such file or directory #include ^~ compilation terminated. netbsd.c:30:10: fatal error: xen/xenio3.h: No such file or directory I couldn't locate this include file; if I try to compile without it, I get further a lot of errors. Chavdar --
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: net/if_wg/t_misc:wg_malformed The above test failed in each of the last 4 test runs, and passed in at least 25 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/depsrc-silent.exp,v 1.2 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/depsrc-silent.mk,v 1.3 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/deptgt-begin.exp,v 1.2 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/deptgt-begin.mk,v 1.3 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/deptgt-end.exp,v 1.2 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/deptgt-end.mk,v 1.3 2020.08.29.17.41.14 christos src/sys/netinet/in.c,v 1.238 2020.08.29.18.50.25 rillig src/distrib/sets/lists/tests/mi,v 1.914 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/Makefile,v 1.127 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/directive-else.exp,v 1.2 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/directive-else.mk,v 1.3 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/directive-for-generating-endif.exp,v 1.1 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/directive-for-generating-endif.mk,v 1.1 2020.08.29.18.54.33 christos src/share/misc/acronyms,v 1.306 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.08.html#2020.08.29.18.54.33
Automated report: NetBSD-current/i386 test failure
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_ipv4_over_ipv4 net/if_wg/t_basic:wg_basic_ipv4_over_ipv6 net/if_wg/t_basic:wg_multiple_interfaces net/if_wg/t_basic:wg_multiple_peers net/if_wg/t_basic:wg_payload_sizes_ipv4_over_ipv4 net/if_wg/t_basic:wg_payload_sizes_ipv4_over_ipv6 net/if_wg/t_misc:wg_handshake_timeout net/if_wg/t_misc:wg_keepalive net/if_wg/t_misc:wg_mobility net/if_wg/t_misc:wg_psk 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.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/depsrc-silent.exp,v 1.2 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/depsrc-silent.mk,v 1.3 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/deptgt-begin.exp,v 1.2 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/deptgt-begin.mk,v 1.3 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/deptgt-end.exp,v 1.2 2020.08.29.17.34.21 rillig src/usr.bin/make/unit-tests/deptgt-end.mk,v 1.3 2020.08.29.17.41.14 christos src/sys/netinet/in.c,v 1.238 2020.08.29.18.50.25 rillig src/distrib/sets/lists/tests/mi,v 1.914 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/Makefile,v 1.127 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/directive-else.exp,v 1.2 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/directive-else.mk,v 1.3 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/directive-for-generating-endif.exp,v 1.1 2020.08.29.18.50.25 rillig src/usr.bin/make/unit-tests/directive-for-generating-endif.mk,v 1.1 2020.08.29.18.54.33 christos src/share/misc/acronyms,v 1.306 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.08.html#2020.08.29.18.54.33
