From owner-freebsd-threads@FreeBSD.ORG Mon Mar 2 16:52:39 2009 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79D7E1065674; Mon, 2 Mar 2009 16:52:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5129E8FC1C; Mon, 2 Mar 2009 16:52:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E1FC746B43; Mon, 2 Mar 2009 11:52:38 -0500 (EST) Date: Mon, 2 Mar 2009 16:52:38 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200903021111.32643.jhb@freebsd.org> Message-ID: References: <200903010956.n219uLdu083246@www.freebsd.org> <200903021111.32643.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Stephane Legrand , freebsd-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/132215: Crash after running ppp X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:52:40 -0000 On Mon, 2 Mar 2009, John Baldwin wrote: >> Unread portion of the kernel message buffer: >> Sleeping thread (tid 100053, pid 516) owns a non-sleepable lock >> panic: sleeping thread ... > Can you do something like this in kgdb: > > frame 5 > set $td = (struct thread *)(m->mtx_lock & ~3) > p $td->td_tid > > (This should print out a thread ID) > > thread $td->td_tid > where > > This should give you the stack trace of the misbehaving thread which slept > while holding a route lock. > > Also, this is a kernel bug, not a thread issue. Actually, just a stack trace of tid 100053/pid 516 should be sufficient. This is the second report I've had of a panic along these lines relating to ppp, and it seems likely to me that the fixes to routing locking have introduced an edge case where the routing code sleeps allocating or waiting for a route while holding a lock where it didn't happen previously. If we can work out the stack trace leading to the sleep, we can probably fix this in short order. Robert N M Watson Computer Laboratory University of Cambridge