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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
