CURRENT with ZFS not bootable when built with LLVM from ports
Building -CURRENT (2023-07-17 be4c7f273508) without system compiler (with LLVM16 from ports) results in unbootable system:Preloaded elf kernel "/boot/kernel/kernel" at 0x82328000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0x82329090. Preloaded boot_entropy_cache "/boot/entropy" at 0x823298f8. Preloaded elf obj module "/boot/kernel/cryptodev.ko" at 0x82329950. Preloaded hostuuid "/etc/hostid" at 0x8232a140. kldload: unexpected relocation type 42, symbol index 8662 link_elf_obj: symbol __stack_chk_guard undefined KLD file zfs.ko - could not finalize loading Patching and rebuilding LLVM16 with this patch results in bootable system: Patch was taken from: https://cgit.freebsd.org/src/commit/?h=stable/13&id=e8e5d75e6a9676e76c3bfd6d1d52561ffbb40846 Few months ago it was possible to use LLVM from ports to build kernel and world, but I don't remember the details. This patch was tested in bhyve VM and on real hardware. On real hardware it was possible to boot system without patched compiler when zfs.ko (options ZFS and GEOM_ELI with devices crypto and cryptodev) is built into the kernel. But then other modules (acpi_ibm, iic, drm, i915kms, acpi_video, ... pf, various ng_* and so on) will fail to load with same reason. Didn't try including zfs.ko into the kernel in the VM. Bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272740
Re: ps(1) bugs and problems
On 2023-07-29 00:07:37, Jamie Landeg-Jones wrote: I have a program that produces a list of PIDS, that are supplied via '-p' to /bin/ps and are sorted with '-d'. What language is it written in? What is the use case? After a late upgrade on a particular machine, I've just been bitten by the modifications to "ps" to unconditionaly add recurive descendancy PID lookups to the '-d' option when a pid is specified. I understand that the behavioral change affected programs/scripts in a way that requires adjustment and I do try to limit that as much as possible. But this feature was a needed one and I thought it should "just work" when -d was combined with -p, as opposed to adding a new flag to the program. Now that you've corrected my thinking, I plan to revert that change and re-introduce the feature as a separate option, see https://reviews.freebsd.org/D41231 for review. There is nothing in the man pages or docs to suggest that this should be a thing, but there you go. I intend to revert the change so there's no plan to update this in the manual page. Rather than just patch it out, Would a patch to allow the previous behaviour as an option (even if the option isn't default) be accepted? Feel free to discuss D41231 or provide an other patch. In addition, there is a bug in that ps now goes into a memory-sucking endless-loop if you do: ps -dp0 Thanks for this report, it was an oversight of the corner case that the parent PID of the PID 0 is also 0. The manual page is no longer accurate either: '-d' says "Note that this option has no effect if the “command” column is not the last column displayed." That is no longer true, it doesn't matter what column is displayed last, if you use '-p', '-d' now completely changes the output title: ps: extend the non-standard option -d (tree view) to work with -p https://cgit.freebsd.org/src/commit/bin/ps/ps.c?id=ca8c0d5e811048ad67d0955642c5b486e9c0f3d2 author: Piotr Pawel Stefaniak 2020-05-07 16:56:18 + commit: ca8c0d5e811048ad67d0955642c5b486e9c0f3d2 (patch) tree: 374be17aead18daf2e3c7477a4573f60ce62d8f0 /bin/ps/ps.c My plan is to revert that. Piotr
FYI for aarch64/armv7 lib32: armv7 kyua test sys/net/if_bridge_test:gif with preloaded if_bridge.ko still panics in my style of testing
I finally got around to testing lib32 some more, first trying the panic case that I'd gotten in early testing. The below is without any special lib32 patching for testing, just my normal non-debug environment updated to a lib32-present aarch64 FreeBSD vintage. Reminder: /usr/obj/DESTDIRs/main-CA7-chroot/ contains an armv7 installworld distrib-dirs distribution DB_FROM_SRC=1 result. (It also has various ports installed.) # ~/prekyua-kldloads.sh . . . # env \ > LD_32_LIBRARY_PATH=/usr/obj/DESTDIRs/main-CA7-chroot/lib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/lib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/libexec/rtld-elf\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libxo\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/csu/dynamiclib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/tls\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libc/stdlib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/lib/libthr/dlopen\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/lib-dynload\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/CORE\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/perl5/5.32/mach/auto \ > PATH=/usr/obj/DESTDIRs/main-CA7-chroot/sbin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/bin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/sbin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/sbin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/bin\ > :/usr/obj/DESTDIRs/main-CA7-chroot/root/bin \ > /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua test \ > -k /usr/obj/DESTDIRs/main-CA7-chroot/usr/tests/Kyuafile > sys/net/if_bridge_test:gif sys/net/if_bridge_test:gif -> Jul 29 21:29:16 CA72-16Gp-ZFS dhclient[56641]: epair0a: not found Jul 29 21:29:16 CA72-16Gp-ZFS dhclient[56641]: exiting. Fatal data abort: x0: 0xa0275306c560 x1: 0xa027f9d053d2 x2: 0x002a x3: 0xa0275306c560 x4: 0xa027f9d053fc x5: 0xa0275306c58a x6: 0x3ec2 x7: 0x010006085ba958bc x8: 0x002a x9: 0x002a x10: 0x0008010006085ba9 x11: 0x58bc3ec201000406 x12: 0x016433c65ba9 x13: 0x026433c6 x14: 0x00ff x15: 0x289f x16: 0x0002d056b370 (_DYNAMIC + 0x370) x17: 0x00598110 (m_dup + 0x0) x18: 0x0002801e94a0 x19: 0x0001 x20: 0x x21: 0x x22: 0x00d95000 (vop_spare3_desc + 0x18) x23: 0xa0275306c500 x24: 0xa0275306c500 x25: 0x00a0 x26: 0x0002 x27: 0x x28: 0xa0275306c500 x29: 0x0002801e94c0 sp: 0x0002801e94a0 lr: 0x00598308 (m_dup + 0x1f8) elr: 0x00598160 (m_dup + 0x50) spsr: 0x2045 far: 0x001c esr: 0x9604 panic: vm_fault failed: 0x00598160 error 1 cpuid = 14 time = 1690691356 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+0x2fc handle_el1h_sync() at handle_el1h_sync+0x14 --- exception, esr 0x9604 m_dup() at m_dup+0x50 bridge_input() at bridge_input+0x17c gif_input() at gif_input+0x2dc in_gif_input() at in_gif_input+0x5c encap_input() at encap_input+0xfc encap4_input() at encap4_input+0x30 ip_input() at ip_input+0x5ac netisr_dispatch_src() at netisr_dispatch_src+0xf8 ether_demux() at ether_demux+0x14c ether_nh_input() at ether_nh_input+0x39c netisr_dispatch_src() at netisr_dispatch_src+0xf8 ether_input() at ether_input+0x50 epair_tx_start_deferred() at epair_tx_start_deferred+0x110 taskqueue_run_locked() at taskqueue_run_locked+0x198 taskqueue_thread_loop() at taskqueue_thread_loop+0x130 fork_exit() at fork_exit+0x88 fork_trampoline() at fork_trampoline+0x14 KDB: enter: panic [ thread pid 0 tid 1028122 ] Stopped at kdb_enter+0x44: str xzr, [x19, #3328] For reference: # uname -apKU FreeBSD CA72-16Gp-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400093 #102 main-n264334-215bab7924f6-dirty: Wed Jul 26 02:02:48 PDT 2023 root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400093 1400093 === Mark Millard marklmi at yahoo.com
