From owner-freebsd-bugs@FreeBSD.ORG Mon Mar 26 14:00:24 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9775106564A for ; Mon, 26 Mar 2012 14:00:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9708FC08 for ; Mon, 26 Mar 2012 14:00:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2QE0OxX083135 for ; Mon, 26 Mar 2012 14:00:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2QE0O6n083124; Mon, 26 Mar 2012 14:00:24 GMT (envelope-from gnats) Date: Mon, 26 Mar 2012 14:00:24 GMT Message-Id: <201203261400.q2QE0O6n083124@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Konstantin Belousov Cc: Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Konstantin Belousov List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:00:24 -0000 The following reply was made to PR kern/166340; it has been noted by GNATS. From: Konstantin Belousov To: Christian Esken Cc: bug-followup@freebsd.org, avg@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Mon, 26 Mar 2012 16:51:42 +0300 Thank you for the data. Semi-obviously, the callout_stop() call in sleepq_check_timeout() have to return 0, otherwise we would not call mi_switch() there. But I do not see how this can happen, because the callout state, printed from kgdb, still indicates that callout is pending. Callout cannot be reset while in sleepq code. So there are two possible routes to go forward: preferrable is for you to extract the self-contained C program that would illustrate the issue and send this sample to me. Second is to recompile your kernel with INVARIANTS/WITNESS and possibly KTR and see what happen.