Re: immediate reboot
On Fri, 1 May 2020 at 08:54, Thomas Klausner wrote: > > Hi! > > With an amd64 kernel from about 12 hours ago I get an immediate reboot > after the boot prompt has decided it wants to load the kernel. > > I.e. I don't even see the numbers going up when the sections are loaded. $ date Fri May 1 09:04:40 BST 2020 $ uname -a NetBSD ymir 9.99.59 NetBSD 9.99.59 (GENERIC) #15: Fri May 1 03:47:43 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 Mine is from 6 hours ago and works fine. > Thomas Chavdar --
Re: firefox build broken
On Fri, 1 May 2020 at 18:46, Thomas Klausner wrote: > > Could it be because I have a userland built with MKLLVM=yes? I don't have it, to the best of my knowledge. If it is of any help, I have PKG_OPTIONS.llvm += -llvm-target-aarch64 -llvm-target-arm -llvm-target-bpf -llvm-target-hexagon -llvm-target-lanai -llvm-target-mips -llvm-target-msp430 -llvm-target-nvptx -llvm-target-powerpc -llvm-target-sparc -llvm-target-systemz PKG_OPTIONS.rust+= rust-llvm in my /etc/mk.conf . > Thomas --
KASLR kernel fails to boot
Hi, netbsd-GENERIC_KASLR from yesterday fails to pass the prekern stage with a frightening message in red 'Page fault'. I've never seen this before, no idea if I can get any further info. This machine has been otherwise running KASLR kernel for some four months now without a problem; it is a VirtualBox guest. Chavdar --
Re: lang/mono6 fails build under -current
On Tue, 12 May 2020 at 14:03, wrote: > > On Mon, May 11, 2020 at 05:25:03PM +0100, Chavdar Ivanov wrote: > > Has anybody been able to build lang/mono6 under reasonably recent > > -current? I keep getting exciting crashes in various places, seem not > > to repeat, e.g. > > > I can build it. > > Setup: > userland: 9.99.51 (early March) > kernel: 9.99.59 (early May) Userland and kernel from yesterday, 11th of May > > GCC 8.4.0 Ditto > binutils 2.31.1 As far as I can see it, on this version of the system it is 2.34: nm -V GNU nm (NetBSD Binutils nb1) 2.34. I never run kernel and userland from different versions, as I use sysbuild and sysupgrade. > > Bare metal on a Ryzen 2700X. --
Re: lang/mono6 fails build under -current
On Fri, 15 May 2020 at 22:44, wrote: > > On Tue, May 12, 2020 at 02:41:19PM +0100, Chavdar Ivanov wrote: > > On Tue, 12 May 2020 at 14:03, wrote: > > > > > > On Mon, May 11, 2020 at 05:25:03PM +0100, Chavdar Ivanov wrote: > > > > Has anybody been able to build lang/mono6 under reasonably recent > > > > -current? I keep getting exciting crashes in various places, seem not > > > > to repeat, e.g. > > > > > > > > > I can build it. > > > > > > Setup: > > > userland: 9.99.51 (early March) > > > kernel: 9.99.59 (early May) > > > > Userland and kernel from yesterday, 11th of May > > > > > > GCC 8.4.0 > > > > Ditto > > > > > binutils 2.31.1 > > > > As far as I can see it, on this version of the system it is 2.34: > > > > nm -V > > GNU nm (NetBSD Binutils nb1) 2.34. > > > > I never run kernel and userland from different versions, as I use > > sysbuild and sysupgrade. > > I am failing to reproduce it on 9.99.61. Any other guesses for what > might be different on your setup? No idea. It is a laptop with i7-3820QM CPU and 20GB memory, following -current, both the OS and pkgsrc, with many pkg_rolling-replace under its belt. Perhaps it is time to reinstall it... I spun a new VM (XCP-NG pvhvm domU, with just 4 virtual CPUs and 2GB memory), extracted and updated pkgsrc as of yesterday, mono6 built fine and I was then able to install the package on the troubled system: $ mono --version Mono JIT compiler version 6.8.0.105 (tarball Sat May 16 22:47:11 BST 2020) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: normal Notification: kqueue Architecture: amd64 Disabled: none Misc: softdebug Interpreter: yes LLVM: supported, not enabled. Suspend: preemptive GC:sgen (concurrent by default) The thing is, while pkg_rolling-replace does simplify the gradual updates of packages, there are situations it can't deal with; e.g. 4-5 days ago I updated and ran pkg_rolling-replace, which completed rather well, with only about 10 packages failing due to being obsoleted etc.; all the tex packages I have installed upgraded without a problem. Yesterday I did another update, this time rolling-replace rendered hundreds of failed upgrades among the tex packages. The reason (one of the reasons) turned out to be a new version of kpathsea - 6.3.2 - which now depends on mktexlsr package; this one has been split from kpathsea and contains a file - well, mktexlsr - which is also part of kpathsea-6.3.1; so mktexlsr can't be installed over kpathsea, and kpathsea can't be upgraded as mktexlsr is missing... And this was not the only problem. --
Re: KASLR kernel fails to boot
On Mon, 4 May 2020 at 21:21, Chavdar Ivanov wrote: > > Hi, > > netbsd-GENERIC_KASLR from yesterday fails to pass the prekern stage > with a frightening message in red 'Page fault'. I've never seen this > before, no idea if I can get any further info. > > This machine has been otherwise running KASLR kernel for some four > months now without a problem; it is a VirtualBox guest. Same with just completed clean buid of 9.99.60. After "[+] Rel relocations applied" I get: ** Fault occurred ** page fault ** I switched th vm to the normal kernel, no problem otherwise. > > Chavdar > > -- > --
Re: pkgtools/pkgin 0.16.1 fails build under -current
On Sun, 10 May 2020 at 23:41, Chavdar Ivanov wrote: > > Hi, > > I get: > ... Same happens with multimedia/libmp4v2, but for this one needs also -Wno-stringop-truncation . > # compile pkgin-0.16.1/tools.o > gcc -O2 -I/usr/include -I/usr/pkg/include -fPIE-std=gnu99 > -Werror-DHAVE_NBCOMPAT_H=1 > -I/usr/pkgsrc/pkgtools/pkgin/work/libnbcompat -I/usr/include > -I/usr/pkg/include -DPKGIN_VERSION=\""0.16.1 for NetB > SD-9.99.60 x86_64"\" -DHAVE_NBCOMPAT_H=1 > -I/usr/pkgsrc/pkgtools/pkgin/work/libnbcompat -I/usr/include > -I/usr/pkg/include -g -DLOCALBASE=\"/usr/pkg\" > -DPKG_SYSCONFDIR=\"/usr/pkg/etc\" > -DPKGIN_DBDIR=\"/var/db/pkgin\" > -DPKGTOOLS=\"/usr/pkg/sbin\" -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE > -D_LARGE_FILES -DCHECK_MACHINE_ARCH=\"x86_64\" -I. -I/usr/pkg/include > -ctools.c > tools.c: In function 'strreplace': > tools.c:170:4: error: 'strncat' specified bound depends on the length > of the source argument [-Werror=stringop-overflow=] > strncat(buf, to, tolen); > ^~~ > tools.c:166:10: note: length computed here > tolen = strlen(to); > ^~ > cc1: all warnings being treated as errors > *** Error code 1 > > For lack of understanding, adding > > CFLAGS+= -Wno-stringop-overflow > > to the Makefile completes the build, but probably is not the right thing to > do. > > Chavdar > > > -- > --
pkgtools/pkgin 0.16.1 fails build under -current
Hi, I get: ... # compile pkgin-0.16.1/tools.o gcc -O2 -I/usr/include -I/usr/pkg/include -fPIE-std=gnu99 -Werror-DHAVE_NBCOMPAT_H=1 -I/usr/pkgsrc/pkgtools/pkgin/work/libnbcompat -I/usr/include -I/usr/pkg/include -DPKGIN_VERSION=\""0.16.1 for NetB SD-9.99.60 x86_64"\" -DHAVE_NBCOMPAT_H=1 -I/usr/pkgsrc/pkgtools/pkgin/work/libnbcompat -I/usr/include -I/usr/pkg/include -g -DLOCALBASE=\"/usr/pkg\" -DPKG_SYSCONFDIR=\"/usr/pkg/etc\" -DPKGIN_DBDIR=\"/var/db/pkgin\" -DPKGTOOLS=\"/usr/pkg/sbin\" -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE -D_LARGE_FILES -DCHECK_MACHINE_ARCH=\"x86_64\" -I. -I/usr/pkg/include -ctools.c tools.c: In function 'strreplace': tools.c:170:4: error: 'strncat' specified bound depends on the length of the source argument [-Werror=stringop-overflow=] strncat(buf, to, tolen); ^~~ tools.c:166:10: note: length computed here tolen = strlen(to); ^~ cc1: all warnings being treated as errors *** Error code 1 For lack of understanding, adding CFLAGS+= -Wno-stringop-overflow to the Makefile completes the build, but probably is not the right thing to do. Chavdar --
Re: lang/mono6 fails build under -current
Has anybody been able to build lang/mono6 under reasonably recent -current? I keep getting exciting crashes in various places, seem not to repeat, e.g. ... gmake[9]: Entering directory '/usr/pkgsrc/lang/mono6/work/mono-6.8.0.105/mcs/class/Facades/System.Linq' /usr/pkg/bin/gmake all-local gmake[10]: Entering directory '/usr/pkgsrc/lang/mono6/work/mono-6.8.0.105/mcs/class/Facades/System.Linq' cat <./../../../build/deps/unix_build_Facades_System.Linq.dll.sources >../../../build/deps/unix_build_Facades_System.Linq.dll.response mono /usr/pkgsrc/lang/mono6/work/mono-6.8.0.105/external/roslyn-binaries/Microsoft.Net.Compilers/3.5.0/csc.exe /shared:monomake /codepage:65001 /nologo /noconfig /deterministic -d:NET_4_0 -d:NET_4_5 -d:MONO -d :WIN_PLATFORM -d:BOOTSTRAP_BASIC -nowarn:1699 -nostdlib -optimize /features:peverify-compat /langversion:latest /delaysign /nowarn:1616,1699 -r:./../../../class/lib/build-unix/System.Core.dll -r:./../../../clas s/lib/build-unix/mscorlib.dll /keyfile:../../msfinal.pub -target:library -out:../../../class/lib/build-unix/Facades/System.Linq.dll @./../../../build/deps/unix_build_Facades_System.Linq.dll.response = Native Crash Reporting = Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = = Basic Fault Address Reporting = Memory around native instruction pointer (0x7ca9b940c125):0x7ca9b940c115 e8 bc fa ff ff 8b 44 24 0c eb 49 48 85 f6 74 09 ..D$..IH..t. 0x7ca9b940c125 81 7e 10 01 00 11 11 74 33 89 44 24 0c 8b 05 58 .~.t3.D$...X 0x7ca9b940c135 77 20 00 85 c0 74 37 48 8d 0d f5 1f 00 00 48 8d w ...t7H..H. 0x7ca9b940c145 15 4e 1f 00 00 be e2 02 00 00 48 8d 3d 3a 26 00 .NH.=:&. = Managed Stacktrace: = = gmake[10]: *** [../../../build/library.make:335: ../../../class/lib/build-unix/Facades/System.Linq.dll] Abort trap (core dumped) gmake[10]: *** Deleting file '../../../class/lib/build-unix/Facades/System.Linq.dll' ... I haven't been able to build it, as I mentioned above, since the end of January. Chavdar On Thu, 26 Mar 2020 at 17:44, Chavdar Ivanov wrote: > > Hi, > > Trying to build v. mono-6.8.0.105 I get: > > gmake[7]: Entering directory > '/usr/pkgsrc/lang/mono6/work/mono-6.8.0.105/mcs/class/Mono.Cecil' > mono ./../../class/lib/build/tmp/gensources.exe --strict > --platformsdir:./../../build > "../../build/deps/unix_build__Mono.Cecil.dll.sources" "Mono.Cecil.dll" > "unix" "build" > /usr/pkg/bin/gmake all-local > gmake[8]: Entering directory > '/usr/pkgsrc/lang/mono6/work/mono-6.8.0.105/mcs/class/Mono.Cecil' > cat <./../../build/deps/unix_build__Mono.Cecil.dll.sources > >../../build/deps/unix_build__Mono.Cecil.dll.response > mono > /usr/pkgsrc/lang/mono6/work/mono-6.8.0.105/external/roslyn-binaries/Microsoft.Net.Compilers/3.5.0/csc.exe > /shared:monomake /codepage:65001 /nologo /noconfig /deterministic > -d:NET_4_0 -d:NET_4_5 -d:MONO -d:WIN_PLATFORM -d:BOOTSTRAP_BASIC > -nowarn:1699 -nostdlib -optimize /features:peverify-compat > /langversion:latest -d:NET_4_0 -unsafe > -r:./../../../external/binary-reference-assemblies/v4.7/System.Core.dll > -r:./../../../external/binary-reference-assemblies/v4.7/System.dll > -r:./../../../external/binary-reference-assemblies/v4.7/mscorlib.dll > /keyfile:../mono.snk -target:library > -out:../../class/lib/build-unix/tmp/Mono.Cecil.dll > @./../../build/deps/unix_build__Mono.Cecil.dll.response > > = > Native Crash Reporting > = > Got a SIGSEGV while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > = > > = > Basic Fault Address Reporting > = > Memory around native instruction pointer (0x70e90fe0c335): > 0x70e90fe0c325 e8 9a fa ff ff 8b 44 24 0c eb 49 48 85 f6 74 09 > ..D$..IH..t. > 0x70e90fe0c335 81 7e 10 01 00 11 11 74 33 89 44 24 0c 8b 05
Re: lang/rust build fails
On Thu, 14 May 2020 at 19:09, Robert Nestor wrote: > > Ran into an interesting problem trying to build lang/rust from both -current > and 2020Q1 pkgsrc. On a NetBSD installation of 9.99.45 kernel and user land, > the builds succeed. Under 9.99.60 kernel and user land the builds fail. # ls -l /usr/pkg/bin/rustc -rwxr-xr-x 1 root wheel 13728 May 7 16:08 /usr/pkg/bin/rustc # file /usr/pkg/bin/rustc /usr/pkg/bin/rustc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetB SD 9.99.60, not stripped # rustc --version rustc 1.42.0 So I've built it a week ago under 9.99.60. > > The failure doesn’t give much of a clue about what’s happened. The last > lines in the build.log are: > > running: /pkg_comp/work/pkg/lang/rust/work/rust-bootstrap/bin/cargo build > --manifest-path > /pkg_comp/work/pkg/lang/rust/work/rustc-1.42.0-src/src/bootstrap/Cargo.toml > --frozen >Compiling proc-macro2 v0.4.30 > > At that point there’s nothing consuming CPU time in the build and everything > seems to be waiting on something to happen that never does. I’ve left the > system in that state for about 24 hours and still no progress. > > Any clues? Could this be something related to some of the recent kernel > changes? > Thanks, > -bob --
Re: lang/rust build fails
Sure, here it is. # rndctl -l Source Bits Type Flags /dev/random 0 ??? estimate, collect, v ukbd0 0 tty estimate, collect, v, t, dt wd2 0 disk estimate, collect, v, t, dt wd1 0 disk estimate, collect, v, t, dt wd0 0 disk estimate, collect, v, t, dt acpibat0-discha 0 power estimate, collect, v, t, dv, dt acpibat0-charge 0 power estimate, collect, v, t, dv, dt acpibat1-discha 0 power estimate, collect, v, t, dv, dt acpibat1-charge 0 power estimate, collect, v, t, dv, dt cpu7 0 vm estimate, collect, v, t, dv cpu6 0 vm estimate, collect, v, t, dv cpu5 0 vm estimate, collect, v, t, dv cpu4 0 vm estimate, collect, v, t, dv cpu3 0 vm estimate, collect, v, t, dv cpu2 0 vm estimate, collect, v, t, dv cpu1 0 vm estimate, collect, v, t, dv cpu0 0 vm estimate, collect, v, t, dv coretemp3-cpu60 env estimate, collect, v, t, dv, dt coretemp2-cpu40 env estimate, collect, v, t, dv, dt coretemp1-cpu20 env estimate, collect, v, t, dv, dt coretemp0-cpu00 env estimate, collect, v, t, dv, dt wm0 0 net estimate, v, t, dt pms0 0 tty estimate, collect, v, t, dt pckbd00 tty estimate, collect, v, t, dt acpitz7-tempera 0 env estimate, collect, v, t, dv, dt acpitz6-tempera 0 env estimate, collect, v, t, dv, dt acpitz5-tempera 0 env estimate, collect, v, t, dv, dt acpitz4-cpu0-te 0 env estimate, collect, v, t, dv, dt acpitz3-tempera 0 env estimate, collect, v, t, dv, dt acpitz2-tempera 0 env estimate, collect, v, t, dv, dt acpitz1-cpu0-te 0 env estimate, collect, v, t, dv, dt acpitz0-tempera 0 env estimate, collect, v, t, dv, dt system-power 0 power estimate, collect, v, t, dt autoconf 0 ??? estimate, collect, t seed256 ??? estimate, collect, v rdrand 512 rng estimate, collect, v On Fri, 15 May 2020 at 05:47, Martin Husemann wrote: > > Can you show output (as root) of rndctl -l please? > > Martin --
Re: firefox-74.0 crash on -current
On Wed, 18 Mar 2020 at 04:01, Ryo ONODERA wrote: > > Hi, > > Your firefox-73.0.1 and 74.0 share the same graphics/MesaLib? It is on the same machine, so I would presume so. How should I check? MesaLib does not appear as a dependency. The version installed is MesaLib-19.2.7nb4. > And what is your GPU? In this case the test was done under VirtualBox: ... [40.370] (II) Initializing extension GLX [40.371] (II) AIGLX: Screen 0 is not DRI2 capable [40.955] (II) IGLX: Loaded and initialized swrast [40.955] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [40.956] (II) Initializing extension XFree86-VidModeExtension [40.956] (II) Initializing extension XFree86-DGA [40.957] (II) Initializing extension XFree86-DRI [40.957] (II) Initializing extension DRI2 and 73.0.1 works fine. If I upgrade it to 74.0 - using pkgin - it crashes when opening a WebGL demo; otherwise it works fine. > > With my Intel internal GPU in KabyLake Refresh, > https://webglsamples.org/aquarium/aquarium.html > works fine (firefox-74.0/MesaLib-20.0.1nb1). I still haven't tested my laptop (Intel 530 grapics) yet, I might boot NetBSD later for that. > > Thank you. Thanks, Chavdar > > Chavdar Ivanov writes: > > > Hi, > > > > On today's -current my build of firefox-74.0 (from yesterday, rust > > 1.42.0 from the day before, cbindgen also rebuilt), when I access the > > demos at webglsamples.org I get: > > > > Core was generated by `firefox'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 > > [Current thread is 1 (process 1)] > > (gdb) bt > > #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 > > #1 0x7b00bc9e6681 in ?? () from /usr/pkg/lib/firefox/libxul.so > > #2 0x7b00bd2628a7 in ?? () from /usr/pkg/lib/firefox/libxul.so > > #3 0x7b00ceab0010 in opendir () from /usr/lib/libc.so.12 > > #4 0x0001000b in ?? () > > #5 0x in ?? () > > ... > > > > On the same system, firefox-73.0.1 works just fine. > > > > > > Chavdar > > > > > > -- > > > > -- > Ryo ONODERA // r...@tetera.org > PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 --
Re: firefox-74.0 crash on -current
На 2020-03-18 в 04:01, Ryo ONODERA написа: > Hi, > > Your firefox-73.0.1 and 74.0 share the same graphics/MesaLib? > And what is your GPU? > > With my Intel internal GPU in KabyLake Refresh, > https://webglsamples.org/aquarium/aquarium.html > works fine (firefox-74.0/MesaLib-20.0.1nb1). It still crashes for me on real hardware, but I see your MesaLib is newer, so I am going to update it as well. I usually do the updates the long way via pkg_rolling-replace, this time was lazy and updated only firefox, rust and cbindgen before building firefox, so most likely it is my fault. > Thank you. > > Chavdar Ivanov writes: > >> Hi, >> >> On today's -current my build of firefox-74.0 (from yesterday, rust >> 1.42.0 from the day before, cbindgen also rebuilt), when I access the >> demos at webglsamples.org I get: >> >> Core was generated by `firefox'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 >> [Current thread is 1 (process 1)] >> (gdb) bt >> #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 >> #1 0x7b00bc9e6681 in ?? () from /usr/pkg/lib/firefox/libxul.so >> #2 0x7b00bd2628a7 in ?? () from /usr/pkg/lib/firefox/libxul.so >> #3 0x7b00ceab0010 in opendir () from /usr/lib/libc.so.12 >> #4 0x0001000b in ?? () >> #5 0x in ?? () >> ... >> >> On the same system, firefox-73.0.1 works just fine. >> >> >> Chavdar >> >> >> -- >>
firefox-74.0 crash on -current
Hi, On today's -current my build of firefox-74.0 (from yesterday, rust 1.42.0 from the day before, cbindgen also rebuilt), when I access the demos at webglsamples.org I get: Core was generated by `firefox'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 [Current thread is 1 (process 1)] (gdb) bt #0 0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12 #1 0x7b00bc9e6681 in ?? () from /usr/pkg/lib/firefox/libxul.so #2 0x7b00bd2628a7 in ?? () from /usr/pkg/lib/firefox/libxul.so #3 0x7b00ceab0010 in opendir () from /usr/lib/libc.so.12 #4 0x0001000b in ?? () #5 0x in ?? () ... On the same system, firefox-73.0.1 works just fine. Chavdar --
Another pmap panic
Hi, Overnight, while doing pkg_rolling-replace, my 'server' got: ... panic: kernel diagnostic assertion "ptp->wire_count == 1" failed: file "/home/sysbuild/src/sys/arch/x86/x86/pmap.c", line 2232 cpu0: Begin traceback... vpanic() at netbsd:vpanic+0x178 kern_assert() at netbsd:kern_assert+0x48 pmap_unget_ptp() at netbsd:pmap_unget_ptp+0x1f1 pmap_get_ptp() at netbsd:pmap_get_ptp+0x300 pmap_enter_ma() at netbsd:pmap_enter_ma+0x6fb pmap_enter_default() at netbsd:pmap_enter_default+0x29 uvm_fault_internal() at netbsd:uvm_fault_internal+0xf2e trap() at netbsd:trap+0x50a --- trap (number 6) --- 7f7eec2007e0: cpu0: End traceback... dumping to dev 168,2 (offset=8, size=5225879): ... --
Re: Another pmap panic
Thanks! Building now. On Fri, 20 Mar 2020 at 18:27, Andrew Doran wrote: > > Hi, > > I meant to send a note yesterday but fatigue got the better of me. > > I suggest updaing to the latest, delivered yesterday, which has fixes for > every problem I have encountered or seen mentioned including this one, and > survives low memory stress testing for me: > > /* $NetBSD: pmap.c,v 1.378 2020/03/19 18:58:14 ad Exp $*/ > > Thank you, > Andrew > > On Fri, Mar 20, 2020 at 05:49:59PM +, Chavdar Ivanov wrote: > > Hi, > > > > Overnight, while doing pkg_rolling-replace, my 'server' got: > > ... > > panic: kernel diagnostic assertion "ptp->wire_count == 1" failed: file > > "/home/sysbuild/src/sys/arch/x86/x86/pmap.c", line 2232 > > > > cpu0: Begin traceback... > > vpanic() at netbsd:vpanic+0x178 > > kern_assert() at netbsd:kern_assert+0x48 > > pmap_unget_ptp() at netbsd:pmap_unget_ptp+0x1f1 > > pmap_get_ptp() at netbsd:pmap_get_ptp+0x300 > > pmap_enter_ma() at netbsd:pmap_enter_ma+0x6fb > > pmap_enter_default() at netbsd:pmap_enter_default+0x29 > > uvm_fault_internal() at netbsd:uvm_fault_internal+0xf2e > > trap() at netbsd:trap+0x50a > > --- trap (number 6) --- > > 7f7eec2007e0: > > cpu0: End traceback... > > > > dumping to dev 168,2 (offset=8, size=5225879): > > ... > > > > > > -- > > --
Re: firefox does not build on -current: clang++ core dumps
On Wed, 20 May 2020 at 21:24, Thomas Klausner wrote: > > On Wed, May 20, 2020 at 09:32:49PM +0200, Thomas Klausner wrote: > > On Wed, May 20, 2020 at 08:06:17PM +0200, Thomas Klausner wrote: > > > I last built firefox successfully on April 23 (version 75.0nb1). > > > > I just downgraded firefox to 75.0nb4 from May 5 and that built. > > And 76.0 from May 7 is the first version that does not build for me. > Thomas I have: # pkg_info firefox Information for firefox-76.0.1: Comment: Web browser with support for extensions (version 76) Requires: libffi>=3.3nb1 nspr>=4.25 icu>=66.1 nss>=3.52 libwebp>=1.0.2 libIDL>=0.8.14nb5 ffmpeg4>=4.2 gtk2+>=2.24.32nb13 gtk3+>=3.24.14nb2 dbus-glib>=0.110nb1 libv4l>=0.4.3nb2 desktop-file-utils>=0.10nb1 ... # uname -a NetBSD ymir 9.99.63 NetBSD 9.99.63 (GENERIC) #0: Wed May 20 12:22:51 BST 2020 root@ymir:/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 # file /usr/pkg/lib/firefox/firefox-bin /usr/pkg/lib/firefox/firefox-bin: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /libexec/ld.elf_so, BuildID[sha1]=4fde6c4b72d3d2ba372c74a2bc7ddc1bd47ed293, for NetBSD 9.99.60, PaX: -mprotect, stripped But it was built under 9.99.60 on the 13th of May. I'll try to build it now. --
Re: firefox does not build on -current: clang++ core dumps
On Thu, 21 May 2020 at 08:25, Chavdar Ivanov wrote: > > On Wed, 20 May 2020 at 21:24, Thomas Klausner wrote: > > > > On Wed, May 20, 2020 at 09:32:49PM +0200, Thomas Klausner wrote: > > > On Wed, May 20, 2020 at 08:06:17PM +0200, Thomas Klausner wrote: > > > > I last built firefox successfully on April 23 (version 75.0nb1). > > > > > > I just downgraded firefox to 75.0nb4 from May 5 and that built. > > > > And 76.0 from May 7 is the first version that does not build for me. > > Thomas > > I have: > # pkg_info firefox > Information for firefox-76.0.1: > > Comment: > Web browser with support for extensions (version 76) > > Requires: > libffi>=3.3nb1 > nspr>=4.25 > icu>=66.1 > nss>=3.52 > libwebp>=1.0.2 > libIDL>=0.8.14nb5 > ffmpeg4>=4.2 > gtk2+>=2.24.32nb13 > gtk3+>=3.24.14nb2 > dbus-glib>=0.110nb1 > libv4l>=0.4.3nb2 > desktop-file-utils>=0.10nb1 > ... > # uname -a > NetBSD ymir 9.99.63 NetBSD 9.99.63 (GENERIC) #0: Wed May 20 12:22:51 > BST 2020 root@ymir:/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > amd64 > # file /usr/pkg/lib/firefox/firefox-bin > /usr/pkg/lib/firefox/firefox-bin: ELF 64-bit LSB shared object, > x86-64, version 1 (SYSV), dynamically linked, interpreter > /libexec/ld.elf_so, > BuildID[sha1]=4fde6c4b72d3d2ba372c74a2bc7ddc1bd47ed293, for NetBSD > 9.99.60, PaX: -mprotect, stripped > > But it was built under 9.99.60 on the 13th of May. > > I'll try to build it now. My firefox-76.01 build finished without any problems earlier today; -current as of yersterday. > > > > > > -- > --
Re: KASLR kernel fails to boot
After the latest updates to /usr/mdec/prekern, now I am getting FATAL elf sym lookup: symbol beyond table when I try to load the KASLR kernel. Chavdar On Tue, 5 May 2020 at 21:26, Chavdar Ivanov wrote: > > Ok, thanks. > > On Tue, 5 May 2020 at 20:21, Maxime Villard wrote: > > > > Le 05/05/2020 à 21:01, Chavdar Ivanov a écrit : > > > On Mon, 4 May 2020 at 21:21, Chavdar Ivanov wrote: > > >> > > >> Hi, > > >> > > >> netbsd-GENERIC_KASLR from yesterday fails to pass the prekern stage > > >> with a frightening message in red 'Page fault'. I've never seen this > > >> before, no idea if I can get any further info. > > >> > > >> This machine has been otherwise running KASLR kernel for some four > > >> months now without a problem; it is a VirtualBox guest. > > > > > > Same with just completed clean buid of 9.99.60. > > > > > > After "[+] Rel relocations applied" I get: > > > > > > ** Fault occurred ** > > > page fault > > > ** > > > > > > I switched th vm to the normal kernel, no problem otherwise. > > > > I know, this is because of the Xen section in the binary, which is not > > marked as allocatable. The prekern explicitly decides not to map the note > > but then proceeds to relocate its RELAs regardless, which causes a fatal > > page fault. > > > > Trivial to fix but I'm not sure which policy to choose, may take a few > > days. > > > > -- > --
cmake hanging
Hi, While doing pkg_rolling-replace on amd64 -current from yesterday, I got three times in a row a hang in cmake as the followingL ... (gdb) bt #0 0x7a316cea8d3a in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7a316d60a7d0 in pthread_cond_timedwait () from /usr/lib/libpthread.so.1 #2 0x7a316e2a0214 in std::condition_variable::wait(std::unique_lock&) () from /usr/lib/libstdc++.so.9 #3 0x004a7bb3 in cmWorkerPoolInternal::Work(unsigned int) () #4 0x7a316e29e53a in ?? () from /usr/lib/libstdc++.so.9 #5 0x7a316d60c899 in ?? () from /usr/lib/libpthread.so.1 #6 0x7a316ce92900 in ?? () from /usr/lib/libc.so.12 #7 0x in ?? () The process completed after I quit the gdb session. --
Re: firefox build broken
On Fri, 1 May 2020 at 13:13, Thomas Klausner wrote:
>
> On Thu, Apr 30, 2020 at 06:22:01AM +0900, Ryo ONODERA wrote:
> > Hi,
> >
> > On my NetBSD/amd64 9.99.59 of 2020-04-29,
> > pkgsrc/www/firefox builds without any problem.
> >
> > I have tested with pkgsrc/lang/rust built on both 9.99.57
> > and 9.99.59 of 2020-04-29, and I did not have any problem.
>
> That's strange, I don't understand this.
>
> I have been seeing this error for days now:
>
> In file included from
> /scratch/www/firefox/work/firefox-75.0/js/src/gc/StoreBuffer.cpp:7:
> In file included from
> /scratch/www/firefox/work/firefox-75.0/js/src/gc/StoreBuffer-inl.h:10:
> In file included from
> /scratch/www/firefox/work/firefox-75.0/js/src/gc/StoreBuffer.h:17:
> In file included from
> /scratch/www/firefox/work/firefox-75.0/js/src/ds/LifoAlloc.h:28:
> In file included from
> /scratch/www/firefox/work/build/dist/include/js/UniquePtr.h:10:
> /scratch/www/firefox/work/build/dist/include/mozilla/UniquePtr.h:223:39:
> error: no template named 'is_reference_v' in namespace 'std'; did you mean
> 'is_reference'?
> typename Conditional, D, const D&>::Type
> aD1)
> ~^~
> is_reference
> /usr/include/c++/type_traits:400:51: note: 'is_reference' declared here
> template struct _LIBCPP_TYPE_VIS_ONLY is_reference:
> public false_type {};
> ^
>
> which doesn't look like it should be specific to my system.
>
> And then later:
>
> stack backtrace:
>0:0x11f4088e2 -
> core::fmt::Display>::fmt::hfc6622696269221b
>1:0x11f4244ad - core::fmt::write::hd3eed79e7afa73cf
>2:0x11f407aa5 - std::io::Write::write_fmt::h60ea7d9604ed82bb
>3:0x11f3fae90 -
> std::panicking::default_hook::{{closure}}::h2c07f5fe2b4f82c2
>4:0x11f3fab82 - std::panicking::default_hook::h6dd6fafda250b80f
>5:0x11f3fb4ed -
> std::panicking::rust_panic_with_hook::hd4a4901bf3898ce4
>6:0x11f3fb0d0 - rust_begin_unwind
>7:0x11f3fb04b - std::panicking::begin_panic_fmt::h08093aab619d21cf
>8:0x11f250244 -
> build_script_build::build_gecko::generate_structs::h05aae5803967982b
>9:0x11f251dc6 - build_script_build::main::hdd2fcab7190374c2
> 10:0x11f238a53 - std::rt::lang_start::{{closure}}::h1cbbafc9225f7a3a
> 11:0x11f3fafb3 - std::panicking::try::do_call::hf264ae5e639af05c
> 12:0x11f40ec37 - __rust_maybe_catch_panic
> 13:0x11f3fe8eb - std::rt::lang_start_internal::h63883908f6b782bf
> 14:0x11f252792 - main
> 15:0x11f235cfb - ___start
>
>
> That's with a userland from yesterday and a kernel from today, rust
> was rebuilt today as well.
I just finished a build of firefox-75-nb1 on -current from overnight
without any problem. Rust is rust-1.42.0nb1.
> Thomas
--
Re: hang while updating pkg_rolling-replace libvdpau
On Thu, 3 Sep 2020 at 12:19, Greg Troxel wrote: > > > Riccardo Mottola writes: > > > I finished updating all my core system to current on i386-64, kernel, > > userland, etc. > > > > Now I launched pkg_rolling replace, it crunches through several > > packages, but then hangs. > > > > > > I tried running it several times, rebooting in between... but > > nothing. What is "hang" ? The CPU stays idle too. Hangs exactly there. > > pkg_rr is just a shell script. As always, I ask that you see what order > it does "make replace package clean" and then run the problematic > command by itself, without pkg_rr, and then report that intead. > > (If you do find a bug in pkg_rr, of which there are many, please do > report it. But it is confusing to people to conflate what broke with > the program that merely chose the sequence.) In this case I don't think it is anything to do with pkg_rolling-replace; I've reported a few of these hangs, which happen to happen during pkg_rolling-replace, but involve most often cmake, but other programs as well. Apparently there are similarities in the traces, perhaps pointing to the thread model and execution. In all these occasions the process in question continued to a successful conclusion after attaching and then detaching with gdb. --
Re: cmake hanging
Hi, I am having the same cmake hangs as in this thread. I've attached the gdb 'thread apply all bt' output (collected with script). It happens during a fairly long pkg_rolling-replace under 9.99.72 from the 29th of August, after about 900 packages were already done, during the build of kmymoney. On Tue, 16 Jun 2020 at 19:05, Chavdar Ivanov wrote: > > I just had another similar hang, this time in git, while trying to > pull pkgsrc/wip: > ... > [Switching to LWP 2518 of process 2823] > 0x72b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12 > (gdb) thread apply all bt > > Thread 2 (LWP 2823 of process 2823): > #0 0x72b102a4551a in _lwp_wait () from /usr/lib/libc.so.12 > #1 0x72b10320c754 in pthread_join () from /usr/lib/libpthread.so.1 > #2 0x00549842 in preload_index () > #3 0x00558178 in refresh_index () > #4 0x004252f0 in cmd_status () > #5 0x004053fe in handle_builtin () > #6 0x00406301 in cmd_main () > #7 0x005ea9a3 in main () > > Thread 1 (LWP 2518 of process 2823): > #0 0x72b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12 > #1 0x72b103209791 in ?? () from /usr/lib/libpthread.so.1 > #2 0x72b102ad6d0a in je_malloc_mutex_lock_slow () from > /usr/lib/libc.so.12 > #3 0x72b102b0e4f1 in je_arena_choose_hard () from /usr/lib/libc.so.12 > #4 0x72b102ab583f in je_tsd_tcache_data_init () from /usr/lib/libc.so.12 > #5 0x72b102ab5a89 in je_tsd_tcache_enabled_data_init () from > /usr/lib/libc.so.12 > #6 0x72b102ab1b09 in je_tsd_fetch_slow () from /usr/lib/libc.so.12 > #7 0x72b102b0e82d in malloc () from /usr/lib/libc.so.12 > #8 0x005cbed5 in xrealloc () > #9 0x005a04d0 in strbuf_grow () > #10 0x005aa74b in lstat_cache_matchlen () > #11 0x005aa885 in threaded_has_symlink_leading_path () > #12 0x005495b8 in preload_thread () > #13 0x72b10320bee0 in ?? () from /usr/lib/libpthread.so.1 > #14 0x72b102a92370 in ?? () from /usr/lib/libc.so.12 > #15 0x0020 in ?? () > #16 0x in ?? () > > > The system is from today: > > $ uname -a > NetBSD ymir 9.99.67 NetBSD 9.99.67 (GENERIC) #4: Tue Jun 16 09:10:01 > BST 2020 > sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > am > d64 > > > Chavdar > > > On Thu, 11 Jun 2020 at 00:19, Andrew Doran wrote: > > > > On Mon, Jun 08, 2020 at 03:38:44PM +0100, Chavdar Ivanov wrote: > > > On Sun, 7 Jun 2020 at 10:25, Chavdar Ivanov wrote: > > > > > > > > Hi, > > > > > > > > I just had another one, rebuilding gimp, running gegl. Again gdb -p > > > > ... ; quit sorted it out. > > > > > > > > On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov wrote: > > > > > > > > > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > > > > > > > > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > > > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > > > > > building misc/kdepimlibs4, trace as follows: > > > > > > > > > > > > > > Just to mention that after I quit gdb and detached from the > > > > > > > process it > > > > > > > continued and completed the build . . . > > > > > > > > > > > > Right, that's the bug in the mutex wakeup handling. > > > > > > > > > > The second hung sample - with git - also completed OK after I quit > > > > > gdb... > > > > > > I had another three cmake hangs just like this today, while rebuilding > > > bits of kf5. > > > > > > Just to confirm - the moment one answers 'y' to the question whether > > > to leave gdb the process continues and the build succeeds. > > > > > > This is somewhat annoying; although it does not stop the rebuild > > > process, it makes it impossible to complete unattended. > > > > I just made some more changes to libpthread today that may help. I'll try > > building KDE soon. > > > > Cheers, > > Andrew > > > > -- > -- cmake.log Description: Binary data
Re: cmake hanging
Another one, overnight, while building gimp, by gegl, attached. As I mentioned earlier, it is enough to attach to the process with gdb and then quit in order for the process to carry on working and complete the build. On Tue, 1 Sep 2020 at 08:55, Tom Ivar Helbekkmo wrote: > > Chavdar Ivanov writes: > > > I am having the same cmake hangs as in this thread. I've attached the > > gdb 'thread apply all bt' output (collected with script). > > That looks suspiciouly similar to the hangs I'm seeing with dhcpd on > amd64-current (note the mutex lock attempt, while nothing else looks > very interesting): > > (gdb) thread apply all bt > > Thread 7 (process 12269): > #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e573fd67d08, > mutex=0x7e573fd67cd8, abstime=0x0) at > /usr/src/lib/libpthread/pthread_cond.c:167 > #2 0x7e573f01ed2e in isc_app_ctxrun (ctx=0x7e573fd67c80) at > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/app.c:340 > #3 0x5664e624 in dispatch () at > /usr/src/external/mpl/dhcp/lib/common/../../dist/common/dispatch.c:121 > #4 0x5668aae7 in main (argc=, argv=) > at /usr/src/external/mpl/dhcp/bin/server/../../dist/server/dhcpd.c:1114 > > Thread 6 (process 21463): > #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e5740037850, > mutex=0x7e5740037800, abstime=0x0) at > /usr/src/lib/libpthread/pthread_cond.c:167 > #2 0x7e573f02a0a4 in dispatch (threadid=, > manager=0x7e5740036800) at > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/task.c:1059 > #3 run (queuep=) at > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/task.c:1346 > #4 0x7e573e80bee0 in pthread__create_tramp (cookie=0x7e574002e000) at > /usr/src/lib/libpthread/pthread.c:560 > #5 0x7e573a2924e0 in ?? () from /usr/lib/libc.so.12 > #6 0x0040 in ?? () > #7 0x7e573980 in ?? () > #8 0x001003a0efff in ?? () > #9 0x7e57396000c0 in ?? () > #10 0x001fff40 in ?? () > #11 0x in ?? () > > Thread 5 (process 19116): > #0 0x7e573a244d8a in _sys___kevent50 () from /usr/lib/libc.so.12 > #1 0x7e573e8079d8 in __kevent50 (fd=, ev=ev@entry=0x0, > nev=nev@entry=0, rev=rev@entry=0x7e5740008000, nrev=nrev@entry=64, > ts=ts@entry=0x0) at /usr/src/lib/libpthread/pthread_cancelstub.c:176 > #2 0x7e573f0223c4 in netthread (uap=0x7e5740039800) at > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/unix/socket.c:3519 > #3 0x7e573e80bee0 in pthread__create_tramp (cookie=0x7e574002fc00) at > /usr/src/lib/libpthread/pthread.c:560 > #4 0x7e573a2924e0 in ?? () from /usr/lib/libc.so.12 > #5 0x0060 in ?? () > #6 0x7e573940 in ?? () > #7 0x002003a0efff in ?? () > #8 0x7e5737a000c0 in ?? () > #9 0x003fff40 in ?? () > Backtrace stopped: Cannot access memory at address 0x7e5737800028 > > Thread 4 (process 25506): > #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e574003a868, > mutex=0x7e574003a810, abstime=0x0) at > /usr/src/lib/libpthread/pthread_cond.c:167 > #2 0x7e573f028631 in run (uap=0x7e574003a800) at > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/timer.c:650 > #3 0x7e573e80bee0 in pthread__create_tramp (cookie=0x7e5740031800) at > /usr/src/lib/libpthread/pthread.c:560 > #4 0x7e573a2924e0 in ?? () from /usr/lib/libc.so.12 > Backtrace stopped: Cannot access memory at address 0x7e57367f > > Thread 3 (process 26000): > #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e573fd69cd0, > mutex=0x7e573fd69c80, abstime=0x0) at > /usr/src/lib/libpthread/pthread_cond.c:167 > #2 0x7e573f02a0a4 in dispatch (threadid=, > manager=0x7e573fd68c80) at > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/task.c:1059 > #3 run (queuep=) at > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/task.c:1346 > #4 0x7e573e80bee0 in pthread__create_tramp (cookie=0x7e5740033400) at > /usr/src/lib/libpthread/pthread.c:560 > #5 0x7e573a2924e0 in ?? () from /usr/lib/libc.so.12 > Backtrace stopped: Cannot access memory at address 0x7e57357e > > Thread 2 (process 24520): > #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > #1 0x7e573e809791 in pthread__mutex_lock_slow > (ptm=ptm@entry=0x7e573fd71158, ts=ts@entry=0x0) at > /usr/src/lib/libpthread/pthread_mutex.c:363 > #2 0x7e573e809a44 in pthread_mutex_lock (p
Re: xen-tools 4.13.1 build failure
Ok, thanks. On Mon, 31 Aug 2020 at 12:32, Manuel Bouyer wrote: > > On Sun, Aug 30, 2020 at 04:54:18PM +0100, Chavdar Ivanov wrote: > > 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 > > This header is in src/sys/arch/xen/include, it should be installed along with > xenio.h > I just commited a fix for this. > > -- > Manuel Bouyer > NetBSD: 26 ans d'experience feront toujours la difference > -- --
Re: hang while updating pkg_rolling-replace libvdpau
On Tue, 8 Sep 2020 at 08:07, Martin Husemann wrote: > > On Mon, Sep 07, 2020 at 11:40:58PM +0200, Riccardo Mottola wrote: > > > It mentions a workaround, but what does it mean to: > > > dd if=/dev/urandom of=/dev/random bs=32 count=1 > > > sysctl -w kern.entropy.consolidate=1 > > > > > > I tried this "quick fix" and then was able to leave the laptop several hours > > upgrading, so indeed it it solves the issue. I suppose this fix needs to > > repeated at every boot? > > Usualy not, a variation of it should happen at install time on all systems > not providing a (good enough) random number generator internally. Taylor > is working on covering more systems. Installation will (in the future) > detect this state and offer solutions. > > Once the "full entropy" state is reached, it usually persists - on proper > shutdown the seed file is written and restored on next boot. > > This is all kind of in flux currently, so there is quite a bit of confusion > and different advices floating around. To add to the confusion, perhaps related to this, I've been getting random hangs when using some of the (admittedly over the top) zsh prompts from oh_my_zsh, when they involve git invocation. Roughly 25% of all commands executed with one particular prompt setting The trace is as follows, if it is of interest: ... [Switching to LWP 27612 of process 16821] 0x74480bca88ba in ___lwp_park60 () from /usr/lib/libc.so.12 (gdb) thread apply all bt Thread 2 (LWP 16821 of process 16821): #0 0x74480bc4556a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x74480c40c754 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x0054ba92 in preload_index () #3 0x0055a3e8 in refresh_index () #4 0x00425510 in cmd_status () #5 0x004053fe in handle_builtin () #6 0x00406301 in cmd_main () #7 0x005ed143 in main () Thread 1 (LWP 27612 of process 16821): #0 0x74480bca88ba in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x74480c409791 in ?? () from /usr/lib/libpthread.so.1 #2 0x74480bcd6e1a in je_malloc_mutex_lock_slow () from /usr/lib/libc.so.12 #3 0x74480bd0e601 in je_arena_choose_hard () from /usr/lib/libc.so.12 #4 0x74480bcb594f in je_tsd_tcache_data_init () from /usr/lib/libc.so.12 #5 0x74480bcb5b99 in je_tsd_tcache_enabled_data_init () from /usr/lib/libc.so.12 #6 0x74480bcb1c19 in je_tsd_fetch_slow () from /usr/lib/libc.so.12 #7 0x74480bd0e93d in malloc () from /usr/lib/libc.so.12 #8 0x005ce9fb in xrealloc () #9 0x005a2e20 in strbuf_grow () #10 0x005ad07b in lstat_cache_matchlen () #11 0x005ad1b5 in threaded_has_symlink_leading_path () #12 0x0054b808 in preload_thread () #13 0x74480c40bee0 in ?? () from /usr/lib/libpthread.so.1 #14 0x74480bc924e0 in ?? () from /usr/lib/libc.so.12 #15 0x in ?? () (gdb) quit The process - again, as with cmake - resumes after quitting gdb. > > Martin Chavdar --
Re: Status of COMPAT_LINUX and Linux emulation?
On Fri, 4 Sep 2020 at 22:39, Thomas Klausner wrote: > > On Wed, Sep 02, 2020 at 11:41:41PM +0200, Jaromír Doleček wrote: > > COMPAT_LINUX works as well as always, and will continue working the > > same. Presence in GENERIC does not change how reliable it is now or in > > future. There are no plans to remove the actual code, the option as > > well as the kernel module will continue working. > > I just tried (on 9.99.72/amd64): > > # sysctl -w kern.module.verbose = 1 > # modload compat_linux > modload: compat_linux: No such file or directory > > In /var/log/messages I found: > > DEBUG: module: Loading module from > /stand/amd64/9.99.72/modules/compat_linux/compat_linux.kmod > kobj_sym_lookup, 908: [%M/...t_linux/compat_linux.kmod]: linker error: local > symbol @0 undefined > DEBUG: module: Cannot load kernel object `compat_linux' error=2 > > The kernel is a GENERIC + SCTP + font change, the module is from a > 'build.sh'. Do I need to create the modules specifically for my > slightly modified kernel? If yes, what's the easiest way? FWIF, on unmodified GENERIC, I get: # modstat compat_linux NAME CLASSSOURCE FLAG REFSSIZE REQUIRES # modload compat_linux # modstat compat_linux NAME CLASSSOURCE FLAG REFSSIZE REQUIRES compat_linux exec filesys -0 52392 compat_ossaudio,sysv_ipc,compat_util,compat_50,compat_43,exec_elf64 # uname -a NetBSD ymir 9.99.72 NetBSD 9.99.72 (GENERIC) #9: Wed Sep 2 17:47:42 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 # /usr/pkg/emul/linux/bin/sh sh-4.2# The module was built with the system. > > Thomas Chavdar --
Re: xen-tools 4.13.1 build failure
On Mon, 31 Aug 2020 at 13:31, Chavdar Ivanov wrote: > > Ok, thanks. Builds OK with the include file in place . > > On Mon, 31 Aug 2020 at 12:32, Manuel Bouyer wrote: > > > > On Sun, Aug 30, 2020 at 04:54:18PM +0100, Chavdar Ivanov wrote: > > > 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 > > > > This header is in src/sys/arch/xen/include, it should be installed along > > with > > xenio.h > > I just commited a fix for this. > > > > -- > > Manuel Bouyer > > NetBSD: 26 ans d'experience feront toujours la difference > > -- > > > > -- > --
Re: xen-tools 4.13.1 build failure
Hi, Another xentools413 build failure. It has been failing for me the last two weeks or so, failing to build seabios, as follows: gmake[5]: Entering directory '/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/firmware' /usr/pkg/bin/gmake -C seabios-dir CC=gcc LD=ld PYTHON=python3.7 EXTRAVERSION="-Xen" all; gmake[6]: Entering directory '/usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1' Linking out/rom.o ld -N -T out/romlayout32flat.lds out/rom16.strip.o out/rom32seg.strip.o out/code32flat.o -o out/rom.o ld: out/code32flat.o: in function `memmove': /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/string.c:206: undefined reference to `memcpy' ld: out/code32flat.o: in function `const_read_file': /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/romfile.c:116: undefined reference to `memcpy' ld: out/code32flat.o: in function `tpm_log_event': /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/tcgbios.c:131: undefined reference to `memcpy' ld: /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/tcgbios.c:134: undefined reference to `memcpy' ld: out/code32flat.o: in function `smm_save_and_copy': /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/fw/smm.c:148: undefined reference to `memcpy' ld: out/code32flat.o:/usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/fw/smm.c:171: more undefined references to `memcpy' follow gmake[6]: *** [Makefile:186: out/rom.o] Error 1 gmake[6]: Leaving directory '/usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1' gmake[5]: *** [Makefile:138: subdir-all-seabios-dir] Error 2 gmake[5]: Leaving directory '/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/firmware' gmake[4]: *** [/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/firmware/../../tools/Rules.mk:232: subdirs-all] Error 2 gmake[4]: Leaving directory '/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/firmware' Wonder whether there is something to do with the switch to gcc9? If you try to build seabios on its own, it fails the same way. Chavdar On Mon, 31 Aug 2020 at 18:08, Chavdar Ivanov wrote: > > On Mon, 31 Aug 2020 at 13:31, Chavdar Ivanov wrote: > > > > Ok, thanks. > > Builds OK with the include file in place . > > > > > On Mon, 31 Aug 2020 at 12:32, Manuel Bouyer wrote: > > > > > > On Sun, Aug 30, 2020 at 04:54:18PM +0100, Chavdar Ivanov wrote: > > > > 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-ali
Re: QEMU booting of non-NetBSD CDs and virtual HDs
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. > Chavdar --
Re: Avoid -current for today :-/
On Fri, 21 Aug 2020 at 09:02, Martin Husemann wrote: > > Carefull when updating, -current is broken in several ways (does not compile > for 32bit architectures, make is broken, maybe more). > > Should be fixed soon... > I guess it is fixed now, I was just able to complete a build. > Martin Chavdar --
Possible rust issue on -current
Hi,
pkgsrc/wip/alacritty builds fine under -current, only two warnings for
obsolete constructs. Apart from the issue of not getting right the
shared library locations and the need to run it with LD_LIBRARY_PATH,
one gets on start:
RUST_BACKTRACE=full WINIT_UNIX_BACKEND=x11
LD_LIBRARY_PATH=/usr/X11R7/lib:/usr/pkg/lib ./alacritty
thread 'main' panicked at 'Initializing the event loop outside of the
main thread is a significant cross-platform compatibility hazard. If
you really, absolutely need to create an EventLoop on a different
thread, please use the `EventLoopExtUnix::new_any_thread` function.',
/usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:703:9
stack backtrace:
0: 0x1cf84809 -
::fmt::h696b0c7164c42b89
1: 0x1ce776ec - core::fmt::write::h3e4f7bb56331df60
2: 0x1cf7eda6 - std::io::Write::write_fmt::hd6b629b0842160ba
3: 0x1cf78715 -
std::panicking::default_hook::{{closure}}::h8b30e814058b19b5
4: 0x1cf7829d -
std::panicking::rust_panic_with_hook::h3062351663ff3949
5: 0x1cf77f38 - rust_begin_unwind
6: 0x1cf77ee0 - std::panicking::begin_panic_fmt::h8b1f010f0b35211e
7: 0x1ccd8d7c -
winit::platform_impl::platform::assert_is_main_thread::h3105b1f3a5f2dee9
at
/usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:703
8: 0x1ccd8d7c -
winit::platform_impl::platform::EventLoop::new::h1238e8f8d9d65e9a
at
/usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:531
9: 0x1ccd8d7c -
winit::event_loop::EventLoop::with_user_event::h2a9c013754dd7b1e
at
/usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/event_loop.rs:129
10: 0x1ccd8d7c - alacritty::main::hde70bbc298dd3f59
at alacritty/src/main.rs:81
11: 0x1cf844b3 -
std::sys_common::backtrace::__rust_begin_short_backtrace::hc4d5a95302ccc82d
12: 0x1cccfd5e - main
13: 0x1cc63d3b - ___start
The suggestion on https://github.com/alacritty/alacritty/issues/2631
was that for some reason under NetBSD the detection of whether one is
on a main thread is incorrect. I wonder if there is anything similar
seen elsewhere.
Chavdar
--
Re: Possible rust issue on -current
On Thu, 20 Aug 2020 at 05:10, Tobias Nygren wrote:
>
> On Thu, 20 Aug 2020 05:04:37 +0200
> Tobias Nygren wrote:
>
> > This doesn't sound like a rust problem but rather some crate is trying
> > to do something nonportable while attempting to fix a portability
> > issue. If it is really important to detect at run time if some code
> > runs on the main thread (doubtful) you should patch the code to mark
> > the main thread as such on startup with one of the available portable
> > thread local storage APIs. Alternatively you can patch out the entire
> > check from the offending create with a pkgsrc patch if you know for
> > sure it's initialization is running on the main thread.
>
> The upstream project created a tentative fix for this issue already.
>
> https://github.com/rust-windowing/winit/pull/1664/commits/b1a90fd5c52ac2aff45558ff932a61892859859e
>
> I added it to wip. The package seems to works fine for me now.
> Shows a terminal window.
This modification also solved the dynamic libraries problem. However,
I am still getting
thread 'main' panicked at 'Failed to open input method: PotentialInputMethods {
xmodifiers: None,
fallbacks: [
PotentialInputMethod {
name: "@im=local",
successful: Some(
false,
),
},
PotentialInputMethod {
name: "@im=",
successful: Some(
false,
),
},
],
_xim_servers: Err(
GetPropertyError(
TypeMismatch(
0,
),
),
),
}', /usr/pkgsrc/lang/rust/work/rustc-1.44.1-src/src/libstd/macros.rs:13:23
stack backtrace:
0: ::fmt
1: core::fmt::write
2: std::io::Write::write_fmt
3: std::panicking::default_hook::{{closure}}
4: std::panicking::rust_panic_with_hook
5: std::panicking::begin_panic
at
/usr/pkgsrc/lang/rust/work/rustc-1.44.1-src/src/libstd/panicking.rs:438
6: winit::platform_impl::platform::x11::EventLoop::new
at
/usr/pkgsrc/lang/rust/work/rustc-1.44.1-src/src/libstd/macros.rs:13
7: winit::platform_impl::platform::EventLoop::new_x11_any_thread
at
/usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:594
8: winit::platform_impl::platform::EventLoop::new_any_thread
at
/usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:560
9: winit::platform_impl::platform::EventLoop::new
at
/usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:533
10: winit::event_loop::EventLoop::with_user_event
at
/usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/event_loop.rs:129
11: alacritty::main
at alacritty/src/main.rs:81
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
with
$ locale
LANG="en_GB.UTF-8"
LC_CTYPE="en_GB.UTF-8"
LC_COLLATE="C"
LC_TIME="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_ALL=""
No idea why; tested with xfce4 and xmonad.
>
> -Tobias
Chavdar
--
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Sun, 23 Aug 2020 at 19:57, 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. I meant - it doesn't crash, but it still can't boot from the ISO, as you said. I perform the installation using normal BIOS, then I switch. Doesn't make sense, I know. > > > > -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. > > > > Chavdar > > -- > --
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Sun, 23 Aug 2020 at 21:01, Chavdar Ivanov wrote: > > On Sun, 23 Aug 2020 at 19:57, 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. > > I meant - it doesn't crash, but it still can't boot from the ISO, as you said. > > I perform the installation using normal BIOS, then I switch. Doesn't > make sense, I know. > > > > > > > > -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. > > > > > I was able to boot EFI and install yesterday's -current using qemu-system-x86_64 \ -m 3072 \ -machine q35 \ -accel nvmm \ -device qemu-xhci \ -device usb-tablet \ -k en-gb \ -smp 2 \ -cdrom /iso/NetBSD-9.99.71-amd64.iso \ -vnc :1 \ -net tap,fd=3 3<>/dev/tap1 \ -net nic \ -bios /usr/pkg/share/ovmf/OVMFX64.fd \ -drive format=raw,file=/dev/zvol/rdsk/tank/ztest > > Chavdar > > > > -- > > > > > > -- > --
Re: QEMU booting of non-NetBSD CDs and virtual HDs
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 c
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 --
-current build failure
Hi, I am getting: --- install-tests --- --- /home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile --- # install /home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile /home/sysbuild/amd64/tools/bin/x86_64--netbsd-install -U -M /home/sysbuild/amd64/destdir/METALOG -D /home/sysbuild/amd64/destdir -h sha256 -N /home/sysbuild/src/etc -c -p -r -o root -g wheel -m 444 Atffile /home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile --- install-external --- --- install-doc --- --- install-share --- install ===> share/man/man8/man8.sgimips --- install-tests --- x86_64--netbsd-install: /home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile.inst.dY8rCE: mkstemp: No such file or directory *** [/home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile] Error code 1 --- install-external --- install ===> external/gpl2/groff/doc --- install-share --- --- install-sys --- ERROR: Failed to make release . --
Re: -current amd64 build failure
On Thu, 24 Sep 2020 at 10:45, matthew green wrote: > > Chavdar Ivanov writes: > > /home/sysbuild/src/usr.sbin/crash/../../sys/arch/amd64/amd64/db_disasm.c:41: > > /home/sysbuild/src/usr.sbin/crash/../../sys/sys/ksyms.h:147:1: error: > > unknown type name 'bool' > > 147 | bool ksyms_available(void); > > | ^~~~ > > should be fixed now. make sure you have sys/ksyms.h 1.39. That was fixed, thanks; now I get: === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/share/man/html3/getentropy.html ./usr/share/man/man3/getentropy.3 = end of 2 extra files === *** [checkflist] Error code 1 --
-current amd64 build failure
Hi, Fourth time in a row for me; after cleaning obj and a 'make cleandir' in src: --- dependall-usr.sbin --- In file included from /home/sysbuild/src/usr.sbin/crash/../../sys/arch/amd64/amd64/db_disasm.c:41: /home/sysbuild/src/usr.sbin/crash/../../sys/sys/ksyms.h:147:1: error: unknown type name 'bool' 147 | bool ksyms_available(void); | ^~~~ Chavdar --
Re: current fails to build on amd64
$ uname -a
NetBSD ymir 9.99.73 NetBSD 9.99.73 (GENERIC) #7: Sat Sep 19 10:58:21
BST 2020
sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
amd64
$ gcc --version
gcc (nb1 20200907) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
It builds for me. I did remove the obj directory before the first
build expecting to bring gcc 9.3; I also - by old custom - run 'make
cleandir' in src and xsrc, whenever I remove the obj folder.
I've got another hour or so doing 'pkg_rolling-replace', then I am
going to build -current.
On Mon, 21 Sep 2020 at 18:21, Nikita Gillmann wrote:
>
> This is with a recent checkout after gcc9 import. If no one can
> reproduce this, what can I do?
>
> #create libstdc++-v3/cow-fs_dir.d
> CC=/usr/src/../tools/bin/x86_64--netbsd-c++
> /usr/src/../tools/bin/nbmkdep -f cow-fs_dir.d.tmp --
> -I/usr/src/../obj/destdir.amd64/usr/include/g++/backward
> --sysroot=/usr/src/../obj/destdir.amd64
> -I/usr/src/external/gpl3/gcc/dist/gcc
> -I/usr/src/external/gpl3/gcc/dist/include
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/libsupc++
> -I/usr/src/external/gpl3/gcc/dist/libgcc
> -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/../libstdc++-v3/arch/x86_64
> -I. -DHAVE_STDLIB_H -DHAVE_STRING_H
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/include
> -I/usr/src/external/gpl3/gcc/di
> st/gcc/config/i386
> -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64
> -D_GLIBCXX_SHARED -DGTHREAD_USE_WEAK -DSUPPORTS_WEAK
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/config/locale/
> dragonfly -Wp,-fno-canonical-system-headers -std=gnu++17
> -fimplicit-templates
> /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc &&
> mv -f cow-fs_dir.d.tmp cow-fs_dir.d
> In file included from
> /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
> /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/fs_dir.cc:29:10:
> fatal error: bits/largefile-config.h: No such file or directory
>29 | #include
> | ^
> compilation terminated.
> nbmkdep: compile failed.
>
> *** Failed target: cow-fs_dir.d
> *** Failed command: CC=/usr/src/../tools/bin/x86_64--netbsd-c++
> /usr/src/../tools/bin/nbmkdep -f cow-fs_dir.d.tmp --
> -I/usr/src/../obj/destdir.amd64/usr/include/g++/backward
> --sysroot=/usr/src/../obj/destdir.amd64
> -I/usr/src/external/gpl3/gcc/dist/gcc
> -I/usr/src/external/gpl3/gcc/dist/include
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/libsupc++
> -I/usr/src/external/gpl3/gcc/dist/libgcc
> -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/../libstdc++-v3/arch/x86_64
> -I. -DHAVE_STDLIB_H -DHAVE_STRING_H
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/include
> -I/usr/src/external/gpl3/gcc/dist/gcc/config/i386
> -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64
> -D_GLIBCXX_SHARED -DGTHREAD_USE_WEAK -DSUPPORTS_WEAK
> -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/config/locale/dragonfly
> -Wp,-fno-canonical-system-headers -std=gnu++17 -fimplicit-templates
> /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc &&
> mv -f cow-fs_dir.d.tmp cow-fs_dir.d
> *** Error code 1
>
> Stop.
> nbmake[5]: stopped in /usr/src/external/gpl3/gcc/lib/libstdc++-v3
> *** Failed target: dependall-../external/gpl3/gcc/lib/libstdc++-v3
> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
> this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
> real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
> ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
> /usr/src/../tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _ma
> kedirtarget ../external/gpl3/gcc/lib/libstdc++-v3 dependall
> *** Error code 1
>
> *** Failed target: build_install
> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
> this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
> real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
> ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
> /usr/src/../tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _ma
> kedirtarget . dependall-../external/bsd/librtld_db/lib
> dependall-../external/cddl/osnet/lib/libctf
> dependall-../external/public-domain/xz/lib
> dependall-../crypto/external/bsd/netpgp/libmj dep
> endall-../crypto/external/bsd/netpgp/lib/verify
> dependall-../external/bsd/blocklist/lib
> dependall-../external/bsd/elftoolchain/lib/libdwarf
> dependall-../external/mit/lua/lib dependall-libcurs
> es dependall-libdm dependall-libedit dependall-libexecinfo
> dependall-libppath dependall-libperfuse dependall-libquota
> dependall-librefuse dependall-libisns dependall-librumphijack dependall-l
> ibrumpres
Re: -current amd64 build failure
On Thu, 24 Sep 2020 at 12:30, Chavdar Ivanov wrote: > > On Thu, 24 Sep 2020 at 10:45, matthew green wrote: > > > > Chavdar Ivanov writes: > > > /home/sysbuild/src/usr.sbin/crash/../../sys/arch/amd64/amd64/db_disasm.c:41: > > > /home/sysbuild/src/usr.sbin/crash/../../sys/sys/ksyms.h:147:1: error: > > > unknown type name 'bool' > > > 147 | bool ksyms_available(void); > > > | ^~~~ > > > > should be fixed now. make sure you have sys/ksyms.h 1.39. > > That was fixed, thanks; now I get: > > === 2 extra files in DESTDIR = > Files in DESTDIR but missing from flist. > File is obsolete or flist is out of date ? > -- > ./usr/share/man/html3/getentropy.html > ./usr/share/man/man3/getentropy.3 > = end of 2 extra files === The build finished OK after I removed the two files from destdir, as expected. Apparently they have been obsoleted just after I initiated my last overnight full build from scratch. > *** [checkflist] Error code 1 > > > > > > -- > --
Re: mesalib abort
FWIW I ran glmark2 on amd64-current as of two days ago without any
problems. I also use only native Xorg. I'll try it once more with
today's current.
On Thu, 17 Sep 2020 at 14:42, Martin Husemann wrote:
>
> On Thu, Sep 17, 2020 at 02:11:13PM +0100, Patrick Welche wrote:
> > #2 0x7f7ff160c63d in pthread_create (thread=0x2f9d,
> > thread@entry=0x7f7fd588, attr=attr@entry=0x0,
> > startfunc=startfunc@entry=0x7f7fed764930 ,
> > arg=arg@entry=0x7f7ff7e9f230) at /usr/src/lib/libpthread/pthread.c:404
>
> That is:
>
> if (__predict_false(__uselibcstub)) {
> pthread__errorfunc(__FILE__, __LINE__, __func__,
> "pthread_create() requires linking with -lpthread");
> return __libc_thr_create_stub(thread, attr, startfunc, arg);
> }
>
>
> So "something" needs to be linked with -pthread but isn't.
>
> Martin
--
Re: cmake hanging
On Sun, 24 May 2020 at 16:39, Joerg Sonnenberger wrote: > > On Sun, May 24, 2020 at 09:22:41AM +0100, Chavdar Ivanov wrote: > > While doing pkg_rolling-replace on amd64 -current from yesterday, I > > got three times in a row a hang in cmake as the followingL > > Please attach with gdb and run "thread apply all bt" and give me the > result. There are still two issues in/around cmake I'm trying to > identify, so it would be interesting to know which of the two you are > hitting. Will do if I hit it again; I restarted pkg_rolling-replace and it has been going well since then. > > Joerg Chavdar --
Re: cmake hanging
On Sun, 24 May 2020 at 17:11, Chavdar Ivanov wrote: > > On Sun, 24 May 2020 at 16:39, Joerg Sonnenberger wrote: > > > > On Sun, May 24, 2020 at 09:22:41AM +0100, Chavdar Ivanov wrote: > > > While doing pkg_rolling-replace on amd64 -current from yesterday, I > > > got three times in a row a hang in cmake as the followingL > > > > Please attach with gdb and run "thread apply all bt" and give me the > > result. There are still two issues in/around cmake I'm trying to > > identify, so it would be interesting to know which of the two you are > > hitting. > > Will do if I hit it again; I restarted pkg_rolling-replace and it has > been going well since then. I tried in a short (10x) loop to build and clean the package which caused cmake to hang; it didn't take place. > > > > > Joerg > > Chavdar > > -- > --
Panic on -current, apparently NFS-related
Hi, On yesterday's -current amd64 I just got: ... crash$ crash -M netbsd.17.core -N netbsd.17 Crash version 9.99.64, image version 9.99.64. crash: _kvm_kvatop(0) Kernel compiled without options LOCKDEBUG. System panicked: Bad nfs svc reply Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NARCNET() at 0 _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf do_nfssvc() at do_nfssvc+0x1631 syscall() at syscall+0x26e --- syscall (number 155) --- syscall+0x26e: crash> ... I was browsing the system from a Windows 10 NFS client workstation at the time of the panic. Chavdar --
Failure to build -current - lapic_reset
Hi, EVen after 'make cleandir' and removing the obj directory, I get three times in a row: # compile GENERIC/if_media_80.o /home/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float -mindirect-branch=thunk -mindirect-branch-registe r -ffreestanding -fno-zero-initialized-in-bss -fno-delete-null-pointer-checks -g -O2 -fno-omit-frame-pointer -fstack-protector -Wstack-protector --param ssp-buffer-size= 1 -fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wold-style-defini tion -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Wold-style-definition -Wno-sign -compare --sysroot=/home/sysbuild/amd64/destdir -Damd64 -Dx86_64 -I. -I/home/sysbuild/src/sys/external/mit/xen-include-public/dist/ -I/home/sysbuild/src/sys/external/bsd /acpica/dist -I/home/sysbuild/src/sys/external/bsd/libnv/dist -I/home/sysbuild/src/sys/../common/lib/libx86emu -I/home/sysbuild/src/sys/../common/lib/libc/misc -I/home/s ysbuild/src/sys/../common/include -I/home/sysbuild/src/sys/arch -I/home/sysbuild/src/sys -nostdinc -DCOMPAT_UTILS -D__XEN_INTERFACE_VERSION__=0x3020a -DDIAGNOSTIC -DCOMP AT_44 -DDISKLABEL_EI -D_KERNEL -D_KERNEL_OPT -std=gnu99 -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/quad -I/home/sysbuild/src/sys/lib/libkern/../../../ common/lib/libc/string -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/arch/x86_64/string -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/has h/sha3 -D_FORTIFY_SOURCE=2 -I/home/sysbuild/src/sys/external/isc/atheros_hal/dist -I/home/sysbuild/src/sys/external/isc/atheros_hal/ic -I/home/sysbuild/src/sys/external/ bsd/common/include -I/home/sysbuild/src/sys/external/bsd/common/include -I/home/sysbuild/src/sys/external/bsd/drm2/include -I/home/sysbuild/src/sys/external/bsd/drm2/inc lude -I/home/sysbuild/src/sys/external/bsd/drm2/include/drm -I/home/sysbuild/src/sys/external/bsd/common/include -I/home/sysbuild/src/sys/external/bsd/drm2/dist/include -I/home/sysbuild/src/sys/external/bsd/drm2/dist/include/drm -I/home/sysbuild/src/sys/external/bsd/drm2/dist/uapi -I/home/sysbuild/src/sys/external/bsd/drm2/dist -D__KERN EL__ -DCONFIG_BACKLIGHT_CLASS_DEVICE=0 -DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0 -DCONFIG_DRM_FBDEV_EMULATION=1 -DCONFIG_FB=0 -I/home/sysbuild/src/sys/../common/include - I/home/sysbuild/src/sys/external/bsd/libnv/dist -I/home/sysbuild/src/sys/external/bsd/drm2/i915drm -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/i915 -DCONFIG_DRM_ I915_FBDEV=1 -DCONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=0 -DCONFIG_DRM_FBDEV_EMULATION=1 -I/home/sysbuild/src/sys/external/bsd/drm2/include/radeon -I/home/sysbuild/src/sys /external/bsd/drm2/radeon -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/amd/include -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/radeon -I/home/sysbuild/src /sys/external/bsd/drm2/dist/drm/nouveau -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/nouveau/include -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/nouveau/i nclude/nvkm -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm -I/home/sysbuild/src/sys/external/bsd/drm2/nouveau -DCONFIG_NOUVEAU_DEBUG=5 -DCONFIG_NOUVEAU _DEBUG_DEFAULT=3 -I/home/sysbuild/src/sys/external/bsd/acpica/dist/include -c /home/sysbuild/src/sys/compat/common/if_media_80.c -o if_media_80.o --- kern-INSTALL --- /home/sysbuild/src/sys/arch/x86/x86/lapic.c: In function 'lapic_delay': /home/sysbuild/src/sys/arch/x86/x86/lapic.c:749:4: error: implicit declaration of function 'lapic_reset'; did you mean 'acpi_reset'? [-Werror=implicit-function-declaration] lapic_reset(); ^~~ acpi_reset .. --
Re: Failure to build -current - lapic_reset
Done, build completed. On Wed, 20 May 2020 at 09:39, SAITOH Masanobu wrote: > > On 2020/05/20 17:33, Chavdar Ivanov wrote: > > Hi, > > > > EVen after 'make cleandir' and removing the obj directory, I get three > > times in a row: > > > > # compile GENERIC/if_media_80.o > > /home/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -mcmodel=kernel > > -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float > > -mindirect-branch=thunk -mindirect-branch-registe > > r -ffreestanding -fno-zero-initialized-in-bss > > -fno-delete-null-pointer-checks -g -O2 -fno-omit-frame-pointer > > -fstack-protector -Wstack-protector --param ssp-buffer-size= > > 1 -fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main > > -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes > > -Wstrict-prototypes -Wold-style-defini > > tion -Wswitch -Wshadow -Wcast-qual -Wwrite-strings > > -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes -Wextra > > -Wno-unused-parameter -Wold-style-definition -Wno-sign > > -compare --sysroot=/home/sysbuild/amd64/destdir -Damd64 -Dx86_64 -I. > > -I/home/sysbuild/src/sys/external/mit/xen-include-public/dist/ > > -I/home/sysbuild/src/sys/external/bsd > > /acpica/dist -I/home/sysbuild/src/sys/external/bsd/libnv/dist > > -I/home/sysbuild/src/sys/../common/lib/libx86emu > > -I/home/sysbuild/src/sys/../common/lib/libc/misc -I/home/s > > ysbuild/src/sys/../common/include -I/home/sysbuild/src/sys/arch > > -I/home/sysbuild/src/sys -nostdinc -DCOMPAT_UTILS > > -D__XEN_INTERFACE_VERSION__=0x3020a -DDIAGNOSTIC -DCOMP > > AT_44 -DDISKLABEL_EI -D_KERNEL -D_KERNEL_OPT -std=gnu99 > > -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/quad > > -I/home/sysbuild/src/sys/lib/libkern/../../../ > > common/lib/libc/string > > -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/arch/x86_64/string > > -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/has > > h/sha3 -D_FORTIFY_SOURCE=2 > > -I/home/sysbuild/src/sys/external/isc/atheros_hal/dist > > -I/home/sysbuild/src/sys/external/isc/atheros_hal/ic > > -I/home/sysbuild/src/sys/external/ > > bsd/common/include > > -I/home/sysbuild/src/sys/external/bsd/common/include > > -I/home/sysbuild/src/sys/external/bsd/drm2/include > > -I/home/sysbuild/src/sys/external/bsd/drm2/inc > > lude -I/home/sysbuild/src/sys/external/bsd/drm2/include/drm > > -I/home/sysbuild/src/sys/external/bsd/common/include > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist/include > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist/include/drm > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist/uapi > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist -D__KERN > > EL__ -DCONFIG_BACKLIGHT_CLASS_DEVICE=0 > > -DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0 > > -DCONFIG_DRM_FBDEV_EMULATION=1 -DCONFIG_FB=0 > > -I/home/sysbuild/src/sys/../common/include - > > I/home/sysbuild/src/sys/external/bsd/libnv/dist > > -I/home/sysbuild/src/sys/external/bsd/drm2/i915drm > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/i915 -DCONFIG_DRM_ > > I915_FBDEV=1 -DCONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=0 > > -DCONFIG_DRM_FBDEV_EMULATION=1 > > -I/home/sysbuild/src/sys/external/bsd/drm2/include/radeon > > -I/home/sysbuild/src/sys > > /external/bsd/drm2/radeon > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/amd/include > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/radeon > > -I/home/sysbuild/src > > /sys/external/bsd/drm2/dist/drm/nouveau > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/nouveau/include > > -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/nouveau/i > > nclude/nvkm -I/home/sysbuild/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm > > -I/home/sysbuild/src/sys/external/bsd/drm2/nouveau > > -DCONFIG_NOUVEAU_DEBUG=5 -DCONFIG_NOUVEAU > > _DEBUG_DEFAULT=3 > > -I/home/sysbuild/src/sys/external/bsd/acpica/dist/include -c > > /home/sysbuild/src/sys/compat/common/if_media_80.c -o if_media_80.o > > --- kern-INSTALL --- > > /home/sysbuild/src/sys/arch/x86/x86/lapic.c: In function 'lapic_delay': > > /home/sysbuild/src/sys/arch/x86/x86/lapic.c:749:4: error: implicit > > declaration of function 'lapic_reset'; did you mean 'acpi_reset'? > > [-Werror=implicit-function-declaration] > > lapic_reset(); > > ^~~ > > Please update the latest x86/lapic.c > > Thanks. > > > acpi_reset > > > > .. > > > > > > > -- > --- > SAITOH Masanobu (msai...@execsw.org > msai...@netbsd.org) --
Re: cmake hanging
On Sun, 20 Sep 2020 at 19:58, Joerg Sonnenberger wrote: > > On Sun, Sep 20, 2020 at 02:06:42PM +0100, Chavdar Ivanov wrote: > > I am not seeing other people report these lately, but I still continue > > to get these hangings, e.g. when running git as part of a zsh prompt > > function; roughly every fourth command ends up with one of these, > > again as before, it is enough to attach with gdb to the got process > > and quit in order for it to complete. Here is another trace, -current > > is 9.99.73 from yesterday: > > Sure, nothing changed. I don't think this is really the fault of > jemalloc, from earlier debugging the real problem is that the wait list > got messed up. The weird thing is, attaching with gdb and then quitting sorts it out... > > Joerg --
Re: cmake hanging
I am not seeing other people report these lately, but I still continue to get these hangings, e.g. when running git as part of a zsh prompt function; roughly every fourth command ends up with one of these, again as before, it is enough to attach with gdb to the got process and quit in order for it to complete. Here is another trace, -current is 9.99.73 from yesterday: [Switching to LWP 26563 of process 23529] 0x7a81318a86ea in ___lwp_park60 () from /usr/lib/libc.so.12 (gdb) thread apply all bt Thread 2 (LWP 23529 of process 23529): #0 0x7a813184554a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x7a813200c7a2 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x0054ba92 in preload_index () #3 0x0055a3e8 in refresh_index () #4 0x00425510 in cmd_status () #5 0x004053fe in handle_builtin () #6 0x00406301 in cmd_main () #7 0x005ed143 in main () Thread 1 (LWP 26563 of process 23529): #0 0x7a81318a86ea in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7a813200975e in ?? () from /usr/lib/libpthread.so.1 #2 0x7a81318d6646 in je_malloc_mutex_lock_slow () from /usr/lib/libc.so.12 #3 0x7a813190dd76 in je_arena_choose_hard () from /usr/lib/libc.so.12 #4 0x7a81318b436d in je_tsd_tcache_data_init () from /usr/lib/libc.so.12 #5 0x7a81318b45ae in je_tsd_tcache_enabled_data_init () from /usr/lib/libc.so.12 #6 0x7a81318b1729 in je_tsd_fetch_slow () from /usr/lib/libc.so.12 #7 0x7a813190e0bc in malloc () from /usr/lib/libc.so.12 #8 0x005ce9fb in xrealloc () #9 0x005a2e20 in strbuf_grow () #10 0x005ad07b in lstat_cache_matchlen () #11 0x005ad1b5 in threaded_has_symlink_leading_path () #12 0x0054b808 in preload_thread () #13 0x7a813200bf4e in ?? () from /usr/lib/libpthread.so.1 #14 0x7a8131892480 in ?? () from /usr/lib/libc.so.12 #15 0x in ?? () On Tue, 1 Sep 2020 at 10:39, Chavdar Ivanov wrote: > > Another one, overnight, while building gimp, by gegl, attached. > > As I mentioned earlier, it is enough to attach to the process with gdb > and then quit in order for the process to carry on working and > complete the build. > > On Tue, 1 Sep 2020 at 08:55, Tom Ivar Helbekkmo wrote: > > > > Chavdar Ivanov writes: > > > > > I am having the same cmake hangs as in this thread. I've attached the > > > gdb 'thread apply all bt' output (collected with script). > > > > That looks suspiciouly similar to the hangs I'm seeing with dhcpd on > > amd64-current (note the mutex lock attempt, while nothing else looks > > very interesting): > > > > (gdb) thread apply all bt > > > > Thread 7 (process 12269): > > #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > > #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e573fd67d08, > > mutex=0x7e573fd67cd8, abstime=0x0) at > > /usr/src/lib/libpthread/pthread_cond.c:167 > > #2 0x7e573f01ed2e in isc_app_ctxrun (ctx=0x7e573fd67c80) at > > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/app.c:340 > > #3 0x5664e624 in dispatch () at > > /usr/src/external/mpl/dhcp/lib/common/../../dist/common/dispatch.c:121 > > #4 0x5668aae7 in main (argc=, argv=) > > at /usr/src/external/mpl/dhcp/bin/server/../../dist/server/dhcpd.c:1114 > > > > Thread 6 (process 21463): > > #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > > #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e5740037850, > > mutex=0x7e5740037800, abstime=0x0) at > > /usr/src/lib/libpthread/pthread_cond.c:167 > > #2 0x7e573f02a0a4 in dispatch (threadid=, > > manager=0x7e5740036800) at > > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/task.c:1059 > > #3 run (queuep=) at > > /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/task.c:1346 > > #4 0x7e573e80bee0 in pthread__create_tramp (cookie=0x7e574002e000) at > > /usr/src/lib/libpthread/pthread.c:560 > > #5 0x7e573a2924e0 in ?? () from /usr/lib/libc.so.12 > > #6 0x0040 in ?? () > > #7 0x7e573980 in ?? () > > #8 0x001003a0efff in ?? () > > #9 0x7e57396000c0 in ?? () > > #10 0x001fff40 in ?? () > > #11 0x in ?? () > > > > Thread 5 (process 19116): > > #0 0x7e573a244d8a in _sys___kevent50 () from /usr/lib/libc.so.12 > > #1 0x7e573e8079d8 in __kevent50 (fd=, ev=ev@entry=0x0, > > nev=nev@entry=0, rev=rev@entry=0x7e5740008000, nrev=nrev@entry=64, > > ts=ts@entry=0x0) at /usr/src/lib/libpthread/pthread_cancelstub.c:176 > > #2 0x7e573f0223c4 in netthread (uap=0x7e5740039800) at > > /usr/src/external/mpl
Re: cmake hanging
On Sun, 20 Sep 2020 at 19:02, Jared McNeill wrote: > > Still happens to me with a -current kernel and -9 chroot. Captured today: > > http://www.invisible.ca/tmp/cmake.txt je_malloc_mutex_lock_slow is seen in the both traces in one of the threads (weird that all of them are trying to mknod...). The same call is seen in my trace. > > > > On Sun, 20 Sep 2020, Chavdar Ivanov wrote: > > > I am not seeing other people report these lately, but I still continue > > to get these hangings, e.g. when running git as part of a zsh prompt > > function; roughly every fourth command ends up with one of these, > > again as before, it is enough to attach with gdb to the got process > > and quit in order for it to complete. Here is another trace, -current > > is 9.99.73 from yesterday: > > > > [Switching to LWP 26563 of process 23529] > > 0x7a81318a86ea in ___lwp_park60 () from /usr/lib/libc.so.12 > > (gdb) thread apply all bt > > > > Thread 2 (LWP 23529 of process 23529): > > #0 0x7a813184554a in _lwp_wait () from /usr/lib/libc.so.12 > > #1 0x7a813200c7a2 in pthread_join () from /usr/lib/libpthread.so.1 > > #2 0x0054ba92 in preload_index () > > #3 0x0055a3e8 in refresh_index () > > #4 0x00425510 in cmd_status () > > #5 0x004053fe in handle_builtin () > > #6 0x00406301 in cmd_main () > > #7 0x005ed143 in main () > > > > Thread 1 (LWP 26563 of process 23529): > > #0 0x7a81318a86ea in ___lwp_park60 () from /usr/lib/libc.so.12 > > #1 0x7a813200975e in ?? () from /usr/lib/libpthread.so.1 > > #2 0x7a81318d6646 in je_malloc_mutex_lock_slow () from > > /usr/lib/libc.so.12 > > #3 0x7a813190dd76 in je_arena_choose_hard () from /usr/lib/libc.so.12 > > #4 0x7a81318b436d in je_tsd_tcache_data_init () from > > /usr/lib/libc.so.12 > > #5 0x7a81318b45ae in je_tsd_tcache_enabled_data_init () from > > /usr/lib/libc.so.12 > > #6 0x7a81318b1729 in je_tsd_fetch_slow () from /usr/lib/libc.so.12 > > #7 0x7a813190e0bc in malloc () from /usr/lib/libc.so.12 > > #8 0x005ce9fb in xrealloc () > > #9 0x005a2e20 in strbuf_grow () > > #10 0x005ad07b in lstat_cache_matchlen () > > #11 0x005ad1b5 in threaded_has_symlink_leading_path () > > #12 0x0054b808 in preload_thread () > > #13 0x7a813200bf4e in ?? () from /usr/lib/libpthread.so.1 > > #14 0x7a8131892480 in ?? () from /usr/lib/libc.so.12 > > #15 0x in ?? () > > > > On Tue, 1 Sep 2020 at 10:39, Chavdar Ivanov wrote: > >> > >> Another one, overnight, while building gimp, by gegl, attached. > >> > >> As I mentioned earlier, it is enough to attach to the process with gdb > >> and then quit in order for the process to carry on working and > >> complete the build. > >> > >> On Tue, 1 Sep 2020 at 08:55, Tom Ivar Helbekkmo > >> wrote: > >>> > >>> Chavdar Ivanov writes: > >>> > >>>> I am having the same cmake hangs as in this thread. I've attached the > >>>> gdb 'thread apply all bt' output (collected with script). > >>> > >>> That looks suspiciouly similar to the hangs I'm seeing with dhcpd on > >>> amd64-current (note the mutex lock attempt, while nothing else looks > >>> very interesting): > >>> > >>> (gdb) thread apply all bt > >>> > >>> Thread 7 (process 12269): > >>> #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > >>> #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e573fd67d08, > >>> mutex=0x7e573fd67cd8, abstime=0x0) at > >>> /usr/src/lib/libpthread/pthread_cond.c:167 > >>> #2 0x7e573f01ed2e in isc_app_ctxrun (ctx=0x7e573fd67c80) at > >>> /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/app.c:340 > >>> #3 0x5664e624 in dispatch () at > >>> /usr/src/external/mpl/dhcp/lib/common/../../dist/common/dispatch.c:121 > >>> #4 0x5668aae7 in main (argc=, argv= >>> out>) at > >>> /usr/src/external/mpl/dhcp/bin/server/../../dist/server/dhcpd.c:1114 > >>> > >>> Thread 6 (process 21463): > >>> #0 0x7e573a2a892a in ___lwp_park60 () from /usr/lib/libc.so.12 > >>> #1 0x7e573e80a9a9 in pthread_cond_timedwait (cond=0x7e5740037850, > >>> mutex=0x7e5740037800, abstime=0x0) at > >>> /usr/src/lib/libpthread/pthread_cond.c:167 > >>>
Re: Failure to build current amd64
On Wed, 15 Jul 2020 at 18:32, Arthur Barlow wrote: > > This was updated from cvs about 10:00 am BST. The failure seems to happen > when trying to link libgssapi with compat/amd64/i386 libraries. The error > message(s) below: I had a successful build at about 15:00. > > dependall ===> > compat/amd64/i386/../../../lib/../crypto/external/bsd/heimdal/lib/libheimntlm > dependall ===> > compat/amd64/i386/../../../lib/../crypto/external/bsd/heimdal/lib/libkdc > dependall ===> > compat/amd64/i386/../../../lib/../crypto/external/bsd/heimdal/lib/libgssapi > # build libgssapi/libgssapi.so.11.0 > rm -f libgssapi.so.11.0 > /usr/src/../tools/bin/x86_64--netbsd-gcc -shared -Wl,-soname,libgssapi.so.11 > -Wl,--warn-shared-textrel -Wl,-Map=libgssapi.so.11.map -m32 > --sysroot=/usr/src/../obj/destdir.amd64 -Wl,-z,relro > -Wl,--version-script=/usr/src/crypto/external/bsd/heimdal/dist/lib/gssapi/version-script.map > -o libgssapi.so.11.0.tmp -Wl,-rpath,/usr/lib/i386 -L=/usr/lib/i386 -Wl,-x > -Wl,--whole-archive libgssapi_pic.a -Wl,--no-whole-archive -m32 > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libkrb5 > -lkrb5 > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libasn1 > -lasn1 > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libcom_err > -lcom_err > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libroken > -lroken > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libheimbase > -lheimbase > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libheimntlm > -lheimntlm > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/openssl/lib/libcrypto > -lcrypto > /usr/tools/bin/../lib/gcc/x86_64--netbsd/8.4.0/../../../../x86_64--netbsd/bin/ld: > libgssapi_pic.a: member libgssapi_pic.a(ntlm__delete_sec_context.pico) in > archive is not an object > collect2: error: ld returned 1 exit status > > *** Failed target: libgssapi.so.11.0 > *** Failed command: /usr/src/../tools/bin/x86_64--netbsd-gcc -shared > -Wl,-soname,libgssapi.so.11 -Wl,--warn-shared-textrel > -Wl,-Map=libgssapi.so.11.map -m32 --sysroot=/usr/src/../obj/destdir.amd64 > -Wl,-z,relro > -Wl,--version-script=/usr/src/crypto/external/bsd/heimdal/dist/lib/gssapi/version-script.map > -o libgssapi.so.11.0.tmp -Wl,-rpath,/usr/lib/i386 -L=/usr/lib/i386 -Wl,-x > -Wl,--whole-archive libgssapi_pic.a -Wl,--no-whole-archive -m32 > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libkrb5 > -lkrb5 > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libasn1 > -lasn1 > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libcom_err > -lcom_err > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libroken > -lroken > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libheimbase > -lheimbase > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/heimdal/lib/libheimntlm > -lheimntlm > -L/usr/src/../obj/compat/amd64/i386/crypto/external/bsd/openssl/lib/libcrypto > -lcrypto > *** Error code 1 > > Stop. > nbmake[9]: stopped in /usr/src/crypto/external/bsd/heimdal/lib/libgssapi --
early tools -current build failure
Hi,
My attempt to build -current amd64 failed twice today; after the first
failure I moved aside the obj and tools directory and did 'make
cleandir', essentially starting from scratch; it failed identically:
...
build.sh command:./build.sh -D/home/sysbuild/amd64/destdir
-M/home/sysbuild/amd64/obj -N2 -R/home/sysbuild/release
-T/home/sysbuild/amd64/tools -U -X/home/sysbuild/xsrc -j4 -mamd64 -u
-x release iso-image
..
cc -D_PATH_DEFSYSPATH="/home/sysbuild/src/share/mk"
-DDEFSHELL_CUSTOM="/bin/sh" -DHAVE_SETENV=1 -DHAVE_STRDUP=1
-DHAVE_STRERROR=1 -DHAVE_STRFTIME=1 -DHAVE_VSNPRINTF=1 -O -c
/home/sysbuild/src/usr.bin/make/lst.lib/lstSucc.c
cc -o nbmake *.o
===> MAKECONF file: /etc/mk.conf
#objdir /home/sysbuild/amd64/obj/home/sysbuild/src/tools
nbmake: "/home/sysbuild/src/share/mk/bsd.nls.mk" line 18: Unknown directive
nbmake: "/home/sysbuild/src/share/mk/bsd.nls.mk" line 19: Unknown directive
nbmake: Fatal errors encountered -- cannot continue
ERROR: bomb_getmakevar TOOLDIR: /tmp/nbbuild81/nbmake failed
*** BUILD ABORTED ***
sysbuild: W: Command failed with code 1
--
Any ideas? Perhaps I've missed something new in the BUILDING file?
there is nothing particular in these two lines of the bsd.nls.mk:
.
# Build rules
.if ${MKNLS} != "no"
NLSALL= ${NLS:.msg=.cat}
realall:${NLSALL} < 18
.NOPATH:${NLSALL}
.SUFFIXES: .cat .msg
.
Chavdar
Re: nvmm under -current not functional since at least 11th of July
On Sat, 18 Jul 2020 at 13:11, Chavdar Ivanov wrote: > > Hi > > I posted several panic traces and descriptions, but to netbsd-users; I > can see the posts, but apparently either nobody is using nvmm under > -current or posting to netbsd-users was too unspecific, hence I am > asking - is this something that only I am seeing? nvmm stopped to work > sometimes after the 11th of July; if I boot older earlier kernel, the > new module (albeit from the same 9.99.69 version) panics on modload; > with matching kernel and module I get either a hard lock, a deep CPU > loop or, on occasion, a more or less regular panic. > > Ref. https://mail-index.netbsd.org/netbsd-users/2020/07/16/msg025534.html > > Chavdar Following a suggestion, I carried over a few tests with DEBUG and LOCKDEBUG enabled. This did not make any difference; starting a 64-bit Linux guest still hard-locks the machine; starting a 32-bit Windows 10 guest keeps it sort-of alive, responding to pings and able to switch between tmux windows, but no further i/o is possible; in this case one is able to go into the debugger and initiate a dump, which then failed for me after the first output line. > > > -- > --
Re: [PATCH] net/samba4: relocate Sysvol to persist between reboots & move variable data out of /usr/pkg/etc/...
On Thu, 30 Jul 2020 at 02:24, Chuck Silvers wrote: > > On Wed, Jul 29, 2020 at 06:13:03PM +0100, Chavdar Ivanov wrote: > > On Wed, 29 Jul 2020 at 08:33, Matthias Petermann > > wrote: > > > > > > Hello Chavdar, > > > > > > Am 28.07.2020 um 18:48 schrieb Chavdar Ivanov: > > > > This being a place people are trying samba4 as a DC, I got a > > > > repeatable panic on one of the systems I am trying it on, as follows: > > > > > > > > crash: _kvm_kvatop(0) > > > > Crash version 9.99.69, image version 9.99.69. > > > > Kernel compiled without options LOCKDEBUG. > > > > System panicked: /: bad dir ino 657889 at offset 0: Bad dir (not > > > > rounded), reclen=0x2e33, namlen=51, dirsiz=60 <= reclen=11827 <= > > > > maxsize=512, flags=0x2005900, entryoffsetinblock=0, dirblksiz=512 > > > > > > > > Backtrace from time of crash is available. > > > > _KERNEL_OPT_NARCNET() at 0 > > > > _KERNEL_OPT_DDB_HISTORY_SIZE() at _KERNEL_OPT_DDB_HISTORY_SIZE > > > > sys_reboot() at sys_reboot > > > > vpanic() at vpanic+0x15b > > > > snprintf() at snprintf > > > > ufs_lookup() at ufs_lookup+0x518 > > > > VOP_LOOKUP() at VOP_LOOKUP+0x42 > > > > lookup_once() at lookup_once+0x1a1 > > > > namei_tryemulroot() at namei_tryemulroot+0xacf > > > > namei() at namei+0x29 > > > > vn_open() at vn_open+0x9a > > > > do_open() at do_open+0x112 > > > > do_sys_openat() at do_sys_openat+0x72 > > > > sys_open() at sys_open+0x24 > > > > syscall() at syscall+0x26e > > > > --- syscall (number 5) --- > > > > syscall+0x26e: > > > > > > > > > > > > > that still looks like a file system inconsistency. Before the patch from > > > Chuck I also had the case several times that a filesystem that was > > > apparently repaired with fsck could no longer be trusted. After > > > importing the patched kernel, to be on the safe side, I recreated all > > > the file systems previously mounted with posix1eacls with newfs. > > > > Hard that one, as it was the root file system... Anyway, a couple of > > fsck's seem to have sorted out this one. > > how exactly did you run fsck to fix this? the most reliable way is to boot > the machine single-user, then run "fsck -fy ..." from the console shell, > then run the same fsck command again to make sure that it says that > everything is ok, then reboot. Exactly. Deep buried in my fingertip's memories is that one should fsck / in single user, twice, and reboot immediately without a 'sync'. Perhaps some old SunOS manual... > > if you have done that and are still crashing due to corruption in your > root file system, then we still have another bug in the kernel somewhere. So it seems to me; the peculiarities here are that in both cases / is a GPT slice and that I have 'log' as a mount option; it was suggested 'posix1eacls' should be used on its own. > > > > > Presumably fsck is not prepared for the kind of inconsistency, and only > > > a newfs can restore a trustworthy initial state. What is the starting > > > point for you? Has the file system been created after the patch, or has > > > it only been treated with fsck so far? > > > > I think it may have been created before the patch to the filesystem > > code, but before the second version of the samba4 package. > > > > > > > > In any case, I would advise you - if you have not already done so - to > > > use a separate partition or LVM volume for the sysvol with its own file > > > system, and to mount only this with the posix1eacls option. It seems the > > > ACL code still needs a lot of testingh, so at least you can be sure that > > > your root filesystem will not be affected. > > > > As this was running on a XCP-NG guest, I added a small 1GB disk to the > > vm, created the filesystem (-O 2) and mounted it on /var/db/samba4. > > > > I removed the 'posix1eacls' options from the other existing > > filesystems and left it only for the one mounted on /var/db/samba4 . > > In this case, the provisioning fails with a message that the > > filesystem does not support acls - so it perhaps checks the root > > filesystem after all. I then re-added this option to /, newfs'd > > /var/db/samba4, rebooted and retried the provisioning. This resulted > > in a similar to the above panic, this time after perhaps 10 minutes > > work of python8 doing database conversion from v1 to v2 - the third > > database in the list. As this was seen on the console of the XCP-NG > > guest, I took screenshots of the panic, in case someone is interested. > > yes, I'd like to see the screenshots please. I'll mail them off-list, to avoid large-ish uuencoded bits polluting the archives. > > -Chuck Chavdar --
Re: Daily packages for NetBSD/amd64 current
On Thu, 30 Jul 2020 at 08:53, Jonathan Perkin wrote: > > * On 2020-07-30 at 05:10 BST, Thomas Mueller wrote: > > > > I was going to choose 9.0, but I saw that mef@ was already producing > > > regular bulk builds on that for pkgsrc-current available here: > > > > > https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0_current/ > > > > > so went with NetBSD-current instead, though it's quite unreliable so I > > > may revisit that choice if every bulk build requires manual > > > intervention and restarts. > > > > > Jonathan Perkin - Joyent, Inc. - www.joyent.com > > > > What is "quite unreliable"? Do you mean the NetBSD-current base > > system, or do you mean the ABI that might not hold still, thereby > > breaking packages following a base-system upgrade? > > NetBSD-current. This shouldn't preclude you or anyone else using it, > the problems I'm running into are primarily limited to a bulk build > environment, but does mean that it's quite annoying for those who are > doing so. I second that. On my main build host I constantly go through the cadence of roughly daily -current updates and weekly pkgsrc -current updates (followed by pkg_rolling-replace); I also run -current on all machines, bare-metal or virtual, which I use daily; while the system itself rarely causes problems, the pkgsrc interaction with -current changes is bound to cause breaks in bulk builds, bits will have to be sorted out manually from time to time. Setting up such a bulk build host will no doubt reveal such problems earlier. > > -- > Jonathan Perkin - Joyent, Inc. - www.joyent.com Chavdar --
Re: tunefs throws mount error
On Thu, 6 Aug 2020 at 14:50, Thomas Klausner wrote: > > On Thu, Aug 06, 2020 at 01:21:34PM +0100, Chavdar Ivanov wrote: > > On Thu, 6 Aug 2020 at 13:51, Thomas Klausner wrote: > > > > > > Hi! > > > > > > I've added a new disk and newfsed it. Then I ran tunefs and saw: > > > > > > # tunefs -o time /dev/rdk10 > > > tunefs: tuning /dev/rdk10 > > > tunefs: optimization preference remains unchanged as time > > > tunefs: mount: Invalid argument > > > > $ uname -a > > NetBSD nbuild.lorien.lan 9.99.69 NetBSD 9.99.69 (GENERIC) #0: Mon Aug > > 3 20:46:23 BST 2020 > > sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > > amd64 > > $ tunefs -o time /dev/rdk1 > > tunefs: tuning /dev/rdk1 > > tunefs: optimization preference remains unchanged as time > > tunefs: mount of /dev/dk1 on / updated > > $ tunefs -o time /dev/rdk4 > > tunefs: tuning /dev/rdk4 > > tunefs: optimization preference remains unchanged as time > > tunefs: mount of /dev/dk1 on / updated > > > > (also worked on a system from earlier today). > > > > > > > > I don't remember seeing this last line before. > > > 9.99.69/amd64 > > Hm, my /dev/dk10 is not mounted. Another hm... I did the same with a non-mounted slice and got: # tunefs -o time /dev/rdk5 tunefs: tuning /dev/rdk5 tunefs: optimization preference remains unchanged as time tunefs: mount of /dev/dk1 on / updated <== Otherwise the slice gets mounted. > Thomas --
Re: virtio panic during reboot (NetBSD 9)
On Tue, 11 Aug 2020 at 17:08, Felix Deichmann wrote: > > Chavdar Ivanov schrieb am Di., 11. Aug. 2020, 18:01: >> >> That would be interesting - to see where vioscsi actually attaches. >> I've always wondered if it would be difficult to modify the vioscsi >> driver to attach under VirtualBox - as it is recognized at the moment >> as >> >> Qumranet product 1048 (SCSI mass storage, revision 0x01) at pci0 dev >> 15 function 0 not configured > > > FWIW, I have > > kern/55210: virtio lacks support for non-transitional devices acc. to VIRTIO > Spec. 1.1 Thanks, I've discussed this issue a few times, but haven't noticed the pr. Hopefully somebody will look into it to see if it is only the id range in need of an extension. > > open concerning this issue... > > Cheers, Felix Chavdar --
cvs update problems
Hi, Is there any present problem with anoncvs at the moment? I got four times in a row ... command failed with code 1 CVS update failed after a few updated entries. Chavdar --
Re: -current build failure
Hi,
Builds now.
On Sun, 9 Aug 2020 at 10:38, Chavdar Ivanov wrote:
>
> Hi,
>
> With sources just updated, I am getting:
>
> # link INSTALL_XEN3_DOMU/netbsd
> ld -Map netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020
> -e start -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ}
> vers.o swapnetbsd.o
> ld: netbsd32_mod.o: in function `amd64_oosyscall_handle':
> netbsd32_mod.c:(.text+0x111): undefined reference to `x86_cpu_is_lcall'
> *** Error code 1
> .
>
> Chavdar
>
>
> --
>
--
Re: Failure to build graphics/graphviz
On Fri, 7 Aug 2020 at 21:35, Paul Goyette wrote:
>
> > I just rebuilt it under 9.99.69 from yesterday without any problems. I
> > do not have any graphviz option changed in /etc/mk.conf. There have
> > been many changes to make recently.
>
> Hmmm. I have
>
> PKG_OPTIONS.graphviz= -lua
>
> to prevent it from using lua. Maybe the PLIST for the two extra files
> should be conditional on lua?
Correct, perhaps an error:
# grep python PLIST
${PLIST.lua}man/man3/gv.3python
${PLIST.lua}share/graphviz/doc/pdf/gv.3python.pdf
Doesn't make sense.
>
>
>
> ++--+---+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
> ++--+---+
--
Re: Failure to build graphics/graphviz
On Fri, 7 Aug 2020 at 20:50, Paul Goyette wrote: > > On Fri, 7 Aug 2020, m...@netbsd.org wrote: > > > On Thu, Aug 06, 2020 at 03:38:31PM -0700, Paul Goyette wrote: > >> Oops wrong list - please ignore > > > > It's actually a netbsd issue, but I think it'd be reasonable to > > USE_TOOLS+= gmake until it is fixed. > > Adding gmake doesn't help - fails with exact same error. > > > > http://gnats.netbsd.org/55539 > > I'll look when gnats.netbsd.org is available. I just rebuilt it under 9.99.69 from yesterday without any problems. I do not have any graphviz option changed in /etc/mk.conf. There have been many changes to make recently. > > > ++--+---+ > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > ++--+---+ --
Re: Failure to build graphics/graphviz
On Fri, 7 Aug 2020 at 21:48, Paul Goyette wrote:
>
> On Fri, 7 Aug 2020, Chavdar Ivanov wrote:
>
> > On Fri, 7 Aug 2020 at 21:35, Paul Goyette wrote:
> >>
> >>> I just rebuilt it under 9.99.69 from yesterday without any problems. I
> >>> do not have any graphviz option changed in /etc/mk.conf. There have
> >>> been many changes to make recently.
> >>
> >> Hmmm. I have
> >>
> >> PKG_OPTIONS.graphviz= -lua
> >>
> >> to prevent it from using lua. Maybe the PLIST for the two extra files
> >> should be conditional on lua?
> >
> > Correct, perhaps an error:
> >
> > # grep python PLIST
> > ${PLIST.lua}man/man3/gv.3python
> > ${PLIST.lua}share/graphviz/doc/pdf/gv.3python.pdf
> >
> > Doesn't make sense.
>
> Rebuilt successfully after removing the ${PLIST.lua} stuff.
>
> Should I commit the change?
With
--- PLIST.orig2020-08-07 22:02:15.094669339 +0100
+++ PLIST 2020-08-07 22:02:47.109579539 +0100
@@ -171,7 +171,7 @@
${PLIST.lua}man/man3/gv.3lua
${PLIST.ocaml}man/man3/gv.3ocaml
${PLIST.perl}man/man3/gv.3perl
-${PLIST.lua}man/man3/gv.3python
+man/man3/gv.3python
${PLIST.tcl}man/man3/gv.3tcl
man/man3/gvc.3
man/man3/gvpr.3
@@ -421,7 +421,7 @@
${PLIST.lua}share/graphviz/doc/pdf/gv.3lua.pdf
${PLIST.ocaml}share/graphviz/doc/pdf/gv.3ocaml.pdf
${PLIST.perl}share/graphviz/doc/pdf/gv.3perl.pdf
-${PLIST.lua}share/graphviz/doc/pdf/gv.3python.pdf
+share/graphviz/doc/pdf/gv.3python.pdf
${PLIST.tcl}share/graphviz/doc/pdf/gv.3tcl.pdf
share/graphviz/doc/pdf/gv2gml.1.pdf
share/graphviz/doc/pdf/gv2gxl.1.pdf
'make package' succeeds with and without lua option.
>
>
> ++--+---+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
> ++--+---+
--
Re: System crash
On Sat, 8 Aug 2020 at 16:42, Chavdar Ivanov wrote: > > On Sat, 8 Aug 2020 at 16:51, Robert Nestor wrote: > > > > Done but I may have put it into the wrong category - PR kern/0 > > > > On Aug 8, 2020, at 8:55 AM, Paul Goyette wrote: > > > > > On Sat, 8 Aug 2020, Robert Nestor wrote: > > > > > >> Stumbled over this trying to check on the format of a NetBSD CD. This > > >> is a newly installed system of 9.99.69 downloaded two days ago with > > >> all the installed packages rebuilt and installed under it, so > > >> everything is pretty much up to date. > > >> > > >> vndconfig -c vnd0 NetBSD-9.99.69-amd64.iso > > >> gpt show vnd0 > > I don't get any panic with today's -current: > > $ vnconfig -c vnd0 /home/sysbuild/release/images/NetBSD-9.99.69-amd64.iso > $ dkctl vnd0 listwedges > /dev/rvnd0: no wedges configured > $ gpt show vnd0 > GPT not found, displaying data from MBR. > >startsize index contents >0 962560 Unused > $ uname -a > NetBSD ymir 9.99.69 NetBSD 9.99.69 (GENERIC) #3: Sat Aug 8 13:47:29 > BST 2020 > sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > amd64 It is just a cd9660 image covering the whole .iso: [/home/xci]$ mount -t cd9660 -o ro /dev/vnd0d /mnt/cdrom [/home/xci]$ ls -l /mnt/cdrom/boot -rw-r--r-- 1 sysbuild sysbuild 85176 Aug 8 13:53 /mnt/cdrom/boot [/home/xci]$ ls -l /mnt/cdrom total 10112 drwxr-xr-x 2 root wheel2048 Jun 19 20:16 altroot drwxr-xr-x 4 sysbuild sysbuild 2048 Aug 8 13:48 amd64 ... drwxr-xr-x 11 root wheel2048 Jun 19 20:16 usr drwxr-xr-x 24 root wheel4096 Jun 19 20:16 var > > > > >> > > >> And the system immediately crashed. Now maybe what I tried doing > > >> isn't permitted, but should the system crash just from trying to do > > >> it? > > > > > > No it should not crash. > > > > > > Please file a PR > > > > > > > > > ++--+---+ > > > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > > > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > > > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > > > ++--+---+ > > > > > -- > --
Re: System crash
On Sat, 8 Aug 2020 at 16:51, Robert Nestor wrote: > > Done but I may have put it into the wrong category - PR kern/0 > > On Aug 8, 2020, at 8:55 AM, Paul Goyette wrote: > > > On Sat, 8 Aug 2020, Robert Nestor wrote: > > > >> Stumbled over this trying to check on the format of a NetBSD CD. This > >> is a newly installed system of 9.99.69 downloaded two days ago with > >> all the installed packages rebuilt and installed under it, so > >> everything is pretty much up to date. > >> > >> vndconfig -c vnd0 NetBSD-9.99.69-amd64.iso > >> gpt show vnd0 I don't get any panic with today's -current: $ vnconfig -c vnd0 /home/sysbuild/release/images/NetBSD-9.99.69-amd64.iso $ dkctl vnd0 listwedges /dev/rvnd0: no wedges configured $ gpt show vnd0 GPT not found, displaying data from MBR. startsize index contents 0 962560 Unused $ uname -a NetBSD ymir 9.99.69 NetBSD 9.99.69 (GENERIC) #3: Sat Aug 8 13:47:29 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 > >> > >> And the system immediately crashed. Now maybe what I tried doing > >> isn't permitted, but should the system crash just from trying to do > >> it? > > > > No it should not crash. > > > > Please file a PR > > > > > > ++--+---+ > > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > > ++--+---+ > --
Re: System crash
On Sat, 8 Aug 2020 at 17:52, Robert Nestor wrote: > > I didn’t realize at the time that the iso file I was using for this was on an > NFS share. It crashes there, but if I move the file to a local disk then I > don’t see any crash and get the same output you got. This is the BT for > attempting this when the file is on an NFS share: > > cpu1: Begin traceback… > vpanic() at netbsd:vpanic+0x152 > snprintf() at netbsd:snprinf > nfs_pathconf() at netbsd:nfs_pathconf > VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x64 > vndthread() at netbsd:vndthread+0x81e > cpu1: End traceback… It sure is worth a pr, but I tested the same, placing the iso file on a FreeNAS NFS share and did not get the panic. > > > On Aug 8, 2020, at 10:42 AM, Chavdar Ivanov wrote: > > > On Sat, 8 Aug 2020 at 16:51, Robert Nestor wrote: > >> > >> Done but I may have put it into the wrong category - PR kern/0 > >> > >> On Aug 8, 2020, at 8:55 AM, Paul Goyette wrote: > >> > >>> On Sat, 8 Aug 2020, Robert Nestor wrote: > >>> > >>>> Stumbled over this trying to check on the format of a NetBSD CD. This > >>>> is a newly installed system of 9.99.69 downloaded two days ago with > >>>> all the installed packages rebuilt and installed under it, so > >>>> everything is pretty much up to date. > >>>> > >>>> vndconfig -c vnd0 NetBSD-9.99.69-amd64.iso > >>>> gpt show vnd0 > > > > I don't get any panic with today's -current: > > > > $ vnconfig -c vnd0 /home/sysbuild/release/images/NetBSD-9.99.69-amd64.iso > > $ dkctl vnd0 listwedges > > /dev/rvnd0: no wedges configured > > $ gpt show vnd0 > > GPT not found, displaying data from MBR. > > > > startsize index contents > > 0 962560 Unused > > $ uname -a > > NetBSD ymir 9.99.69 NetBSD 9.99.69 (GENERIC) #3: Sat Aug 8 13:47:29 > > BST 2020 > > sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > > amd64 > > > > > >>>> > >>>> And the system immediately crashed. Now maybe what I tried doing > >>>> isn't permitted, but should the system crash just from trying to do > >>>> it? > >>> > >>> No it should not crash. > >>> > >>> Please file a PR > >>> > >>> > >>> ++--+---+ > >>> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > >>> | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > >>> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > >>> ++--+---+ > >> > > > > > > -- > > > --
Re: System crash
On Sat, 8 Aug 2020 at 18:07, Robert Nestor wrote: > > My NFS is on a DS218+ Synology NAS which I believe is based on a version of > Linux. FreeNAS is based on FreeBSD I think, if that makes any difference. > > Could be something I haven’t configured properly on my NAS, but everything > else has been working fine for the last couple of years and it’s where I have > /home mounted which works for accessing files from Mac, Linux and NetBSD. I haven't got a Synology hardware, but I have an xpenology VirtualBox guest with a very recent version of DSM - 6.2.3. I am happy to report I get exactly the same panic if I place the iso file on a NFS share there: # crash -M netbsd.27.core -N netbsd.27 Crash version 9.99.69, image version 9.99.69. crash: _kvm_kvatop(0) Kernel compiled without options LOCKDEBUG. System panicked: nfs physio/async Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NARCNET() at 0 ?() at 8d05670b2440 sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf nfs_pathconf() at nfs_pathconf VOP_STRATEGY() at VOP_STRATEGY+0x64 vndthread() at vndthread+0x81e The nfs parameter definitions on the server are the default ones. > > -bo > > On Aug 8, 2020, at 11:01 AM, Chavdar Ivanov wrote: > > > On Sat, 8 Aug 2020 at 17:52, Robert Nestor wrote: > >> > >> I didn’t realize at the time that the iso file I was using for this was on > >> an NFS share. It crashes there, but if I move the file to a local disk > >> then I don’t see any crash and get the same output you got. This is the > >> BT for attempting this when the file is on an NFS share: > >> > >> cpu1: Begin traceback… > >> vpanic() at netbsd:vpanic+0x152 > >> snprintf() at netbsd:snprinf > >> nfs_pathconf() at netbsd:nfs_pathconf > >> VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x64 > >> vndthread() at netbsd:vndthread+0x81e > >> cpu1: End traceback… > > > > It sure is worth a pr, but I tested the same, placing the iso file on > > a FreeNAS NFS share and did not get the panic. > > > >> > >> > >> On Aug 8, 2020, at 10:42 AM, Chavdar Ivanov wrote: > >> > >>> On Sat, 8 Aug 2020 at 16:51, Robert Nestor wrote: > >>>> > >>>> Done but I may have put it into the wrong category - PR kern/0 > >>>> > >>>> On Aug 8, 2020, at 8:55 AM, Paul Goyette wrote: > >>>> > >>>>> On Sat, 8 Aug 2020, Robert Nestor wrote: > >>>>> > >>>>>> Stumbled over this trying to check on the format of a NetBSD CD. This > >>>>>> is a newly installed system of 9.99.69 downloaded two days ago with > >>>>>> all the installed packages rebuilt and installed under it, so > >>>>>> everything is pretty much up to date. > >>>>>> > >>>>>>vndconfig -c vnd0 NetBSD-9.99.69-amd64.iso > >>>>>>gpt show vnd0 > >>> > >>> I don't get any panic with today's -current: > >>> > >>> $ vnconfig -c vnd0 /home/sysbuild/release/images/NetBSD-9.99.69-amd64.iso > >>> $ dkctl vnd0 listwedges > >>> /dev/rvnd0: no wedges configured > >>> $ gpt show vnd0 > >>> GPT not found, displaying data from MBR. > >>> > >>> startsize index contents > >>> 0 962560 Unused > >>> $ uname -a > >>> NetBSD ymir 9.99.69 NetBSD 9.99.69 (GENERIC) #3: Sat Aug 8 13:47:29 > >>> BST 2020 > >>> sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > >>> amd64 > >>> > >>> > >>>>>> > >>>>>> And the system immediately crashed. Now maybe what I tried doing > >>>>>> isn't permitted, but should the system crash just from trying to do > >>>>>> it? > >>>>> > >>>>> No it should not crash. > >>>>> > >>>>> Please file a PR > >>>>> > >>>>> > >>>>> ++--+---+ > >>>>> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: > >>>>> | > >>>>> | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com > >>>>> | > >>>>> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org > >>>>> | > >>>>> ++--+---+ > >>>> > >>> > >>> > >>> -- > >>> > >> > > > > > > -- > > > --
Re: System crash
On Sat, 8 Aug 2020 at 18:53, Robert Nestor wrote: > > Phew! At least there’s one other configuration seeing the same crash. > > The Synology documentation is pretty confusing and to get things working I > played around with a lot of settings. Basically since it’s only used for > local access I’ve opened up the privileges for access to everything and > everyone, so whatever the problem is it shouldn’t be one concerning > privileges on the NAS. But to get it working from NetBSD I did have to use in > my /etc/fstab: > ds218:/volume1/home /homes nfs rw,-w=1024,-r=1024,tcp I just opened the access from my local network and mounted it with no additional parameters # mount -t nfs syno:/volume1/sytest /mnt/sytest I also tried # vnconfig -c vnd0 /mnt/sytest/NetBSDiso # mount -t cd9660 -o ro /dev/vnd0d /mnt/cdrom which works fine; dkctl also does not trigger any panic, only gpt. > > Found the suggestion for the read/write block sizes and tcp parameters on > someone’s NetBSD blog. > > -bob > > On Aug 8, 2020, at 11:44 AM, Chavdar Ivanov wrote: > > > On Sat, 8 Aug 2020 at 18:07, Robert Nestor wrote: > >> > >> My NFS is on a DS218+ Synology NAS which I believe is based on a version > >> of Linux. FreeNAS is based on FreeBSD I think, if that makes any > >> difference. > >> > >> Could be something I haven’t configured properly on my NAS, but everything > >> else has been working fine for the last couple of years and it’s where I > >> have /home mounted which works for accessing files from Mac, Linux and > >> NetBSD. > > > > I haven't got a Synology hardware, but I have an xpenology VirtualBox > > guest with a very recent version of DSM - 6.2.3. I am happy to report > > I get exactly the same panic if I place the iso file on a NFS share > > there: > > > > > > # crash -M netbsd.27.core -N netbsd.27 > > Crash version 9.99.69, image version 9.99.69. > > crash: _kvm_kvatop(0) > > Kernel compiled without options LOCKDEBUG. > > System panicked: nfs physio/async > > Backtrace from time of crash is available. > > crash> bt > > _KERNEL_OPT_NARCNET() at 0 > > ?() at 8d05670b2440 > > sys_reboot() at sys_reboot > > vpanic() at vpanic+0x15b > > snprintf() at snprintf > > nfs_pathconf() at nfs_pathconf > > VOP_STRATEGY() at VOP_STRATEGY+0x64 > > vndthread() at vndthread+0x81e > > > > The nfs parameter definitions on the server are the default ones. > > > >> > >> -bo > >> > >> On Aug 8, 2020, at 11:01 AM, Chavdar Ivanov wrote: > >> > >>> On Sat, 8 Aug 2020 at 17:52, Robert Nestor wrote: > >>>> > >>>> I didn’t realize at the time that the iso file I was using for this was > >>>> on an NFS share. It crashes there, but if I move the file to a local > >>>> disk then I don’t see any crash and get the same output you got. This > >>>> is the BT for attempting this when the file is on an NFS share: > >>>> > >>>> cpu1: Begin traceback… > >>>> vpanic() at netbsd:vpanic+0x152 > >>>> snprintf() at netbsd:snprinf > >>>> nfs_pathconf() at netbsd:nfs_pathconf > >>>> VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x64 > >>>> vndthread() at netbsd:vndthread+0x81e > >>>> cpu1: End traceback… > >>> > >>> It sure is worth a pr, but I tested the same, placing the iso file on > >>> a FreeNAS NFS share and did not get the panic. > >>> > >>>> > >>>> > >>>> On Aug 8, 2020, at 10:42 AM, Chavdar Ivanov wrote: > >>>> > >>>>> On Sat, 8 Aug 2020 at 16:51, Robert Nestor wrote: > >>>>>> > >>>>>> Done but I may have put it into the wrong category - PR kern/0 > >>>>>> > >>>>>> On Aug 8, 2020, at 8:55 AM, Paul Goyette wrote: > >>>>>> > >>>>>>> On Sat, 8 Aug 2020, Robert Nestor wrote: > >>>>>>> > >>>>>>>> Stumbled over this trying to check on the format of a NetBSD CD. > >>>>>>>> This > >>>>>>>> is a newly installed system of 9.99.69 downloaded two days ago with > >>>>>>>> all the installed packages rebuilt and installed under it, so > >>>>>>>> everything is pretty much up to date. > >>>>>&g
-current build failure
Hi,
With sources just updated, I am getting:
# link INSTALL_XEN3_DOMU/netbsd
ld -Map netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020
-e start -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ}
vers.o swapnetbsd.o
ld: netbsd32_mod.o: in function `amd64_oosyscall_handle':
netbsd32_mod.c:(.text+0x111): undefined reference to `x86_cpu_is_lcall'
*** Error code 1
.
Chavdar
--
strange assert failure on today's -current
Hi,
On one of my -current boxes with -current from today pkgin fails as
follows (via ktrust):
8831 8831 pkgin__statvfs190("/var/db/pkgin/cache",
0x7f7fff18a300, 0x1) = 0
8831 8831 pkgin__statvfs190("/usr/pkg", 0x7f7fff18a300, 0x1) = 0
8831 8831 pkginioctl(0x1, TIOCGWINSZ, 0x7f7fff18afb8) = 0
"%\0\M->\0:\^B\M-<\^A"
8831 8831 pkginioctl(0x1, TIOCGWINSZ, 0x7f7fff18afb8) = 0
"%\0\M->\0:\^B\M-<\^A"
8831 8831 pkginioctl(0x1, TIOCGWINSZ, 0x7f7fff18afb8) = 0
"%\0\M->\0:\^B\M-<\^A"
8831 8831 pkginioctl(0x1, TIOCGWINSZ, 0x7f7fff18afb8) = 0
"%\0\M->\0:\^B\M-<\^A"
8831 8831 pkginioctl(0x1, TIOCGWINSZ, 0x7f7fff18afb8) = 0
"%\0\M->\0:\^B\M-<\^A"
8831 8831 pkgin__sysctl(0x7f7fff188fd8, 0x2, 0x7f7fff18a760,
0x7f7fff188fd0, 0, 0) = 0
8831 8831 pkgin__socket30(0x1, 0x1002, 0) = 4
8831 8831 pkginconnect(0x4, 0x7716ec7a4de0, 0x6a) = 0
8831 8831 pkginsendto(0x4, 0x7f7fff1899c0, 0x95, 0, 0, 0) = 149
"<15>1 - marge.lorien.lan pkgin - - - assertion "str != NULL"
failed: file "/home/sysbuild/src/lib/libc/string/strdup.c", line 58,
function "_strdup"\n"
8831 8831 pkginclose(0x4) = 0
8831 8831 pkginSIGSEGV SIG_DFL
.
Under gdb (perhaps not very useful):
..
(gdb) run upgrade
Starting program: /usr/pkg/bin/pkgin upgrade
[Detaching after vfork from child process 10654]
calculating dependencies...done.
Program received signal SIGSEGV, Segmentation fault.
0x795505584870 in strlen () from /usr/lib/libc.so.12
(gdb) bt
#0 0x795505584870 in strlen () from /usr/lib/libc.so.12
#1 0x7955054b17be in strdup () from /usr/lib/libc.so.12
#2 0x0040d352 in ?? ()
#3 0x004078b5 in ?? ()
#4 0x00404d27 in ?? ()
#5 0x00405829 in ?? ()
#6 0x00414d71 in ?? ()
#7 0x0040413b in ?? ()
#8 0x7f7fbce0c840 in ?? () from /usr/libexec/ld.elf_so
#9 0x0002 in ?? ()
#10 0x7f7dc690 in ?? ()
#11 0x7f7dc6a3 in ?? ()
#12 0x in ?? ()
I've rebuilt pkgin itself, it doesn't do that on the build host, only
on one which normally receives its packages via pkgin.
Chavdar
--
Re: [PATCH] net/samba4: relocate Sysvol to persist between reboots & move variable data out of /usr/pkg/etc/...
On Fri, 31 Jul 2020 at 21:27, Matthias Petermann wrote: > > Hello everybody, > > unfortunately I was late to test this patch and saw that it is already > in CVS. I still wanted to let you know that I can now confirm that > without the patch and activated "log" the problem described by Chavdar > occurs, and that everything seems fine with the patch. I have > successfully provisioned a new domain on a sysvol on FFSv2 with > activated log. > > A big thank you from me for the quick remedy and the great cooperation! I also managed to provision once more, then I added a second DC (same samba4 version, but using python8), which went well; then I added a Windows 10 machine and a Windows Next server as members, all appearing fine. There are other things to test, of course - e.g. replication, DNS etc. - but it looks reasonably good. > > Best regards and have a nice weekend > Matthias > Likewise, Chavdar --
Re: tunefs throws mount error
On Thu, 6 Aug 2020 at 13:51, Thomas Klausner wrote: > > Hi! > > I've added a new disk and newfsed it. Then I ran tunefs and saw: > > # tunefs -o time /dev/rdk10 > tunefs: tuning /dev/rdk10 > tunefs: optimization preference remains unchanged as time > tunefs: mount: Invalid argument $ uname -a NetBSD nbuild.lorien.lan 9.99.69 NetBSD 9.99.69 (GENERIC) #0: Mon Aug 3 20:46:23 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 $ tunefs -o time /dev/rdk1 tunefs: tuning /dev/rdk1 tunefs: optimization preference remains unchanged as time tunefs: mount of /dev/dk1 on / updated $ tunefs -o time /dev/rdk4 tunefs: tuning /dev/rdk4 tunefs: optimization preference remains unchanged as time tunefs: mount of /dev/dk1 on / updated (also worked on a system from earlier today). > > I don't remember seeing this last line before. > 9.99.69/amd64 > Thomas --
Re: virtio panic during reboot (NetBSD 9)
On Tue, 11 Aug 2020 at 14:59, Thomas Klausner wrote: > > Hi! > > With a NetBSD 9 release in a virtual server (not sure what technology, > dmesg available on request), I saw a panic during reboot: That would be interesting - to see where vioscsi actually attaches. I've always wondered if it would be difficult to modify the vioscsi driver to attach under VirtualBox - as it is recognized at the moment as Qumranet product 1048 (SCSI mass storage, revision 0x01) at pci0 dev 15 function 0 not configured I appreciate that VirtualBox documentation states 'Currently the virtio-scsi controller is experimental'. vioif attaches just fine and as far as I can see, works the same. > > netbsd: [ 425.9816243] uvm_fault(0xceeb5b6b2a20, 0x0, 1) -> e > netbsd: [ 425.9816243] fatal page fault in supervisor mode > netbsd: [ 425.9816243] trap type 6 code 0 rip 0x80240fb0 cs 0x8 > rflags 0x10246 cr2 0x41 ilevel 0 rsp 0xda80b0 > 2fed70 > netbsd: [ 425.9816243] curlwp 0xceeb58a62080 pid 72.1 lowest kstack > 0xda80b02fc2c0 > netbsd: [ 425.9816243] Skipping crash dump on recursive panic > netbsd: [ 425.9816243] panic: trap > netbsd: [ 425.9893443] cpu0: Begin traceback... > netbsd: [ 425.9893443] vpanic() at netbsd:vpanic+0x160 > netbsd: [ 425.9893443] snprintf() at netbsd:snprintf > netbsd: [ 425.9893443] startlwp() at netbsd:startlwp > netbsd: [ 425.9893443] alltraps() at netbsd:alltraps+0xbb > netbsd: [ 425.9992299] virtio_pci_free_interrupts() at > netbsd:virtio_pci_free_interrupts+0x3c > netbsd: [ 426.0220926] virtio_child_detach() at > netbsd:virtio_child_detach+0x61 > netbsd: [ 426.0220926] vioscsi_detach() at netbsd:vioscsi_detach+0x9d > netbsd: [ 426.0292585] config_detach() at netbsd:config_detach+0x85 > netbsd: [ 426.0292585] config_detach_all() at netbsd:config_detach_all+0x9f > netbsd: [ 426.0292585] cpu_reboot() at netbsd:cpu_reboot+0x137 > netbsd: [ 426.0292585] sys_reboot() at netbsd:sys_reboot+0x75 > netbsd: [ 426.0292585] syscall() at netbsd:syscall+0x157 > netbsd: [ 426.0392749] --- syscall (number 208) --- > netbsd: [ 426.0392749] 7af270242f5a: > netbsd: [ 426.0392749] cpu0: End traceback... > netbsd: [ 426.0392749] rebooting... > > Is this a known problem or should I file a bug report? > Thomas Chavdar --
Re: Failure to build gobject-introspection
On Tue, 30 Jun 2020 at 15:52, Riccardo Mottola wrote: > > Hi, > > Chavdar Ivanov wrote: > > FWIW I just rebuilt it on today's -current amd64 and -current pkgsrc; > > it wasn't rebuilt during the last rolling-replace, so the package was > > from early May; today it was also built right away. > > let me check for updates of pkgsrc then... > > > > I've had various troubles in the past building this package; at one > > stage it would not build unless DISPLAY was set to a working X > > server... (that problem was resolved at the time). > > I just tried building inside X11 (I usually avoid, since it steals some > RAM...) but it does not help Yes, I mentioned that particular problem with it was resolved at the time. But I also remember having to force update devel/glib2, as was indeed already suggested, although I don't know if this will solve your problem. > > Riccardo Chavdar --
9.99.69 panic - libcrypto changes?
Hi, On amd64 9.99.69 from yesterday I get: crash: _kvm_kvatop(0) Crash version 9.99.69, image version 9.99.69. Kernel compiled without options LOCKDEBUG. System panicked: fpudna from kernel, ip 0x802292af, trapframe 0xbe013c564a50 Backtrace from time of crash is available. _KERNEL_OPT_NARCNET() at 0 ?() at be013c564d98 sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf fpu_set_default_cw() at fpu_set_default_cw Xtrap07() at Xtrap07+0xbd aesni_enc_impl() at aesni_enc_impl+0x1c rijndaelEncrypt() at rijndaelEncrypt+0x4b ccmp_init_blocks() at ccmp_init_blocks+0xe8 ccmp_decap() at ccmp_decap+0x18f ieee80211_crypto_decap() at ieee80211_crypto_decap+0xb2 ieee80211_input() at ieee80211_input+0xb93 iwm_softintr() at iwm_softintr+0x921 softint_dispatch() at softint_dispatch+0x2d1 -- My WiFi link (iwm) is also visibly slower than usual. The panic happened while I was running 'pkgin upgrade' over an NFS mount through the iwm adapter. On the same system - after the reboot - I was able to start kde and xfce4, but got twice identical freezes when running thunderbird, while getting mail. I couldn't break into the debugger. This hardware has been running NetBSD-current (among others) for about four years now without major problems otherwise (HP Envy 17 from 2016). Chavdar
Re: 9.99.69 panic - libcrypto changes?
On Mon, 6 Jul 2020 at 02:14, Taylor R Campbell wrote: > > > Date: Sun, 5 Jul 2020 11:45:48 +0100 > > From: Chavdar Ivanov > > > > panic: fpudna from userland, ip 0x7c16e87b95ca, trapframe 0xce01527ec000 > > cpu0: Begin traceback... > > vpanic() at netbsd:vpanic+0x152 > > snprintf() at netbsd:snprintf > > fpu_set_default_cw() at netbsd:fpu_set_default_cw > > cpu0: End traceback... > > This and the earlier panic you reported may be fixed by > > https://mail-index.netbsd.org/source-changes/2020/07/06/msg119081.html I upgraded this morning. Unfortunately it did not fix it for me, though I did not get a panic. I got a deep CPU loop with a fully spinning fan and no reaction to the attempt to break into the debugger, so I had to hit the power button. > > (The performance regression with WPA/WPA2 remains -- I'm working on > that.) Chavdar --
Re: Failure to build gobject-introspection
FWIW I just rebuilt it on today's -current amd64 and -current pkgsrc; it wasn't rebuilt during the last rolling-replace, so the package was from early May; today it was also built right away. I've had various troubles in the past building this package; at one stage it would not build unless DISPLAY was set to a working X server... (that problem was resolved at the time). On Mon, 29 Jun 2020 at 23:32, Robert Swindells wrote: > > > I wrote: > >What is wrong with the idea that you have run out of memory ? > > OTOH, running top(1) at the same time as building it doesn't show > any particularly large processes. --
Re: ZFS disaster on -current
Yes, I do. Should I be looking for something specific? I've uploaded it here, if it is of interest - https://send.firefox.com/download/74761aa43c6c54b3/#PbaGxtDN81Hzk2VUjefozw . BTW I repeated the test on a pvh guest of XCP-NG, it panics the same way. Chavdar On Wed, 24 Jun 2020 at 12:07, Jaromír Doleček wrote: > > By chance, do you have the kernel crash dump from the original panic > which happened yesterday? The subsequent ones might be a result of the > first one. > > The messages about redzone don't mean anything beyond that there is no > overflow protection for items on the pool. > > Jaromir > > Le mer. 24 juin 2020 à 11:34, Chavdar Ivanov a écrit : > > > > Hi, > > > > On > > > > NetBSD ymir 9.99.68 NetBSD 9.99.68 (GENERIC) #1: Tue Jun 23 22:53:46 > > BST 2020 > > sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > > amd64 > > > > I suddenly got a panic with ZFS; it took place with the previous > > kernel, so it was something with the module. In single user I disabled > > zfs in /etc/rc.conf and was able to complete boot, but obviously > > without my two pools. > > > > 'modload solaris' didn't show any problem. > > > > I set aside the contents of /etc/zfs and did 'modload zfs', which resulted > > in: > > > > . > > > > WARNING: ZFS on NetBSD is under development > > pool redzone disabled for 'zio_buf_4096' > > pool redzone disabled for 'zio_data_buf_4096' > > pool redzone disabled for 'zio_buf_8192' > > pool redzone disabled for 'zio_data_buf_8192' > > pool redzone disabled for 'zio_buf_16384' > > pool redzone disabled for 'zio_data_buf_16384' > > pool redzone disabled for 'zio_buf_32768' > > pool redzone disabled for 'zio_data_buf_32768' > > pool redzone disabled for 'zio_buf_65536' > > pool redzone disabled for 'zio_data_buf_65536' > > pool redzone disabled for 'zio_buf_131072' > > pool redzone disabled for 'zio_data_buf_131072' > > pool redzone disabled for 'zio_buf_262144' > > pool redzone disabled for 'zio_data_buf_262144' > > pool redzone disabled for 'zio_buf_524288' > > pool redzone disabled for 'zio_data_buf_524288' > > pool redzone disabled for 'zio_buf_1048576' > > pool redzone disabled for 'zio_data_buf_1048576' > > pool redzone disabled for 'zio_buf_2097152' > > pool redzone disabled for 'zio_data_buf_2097152' > > pool redzone disabled for 'zio_buf_4194304' > > pool redzone disabled for 'zio_data_buf_4194304' > > pool redzone disabled for 'zio_buf_8388608' > > pool redzone disabled for 'zio_data_buf_8388608' > > pool redzone disabled for 'zio_buf_16777216' > > pool redzone disabled for 'zio_data_buf_16777216' > > > > I have no idea what that means, it is a first for me, ZFS otherwise > > has been very reliable on this hardware so far, inasmuch as I have the > > mercurial repo on a zfs and build from it from time to time (the panic > > is from the last cvs update from yesterday, though). > > > > Subsequent 'zpool import' repeated the panic (without getting me into > > the debugger, though): > > > > > > ZFS filesystem version: 5 > > uvm_fault(0xa97e4c3e1610, 0x0, 1) -> e > > fatal page fault in supervisor mode > > trap type 6 code 0 rip 0x81d49882 cs 0x8 rflags 0x10286 cr2 > > 0xa0 ilevel 0 rsp 0xde819c16d760 > > curlwp 0xa97e3a41e140 pid 17394.17394 lowest kstack 0xde819c16a2c0 > > panic: trap > > cpu0: Begin traceback... > > vpanic() at netbsd:vpanic+0x152 > > snprintf() at netbsd:snprintf > > startlwp() at netbsd:startlwp > > alltraps() at netbsd:alltraps+0xc3 > > vdev_open() at zfs:vdev_open+0x9e > > vdev_open_children() at zfs:vdev_open_children+0x39 > > vdev_root_open() at zfs:vdev_root_open+0x33 > > vdev_open() at zfs:vdev_open+0x9e > > spa_load() at zfs:spa_load+0x38e > > spa_tryimport() at zfs:spa_tryimport+0x86 > > zfs_ioc_pool_tryimport() at zfs:zfs_ioc_pool_tryimport+0x41 > > zfsdev_ioctl() at zfs:zfsdev_ioctl+0x8c1 > > nb_zfsdev_ioctl() at zfs:nb_zfsdev_ioctl+0x38 > > VOP_IOCTL() at netbsd:VOP_IOCTL+0x44 > > vn_ioctl() at netbsd:vn_ioctl+0xa5 > > sys_ioctl() at netbsd:sys_ioctl+0x550 > > syscall() at netbsd:syscall+0x26e > > --- syscall (number 54) --- > > netbsd:syscall+0x26e: > > cpu0: End traceback... > > > > The above panic did not leave a crash dump. > > > > When I had /etc/zfs populated before, I also got a crash dump (with > > 'reboot 0x104'), as follows: > > > > # crash -M netbsd.18.co
Re: ZFS disaster on -current
# » crash -M netbsd.19.core -N netbsd.19 Crash version 9.99.68, image version 9.99.68. crash: _kvm_kvatop(0) Kernel compiled without options LOCKDEBUG. System panicked: trap Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NARCNET() at 0 ?() at 90819ac6 sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf startlwp() at startlwp calltrap() at calltrap+0x19 vdev_open() at vdev_open+0x9e vdev_open_children() at vdev_open_children+0x39 vdev_root_open() at vdev_root_open+0x33 vdev_open() at vdev_open+0x9e spa_load() at spa_load+0x38e spa_tryimport() at spa_tryimport+0x86 zfs_ioc_pool_tryimport() at zfs_ioc_pool_tryimport+0x41 zfsdev_ioctl() at zfsdev_ioctl+0x8c1 nb_zfsdev_ioctl() at nb_zfsdev_ioctl+0x38 VOP_IOCTL() at VOP_IOCTL+0x44 vn_ioctl() at vn_ioctl+0xa5 sys_ioctl() at sys_ioctl+0x550 syscall() at syscall+0x26e --- syscall (number 54) --- syscall+0x26e: On Wed, 24 Jun 2020 at 12:04, Chavdar Ivanov wrote: > > Yes, I do. Should I be looking for something specific? > > I've uploaded it here, if it is of interest - > https://send.firefox.com/download/74761aa43c6c54b3/#PbaGxtDN81Hzk2VUjefozw > . > > BTW I repeated the test on a pvh guest of XCP-NG, it panics the same way. > > Chavdar > > On Wed, 24 Jun 2020 at 12:07, Jaromír Doleček > wrote: > > > > By chance, do you have the kernel crash dump from the original panic > > which happened yesterday? The subsequent ones might be a result of the > > first one. > > > > The messages about redzone don't mean anything beyond that there is no > > overflow protection for items on the pool. > > > > Jaromir > > > > Le mer. 24 juin 2020 à 11:34, Chavdar Ivanov a écrit : > > > > > > Hi, > > > > > > On > > > > > > NetBSD ymir 9.99.68 NetBSD 9.99.68 (GENERIC) #1: Tue Jun 23 22:53:46 > > > BST 2020 > > > sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > > > amd64 > > > > > > I suddenly got a panic with ZFS; it took place with the previous > > > kernel, so it was something with the module. In single user I disabled > > > zfs in /etc/rc.conf and was able to complete boot, but obviously > > > without my two pools. > > > > > > 'modload solaris' didn't show any problem. > > > > > > I set aside the contents of /etc/zfs and did 'modload zfs', which > > > resulted in: > > > > > > . > > > > > > WARNING: ZFS on NetBSD is under development > > > pool redzone disabled for 'zio_buf_4096' > > > pool redzone disabled for 'zio_data_buf_4096' > > > pool redzone disabled for 'zio_buf_8192' > > > pool redzone disabled for 'zio_data_buf_8192' > > > pool redzone disabled for 'zio_buf_16384' > > > pool redzone disabled for 'zio_data_buf_16384' > > > pool redzone disabled for 'zio_buf_32768' > > > pool redzone disabled for 'zio_data_buf_32768' > > > pool redzone disabled for 'zio_buf_65536' > > > pool redzone disabled for 'zio_data_buf_65536' > > > pool redzone disabled for 'zio_buf_131072' > > > pool redzone disabled for 'zio_data_buf_131072' > > > pool redzone disabled for 'zio_buf_262144' > > > pool redzone disabled for 'zio_data_buf_262144' > > > pool redzone disabled for 'zio_buf_524288' > > > pool redzone disabled for 'zio_data_buf_524288' > > > pool redzone disabled for 'zio_buf_1048576' > > > pool redzone disabled for 'zio_data_buf_1048576' > > > pool redzone disabled for 'zio_buf_2097152' > > > pool redzone disabled for 'zio_data_buf_2097152' > > > pool redzone disabled for 'zio_buf_4194304' > > > pool redzone disabled for 'zio_data_buf_4194304' > > > pool redzone disabled for 'zio_buf_8388608' > > > pool redzone disabled for 'zio_data_buf_8388608' > > > pool redzone disabled for 'zio_buf_16777216' > > > pool redzone disabled for 'zio_data_buf_16777216' > > > > > > I have no idea what that means, it is a first for me, ZFS otherwise > > > has been very reliable on this hardware so far, inasmuch as I have the > > > mercurial repo on a zfs and build from it from time to time (the panic > > > is from the last cvs update from yesterday, though). > > > > > > Subsequent 'zpool import' repeated the panic (without getting me into > > > the debugger, though): > > > > > > > > > ZFS filesystem version: 5 > > > uvm_fault(0xa97e4c3e1610, 0x0, 1) -> e > > > fatal page fault in supervisor mode > > > trap type 6 code
Re: ZFS disaster on -current
Reverting external/cddl/osnet/dist/uts/common/fs/zfs/vdev_disk.c to 1.16 resolved the panic. I don't know if there is a link with the change to src/external/cddl/osnet/dist/uts/common/fs/zfs/zio.c, the build was done with the reverted to 1.6 one. On Wed, 24 Jun 2020 at 13:20, Chavdar Ivanov wrote: > > On Wed, 24 Jun 2020 at 14:12, Jaromír Doleček > wrote: > > > > OK nvm, mlelsv@ claims it's the unrelated change to vdev_disk.c - so > > perhaps try with that backed off, i.e. rev. 1.16 of: > > > > external/cddl/osnet/dist/uts/common/fs/zfs/vdev_disk.c > > > > Le mer. 24 juin 2020 à 14:55, Jaromír Doleček > > a écrit : > > > > > > Can you please check if it still panics the same way if you revert > > > sources to rev. 1.6 file: > > > src/external/cddl/osnet/dist/uts/common/fs/zfs/zio.c > > Backing the change in this one didn't sort the problem, identical > panic on 'zpool import' > > I'll try to back vdev_disk.c now. > > > > > > > and rebuild the zfs module? > > > > > > Jaromir > > > > > > > > > Le mer. 24 juin 2020 à 14:39, Jaromír Doleček > > > a écrit : > > > > > > > > What is 'the test' ? Just modload zfs? > > > > > > > > Jaromir > > > > > > > > Le mer. 24 juin 2020 à 14:05, Chavdar Ivanov a écrit > > > > : > > > > > > > > > > Yes, I do. Should I be looking for something specific? > > > > > > > > > > I've uploaded it here, if it is of interest - > > > > > https://send.firefox.com/download/74761aa43c6c54b3/#PbaGxtDN81Hzk2VUjefozw > > > > > . > > > > > > > > > > BTW I repeated the test on a pvh guest of XCP-NG, it panics the same > > > > > way. > > > > > > > > > > Chavdar > > > > > > > > > > On Wed, 24 Jun 2020 at 12:07, Jaromír Doleček > > > > > wrote: > > > > > > > > > > > > By chance, do you have the kernel crash dump from the original panic > > > > > > which happened yesterday? The subsequent ones might be a result of > > > > > > the > > > > > > first one. > > > > > > > > > > > > The messages about redzone don't mean anything beyond that there is > > > > > > no > > > > > > overflow protection for items on the pool. > > > > > > > > > > > > Jaromir > > > > > > > > > > > > Le mer. 24 juin 2020 à 11:34, Chavdar Ivanov a > > > > > > écrit : > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On > > > > > > > > > > > > > > NetBSD ymir 9.99.68 NetBSD 9.99.68 (GENERIC) #1: Tue Jun 23 > > > > > > > 22:53:46 > > > > > > > BST 2020 > > > > > > > sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC > > > > > > > amd64 > > > > > > > > > > > > > > I suddenly got a panic with ZFS; it took place with the previous > > > > > > > kernel, so it was something with the module. In single user I > > > > > > > disabled > > > > > > > zfs in /etc/rc.conf and was able to complete boot, but obviously > > > > > > > without my two pools. > > > > > > > > > > > > > > 'modload solaris' didn't show any problem. > > > > > > > > > > > > > > I set aside the contents of /etc/zfs and did 'modload zfs', which > > > > > > > resulted in: > > > > > > > > > > > > > > . > > > > > > > > > > > > > > WARNING: ZFS on NetBSD is under development > > > > > > > pool redzone disabled for 'zio_buf_4096' > > > > > > > pool redzone disabled for 'zio_data_buf_4096' > > > > > > > pool redzone disabled for 'zio_buf_8192' > > > > > > > pool redzone disabled for 'zio_data_buf_8192' > > > > > > > pool redzone disabled for 'zio_buf_16384' > > > > > > > pool redzone disabled for 'zio_data_buf_16384' > > > > > > > pool redzone disabled for 'zio_buf_32768' > > > > > > > pool redzone disabled for 'zio_data_bu
ZFS disaster on -current
Hi, On NetBSD ymir 9.99.68 NetBSD 9.99.68 (GENERIC) #1: Tue Jun 23 22:53:46 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 I suddenly got a panic with ZFS; it took place with the previous kernel, so it was something with the module. In single user I disabled zfs in /etc/rc.conf and was able to complete boot, but obviously without my two pools. 'modload solaris' didn't show any problem. I set aside the contents of /etc/zfs and did 'modload zfs', which resulted in: . WARNING: ZFS on NetBSD is under development pool redzone disabled for 'zio_buf_4096' pool redzone disabled for 'zio_data_buf_4096' pool redzone disabled for 'zio_buf_8192' pool redzone disabled for 'zio_data_buf_8192' pool redzone disabled for 'zio_buf_16384' pool redzone disabled for 'zio_data_buf_16384' pool redzone disabled for 'zio_buf_32768' pool redzone disabled for 'zio_data_buf_32768' pool redzone disabled for 'zio_buf_65536' pool redzone disabled for 'zio_data_buf_65536' pool redzone disabled for 'zio_buf_131072' pool redzone disabled for 'zio_data_buf_131072' pool redzone disabled for 'zio_buf_262144' pool redzone disabled for 'zio_data_buf_262144' pool redzone disabled for 'zio_buf_524288' pool redzone disabled for 'zio_data_buf_524288' pool redzone disabled for 'zio_buf_1048576' pool redzone disabled for 'zio_data_buf_1048576' pool redzone disabled for 'zio_buf_2097152' pool redzone disabled for 'zio_data_buf_2097152' pool redzone disabled for 'zio_buf_4194304' pool redzone disabled for 'zio_data_buf_4194304' pool redzone disabled for 'zio_buf_8388608' pool redzone disabled for 'zio_data_buf_8388608' pool redzone disabled for 'zio_buf_16777216' pool redzone disabled for 'zio_data_buf_16777216' I have no idea what that means, it is a first for me, ZFS otherwise has been very reliable on this hardware so far, inasmuch as I have the mercurial repo on a zfs and build from it from time to time (the panic is from the last cvs update from yesterday, though). Subsequent 'zpool import' repeated the panic (without getting me into the debugger, though): ZFS filesystem version: 5 uvm_fault(0xa97e4c3e1610, 0x0, 1) -> e fatal page fault in supervisor mode trap type 6 code 0 rip 0x81d49882 cs 0x8 rflags 0x10286 cr2 0xa0 ilevel 0 rsp 0xde819c16d760 curlwp 0xa97e3a41e140 pid 17394.17394 lowest kstack 0xde819c16a2c0 panic: trap cpu0: Begin traceback... vpanic() at netbsd:vpanic+0x152 snprintf() at netbsd:snprintf startlwp() at netbsd:startlwp alltraps() at netbsd:alltraps+0xc3 vdev_open() at zfs:vdev_open+0x9e vdev_open_children() at zfs:vdev_open_children+0x39 vdev_root_open() at zfs:vdev_root_open+0x33 vdev_open() at zfs:vdev_open+0x9e spa_load() at zfs:spa_load+0x38e spa_tryimport() at zfs:spa_tryimport+0x86 zfs_ioc_pool_tryimport() at zfs:zfs_ioc_pool_tryimport+0x41 zfsdev_ioctl() at zfs:zfsdev_ioctl+0x8c1 nb_zfsdev_ioctl() at zfs:nb_zfsdev_ioctl+0x38 VOP_IOCTL() at netbsd:VOP_IOCTL+0x44 vn_ioctl() at netbsd:vn_ioctl+0xa5 sys_ioctl() at netbsd:sys_ioctl+0x550 syscall() at netbsd:syscall+0x26e --- syscall (number 54) --- netbsd:syscall+0x26e: cpu0: End traceback... The above panic did not leave a crash dump. When I had /etc/zfs populated before, I also got a crash dump (with 'reboot 0x104'), as follows: # crash -M netbsd.18.core -N netbsd.18 Crash version 9.99.68, image version 9.99.68. crash: _kvm_kvatop(0) Kernel compiled without options LOCKDEBUG. System panicked: reboot forced via kernel debugger Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NARCNET() at 0 _KERNEL_OPT_NARCNET() at 0 sys_reboot() at sys_reboot db_fncall() at db_fncall db_command() at db_command+0x127 db_command_loop() at db_command_loop+0xa6 db_trap() at db_trap+0xe6 kdb_trap() at kdb_trap+0xe1 trap() at trap+0x2b7 --- trap (number 6) --- vdev_disk_open.part.4() at vdev_disk_open.part.4+0x49a vdev_open() at vdev_open+0x9e vdev_open_children() at vdev_open_children+0x39 vdev_root_open() at vdev_root_open+0x33 vdev_open() at vdev_open+0x9e spa_load() at spa_load+0x38e spa_load_best() at spa_load_best+0x58 spa_open_common() at spa_open_common+0xc2 pool_status_check.part.25() at pool_status_check.part.25+0x1e zfsdev_ioctl() at zfsdev_ioctl+0x80e nb_zfsdev_ioctl() at nb_zfsdev_ioctl+0x38 VOP_IOCTL() at VOP_IOCTL+0x44 vn_ioctl() at vn_ioctl+0xa5 sys_ioctl() at sys_ioctl+0x550 syscall() at syscall+0x26e --- syscall (number 54) --- syscall+0x26e: . Any idea what is going on? I've restarted a build, but the cvs log doesn't show anything relevant as far as I can see. Chavdar --
Re: cmake hanging
I just had another similar hang, this time in git, while trying to pull pkgsrc/wip: ... [Switching to LWP 2518 of process 2823] 0x72b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12 (gdb) thread apply all bt Thread 2 (LWP 2823 of process 2823): #0 0x72b102a4551a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x72b10320c754 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x00549842 in preload_index () #3 0x00558178 in refresh_index () #4 0x004252f0 in cmd_status () #5 0x004053fe in handle_builtin () #6 0x00406301 in cmd_main () #7 0x005ea9a3 in main () Thread 1 (LWP 2518 of process 2823): #0 0x72b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x72b103209791 in ?? () from /usr/lib/libpthread.so.1 #2 0x72b102ad6d0a in je_malloc_mutex_lock_slow () from /usr/lib/libc.so.12 #3 0x72b102b0e4f1 in je_arena_choose_hard () from /usr/lib/libc.so.12 #4 0x72b102ab583f in je_tsd_tcache_data_init () from /usr/lib/libc.so.12 #5 0x72b102ab5a89 in je_tsd_tcache_enabled_data_init () from /usr/lib/libc.so.12 #6 0x72b102ab1b09 in je_tsd_fetch_slow () from /usr/lib/libc.so.12 #7 0x72b102b0e82d in malloc () from /usr/lib/libc.so.12 #8 0x005cbed5 in xrealloc () #9 0x005a04d0 in strbuf_grow () #10 0x005aa74b in lstat_cache_matchlen () #11 0x005aa885 in threaded_has_symlink_leading_path () #12 0x005495b8 in preload_thread () #13 0x72b10320bee0 in ?? () from /usr/lib/libpthread.so.1 #14 0x72b102a92370 in ?? () from /usr/lib/libc.so.12 #15 0x0020 in ?? () #16 0x in ?? () The system is from today: $ uname -a NetBSD ymir 9.99.67 NetBSD 9.99.67 (GENERIC) #4: Tue Jun 16 09:10:01 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC am d64 Chavdar On Thu, 11 Jun 2020 at 00:19, Andrew Doran wrote: > > On Mon, Jun 08, 2020 at 03:38:44PM +0100, Chavdar Ivanov wrote: > > On Sun, 7 Jun 2020 at 10:25, Chavdar Ivanov wrote: > > > > > > Hi, > > > > > > I just had another one, rebuilding gimp, running gegl. Again gdb -p > > > ... ; quit sorted it out. > > > > > > On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov wrote: > > > > > > > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > > > > > > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > > > > building misc/kdepimlibs4, trace as follows: > > > > > > > > > > > > Just to mention that after I quit gdb and detached from the process > > > > > > it > > > > > > continued and completed the build . . . > > > > > > > > > > Right, that's the bug in the mutex wakeup handling. > > > > > > > > The second hung sample - with git - also completed OK after I quit > > > > gdb... > > > > I had another three cmake hangs just like this today, while rebuilding > > bits of kf5. > > > > Just to confirm - the moment one answers 'y' to the question whether > > to leave gdb the process continues and the build succeeds. > > > > This is somewhat annoying; although it does not stop the rebuild > > process, it makes it impossible to complete unattended. > > I just made some more changes to libpthread today that may help. I'll try > building KDE soon. > > Cheers, > Andrew --
Re: sysinst extended partitioning won't set/do the "newfs" flag!
On Wed, 10 Jun 2020 at 05:32, Martin Husemann wrote: > > On Mon, Jun 08, 2020 at 04:42:42PM -0700, Greg A. Woods wrote: > > What magic am I missing, or is this a bug? > > A bug, probably related to not using MBR on xen devices (but most other x86 > code expecting disklabel inside MBR). It worked (last I tested) in the > default partition editor, not sure what goes wrong here. > > I'll try to reproduce it locally. > > Martin I've done several installations lately under XCP-NG, but I always switch to uEFI and GPT scheme, this has worked just fine for me. (Only native X stopped recently to work with some ancient message about the Cirrus Logic driver having a kernel module, which cannot be unloaded; wsfb starts, though the mouse is erratic). Chavdar --
libuv.so
Hi, On my system from the 4th of June I get unresolved libuv for host, nslookup, dig. # ldd /usr/bin/dig | grep uv -luv.1 => not found Is this some local problem? Should I do a clean rebuild? --
Re: cmake hanging
On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote: > > Hi, > > I got another cmake hang during pkg_rolling-replace today, while > building misc/kdepimlibs4, trace as follows: Just to mention that after I quit gdb and detached from the process it continued and completed the build . . . > > . . . . > > Find the GDB manual and other documentation resources online at: > > [190/47198] > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word". > Attaching to process 18255 > Reading symbols from /usr/pkg/bin/cmake... > (No debugging symbols found in /usr/pkg/bin/cmake) > [New LWP 11876 of process 18255] > [New LWP 22853 of process 18255] > [New LWP 24648 of process 18255] > [New LWP 19500 of process 18255] > [New LWP 14244 of process 18255] > [New LWP 704 of process 18255] > [New LWP 876 of process 18255] > [New LWP 18255 of process 18255] > Reading symbols from /usr/lib/libexecinfo.so.0... > (No debugging symbols found in /usr/lib/libexecinfo.so.0) > Reading symbols from /usr/lib/libexpat.so.2... > (No debugging symbols found in /usr/lib/libexpat.so.2) > Reading symbols from /usr/lib/libz.so.1... > (No debugging symbols found in /usr/lib/libz.so.1) > Reading symbols from /usr/lib/libarchive.so.4... > (No debugging symbols found in /usr/lib/libarchive.so.4) > Reading symbols from /usr/pkg/lib/libcurl.so.4... > (No debugging symbols found in /usr/pkg/lib/libcurl.so.4) > Reading symbols from /usr/pkg/lib/libuv.so.1... > Reading symbols from /usr/lib/libcrypto.so.14... > (No debugging symbols found in /usr/lib/libcrypto.so.14) > Reading symbols from /usr/lib/libstdc++.so.9... > (No debugging symbols found in /usr/lib/libstdc++.so.9) > Reading symbols from /usr/lib/libm.so.0... > (No debugging symbols found in /usr/lib/libm.so.0) > Reading symbols from /usr/lib/libgcc_s.so.1... > (No debugging symbols found in /usr/lib/libgcc_s.so.1) > Reading symbols from /usr/lib/libpthread.so.1... > (No debugging symbols found in /usr/lib/libpthread.so.1) > Reading symbols from /usr/lib/libc.so.12... > --Type for more, q to quit, c to continue without paging-- > (No debugging symbols found in /usr/lib/libc.so.12) > (No debugging symbols found in /usr/lib/libelf.so.2) > > [149/47198] > Reading symbols from /usr/lib/libbz2.so.1... > (No debugging symbols found in /usr/lib/libbz2.so.1) > Reading symbols from /usr/lib/liblzma.so.2... > (No debugging symbols found in /usr/lib/liblzma.so.2) > Reading symbols from /usr/pkg/lib/libnghttp2.so.14... > (No debugging symbols found in /usr/pkg/lib/libnghttp2.so.14) > Reading symbols from /usr/pkg/lib/libidn2.so.0... > (No debugging symbols found in /usr/pkg/lib/libidn2.so.0) > Reading symbols from /usr/pkg/lib/librtmp.so.0... > (No debugging symbols found in /usr/pkg/lib/librtmp.so.0) > Reading symbols from /usr/pkg/lib/libgnutls.so.30... > (No debugging symbols found in /usr/pkg/lib/libgnutls.so.30) > Reading symbols from /usr/pkg/lib/libp11-kit.so.0... > Reading symbols from /usr/pkg/lib/libffi.so.7... > (No debugging symbols found in /usr/pkg/lib/libffi.so.7) > Reading symbols from /usr/pkg/lib/libunistring.so.2... > (No debugging symbols found in /usr/pkg/lib/libunistring.so.2) > Reading symbols from /usr/pkg/lib/libtasn1.so.6... > (No debugging symbols found in /usr/pkg/lib/libtasn1.so.6) > Reading symbols from /usr/lib/libintl.so.1... > (No debugging symbols found in /usr/lib/libintl.so.1) > Reading symbols from /usr/pkg/lib/libhogweed.so.6... > Reading symbols from /usr/pkg/lib/libgmp.so.10... > (No debugging symbols found in /usr/pkg/lib/libgmp.so.10) > Reading symbols from /usr/pkg/lib/libnettle.so.8... > Reading symbols from /usr/pkg/lib/libssh2.so.1... > (No debugging symbols found in /usr/pkg/lib/libssh2.so.1) > Reading symbols from /usr/lib/libssl.so.14... > (No debugging symbols found in /usr/lib/libssl.so.14) > Reading symbols from /usr/lib/libgssapi.so.11... > (No debugging symbols found in /usr/lib/libgssapi.so.11) > Reading symbols from /usr/lib/libkvm.so.6... > (No debugging symbols found in /usr/lib/libkvm.so.6) > Reading symbols from /lib/libcrypt.so.1... > (No debugging symbols found in /lib/libcrypt.so.1) > Reading symbols from /usr/lib/libkrb5.so.27... > --Type for more, q to quit, c to continue without paging-- > (No debugging symbols found in /usr/lib/libkrb5.so.27) > Reading symbols from /usr/lib/libasn1.so.10... > Reading symbols from /usr/lib/libcom_err.so.8... > > [108/47198] > (No debugging symbols found in /usr/lib/libcom_err.so.8) > Reading symbols from /usr/lib/libroken.so.20... > (No debugging
Re: cmake hanging
wait () from /usr/lib/libpthread.so.1 #2 0x7c0af00a0214 in std::condition_variable::wait(std::unique_lock&) () from /usr/lib/libstdc++.so.9 #3 0x004a7c13 in cmWorkerPoolInternal::Work(unsigned int) () #4 0x7c0af009e53a in ?? () from /usr/lib/libstdc++.so.9 #5 0x7c0aef40c6bc in ?? () from /usr/lib/libpthread.so.1 #6 0x7c0aeec92370 in ?? () from /usr/lib/libc.so.12 #7 0x0020 in ?? () #8 0x in ?? () Thread 4 (LWP 24648 of process 18255): #0 0x7c0aeeca87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7c0aef40a97d in pthread_cond_timedwait () from /usr/lib/libpthread.so.1 #2 0x7c0af00a0214 in std::condition_variable::wait(std::unique_lock&) () from /usr/lib/libstdc++.so.9 #3 0x004a7c13 in cmWorkerPoolInternal::Work(unsigned int) () --Type for more, q to quit, c to continue without paging-- #4 0x7c0af009e53a in ?? () from /usr/lib/libstdc++.so.9 #5 0x7c0aef40c6bc in ?? () from /usr/lib/libpthread.so.1 #6 0x7c0aeec92370 in ?? () from /usr/lib/libc.so.12 #7 0x0020 in ?? () #8 0x in ?? () Thread 3 (LWP 22853 of process 18255): #0 0x7c0aeeca87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7c0aef40a97d in pthread_cond_timedwait () from /usr/lib/libpthread.so.1 #2 0x7c0af00a0214 in std::condition_variable::wait(std::unique_lock&) () from /usr/lib/libstdc++.so.9 #3 0x004a7c4a in cmWorkerPoolInternal::Work(unsigned int) () #4 0x7c0af009e53a in ?? () from /usr/lib/libstdc++.so.9 #5 0x7c0aef40c6bc in ?? () from /usr/lib/libpthread.so.1 #6 0x7c0aeec92370 in ?? () from /usr/lib/libc.so.12 #7 0x0020 in ?? () #8 0x in ?? () Thread 2 (LWP 11876 of process 18255): #0 0x7c0aeeca87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7c0aef40a97d in pthread_cond_timedwait () from /usr/lib/libpthread.so.1 #2 0x7c0af00a0214 in std::condition_variable::wait(std::unique_lock&) () from /usr/lib/libstdc++.so.9 #3 0x004a7c13 in cmWorkerPoolInternal::Work(unsigned int) () #4 0x7c0af009e53a in ?? () from /usr/lib/libstdc++.so.9 #5 0x7c0aef40c6bc in ?? () from /usr/lib/libpthread.so.1 #6 0x7c0aeec92370 in ?? () from /usr/lib/libc.so.12 #7 0x in ?? () Thread 1 (LWP 24143 of process 18255): #0 0x7c0aeeca87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7c0aef40a97d in pthread_cond_timedwait () from /usr/lib/libpthread.so.1 #2 0x7c0af00a0214 in std::condition_variable::wait(std::unique_lock&) () from /usr/lib/libstdc++.so.9 #3 0x004a7c13 in cmWorkerPoolInternal::Work(unsigned int) () #4 0x7c0af009e53a in ?? () from /usr/lib/libstdc++.so.9 #5 0x7c0aef40c6bc in ?? () from /usr/lib/libpthread.so.1 #6 0x7c0aeec92370 in ?? () from /usr/lib/libc.so.12 #7 0x in ?? () (gdb) On Sat, 30 May 2020 at 10:31, Chavdar Ivanov wrote: > > On Sun, 24 May 2020 at 17:11, Chavdar Ivanov wrote: > > > > On Sun, 24 May 2020 at 16:39, Joerg Sonnenberger wrote: > > > > > > On Sun, May 24, 2020 at 09:22:41AM +0100, Chavdar Ivanov wrote: > > > > While doing pkg_rolling-replace on amd64 -current from yesterday, I > > > > got three times in a row a hang in cmake as the followingL > > > > > > Please attach with gdb and run "thread apply all bt" and give me the > > > result. There are still two issues in/around cmake I'm trying to > > > identify, so it would be interesting to know which of the two you are > > > hitting. > > > > Will do if I hit it again; I restarted pkg_rolling-replace and it has > > been going well since then. > > I tried in a short (10x) loop to build and clean the package which > caused cmake to hang; it didn't take place. > > > > > > > > > Joerg > > > > Chavdar > > > > -- > > > > > > -- > --
Re: cmake hanging
Hi, And another very similar; this time making wip/emacs-git, at the beginning of the clone process ... Find the GDB manual and other documentation resources online at: [38/47295] <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". Attaching to process 23291 Reading symbols from /usr/pkg/libexec/git-core/git... (No debugging symbols found in /usr/pkg/libexec/git-core/git) [New LWP 28957 of process 23291] [New LWP 558 of process 23291] [New LWP 23291 of process 23291] Reading symbols from /usr/pkg/lib/libpcre2-8.so.0... (No debugging symbols found in /usr/pkg/lib/libpcre2-8.so.0) Reading symbols from /usr/lib/libz.so.1... (No debugging symbols found in /usr/lib/libz.so.1) Reading symbols from /usr/pkg/lib/libiconv.so.2... (No debugging symbols found in /usr/pkg/lib/libiconv.so.2) Reading symbols from /usr/lib/libintl.so.1... (No debugging symbols found in /usr/lib/libintl.so.1) Reading symbols from /usr/lib/libpthread.so.1... (No debugging symbols found in /usr/lib/libpthread.so.1) Reading symbols from /usr/lib/libc.so.12... (No debugging symbols found in /usr/lib/libc.so.12) Reading symbols from /usr/lib/i18n/libUTF8.so.5.0... (No debugging symbols found in /usr/lib/i18n/libUTF8.so.5.0) Reading symbols from /usr/libexec/ld.elf_so... (No debugging symbols found in /usr/libexec/ld.elf_so) [Switching to LWP 26184 of process 23291] 0x005d9d19 in ubc_check () (gdb) thread apply all bt Thread 4 (LWP 23291 of process 23291): #0 0x7769a444551a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x7769a4c0c8c4 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x00441c50 in cmd_index_pack () #3 0x004053fe in handle_builtin () #4 0x00406301 in cmd_main () #5 0x005ea9a3 in main () Thread 3 (LWP 558 of process 23291): #0 0x005da8fd in ubc_check () #1 0x005d9853 in sha1_process () #2 0x005d996e in SHA1DCUpdate.part.0 () #3 0x00594de8 in write_object_file_prepare () #4 0x005976d7 in hash_object_file () #5 0x00440940 in resolve_delta () #6 0x00440a96 in find_unresolved_deltas () #7 0x00441191 in threaded_second_pass () #8 0x7769a4c0c6bc in ?? () from /usr/lib/libpthread.so.1 #9 0x7769a4492370 in ?? () from /usr/lib/libc.so.12 #10 0x in ?? () Thread 2 (LWP 28957 of process 23291): #0 0x005d7b04 in sha1_process () #1 0x005d996e in SHA1DCUpdate.part.0 () #2 0x00594de8 in write_object_file_prepare () #3 0x005976d7 in hash_object_file () #4 0x00440940 in resolve_delta () #5 0x00440a96 in find_unresolved_deltas () #6 0x00441191 in threaded_second_pass () #7 0x7769a4c0c6bc in ?? () from /usr/lib/libpthread.so.1 #8 0x7769a4492370 in ?? () from /usr/lib/libc.so.12 #9 0x in ?? () Thread 1 (LWP 26184 of process 23291): #0 0x005d9d19 in ubc_check () #1 0x005d9853 in sha1_process () #2 0x005d996e in SHA1DCUpdate.part.0 () #3 0x00594de8 in write_object_file_prepare () --Type for more, q to quit, c to continue without paging-- #4 0x005976d7 in hash_object_file () #5 0x00440940 in resolve_delta () #6 0x00440a96 in find_unresolved_deltas () #7 0x00441191 in threaded_second_pass () #8 0x7769a4c0c6bc in ?? () from /usr/lib/libpthread.so.1 #9 0x7769a4492370 in ?? () from /usr/lib/libc.so.12 #10 0x in ?? () (gdb) On Sat, 6 Jun 2020 at 18:45, Chavdar Ivanov wrote: > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote: > > > > Hi, > > > > I got another cmake hang during pkg_rolling-replace today, while > > building misc/kdepimlibs4, trace as follows: > > Just to mention that after I quit gdb and detached from the process it > continued and completed the build . . . > > > > > > . . . . > > > > Find the GDB manual and other documentation resources online at: > > > > [190/47198] > > <http://www.gnu.org/software/gdb/documentation/>. > > > > For help, type "help". > > Type "apropos word" to search for commands related to "word". > > Attaching to process 18255 > > Reading symbols from /usr/pkg/bin/cmake... > > (No debugging symbols found in /usr/pkg/bin/cmake) > > [New LWP 11876 of process 18255] > > [New LWP 22853 of process 18255] > > [New LWP 24648 of process 18255] > > [New LWP 19500 of process 18255] > > [New LWP 14244 of process 18255] > > [New LWP 704 of process 18255] > > [New LWP 876 of process 18255] > > [New LWP 18255 of process 18255] > > Reading symbols from /usr/lib/libexecinfo.so.0... > > (No debugging symbol
Re: cmake hanging
Hi, I just had another one, rebuilding gimp, running gegl. Again gdb -p ... ; quit sorted it out. On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov wrote: > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote: > > > > > > > > Hi, > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > building misc/kdepimlibs4, trace as follows: > > > > > > Just to mention that after I quit gdb and detached from the process it > > > continued and completed the build . . . > > > > Right, that's the bug in the mutex wakeup handling. > > The second hung sample - with git - also completed OK after I quit gdb... > > > > > Joerg > > > > -- > --
Re: cmake hanging
On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote: > > > > > > Hi, > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > building misc/kdepimlibs4, trace as follows: > > > > Just to mention that after I quit gdb and detached from the process it > > continued and completed the build . . . > > Right, that's the bug in the mutex wakeup handling. The second hung sample - with git - also completed OK after I quit gdb... > > Joerg --
Re: cmake hanging
On Sun, 7 Jun 2020 at 10:25, Chavdar Ivanov wrote: > > Hi, > > I just had another one, rebuilding gimp, running gegl. Again gdb -p > ... ; quit sorted it out. > > On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov wrote: > > > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote: > > > > > > > > > > Hi, > > > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > > building misc/kdepimlibs4, trace as follows: > > > > > > > > Just to mention that after I quit gdb and detached from the process it > > > > continued and completed the build . . . > > > > > > Right, that's the bug in the mutex wakeup handling. > > > > The second hung sample - with git - also completed OK after I quit gdb... I had another three cmake hangs just like this today, while rebuilding bits of kf5. Just to confirm - the moment one answers 'y' to the question whether to leave gdb the process continues and the build succeeds. This is somewhat annoying; although it does not stop the rebuild process, it makes it impossible to complete unattended. > > > > > > > > Joerg > > > > > > > > -- > > > > > > -- > --
Re: regression: xen domU no longer supports "type=cdrom" vbd disk
On Mon, 8 Jun 2020 at 22:26, Greg A. Woods wrote:
>
> I use xl.cfg "disk" entries like the following to mount a virtual CDROM
> in a Xen domU:
>
> 'format=raw, vdev=0x5, access=ro, devtype=cdrom,
> target=/images/NetBSD-9.0-amd64.iso'
>
> However since upgrading my -current source tree I've been seeing:
>
> xenbus0: ignoring device/vbd/4 type cdrom
>
> As shown in this patch I had to comment out the core of the mentioned
> change to be able to use an ISO image again as a virtual CDROM again:
>
>
> --- xenbus_probe.c.~1.55.~ 2020-05-30 17:32:39.672816814 -0700
> +++ xenbus_probe.c 2020-06-08 14:13:45.025527521 -0700
> @@ -443,6 +443,14 @@
> kmem_free(xbusd, xbusd->xbusd_sz);
> break;
> }
> +//revision 1.51
> +//date: 2020-04-28 06:21:01 -0700; author: bouyer; state: Exp; lines: +30
> -9; commitid: 5XOy6F9zbgN8C96C;
> +//Skip block device with device-type "cdrom", as their emulation can't be
> +//disabled; and the backend driver doesn't handle them either.
> +//Fix hang when booting with 'ioemu:hdc:cdrom' type disks.
> +//While there convert some printf to aprint_error()
> +//
> +#if 0 /* XXX breaks use of ISO files! */
> if (strcmp(xa.xa_type, "vbd") == 0) {
> char dtype[10];
> if (xenbus_read(NULL, xbusd->xbusd_path,
> @@ -461,6 +469,7 @@
> continue;
> }
> }
> +#endif
> err = read_backend_details(xbusd);
> if (err != 0) {
> aprint_error_dev(xenbus_dev,
>
>
> Now it works again:
>
> xbd4 at xenbus0 id 4: Xen Virtual Block Device Interface
> xbd4: using event channel 12
> ...
> boot device: xbd4
> root on xbd4a dumps on xbd4b
> root file system type: cd9660
I believe this was necessary at least under XCP-NG in PVHVM mode with
platform:viridian set to false - before the change the CD-ROM had to
be unconfigured as the system was hanging. After the change this was
no longer necessary and the CD-ROM was available.
>
> --
> Greg A. Woods
>
> Kelowna, BC +1 250 762-7675 RoboHack
> Planix, Inc. Avoncote Farms
--
Re: cmake hanging
On Mon, 8 Jun 2020 at 15:38, Chavdar Ivanov wrote: > > On Sun, 7 Jun 2020 at 10:25, Chavdar Ivanov wrote: > > > > Hi, > > > > I just had another one, rebuilding gimp, running gegl. Again gdb -p > > ... ; quit sorted it out. > > > > On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov wrote: > > > > > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > > > > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > > > building misc/kdepimlibs4, trace as follows: > > > > > > > > > > Just to mention that after I quit gdb and detached from the process it > > > > > continued and completed the build . . . > > > > > > > > Right, that's the bug in the mutex wakeup handling. > > > > > > The second hung sample - with git - also completed OK after I quit gdb... > > I had another three cmake hangs just like this today, while rebuilding > bits of kf5. > > Just to confirm - the moment one answers 'y' to the question whether > to leave gdb the process continues and the build succeeds. > > This is somewhat annoying; although it does not stop the rebuild > process, it makes it impossible to complete unattended. I've had probably about 30 of these today, it renders bits of pkgsrc unusable on -current. I had to go through another kf5 update today and I've got a split tmux window, left side going through the build, right - just waiting for a hang so that I can attach to the cmake process with gdb and quit; the build then carries on. Is there any workaround for this hang? Here is another typical trace: [Switching to LWP 5461 of process 15944] 0x7d33fb4a87aa in ___lwp_park60 () from /usr/lib/libc.so.12 (gdb) thread apply all bt Thread 2 (LWP 15944 of process 15944): #0 0x7d33fb44551a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x7d33fbc0c8e4 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x7d33fc89e57b in std::thread::join() () from /usr/lib/libstdc++.so.9 #3 0x004a87eb in cmWorkerPoolWorker::~cmWorkerPoolWorker() () #4 0x004a8e2e in cmWorkerPoolInternal::UVSlotEnd(uv_async_s*) () #5 0x7d33fd20f69f in uv__async_io (loop=0x7d33fe8bb000, w=, events=) at src/unix/async.c:163 #6 0x7d33fd21d2aa in uv__io_poll (loop=loop@entry=0x7d33fe8bb000, timeout=) at src/unix/kqueue.c:343 #7 0x7d33fd20fc87 in uv_run (loop=0x7d33fe8bb000, mode=UV_RUN_DEFAULT) at src/unix/core.c:381 #8 0x004a948a in cmWorkerPoolInternal::Process() () #9 0x004a94d4 in cmWorkerPool::Process(void*) () #10 0x004731d4 in (anonymous namespace)::cmQtAutoMocUicT::Process() () #11 0x0067009c in cmQtAutoGenerator::Run(cm::string_view, cm::string_view) () #12 0x00462e22 in cmQtAutoMocUic(cm::string_view, cm::string_view) () #13 0x004186d5 in cmcmd::ExecuteCMakeCommand(std::vector, std::allocator >, std::allocator, std::allocator > > > const&) () #14 0x007652ea in main () Thread 1 (LWP 5461 of process 15944): #0 0x7d33fb4a87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7d33fbc096fd in ?? () from /usr/lib/libpthread.so.1 #2 0x004a7d35 in cmWorkerPoolInternal::Work(unsigned int) () #3 0x7d33fc89e53a in ?? () from /usr/lib/libstdc++.so.9 #4 0x7d33fbc0c6dc in ?? () from /usr/lib/libpthread.so.1 #5 0x7d33fb492370 in ?? () from /usr/lib/libc.so.12 #6 0x in ?? () Chavdar > > > > > > > > > > > > Joerg > > > > > > > > > > > > -- > > > > > > > > > > > -- > > > > > > -- > --
-current panic
Hi, I might have seen a similar one these days reported; I got: . > crash -M netbsd.24.core -N netbsd.24 >──(Fri,Jul24)─┘ Crash version 9.99.69, image version 9.99.69. crash: _kvm_kvatop(0) Kernel compiled without options LOCKDEBUG. System panicked: ffs_blkfree: bad size: dev = 0xa801, bno = 7234308676127845999 bsize = 32768, size = 32768, fs = / Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NARCNET() at 0 __LARGE_PAGE_SIZE() at c35526 sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf ffs_mapsearch() at ffs_mapsearch ffs_blkfree() at ffs_blkfree+0x82 ffs_indirtrunc() at ffs_indirtrunc+0x3ea ffs_indirtrunc() at ffs_indirtrunc+0x32c ffs_truncate() at ffs_truncate+0xaad ufs_truncate_retry() at ufs_truncate_retry+0x63 ufs_inactive() at ufs_inactive+0x130 VOP_INACTIVE() at VOP_INACTIVE+0x3c vrelel() at vrelel+0x13d vn_close() at vn_close+0x3f closef() at closef+0x56 fd_close() at fd_close+0x1fd sys_close() at sys_close+0x1f syscall() at syscall+0x26e --- syscall (number 6) --- syscall+0x26e: on amd64 -current from 22nd of July. Chavdar --
Re: Samba DC provisioning fails with ACL-enabled NetBSD-current
On Fri, 24 Jul 2020 at 01:09, Christos Zoulas wrote: > > Be very careful and use a separate partition for sysvol because Matthias > reported > fs corruption which I have not looked at yet. Thanks for the warning. It runs on a XCP-NG guest, so I will take a snapshot. > > christos > > On Jul 23, 2020, at 7:39 PM, Chavdar Ivanov wrote: > > On Thu, 23 Jul 2020 at 16:25, Chavdar Ivanov wrote: > > > On Thu, 23 Jul 2020 at 15:59, Christos Zoulas wrote: > > > You are missing: > > PKG_OPTIONS.samba4= acl > > > Unfortunately not - this is the line: > > PKG_OPTIONS.samba4=acl avahi ldap pam winbind > > and I get: > > #... /net/samba4 ❯ make show-options > Any of the following general options may be selected: >acl Enable POSIX ACL support. >ads Enable Windows Active Directory support. >avahiEnable DNS service discovery and multicast DNS support. >fam Support using File Alteration Monitor (FAM). >ldap Enable LDAP support. >pam Enable PAM support. >winbind Enable name-service switch daemon support using > Windows Servers. > > These options are enabled by default: >ads avahi ldap pam winbind > > These options are currently enabled: >acl ads avahi ldap pam winbind > > You can select which build options to use by setting PKG_DEFAULT_OPTIONS > or PKG_OPTIONS.samba4. > > As I said, configure definitely has --with-acl-support and the log > file indicates attempts to find the bits in question, so it is > something else. > > This is a fairly used pkgsrc build host, perhaps something has gone > wrong at some stage; I have another one setup with much less changes > since the original modification, I'll cvs update the whole tree and > after a rolling-replace will try one more to build samba4 with ad > support. > > > > The build on the second pkgsrc host produced a working dc. The two > pkgsrc hosts use the same /etc/mk.conf file, with the exception that > on the first - failed one - the default python is 3.7, hereas on the > second one it is 3.8, if this matters. > > Now some domain joining... > > > > in /etc/mk.conf > > christos > > On Jul 23, 2020, at 9:54 AM, Chavdar Ivanov wrote: > > ... > Chavdar > > --
strange hang on wscons
Hi, On a -current system, when running wip/neovim-git on the console or any of the enabled terminals, I get a hang - the screen becomes entirely black and no longer responds, I cannot blindly quit nvim anymore. If I ssh to another system and attach with gdb to the process, I get: ... 0x7b6def844d5a in _sys___kevent50 () from /usr/lib/libc.so.12 (gdb) thread apply all bt Thread 2 (LWP 8876 of process 8876): #0 0x7b6def844d5a in _sys___kevent50 () from /usr/lib/libc.so.12 #1 0x7b6df0c079d8 in __kevent50 () from /usr/lib/libpthread.so.1 #2 0x7b6df281d78e in uv__io_poll (loop=loop@entry=0x960600 , timeout=) at src/unix/kqueue.c:214 #3 0x7b6df280fc87 in uv_run (loop=loop@entry=0x960600 , mode=UV_RUN_ONCE) at src/unix/core.c:385 #4 0x004ca70c in loop_poll_events (loop=0x960600 , ms=ms@entry=-1) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/event/loop.c:62 #5 0x005912b0 in inbuf_poll (ms=ms@entry=-1, events=events@entry=0x7b6df36f8000) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/os/input.c:403 #6 0x0059170c in os_inchar (buf=buf@entry=0x0, maxlen=maxlen@entry=0, ms=ms@entry=-1, tb_change_cnt=tb_change_cnt@entry=0, events=0x7b6df36f8000) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/os/input.c:128 #7 0x006059d3 in state_enter (s=s@entry=0x7f781370) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/state.c:54 #8 0x00569af9 in normal_enter (cmdwin=cmdwin@entry=false, noexmode=noexmode@entry=false) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/normal.c:463 #9 0x005380d1 in main (argc=, argv=) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/main.c:553 Thread 1 (LWP 8779 of process 8876): #0 0x7b6def844d5a in _sys___kevent50 () from /usr/lib/libc.so.12 #1 0x7b6df0c079d8 in __kevent50 () from /usr/lib/libpthread.so.1 #2 0x7b6df281d78e in uv__io_poll (loop=loop@entry=0x7b6deedff9c0, timeout=) at src/unix/kqueue.c:214 #3 0x7b6df280fc87 in uv_run (loop=loop@entry=0x7b6deedff9c0, mode=UV_RUN_ONCE) at src/unix/core.c:385 #4 0x004ca70c in loop_poll_events (loop=loop@entry=0x7b6deedff9c0, ms=ms@entry=-1) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/event/loop.c:62 #5 0x0062125c in tui_main (bridge=0x7b6df360e000, ui=0x7b6df36b4140) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/tui/tui.c:451 #6 0x00626646 in ui_thread_run (data=) at /usr/pkgsrc/wip/neovim-git/work/neovim/src/nvim/ui_bridge.c:104 #7 0x7b6df0c0bee0 in ?? () from /usr/lib/libpthread.so.1 #8 0x7b6def892390 in ?? () from /usr/lib/libc.so.12 #9 0x0040 in ?? () #10 0x7b6def20 in ?? () #11 0x001003a0efff in ?? () #12 0x7b6defc0 in ?? () #13 0x001fff40 in ?? () #14 0x in ?? () If I now kill the nvim process, the screen remains stuck; I cannot blindly logout and then login again for instance; perhaps there is a way to recover the console I am not aware of, but for now I just reboot... The same program runs fine under X or if I ssh to the machine from elsewhere. On the other hand, it happens the same way if I ssh from the console to some other system with neovim installed and run it. Chavdar --
Re: Failure durin nbmake build
On Sun, 26 Jul 2020 at 14:58, Patrick Welche wrote: > > On Sun, Jul 26, 2020 at 10:33:33AM +0100, Chavdar Ivanov wrote: > > cc -D_PATH_DEFSYSPATH="/home/sysbuild/src/share/mk" > > -DDEFSHELL_CUSTOM="/bin/sh" -DHAVE_SETENV=1 -DHAVE_STRDUP=1 > > -DHAVE_STRERROR=1 -DHAVE_STRFTIME=1 -DHAVE_VSNPRINTF=1 -O -c > > /home/sysbuild/src/usr.bin/make/lst.lib/*.c > > cc: error: /home/sysbuild/src/usr.bin/make/lst.lib/*.c: No such file > > or directory > > cc: fatal error: no input files > > compilation terminated. > > I think the lst.lib directory has just been removed. I haven't seen > your build error, but do see a couple of references to lst.lib in Makefiles. It was sorted out recently, the build is going ahead. > > Cheers, > > Patrick Chavdar --
Failure durin nbmake build
Hi, I am getting repeated .. cc -D_PATH_DEFSYSPATH="/home/sysbuild/src/share/mk" -DDEFSHELL_CUSTOM="/bin/sh" -DHAVE_SETENV=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRFTIME=1 -DHAVE_VSNPRINTF=1 -O -c /home/sysbuild/src/usr.bin/make/lst.lib/*.c cc: error: /home/sysbuild/src/usr.bin/make/lst.lib/*.c: No such file or directory cc: fatal error: no input files compilation terminated. .. I've cleaned and updated everything possible (make cleandir in src, put away the old obj and tools directories, essentially starting from scratch). Chavdar --
Re: [PATCH] net/samba4: relocate Sysvol to persist between reboots & move variable data out of /usr/pkg/etc/...
This being a place people are trying samba4 as a DC, I got a repeatable panic on one of the systems I am trying it on, as follows: crash: _kvm_kvatop(0) Crash version 9.99.69, image version 9.99.69. Kernel compiled without options LOCKDEBUG. System panicked: /: bad dir ino 657889 at offset 0: Bad dir (not rounded), reclen=0x2e33, namlen=51, dirsiz=60 <= reclen=11827 <= maxsize=512, flags=0x2005900, entryoffsetinblock=0, dirblksiz=512 Backtrace from time of crash is available. _KERNEL_OPT_NARCNET() at 0 _KERNEL_OPT_DDB_HISTORY_SIZE() at _KERNEL_OPT_DDB_HISTORY_SIZE sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf ufs_lookup() at ufs_lookup+0x518 VOP_LOOKUP() at VOP_LOOKUP+0x42 lookup_once() at lookup_once+0x1a1 namei_tryemulroot() at namei_tryemulroot+0xacf namei() at namei+0x29 vn_open() at vn_open+0x9a do_open() at do_open+0x112 do_sys_openat() at do_sys_openat+0x72 sys_open() at sys_open+0x24 syscall() at syscall+0x26e --- syscall (number 5) --- syscall+0x26e: The other panics differ only by the dir ino displayed; the rest is exactly the same. I forced fsck on / and repeated - with the same result. / is mounted with posix1eacls and I've ran tunefs as well. The panic occurs during the provision, using the exact command shown earlier in the thread, at the following moment of the provision: ... INFO 2020-07-28 17:55:16,331 pid:2844 /usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py #1586: Setting up well known security principals INFO 2020-07-28 17:55:16,358 pid:2844 /usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py #1600: Setting up sam.ldb users and groups INFO 2020-07-28 17:55:16,460 pid:2844 /usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py #1608: Setting up self join . Repacking database from v1 to v2 format (first record CN=FRS-Replica-Set-GUID,CN=Schema,CN=Configuration,DC=lorien,DC=lan) Repack: re-packed 1 records so far Repacking database from v1 to v2 format (first record CN=foreignSecurityPrincipal-Display,CN=411,CN=DisplaySpecifiers,CN=Configuration,DC=lorien,DC=lan) Repacking database from v1 to v2 format (first record CN=IP Security,CN=System,DC=lorien,DC=lan) On the second machine I am trying this - which uses python3.8 and which provisioned OK with the previous version and worked for a few days, but - as was rightly explained earlier - the database was lost after a reboot, new provision fails at a later stage with a message that an object has not been found; I rebooted and forced fsck on /, which didn't find anything, but I got the same panic as above when i tried to 'rm -r /var/db/samba4/*' . So methinks there are still outstanding problems with the underlying file system code, as far as samba4 as dc is concerned. Chavdar On Tue, 28 Jul 2020 at 02:12, Christos Zoulas wrote: > > Done, thanks! > > christos > > > On Jul 27, 2020, at 8:49 PM, Matthias Petermann > > wrote: > > > > Hello everyone, > > > > with the introduction of FFS ACLs Samba can be used as windows domain > > controller (DC). The DC needs a directory to persist its policies and > > scripts - the so called Sysvol. > > > > The creation of the Sysvol typically takes place during the domain > > provisioning with samba-tool. At the moment, the default Samba4 from pkgsrc > > is configured to put Sysvol below /var/run/sysvol. Unfortunately, there is > > a critical issue with this location: Everything inside /var/run gets purged > > as part of the systems startup sequence. So this means losing all your > > policies, ultimately a corruption of the domain controller state at the > > next reboot. > > > > Therefore, Sysvol needs to be relocated to a persistent place. > > > > I checked how this is implemented elsewhere: > > > > * On Linux systems Sysvol is typically located at /var/lib/samba/sysvol > > * On FreeBSD the location is /var/db/samba4/sysvol > > > > As /var/lib is not mentioned in HIER(7) at all, I guess this is Linux > > specific. Therefore I would propose the FreeBSD-way and put it below > > /var/db/samba4/sysvol. In addition to that I think it would be a good idea > > to relocate the variable Samba data (databases, caches) currently located > > at /usr/pkg/etc/samba/private) as well. My proposal for the target is > > /var/db/samba4/private. > > > > Attached is a patch which applies to pkgsrc-current. I did perform the > > usual tests (removing all previous configuration and databases, > > provisioning a new domain, joining a Windows client to the domain) - no > > issues so far. > > > > What do you think? > > > > Kind regards > > Matthias > > > --
Re: early tools -current build failure
Ok, thanks. On Sun, 19 Jul 2020 at 13:51, Martin Husemann wrote: > On Sun, Jul 19, 2020 at 01:42:30PM +0100, Chavdar Ivanov wrote: > > Any ideas? Perhaps I've missed something new in the BUILDING file? > > there is nothing particular in these two lines of the bsd.nls.mk: > > make(1) is broken right now. > > Martin > --
Re: Samba DC provisioning fails with ACL-enabled NetBSD-current
On Thu, 23 Jul 2020 at 15:59, Christos Zoulas wrote:
>
> You are missing:
>
> PKG_OPTIONS.samba4= acl
Unfortunately not - this is the line:
PKG_OPTIONS.samba4=acl avahi ldap pam winbind
and I get:
#... /net/samba4 ❯ make show-options
Any of the following general options may be selected:
acl Enable POSIX ACL support.
ads Enable Windows Active Directory support.
avahiEnable DNS service discovery and multicast DNS support.
fam Support using File Alteration Monitor (FAM).
ldap Enable LDAP support.
pam Enable PAM support.
winbind Enable name-service switch daemon support using
Windows Servers.
These options are enabled by default:
ads avahi ldap pam winbind
These options are currently enabled:
acl ads avahi ldap pam winbind
You can select which build options to use by setting PKG_DEFAULT_OPTIONS
or PKG_OPTIONS.samba4.
As I said, configure definitely has --with-acl-support and the log
file indicates attempts to find the bits in question, so it is
something else.
This is a fairly used pkgsrc build host, perhaps something has gone
wrong at some stage; I have another one setup with much less changes
since the original modification, I'll cvs update the whole tree and
after a rolling-replace will try one more to build samba4 with ad
support.
>
> in /etc/mk.conf
>
> christos
>
> > On Jul 23, 2020, at 9:54 AM, Chavdar Ivanov wrote:
> >
> > I decided to try the same procedure under -current. It failed with the same:
> >
> > ...
> > File "/usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py",
> > line 1707, in setsysvolacl
> >raise ProvisioningError("Samba was compiled without the posix ACL
> > support that s3fs requires. "
> > ...
> >
> > I checked the config.log file of the samba4 build and found in
> > bin/config.log:
> >
> > # using /usr/pkgsrc/net/samba4/work/samba-4.12.5/buildtools/bin/waf
> > configure --prefix=/usr/pkg --infodir=/usr/pkg/info
> > --mandir=/usr/pkg/man --datarootdir=/usr/pkg/share/samba --libdir=
> > --localedir=/usr/pkg/share/locale --docdir=/usr/pkg/share/doc/samba
> > --with-statedir=/var/run --with-privatedir=/usr/pkg/etc/samba/private
> > --with-piddir=/var/run --with-cachedir=/var/run
> > --with-lockdir=/var/run --with-logfilebase=/var/log
> > --with-sockets-dir=/var/run --with-modulesdir=/usr/pkg/lib/samba
> > --with-privatelibdir=/usr/pkg/lib/samba/private
> > --with-privileged-socket-dir=/var/run
> > --with-configdir=/usr/pkg/etc/samba --with-libiconv=/usr/pkg
> > --abi-check-disable --disable-symbol-versions --jobs=4 --without-gpgme
> > --without-regedit --with-acl-support --with-ads --disable-cups
> > --without-fam --with-ldap --with-pam
> > --with-pammodulesdir=/usr/pkg/lib/samba/security --with-winbind
> > --enable-avahi
> >
> > So '--with-acl-support' is present. Further down it checks for a
> > number of other acl related include files, does not find libacl.h, but
> > finds acl.h; it can't find the library, though I don't know if it
> > should - I couldn't find any.
> >
> > The rest of the requirements have been apparently fulfilled; the
> > samba4 build is from this morning after the latest modifications to
> > the package; I've modified /etc/fstab to add posix1eacls and ran
> > tunefs, so I get
> >
> > ➜ xci getfacl .
> > # file: .
> > # owner: xci
> > # group: users
> > user::rwx
> > group::r-x
> > other::r-x
> >
> > Am I missing something else? I ran the provision command with '-d 10'
> > and got a 151MB log file, ending with
> > ...
> > dfs_samba4: connect to service[Unknown Service (snum == -1)]
> > vfswrap_fs_capabilities: timestamp resolution of sec available on
> > share (null), directory /
> > vfs_ChDir to /
> > vfs_ChDir: vfs_ChDir got /
> > dfs_samba4_disconnect() connect to service[(null)].
> > ERROR(): Provision failed -
> > ProvisioningError: Samba was compiled without the posix ACL support
> > that s3fs requires. Try installing libacl1-dev or libacl-devel, then
> > re-run configure and make.
> > File "/usr/pkg/lib/python3.7/site-packages/samba/netcmd/domain.py",
> > line 505, in run
> >backend_store_size=backend_store_size)
> > File "/usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py",
> > line 2366, in provision
> >backend_store_size=backend_store_size)
> > File "/usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py",
> > line 1992, in provision_fill
> >names.domaindn, lp, use_ntvfs)
> > Fi
