Jan Mikkelsen
2014-Dec-05 07:44 UTC
10.1 regression: process using serial port becomes unkillable when no modem control signals
Hi, I have just found this problem on a machine upgraded to 10.1. When running mgetty on a serial port with nothing connected and then killing it the process becomes unkillable. This prevents ?shutdown -r? from completing, which is particularly annoying. Giving the serial port a device which provides the right modem control signals lets the process exit immediately. The same hardware with 9.3 was fine. Below is the kernel stack trace on the unkillable process. Does this ring any bells for anyone? Thanks, Jan Mikkelsen (kgdb) bt #0 sched_switch (td=0xfffff80236e1a920, newtd=<value optimized out>, flags=<value optimized out>) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/sched_ule.c:1945 #1 0xffffffff80939ba1 in mi_switch (flags=260, newtd=0x0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_synch.c:494 #2 0xffffffff80976d6b in sleepq_catch_signals (wchan=0xfffff8000c7344b8, pri=0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/subr_sleepqueue.c:426 #3 0xffffffff80976c1f in sleepq_wait_sig (wchan=0x0, pri=0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/subr_sleepqueue.c:631 #4 0xffffffff808e345a in _cv_wait_sig (cvp=0xfffff8000c7344b8, lock=0xfffff8000c734408) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_condvar.c:258 #5 0xffffffff809957a5 in ttydev_leave (tp=0xfffff8000c734400) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/tty.c:1392 #6 0xffffffff80994d30 in ttydev_close (dev=<value optimized out>, fflag=0, devtype=0, td=0x0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/tty.c:353 #7 0xffffffff8081ec63 in devfs_close (ap=0xfffffe0c541d57e0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/fs/devfs/devfs_vnops.c:592 #8 0xffffffff80e6d281 in VOP_CLOSE_APV (vop=<value optimized out>, a=<value optimized out>) at vnode_if.c:535 #9 0xffffffff809df673 in vn_close (vp=0xfffff80236a6f588, flags=3, file_cred=0xfffff806a300b200, td=0xfffff80236e1a920) at vnode_if.h:225 #10 0xffffffff809de4c8 in vn_closefile (fp=0xfffff8001243d9b0, td=0xfffff80236e1a920) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/vfs_vnops.c:1557 #11 0xffffffff808204bc in devfs_close_f (fp=0xfffff8001243d9b0, td=0x0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/fs/devfs/devfs_vnops.c:611 #12 0xffffffff808ed249 in _fdrop (fp=0xfffff8001243d9b0, td=0x0) at file.h:343 #13 0xffffffff808ef9ae in closef (fp=<value optimized out>, td=<value optimized out>) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_descrip.c:2335 #14 0xffffffff808ef5c9 in fdescfree (td=0xfffff80236e1a920) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_descrip.c:2103 #15 0xffffffff808fb8fb in exit1 (td=0xfffff80236e1a920, rv=<value optimized out>) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_exit.c:329 #16 0xffffffff808fb37e in sys_sys_exit (td=0x0, uap=<value optimized out>) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_exit.c:153 #17 0xffffffff80d4f521 in amd64_syscall (td=0xfffff80236e1a920, traced=0) at subr_syscall.c:134
Konstantin Belousov
2014-Dec-05 09:57 UTC
10.1 regression: process using serial port becomes unkillable when no modem control signals
On Fri, Dec 05, 2014 at 06:44:51PM +1100, Jan Mikkelsen wrote:> Hi, > > I have just found this problem on a machine upgraded to 10.1. > > When running mgetty on a serial port with nothing connected and then killing it the process becomes unkillable. This prevents ???shutdown -r??? from completing, which is particularly annoying. > > Giving the serial port a device which provides the right modem control signals lets the process exit immediately. The same hardware with 9.3 was fine. > > Below is the kernel stack trace on the unkillable process. > > Does this ring any bells for anyone?This sounds as something that might be fixed by r272786 and r272789 in HEAD. I did not looked into details too close. The changes are not in stable/10, apply manually and test.> > Thanks, > > Jan Mikkelsen > > (kgdb) bt > #0 sched_switch (td=0xfffff80236e1a920, newtd=<value optimized out>, flags=<value optimized out>) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/sched_ule.c:1945 > #1 0xffffffff80939ba1 in mi_switch (flags=260, newtd=0x0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_synch.c:494 > #2 0xffffffff80976d6b in sleepq_catch_signals (wchan=0xfffff8000c7344b8, pri=0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/subr_sleepqueue.c:426 > #3 0xffffffff80976c1f in sleepq_wait_sig (wchan=0x0, pri=0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/subr_sleepqueue.c:631 > #4 0xffffffff808e345a in _cv_wait_sig (cvp=0xfffff8000c7344b8, lock=0xfffff8000c734408) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_condvar.c:258 > #5 0xffffffff809957a5 in ttydev_leave (tp=0xfffff8000c734400) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/tty.c:1392 > #6 0xffffffff80994d30 in ttydev_close (dev=<value optimized out>, fflag=0, devtype=0, td=0x0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/tty.c:353 > #7 0xffffffff8081ec63 in devfs_close (ap=0xfffffe0c541d57e0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/fs/devfs/devfs_vnops.c:592 > #8 0xffffffff80e6d281 in VOP_CLOSE_APV (vop=<value optimized out>, a=<value optimized out>) at vnode_if.c:535 > #9 0xffffffff809df673 in vn_close (vp=0xfffff80236a6f588, flags=3, file_cred=0xfffff806a300b200, td=0xfffff80236e1a920) at vnode_if.h:225 > #10 0xffffffff809de4c8 in vn_closefile (fp=0xfffff8001243d9b0, td=0xfffff80236e1a920) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/vfs_vnops.c:1557 > #11 0xffffffff808204bc in devfs_close_f (fp=0xfffff8001243d9b0, td=0x0) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/fs/devfs/devfs_vnops.c:611 > #12 0xffffffff808ed249 in _fdrop (fp=0xfffff8001243d9b0, td=0x0) at file.h:343 > #13 0xffffffff808ef9ae in closef (fp=<value optimized out>, td=<value optimized out>) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_descrip.c:2335 > #14 0xffffffff808ef5c9 in fdescfree (td=0xfffff80236e1a920) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_descrip.c:2103 > #15 0xffffffff808fb8fb in exit1 (td=0xfffff80236e1a920, rv=<value optimized out>) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_exit.c:329 > #16 0xffffffff808fb37e in sys_sys_exit (td=0x0, uap=<value optimized out>) at /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_exit.c:153 > #17 0xffffffff80d4f521 in amd64_syscall (td=0xfffff80236e1a920, traced=0) at subr_syscall.c:134 > > > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"