Hi,

I had the below panic just now:

panic: kernel diagnostic assertion "mutex_owned(&tty_lock)" failed: file "/home/plunky/src/sys/kern/tty_pty.c", line 476
Stopped in pid 445.1 (pppd) at	netbsd:breakpoint+0x1:	ret
db> bt
breakpoint(c0a3a05c,c098b725,c09d1267,c09d1684,1dc) at netbsd:breakpoint+0x1
__kernassert(c098b725,c09d1684,1dc,c09d1267,ca40d000) at netbsd:__kernassert+0x39
ptsstart(ca40d000,c10a144a,5,0,3) at netbsd:ptsstart+0xae
pppstart(ca40d000,c10a1400,ffffffff,0,c11a392c) at netbsd:pppstart+0x24
pppasyncstart(c14f4000,fff2,c12208c8,c12208c8,2000) at netbsd:pppasyncstart+0x657
pppintr(c14f4000,330,3,0,c010102f) at netbsd:pppintr+0x54
softintr_dispatch(1,cbd0ba30,0,uvm_fault(0xc0acd5a0, 0xcabfa000, 1) -> 0xe
kernel: supervisor trap page fault, code=0
Faulted in DDB; continuing...

when setting up PPP over bluetooth, sources as of monday
(GENERIC+DIAGNOSTIC)

I'm guessing pppstart needs to apply use of tty_lock but I'm not sure how
extensive that ought to be..  the below works

--- /usr/src/sys/net/ppp_tty.c	2007-11-26 21:10:59.000000000 +0000
+++ ppp_tty.c	2007-11-28 21:31:11.000000000 +0000
@@ -912,8 +912,10 @@
      * If there is stuff in the output queue, send it now.
      * We are being called in lieu of ttstart and must do what it would.
      */
+    mutex_spin_enter(&tty_lock);
     if (tp->t_oproc != NULL)
 	(*tp->t_oproc)(tp);
+    mutex_spin_exit(&tty_lock);

     /*
      * If the transmit queue has drained and the tty has not hung up

but is it enough - Andrew?

iain