daily CVS update output
Updating src tree: P src/common/lib/libc/arch/x86_64/atomic/atomic.S P src/distrib/sets/lists/comp/md.sparc64 P src/distrib/sets/lists/debug/mi P src/distrib/sets/lists/tests/mi P src/etc/mtree/Makefile U src/etc/mtree/NetBSD.compat.mips64 cvs update: `src/etc/mtree/NetBSD.compat.mips64eb' is no longer in the repository cvs update: `src/etc/mtree/NetBSD.compat.mips64el' is no longer in the repository U src/etc/mtree/NetBSD.dist.aarch64 U src/etc/mtree/NetBSD.dist.arm U src/etc/mtree/NetBSD.dist.ia64 U src/etc/mtree/NetBSD.dist.mips U src/etc/mtree/NetBSD.dist.powerpc U src/etc/mtree/NetBSD.dist.sh3 U src/etc/mtree/NetBSD.dist.sparc U src/etc/mtree/NetBSD.dist.sparc64 P src/etc/mtree/NetBSD.dist.tests P src/external/bsd/libnv/lib/Makefile P src/external/gpl3/gcc/README.gcc7 P src/lib/libnvmm/libnvmm_x86.c P src/lib/librumphijack/Makefile P src/lib/librumphijack/hijack.c P src/sys/arch/arm/sunxi/sunxi_lcdc.c P src/sys/arch/atari/atari/trap.c P src/sys/arch/atari/conf/files.atari P src/sys/arch/atari/include/cpu.h P src/sys/arch/cesfic/cesfic/trap.c P src/sys/arch/cesfic/conf/files.cesfic P src/sys/arch/cesfic/include/cpu.h P src/sys/arch/hp300/conf/files.hp300 P src/sys/arch/hp300/hp300/trap.c P src/sys/arch/hp300/include/cpu.h P src/sys/arch/luna68k/conf/files.luna68k P src/sys/arch/luna68k/include/cpu.h P src/sys/arch/luna68k/luna68k/trap.c P src/sys/arch/m68k/include/frame.h U src/sys/arch/m68k/m68k/m68k_trap.c P src/sys/arch/mac68k/conf/files.mac68k P src/sys/arch/mac68k/include/cpu.h P src/sys/arch/mac68k/mac68k/trap.c P src/sys/arch/mips/adm5120/dev/ahci.c P src/sys/arch/mvme68k/conf/files.mvme68k P src/sys/arch/mvme68k/mvme68k/trap.c P src/sys/arch/news68k/conf/files.news68k P src/sys/arch/news68k/include/cpu.h P src/sys/arch/news68k/news68k/trap.c P src/sys/arch/next68k/conf/files.next68k P src/sys/arch/next68k/include/cpu.h P src/sys/arch/next68k/next68k/trap.c P src/sys/arch/usermode/modules/syscallemu/Makefile P src/sys/arch/x68k/conf/files.x68k P src/sys/arch/x68k/include/cpu.h P src/sys/arch/x68k/x68k/trap.c P src/sys/arch/x86/x86/lapic.c P src/sys/dev/ic/sl811hs.c P src/sys/dev/usb/ehci.c P src/sys/dev/usb/if_axen.c P src/sys/dev/usb/if_axenreg.h P src/sys/dev/usb/motg.c P src/sys/dev/usb/ohci.c P src/sys/dev/usb/uhci.c P src/sys/dev/usb/usbdi.c P src/sys/dev/usb/xhci.c P src/sys/external/bsd/dwc2/dwc2.c P src/sys/kern/subr_bufq.c P src/sys/modules/Makefile.inc P src/sys/modules/accf_httpready/Makefile P src/sys/modules/acpiacad/Makefile P src/sys/modules/acpibat/Makefile P src/sys/modules/acpibut/Makefile P src/sys/modules/acpicpu/Makefile P src/sys/modules/acpidalb/Makefile P src/sys/modules/acpifan/Makefile P src/sys/modules/acpilid/Makefile P src/sys/modules/acpipmtr/Makefile P src/sys/modules/acpitz/Makefile P src/sys/modules/acpiverbose/Makefile P src/sys/modules/acpivga/Makefile P src/sys/modules/acpiwdrt/Makefile P src/sys/modules/acpiwmi/Makefile P src/sys/modules/adosfs/Makefile P src/sys/modules/aibs/Makefile P src/sys/modules/aio/Makefile P src/sys/modules/amdsmn/Makefile P src/sys/modules/amdtemp/Makefile P src/sys/modules/amdzentemp/Makefile P src/sys/modules/apple_smc/Makefile P src/sys/modules/apple_smc_acpi/Makefile P src/sys/modules/apple_smc_fan/Makefile P src/sys/modules/apple_smc_temp/Makefile P src/sys/modules/asus/Makefile P src/sys/modules/ati_pcigart/Makefile P src/sys/modules/au8522/Makefile P src/sys/modules/audio/Makefile P src/sys/modules/autofs/Makefile P src/sys/modules/auvitek/Makefile P src/sys/modules/azalia/Makefile P src/sys/modules/bpf/Makefile P src/sys/modules/bpf_filter/Makefile P src/sys/modules/ccd/Makefile P src/sys/modules/cd9660/Makefile P src/sys/modules/cgd/Makefile P src/sys/modules/chfs/Makefile P src/sys/modules/cir/Makefile P src/sys/modules/coda/Makefile P src/sys/modules/coda5/Makefile P src/sys/modules/compat_20/Makefile P src/sys/modules/compat_30/Makefile P src/sys/modules/compat_43/Makefile P src/sys/modules/compat_50/Makefile P src/sys/modules/compat_freebsd/Makefile P src/sys/modules/compat_linux/Makefile P src/sys/modules/compat_linux32/Makefile P src/sys/modules/compat_netbsd32/Makefile P src/sys/modules/compat_netbsd32_43/Makefile P src/sys/modules/compat_netbsd32_50/Makefile P src/sys/modules/compat_ossaudio/Makefile P src/sys/modules/compat_raid_50/Makefile P src/sys/modules/compat_sysctl_09_43/Makefile P src/sys/modules/coram/Makefile P src/sys/modules/coredump/Makefile P src/sys/modules/coretemp/Makefile P src/sys/modules/crypto/Makefile P src/sys/modules/cx24227/Makefile P src/sys/modules/cxdtv/Makefile P src/sys/modules/dbcool/Makefile P src/sys/modules/dk_subr/Makefile P src/sys/modules/dm/Makefile P src/sys/modules/drm/Makefile P src/sys/modules/drmkms/Makefile P src/sys/modules/drmkms_agp/Makefile P src/sys/modules/drmkms_linux/Makefile P src/sys/modules/drmkms_pci/Makefile P src/sys/modules/drvctl/Makefile P src/sys/modules/dtrace/dtrace/Makefile P src/sys/modules/dtrace/fbt/Makefile P
Re: Automated report: NetBSD-current/i386 build failure
Sorry I forgot to commit a file outside sys/module.
Should be fixed now.
Thanks,
rin
On 2019/02/17 15:15, NetBSD Test Fixture wrote:
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
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: usr.bin/c++/t_cxxruntime:cxxruntime_pic_profile usr.bin/c++/t_static_destructor:static_destructor_pic_profile 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 412 revisions were committed, by the following developers: christos gutteridge hannken isaki jmcneill kamil kre martin maxv mgorny mrg nonaka rin rjs rmind tron wiz Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.02.html#2019.02.17.05.32.35
Re: job pipe read: no such process
Date:Sun, 17 Feb 2019 11:57:24 +0100 From:Thomas Klausner Message-ID: <20190217105724.b7itw2iebg2znhei@danbala> | I saw a new error today when building -current on 8.99.34/amd64: | job pipe read: No such process That's a weird one. The error is from make - and indicates that read() returned <0 with errno == ESRCH (this is in the code that handles -jN builds I think). Exactly what that error is supposed to indicate I have no idea, ESRCH isn't a defined error from read() and I can't even imagine what it might ever be used for. The most likely cause would seem to be that a signal was caught, and did something which changed errno to ESRCH just after a read from a pipe had failed (presumably for some other reason - and failed, not just pipe closed/EOF). If that was what it was, it is not likely to be anything you can reproduce. kre
Re: xhci power to external device
Rhialto writes: > I have an external harddisk, like so: (output from usbdevs -v) > > Controller /dev/usb0: > addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), vendor > 8086(0x8086), rev 1.00(0x0100) > port 1 addr 9: super speed, power 224 mA, config 1, Elements 25A1(0x25a1), > Western Digital(0x1058), rev 10.14(0x1014), serial > > I have some reason to believe it does nog get enough power from the > port. Is the "power 224 mA" how the current is actually limited? Or can > the device draw more without telling us? My impression is: USB ports and devices are limited to 500 mA, per the spec. (But, there are various schemes for USB chargers to communciate that they support more, so devices can be willing to draw more) what you are seeing is the device's declaration of how much power it will draw there is, very maybe, some notion that a computer will only enable a port if some power conditions are met, such as the total declared power of all enabled devices remains below some level believed to be what can in aggregate is supplied. But I'm not sure this exists. I have never heard of a port that can throttle what it supplies. I have definitely seen problems from trying to pull too much power in various ways. I don't have a good reason to believe all ports in any one computer will have exactly the same behavior. if you have an external disk that is USB powered, and it's flaky, you should get a powered hub
Re: xhci power to external device
On Sun 17 Feb 2019 at 21:34:44 +0100, Rhialto wrote: > I have an external harddisk, like so: (output from usbdevs -v) > > Controller /dev/usb0: > addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), vendor > 8086(0x8086), rev 1.00(0x0100) > port 1 addr 9: super speed, power 224 mA, config 1, Elements 25A1(0x25a1), > Western Digital(0x1058), rev 10.14(0x1014), serial To make things more interesting, I connected it to a laptop which has USB 2, not 3, and under Linux "lsusb -v" says bmAttributes 0x80 (Bus Powered) MaxPower 500mA On the same laptop, with NetBSD 8, also 500 mA: Controller /dev/usb7: addr 1: high speed, self powered, config 1, EHCI root hub(0x), vendor 8086(0x8086), rev 1.00(0x0100) port 1 addr 2: high speed, power 500 mA, config 1, Elements 25A1(0x25a1), Western Digital(0x1058), rev 10.14(0x1014), serial When I try the same on the original computer in a USB 2 port, I get the same result. On a MacBook (which does have USB 3), "System Information" says "Current Available (mA): 900" and "Current Required (mA): 896". And on a laptop with Linux and USB 3 ports, the same "224 mA" number is shown by lsusb -v. So there seems some confusion about the number, which supposedly is reported by the device and simply believed by the computer. So inspired by seeing "500 mA" on USB-2 ports, I plugged the disk into a USB-2 port on the original computer, and I don't see the symptoms (yet??) that made me think that there was a power problem. Can anyone shed some light on this? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
xhci power to external device
I have an external harddisk, like so: (output from usbdevs -v) Controller /dev/usb0: addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), vendor 8086(0x8086), rev 1.00(0x0100) port 1 addr 9: super speed, power 224 mA, config 1, Elements 25A1(0x25a1), Western Digital(0x1058), rev 10.14(0x1014), serial I have some reason to believe it does nog get enough power from the port. Is the "power 224 mA" how the current is actually limited? Or can the device draw more without telling us? For comparison, there is another device like so, which is a SD card reader: Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x), vendor 8086(0x8086), rev 1.00(0x0100) port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x0024), Intel(0x8087), rev 0.00(0x) ... port 6 addr 3: high speed, power 500 mA, config 1, USB Storage(0x0723), Generic(0x05e3), rev 94.51(0x9451) so at least some devices can draw that much. If the given 224 mA are actually enforced, can I give the disk more anyway? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: current fails to boot on VirtualBox
This *may* have relevance - with kernel from yesterday, lapic.c downgraded as above, the system can't boot multi-CPU under XCP-NG with HVM. With one CPU it happily works, with more - hangs at some stage during hardware discovery, with or without ACPI. I was hoping to use that particular XCP-NG guest to setup a dedicated build host, so wanted at least 4 CPUs... On Sun, 17 Feb 2019 at 17:33, Chavdar Ivanov wrote: > > I always have a few NewBSD guests under VirtualBox, I have never > disabled SVS so far. > > On Sun, 17 Feb 2019 at 09:20, Martin Husemann wrote: > > > > On Sun, Feb 17, 2019 at 09:23:41AM +0100, Adam wrote: > > > VirtualBox does not support SVS. > > > > I am not sure how to parse that - what part of Virtual Box would need > > to "support" the NetBSD guest kernel's SVS option? > > > > Martin > > > > -- > --
Re: current fails to boot on VirtualBox
I always have a few NewBSD guests under VirtualBox, I have never disabled SVS so far. On Sun, 17 Feb 2019 at 09:20, Martin Husemann wrote: > > On Sun, Feb 17, 2019 at 09:23:41AM +0100, Adam wrote: > > VirtualBox does not support SVS. > > I am not sure how to parse that - what part of Virtual Box would need > to "support" the NetBSD guest kernel's SVS option? > > Martin --
job pipe read: no such process
Hi! I saw a new error today when building -current on 8.99.34/amd64: #create nvi/ex_equal.d --- dependall-pdisk --- --- dependall --- --- dependall-mit --- --- dependall-misc --- rm -f 4x6.pcf.gz /usr/obj/src.amd64/external/mit/xorg/tools/bdftopcf/bdftopcf -t /usr/xsrc/external/mit/font-misc-misc/dist/4x6.bdf | gzip -n -9 -cf > 4x6.pcf.gz.tmp && mv 4x6.pcf.gz.tmp 4x6.pcf.gz job pipe read: No such process nbmake[11]: stopped in /usr/src/external/mit/xorg/share/fonts/misc/font-misc-misc *** [dependall] Error code 2 nbmake[10]: stopped in /usr/src/external/mit/xorg/share/fonts/misc/font-misc-misc 1 error nbmake[10]: stopped in /usr/src/external/mit/xorg/share/fonts/misc/font-misc-misc *** [dependall-font-misc-misc] Error code 2 nbmake[9]: stopped in /usr/src/external/mit/xorg/share/fonts/misc 1 error nbmake[9]: stopped in /usr/src/external/mit/xorg/share/fonts/misc *** [dependall-misc] Error code 2 nbmake[8]: stopped in /usr/src/external/mit/xorg/share/fonts --- dependall-bsd --- --- dependall-sys --- A failure has been detected in another branch of the parallel make I haven't tried reproducing it yet. Thomas
Re: current fails to boot on VirtualBox
On Sun, Feb 17, 2019 at 09:23:41AM +0100, Adam wrote: > VirtualBox does not support SVS. I am not sure how to parse that - what part of Virtual Box would need to "support" the NetBSD guest kernel's SVS option? Martin
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. VirtualBox does not support SVS. Apply this patch and try again. Kind regards, Adam --- conf/GENERIC15 Feb 2019 08:54:01 - 1.516 +++ conf/GENERIC17 Feb 2019 08:22:25 - @@ -74,7 +74,7 @@ optionsSYSCTL_INCLUDE_DESCR# Include sysctl descriptions in kernel # CPU-related options -optionsSVS # Separate Virtual Space +#options SVS # Separate Virtual Space makeoptionsSPECTRE_V2_GCC_MITIGATION=1 # GCC Spectre variant 2 # migitation optionsSPECTRE_V2_GCC_MITIGATION
