NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/51877: carp related panic during shutdown

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

From: Ryota Ozaki <>
To: Hauke Fath <>
Cc: "" <>,,
Subject: Re: kern/51877: carp related panic during shutdown
Date: Tue, 17 Jan 2017 17:44:04 +0900

 On Tue, Jan 17, 2017 at 5:00 PM, Hauke Fath <> wrote:
 > 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?
 The option isn't required.
 Without that, you can explore by something like this:
   objdump -d netbsd |grep -30 ffffffff8044b97a
 If you want to see with the source code:
   ./ ... kernel.gdb=NFIFI  # without -u
   objdump -S -d netbsd.gdb |grep -30 ffffffff8044b97a  # 30 may not be enough
 > [...]
 >>> 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?
 sys/net/route.c is.

Home | Main Index | Thread Index | Old Index