Re: LOR during boot (if_sis.c/kbdmux.c - Giant after non-sleepable)

From: Maksim Yevmenkin <maksim.yevmenkin_at_gmail.com>
Date: Thu, 9 Oct 2008 16:49:01 -0700
On 10/8/08, Bruce Cran <bruce_at_cran.org.uk> wrote:
> During boot I pressed Scroll Lock at the wrong time and got a LOR.
> Switching between consoles became really slow once the system was running,
> taking a couple of seconds each time.
>  I'm running -current from a few days ago.
>
>  lock order reversal: (Giant after non-sleepable)
>  1st 0xc4283e84 sis0 (network driver) _at_
> /usr/src/sys/dev/sis/if_sis.c:2106
>  2nd 0xc0d0d430 Giant (Giant) _at_
> /usr/src/sys/dev/kbdmux/kbdmux.c:1103
>  KDB: stack backtrace:
> db_trace_self_wrapper(c0bc49d7,c3ee27f0,c0837e85,4,c0bc0367,...)
> at db_trace_self_wrapper+0x26
> kdb_backtrace(4,c0bc0367,c0b9b6f1,c411d1a0,c3ee2848,...)
> at kdb_backtrace+0x29
> _witness_debugger(c0bc728c,c0d0d430,c0be0869,c411d1a0,c0b9b6f1,...)
> at _witness_debugger+0x25
>  witness_checkorder(c0d0d430,9,c0b9b6f1,44f,0,...) at
> witness_checkorder+0x800
>  _mtx_lock_flags(c0d0d430,0,c0b9b6f1,44f,c4167d20,...) at
> _mtx_lock_flags+0xc4
> kbdmux_ioctl(c4221b00,40044b13,c3ee28c8,100202,7,...)
> at kbdmux_ioctl+0x76e
> update_kbd_state(c0bc0367,c0bbaf86,2,c44b08c0,c0c577a0,...)
> at update_kbd_state+0x44
>  sc_cnputc(c0c577a0,73,c3ee2a94,5,73,...) at sc_cnputc+0x39
>  cnputc(73,c3ee2a94,c3ee2944,c082a2a1,c0be63cd,...) at
> cnputc+0x5f
>  putcons(c0be63cd,c0bbaf86,1000001,c41d9d6d,c082a240,...)
> at putcons+0x17
>  putchar(73,c3ee2a94,c0d11900,1,c41d9d6f,...) at
> putchar+0x61
>  kvprintf(c0b668aa,c082a240,c3ee2a94,a,c3ee2ac0,...) at
> kvprintf+0xa27
>  printf(c0b668aa,c41d9d6c,0,c4283e00,c4283e00,...) at
> printf+0x4e
> device_print_prettyname(c4277c80,c4289800,c4283e00,c4283e00,c3ee2b24,...)
> at device_print_prettyname+0x4c
>  device_printf(c4277c80,c0bab5be,f4,0,c06da240,...) at
> device_printf+0x12
>  sis_initl(c4283e84,0,c0bab5a0,83a,80206910,...) at
> sis_initl+0x99d
>  sis_ioctl(c428cc00,80206910,c45ab740,628,c428cc00,...) at
> sis_ioctl+0xa8
> ifhwioctl(c44b08c0,c452122c,c0e4d6d0,c44b0964,c0e4d6d0,...)
> at ifhwioctl+0x3eb
> ifioctl(c4555ab8,80206910,c45ab740,c44b08c0,80206910,...)
> at ifioctl+0x305
> soo_ioctl(c449f3b8,80206910,c45ab740,c4169400,c44b08c0,...)
> at soo_ioctl+0x397
>  kern_ioctl(c44b08c0,5,80206910,c45ab740,8318c0,...) at
> kern_ioctl+0x1dd
>  ioctl(c44b08c0,c3ee2cf8,c,c0bf8ba3,c0c9b110,...) at
> ioctl+0x134
>  syscall(c3ee2d38) at syscall+0x2a3
>  Xint0x80_syscall() at Xint0x80_syscall+0x20
>  --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281a9a23, esp = 0xbfbfe5bc,
> ebp = 0xbfbfe618 ---

well, this particular lor is caused by the fact that sc_cnputc() wants
to muck around kbd state. i do not know syscons code very well, but
this looks rather strange to me. i really do not know why the function
that really should just put a char on screen wants to do something
with kbd. i see the code tries to deal with scroll lock, so that is
consistent with your report.

kbdmux was recently changed to use Giant based locking (as an attempt
to work around other problems). when update_kbd_state() uses ioctl()
on kbd device, kbdmux will try to grab Giant. the whole thing was
started by device_printf() that is called from sis_initl() with
another mutex held.

so, to me, sc_cnputc() is broken and should be fixed.

thanks,
max
Received on Thu Oct 09 2008 - 21:49:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC