[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 <ozaki-r%netbsd.org@localhost>
To: Hauke Fath <hf%spg.tu-darmstadt.de@localhost>
Cc: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>, kern-bug-people%netbsd.org@localhost,
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 <hf%spg.tu-darmstadt.de@localhost> 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:
./build.sh ... 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?
Main Index |
Thread Index |