On Thu, Jun 11, 2026 at 5:15 PM Aleksandr Rybalko <[email protected]> wrote: > > Fixed with mtx_owned(9) test yet. > See > https://github.com/freebsd/freebsd-src/commit/1f68ca5802db91bd9725bcdbf55932e104dbe95d > > Thanks! > >
Thank you for fixing the panic. I still think the locking from vt_mouse_event may be busted. Ryan > сб, 6 черв. 2026 р. о 03:17 Ryan Libby <[email protected]> пише: >> >> On Tue, Jun 2, 2026 at 3:01 PM Aleksandr Rybalko <[email protected]> wrote: >> > >> > Hey, Adrian! >> > >> > Know why, but working on a fix yet. >> > >> > Thanks! >> > >> > вт, 2 черв. 2026 р. о 20:01 Adrian Chadd <[email protected]> пише: >> >> >> >> hey! was this eventually fixed? I just hit it, notably a few days old >> >> -head (i think), but I still hit it. >> >> >> >> THanks! >> >> >> >> >> >> -a >> >> >> >> On Fri, 22 May 2026 at 08:51, Aleksandr Rybalko <[email protected]> wrote: >> >> > >> >> > Hey guys! >> >> > >> >> > Yeah, it seems my. >> >> > I will look into it today. >> >> > >> >> > Thanks! >> >> > >> >> > пт, 22 трав. 2026 р. о 18:35 Ryan Libby <[email protected]> пише: >> >> >> >> >> >> On Fri, May 22, 2026 at 1:46 AM Bjoern A. Zeeb >> >> >> <[email protected]> wrote: >> >> >> > >> >> >> > Hi, >> >> >> > >> >> >> > I was using the mouse in tmux on v1 when everying stopped. >> >> >> > Sadly we didn't switch to v0 for console but it seems I managed to >> >> >> > get a dump only checking now; the kernel from then is already gone. >> >> >> > >> >> >> > core.txt said. >> >> >> > >> >> >> > panic: mtx_lock_spin: recursed on non-recursive mutex vtbuf @ >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:744 >> >> >> > >> >> >> > cpuid = 1 >> >> >> > time = 1779437567 >> >> >> > KDB: stack backtrace: >> >> >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> >> >> > 0xfffffe00d773e7a0 >> >> >> > vpanic() at vpanic+0x149/frame 0xfffffe00d773e8d0 >> >> >> > panic() at panic+0x43/frame 0xfffffe00d773e930 >> >> >> > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0x11b/frame >> >> >> > 0xfffffe00d773e970 >> >> >> > vtbuf_flush_mark() at vtbuf_flush_mark+0x82/frame 0xfffffe00d773e9b0 >> >> >> > vtbuf_unmark_on_cross() at vtbuf_unmark_on_cross+0xcc/frame >> >> >> > 0xfffffe00d773e9d0 >> >> >> > vtterm_fill() at vtterm_fill+0x27/frame 0xfffffe00d773ea00 >> >> >> > teken_subr_erase_line() at teken_subr_erase_line+0x90/frame >> >> >> > 0xfffffe00d773ea20 >> >> >> > teken_state_2() at teken_state_2+0x497/frame 0xfffffe00d773ea40 >> >> >> > teken_input_char() at teken_input_char+0x47/frame 0xfffffe00d773ea60 >> >> >> > teken_input() at teken_input+0x9f/frame 0xfffffe00d773ea90 >> >> >> > termtty_outwakeup() at termtty_outwakeup+0xcf/frame >> >> >> > 0xfffffe00d773eb60 >> >> >> > ttydisc_write() at ttydisc_write+0x337/frame 0xfffffe00d773ecd0 >> >> >> > ttydev_write() at ttydev_write+0x13f/frame 0xfffffe00d773ed10 >> >> >> > devfs_write_f() at devfs_write_f+0xf3/frame 0xfffffe00d773ed70 >> >> >> > dofilewrite() at dofilewrite+0x81/frame 0xfffffe00d773edc0 >> >> >> > sys_writev() at sys_writev+0x69/frame 0xfffffe00d773ee00 >> >> >> > amd64_syscall() at amd64_syscall+0x168/frame 0xfffffe00d773ef30 >> >> >> > fast_syscall_common() at fast_syscall_common+0xf8/frame >> >> >> > 0xfffffe00d773ef30 >> >> >> > --- syscall (121, FreeBSD ELF64, writev), rip = 0x82601d5aa, rsp = >> >> >> > 0x8207a3408, rbp = 0x8207a3430 --- >> >> >> > KDB: enter: panic >> >> >> > >> >> >> > >> >> >> > In case it helps, I believe this is file:line as reported by gdb in >> >> >> > core.txt: >> >> >> > >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/kern_mutex.c:353 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:744 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:864 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:210 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:232 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_core.c:1201 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:121 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken_subr.h:558 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:255 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:284 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:317 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/subr_terminal.c:422 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/sys/ttydevsw.h:114 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/tty_ttydisc.c:658 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/tty.c:550 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/fs/devfs/devfs_vnops.c:1980 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/sys/file.h:372 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:565 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:492 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:478 >> >> >> > at >> >> >> > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/amd64/amd64/../../kern/subr_syscall.c:193 >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Bjoern A. Zeeb >> >> >> > r15:7 >> >> >> > >> >> >> >> >> >> I think it's probably related to or a regression from >> >> >> 8db0553ed6d8 ("vt: Clear cut-paste selection if the area intersects >> >> >> with the filled region") >> >> >> https://cgit.freebsd.org/src/commit/?id=8db0553ed6d8636d82a26896237099526b93be19 >> >> >> >> >> >> which added vtbuf_unmark_on_cross() which is in your panic stack. >> >> >> >> >> >> I don't know this code but it looks like the mutex is first taken by >> >> >> teken_input / teken_funcs_pre_input / vtterm_pre_input and then again >> >> >> by teken_input with your panic stack. >> >> >> >> >> >> Ryan >> >> How is the locking supposed to work in vt_mouse_event anyway? >> >> Unsolicited suggestion: require that the vb_lock be held on entry to >> vtbuf_set_mark, remove the lock acquisition from vtbuf_flush_mark, and >> make the call path through vt_mouse_event to vtbuf_set_mark and >> vtbuf_unmark acquire the lock. >> >> Ryan
