Bug #2148

DFBSD v2.13.0.38.g09a36 - Switch to TTY panic

Added by tuxillo over 6 years ago. Updated over 6 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



Panic when switching to other tty (Alt+Fx):

panic: lockmgr kbdmux from /home/source/dfbsd/sys/dev/misc/kbd/kbdsw.c:199:
called with 1 spinlocks held
cpuid = 3
Trace beginning at frame 0xffffffe05ba746e8
panic() at panic+0x1ed
panic() at panic+0x1ed
debuglockmgr() at debuglockmgr+0xab
kbd_ioctl() at kbd_ioctl+0x62
save_kbd_state() at save_kbd_state+0x22
exchange_scr() at exchange_scr+0x4e
sc_switch_scr() at sc_switch_scr+0x38f
scioctl() at scioctl+0xcfc
dev_dioctl() at dev_dioctl+0x56
devfs_fo_ioctl() at devfs_fo_ioctl+0x125
fo_ioctl() at fo_ioctl+0x46
mapped_ioctl() at mapped_ioctl+0x498
sys_ioctl() at sys_ioctl+0x1c
syscallpending() at 0x47f1d8
gd_ipending() at 0x42a6be
gd_ipending() at

No coredump no nothing, trying to get some more info right now.

Antonio Huete


#1 Updated by sjg over 6 years ago

<@tuxillo> I still don't understand why sc_switch_scr() needs to be called locked
<@thesjg_> for accesses to sc probably
<@tuxillo> thesjg_: so that the values that it checks doesn't change in the mean time?=
<@tuxillo> like saying, instead of locking/unlocking in a bunch of places inside sc_switch_scr(), I rather
lock the whole thing
<@thesjg_> if that's the case.. you can't unlock until around save_kbd_state() in exchange_scr(), but i'm
not sure its protecting that
<@tuxillo> is that right?
<@thesjg_> not even then
<@thesjg_> you need to figure out what the lock is protecting for sure
<@thesjg_> then you can figure out what to do about it
<@tuxillo> yah true
<@tuxillo> thesjg_: gonna see where it is used to try to find out why
<@thesjg_> it certainly looks like its protecting accesses to the softc
<@thesjg_> yeah, it is
<@tuxillo> hmm
<@thesjg_> so, you need to call kbd_ioctl() without the lock held, but you have two problems there
<@thesjg_> save_kbd_state() (maybe update_kbd_state() too) is called with the lock held sometimes, you know
that, but you can't just unlock unconditionally until you confirm that it is always called with the lock
<@thesjg_> if its sometimes called with the lock held, sometimes not, you have to sort that out
<@thesjg_> also, it passes an argument contained in the protected softc into the ioctl, you need to sort
that out
<aggelos> thesjg_: back to the freebsd 5.x days? :P
<@thesjg_> (make a copy of that member of the softc structure, call the ioctl, copy it back into the
structure after you re-acquire the lock on return?)
<@thesjg_> aggelos: looks that way
<@thesjg_> i'm not sure if the ioctl modifies the arg or just needs it for reference, so you'll have to
figure that out
<@thesjg_> tuxillo: armed that with info, you should be able to come up with a fix w/o too much pain
<aggelos> ok, time to reboot into kubuntu 11.10 :/
<@thesjg_> can't help, must sleep :)

^-- for posterity

#2 Updated by tuxillo over 6 years ago

From what I've seen in the syscons code, save_kbd_state() and update_kbd_state()
are never called with the lock held.

Furthermore, in the console path functions, specifically in sccnputc() I've
found this:

scp->status &= ~SLKED;
#if 0
/* This can block, illegal in the console path */
update_kbd_state(scp, scp->status, SLKED);

#3 Updated by tuxillo over 6 years ago


As you already know what's passed to the ioctl is struct keyboard kbd from the

For both atkbd and ukbd that struct's private data (kb_data) is modified. One
thing to note is that for both the ioctl function is entirely under a critical

Antonio Huete

#4 Updated by tuxillo over 6 years ago

Fixed in f6ce8b1945431efc69d4d9b9b02f73af98edbe53

Also available in: Atom PDF