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=0xc03db920, flags=8, > file=0xc0392734 "/usr/src/sys/kern/sys_generic.c", line=1191) > 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=0xc03d82a0, opts=0, > file=0xc03db920 " \202=À]'9À]'9À", line=1191) > ---Type <return> to continue, or q <return> to quit--- > at /usr/src/sys/kern/kern_mutex.c:337 > #14 0xc025955f in selwakeup (sip=0xc03d82a0) > at /usr/src/sys/kern/sys_generic.c:1191 > #15 0xc02638be in ptcwakeup (tp=0xc414f030, flag=-1069696736) > at /usr/src/sys/kern/tty_pty.c:327 > #16 0xc0263887 in ptsstart (tp=0x0) at /usr/src/sys/kern/tty_pty.c:316 > #17 0xc025f8bb in ttstart (tp=0x0) at /usr/src/sys/kern/tty.c:1459 > #18 0xc0261604 in tputchar (c=-1005260800, tp=0xc414f030) > at /usr/src/sys/kern/tty.c:2579 > #19 0xc0250f1b in putchar (c=10, arg=0xc044e74c) > at /usr/src/sys/kern/subr_prf.c:349 > #20 0xc025123d in kvprintf (fmt=0xc414f000 "", func=0xc0250eb0 <putchar>, > arg=0xc044e74c, radix=10, ap=0xc044e76c "") > at /usr/src/sys/kern/subr_prf.c:528 > #21 0xc0250e07 in printf (fmt=0x0) 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:863 ... 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
