tty panic in current

[David Holland <dholland+netbsd%eecs.harvard.edu@localhost>]

Logging into one of my shell accounts from the console kills -current;
the problem appears to be that the account in question still does
tset(1). This causes the following trace fragment:

   ttyinput()
   wsdisplay_emulinput()
   wsemul_vt100_handle_csi()
   wsemul_vt100_output_csi()
   wsemul_vt100_output()
   wsdisplaystart()
   ttstart()
   ttwrite()

The problem then is that ttstart is called holding tty_lock, and
ttyinput gets tty_lock.

This appears to be fallout from one of the earlier vmlocking merges a
couple months ago and to have been lurking since.

The (mostly) full panic follows for reference:

   ------

Mutex error: lockdebug_wantlock: locking against myself

lock address : 0xffffffff805fdc08 type     :               spin
shared holds :                  0 exclusive:                  1
shares wanted:                  0 exclusive:                  1
current cpu  :                  0 last held:                  0
current lwp  : 0xffff80004e3e5360 last held: 0xffff80004e3e5360
last locked  : 0xffffffff8028de37 unlocked : 0xffffffff8028ddb5
initialized  : 0xffffffff8028af2a
owner field  : 0x0000000000010500 wait/spin:                0/1

panic: LOCKDEBUG
Stopped in pid 18285.1 (slogin) at     netbsd:breakpoint+0x1: ret
db{0}> bt
breakpoint() at [...]
lockdebug_abort1() at [...]
lockdebug_wantlock() at [...]
mutex_vector_enter() at [...]
ttyinput() at netbsd:ttyinput+0x32
wsdisplay_emulinput() at netbsd:wsdisplay_emulinput+0x58
wsemul_vt100_handle_csi() at [...]
wsemul_vt100_output_csi() at [...]
wsemul_vt100_output() at [...]
wsdisplaystart() at [...]
ttstart() at [...]
ttwrite() at [...]
cdev_write() at [...]
spec_write() at [...]
VOP_WRITE() at [...]
vn_write() at [...]
dofilewrite() at [...]
sys_write() at [...]
syscall() at [...]

-- 
   - David A. Holland / dholland+netbsd%eecs.harvard.edu@localhost