Re: 13 stable build fail
Is this the same as: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256947 ? mcl
13 stable build fail
... In file included from /usr/src/lib/libc/gen/fstab.c:38: In file included from /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38: /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal error: 'bsm/audit.h' file not found #include ^ 1 error generated. --- fstab.o --- *** [fstab.o] Error code 1 make[4]: stopped in /usr/src/lib/libc In file included from /usr/src/lib/libc/gen/fts.c:40: In file included from /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38: /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal error: 'bsm/audit.h' file not found #include ^ In file included from /usr/src/lib/libc/gen/fts-compat.c:41: In file included from /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38: /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal error: 'bsm/audit.h' file not found #include ^ 1 error generated. --- fts.o --- *** [fts.o] Error code 1 make[4]: stopped in /usr/src/lib/libc ...
Re: I got a panic for "nvme0: cpl does not map to outstanding cmd" on a MACHIATObin Double Shot
On 2021-Jul-2, at 08:38, Chuck Tuffli wrote: > On Thu, Jun 24, 2021 at 11:50 PM Mark Millard via freebsd-current > wrote: >> >> I've given up on figuring any useful out for this example. >> I've also not had a repeat so far. >> >> I'm progressing to much more recent commits for the >> environment to be based on as well. >> >> The primary aarch64 system for my access is switching to >> be a HoneyComb. The Optane was moved to the HoneyComb. > > Since the architecture isn't x86, I'm wondering if what you are seeing > is related to the changes being proposed in these Differentials: > https://reviews.freebsd.org/D30995 > https://reviews.freebsd.org/D31002 > Interesting. But I've never had a repeat so I do not seem to have a context that makes for a useful comparison/contrast test case. Thanks for the note. I'll watch for what is committed and update afterwards just in hopes that it is sufficient for my context. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: I got a panic for "nvme0: cpl does not map to outstanding cmd" on a MACHIATObin Double Shot
On Thu, Jun 24, 2021 at 11:50 PM Mark Millard via freebsd-current wrote: > > I've given up on figuring any useful out for this example. > I've also not had a repeat so far. > > I'm progressing to much more recent commits for the > environment to be based on as well. > > The primary aarch64 system for my access is switching to > be a HoneyComb. The Optane was moved to the HoneyComb. Since the architecture isn't x86, I'm wondering if what you are seeing is related to the changes being proposed in these Differentials: https://reviews.freebsd.org/D30995 https://reviews.freebsd.org/D31002 --chuck
Re: Changes to backtrace() ??
On Fri, Jul 2, 2021, 4:35 AM Willem Jan Withagen via freebsd-current < freebsd-current@freebsd.org> wrote: > On 2-7-2021 12:17, Tobias Kortkamp wrote: > > On Fri, Jul 02, 2021 at 11:52:14AM +0200, Willem Jan Withagen via > freebsd-current wrote: > >> Hi, > >> > >> Have there been changes in the backtrace() calls? > >> I recently upgraded my current server, and now the Ceph backtrace test > >> starts to fail > >> > >> It looks like it is implemented in the llvm code. > >> So it could be that something is off in that code. > > lang/rust also fails to build on at least aarch64 after the LLVM12 > > import (the prebuilt bootstrap crashes). Very similar backtrace. > > See https://bugs.freebsd.org/256864 > Yup, > That trace looks very similar. > > Forgot to explicitly mention that my problem is with a very recent 14.0 > FreeBSD quad-b.digiware.nl 14.0-CURRENT FreeBSD 14.0-CURRENT #1 > main-n247587-33b8c039a96: Sun Jun 27 21:19:03 CEST 2021 > r...@quad-b.digiware.nl:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > amd64 > That is after the last LLVM import. I've cc'd dim@. Warner The one before that was from around early May, and that did not have the > problem... > I have a Jenkins builder/tester that checks all changes that get submitted. > And only after the upgrade last weekend things started to go wrong. > > But I do not track changes to current so I have no clue as to what has > changed there. > > --WjW > > >
Re: Changes to backtrace() ??
On 2-7-2021 12:17, Tobias Kortkamp wrote: On Fri, Jul 02, 2021 at 11:52:14AM +0200, Willem Jan Withagen via freebsd-current wrote: Hi, Have there been changes in the backtrace() calls? I recently upgraded my current server, and now the Ceph backtrace test starts to fail It looks like it is implemented in the llvm code. So it could be that something is off in that code. lang/rust also fails to build on at least aarch64 after the LLVM12 import (the prebuilt bootstrap crashes). Very similar backtrace. See https://bugs.freebsd.org/256864 Yup, That trace looks very similar. Forgot to explicitly mention that my problem is with a very recent 14.0 FreeBSD quad-b.digiware.nl 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n247587-33b8c039a96: Sun Jun 27 21:19:03 CEST 2021 r...@quad-b.digiware.nl:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 The one before that was from around early May, and that did not have the problem... I have a Jenkins builder/tester that checks all changes that get submitted. And only after the upgrade last weekend things started to go wrong. But I do not track changes to current so I have no clue as to what has changed there. --WjW
Re: Changes to backtrace() ??
On Fri, Jul 02, 2021 at 11:52:14AM +0200, Willem Jan Withagen via freebsd-current wrote: > Hi, > > Have there been changes in the backtrace() calls? > I recently upgraded my current server, and now the Ceph backtrace test > starts to fail > > It looks like it is implemented in the llvm code. > So it could be that something is off in that code. lang/rust also fails to build on at least aarch64 after the LLVM12 import (the prebuilt bootstrap crashes). Very similar backtrace. See https://bugs.freebsd.org/256864 signature.asc Description: PGP signature
Changes to backtrace() ??
Hi, Have there been changes in the backtrace() calls? I recently upgraded my current server, and now the Ceph backtrace test starts to fail It looks like it is implemented in the llvm code. So it could be that something is off in that code. --WjW Program terminated with signal SIGSEGV, Segmentation fault. #0 libunwind::LocalAddressSpace::get32 (this=0x80b144828 , addr=408197395) at /usr/src/contrib/llvm-project/libunwind/src/AddressSpace.hpp:164 164 memcpy(, (void *)addr, sizeof(val)); (gdb) bt #0 libunwind::LocalAddressSpace::get32 (this=0x80b144828 , addr=408197395) at /usr/src/contrib/llvm-project/libunwind/src/AddressSpace.hpp:164 #1 libunwind::CFI_Parser::findFDE (addressSpace=..., pc=pc@entry=4578143, ehSectionStart=5219072, sectionLength=, fdeHint=, fdeHint@entry=0, fdeInfo=fdeInfo@entry=0x7fffd7a0, cieInfo=0x7fffd768) at /usr/src/contrib/llvm-project/libunwind/src/DwarfParser.hpp:233 #2 0x00080b141091 in libunwind::UnwindCursorlibunwind::Registers_x86_64>::getInfoFromDwarfSection ( this=this@entry=0x7fffdde0, pc=pc@entry=4578143, sects=..., fdeSectionOffsetHint=fdeSectionOffsetHint@entry=0) at /usr/src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:1566 #3 0x00080b13db40 in libunwind::UnwindCursorlibunwind::Registers_x86_64>::setInfoBasedOnIPRegister ( this=0x7fffdde0, isReturnAddress=true) at /usr/src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:1958 #4 0x00080b13d99b in libunwind::UnwindCursorlibunwind::Registers_x86_64>::step (this=0x7fffdde0) at /usr/src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:2103 #5 0x00080b13b345 in _Unwind_Backtrace (callback=0x80ace5fe0 , ref=0x7fffdf78) at /usr/src/contrib/llvm-project/libunwind/src/UnwindLevel1-gcc-ext.c:131 #6 0x00080ace5fa7 in backtrace (arr=, len=out>) at /usr/src/contrib/libexecinfo/unwind.c:69 #7 0x0045e698 in ceph::BackTrace::BackTrace(int) () #8 0x0045dd94 in foo() () #9 0x0045dfc8 in BackTrace_Basic_Test::TestBody() () #10 0x004ddaeb in void testing::internal::HandleSehExceptionsInMethodIfSupportedvoid>(testing::Test*, void (testing::Test::*)(), char const*) () #11 0x004c468a in void testing::internal::HandleExceptionsInMethodIfSupportedvoid>(testing::Test*, void (testing::Test::*)(), char const*) () #12 0x004a7d43 in testing::Test::Run() () #13 0x004a88f4 in testing::TestInfo::Run() () #14 0x004a8efb in testing::TestSuite::Run() () #15 0x004b44ca in testing::internal::UnitTestImpl::RunAllTests() () #16 0x004e220b in bool testing::internal::HandleSehExceptionsInMethodIfSupportedbool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) () #17 0x004c6a9a in bool testing::internal::HandleExceptionsInMethodIfSupportedbool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) () #18 0x004b408e in testing::UnitTest::Run() () #19 0x004850f1 in RUN_ALL_TESTS() () #20 0x004850cb in main ()
etcupdate: Failed to build new tree
Hello, Last update I have some issues with etcupdate: etcupdate warning: "No previous tree to compare against, a sane comparison is not possible." That I corrected with: etcupdate extract etcupdate diff > /tmp/etc.diff patch -R < /tmp/etc.diff (etcupdate diff doesn't show any diffs.) Today I've just updated current and etcupdate -p gives: "Failed to build new tree" What might be wrong? Thanks Nuno Teixeira
