From owner-freebsd-bugs@FreeBSD.ORG Sun Feb 12 03:00:26 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C07411065677 for ; Sun, 12 Feb 2012 03:00:25 +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 8D66A8FC0A for ; Sun, 12 Feb 2012 03:00:25 +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 q1C30PFR018255 for ; Sun, 12 Feb 2012 03:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1C30PPj018254; Sun, 12 Feb 2012 03:00:25 GMT (envelope-from gnats) Resent-Date: Sun, 12 Feb 2012 03:00:25 GMT Resent-Message-Id: <201202120300.q1C30PPj018254@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Adrian Chadd Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39538106564A for ; Sun, 12 Feb 2012 02:51:45 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 284C18FC0A for ; Sun, 12 Feb 2012 02:51:45 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q1C2piuP081650 for ; Sun, 12 Feb 2012 02:51:44 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q1C2piEe081649; Sun, 12 Feb 2012 02:51:44 GMT (envelope-from nobody) Message-Id: <201202120251.q1C2piEe081649@red.freebsd.org> Date: Sun, 12 Feb 2012 02:51:44 GMT From: Adrian Chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: misc/165021: [ath] ath device timeout during scan/attach, if wlan_ccmp/wlan_tkip isn't loaded X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 03:00:26 -0000 >Number: 165021 >Category: misc >Synopsis: [ath] ath device timeout during scan/attach, if wlan_ccmp/wlan_tkip isn't loaded >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 12 03:00:25 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: 9.0-RELEASE >Organization: >Environment: 9.0-RELEASE i386, but with -HEAD net80211/ath driver. >Description: If wlan_tkip/wlan_ccmp aren't loaded but are required by the hostap, the station mode code will: * attempt to associate * succeed * mark wlanX as UP * note that the required encryption type is not active * mark wlanX as DOWN . then 5 seconds later, "ath0: device timeout" shows up. >How-To-Repeat: * compile ath/net80211 as modules * load wlan and ath/ath_pci - but don't load wlan_wep/wlan_tkip/wlan_ccmp * attempt to associate to a network which requires encryption >Fix: After enabling debugging, I discovered this sequence of events: * a frame was being queued to the hardware - in this instance, a DISCONNECT frame; * the state would then transition to DOWN; * the IER was disabled - ie, HAL_INT_GLOBAL was cleared and something called ath_hal_intrset(); so the interrupt wouldn't occur; * the watchdog timer would kick in and call ath_reset(); * there'd be at least one completed frame in the TX queue, status OK - so it did go out. The actual cause seems to be that the state transition is going from RUN -> INIT, and this is causing interrupts to be disabled. ath_newstate() is causing a state transition to INIT, which disables interrupts and blocks the ath taskqueue. Trouble is, this doesn't stop/flush any of the currently pending hardware TX and this is what's eventually causing the watchdog timeout - although the hardware has completed the TX, the driver has disabled all methods of actually being notified about it. >Release-Note: >Audit-Trail: >Unformatted: