Created attachment 204230 [details] kldstat -v I have FreeBSD system: # uname -a FreeBSD core.domain.com 12.0-STABLE FreeBSD 12.0-STABLE r347079 SUPPORT-12-0-1 amd64 root@core:~ # kldload dcons.ko root@core:~ # root@core:~ # kldunload dcons.ko And the system crashes... root@core:~ # /usr/libexec/kgdb /boot/kernel/kernel /var/crash/vmcore.2 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: dcons: unload panic: Terminal device freed without a free-handler cpuid = 0 time = 1557100854 KDB: stack backtrace: #0 0xffffffff80cc3707 at kdb_backtrace+0x67 #1 0xffffffff80c775dd at vpanic+0x19d #2 0xffffffff80c77433 at panic+0x43 #3 0xffffffff80cf81a2 at ttydevsw_deffree+0x12 #4 0xffffffff80cfa15d at tty_dealloc+0xad #5 0xffffffff80c14c5c at destroy_dev_tq+0xac #6 0xffffffff80cd5de4 at taskqueue_run_locked+0x154 #7 0xffffffff80cd5bd1 at taskqueue_run+0x71 #8 0xffffffff80c3a654 at ithread_loop+0x1d4 #9 0xffffffff80c374c3 at fork_exit+0x83 #10 0xffffffff81248a8e at fork_trampoline+0xe Uptime: 1m52s Dumping 268 out of 979 MB:..6%..12%..24%..36%..42%..54%..66%..72%..84%..96% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/dcons.ko...Reading symbols from /usr/lib/debug//boot/kernel/dcons.ko.debug...done. done. Loaded symbols for /boot/kernel/dcons.ko #0 doadump () at src/sys/amd64/include/pcpu.h:230 230 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (OFFSETOF_CURTHREAD)); (kgdb) bt #0 doadump () at src/sys/amd64/include/pcpu.h:230 #1 0xffffffff80c771d8 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xffffffff80c77639 in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:877 #3 0xffffffff80c77433 in panic (fmt=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:804 #4 0xffffffff80cf81a2 in ttydevsw_deffree (softc=<value optimized out>) at /usr/src/sys/kern/tty.c:1007 #5 0xffffffff80cfa15d in tty_dealloc (arg=0xfffff800254ea000) at src/sys/sys/ttydevsw.h:198 #6 0xffffffff80c14c5c in destroy_dev_tq (ctx=<value optimized out>, pending=<value optimized out>) at /usr/src/sys/kern/kern_conf.c:1438 #7 0xffffffff80cd5de4 in taskqueue_run_locked (queue=0xfffff8000305db00) at /usr/src/sys/kern/subr_taskqueue.c:467 #8 0xffffffff80cd5bd1 in taskqueue_run (queue=0xfffff8000305db00) at /usr/src/sys/kern/subr_taskqueue.c:486 #9 0xffffffff80c3a654 in ithread_loop (arg=<value optimized out>) at /usr/src/sys/kern/kern_intr.c:1129 #10 0xffffffff80c374c3 in fork_exit (callout=0xffffffff80c3a480 <ithread_loop>, arg=0xfffff80003111540, frame=0xfffffe0000434ac0) at /usr/src/sys/kern/kern_fork.c:1060 #11 0xffffffff81248a8e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:995 #12 0x0000000000000000 in ?? () Current language: auto; currently minimal
CC (relatively) recent sys/kern/tty.c committers, in particular base r294598 which may be relevant. CC eadler who pasted [1] a dcons kld load/unload panic recently [1] https://reviews.freebsd.org/P170
Original freebsd-hackers post on dcons panic: https://lists.freebsd.org/pipermail/freebsd-hackers/2018-April/052610.html
I've tracked down what's causing this, but it may take me a couple days to have a non-hacky fix ready.
Created attachment 204233 [details] Patch for panic on kldunload dcons Actually, this is not too hacky, and allows me to load/unload the module repeatedly on an rpi2. I don't have an x86 system available to test right now, but I'd expect it to work there too.
A commit references this bug: Author: ian Date: Fri May 10 02:30:17 UTC 2019 New revision: 347422 URL: https://svnweb.freebsd.org/changeset/base/347422 Log: Allow dcons(4) to be unloaded when loaded as a module. When the module is unloaded, the tty devices are destroyed. That requires implementing the tsw_free callback to avoid a panic. This driver requires no particular cleanup to be done from the callback, but the module itself must remain in memory until the deferred tsw_free callbacks are invoked. These changes implement that by incrementing a reference count variable in the detach routine, and decrementing it in the tsw_free callback. The MOD_UNLOAD event handler doesn't return until the count drops to zero. PR: 237758 Changes: head/sys/dev/dcons/dcons_os.c
@Ian Thank you for taking care of this. I note no MFC in the commit log message, but imagine 12 & 11 are affected, unless it was only a 12 regression? Could you clarify.
A commit references this bug: Author: ian Date: Wed May 15 17:50:17 UTC 2019 New revision: 347624 URL: https://svnweb.freebsd.org/changeset/base/347624 Log: MFC r347422: Allow dcons(4) to be unloaded when loaded as a module. When the module is unloaded, the tty devices are destroyed. That requires implementing the tsw_free callback to avoid a panic. This driver requires no particular cleanup to be done from the callback, but the module itself must remain in memory until the deferred tsw_free callbacks are invoked. These changes implement that by incrementing a reference count variable in the detach routine, and decrementing it in the tsw_free callback. The MOD_UNLOAD event handler doesn't return until the count drops to zero. PR: 237758 Changes: _U stable/12/ stable/12/sys/dev/dcons/dcons_os.c
A commit references this bug: Author: ian Date: Wed May 15 17:58:09 UTC 2019 New revision: 347627 URL: https://svnweb.freebsd.org/changeset/base/347627 Log: MFC r347422: Allow dcons(4) to be unloaded when loaded as a module. When the module is unloaded, the tty devices are destroyed. That requires implementing the tsw_free callback to avoid a panic. This driver requires no particular cleanup to be done from the callback, but the module itself must remain in memory until the deferred tsw_free callbacks are invoked. These changes implement that by incrementing a reference count variable in the detach routine, and decrementing it in the tsw_free callback. The MOD_UNLOAD event handler doesn't return until the count drops to zero. PR: 237758 Changes: _U stable/11/ stable/11/sys/dev/dcons/dcons_os.c