Re: LOCKDEBUG panic in serial tty code

[Andrew Doran <ad%netbsd.org@localhost>]

Hi,

On Tue, Jun 03, 2008 at 12:29:57PM +0200, Hauke Fath wrote:

> Condition variable error: lockdebug_wakeup: interlocking mutex not held 
> during wakeup
> 
> lock address : 0x000000000aa847a0 type     :               spin
> initialized  : 0x00000000001c0138 interlock: 0x00000000003536c0
> 
> panic: LOCKDEBUG
> Stopped in pid 0.6 (system) at  netbsd:cpu_Debugger+0x6: unlk a6
> db> t
> cpu_Debugger(2000,2001,a9adc1c,aa30e8c,aa30e9c) + 6
> panic(2be5f7,aa847a0,2000,a9adc1c,aa84708) + 172
> lockdebug_abort1(a9adc1c,2000,2be882,2be735,1) + 92
> lockdebug_wakeup(aa847a0,1c0ffe) + aa
> cv_broadcast(aa847a0,d06100,aa30f0c,265b9e,aa84708) + 1a
> ttypull(aa84708) + 18
> zsstart(aa84708) + 52
> ttstart(aa84708,cb4020) + 12
> zstty_softint1(cb400c) + 2ae
> zstty_softint(cb400c,a084fa8,2d2000,aa23308,aa30fa8) + 8
> zsc_intr_soft(cb4000,aa230f8,2dd501,1800be,3e9ec0) + 32
> softint_thread(aa230f8) + 9c
> lwp_trampoline() + e
> db>
> 
> Any pointers?

It's due to the new assertions that were added for condition variables. In this
case the system will operate fine, but it is a real bug in the tty code.

I'm going through the all the tty drivers at the moment and completing the
locking that we started ~5 years ago. It will take a few more days because
it's a lot of code to go through..

Thanks,
Andrew