11.1-STABLE for amd64: jumping from -r326142 to -r327228: all_subdir_cxgbe/t4_firmware failed to build
This update spans the clang upgrade to 5.0.1 and ld is listed in _ERROR_CMD. But I've no direct evidence that these contributed. Cleaning out /usr/obj/amd64_clang/amd64.amd64/ and rebuilding instead of having an incremental build did not reproduce the problem. I provide the information anyway, in case others sometimes see similar examples. --- all_subdir_cxgbe/t4_firmware --- *** [t4fw_cfg.txt.fwo] Error code 1 make[5]: stopped in /usr/src/sys/modules/cxgbe/t4_firmware .ERROR_TARGET='t4fw_cfg.txt.fwo' .ERROR_META_FILE='/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC/modules/usr/src/sys/modules/cxgbe/t4_firmware/t4fw_cfg.txt.fwo.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='@echo t4fw_cfg.txt /usr/src/sys/dev/cxgbe/firmware/t4fw_cfg.txt; @if [ -e t4fw_cfg.txt ]; then ld -b binary --no-warn-mismatch -d -warn-common -m elf_x86_64_fbsd -r -d -o t4fw_cfg.txt.fwo t4fw_cfg.txt; else ln -s /usr/src/sys/dev/cxgbe/firmware/t4fw_cfg.txt t4fw_cfg.txt; ld -b binary --no-warn-mismatch -d -warn-common -m elf_x86_64_fbsd -r -d -o t4fw_cfg.txt.fwo t4fw_cfg.txt; rm t4fw_cfg.txt; fi;' .CURDIR='/usr/src/sys/modules/cxgbe/t4_firmware' .MAKE='make' .OBJDIR='/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC/modules/usr/src/sys/modules/cxgbe/t4_firmware' .TARGETS='all' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC/modules' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20170720' PATH='/usr/obj/amd64_clang/amd64.amd64/usr/src/tmp/legacy/usr/sbin:/usr/obj/amd64_clang/amd64.amd64/usr/src/tmp/legacy/usr/bin:/usr/obj/amd64_clang/amd64.amd64/usr/src/tmp/legacy/bin:/usr/obj/amd64_clang/amd64.amd64/usr/src/tmp/usr/sbin:/usr/obj/amd64_clang/amd64.amd64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC/modules/usr/src' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.amd64-clang.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/sys/modules/cxgbe/t4_firmware/Makefile /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/sys/conf/kern.mk' .PATH='. /usr/src/sys/modules/cxgbe/t4_firmware /usr/src/sys/dev/cxgbe/firmware /usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC' # less /usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC/modules/usr/src/sys/modules/cxgbe/t4_firmware/t4fw_cfg.txt.fwo.meta # Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC/modules/usr/src/sys/modules/cxgbe/t4_firmware/t4fw_cfg.txt.fwo.meta CMD @echo t4fw_cfg.txt /usr/src/sys/dev/cxgbe/firmware/t4fw_cfg.txt CMD @if [ -e t4fw_cfg.txt ]; thenld -b binary --no-warn-mismatch -d -warn-common -m elf_x86_64_fbsd -r -d -o t4fw_cfg.txt.fwo t4fw_cfg.txt; else ln -s /usr/src/sys/dev/cxgbe/firmware/t4fw_cfg.txt t4fw_cfg.txt; ld -b binary --no-warn-mismatch -d -warn-common -m elf_x86_64_fbsd -r -d -o t4fw_cfg.txt.fwo t4fw_cfg.txt; rm t4fw_cfg.txt; fi CWD /usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC/modules/usr/src/sys/modules/cxgbe/t4_firmware TARGET t4fw_cfg.txt.fwo -- command output -- t4fw_cfg.txt /usr/src/sys/dev/cxgbe/firmware/t4fw_cfg.txt *** Error code 1 -- filemon acquired metadata -- # filemon version 5 # Target pid 99801 # Start 1514338319.353476 V 5 E 99829 /bin/sh R 99829 /etc/libmap.conf R 99829 /var/run/ld-elf.so.hints R 99829 /lib/libedit.so.7 R 99829 /lib/libc.so.7 R 99829 /lib/libncursesw.so.8 F 99829 99831 E 99831 /bin/ln R 99831 /etc/libmap.conf R 99831 /var/run/ld-elf.so.hints R 99831 /lib/libc.so.7 L 99831 '/usr/src/sys/dev/cxgbe/firmware/t4fw_cfg.txt' 't4fw_cfg.txt' X 99831 0 0 F 99829 99835 E 99835 /usr/obj/amd64_clang/amd64.amd64/usr/src/tmp/usr/bin/ld D 99835 t4fw_cfg.txt.fwo R 99835 t4fw_cfg.txt.fwo W 99835 t4fw_cfg.txt.fwo R 99835 t4fw_cfg.txt X 99835 1 0 X 99829 1 0 # Stop 1514338319.363473 # Bye bye The "L 99831 '/usr/src/sys/dev/cxgbe/firmware/t4fw_cfg.txt'
Re: idprio(1) broken
On 26.12.2017 18:37, Andriy Gapon wrote: >>> Is idprio(1) broken in stable/11? >>> >>> As root, start one bzip2 instance with idprio and one additional bzip2 >>> intance per CPU core: >>> >>> # idprio 5 bzip2 -9 /dev/null & >>> # n=$(sysctl -n kern.smp.cpus) >>> # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & >>> i=$(($i+1)); done >>> # top >>> >>> For dual core system, I see that idprio'd bzip2 takes all cycles of first >>> core >>> and two "normal" bzip2's share cycles of second core each taking ~50% of >>> CPU time. >>> >>> It is expected that idprio'd bzip2 get no CPU time at all and each of >>> "normal" bzip2's >>> get ~100% of single CPU core for such setup. >> >> This works as expected for stable/10. > > Seems to work as expected on head as well. I have a report that head r323607 has the problem and head r326729 has not. I can't check it myself as I have do not run head yet. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: idprio(1) broken
On 26/12/2017 11:18, Eugene Grosbein wrote: > On 26.12.2017 16:10, Eugene Grosbein wrote: > >> Is idprio(1) broken in stable/11? >> >> As root, start one bzip2 instance with idprio and one additional bzip2 >> intance per CPU core: >> >> # idprio 5 bzip2 -9 /dev/null & >> # n=$(sysctl -n kern.smp.cpus) >> # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & i=$(($i+1)); >> done >> # top >> >> For dual core system, I see that idprio'd bzip2 takes all cycles of first >> core >> and two "normal" bzip2's share cycles of second core each taking ~50% of CPU >> time. >> >> It is expected that idprio'd bzip2 get no CPU time at all and each of >> "normal" bzip2's >> get ~100% of single CPU core for such setup. > > This works as expected for stable/10. Seems to work as expected on head as well. Tested on a 6-core physical system and a 2-core bhyve VM. # ps axwwl | fgrep bzip2 0 943 935 0 129 5 10564 2196 -RN1 0:00.00 idprio 5 bzip2 -9 0 945 935 0 108 5 18332 9676 -RN1 1:16.15 bzip2 -9 0 946 935 0 108 5 18332 9676 -RN1 1:16.34 bzip2 -9 idprio isn't even able to exec bzip2. # ps axwwl | fgrep bzip2 0 28986 86816 0 129 5 183482324 -RN 17 0:00.02 bzip2 -9 0 28988 86816 0 106 5 183489680 -RN 17 1:27.25 bzip2 -9 0 28989 86816 0 106 5 183489680 -RN 17 1:27.86 bzip2 -9 0 28990 86816 0 108 5 183489680 -RN 17 1:35.50 bzip2 -9 0 28991 86816 0 106 5 183489680 -RN 17 1:27.00 bzip2 -9 0 28992 86816 0 106 5 183489680 -RN 17 1:25.83 bzip2 -9 0 28993 86816 0 106 5 183489680 -RN 17 1:26.76 bzip2 -9 -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: idprio(1) broken
On 26.12.2017 16:10, Eugene Grosbein wrote: > Is idprio(1) broken in stable/11? > > As root, start one bzip2 instance with idprio and one additional bzip2 > intance per CPU core: > > # idprio 5 bzip2 -9 /dev/null & > # n=$(sysctl -n kern.smp.cpus) > # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & i=$(($i+1)); > done > # top > > For dual core system, I see that idprio'd bzip2 takes all cycles of first core > and two "normal" bzip2's share cycles of second core each taking ~50% of CPU > time. > > It is expected that idprio'd bzip2 get no CPU time at all and each of > "normal" bzip2's > get ~100% of single CPU core for such setup. This works as expected for stable/10. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
idprio(1) broken
Hi! Is idprio(1) broken in stable/11? As root, start one bzip2 instance with idprio and one additional bzip2 intance per CPU core: # idprio 5 bzip2 -9 /dev/null & # n=$(sysctl -n kern.smp.cpus) # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & i=$(($i+1)); done # top For dual core system, I see that idprio'd bzip2 takes all cycles of first core and two "normal" bzip2's share cycles of second core each taking ~50% of CPU time. It is expected that idprio'd bzip2 get no CPU time at all and each of "normal" bzip2's get ~100% of single CPU core for such setup. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
