Date: Fri, 5 Dec 2014 18:44:51 +1100 From: Jan Mikkelsen <janm@transactionware.com> To: FreeBSD Stable Mailing List <freebsd-stable@freebsd.org> Subject: 10.1 regression: process using serial port becomes unkillable when no modem control signals Message-ID: <F8A3069F-B662-46B8-85BF-2F0A7AE994E0@transactionware.com>
next in thread | raw e-mail | index | archive | help
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 =E2=80=9Cshutdown= -r=E2=80=9D 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=3D0xfffff80236e1a920, newtd=3D<value optimized = out>, flags=3D<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=3D260, newtd=3D0x0) 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=3D0xfffff8000c7344b8, pri=3D0) at = /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/subr_sleep= queue.c:426 #3 0xffffffff80976c1f in sleepq_wait_sig (wchan=3D0x0, pri=3D0) at = /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/subr_sleep= queue.c:631 #4 0xffffffff808e345a in _cv_wait_sig (cvp=3D0xfffff8000c7344b8, = lock=3D0xfffff8000c734408) at = /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_condv= ar.c:258 #5 0xffffffff809957a5 in ttydev_leave (tp=3D0xfffff8000c734400) at = /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/tty.c:1392= #6 0xffffffff80994d30 in ttydev_close (dev=3D<value optimized out>, = fflag=3D0, devtype=3D0, td=3D0x0) at = /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/tty.c:353 #7 0xffffffff8081ec63 in devfs_close (ap=3D0xfffffe0c541d57e0) 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=3D<value optimized out>, = a=3D<value optimized out>) at vnode_if.c:535 #9 0xffffffff809df673 in vn_close (vp=3D0xfffff80236a6f588, flags=3D3, = file_cred=3D0xfffff806a300b200, td=3D0xfffff80236e1a920) at = vnode_if.h:225 #10 0xffffffff809de4c8 in vn_closefile (fp=3D0xfffff8001243d9b0, = td=3D0xfffff80236e1a920) 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=3D0xfffff8001243d9b0, = td=3D0x0) at = /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/fs/devfs/devfs_= vnops.c:611 #12 0xffffffff808ed249 in _fdrop (fp=3D0xfffff8001243d9b0, td=3D0x0) at = file.h:343 #13 0xffffffff808ef9ae in closef (fp=3D<value optimized out>, td=3D<value = optimized out>) at = /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_descr= ip.c:2335 #14 0xffffffff808ef5c9 in fdescfree (td=3D0xfffff80236e1a920) at = /usr/home/janm/p4/freebsd-image-std-2014.2/FreeBSD/src/sys/kern/kern_descr= ip.c:2103 #15 0xffffffff808fb8fb in exit1 (td=3D0xfffff80236e1a920, rv=3D<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=3D0x0, uap=3D<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=3D0xfffff80236e1a920, = traced=3D0) at subr_syscall.c:134
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8A3069F-B662-46B8-85BF-2F0A7AE994E0>