From owner-freebsd-current@FreeBSD.ORG Thu Oct 18 18:22:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F09A16A41A for ; Thu, 18 Oct 2007 18:22:44 +0000 (UTC) (envelope-from stadtkind2@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 5DC5B13C44B for ; Thu, 18 Oct 2007 18:22:43 +0000 (UTC) (envelope-from stadtkind2@gmx.de) Received: (qmail invoked by alias); 18 Oct 2007 17:56:02 -0000 Received: from f051119064.adsl.alicedsl.de (EHLO [192.168.0.2]) [78.51.119.64] by mail.gmx.net (mp047) with SMTP; 18 Oct 2007 19:56:02 +0200 X-Authenticated: #42330871 X-Provags-ID: V01U2FsdGVkX19NadU+OblNgULaKGVT68HH26J3J4WlioGUBlvNMa ocAkTWQzkbvr3B Message-ID: <47179E29.40705@gmx.de> Date: Thu, 18 Oct 2007 17:55:53 +0000 From: =?ISO-8859-1?Q?Stefan_Kr=FCger?= User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Thu, 18 Oct 2007 18:46:01 +0000 Subject: Re: 7.0 CURRENT, need help with panic: Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 18:22:44 -0000 Robert Watson wrote: > The bug in ipfilter has to do with using a sleepable lock class in an > interrupt or a software interrupt thread. This can lead to deadlocks, > although is relatively unlikely to do so, so is reported by invariants > testing as a fatal condition. The panic won't turn up without > invariants enabled, and in practice the deadlock is quite unlikely, but > reflects a violation of the assumptions under which kernel > synchronization is designed to work. Switching to a non-sleepable lock > class doesn't provide an instant solution because the non-sleepable lock > will then be held over a potentially sleepable path for managing the > firewall from user space (if a copyin/copyout results in a page fault > that sleeps waiting on disk I/O, or worse, network I/O from > network-backed swap, which could lead directly to the deadlock). > Chances are, this is relatively easy to fix, but someone needs to do > that -- ideally someone very familiar with ipfilter. :-) this someone could take a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=117182 (FreeBSD 7.0-PRERELEASE w/ ipfilter, sleeping thread panic)