Re: kern/51877: carp related panic during shutdown

[Hauke Fath <hf%spg.tu-darmstadt.de@localhost>]

The following reply was made to PR kern/51877; it has been noted by GNATS.

From: Hauke Fath <hf%spg.tu-darmstadt.de@localhost>
To: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
Cc: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>,
        kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
Subject: Re: kern/51877: carp related panic during shutdown
Date: Tue, 17 Jan 2017 09:00:26 +0100

 On Tue, 17 Jan 2017 13:41:01 +0900, Ryota Ozaki wrote:
 >> Skipping crash dump on recursive panic
 >> panic: LOCKDEBUG: Mutex error: lockdebug_barrier: spin lock held
 > 
 > The mutex error happened because uvm_fault_internal tries to hold
 > a rwlock with holding a spin mutex. Can you identify the spin mutex
 > by dissembling the kernel? The addresses above such as "last locked"
 > will help to explore.
 
 Before I am off to work - that would be gdb? ddb? Do I need 
 
 makeoptions    DEBUG="-g"
 
 for that?
 
 [...]
 >> mutex_enter() at netbsd:mutex_enter+0x36c
 > 
 > I don't know why a fault happens inside mutex_enter. It's a global
 > adaptive mutex that is never destroyed and stable. And the fault
 > happened on a different place from the fault of the first report.
 > Something broken around the mutex...?
 > 
 > Just in case could you clean-build tools and the kernel and try again?
 
 Sure, will do.
 
 > If it doesn't help could you comment out rt_update_wait in _rt_free
 > and try?
 
 Before I try and err... which source file are we talking about?
 
 > Actually rt_update_wait isn't needed if !NET_MPSAFE for now.
 
 Cheerio,
 hauke