[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: 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>,
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
>> 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.
Main Index |
Thread Index |