From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 11 20:50:09 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 46195106568E for ; Sun, 11 Mar 2012 20:50:09 +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 C88358FC12 for ; Sun, 11 Mar 2012 20:50:08 +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 q2BKo8Qg039720 for ; Sun, 11 Mar 2012 20:50:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2BKo8vx039719; Sun, 11 Mar 2012 20:50:08 GMT (envelope-from gnats) Date: Sun, 11 Mar 2012 20:50:08 GMT Message-Id: <201203112050.q2BKo8vx039719@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Adrian Chadd 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: Adrian Chadd 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: Sun, 11 Mar 2012 20:50:09 -0000 The following reply was made to PR kern/163318; it has been noted by GNATS. From: Adrian Chadd To: Joel Dahl Cc: bug-followup@freebsd.org Subject: Re: kern/163318: [ath] ath(4) stops working Date: Sun, 11 Mar 2012 13:45:02 -0700 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_... Adrian