Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Apr 2018 09:11:38 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Eitan Adler <lists@eitanadler.com>, "hackers@freebsd.org" <hackers@freebsd.org>
Subject:   Re: panic: deadlkres: possible deadlock detected for 0xfffff80141b04560, blocked for 1801695 ticks
Message-ID:  <33e482b2-ee50-bd72-51d6-bb320cc95b82@FreeBSD.org>
In-Reply-To: <CAF6rxgmF_aOx-R7nZ%2B6-N70jwtH8pgHXPK3WovHS2V5Aed0qwA@mail.gmail.com>
References:  <CAF6rxgmF_aOx-R7nZ%2B6-N70jwtH8pgHXPK3WovHS2V5Aed0qwA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/04/2018 07:00, Eitan Adler wrote:
> How to reproduce?
> 
> # kldload sem
> # kldunload sem
> < wait debug.deadlkres.slptime_threshold seconds >
> 
> https://reviews.freebsd.org/P168
> Reading symbols from ./kernel/kernel...Reading symbols from
> /usr/home/eax/crashes/sem_load_dklres/kernel/kernel.debug...done.
> done.
> 
> Unread portion of the kernel message buffer:
> [29474] panic: deadlkres: possible deadlock detected for
> 0xfffff80141b04560, blocked for 1801695 ticks

The debugging information you provided does not help.
You need to do
(gdb) p *(struct thread*)0xfffff80141b04560  <=== taken from the panic message
find td_tid value and then do
(gdb) tid <td_tid>
And then examine that thread.

I guess that the deadlkres could be enhanced to print the tid and the stack
trace of the deadlocked thread, so that it is faster to get started.


-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33e482b2-ee50-bd72-51d6-bb320cc95b82>