This may or may not be related to bug #226413, but I'm seeing exactly the same autofs warnings before it happens, and I'm using a wildcard in /etc/auto_home. When shutting down the system, I sometimes get this panic: WARNING: autofs_trigger_one: cv_wait_sig for /home/ failed with error -1 WARNING: autofs_trigger_one: cv_wait_sig for /home/ failed with error -1 WARNING: autofs_trigger_one: cv_wait_sig for /home/ failed with error -1 Fatal trap 9: general protection fault while in kernel mode cpuid = 10; apic id = 0a instruction pointer = 0x20:0xffffffff83df4d06 stack pointer = 0x28:0xfffffe01fe0907d0 frame pointer = 0x28:0xfffffe01fe090850 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 7055 (tcsh) rdi: fffff80106975ea0 rsi: 0000000000000004 rdx: fffff802390cf000 rcx: deadc0dedeadc0de r8: fffff801f8ab5000 r9: ffffffff82264908 rax: deadc0dedeadc0de rbx: deadc0dedeadc0de rbp: fffffe01fe090850 r10: 0000000000000000 r11: 0000000000000001 r12: fffff801fc40b806 r13: 0000000000200000 r14: 0000000000000000 r15: fffff802390cf000 trap number = 9 panic: general protection fault cpuid = 10 time = 1775745385 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01fe090550 vpanic() at vpanic+0x136/frame 0xfffffe01fe090680 panic() at panic+0x43/frame 0xfffffe01fe0906e0 trap_fatal() at trap_fatal+0x68/frame 0xfffffe01fe090700 calltrap() at calltrap+0x8/frame 0xfffffe01fe090700 --- trap 0x9, rip = 0xffffffff83df4d06, rsp = 0xfffffe01fe0907d0, rbp = 0xfffffe01fe090850 --- autofs_trigger() at autofs_trigger+0xd6/frame 0xfffffe01fe090850 autofs_trigger_vn() at autofs_trigger_vn+0x98/frame 0xfffffe01fe0908b0 autofs_lookup() at autofs_lookup+0x20f/frame 0xfffffe01fe0909d0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x57/frame 0xfffffe01fe090a00 vfs_lookup() at vfs_lookup+0x5aa/frame 0xfffffe01fe090a90 namei() at namei+0x35d/frame 0xfffffe01fe090af0 vn_open_cred() at vn_open_cred+0x54a/frame 0xfffffe01fe090c70 openatfp() at openatfp+0x2b7/frame 0xfffffe01fe090dd0 sys_openat() at sys_openat+0x3d/frame 0xfffffe01fe090e00 amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe01fe090f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe01fe090f30 --- syscall (499, FreeBSD ELF64, openat), rip = 0x708b64aa24a, rsp = 0x708b286e608, rbp = 0x708b286e700 --- KDB: enter: panic [ thread pid 7055 tid 101224 ] Stopped at kdb_enter+0x33: movq $0,0x15e5d72(%rip) db>
What is the source line for autofs_trigger+0xd6? Ideally you would obtain a vmcore and do full backtrace in kgdb.
Created attachment 273415 [details] crashinfo output It happened again and I was able to get a vmcore. Have attached crashinfo output, can provide a 3.5GB core file for debugging if necessary.
(In reply to Hans Rosenfeld from comment #2) This crash has nothing to do with autofs.
Created attachment 273416 [details] crashinfo output Uploaded the wrong file. Sorry, I've added the correct one now.
Load the core file into kgdb, then please do the following: frame 7 p *anp list The line numbers in your core dump do not match the kernel sources.
(kgdb) frame 7 #7 0xffffffff839f4d46 in autofs_trigger_one (anp=0xfffff8019022b000, component=0xfffff80a7c390c06 "woodstoc/.screen/7085.pts-1.tequila", componentlen=<optimized out>) at /usr/src/sys/fs/autofs/autofs.c:399 399 for (firstanp = anp; firstanp->an_parent->an_parent != NULL; (kgdb) p *anp $1 = {an_link = {rbe_link = {0xdeadc0dedeadc0de, 0xdeadc0dedeadc0de, 0xdeadc0dedeadc0de}}, an_name = 0xdeadc0dedeadc0de <error: Cannot access memory at address 0xdeadc0dedeadc0de>, an_fileno = -559038242, an_parent = 0xdeadc0dedeadc0de, an_children = {rbh_root = 0xdeadc0dedeadc0de}, an_mount = 0xdeadc0dedeadc0de, an_vnode = 0xdeadc0dedeadc0de, an_vnode_lock = {lock_object = { lo_name = 0xdeadc0dedeadc0de <error: Cannot access memory at address 0xdeadc0dedeadc0de>, lo_flags = 3735929054, lo_data = 3735929054, lo_witness = 0xdeadc0dedeadc0de}, sx_lock = 16045693110842147038}, an_cached = 222, an_wildcards = 192, an_callout = {c_links = {le = {le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de}, sle = { sle_next = 0xdeadc0dedeadc0de}, tqe = {tqe_next = 0xdeadc0dedeadc0de, tqe_prev = 0xdeadc0dedeadc0de}}, c_time = -2401050962867404578, c_precision = -2401050962867404578, c_arg = 0xdeadc0dedeadc0de, c_func = 0xdeadc0dedeadc0de, c_lock = 0xdeadc0dedeadc0de, c_flags = -16162, c_iflags = -8531, c_cpu = -559038242}, an_retries = -559038242, an_ctime = { tv_sec = -2401050962867404578, tv_nsec = -2401050962867404578}} (kgdb) list 394 sx_assert(&autofs_softc->sc_lock, SA_XLOCKED); 395 396 if (anp->an_parent == NULL) { 397 key = strndup(component, componentlen, M_AUTOFS); 398 } else { 399 for (firstanp = anp; firstanp->an_parent->an_parent != NULL; 400 firstanp = firstanp->an_parent) 401 continue; 402 key = strdup(firstanp->an_name, M_AUTOFS); 403 }
When this happens, did you tried something like restarting the automounter daemons, or manually unmounting autofs mounts? Anyway, try https://reviews.freebsd.org/D58626
When this happened I was rebooting the system with reboot(8) while logged in as user with $HOME on an automounted NFS share.
(In reply to Hans Rosenfeld from comment #8) Yeah, the automounter is being stopped by rc, but your session tried to access the home perhaps. This fits into what I theoretised there. Try the patch.
I was able to reproduce a panic with similar backtrace by triggering a lookup and performing a forced unmount before the lookup could finish. after applying kib's patch, the panic didn't occur it took a couple minutes for the long running autofs requests to timeout before the unmount finished successfully - not unexpected since the default timeout for requests is 30 seconds
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b95a859483f1ac0671bde55c0a2fc46f4db5ba4b commit b95a859483f1ac0671bde55c0a2fc46f4db5ba4b Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2026-08-03 17:41:46 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2026-08-04 22:36:13 +0000 autofs_lookup(): busy the mount point around autofs_trigger() Since autofs_lookup() calls into autofs_trigger_vn() to perform automounting, and autofs_trigger_vn() unlocks the vnode, it is possible for the unmount to start meantime. Then autofs_trigger() accesses freed memory. At this point, busy can be only done unblocking, and the transient failure must abort the trigger operation. This would cause spurious automounter errors, but at least should prevent accesses to the freed memory. PR: 294361 Reviewed by: markj, rew Tested by: rew Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D58626 sys/fs/autofs/autofs_vnops.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
The patch seems to fix this issue. There are still a gazillion of cv_wait_sig messages: WARNING: autofs_trigger_one: cv_wait_sig for /home/ failed with error -1
(In reply to Hans Rosenfeld from comment #12) I see what you mean when you say a gazillion cv_wait_sig() messages..looks like a different bug, can you try the following? https://reviews.freebsd.org/D58682