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

Maksim Yevmenkin maksim.yevmenkin at gmail.com
Thu Oct 9 23:49:03 UTC 2008


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) @
> /usr/src/sys/dev/sis/if_sis.c:2106
>  2nd 0xc0d0d430 Giant (Giant) @
> /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


More information about the freebsd-current mailing list