From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 12 05:50:13 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C94C106566C for ; Mon, 12 Mar 2012 05:50:13 +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 083D48FC0C for ; Mon, 12 Mar 2012 05:50:13 +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 q2C5oCgZ043738 for ; Mon, 12 Mar 2012 05:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2C5oCnR043737; Mon, 12 Mar 2012 05:50:12 GMT (envelope-from gnats) Date: Mon, 12 Mar 2012 05:50:12 GMT Message-Id: <201203120550.q2C5oCnR043737@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Joel Dahl Cc: Subject: Re: kern/163318: [ath] ath(4) stops working X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joel Dahl List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 05:50:13 -0000 The following reply was made to PR kern/163318; it has been noted by GNATS. From: Joel Dahl To: Adrian Chadd Cc: bug-followup@freebsd.org Subject: Re: kern/163318: [ath] ath(4) stops working Date: Mon, 12 Mar 2012 06:44:12 +0100 On 11-03-2012 13:45, Adrian Chadd wrote: > On 11 March 2012 13:13, Joel Dahl wrote: > > >> Nope. That just started shifting around locks. Can you please try > >> 231852 with the debugging patch I threw you (that patched > >> ieee80211_scan.c) and see if it complains? > > > > Sure, I'll try 231852 + your patch. > > > >> If that patch fixed anything, it just delayed things enough to hide > >> what's going on... > > > > I see. Hiding a problem is not equal to fixing it. :-) > > Yup. The main thing that changed is the order of the TX/RX/interrupt > taskqueue stop versus grabbing the PCU lock. > > Since the PCU lock is also grabbed when doing some other things > (notably RX and interrupts, briefly in each situation), it's possible > that we're just now not hitting whatever the race is, versus having > fixed it. > > I'd really like to know where the race _is_... 231852 + your patch died after 2 hours, so the problem remains. -- Joel