Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
Mike Karels wrote on Date: Sat, 12 Aug 2023 22:17:39 UTC : On 12 Aug 2023, at 15:32, Juraj Lutter wrote: > > 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. > > 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. > buildworld buildkernel is always done on amd64 for all the official builds as I understand. No use of quemu is required for this. https://ci.freebsd.org/ allows looking at the build logs and such for the ci build activity, not for the release/snapshot builds. It is ports being turned into packages that has the issue of wanting to avoid qemu use and so that only armv6 builds ports->packages via amd64. https://pkg-status.freebsd.org/?all=1=package allows looking at the logs and such for this. === Mark Millard marklmi at yahoo.com
RE: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
Juraj Lutter wrote on Date: Sat, 12 Aug 2023 20:32:53 UTC : > 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? The likes of https://ci.freebsd.org/job/FreeBSD-main-aarch64-build/ are built on amd64 via cross building. Those builds have been and are still working. A log file from the recent one shows the actual cc command it used for /usr/src/lib/libssp_nonshared/libssp_nonshared.c : 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 But you have not provided anything to compare with for finding differences. Simillarly for: /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/int_util.c (but needing some output splicing to form the whole line as one) there is: 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 -fpic -fvisibility=hidden -DVISIBILITY_HIDDEN -O2 -pipe -fno-common -I/usr/src/contrib/llvm-project/libunwind/include -D_LIBUNWIND_IS_NATIVE_ONLY -D_LIBUNWIND_USE_FRAME_HEADER_CACHE -I/usr/src/lib/msun/src -g -gz=zlib -MD -MF.depend.int_util.o -MTint_util.o -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -fno-exceptions -funwind-tables -c /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/int_util.c -o int_util.o Did your build's commands have the expected "-march=armv7"? "-m32"? And so on. You might want to show the exact commands and failure notice together. === Mark Millard marklmi at yahoo.com
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
On 12 Aug 2023, at 15:32, Juraj Lutter wrote: > 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. 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. Mike > — > 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
14.0-APLHA1 snapshot use of kyua: An odd backtrace that appeared on the aarch64 console (and logs)
I ran the block of zfs tests on a snapshot 14.0-APLHA1 install used to boot and operate a Windows Dev Ket 2023. I just noticed a non-panic/non-crash backtrace had been output to the console (and related logs): . . . GEOM: md0: the primary GPT table is corrupt or invalid. GEOM: md0: using the secondary instead -- recovery strongly advised. GEOM: md1: the primary GPT table is corrupt or invalid. GEOM: md1: using the secondary instead -- recovery strongly advised. GEOM: md2: the primary GPT table is corrupt or invalid. GEOM: md2: using the secondary instead -- recovery strongly advised. GEOM: md3: the primary GPT table is corrupt or invalid. GEOM: md3: using the secondary instead -- recovery strongly advised. got error -2 on name 1 on op 3 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 zfs_lookup_internal() at zfs_lookup_internal+0xb8 zfs_rename() at zfs_rename+0x128 zfs_replay_rename() at zfs_replay_rename+0xa4 zil_replay_log_record() at zil_replay_log_record+0x1b0 zil_parse() at zil_parse+0x360 zil_replay() at zil_replay+0xdc zfsvfs_setup() at zfsvfs_setup+0x1fc $x.0() at $x.0+0x6b0 vfs_domount_first() at vfs_domount_first+0x24c vfs_domount() at vfs_domount+0x2cc vfs_donmount() at vfs_donmount+0x844 sys_nmount() at sys_nmount+0x60 do_el0_sync() at do_el0_sync+0x520 handle_el0_sync() at handle_el0_sync+0x44 --- exception, esr 0x5600 GEOM_NOP: Device md0.nop created. GEOM_NOP: Device md1.nop created. GEOM_NOP: Device md2.nop created. GEOM_NOP: Device md3.nop created. GEOM_NOP: Device md4.nop created. GEOM_NOP: Device md5.nop created. GEOM_NOP: Device md0.nop removed. GEOM_NOP: Device md1.nop removed. GEOM_NOP: Device md2.nop removed. GEOM_NOP: Device md3.nop removed. GEOM_NOP: Device md4.nop removed. GEOM_NOP: Device md5.nop removed. . . . For reference . . . I had set up md0 .. md5, each 1g swap backed, and, in /etc/kyua/kyua.conf , had used: test_suites.FreeBSD.disks = '/dev/md0 /dev/md1 /dev/md2 /dev/md3 /dev/md4 /dev/md5' (I the future I'll use file backed that are larger.) Note: After dropping a copy of the extra files from the rpi-arm64 snapshots's msdosfs into the rock64 installation's msdosfs, the rock64 snapshot install on the USB media then can boot and operate every aarch64 system I have access to. (It is something I've done for a long time.) The rock64 having an unusually large area for u-boot related dd'ing could serve well for dd'ing various alternatives and testing them: overlapping the other file systems is unlikely. Such can be handy for having a uniform testing environment. === Mark Millard marklmi at yahoo.com
Re: ZFS deadlock in 14
On August 12, 2023 7:11:10 AM PDT, "Dag-Erling Smørgrav"
wrote:
>Dag-Erling Smørgrav writes:
>> At some point between 42d088299c (4 May) and f0c9703301 (26 June), a
>> deadlock was introduced in ZFS.
>
>Trying to narrow this range down, I did not get a deadlock with
>4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June), albeit
>after building ~1800 packages. This is surprising since we have a
>report of this or a very similar deadlock occurring with a kernel from 8
>June (https://bugs.freebsd.org/271945). Perhaps I should try
>4e8d558c9d1c again.
>
>Here's the complete kgdb session showing, once again, a zfs rollback
>stuck waiting for the txg to sync:
>
>Reading symbols from /boot/GENERIC/kernel...
>Reading symbols from /usr/lib/debug//boot/GENERIC/kernel.debug...
>
>Unread portion of the kernel message buffer:
>panic: deadlres_td_sleep_q: possible deadlock detected for
> 0xfe03567a01e0 (sh), blocked for 180242 ticks
>
>cpuid = 17
>time = 1691802362
>KDB: stack backtrace:
>db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe021507ce00
>vpanic() at vpanic+0x150/frame 0xfe021507ce50
>panic() at panic+0x43/frame 0xfe021507ceb0
>deadlkres() at deadlkres+0x350/frame 0xfe021507cef0
>fork_exit() at fork_exit+0x80/frame 0xfe021507cf30
>fork_trampoline() at fork_trampoline+0xe/frame 0xfe021507cf30
>--- trap 0xdeadc0de, rip = 0xdeadc0dedeadc0de, rsp = 0xdeadc0dedeadc0de,
> rbp = 0xdeadc0dedeadc0de ---
>KDB: enter: panic
>
>__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59
>59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
> pcpu,
>(kgdb) tid 0xfe03567a01e0
>(kgdb) bt
>#0 sched_switch (td=td@entry=0xfe03567a01e0, flags=flags@entry=259)
> at /usr/src/sys/kern/sched_ule.c:2299
>#1 0x80b5fbd4 in mi_switch (flags=flags@entry=259) at
> /usr/src/sys/kern/kern_synch.c:550
>#2 0x80bb1257 in sleepq_switch (wchan=0xf80b139e4770,
> wchan@entry=0x8113878f, pri=pri@entry=64) at
> /usr/src/sys/kern/subr_sleepqueue.c:609
>#3 0x80bb112e in sleepq_wait (wchan=,
> pri=) at /usr/src/sys/kern/subr_sleepqueue.c:660
>#4 0x80b21d6f in sleeplk (lk=lk@entry=0xf80b139e4770,
> flags=flags@entry=2122752, ilk=ilk@entry=0x0,
> wmesg=wmesg@entry=0x8113878f "tmpfs", pri=,
> pri@entry=64, timo=timo@entry=6, queue=1) at /usr/src/sys/kern/kern_lock.c:310
>#5 0x80b1fd9f in lockmgr_slock_hard (lk=0xf80b139e4770,
> flags=2122752, ilk=, file=0x81296919
> "/usr/src/sys/kern/vfs_lookup.c", line=1012, lwa=0x0) at
> /usr/src/sys/kern/kern_lock.c:705
>#6 0x80c5e444 in VOP_LOCK1 (vp=0xf80b139e4700, flags=2106368,
> file=0x81296919 "/usr/src/sys/kern/vfs_lookup.c", line=1012) at
> ./vnode_if.h:1120
>#7 _vn_lock (vp=0xf80b139e4700, flags=2106368, file=,
> line=) at /usr/src/sys/kern/vfs_vnops.c:1808
>#8 0x80c36eae in vfs_lookup (ndp=ndp@entry=0xfe03c63a6bd8) at
> /usr/src/sys/kern/vfs_lookup.c:1010
>#9 0x80c36291 in namei (ndp=ndp@entry=0xfe03c63a6bd8) at
> /usr/src/sys/kern/vfs_lookup.c:689
>#10 0x80c5681f in kern_statat (td=0xfe03567a01e0,
> td@entry=, flag=, fd=-100, path=0x1032a8685a15
> ,
> pathseg=pathseg@entry=UIO_USERSPACE, sbp=sbp@entry=0xfe03c63a6d18)
>at /usr/src/sys/kern/vfs_syscalls.c:2441
>#11 0x80c56f17 in sys_fstatat (td=, td@entry= reading variable: value is not available>, uap=0xfe03567a05e0,
> uap@entry=) at
> /usr/src/sys/kern/vfs_syscalls.c:2419
>#12 0x8104d8e0 in syscallenter (td=) at
> /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:190
>#13 amd64_syscall (td=0xfe03567a01e0, traced=0) at
> /usr/src/sys/amd64/amd64/trap.c:1199
>#14
>#15 0x103acaf3b03a in ?? ()
>Backtrace stopped: Cannot access memory at address 0x103ac929af28
>(kgdb) f 5
>#5 0x80b1fd9f in lockmgr_slock_hard (lk=0xf80b139e4770,
> flags=2122752, ilk=, file=0x81296919
> "/usr/src/sys/kern/vfs_lookup.c", line=1012, lwa=0x0) at
> /usr/src/sys/kern/kern_lock.c:705
>705error = sleeplk(lk, flags, ilk, iwmesg, ipri,
> itimo,
>(kgdb) p (struct thread *)(lk->lk_lock & ~0x1f)
>$1 = (struct thread *) 0xfe02ddae0e40
>(kgdb) tid 0xfe02ddae0e40
>(kgdb) bt
>#0 sched_switch (td=td@entry=0xfe02ddae0e40, flags=flags@entry=259)
> at /usr/src/sys/kern/sched_ule.c:2299
>#1 0x80b5fbd4 in mi_switch (flags=flags@entry=259) at
> /usr/src/sys/kern/kern_synch.c:550
>#2 0x80bb1257 in sleepq_switch
> (wchan=wchan@entry=0xf81ab3c81154, pri=87, pri@entry=-1278734048) at
> /usr/src/sys/kern/subr_sleepqueue.c:609
>#3 0x80bb112e in sleepq_wait (wchan=,
> pri=) at /usr/src/sys/kern/subr_sleepqueue.c:660
>#4
Re: [Intel AlderLake] Read files to FAT32 or UFS partition cause data corrupt due to P-Core-Core
On Tue, Aug 8, 2023 at 10:50 AM Michael Butler wrote: > On 8/8/23 10:56, Tomoaki AOKI wrote: > > On Tue, 8 Aug 2023 17:02:32 +0300 > > Konstantin Belousov wrote: > > [ .. snip .. ] > > >> The workaround is switched on automatically, when kernel detects 'small > cores' > >> reported by CPUID. > > > > If I read the code correctly, vm.pmap.pcid_invlpg_workaround > > (precicely, the corresponding variable) is set to non-zero when the > > workaround is enabled. Not sure it was detected correctly at the > > original reporter's environment, but forcibly setting the tunable to 1 > > didn't reported to help sufficiently. > > Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help. > > I'm seeing similar stability problems on an N95-based device. This too > is an Alderlake-N device with only E-cores although I'm running it with > a compilation with CPUTYPE=tremont .. from an older, verbose start-up .. > > PPIM 0: PA=0x40, VA=0x8271, size=0x1d5000, mode=0x1 > pmap: large map 8 PML4 slots (4096 GB) > VT(efifb): resolution 800x600 > Preloaded elf kernel "/boot/kernel.new/kernel" at 0x8234e000. > Preloaded boot_entropy_cache "/boot/entropy" at 0x82357d08. > Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at > 0x82357d60. > Preloaded hostuuid "/etc/hostid" at 0x82357dc0. > Preloaded TSLOG data "TSLOG" at 0x82357e10. > CPU: Intel(R) N95 (1689.60-MHz K8-class CPU) >Origin="GenuineIntel" Id=0xb06e0 Family=0x6 Model=0xbe Stepping=0 > > > Features=0xbfebfbff > > > Features2=0x7ffafbbf >AMD Features=0x2c100800 >AMD Features2=0x121 >Structured Extended > > Features=0x239ca7eb >Structured Extended > > Features2=0x98c007bc >Structured Extended > > Features3=0xfc184410 >XSAVE Features=0xf >IA32_ARCH_CAPS=0x180fd6b >VT-x: Basic Features=0x3da0500 > Pin-Based Controls=0xff > Primary Processor > > Controls=0xfffbfffe > Secondary Processor > > Controls=0x75d7fff > Exit Controls=0x3da0500 > Entry Controls=0x3da0500 > EPT Features=0x6f34141 > VPID Features=0xf01 >TSC: P-state invariant, performance statistics > 64-Byte prefetching > L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > real memory = 17179869184 (16384 MB) > Physical memory chunk(s): > 0x0001 - 0x0009dfff, 581632 bytes (142 pages) > 0x0009f000 - 0x0009, 4096 bytes (1 pages) > 0x0010 - 0x5fff, 1609564160 bytes (392960 pages) > 0x62401000 - 0x7264dfff, 270848000 bytes (66125 pages) > 0x75fff000 - 0x75ff, 4096 bytes (1 pages) > 0x00011000 - 0x000462497fff, 14533881856 bytes (3548311 pages) > 0x00047fa0 - 0x00047fb68fff, 1478656 bytes (361 pages) > avail memory = 16363008000 (15604 MB) > CPU microcode: updated from 0xc to 0x10 > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 1: enabled > SMP: Added CPU 2 (AP) > MADT: Found CPU APIC ID 4 ACPI ID 2: enabled > SMP: Added CPU 4 (AP) > MADT: Found CPU APIC ID 6 ACPI ID 3: enabled > SMP: Added CPU 6 (AP) > > On start-up, vm.pmap.pcid_invlpg_workaround=1 but seemingly random > faults still occurred under load, for example, 'make buildworld'. > Apparent misreads of source-files resulting in syntax errors were the > most common symptom. Compilation reattempts (mostly) succeed. > > Initially, I put this down to an inadequate power-supply but setting > vm.pmap.pcid_enabled=0 seems to have stabilised it. > > I guess there's another dragon in there .. :-( > > Michae > Just to add another report (in the wrong mail list as it is also on a system running 13.2), I have a very similar system from a different manufacturer with the same Alder Lake processor. I will note that the SSD interface is SATA, not nvme. I was getting crashes and corrupt file systems, especially when installing large ports and using rsync to backup the system. I see many, almost identical systems on Amazon that use the same form factor CPU, SSD, RAM, etc, probably all using the same motherboard from a single manufacturer. There are going to be more issues as these boxes are generally <$225 US. (Mine was a bit more expensive to get a VGA connector for my ancient monitor. I had not tried the tuneable, but largely resolved the issue by installing a 250 MB hard drive and putting the system there. In the couple of months since I did this I have had two crashes, both when doing a full backup with rsync. This leads me to think that there is some sort of race triggering this that is minimized by the slow disc speed of spinning rust. I am considering moving the system back to the SSD with vm.pmap.pcid_enabled=0. If so, the failure should be very quick as I never could keep the system up long enough to get the system into production. -- Kevin Oberman, Part time kid herder and retired Network
Re: periodic daily produces ridiculously huge report files
Michael Grimm wrote > Ever since either upgrading to MAIN or WITHOUT_INET6=yes [1] I noticed that > periodic daily still runs in the morning failing to mail ridiculously huge > report files (>= 90 *GB*). > > [1] Can't remember when this started. FTR: It started with WITHOUT_INET6=yes. Recompiling world and kernel including IPv6 support brings "netstat -i -d -W -n" back to normal behavior. No more of netstat producing producing huge amounts of garbage. > But I would like to know, if this has to do with WITHOUT_INET6=yes or FreeBSD > 14? > Or something different ... > > Did someone of you experiences equal behaviour of "netstat -i -d -W"? > Anyone with WITHOUT_INET6=yes willing to test this? Anyone? Regards, Michael
Re: ZFS deadlock in 14
Dag-Erling Smørgrav writes:
> At some point between 42d088299c (4 May) and f0c9703301 (26 June), a
> deadlock was introduced in ZFS.
Trying to narrow this range down, I did not get a deadlock with
4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June), albeit
after building ~1800 packages. This is surprising since we have a
report of this or a very similar deadlock occurring with a kernel from 8
June (https://bugs.freebsd.org/271945). Perhaps I should try
4e8d558c9d1c again.
Here's the complete kgdb session showing, once again, a zfs rollback
stuck waiting for the txg to sync:
Reading symbols from /boot/GENERIC/kernel...
Reading symbols from /usr/lib/debug//boot/GENERIC/kernel.debug...
Unread portion of the kernel message buffer:
panic: deadlres_td_sleep_q: possible deadlock detected for
0xfe03567a01e0 (sh), blocked for 180242 ticks
cpuid = 17
time = 1691802362
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe021507ce00
vpanic() at vpanic+0x150/frame 0xfe021507ce50
panic() at panic+0x43/frame 0xfe021507ceb0
deadlkres() at deadlkres+0x350/frame 0xfe021507cef0
fork_exit() at fork_exit+0x80/frame 0xfe021507cf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe021507cf30
--- trap 0xdeadc0de, rip = 0xdeadc0dedeadc0de, rsp = 0xdeadc0dedeadc0de,
rbp = 0xdeadc0dedeadc0de ---
KDB: enter: panic
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59
59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb) tid 0xfe03567a01e0
(kgdb) bt
#0 sched_switch (td=td@entry=0xfe03567a01e0, flags=flags@entry=259) at
/usr/src/sys/kern/sched_ule.c:2299
#1 0x80b5fbd4 in mi_switch (flags=flags@entry=259) at
/usr/src/sys/kern/kern_synch.c:550
#2 0x80bb1257 in sleepq_switch (wchan=0xf80b139e4770,
wchan@entry=0x8113878f, pri=pri@entry=64) at
/usr/src/sys/kern/subr_sleepqueue.c:609
#3 0x80bb112e in sleepq_wait (wchan=,
pri=) at /usr/src/sys/kern/subr_sleepqueue.c:660
#4 0x80b21d6f in sleeplk (lk=lk@entry=0xf80b139e4770,
flags=flags@entry=2122752, ilk=ilk@entry=0x0,
wmesg=wmesg@entry=0x8113878f "tmpfs", pri=,
pri@entry=64, timo=timo@entry=6, queue=1) at /usr/src/sys/kern/kern_lock.c:310
#5 0x80b1fd9f in lockmgr_slock_hard (lk=0xf80b139e4770,
flags=2122752, ilk=, file=0x81296919
"/usr/src/sys/kern/vfs_lookup.c", line=1012, lwa=0x0) at
/usr/src/sys/kern/kern_lock.c:705
#6 0x80c5e444 in VOP_LOCK1 (vp=0xf80b139e4700, flags=2106368,
file=0x81296919 "/usr/src/sys/kern/vfs_lookup.c", line=1012) at
./vnode_if.h:1120
#7 _vn_lock (vp=0xf80b139e4700, flags=2106368, file=,
line=) at /usr/src/sys/kern/vfs_vnops.c:1808
#8 0x80c36eae in vfs_lookup (ndp=ndp@entry=0xfe03c63a6bd8) at
/usr/src/sys/kern/vfs_lookup.c:1010
#9 0x80c36291 in namei (ndp=ndp@entry=0xfe03c63a6bd8) at
/usr/src/sys/kern/vfs_lookup.c:689
#10 0x80c5681f in kern_statat (td=0xfe03567a01e0,
td@entry=, flag=, fd=-100, path=0x1032a8685a15
,
pathseg=pathseg@entry=UIO_USERSPACE, sbp=sbp@entry=0xfe03c63a6d18)
at /usr/src/sys/kern/vfs_syscalls.c:2441
#11 0x80c56f17 in sys_fstatat (td=, td@entry=, uap=0xfe03567a05e0,
uap@entry=) at
/usr/src/sys/kern/vfs_syscalls.c:2419
#12 0x8104d8e0 in syscallenter (td=) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:190
#13 amd64_syscall (td=0xfe03567a01e0, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:1199
#14
#15 0x103acaf3b03a in ?? ()
Backtrace stopped: Cannot access memory at address 0x103ac929af28
(kgdb) f 5
#5 0x80b1fd9f in lockmgr_slock_hard (lk=0xf80b139e4770,
flags=2122752, ilk=, file=0x81296919
"/usr/src/sys/kern/vfs_lookup.c", line=1012, lwa=0x0) at
/usr/src/sys/kern/kern_lock.c:705
705 error = sleeplk(lk, flags, ilk, iwmesg, ipri, itimo,
(kgdb) p (struct thread *)(lk->lk_lock & ~0x1f)
$1 = (struct thread *) 0xfe02ddae0e40
(kgdb) tid 0xfe02ddae0e40
(kgdb) bt
#0 sched_switch (td=td@entry=0xfe02ddae0e40, flags=flags@entry=259) at
/usr/src/sys/kern/sched_ule.c:2299
#1 0x80b5fbd4 in mi_switch (flags=flags@entry=259) at
/usr/src/sys/kern/kern_synch.c:550
#2 0x80bb1257 in sleepq_switch
(wchan=wchan@entry=0xf81ab3c81154, pri=87, pri@entry=-1278734048) at
/usr/src/sys/kern/subr_sleepqueue.c:609
#3 0x80bb112e in sleepq_wait (wchan=,
pri=) at /usr/src/sys/kern/subr_sleepqueue.c:660
#4 0x80b5f11d in _sleep (ident=0xf81ab3c81154,
lock=0xf81ab3c81120, priority=87, wmesg=0x82239fba "zfs teardown
inactive", sbt=0, pr=0, flags=256) at /usr/src/sys/kern/kern_synch.c:225
#5 0x80b4b640 in
Re: lang/gcc12 will not build on a host w/ 8 CPU and 16G mem
El día sábado, agosto 12, 2023 a las 01:38:32p. m. +, Lorenzo Salvadore escribió: > Hello, I am the port maintainer. > > It is a well known issue unfortunately. Just disable the LTO_BOOTSTRAP option > and the build will succeed. > > Cheers, > > Lorenzo Salvadore Lorenzo, Thanks for this FAST answer, much faster than I was able to describe my problem. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: lang/gcc12 will not build on a host w/ 8 CPU and 16G mem
Hello, I am the port maintainer. It is a well known issue unfortunately. Just disable the LTO_BOOTSTRAP option and the build will succeed. Cheers, Lorenzo Salvadore Sent from Proton Mail mobile Messaggio originale Il 12 Ago 2023, 15:33, Matthias Apitz ha scritto: > I'm building on 14-CURRENT with poudriere. The server in question is a Dell > R210 with 8x 3.30GHz CPU and 15.8 GB memory: Aug 11 19:03:21 jet kernel: CPU: > Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz (3292.74-MHz K8-class CPU) Aug 11 > 19:03:21 jet kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs Aug > 11 19:03:21 jet kernel: avail memory = 16582250496 (15814 MB) I have set swap > to 4GB + 10GB + 10GB: # swapctl -lh Device: Bytes Used: /dev/da0p3 4.0G 1.5G > /dev/md9 10G 1.5G /dev/md10 10G 1.5G and poudriere does use ZFS. Despite of > this relatively good equipped machine, lang/gcc12 can't be build. In > /var/log/messages after some 3 hours of compiling as a single(!) job in > poudriere: Aug 12 14:59:47 jet kernel: pid 57837 (lto1), jid 111, uid 65534, > was killed: a thread waited too long to allocate a page and the job fails in > poudriere with: ... xg++: fatal error: Killed signal terminated program lto1 > compilation terminated. lto-wrapper: fatal error: > /wrkdirs/usr/ports/lang/gcc12/work/.build/./prev-gcc/xg++ returned 1 exit > status compilation terminated. /usr/local/bin/ld: error: lto-wrapper failed > collect2: error: ld returned 1 exit status gmake[4]: *** > [/wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/cp/Make-lang.in:136: > cc1plus] Error 1 gmake[4]: *** Waiting for unfinished jobs What could I > do? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
lang/gcc12 will not build on a host w/ 8 CPU and 16G mem
I'm building on 14-CURRENT with poudriere. The server in question is a Dell R210 with 8x 3.30GHz CPU and 15.8 GB memory: Aug 11 19:03:21 jet kernel: CPU: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz (3292.74-MHz K8-class CPU) Aug 11 19:03:21 jet kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs Aug 11 19:03:21 jet kernel: avail memory = 16582250496 (15814 MB) I have set swap to 4GB + 10GB + 10GB: # swapctl -lh Device:Bytes Used: /dev/da0p3 4.0G 1.5G /dev/md9 10G 1.5G /dev/md1010G 1.5G and poudriere does use ZFS. Despite of this relatively good equipped machine, lang/gcc12 can't be build. In /var/log/messages after some 3 hours of compiling as a single(!) job in poudriere: Aug 12 14:59:47 jet kernel: pid 57837 (lto1), jid 111, uid 65534, was killed: a thread waited too long to allocate a page and the job fails in poudriere with: ... xg++: fatal error: Killed signal terminated program lto1 compilation terminated. lto-wrapper: fatal error: /wrkdirs/usr/ports/lang/gcc12/work/.build/./prev-gcc/xg++ returned 1 exit status compilation terminated. /usr/local/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status gmake[4]: *** [/wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/cp/Make-lang.in:136: cc1plus] Error 1 gmake[4]: *** Waiting for unfinished jobs What could I do? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: problem with poudriere && port ftp/curl
El día viernes, agosto 11, 2023 a las 11:59:45p. m. +0200, Jan Beich escribió:
> Matthias Apitz writes:
>
> > I have the following problem with poudriere on 14-CURRENT and ports from
> > git head: every time when I start poudriere-bulk it removes a port
> > already compile fine (and all its dependent ports) with the message:
> >
> > ...
> > [00:00:40] Sanity checking the repository
> > [00:00:40] Checking packages for incremental rebuild needs
> > [00:00:43] Deleting curl-8.2.1.pkg: changed options
> > [00:00:43] Pkg: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG
> > -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER -GSSAPI_BASE
> > -GSSAPI_HEIMDAL -GSSAPI_MIT +GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6
> > -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL
> > -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER
> > +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD
> > [00:00:43] New: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG
> > -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER +GSSAPI_BASE
> > -GSSAPI_HEIMDAL -GSSAPI_MIT -GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6
> > -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL
> > -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER
> > +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD
> >
> > The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE.
> > I have not set anything about
> > this in the port's options or jail's make.conf.
> >
> > What can I do to fix this?
>
> Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} == base :?BASE :NONE}
> in OPTIONS_DEFAULT due ssl!=base in DEFAULT_VERSIONS via make.conf(5).
> Try filing a bug against ftp/curl.
>
> $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty make -V
> '${OPTIONS_DEFAULT:M*GSS*}'
> GSSAPI_BASE
> $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty DEFAULT_VERSIONS=ssl=openssl make
> -V '${OPTIONS_DEFAULT:M*GSS*}'
> GSSAPI_NONE
>
> See also https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=6d324c1f70c9
>
> I can't reproduce on -CURRENT when only using base OpenSSL 3.0.
I ended up with creating the port's option file with
# cd /usr/ports/ftp/curl
# make config
# mkdir /usr/local/etc/poudriere.d/140-CURRENT-options/ftp_curl
# /var/db/ports/ftp_curl/options
/usr/local/etc/poudriere.d/140-CURRENT-options/ftp_curl/options
After this the port was not deleted anymore when starting poudriere.
The file /usr/local/etc/poudriere.d/140-CURRENT-options/ftp_curl/options
contains:
# This file is auto-generated by 'make config'.
# Options for curl-8.2.1
_OPTIONS_READ=curl-8.2.1
_FILE_COMPLETE_OPTIONS_LIST=ALTSVC BROTLI CA_BUNDLE COOKIES CURL_DEBUG DEBUG
DOCS EXAMPLES IDN IPV6 NTLM PROXY PSL STATIC TLS_SRP ZSTD GSSAPI_BASE
GSSAPI_HEIMDAL GSSAPI_MIT GSSAPI_NONE CARES THREADED_RESOLVER GNUTLS OPENSSL
WOLFSSL DICT FTP GOPHER HTTP HTTP2 IMAP LDAP LDAPS LIBSSH LIBSSH2 MQTT POP3
RTMP RTSP SMB SMTP TELNET TFTP WEBSOCKET
OPTIONS_FILE_SET+=ALTSVC
OPTIONS_FILE_UNSET+=BROTLI
OPTIONS_FILE_SET+=CA_BUNDLE
OPTIONS_FILE_SET+=COOKIES
OPTIONS_FILE_UNSET+=CURL_DEBUG
OPTIONS_FILE_UNSET+=DEBUG
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EXAMPLES
OPTIONS_FILE_UNSET+=IDN
OPTIONS_FILE_SET+=IPV6
OPTIONS_FILE_SET+=NTLM
OPTIONS_FILE_SET+=PROXY
OPTIONS_FILE_UNSET+=PSL
OPTIONS_FILE_SET+=STATIC
OPTIONS_FILE_SET+=TLS_SRP
OPTIONS_FILE_UNSET+=ZSTD
OPTIONS_FILE_UNSET+=GSSAPI_BASE
OPTIONS_FILE_UNSET+=GSSAPI_HEIMDAL
OPTIONS_FILE_UNSET+=GSSAPI_MIT
OPTIONS_FILE_SET+=GSSAPI_NONE
OPTIONS_FILE_UNSET+=CARES
OPTIONS_FILE_SET+=THREADED_RESOLVER
OPTIONS_FILE_UNSET+=GNUTLS
OPTIONS_FILE_SET+=OPENSSL
OPTIONS_FILE_UNSET+=WOLFSSL
OPTIONS_FILE_SET+=DICT
OPTIONS_FILE_SET+=FTP
OPTIONS_FILE_SET+=GOPHER
OPTIONS_FILE_SET+=HTTP
OPTIONS_FILE_SET+=HTTP2
OPTIONS_FILE_SET+=IMAP
OPTIONS_FILE_UNSET+=LDAP
OPTIONS_FILE_UNSET+=LDAPS
OPTIONS_FILE_UNSET+=LIBSSH
OPTIONS_FILE_UNSET+=LIBSSH2
OPTIONS_FILE_UNSET+=MQTT
OPTIONS_FILE_SET+=POP3
OPTIONS_FILE_UNSET+=RTMP
OPTIONS_FILE_SET+=RTSP
OPTIONS_FILE_UNSET+=SMB
OPTIONS_FILE_SET+=SMTP
OPTIONS_FILE_SET+=TELNET
OPTIONS_FILE_SET+=TFTP
OPTIONS_FILE_UNSET+=WEBSOCKET
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Re: ssh 9.4 fails to build
On Sat, 12 Aug 2023 08:04:29 +0200 (CEST) Ronald Klop wrote: > Hi, > > I get this error while building world. > NB: I'm building with llvm15 from a pkg. But I don't think that should make a > difference. > ld.lld: error: undefined symbol: Fssh_lib_contains_symbol > >>> referenced by ssh-pkcs11.c:1538 > >>> (/usr/src/crypto/openssh/ssh-pkcs11.c:1538) > >>> ssh-pkcs11.o:(Fssh_pkcs11_add_provider) > > > git reset --hard fixes the build for me. > I just updated my current source tree and ran buildworld and ssh compiled without any errors. ./obj/usr/src/amd64.amd64/secure/usr.bin/ssh/ssh -V OpenSSH_9.4p1, OpenSSL 3.0.9 30 May 2023 But I'm using LLVM16. -- Gary Jennejohn
Re: aarch64 (not armv7) kyua run on main [so: 14]: sys/net/if_lagg_test:status_stress got "Fatal data abort" panic [14.0-ALPHA1 snapshot panic submitted to bugzilla]
On Aug 9, 2023, at 22:30, Mark Millard wrote: > The context is on a Windows Dev Kit 2023, using a bectl based boot/root disk: > > # uname -apKU > FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400094 #9 > main-n264643-0befc55cdf4b-dirty: Wed Aug 9 14:23:48 PDT 2023 > root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA78C > arm64 aarch64 1400094 1400094 > > I only do bugzailla submittals based on just my > own builds as a means of last resort: I try to > use official builds for such. The: > > main-n264491-8a5c836b51ce: Thu Aug 3 > > snapshot did not panic on the RPi4B that I > tried it with. We will see for the next > snapshot at some point. > > Both the non-debug and the debug kernels panic. > I saw no evidence of the debug kernel reporting > anything. > > Note the: > > 0xdeadc0dedeadc0de (2 examples) > and: > 0xfefefefefefefeff (1 example) > > that may have some significance. > > . . . > sys/net/if_gif:basic -> passed [0.195s] > sys/net/if_lagg_test:create -> passed [0.125s] > sys/net/if_lagg_test:create_destroy_stress -> skipped: Skipping this test > because it easily panics the machine [0.022s] > sys/net/if_lagg_test:lacp_linkstate_destroy_stress -> passed [60.048s] > sys/net/if_lagg_test:set_ether -> passed [0.090s] > sys/net/if_lagg_test:status_stress -> > > <6>lagg0: link state changed to DOWN > Fatal data abort: > x0: 0x000186c82858 (_DYNAMIC + 0x271e46b8) > x1: 0x0001 > x2: 0xdeadc0dedeadc0de > x3: 0x005b68c0 (ifdead_ioctl + 0x0) > x4: 0xa000a8ba305e > x5: 0xa00023d932fa > x6: 0x6767616c > x7: 0x6e6d760070617401 > x8: 0x030c > x9: 0x00210005 > x10: 0x0800 > x11: 0xfefefefefefefeff > x12: 0x0008 > x13: 0x > x14: 0x0001 > x15: 0x0001 > x16: 0x0001 > x17: 0x0007 > x18: 0x000186c82520 > <6>ue0: link state changed to DOWN > (_DYNAMIC + 0x271e4380) > x19: 0x000186c82858 (_DYNAMIC + 0x271e46b8) > x20: 0xa000a8ba3000 > x21: 0xa000a8ba3058 > x22: 0x000c > x23: 0x0005 > x24: 0x > x25: 0x00c7a000 (keysw + 0xb8) > x26: 0x > x27: 0x00cf9000 (sdta_vfs_vop_vop_spare4_return1 + 0x18) > x28: 0x0008 > x29: 0x000186c82540 (_DYNAMIC + 0x271e43a0) > sp: 0x000186c82520 > lr: 0x006a0b50 (dump_iface + 0x2c0) > elr: 0x006a124c (dump_sa + 0x1c) > spsr: 0x00400045 > far: 0xdeadc0dedeadc0df > esr: 0x9604 > timeout stopping cpus > panic: vm_fault failed: 0x006a124c error 1 > cpuid = 2 > time = 1691642123 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x13c > panic() at panic+0x44 > data_abort() at data_abort+0x358 > handle_el1h_sync() at handle_el1h_sync+0x14 > --- exception, esr 0x9604 > dump_sa() at dump_sa+0x1c > dump_iface() at dump_iface+0x2bc > dump_cb() at dump_cb+0x18 > if_foreach_sleep() at if_foreach_sleep+0x208 > rtnl_handle_getlink() at rtnl_handle_getlink+0xec > rtnl_handle_message() at rtnl_handle_message+0x19c > nl_taskqueue_handler() at nl_taskqueue_handler+0x5f4 > taskqueue_run_locked() at taskqueue_run_locked+0x1a4 > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 > > This was from: > > # /usr/bin/kyua test -k /usr/tests/Kyuafile > > But the earlier part of the run is not > needed to get the panic. Booting, logging > in as root, and doing: > > # /usr/bin/kyua test -k /usr/tests/Kyuafile sys/net/if_lagg_test:status_stress > > is sufficient to get the panic in my context. > > > For reference for the RPi4B not getting the panic: > > Trying on an RPi4B with a somewhat older snapshot did not panic: > > # uname -apKU > you have mail > FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400093 #0 > main-n264491-8a5c836b51ce: Thu Aug 3 12:10:50 UTC 2023 > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > aarch64 1400093 1400093 > > # /usr/bin/kyua test -k /usr/tests/Kyuafile sys/net/if_lagg_test:status_stress > sys/net/if_lagg_test:status_stress -> passed [60.371s] > > Results file id is usr_tests.20230804-151402-553517 > Results saved to /root/.kyua/store/results.usr_tests.20230804-151402-553517.db > > 1/1 passed (0 failed) I replicated the panic via an 14.0-ALPHA1 snapshot dd'd to USB media then used to boot and operate a Windows Dev Kit 2023. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273081 === Mark Millard marklmi at yahoo.com
ssh 9.4 fails to build
Hi, I get this error while building world. NB: I'm building with llvm15 from a pkg. But I don't think that should make a difference. ld.lld: error: undefined symbol: Fssh_lib_contains_symbol referenced by ssh-pkcs11.c:1538 (/usr/src/crypto/openssh/ssh-pkcs11.c:1538) ssh-pkcs11.o:(Fssh_pkcs11_add_provider) git reset --hard fixes the build for me. Regards, Ronald.
