From owner-freebsd-current Sun Jul 1 10:47:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2623E37B403 for ; Sun, 1 Jul 2001 10:47:28 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA29958; Mon, 2 Jul 2001 03:47:17 +1000 Date: Mon, 2 Jul 2001 03:45:19 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dag-Erling Smorgrav Cc: current@FreeBSD.ORG Subject: Re: blockable sleep lock panic (and dumps still don't work) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 1 Jul 2001, Dag-Erling Smorgrav wrote: > "microuptime() went backwards" warning caused a "blockable sleep lock" > panic on a June 25 kernel: > > panic: blockable sleep lock (sx) allproc @ ../../kern/kern_proc.c:146 > Debugger("panic") > Stopped at Debugger+0x44: pushl %ebx > db> trace > ... > tputchar(6d,c2ad1620) at tputchar+0x35 > putchar(6d,dc3aeeb4) at putchar+0x4f > kvprintf(c02c7701,c01c3624,dc3aeeb4,a,dc3aeecc) at kvprintf+0x8e > printf(c02c7700,6949e,93dc1,6949e,d696a092) at printf+0x44 > Debugger(c02c7cfb) at Debugger+0x44 > panic(c02cb140,c02c8500,c02c71a3,c02c7283,92) at panic+0x70 > witness_lock(c038ad60,0,c02c7283,92) at witness_lock+0x22e > _sx_slock(c038ad60,c02c7283,92,c2ad1604,c2ad1620) at _sx_slock+0x128 > pfind(1ca,c2ad1600,c2ad1620,dc3aeda8,c01d94a7) at pfind+0x1c > selwakeup(c2ad1604,c2ad1620,6d,dc3aeeb4,dc3aedb8) at selwakeup+0x35 > ptcwakeup(c2ad1620,1,dc3aedc4,c01d68ac,c2ad1620) at ptcwakeup+0x23 > ptsstart(c2ad1620,dc3aede0,c01d7fa5,c2ad1620,6d) at ptsstart+0x26 > ttstart(c2ad1620,6d,c2ad1620,7,c2ad1620) at ttstart+0x18 > tputchar(6d,c2ad1620) at tputchar+0x35 This has something to do with the TIOCCONS ioctl. tputchar() is the output function for the TOTTY case, and the TOTTY flag is only set for kernel printfs if TIOCCONS has set constty to non-NULL. I'm not sure what uses TIOCCONS (I think it is intended for use with X, but it doesn't seem to be used on my systems). TIOCCONS is almost unimplementable (printing to a terminal is not reentrant enough to work in all contexts, and is supposed to be protected by spltty(), but kernel printfs must work in all contexts), so the correct fix may be to remove it. TIOCCONS is broken in all versions of FreeBSD. The brokenness is just more obvious now that there are more locks to trip over. The output function for the TOLOG case (i.e., msglogchar()) also seems to be broken in all versions of FreeBSD. It operates on the circular message buffer, but doesn't have any locking. The output function for the TOCONS case (i.e., cnputc()) is also problematic. Only the serial console output routine even attempts to be reentrant, and (per-cpu) reentrancy is not enough under SMP. Syscons' output routine was easy to panic by mixing kernel printfs with user-mode output the last time I checked. > putchar(6d,dc3aeeb4) at putchar+0x4f > kvprintf(c02c7701,c01c3624,dc3aeeb4,a,dc3aeecc) at kvprintf+0x8e > printf(c02c7700,6949e,93dc1,6949e,d696a092) at printf+0x44 > calcru(dc3abc80,dc3adb74,dc3adb7c,0) at calcru+0x12b > getrusage(dc3abc80,dc3aef80,8332e78,84c4000,8505) at getrusage+0x112 > syscall(2f,2f,2f,8505,84c4000) at syscall+0x8d5 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > --- syscall (117, FreeBSD ELF, getrusage), eip = 0x8247269, esp = 0x8517720, ebp = 0x8517730 --- > ... > dumping to dev ad1b, offset 7340064 > dump ata1: resetting devices .. ad1: invalidating queued requests > panic: mutex sched lock recursed at ../../kern/kern_synch.c:826 Apparently addump() depends on too much infrastructure. A panic may occur at any time, so dump routines face much the same locking problems as console output routines. They can't go near normal locks like sched_lock, since they need to work when such locks are in any state. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message