Re: make warning: ?: No such file or directory.
> On May 9, 2017, at 21:37, O. Hartmann wrote: > > On recent CURRENT, the source tree /usr/src seems to have issues on some of my > boxes and whenever I issue "make build", the message: > > make warning: �: No such file or directory. > > pops up. "svn st" doesn't reveal anything wrong. > > My locale settings are: > > LANG= > LC_CTYPE="C" > LC_COLLATE="C" > LC_TIME="C" > LC_NUMERIC="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_ALL= > > (just for the record). Those spooky non-printables are seen on xterm(s) of > various other systems (11.0, 11-STABLE, 12-CURRENT) when connecting to the > systems in question. > > What is this? > > Kind regards and thanks in advance, I see similar oddness when running some commands. It seems to be happening as of the last month or two. Thanks, -Ngie $ make buildenv TARGET_ARCH=armv6 make warning: I: No such file or directory. make warning: I: No such file or directory. Entering world for armv6:arm $ signature.asc Description: Message signed with OpenPGP using GPGMail
make warning: ?: No such file or directory.
On recent CURRENT, the source tree /usr/src seems to have issues on some of my boxes and whenever I issue "make build", the message: make warning: �: No such file or directory. pops up. "svn st" doesn't reveal anything wrong. My locale settings are: LANG= LC_CTYPE="C" LC_COLLATE="C" LC_TIME="C" LC_NUMERIC="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= (just for the record). Those spooky non-printables are seen on xterm(s) of various other systems (11.0, 11-STABLE, 12-CURRENT) when connecting to the systems in question. What is this? Kind regards and thanks in advance, oh ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
TARGET_ARCH=powerpc head -r317820 production-style kernel: periodic panics always in pid=11 (the Idle threads)
kgdb is not working for powerpc, neither system nor ports. I've used "strings" to extract the later information below about the failures. The time frames to failure are widely variable, minutes to hours. I've never seen the below with a debug kernel, only with production-style. I have not seen any such problems for powerpc64, aarch64 (with -mcpu=cortex-a53 ), armv6 (with -mcpu=cortex-a7 ), or amd64. Just powerpc. The powerpc and powerpc64 hardware is (e.g.) the same old PowerMac G5 so-called "Quad Core" used with two different boot SSDs. Note: This reproduces for me for pure gcc 4.2.1 based builds. My usual clang-targetting- powerpc experiments are not involved here. I'd not updated for a long time before this due to the status of the clang compiler not changing and its powerpc stack code-generation problems being difficult to work around. My kernels are unusual by having both sc and vt in the build and ps3 disabled. I happen to be using sc because it works with the 2560x1440 display that is currently connected but with vt it fails to boot for such a size. Of 7 example vmcore.* files. . . (Note that all are pid 11 Idle-process thread failures) 3 contain: fatal kernel trap: exception = 0x903a64e (unknown) srr0= 0x7ff760 srr1= 0xc1007c lr = 0x907f curthread = 0x147d6c0 pid = 11, comm = idle: cpu0 [ thread pid 11 tid 13 ] Stopped at ffs_truncate+0x1080:stw r11, 0xf8(r31) 1 contains (cpu1 instead of cpu0, so different tid): fatal kernel trap: exception = 0x903a64e (unknown) srr0= 0x7ff760 srr1= 0xc1007c lr = 0x907f curthread = 0x147d360 pid = 11, comm = idle: cpu1 [ thread pid 11 tid 14 ] Stopped at ffs_truncate+0x1080:stw r11, 0xf8(r31) 1 contains: fatal kernel trap: exception = 0x2100 (unknown) srr0= 0x7c0903 srr1= 0xa64e8004 lr = 0x807fc9e7 curthread = 0x147d000 pid = 11, comm = idle: cpu2 [ thread pid 11 tid 15 ] Stopped at audit_commit+0x24f: illegal instruction 4915f00 1 contains: fatal kernel trap: exception = 0x300 (data storage interrupt) virtual address = 0x7ff76000 dsisr = 0x4000 srr0= 0x8e3cf8 srr1= 0x1032 lr = 0x8e3ce8 curthread = 0x147d6c0 pid = 11, comm = idle: cpu0 panic: data storage interrupt trap cpuid = 0 time = 1494057319 KDB: stack backtrace: 0xdf5e52c0: at kdb_backtrace+0x5c 0xdf5e5330: at vpanic+0x1ec 0xdf5e53a0: at panic+0x54 0xdf5e53f0: at trap_fatal+0x1cc 0xdf5e5420: at trap+0x122c 0xdf5e55c0: at powerpc_interrupt+0x180 0xdf5e55f0: kernel DSI read trap @ 0x7ff76000 by db_disasm+0x30: srr1=0x1032 r1=0xdf5e56b0 cr=0x24009022 xer=0 ctr=0x1852cc sr=0x4000 0xdf5e56b0: at 0x1007460 0xdf5e56d0: at db_print_loc_and_inst+0x60 0xdf5e5700: at db_trap+0x104 0xdf5e5790: at kdb_trap+0x1bc 0xdf5e5810: at trap_fatal+0x1b0 0xdf5e5840: at trap+0x1184 0xdf5e5870: kernel DECR trap by cpu_idle_60x+0x88: srr1=0x9032 r1=0xdf5e5930 cr=0x4042 xer=0x2000 ctr=0x8e3bd8 saved LR(0xfffe) is invalid And 1 contains: fatal kernel trap: exception = 0x0 (unknown) srr0= 0x903a64e srr1= 0x80042100 lr = 0xc9e7c800 curthread = 0x147d360 pid = 11, comm = idle: cpu1 [ thread pid 11 tid 14 ] Stopped at 0x903a64e: fatal kernel trap: exception = 0x300 (data storage interrupt) virtual address = 0x903a64e dsisr = 0x4000 srr0= 0x8e3cf8 srr1= 0x1032 lr = 0x8e3ce8 curthread = 0x147d360 pid = 11, comm = idle: cpu1 panic: data storage interrupt trap cpuid = 1 time = 1494132014 KDB: stack backtrace: 0xdf5ea2c0: at kdb_backtrace+0x5c 0xdf5ea330: at vpanic+0x1ec 0xdf5ea3a0: at panic+0x54 0xdf5ea3f0: at trap_fatal+0x1cc 0xdf5ea420: at trap+0x122c 0xdf5ea5c0: at powerpc_interrupt+0x180 0xdf5ea5f0: kernel DSI read trap @ 0x903a64e by db_disasm+0x30: srr1=0x1032 r1=0xdf5ea6b0 cr=0x24009022 xer=0 ctr=0x1852cc sr=0x4000 0xdf5ea6b0: at 0x1007460 0xdf5ea6d0: at db_print_loc_and_inst+0x60 0xdf5ea700: at db_trap+0x104 0xdf5ea790: at kdb_trap+0x1bc 0xdf5ea810: at trap_fatal+0x1b0 0xdf5ea840: at trap+0x122c 0xdf5ea870: kernel EXI trap by cpu_idle_60x+0x88: srr1=0x9032 r1=0xdf5ea930 cr=0x4042 xer=0x2000 ctr=0x8e3bd8 saved LR(0x5) is invalid Most (but not all) of the above were while the old PowerMac was sitting unused. The pid 11 Idle thread commonality suggests to me some sort of interrupt oddity messing up when the idle threads were put to use for the interrupt. The /usr/src/sys/powerpc/conf/* files in use are (-NODBG for production style and -DBG for debug style): # more /usr/src/sys/powerpc/c
A head -r317820 incremental buildworld race: kvm_geterr_test failures for -j16 but works without -j
I've had reason to be experimenting with libkvm recently
and have repeatedly run into the following when doing
buildworld with -j16. (I tend to run full buildworlds even
for well-localized changes.) The context is having run
buildworld to completion before so the update is
incremental.
--- kvm_geterr_test ---
kvm_geterr_test.o: In function `atfu_kvm_geterr_negative_test_NULL_body':
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:56: undefined reference to
`errbuf_has_error'
kvm_geterr_test.o: In function `atfu_kvm_geterr_positive_test_no_error_body':
. . .
--- kvm_geterr_test ---
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:108: undefined reference to
`errbuf_clear'
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:109: undefined reference to `errbuf'
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:109: undefined reference to `errbuf'
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:110: undefined reference to
`errbuf_has_error'
kvm_geterr_test.o: In function `atfu_kvm_geterr_positive_test_error_body':
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:73: undefined reference to
`errbuf_clear'
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:74: undefined reference to `errbuf'
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:74: undefined reference to `errbuf'
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:75: undefined reference to
`errbuf_has_error'
/usr/src/lib/libkvm/tests/kvm_geterr_test.c:80: undefined reference to
`errbuf_has_error'
By contrast if I omit -j completely the incremental
buildworld runs to completion just fine. (rm -rf of the
past buildworld and so building from scratch also works.)
The context for my activity happens to use:
# more
~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_gcc421_bootstrap_clang-amd64-host.sh
kldload -n filemon && \
script
~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_gcc421_bootstrap_clang-amd64-host-$(date
+%Y-%m-%d:%H:%M:%S) \
env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null"
SRC_ENV_CONF="/root/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.amd64-host"
\
WITH_META_MODE=yes \
MAKEOBJDIRPREFIX="/usr/obj/powerpcvtsc_clang_gcc421" \
make $*
# more /root/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.amd64-host
TO_TYPE=powerpc
#
KERNCONF=GENERICvtsc-NODBG
TARGET=${TO_TYPE}
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITHOUT_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
WITHOUT_CLANG=
WITHOUT_CLANG_IS_CC=
WITHOUT_CLANG_FULL=
WITHOUT_CLANG_EXTRAS=
WITHOUT_LLD=
WITHOUT_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITH_GCC_BOOTSTRAP=
WITH_GCC=
WITH_GCC_IS_CC=
WITH_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A head -r317820 incremental buildworld race: kvm_geterr_test failures for -j16 but works without -j
On 5/9/2017 11:10 AM, Mark Millard wrote: > I've had reason to be experimenting with libkvm recently > and have repeatedly run into the following when doing > buildworld with -j16. (I tend to run full buildworlds even > for well-localized changes.) The context is having run > buildworld to completion before so the update is > incremental. > > --- kvm_geterr_test --- > kvm_geterr_test.o: In function `atfu_kvm_geterr_negative_test_NULL_body': > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:56: undefined reference to > `errbuf_has_error' > kvm_geterr_test.o: In function `atfu_kvm_geterr_positive_test_no_error_body': > . . . > --- kvm_geterr_test --- > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:108: undefined reference to > `errbuf_clear' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:109: undefined reference to > `errbuf' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:109: undefined reference to > `errbuf' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:110: undefined reference to > `errbuf_has_error' > kvm_geterr_test.o: In function `atfu_kvm_geterr_positive_test_error_body': > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:73: undefined reference to > `errbuf_clear' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:74: undefined reference to > `errbuf' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:74: undefined reference to > `errbuf' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:75: undefined reference to > `errbuf_has_error' > /usr/src/lib/libkvm/tests/kvm_geterr_test.c:80: undefined reference to > `errbuf_has_error' > > By contrast if I omit -j completely the incremental > buildworld runs to completion just fine. (rm -rf of the > past buildworld and so building from scratch also works.) > > The context for my activity happens to use: > > # more > ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_gcc421_bootstrap_clang-amd64-host.sh > > kldload -n filemon && \ > script > ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_gcc421_bootstrap_clang-amd64-host-$(date > +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" > SRC_ENV_CONF="/root/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.amd64-host" > \ > WITH_META_MODE=yes \ Thanks for the report. Fixed in r318092. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ?
On Tue, May 09, 2017 at 12:07:47PM +0200, Henri Hennebert wrote: > Hello, > > I build current -r317181 with crochet for my PINE64. > > the kernel can boot with loader.conf.local: > > geom_mirror_load="YES" > > If I add to loader.conf.local: > > zfs_load="YES" > > or if I strike the space bar during loader.efi and I load zfs manually: > > OK load zfs > ... > OK boot > > the kernel don't boot and the console stay with the last line: > > Using DTB provided by EFI at 0x4900. > > Moreover the opensolaris.ko is not loader. > > Maybe DTB is smashed by zfs.ko > > Any idea ? I see the same symptom with root-on-ZFS with my SoftIron OverDrive 1000. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ?
Hello, I build current -r317181 with crochet for my PINE64. the kernel can boot with loader.conf.local: geom_mirror_load="YES" If I add to loader.conf.local: zfs_load="YES" or if I strike the space bar during loader.efi and I load zfs manually: OK load zfs ... OK boot the kernel don't boot and the console stay with the last line: Using DTB provided by EFI at 0x4900. Moreover the opensolaris.ko is not loader. Maybe DTB is smashed by zfs.ko Any idea ? Henri PS with r312006M from RaspBSD all is OK and I can user zfs as root filesystem. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
