From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 06:12:39 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E55C16A41F for ; Thu, 22 Dec 2005 06:12:39 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3F5343D5C for ; Thu, 22 Dec 2005 06:12:37 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.198] ([10.0.0.198]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jBM6CZiE027707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2005 22:12:36 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43AA4415.8070300@errno.com> Date: Wed, 21 Dec 2005 22:13:41 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi References: <20051221191919.GB17950@webcom.it> <43A9B5EA.8030905@errno.com> <20051221215457.GE17950@webcom.it> In-Reply-To: <20051221215457.GE17950@webcom.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrea Campi , current@freebsd.org Subject: Re: Panic and LOR on -CURRENT with ath 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, 22 Dec 2005 06:12:39 -0000 Andrea Campi wrote: > Sam, > > On Wed, Dec 21, 2005 at 12:07:06PM -0800, Sam Leffler wrote: > >>This is a driver lock held across an ioctl that does copyout and the >>destination faults. I've tried to get people to buy into a solution to >>the general problem w/o luck. > > > Does this only need someone to sit down and code a solution, or is that > a broader and not only technical issue? It's a design issue with implications. The net80211 ioctl code is typically invoked from drivers w/ the driver lock held to guard against changes in state used by code that is invoked from an interrupt thread. But once inside net80211 there's no way to release the lock around calls like copyout. I've suggested exposing the driver lock to the net80211 layer so it can unlock+relock but gotten zero response so the problem remains. A concern is whether doing this forces driver locking into a particular model that is undesirable. This issue is really caused by the confusion in drivers over who is responsible for locking net80211 state. The net80211 layer handles the major pieces itself but some small bits are still implicitly handled by single-threading the rx path. Drivers that use the driver lock on the rx path must thus hold it over ioctl; other drivers do not except they cannot tell if an ioctl interacts with the rx path. > > >>It appears the mbuf was reclaimed while sitting on the tx queue waiting >>to be reaped. I've seen a few complaints of this sort but never enough >>info to start looking. This problem seems to be common to soekris h/w >>or perhaps this general config which is common on soekris h/w. Knowing >>the configuration might be useful; e.g. bridged config? what packet >>filter package? network setup? > > > Nope, no bridging; this is nanobsd with a GENERIC kernel minus a lot of > stuff plus ipfw (which I also use for NAT). Nothing fancy really. It's > not even under any high load. > > Is there anything I can investigate from DDB? The info you want is gone by the time the crash happens. Last time I chased a similar problem I did some private hacks to write-protect mbufs to catch unexpected modification. You might try removing ipfw or using an alternate packet filter if that's feasible. I wouldn't be surprised if this is related to ipfw and/or divert sockets. Sam