Re: kernel: psm: keyboard controller failed at git revision 3334a537ed38
> On 27 Dec 2023, at 21:44, Ruslan Makhmatkhanov wrote: > > Hello, > > I updated my tree to revision 3334a537ed38, made buildworld and kernel as > usual. > Booting with new kernel leads to keyboard not working at system login prompt > and the message "kernel: psm: keyboard controller failed" in > /var/log/messages. > > Reverting to boot the old kernel main-n266238-03e2fc4c4446 makes keyboard and > system working again. Did you try to git bisect between the working and non-working commits? — Juraj Lutter o...@freebsd.org
Re: uname -KU 1500001 1500000
> On 15 Nov 2023, at 08:09, Graham Perrin wrote:
>
> On Mon, 2 Oct 2023 at 08:33, Mark Millard wrote:
>
>> Or file and ls results for the amd64.amd64/usr.bin/uname/uname.o ?
>> (Just checking for if there are surprises.)
>
> Please, where would I find that file? I'm lost
Under ${MAKEOBJDIRPREFIX}/$(SRCDIR) (in case you do the build yourself).
MAKEOBJDIRPREFIX is normally /usr/obj and SRCDIR is /usr/src (in case you don’t
use any other).
—
Juraj Lutter
o...@freebsd.org
Re: how to set vfs.zfs.arc.max in 15-current ?
> On 13 Oct 2023, at 00:59, void wrote: > >> Try reducing your arc.max by an order of 10. This suggests that it's >> probably failing in param_set_arc_max() in the val >= arc_all_memory() >> comparison.. > > Hi, thanks for replying. Sadly, your suggestion doesn't work in this case: > > root@beer:/usr/src# sysctl vfs.zfs.arc.max=8589934592 > vfs.zfs.arc.max: 0 > sysctl: vfs.zfs.arc.max=8589934592: Invalid argument Set also vfs.zfs.arc.min to some value higher than zero. — Juraj Lutter o...@freebsd.org
Re: kernel 100% CPU
> On 3 Sep 2023, at 09:56, Graham Perrin wrote: >> >> dtrace -s script.d -o out This is the actual command. The script mjg@ provided is not a shell script. The script filename is “script.d” where you should put the above-mentioned DTrace script (without the "dtrace -s script.d -o out” line). — Juraj Lutter o...@freebsd.org
Re: 7addfafe73e0 early boot kernel panics
> On 22 Aug 2023, at 16:30, Graham Perrin wrote: > > I could not get 7addfafe73e0 to boot. > > <https://cgit.freebsd.org/src/log/?qt=range=7addfafe73e0> (2023-08-21, 21 > hours ago). > > I reverted to a edacf4b4824a boot environment, which is fine. > > Should I simply update to ? > Assuming a known issue with 7addfafe73e0 Recent c941b82e1c31 boots and runs fine (as a bhyve guest) otis — Juraj Lutter o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
> On 13 Aug 2023, at 23:13, Mark Millard wrote:
>
> On Aug 13, 2023, at 14:01, Mark Millard wrote:
>
>> On Aug 13, 2023, at 13:19, Juraj Lutter wrote:
>>
>>>> On 13 Aug 2023, at 21:13, Mark Millard wrote:
>>>>
>>>> But the offical CI builds on amd64 do not have the problem.
>>>>
>>>> We still have not found what is different about your context from the
>>>> standard context used for CI builds and snapshot builds, all of which
>>>> have worked find building on amd64 to target aarch64 with armv7 support.
>>>
>>> My src.conf:
>>>
>>> WITHOUT_PROFILE=yes
>>> WITHOUT_TESTS=yes
>>> WITHOUT_STATIC=yes
>>>
>>> WITHOUT_LLVM_TARGET_ALL=yes
>>
>> Starting below this is wrong presuming all
>> builds are actually done on amd64:
>>
>>> .if "${TARGET}" == "arm64" && "${TARGET_ARCH}" == "aarch64"
>>> KERNCONF?=GENERIC-MMCCAM
>>> REPODIR?=/data/poudriere/packages/pkgbase
>>> MODULES_EXTRA="rpi_ft5406"
>>> WITH_LLVM_TARGET_AARCH64=yes
>>> WITH_LLVM_TARGET_ARM=yes
>>> .else
>>> KERNCONF?=GENERIC-NODEBUG
>>> REPODIR?=/data/poudriere/packages/pkgbase
>>> WITH_LLVM_TARGET_AARCH64=yes
>>> WITH_LLVM_TARGET_X86=yes
>>> .endif
>>
>> Ending here.
>>
>> This is written as if there were separate toolchains for
>> each target. That is not how llvm/clang/lld works,
>> unlike gcc. One toolchain covers all the targets. That
>> is what the FreBSD llvm support is structured for.
>>
>> You want the one llvm/clang/lld toolchain that includes
>> everything required to build any/all of:
>>
>> A) amd64
>> B) i386 for amd64's lib32
>> C) aarch64
>> D) armv7 for aarch64's lib32
>>
>> So the *_LLVM_TARGET_* parts would be more like:
>>
>> WITHOUT_PROFILE=yes
>> WITHOUT_TESTS=yes
>> WITHOUT_STATIC=yes
>>
>> WITHOUT_LLVM_TARGET_ALL=yes
>> WITH_LLVM_TARGET_AARCH64=yes
>> WITH_LLVM_TARGET_X86=yes
>> WITH_LLVM_TARGET_AARCH64=yes
>> WITH_LLVM_TARGET_ARM=yes
>
If you look closer, you will see that:
WITH_LLVM_TARGET_AARCH64=yes
WITH_LLVM_TARGET_X86=yes
is in effect when I do “make buildworld” without any TARGET and TARGET_ARCH,
i.e. when I build the OS for the host (that is, 14.0/amd64).
But once I specify make TARGET=arm64 TARGET_ARCH=aarch64, only the lines:
WITH_LLVM_TARGET_AARCH64=yes
WITH_LLVM_TARGET_ARM=yes
are in effect. The line “WITH_LLVM_TARGET_ARM=yes” has only been added today
for a test, but it did not make any difference.
—
Juraj Lutter
o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
> On 13 Aug 2023, at 21:13, Mark Millard wrote:
>
> But the offical CI builds on amd64 do not have the problem.
>
> We still have not found what is different about your context from the
> standard context used for CI builds and snapshot builds, all of which
> have worked find building on amd64 to target aarch64 with armv7 support.
My src.conf:
WITHOUT_PROFILE=yes
WITHOUT_TESTS=yes
WITHOUT_STATIC=yes
WITHOUT_LLVM_TARGET_ALL=yes
.if "${TARGET}" == "arm64" && "${TARGET_ARCH}" == "aarch64"
KERNCONF?=GENERIC-MMCCAM
REPODIR?=/data/poudriere/packages/pkgbase
MODULES_EXTRA="rpi_ft5406"
WITH_LLVM_TARGET_AARCH64=yes
WITH_LLVM_TARGET_ARM=yes
.else
KERNCONF?=GENERIC-NODEBUG
REPODIR?=/data/poudriere/packages/pkgbase
WITH_LLVM_TARGET_AARCH64=yes
WITH_LLVM_TARGET_X86=yes
.endif
make.conf is empty, git workdir has `main’ checked out, without any
modifications (git status reports clean workdir)
otis
—
Juraj Lutter
o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
> On 13 Aug 2023, at 19:50, Mark Millard wrote: > > So it still looks to me like a build infrastructure problem: > it did not do what it said it would do. I've no clue about > why at this point. > > I'll note that clang and lld do not get per-target builds like > gcc does. "bootstrap" means for getting version differences early > on in this context, not the targeting. See the other thread. After backing out f1d5183124d3e18d410ded61e45adb9a23b23c83, cross tools started to build again. otis — Juraj Lutter o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
> On 13 Aug 2023, at 17:22, Juraj Lutter wrote: > > > >> On 13 Aug 2023, at 17:17, Mike Karels wrote: >> >> >> On 13 Aug 2023, at 10:00, Juraj Lutter wrote: >> >>>> On 13 Aug 2023, at 16:55, Mike Karels wrote: >>>> >>>> >>>> lib32 is not built until stage 4.3.1, after build and cross tools. I >>>> tested >>>> a build just now on amd64 with empty /usr/obj, and it worked (make -j$NCU >>>> buildworld TARGET=arm64 TARGET_ARCH=aarch64). However, the host was >>>> approximately at the level of ALPHA1, and the first lines of the output >>>> showed that a cross-compiler was not needed. However, my earlier builds >>>> that required a cross-compiler worked fine. >>>> >>> >>> Earlier builds worked for me as well. I use it for “make packages” that I >>> use to upgrade my RPi. >>> >>> It definitely worked on 20230712 when I did the build last time. >> >> That was before the lib32 addition went in (20230725). > > Yeah, that’s why I will try with commit just before > eafd028327cee688b54bc526e088c2a3b98f94e0 or > with eafd028327cee688b54bc526e088c2a3b98f94e0 backed out to see if it will > help. To me it seems that f1d5183124d3e18d410ded61e45adb9a23b23c83 is the commit that broke it. I did “git revert” on that single commit, these were rebuilt: Building /usr/obj/usr/src/arm64.aarch64/tmp/obj-tools/lib/clang/libllvmminimal/Support/Path.o Building /usr/obj/usr/src/arm64.aarch64/tmp/obj-tools/lib/clang/libllvmminimal/Support/Signals.o Building /usr/obj/usr/src/arm64.aarch64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a And cross tools started to build as well. otis — Juraj Lutter o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
Mark, > On 13 Aug 2023, at 19:04, Mark Millard wrote: > > No arm64.aarch64/tmp/ SYSTEM_COMPILER or SYSTEM_LINKER bootstrap > compiler/linker were built. > > From what I can tell, this leads to: > > cc -march=armv7 -m32 -target armv7-unknown-freebsd14.0-gnueabihf > -DCOMPAT_LIBCOMPAT=\"32\" -DCOMPAT_libcompat=\"32\" -DCOMPAT_LIB32 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib32 -O2 -pipe -fno-common -fPIC > -g -gz=zlib -MD -MF.depend.libssp_nonshared.o -MTlibssp_nonshared.o > -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers > -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign > -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-error=unused-but-set-parameter -Qunused-arguments-c > /usr/src/lib/libssp_nonshared/libssp_nonshared.c -o libssp_nonshared.o > > using the pre-existing system compiler that, in your context, gets: > > error: unable to create target: 'No available targets are compatible with > triple "armv7-unknown-freebsd14.0-gnueabihf"' > 1 error generated. > True, exactly the same error I’m getting. > > I doubt that "make package" was tested for being able to handle > the lib32 addition to aarch64 builds for SYSTEM_COMPILER or > SYSTEM_LINKER bootstrap cases. > I’m getting it in buildworld, not in packages (it does not come to packages target) otis — Juraj Lutter o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
> On 13 Aug 2023, at 17:17, Mike Karels wrote: > > > On 13 Aug 2023, at 10:00, Juraj Lutter wrote: > >>> On 13 Aug 2023, at 16:55, Mike Karels wrote: >>> >>> >>> lib32 is not built until stage 4.3.1, after build and cross tools. I tested >>> a build just now on amd64 with empty /usr/obj, and it worked (make -j$NCU >>> buildworld TARGET=arm64 TARGET_ARCH=aarch64). However, the host was >>> approximately at the level of ALPHA1, and the first lines of the output >>> showed that a cross-compiler was not needed. However, my earlier builds >>> that required a cross-compiler worked fine. >>> >> >> Earlier builds worked for me as well. I use it for “make packages” that I >> use to upgrade my RPi. >> >> It definitely worked on 20230712 when I did the build last time. > > That was before the lib32 addition went in (20230725). Yeah, that’s why I will try with commit just before eafd028327cee688b54bc526e088c2a3b98f94e0 or with eafd028327cee688b54bc526e088c2a3b98f94e0 backed out to see if it will help. otis — Juraj Lutter o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
> On 13 Aug 2023, at 16:55, Mike Karels wrote: > > > lib32 is not built until stage 4.3.1, after build and cross tools. I tested > a build just now on amd64 with empty /usr/obj, and it worked (make -j$NCU > buildworld TARGET=arm64 TARGET_ARCH=aarch64). However, the host was > approximately at the level of ALPHA1, and the first lines of the output > showed that a cross-compiler was not needed. However, my earlier builds > that required a cross-compiler worked fine. > Earlier builds worked for me as well. I use it for “make packages” that I use to upgrade my RPi. It definitely worked on 20230712 when I did the build last time. > Yes, lib32 is supposed to be built on aarch64 as of a few weeks ago. > >> So it seems that “native-xtools” and associated targets are not being built. >> If I do “make TARGET=arm64 TARGET_ARCH=aarch64 native-xtools”, cross tools >> are >> being built and lib32 is built, in turn, also. > > I don't see native-xtools built either. but the build worked. > > Have you checked src.conf? Yes, I only have KERNCONF there. I will try with eafd028327cee688b54bc526e088c2a3b98f94e0 backed out to see if it will make any difference. otis — Juraj Lutter o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
> On 13 Aug 2023, at 14:42, Juraj Lutter wrote: > > Hi, > >> On 13 Aug 2023, at 00:17, Mike Karels wrote: >> >> On 12 Aug 2023, at 15:32, Juraj Lutter wrote: >> >> Did the buildworld start out by building a cross-compiler? >> >> Have you tried without meta mode? With a clean objdir, I don't see how >> it would matter, but I'm not sure I've tried it. >> >> The ALPHA1 builds seem to have worked, but I think they run on arm64. >> > > See here: https://files.wilbury.net/s/bJKKB5Kbta6DNqB for the full log. > > As I read it, lib32 is being built before crosscompiler. Is lib32 supposed to > be built on aarch64? So it seems that “native-xtools” and associated targets are not being built. If I do “make TARGET=arm64 TARGET_ARCH=aarch64 native-xtools”, cross tools are being built and lib32 is built, in turn, also. The commit I suspect that lead into this was eafd028327cee688b54bc526e088c2a3b98f94e0 (there sees to not be any other related changes fiddling with make targets). otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
Hi, > On 13 Aug 2023, at 00:17, Mike Karels wrote: > > On 12 Aug 2023, at 15:32, Juraj Lutter wrote: > > Did the buildworld start out by building a cross-compiler? > > Have you tried without meta mode? With a clean objdir, I don't see how > it would matter, but I'm not sure I've tried it. > > The ALPHA1 builds seem to have worked, but I think they run on arm64. > See here: https://files.wilbury.net/s/bJKKB5Kbta6DNqB for the full log. As I read it, lib32 is being built before crosscompiler. Is lib32 supposed to be built on aarch64? otis — Juraj Lutter o...@freebsd.org
Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
Hi, recent 14.0-ALPHA1 sources is giving an error: Building /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libssp_nonshared/libssp_nonshared.o Building /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libgcc_eh/int_util.o error: unable to create target: 'No available targets are compatible with triple "armv7-unknown-freebsd14.0-gnueabihf"' 1 error generated. error: unable to create target: 'No available targets are compatible with triple "armv7-unknown-freebsd14.0-gnueabihf"' *** [libssp_nonshared.o] Error code 1 Commandline: make -j`sysctl -n hw.ncpu` WITH_META_MODE=1 TARGET=arm64 TARGET_ARCH=aarch64 buildworld buildkernel The build runs in clean objdir, src git hash 220427da0e9b2c1d8e964120becc17eb7524e46f Host runs 14.0-CURRENT 28d2e3b5dedf Am I missing something obvious? Thanks. — Juraj Lutter o...@freebsd.org
LOR in network
Hi, I’ve seen following LOR in -CURRENT (3a46fe226193) on GENERIC arm64.aarch64: lock order reversal: 1st 0x41af89e8 tcphash (tcphash, sleep mutex) @ /usr/src/sys/netinet/tcp_usrreq.c:1513 2nd 0x00f91648 in6_ifaddr_lock (in6_ifaddr_lock, rm) @ /usr/src/sys/netinet6/in6_src.c:305 lock order tcphash -> in6_ifaddr_lock attempted at: #0 0x004d64bc at witness_checkorder+0xa98 #1 0x0045fce4 at _rm_rlock_debug+0x130 #2 0x0063f5e8 at in6_selectsrc+0x33c #3 0x0063f260 at in6_selectsrc_socket+0x44 #4 0x0063d314 at in6_pcbconnect+0x228 #5 0x00621f40 at tcp6_connect+0x9c #6 0x0061fa80 at tcp6_usr_connect+0x230 #7 0x0051003c at soconnectat+0xc8 #8 0x00516cfc at kern_connectat+0xc8 #9 0x00516c14 at sys_connect+0xb0 #10 0x007fa3cc at do_el0_sync+0x520 #11 0x007d6910 at handle_el0_sync+0x44 — Juraj Lutter o...@freebsd.org
Re: nvme related(?) panic on recent -CURRENT
> On 4 Jul 2023, at 17:01, Chuck Tuffli wrote: > > On Thu, Jun 29, 2023 at 12:47 PM Juraj Lutter wrote: >> >> With recent -current, following occured: >> >> db> bt >> Tracing pid 0 tid 100063 td 0xfe00c5c35e40 >> kdb_enter() at kdb_enter+0x32/frame 0xfe00c5e31c90 >> vpanic() at vpanic+0x181/frame 0xfe00c5e31ce0 >> panic() at panic+0x43/frame 0xfe00c5e31d40 >> nvme_ctrlr_identify() at nvme_ctrlr_identify+0x10e/frame 0xfe00c5e31d90 >> nvme_ctrlr_start() at nvme_ctrlr_start+0x91/frame 0xfe00c5e31e10 >> nvme_ctrlr_reset_task() at nvme_ctrlr_reset_task+0xec/frame >> 0xfe00c5e31e40 >> taskqueue_run_locked() at taskqueue_run_locked+0x182/frame 0xfe00c5e31ec0 >> taskqueue_thread_loop() at taskqueue_thread_loop+0xc2/frame >> 0xfe00c5e31ef0 >> fork_exit() at fork_exit+0x7d/frame 0xfe00c5e31f30 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfe00c5e31f30 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 — >> >> machine is a bhyve guest. > > If I'm lldb'ing correctly, nvme_ctrlr_identify+0x10e is the panic in > nvme_completion_poll() if the NVMe command does not complete within > the timeout period (10 seconds). In this case, it is the Identify, > Controller command. In the bhyve emulation, this command effectively > memcpy's the data structure to the memory provided by the guest and > completes the command. If this panic is reproducible, I can provide a > patch to enhance the debug output to figure out if this is an > emulation or driver issue. It hasn’t happened since. What I can do is to put heavy load on that box (poudriere in a jail as well as poudriere in that VM). That could help to reproduce the panic. As mentioned somewhere else in this thread, I’ve a `cu’ session running. otis — Juraj Lutter o...@freebsd.org
Re: nvme related(?) panic on recent -CURRENT
>> >> machine is a bhyve guest. > > Did bhyve log any warnings or errors? I'm curious if its NVMe > emulation did something dumb or itself noticed an issue. > No, nothing in bhyve logs, nothing in host’s syslog. For now, I’ve left `cu’ session to VM’s console running under tmux to see if the error re-occurs. — Juraj Lutter o...@freebsd.org
Re: nvme related(?) panic on recent -CURRENT
> On 29 Jun 2023, at 22:01, Warner Losh wrote: > > What's the panic string? I don’t have any, even savecore did not worked. I’ve left a “cu” session to the VM’s console running under tmux and should it reappear, I can grab it. otis — Juraj Lutter o...@freebsd.org
nvme related(?) panic on recent -CURRENT
With recent -current, following occured: db> bt Tracing pid 0 tid 100063 td 0xfe00c5c35e40 kdb_enter() at kdb_enter+0x32/frame 0xfe00c5e31c90 vpanic() at vpanic+0x181/frame 0xfe00c5e31ce0 panic() at panic+0x43/frame 0xfe00c5e31d40 nvme_ctrlr_identify() at nvme_ctrlr_identify+0x10e/frame 0xfe00c5e31d90 nvme_ctrlr_start() at nvme_ctrlr_start+0x91/frame 0xfe00c5e31e10 nvme_ctrlr_reset_task() at nvme_ctrlr_reset_task+0xec/frame 0xfe00c5e31e40 taskqueue_run_locked() at taskqueue_run_locked+0x182/frame 0xfe00c5e31ec0 taskqueue_thread_loop() at taskqueue_thread_loop+0xc2/frame 0xfe00c5e31ef0 fork_exit() at fork_exit+0x7d/frame 0xfe00c5e31f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00c5e31f30 --- trap 0, rip = 0, rsp = 0, rbp = 0 — machine is a bhyve guest. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576
Re: ifconfig dumps core and gdb uses an undefined symbol
> On 14 Jun 2023, at 11:12, Juraj Lutter wrote: > > > >> On 14 Jun 2023, at 11:01, Gary Jennejohn wrote: >> I compiled gbd under /usr/ports and it now works, although it's emitting >> some weird errors. >> >> -O0 -g3 removes too much and gdb shows no useful information. > > Build it with: > > WITH_DEBUG=1 DEBUG_FLAGS=“-O3 -g3” > Silly me. Actually with: WITH_DEBUG=1 DEBUG_FLAGS=“-O0 -g3” otis — Juraj Lutter o...@freebsd.org
Re: ifconfig dumps core and gdb uses an undefined symbol
> On 14 Jun 2023, at 11:01, Gary Jennejohn wrote: > I compiled gbd under /usr/ports and it now works, although it's emitting > some weird errors. > > -O0 -g3 removes too much and gdb shows no useful information. Build it with: WITH_DEBUG=1 DEBUG_FLAGS=“-O3 -g3” otis — Juraj Lutter o...@freebsd.org
CPU hog on -current (pfSense 23.05)
Hi,
since cca 7 days I’ve started to observe a CPU hog of one CPU core on APU2 box
running pfSense 23.05 (if that matters).
mjg@ suggested to run a dtrace oneliner that showed:
~~
kernel`pmap_copy 33
kernel`amd64_syscall 33
kernel`vm_radix_insert 35
kernel`vm_map_pmap_enter 37
kernel`vm_radix_lookup_unlocked 38
kernel`memcpy_std 38
kernel`vm_object_deallocate 39
kernel`pmap_enter_quick_locked 41
kernel`em_update_stats_counters 43
kernel`copyout_nosmap_std 43
kernel`ck_epoch_poll_deferred 44
kernel`sbuf_put_bytes 46
kernel`vm_page_pqbatch_submit 48
kernel`pmap_remove_pte 51
kernel`pmap_pvh_remove 53
kernel`vm_pqbatch_process_page 54
kernel`cpu_search_highest 56
kernel`get_pv_entry 57
kernel`pmap_try_insert_pv_entry 59
kernel`vm_map_lookup_entry 65
kernel`epoch_call_task 92
kernel`pmap_enter 101
kernel`vm_fault 110
kernel`pagecopy 110
kernel`0x81 133
kernel`lock_delay 145
kernel`pmap_remove_pages 203
kernel`_thread_lock 415
kernel`pagezero_std 490
kernel`assert_rw 532
kernel`acpi_cpu_c1 600
kernel`callout_lock 641
kernel`kern_yield1206
kernel`_callout_stop_safe2010
kernel`spinlock_enter2032
kernel`tcp_timer_stop2703
0x05927
kernel`spinlock_exit 40964
kernel`cpu_idle 61943
kernel`sched_idletd 76722
~~~
The symptom is that the kernel thread "kernel{if_io_tqg_1}” consumes 100% of
the CPU core.
Can this be debugged any further?
I also suspect the hardware problem (I have one spare box where I’ll put my XML
config
and test whether the problem will persist).
I’d be very thankful for any pointers.
Thanks!
otis
—
Juraj Lutter
o...@freebsd.org
Re: another crash and going forward with zfs
> On 18 Apr 2023, at 09:46, Martin Matuska wrote: > > Btw. I am open for setting up a pre-merge stress testing > > I will check out if I can use the hourly-billed amd64 and arm64 cloud boxes > at Hetzner with FreeBSD. > Otherwise there are monthly-billed as well. I can provide a bhyve VM on some of my hosts. We can discuss it off-list. jl — Juraj Lutter o...@freebsd.org
Re: byteswap.h not found on 12 and 13
> On 24 Mar 2023, at 10:09, Warner Losh wrote: > > one last reply, if this is for a port, then byteswap.h can usually be > implemented as > > #include > #define __bswap_16(x) __bswap16(x) > #define __bswap_32(x) __bswap32(x) > #define __bswap_64(x) __bswap64(x) > > #define bswap_16(x) __bswap16(x) > #define bswap_32(x) __bswap32(x) > #define bswap_64(x) __bswap64(x) > > in older versions of FreeBSD, but some tricky software will hate the bswap16 > (no underscore) etc defines. You could likely put that into the port. In releng/13 there is also infiniband/byteswap.h that does: #include #include #define bswap_16bswap16 #define bswap_32bswap32 #define bswap_64bswap64 otis — Juraj Lutter o...@freebsd.org
Re: local-unbound regression
Hi, > On 17 Jan 2023, at 18:11, User Ngor wrote: > > I discovered that recent unbound update broke my VPN scripts, after some > investigation I think I found the problem - default location of the config > file was reset to upstream value. My config file is at > /var/unbound/unbound.conf (as created by local-unbound-setup) but when I use > local-unbound-control I see this error message: >> >> >> # local-unbound-control flush_stats >> [1673972554] unbound-control[16206:0] error: Could not open >> /usr/local/etc/unbound/unbound.conf: No such file or directory >> [1673972554] unbound-control[16206:0] fatal error: could not read config >> file >> >> I have not yet created bugzilla bug >> > > https://cgit.freebsd.org/src/commit/?id=1838dec31895fd4752fa8631322ab93be0705a66 > > /* Pathname to the Unbound configuration file */ > -#define CONFIGFILE "/var/unbound/unbound.conf" > +#define CONFIGFILE "/usr/local/etc/unbound/unbound.conf" > > > It looks like it was intentional, but then my local-unbound-setup keeps > creating configuration in the old destination... And it looks like a POLA > violation - I can imagine lot's of users might have configs in /var/unbound I’ve opened a https://reviews.freebsd.org/D38106 <https://reviews.freebsd.org/D38106> to see whether this can be fixed. — Juraj Lutter o...@freebsd.org
Re: native recording of all network connections on freebsd
> On 28 Dec 2022, at 15:28, Sami Halabi wrote: > > using firewall ike ipfw with rule to log any to any would be a start.. for > advanced use, stateful fw so You can log start of connections I would also consider using ng_netflow(4) with, for example, nfsend or even logstash with netflow input module (and stored into elastic indexes), visualized by kibana or other tools. — Juraj Lutter o...@freebsd.org
Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES
> On 24 Nov 2022, at 15:16, Juraj Lutter wrote: >> >> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR. You could try adding >> that to your list. >> > > PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR into > src-env.conf instead of /etc/src.conf, for that purpose. Fingers are quicker than the brain: I’d put PORTSDIR into /etc/src.conf instead of /etc/make.conf for that purpose. otis — Juraj Lutter o...@freebsd.org
Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES
> On 24 Nov 2022, at 15:05, Gary Jennejohn wrote: > > On Thu, 24 Nov 2022 12:02:35 + > Nuno Teixeira wrote: > >> Hello, >> >> I'm trying PORT_MODULES with make.conf: >> --- >> PORTSDIR=/work/freebsd/ports >> DISTDIR=/work/DISTFILES >> PORTS_MODULES=graphics/drm-kmod x11/nvidia-driver >> > > bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR. You could try adding > that to your list. > PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR into src-env.conf instead of /etc/src.conf, for that purpose. — Juraj Lutter o...@freebsd.org
Re: Turning security email back on
> On 15 Nov 2022, at 17:22, Chris wrote: > > On 2022-11-15 08:05, bob prohaska wrote: >> It looks as if daily email reporting login failures and system status >> are no longer being sent out on -current. Is there a switch for >> /etc/rc.conf that will turn them back on? > Isn't this facilitated in periodic(8) Moreover, there was a switch from sendmail to dma very recently. Isn’t this the case? Difficult to judge without knowing more details (like, snippets from logs, etc…) — Juraj Lutter o...@freebsd.org
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
> On 27 Aug 2022, at 15:27, Michael Gmelin wrote: > > > >> On 27. Aug 2022, at 15:18, free...@oldach.net wrote: >> >> Michael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST): >>> (you're removing /var/run, which shouldn't be removed >> >> Not quite. It's actually not uncommon to boot with an empty /var. Please see >> /etc/rc.d/var and related. > > That’s a good point. > >> The request that ports/packages should consider this case is not exactly >> unreasonable IMO. >> > > If I was the maintainer, I would simply add the code to create the directory > for robustness sake (I for one deleted subdirs in /var/run more than once and > would expect a port to fix this on restart, also to make sure correct > permissions are applied). But since it doesn’t seem like this is going to > happen, adding a custom rc file would be a viable short term workaround for > the requester. > > I like the idea of having something like tmpfiles.d, it would also help port > maintainers (could also be done as a port). > As I have stated in one of those PR: clamd creates file in two locations: - PidFile - LocalSocket Both the locations could be checked by rc.d script in clamd.conf (also freshclam eventually) and respective directories can be created from within start_precmd() otis — Juraj Lutter o...@freebsd.org
Re: 14.0-CURRENT panic in early boot
> On 18 Nov 2021, at 18:46, Karel Gardas wrote: > > > Completely speculating, but since you don't see ioapic's are you sure this is > just ~2 weeks old build? If not, then it may be relevant to: Bisecting would be a better approach. otis > > commit 1b7a2680fba589daf6f700565214919cb941ab56 > Author: Jung-uk Kim > Date: Thu Sep 30 16:23:21 2021 -0400 > >Import ACPICA 20210930 > >(cherry picked from commit c509b6ab0d7e5bafc5348b08653b8738bd40716e) > — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576
Re: latest current fails to boot.
> On 23 Sep 2021, at 19:52, Konstantin Belousov wrote: > > If you do not load nvidia-modeset.ko at all, does the boot proceed? > > When the boot hangs, can you enter into ddb? That also brings up a question: Does nvidia kmods (and probably also drm kmod) match the kernel? — Juraj Lutter o...@freebsd.org
Re: [HEADSUP] making /bin/sh the default shell for root
> On 22 Sep 2021, at 10:36, Baptiste Daroussin wrote: > Hello, > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > This makes it a usable shell by default, which is why I would like to propose > to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > Thanks for this! What I miss a bit is a completion triggered by delete-char-or-list-or-eof (^D) as it was in (t)csh. otis — Juraj Lutter o...@freebsd.org
Re: Building multiple kernels with "make release"
> On 28 Jul 2021, at 20:37, Glen Barber wrote:
>
> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
>>> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
>>> your release.conf?
>>>
>>> I now seem to recall some weirdness with this, but the exact details
>>> elude me at the moment.
>>>
>>
>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
>> overrides whatever KERNCONF was set to. But it still only installs one
>> kernel. Trying to set that variable to a list doesn't work.
>
> Ok. Give me a day or so to try to figure out what is (or isn't)
> happening here. I do not recall any recent-ish changes that would have
> caused this, and I am 95% certain it has worked in the past.
According to Makefile.inc1:
make installkernel KERNCONF=“KERN1 KERN2”
should install KERN1 and KERN2. Similar goes for buildkernel.
Or is there something I am missing?
—
Juraj Lutter
o...@freebsd.org
signature.asc
Description: Message signed with OpenPGP
Re: 14-CURRENT/aarch64 build problem
> On 8 Jun 2021, at 21:38, bob prohaska wrote: > > FWIW, same problem seen here. In an added twist, git pull (hoping for > a fix) fails also: > > root@www:/usr/src # git pull > error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': > 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create > 'refs/remotes/freebsd/vendor/openzfs/legacy' > From https://git.freebsd.org/src > ! [new branch] vendor/openzfs/legacy -> > freebsd/vendor/openzfs/legacy (unable to update local ref) > error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': > 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create > 'refs/remotes/freebsd/vendor/openzfs/master' > ! [new branch] vendor/openzfs/master -> > freebsd/vendor/openzfs/master (unable to update local ref) > error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release': > 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create > 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release' > ! [new branch] vendor/openzfs/zfs-2.1-release -> > freebsd/vendor/openzfs/zfs-2.1-release (unable to update local ref) > > Is this a problem at my end, or the server's end? This already has been documented, as the old openzfs branch has been renamed/moved. $ git remote prune freebsd $ git pull See: https://lists.freebsd.org/archives/freebsd-git/2021-June/15.html otis — Juraj Lutter o...@freebsd.org
14-CURRENT/aarch64 build problem
Hi, I’m having problem to build recent 14-CURRENT/aarch64 as of 6d2648bcaba9b14e2f5c76680f3e7608e1f125f4: --- cddl/lib/libuutil__L --- make[4]: make[4]: don't know how to make uu_dprintf.c. Stop make[4]: make[4]: don't know how to make uu_open.c. Stop `uu_alloc.c' is up to date. `uu_avl.c' is up to date. `uu_dprintf.c' was not built (being made, type OP_DEPS_FOUND|OP_MARK, flags REMAKE|DONE_WAIT|DONE_ALLSRC|DONECYCLE)! … The build is performed with pristine /usr/obj Any hints, please? Thanks otis — Juraj Lutter o...@freebsd.org
Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved
> On 7 Jun 2021, at 02:15, Thomas Mueller wrote: > > I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld took > 11:15 (hours:minutes), buildkernel was also successful, I even appeared to be > successful with "dhclient re0". > > UPDATING file says to boot single-user after buildkernel and installkernel, > but then mount -u / or mount -uw / does not work as it did in previous times. > > Results were > > mount -uw / or mount -u / produces > fstab: /etc/fstab:2: Inappropriate file type or format > fstab: /etc/fstab:2: Inappropriate file type or format Bacause swap entry is in inapropriate format. The line should read: /dev/gpt/Sea1-18 noneswapsw 0 0 otis — Juraj Lutter o...@freebsd.org
Re: NFS issues since upgrading to 13-RELEASE
> On 25 Apr 2021, at 15:06, Rick Macklem wrote: > > 2 - TSO does work correctly, but results in different timing of the TCP > segments transmitted for the segment compared with non-TSO. > > I believe that, for otis@, disabling TSO reduced the frequency of Linux > client hangs, but did not stop them. > --> reverting the patch in r367492 (this patch is not in FreeBSD12) has > fixed the problem for him. > Correct. Reverting the patch in r367492 has made the system stable and usable (thanks, Rick!). We also have disabled LRO and TSO on the interfaces serving the NFS traffic, it also might have added up to the stability. There is some more work going on in Phabricator (D29690) that we also want to test. otis — Juraj Lutter o...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
> On 19 Apr 2021, at 17:03, Rick Macklem wrote: > > Olav Gjerde wrote: >> I have tried D29690 patch and reverting back to r367492 this weekend. >> Neither made any difference for my system. For me, reverting the patch in r367492, solved all the problems. In addition, I also turned off LRO and TSO on NICs comprising the lagg interface over which NFS service is provided. otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
> On 15 Apr 2021, at 23:09, Juraj Lutter wrote: > > The machine it’s running on is definitely a slow or weak one (it’s dell > r740xd with 2x CPU, 256GB RAM, 22xNVMe data zpool). Is definitely *NOT* a slow or weak one :-) otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
> On 15 Apr 2021, at 22:47, Rick Macklem wrote: > > Allan Jude wrote: >> On 4/15/2021 9:22 AM, Chris Roose wrote: >>> I posted this in -questions and someone suggested I post here as well. >>> >>> I'm having NFS availability issues between my Proxmox client and FreeBSD >>> server (10G link) since upgrading to 13->RELEASE. And unfortunately I >>> upgraded my ZFS pool to v2.0.0 before I noticed the issue, so I'm kind of >>> stuck. >>> >>> Periodically, the NFS server (I've tried both v3 and v4.2 clients) will go >>> unresponsive for several minutes. I never had >this problem on 12.2, and as >>> far as I can tell it's not a disk or network I/O issue. I'll get several >>> "nfs: server not >responding, still trying" messages on the client and a >>> few minutes later it usually recovers. It's not clear to me yet >what's >>> causing the block. Restarting nfsd on the server will resolve the issue if >>> it doesn't clear itself. >> > otis@ has run into a problem that sounds similar. > He sees a growing Recv-Q size on the server for the TCP connection from the > client > when "netstat -a" is done on the server when the "hang" occurs. > In his case, he is using a Linux client and it does not recover, however > other client > mounts continue to function. Correct. > I suspect the recovery after a few minutes is the client establishing a new > TCP > connection. > > He has been running for almost a week with r367492 reverted and has not > reported > seeing the problem again (he had reported that it has taken up to a week to > recur, so > reverting r367492 *might* have fixed the problem and I'd guess we'll know in > another > week?). We are now running 4 days without interruption. Before r367492 was reverted, it was unpredictable when it will lock up. The best result we achieved was 7 days. The machine it’s running on is definitely a slow or weak one (it’s dell r740xd with 2x CPU, 256GB RAM, 22xNVMe data zpool). otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.0-RC3 bison causes tputs SIGSEGV
> On 31 Mar 2021, at 15:53, Henric Jungheim wrote: > >> >> Knowing that would help me see whether the problem is faulty initialization >> from libtextstyle (i.e., the SCREEN pointer is null, making the path via >> the static structure), or some ifdef-combination in ncurses that I've >> neglected (i.e., a flaw in the pointer juggling). I’ve observed that the application in question calls: /* Create the output styled stream. */ pk_ostream = (color_mode == color_html ? html_styled_ostream_create (file_ostream_create (stdout), style_file_name) : styled_ostream_create (STDOUT_FILENO, "(stdout)", TTYCTL_AUTO, style_file_name)); Does it make any difference? thanks otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.0-RC3 bison causes tputs SIGSEGV
> On 31 Mar 2021, at 15:53, Henric Jungheim wrote: > >> >> So... the question I have is what is $TERM in this case, >> and where is the related terminal description (in terminfo or termcap). > > In the example in my original email, $TERM was "xterm-256color" > (connected through "Windows Terminal" running MS' ssh on Win10). In my case, also xterm-256color, connected using iTerm2 on macOS. otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.0-RC3 bison causes tputs SIGSEGV
Hi, very similar behavior is observed in editors/poke, on recent 13.0-STABLE (stable/13-85ad493677a2): (lldb) bt * thread #1, name = 'poke', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x frame #1: 0x0008009ed30a libncursesw.so.9`delay_output_sp(sp=0x, ms=) at lib_tputs.c:104:6 frame #2: 0x0008009edb81 libncursesw.so.9`tputs_sp [inlined] delay_output(ms=) at lib_tputs.c:116:12 frame #3: 0x0008009edb72 libncursesw.so.9`tputs_sp(sp=, string="", affcnt=1, outc=) at lib_tputs.c:422 frame #4: 0x0008009edcfb libncursesw.so.9`tputs(string="4f0fdc740005bebaf92e5a2e", affcnt=1, outc=(libtextstyle.so.0`out_char at term-ostream.oo.c:1198)) at lib_tputs.c:444:12 frame #5: 0x000800424bb0 libtextstyle.so.0`out_hyperlink_change(stream=0x000800e3d000, new_hyperlink=0x0008018bd600, async_safe=false) at term-ostream.oo.c:1586:7 frame #6: 0x00080042579c libtextstyle.so.0`out_attr_change(stream=0x000800e3d000, new_attr=attributes_t @ 0x7fffe608) at term-ostream.oo.c:1737:11 frame #7: 0x000800424f3b libtextstyle.so.0`output_buffer(stream=0x000800e3d000, goal_attr=attributes_t @ 0x7fffe690) at term-ostream.oo.c:1906:11 frame #8: 0x0008004223b2 libtextstyle.so.0`term_ostream__write_mem(stream=0x000800e3d000, data=0x00207a94, len=123) at term-ostream.oo.c:2037:11 frame #9: 0x000800422ed5 libtextstyle.so.0`term_ostream_write_mem(first_arg=0x000800e3d000, data=0x00207a94, len=123) at term-ostream.c:2721:3 frame #10: 0x000800427e3f libtextstyle.so.0`term_styled_ostream__write_mem(stream=0x000800e3a000, data=0x00207a94, len=123) at term-styled-ostream.oo.c:95:3 frame #11: 0x000800420535 libtextstyle.so.0`ostream_write_mem(first_arg=0x000800e3a000, data=0x00207a94, len=123) at ostream.c:138:3 frame #12: 0x0008004204ec libtextstyle.so.0`ostream_write_str(stream=0x000800e3a000, string=".\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.\n") at ostream.oo.c:35:3 frame #13: 0x00210add poke`pk_puts(str=".\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.\n") at pk-term.c:257:3 Iny my case, there is a NULL pointer dereference in delay_output_ch(), where my_outch is NULL: frame #0: 0x0008009ed2da libncursesw.so.9`delay_output_sp(sp=0x, ms=4) at lib_tputs.c:103:22 100 register int nullcount; 101 102 nullcount = (ms * _nc_baudrate(ospeed)) / (BAUDBYTE * 1000); -> 103 for (_nc_nulls_sent += nullcount; nullcount > 0; nullcount--) 104 my_outch(NCURSES_SP_ARGx PC); 105 if (my_outch == NCURSES_SP_NAME(_nc_outch)) 106 NCURSES_SP_NAME(_nc_flush) (NCURSES_SP_ARG); Application is using term_styled_ostream_create() that does not initialize default_attr. > On 30 Mar 2021, at 01:31, Thomas Dickey wrote: > > On Mon, Mar 29, 2021 at 12:12:55PM -0700, Henric Jungheim wrote: >> >> I ran into a bit of an odd problem when building the >> sysutils/grub2-bhyve port on 13.0-RC3 (on x64). The bison command >> dumps core when the output is going to a console. Redirecting the >> build output to a file avoids the problem. I'm not sure if this is >> an ncurses issue, a port issue (and which port?), my box, or >> something else (clang?). > > It might be a problem with the application's initialization of ncurses. signature.asc Description: Message signed with OpenPGP
Re: -CURRENT panics in NFS
> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote: > > Can you dump 'struct componentname *cnp'? This should do the trick: > f 12 > p cnp > > Most notably I want to know if the name to added is a literal dot. > Yes, it is a dot (the directory itself): cn_nameptr = 0xfe0011428018 ".", cn_namelen = 1 otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
I am now running a patched kernel, without problems. I can boot to unpatched one and see the output of these ddb commands. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 21:49, Mateusz Guzik wrote: > > Can you dump 'struct componentname *cnp'? This should do the trick: > f 12 > p cnp > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
LORs in -CURRENT
I’ve got some LORs: lock order reversal: 1st 0xf8008c4f4af0 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1071 2nd 0xf8008c51a930 zfs (zfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1083 lock order zfs -> nfs established at: #0 0x80c7bb7d at witness_checkorder+0x46d #1 0x80bdcf18 at lockmgr_lock_flags+0x188 #2 0x80af1b9c at nfs_lock+0x2c #3 0x80ce485f at vop_sigdefer+0x2f #4 0x80d0e5e4 at _vn_lock+0x54 #5 0x80ced6a5 at vfs_domount+0xef5 #6 0x80cebb02 at vfs_donmount+0x872 #7 0x80ceb259 at sys_nmount+0x69 #8 0x810bd00e at amd64_syscall+0x12e #9 0x8108fdfe at fast_syscall_common+0xf8 lock order nfs -> zfs attempted at: #0 0x80c7c4dc at witness_checkorder+0xdcc #1 0x80bde955 at lockmgr_xlock+0x55 #2 0x80d0e5e4 at _vn_lock+0x54 #3 0x80ced6a5 at vfs_domount+0xef5 #4 0x80cebb02 at vfs_donmount+0x872 #5 0x80ceb259 at sys_nmount+0x69 #6 0x810bd00e at amd64_syscall+0x12e #7 0x8108fdfe at fast_syscall_common+0xf8 lock order reversal: 1st 0xf8008c6473f0 zfs (zfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1071 2nd 0xf80035f4dcb0 devfs (devfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1083 lock order devfs -> zfs established at: #0 0x80c7bb7d at witness_checkorder+0x46d #1 0x80bde955 at lockmgr_xlock+0x55 #2 0x80d0e5e4 at _vn_lock+0x54 #3 0x80ced6a5 at vfs_domount+0xef5 #4 0x80cebb02 at vfs_donmount+0x872 #5 0x80cf01f7 at kernel_mount+0x57 #6 0x80cf2bc1 at parse_mount+0x4a1 #7 0x80cf1027 at vfs_mountroot+0x587 #8 0x80b9a4ff at start_init+0x1f #9 0x80bc7470 at fork_exit+0x80 #10 0x8109055e at fork_trampoline+0xe lock order zfs -> devfs attempted at: #0 0x80c7c4dc at witness_checkorder+0xdcc #1 0x80bde955 at lockmgr_xlock+0x55 #2 0x80d0e5e4 at _vn_lock+0x54 #3 0x80ced6a5 at vfs_domount+0xef5 #4 0x80cebb02 at vfs_donmount+0x872 #5 0x80ceb259 at sys_nmount+0x69 #6 0x810bd00e at amd64_syscall+0x12e #7 0x8108fdfe at fast_syscall_common+0xf8 lock order reversal: 1st 0xf8008c6f7230 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_syscalls.c:4135 2nd 0xfe000ee1dc50 bufwait (bufwait, lockmgr) @ /usr/src/sys/kern/vfs_bio.c:1674 3rd 0xf8008c6f73f0 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:2915 lock order nfs -> bufwait established at: #0 0x80c7bb7d at witness_checkorder+0x46d #1 0x80bdd5ec at lockmgr_xlock_hard+0x6c #2 0x80bde303 at __lockmgr_args+0x613 #3 0x80ccf504 at getnewbuf+0x334 #4 0x80ccc839 at getblkx+0x359 #5 0x80ccf1b2 at getblk+0x22 #6 0x80afd3b6 at nfs_getcacheblk+0x46 #7 0x80afcd4b at ncl_bioread+0x58b #8 0x80af1aff at nfs_readdir+0x18f #9 0x80ce485f at vop_sigdefer+0x2f #10 0x81181f38 at VOP_READDIR_APV+0x38 #11 0x80d0b18b at kern_getdirentries+0x1fb #12 0x80d0b399 at sys_getdirentries+0x29 #13 0x810bd00e at amd64_syscall+0x12e #14 0x8108fdfe at fast_syscall_common+0xf8 lock order bufwait -> nfs attempted at: #0 0x80c7c4dc at witness_checkorder+0xdcc #1 0x80bdcf18 at lockmgr_lock_flags+0x188 #2 0x80af1b9c at nfs_lock+0x2c #3 0x80ce485f at vop_sigdefer+0x2f #4 0x80d0e5e4 at _vn_lock+0x54 #5 0x80cf6e0f at vget_finish+0x4f #6 0x80ce6b3c at vfs_hash_get+0xbc #7 0x80af9d09 at nfscl_nget+0x119 #8 0x80ae291a at nfsrpc_readdirplus+0xaaa #9 0x80aed43c at ncl_readdirplusrpc+0xdc #10 0x80afdbe3 at ncl_doio+0x423 #11 0x80afcd8c at ncl_bioread+0x5cc #12 0x80af1aff at nfs_readdir+0x18f #13 0x80ce485f at vop_sigdefer+0x2f #14 0x81181f38 at VOP_READDIR_APV+0x38 #15 0x80d0b18b at kern_getdirentries+0x1fb #16 0x80d0b399 at sys_getdirentries+0x29 #17 0x810bd00e at amd64_syscall+0x12e kernel is GENERIC, stock config. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
Hi, thank you for the swift reaction. This patch fixed my problem. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 16:53, Rick Macklem wrote: > > I reproduced the problem and the attached trivial patch > seems to fix it. Please test the patch if you can. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
And a kgdb backtrace: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0x804c7b2a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0x804c78ee in db_command (last_cmdp=, cmd_table=, dopager=dopager@entry=1) at /usr/src/sys/ddb/db_command.c:482 #4 0x804c762d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0x804cac36 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270 #6 0x80c59d04 in kdb_trap (type=type@entry=3, code=code@entry=0, tf=, tf@entry=0xfe00d01c3d40) at /usr/src/sys/kern/subr_kdb.c:727 #7 0x810bc1ee in trap (frame=0xfe00d01c3d40) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=0x812accc9 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:506 #10 0x80c0d5d2 in vpanic (fmt=, ap=, ap@entry=0xfe00d01c3ea0) at /usr/src/sys/kern/kern_shutdown.c:907 #11 0x80c0d363 in panic (fmt=0x81e9a178 "\177\256&\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:843 #12 0x80cd6d74 in cache_enter_time (dvp=0xf80079321e00, vp=0xf80079321e00, cnp=cnp@entry=0xfe00d01c4030, tsp=tsp@entry=0xfe00d01c40e0, dtsp=) at /usr/src/sys/kern/vfs_cache.c:2274 #13 0x80ae2bd6 in nfsrpc_readdirplus (vp=, vp@entry=0xf80079321e00, uiop=, uiop@entry=0xfe00d01c4540, cookiep=cookiep@entry=0xfe00d01c44e0, cred=cred@entry=0xf80079307e00, p=, p@entry=0xfe00de06be00, nap=nap@entry=0xfe00d01c4400, attrflagp=0xfe00d01c44f0, eofp=0xfe00d01c44f4, stuff=0x0) at /usr/src/sys/fs/nfsclient/nfs_clrpcops.c:3766 #14 0x80aed4ec in ncl_readdirplusrpc (vp=vp@entry=0xf80079321e00, uiop=uiop@entry=0xfe00d01c4540, cred=0xf80079307e00, td=td@entry=0xfe00de06be00) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2490 #15 0x80afdc93 in ncl_doio (vp=vp@entry=0xf80079321e00, bp=bp@entry=0xfe000ee1c610, cr=0xfe00d01c3d00, cr@entry=0xf80079307e00, td=td@entry=0xfe00de06be00, called_from_strategy=called_from_strategy@entry=0) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1686 #16 0x80afce3c in ncl_bioread (vp=, vp@entry=0xf80079321e00, uio=, ioflag=ioflag@entry=0, cred=) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:604 #17 0x80af1baf in nfs_readdir (ap=ap@entry=0xfe00d01c4918) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2383 #18 0x80ce490f in vop_sigdefer (vop=, a=0xfe00d01c4918) at /usr/src/sys/kern/vfs_default.c:1471 #19 0x81181f38 in VOP_READDIR_APV (vop=0x81af00d8 , a=a@entry=0xfe00d01c4918) at vnode_if.c:1939 #20 0x80d0b23b in VOP_READDIR (vp=0xf80079321e00, uio=0xfe00d01c48d0, cred=, eofflag=0xfe00d01c48cc, ncookies=0x0, cookies=0x0) at ./vnode_if.h:985 #21 kern_getdirentries (td=, fd=, buf=0x801851000 , count=4096, basep=basep@entry=0xfe00d01c49b0, residp=residp@entry=0x0, bufseg=UIO_USERSPACE) at /usr/src/sys/kern/vfs_syscalls.c:4142 #22 0x80d0b449 in sys_getdirentries (td=0x81e9a178 , uap=0xfe00de06c1e8) at /usr/src/sys/kern/vfs_syscalls.c:4089 #23 0x810bd00e in syscallenter (td=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #24 amd64_syscall (td=0xfe00de06be00, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1156 #25 #26 0x0008012a83fa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffd928 — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 15:18, Juraj Lutter wrote: > > Reliably reproducible: > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT panics in NFS
Reliably reproducible: VNASSERT failed: dvp != vp not true at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) 0xf80079321e00: type VDIR usecount 4, writecount 0, refcount 3 seqc users 0 mountedhere 0 hold count flags () flags (VV_ROOT|VV_VMSIZEVNLOCK) v_object 0xf801eeaf1d68 ref 0 pages 2 cleanbuf 1 dirtybuf 0 lock type nfs: SHARED (count 1) fileid 34 fsid 0x3a3a00ff02 panic: condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) cpuid = 1 time = 1614435453 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00d01c3e10 vpanic() at vpanic+0x181/frame 0xfe00d01c3e60 panic() at panic+0x43/frame 0xfe00d01c3ec0 cache_enter_time() at cache_enter_time+0x1574/frame 0xfe00d01c3fa0 nfsrpc_readdirplus() at nfsrpc_readdirplus+0xcb6/frame 0xfe00d01c43d0 ncl_readdirplusrpc() at ncl_readdirplusrpc+0xdc/frame 0xfe00d01c4520 ncl_doio() at ncl_doio+0x423/frame 0xfe00d01c45b0 ncl_bioread() at ncl_bioread+0x5cc/frame 0xfe00d01c4740 nfs_readdir() at nfs_readdir+0x18f/frame 0xfe00d01c4850 vop_sigdefer() at vop_sigdefer+0x2f/frame 0xfe00d01c4880 VOP_READDIR_APV() at VOP_READDIR_APV+0x38/frame 0xfe00d01c48a0 kern_getdirentries() at kern_getdirentries+0x1fb/frame 0xfe00d01c4990 sys_getdirentries() at sys_getdirentries+0x29/frame 0xfe00d01c49c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00d01c4af0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00d01c4af0 --- syscall (554, FreeBSD ELF64, sys_getdirentries), rip = 0x8012a83fa, rsp = 0x7fffd928, rbp = 0x7fffd960 --- KDB: enter: panic [ thread pid 1879 tid 101207 ] Stopped at kdb_enter+0x37: movq$0,0x128bdde(%rip) db> — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 15:10, Juraj Lutter wrote: > > - poudriere data stored on NFS > - NFS server 12-STABLE > - NFS client (that panicked) 14-CURRENT > - Panic string: > > condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 > (cache_enter_time) > > backtrace: > > Tracing pid 27294 tid 100893 td 0xfe00ea1a3500 > kdb_enter() at kdb_enter+0x37/frame 0xfe00ea3dee10 > vpanic() at vpanic+0x1b2/frame 0xfe00ea3dee60 > panic() at panic+0x43/frame 0xfe00ea3deec0 > cache_enter_time() at cache_enter_time+0x1574/frame 0xfe00ea3defa0 > nfsrpc_readdirplus() at nfsrpc_readdirplus+0xcb6/frame 0xfe00ea3df3d0 > ncl_readdirplusrpc() at ncl_readdirplusrpc+0xdc/frame 0xfe00ea3df520 > ncl_doio() at ncl_doio+0x423/frame 0xfe00ea3df5b0 > ncl_bioread() at ncl_bioread+0x5cc/frame 0xfe00ea3df740 > nfs_readdir() at nfs_readdir+0x18f/frame 0xfe00ea3df850 > vop_sigdefer() at vop_sigdefer+0x2f/frame 0xfe00ea3df880 > VOP_READDIR_APV() at VOP_READDIR_APV+0x38/frame 0xfe00ea3df8a0 > kern_getdirentries() at kern_getdirentries+0x1fb/frame 0xfe00ea3df990 > sys_getdirentries() at sys_getdirentries+0x29/frame 0xfe00ea3df9c0 > amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00ea3dfaf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00ea3dfaf0 > > > running processes: > > 27295 27179 27179 0 S+ piperd 0xf800090b4ba0 xargs > 27294 27179 27179 0 R+ CPU 1 find > 27179 816 27179 0 S+ wait0xf80181b69528 sh > > Dump header from device: /dev/vtbd0p3 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 1860571136 > Blocksize: 512 > Compression: none > Dumptime: 2021-02-27 14:59:59 +0100 > Hostname: b14.builder.wilbury.net > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 14.0-CURRENT #0 main-n245107-172f2fc11cc: Fri Feb 26 > 15:20:00 CET 2021 >r...@b14.builder.wilbury.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > Panic String: condition dvp != vp not met at > /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) > Dump Parity: 1481068399 > Bounds: 0 > Dump Status: good > > — > Juraj Lutter > XMPP: juraj (at) lutter.sk > GSM: +421907986576 > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
-CURRENT panics in NFS
- poudriere data stored on NFS - NFS server 12-STABLE - NFS client (that panicked) 14-CURRENT - Panic string: condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) backtrace: Tracing pid 27294 tid 100893 td 0xfe00ea1a3500 kdb_enter() at kdb_enter+0x37/frame 0xfe00ea3dee10 vpanic() at vpanic+0x1b2/frame 0xfe00ea3dee60 panic() at panic+0x43/frame 0xfe00ea3deec0 cache_enter_time() at cache_enter_time+0x1574/frame 0xfe00ea3defa0 nfsrpc_readdirplus() at nfsrpc_readdirplus+0xcb6/frame 0xfe00ea3df3d0 ncl_readdirplusrpc() at ncl_readdirplusrpc+0xdc/frame 0xfe00ea3df520 ncl_doio() at ncl_doio+0x423/frame 0xfe00ea3df5b0 ncl_bioread() at ncl_bioread+0x5cc/frame 0xfe00ea3df740 nfs_readdir() at nfs_readdir+0x18f/frame 0xfe00ea3df850 vop_sigdefer() at vop_sigdefer+0x2f/frame 0xfe00ea3df880 VOP_READDIR_APV() at VOP_READDIR_APV+0x38/frame 0xfe00ea3df8a0 kern_getdirentries() at kern_getdirentries+0x1fb/frame 0xfe00ea3df990 sys_getdirentries() at sys_getdirentries+0x29/frame 0xfe00ea3df9c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00ea3dfaf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00ea3dfaf0 running processes: 27295 27179 27179 0 S+ piperd 0xf800090b4ba0 xargs 27294 27179 27179 0 R+ CPU 1 find 27179 816 27179 0 S+ wait0xf80181b69528 sh Dump header from device: /dev/vtbd0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 1860571136 Blocksize: 512 Compression: none Dumptime: 2021-02-27 14:59:59 +0100 Hostname: b14.builder.wilbury.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 14.0-CURRENT #0 main-n245107-172f2fc11cc: Fri Feb 26 15:20:00 CET 2021 r...@b14.builder.wilbury.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC Panic String: condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) Dump Parity: 1481068399 Bounds: 0 Dump Status: good — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
> On 15 Jan 2021, at 18:26, Freddie Cash wrote: > > > /var/run/dmesg.boot includes all output from dmesg for the current boot. No > need to manually redirect dmesg output to a file or play with buffer sizes. > :) Just upload that file. On boot, dmesg is saved to dmesg.boot quite lately and start of the circular buffer can already be rewritten. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
> On 15 Jan 2021, at 12:10, Yasuhiro Kimura wrote: > > From: Jakob Alvermark > Subject: Waiting for bufdaemon > Date: Fri, 15 Jan 2021 11:26:47 +0100 > >> When rebooting my thinkpad the 'bufdaemon' times out: >> >> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop >> ... timed out >> >> >> This started happening recently (within the last week I think). >> >> >> Any ideas? > > I have been experiencing same problem with my 13-CURRENT amd64 > VirtualBox VM for about a month. The conditions that the problem > happens are unclear and all what I can say is > > * It happens only after I login in the VM and do something for a > while. If I boot the VM and shut it down immediately, it never > happens. > * When the problem happens, one or more unkillable processes seem to > be left. I have been fighting with situations like this for month or two, opened more PRs about it. My observation was that after putting some load on the machine, mysterious mrsas(4) timeouts started to happen, processes were unkillable, reboots could not complete in time... For sake of bisect, main-c255656-gb500c184b656 is known to work OK for me as of now. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git tools for building in base?
> On 18 Dec 2020, at 14:02, Miroslav Lachman <000.f...@quip.cz> wrote: > > On 25/11/2020 06:54, Thomas Mueller wrote: > >> NetBSD users face a similar problem with their upcoming switch from cvs to >> hg (Mercurial). > > Do anybody have a link to some documents stating why FreeBSD chose Git and > why NetBSD chose Mercurial? I am using both tools at $WORK, I am just curious > what leads to these decisions. Joerg Sonnenberger had a talk about it: https://archive.fosdem.org/2018/schedule/event/netbsd_and_mercurial/ At NetBSD it is not that straightforward: - git is used for pkgsrc-wip - src, xsrc and pkgsrc are in CVS and there are *plans* to move to hg, but there are no fixed deadlines when this will be done. otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
