Date: Fri, 7 Mar 2003 04:06:59 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Maxim Konovalov <maxim@macomnet.ru> Cc: current@FreeBSD.ORG, <jhb@FreeBSD.ORG> Subject: Re: "blockable sleep lock" panic in latest -current. Message-ID: <20030307035011.I2362-100000@gamplex.bde.org> In-Reply-To: <20030306184626.A22859@news1.macomnet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Mar 2003, Maxim Konovalov wrote: > Several identical kernel panics with today -current. I suspect recent > commits to subr_witness.c. See an attachment for details. This seems to be most from a double fault triggering a cascade of errors. There is no frame for the double fault so the critical information is not shown in the trace. > panic: blockable sleep lock (sleep mutex) sellck @ /usr/src/sys/kern/sys_= generic.c:1191 This is the usual panic from sync() in panic() tripping over a lock. Calling sync() in panic was never safe and now usually fails. > #11 0xc0236143 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 > #12 0xc0255837 in witness_lock (lock=3D0xc03db920, flags=3D8, > file=3D0xc0392734 "/usr/src/sys/kern/sys_generic.c", line=3D1191) > at /usr/src/sys/kern/subr_witness.c:552 This seems to be usual panic from using TIOCCONS. TIOCCONS was never safe and now causes locking violations if printf(9) is called with certain locks held. > #13 0xc022d1f3 in _mtx_lock_flags (m=3D0xc03d82a0, opts=3D0, > file=3D0xc03db920 "=A0\202=3D=C0]'9=C0]'9=C0", line=3D1191) > ---Type <return> to continue, or q <return> to quit--- > at /usr/src/sys/kern/kern_mutex.c:337 > #14 0xc025955f in selwakeup (sip=3D0xc03d82a0) > at /usr/src/sys/kern/sys_generic.c:1191 > #15 0xc02638be in ptcwakeup (tp=3D0xc414f030, flag=3D-1069696736) > at /usr/src/sys/kern/tty_pty.c:327 > #16 0xc0263887 in ptsstart (tp=3D0x0) at /usr/src/sys/kern/tty_pty.c:316 > #17 0xc025f8bb in ttstart (tp=3D0x0) at /usr/src/sys/kern/tty.c:1459 > #18 0xc0261604 in tputchar (c=3D-1005260800, tp=3D0xc414f030) > at /usr/src/sys/kern/tty.c:2579 > #19 0xc0250f1b in putchar (c=3D10, arg=3D0xc044e74c) > at /usr/src/sys/kern/subr_prf.c:349 > #20 0xc025123d in kvprintf (fmt=3D0xc414f000 "", func=3D0xc0250eb0 <putch= ar>, > arg=3D0xc044e74c, radix=3D10, ap=3D0xc044e76c "") > at /usr/src/sys/kern/subr_prf.c:528 > #21 0xc0250e07 in printf (fmt=3D0x0) at /usr/src/sys/kern/subr_prf.c:305 This shows how printf(9) fails. It wanders into the pty driver. The pty driver is highly non-reentrant, but printf(9) needs to work when called from an abitrary context ... > #22 0xc03522b2 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:86= 3 =2E.. the double fault context is especially arbitrary. Something caused a double fault, but neither ddb nor kgdb understands backtracing from double faults. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030307035011.I2362-100000>