From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-we0-f176.google.com ([74.125.82.176]:34896 "EHLO mail-we0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751791Ab3C0Qdk (ORCPT ); Wed, 27 Mar 2013 12:33:40 -0400 Received: by mail-we0-f176.google.com with SMTP id s43so3183344wey.35 for ; Wed, 27 Mar 2013 09:33:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <201303251712.19808.chunkeey@googlemail.com> <5151D752.3080303@candelatech.com> Date: Wed, 27 Mar 2013 09:33:38 -0700 Message-ID: (sfid-20130327_173353_667997_BB38B0AA) Subject: Re: [ath9k-devel] Auth Packet TX Delay From: Adrian Chadd To: Robert Shade Cc: Ben Greear , Christian Lamparter , ath9k-devel@venema.h4ckr.net, linux-wireless@vger.kernel.org, Marco Fonseca Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: Good catch! Can you add that to the bugzilla bug please? Adrian On 26 March 2013 20:11, Robert Shade wrote: > Think I found it: In ath_reset_internal, before we reset, we call > ath_prepare_reset, which calls ath9k_hw_disable_interrupts. If the > channel change fails, we never call ath_complete_reset, which calls > ath9k_hw_enable_interrupts. > > ath9k_hw_{enable|disable}_interrupts calls definitely needs to be > balanced. Looking at an old log, IER never gets re-enabled after the > channel set failure. > > Any suggestions on the proper cleanup? Could we just call > ath_complete_reset anyway? Some sort of special handling? > > On Tue, Mar 26, 2013 at 8:55 PM, Robert Shade wrote: >> On Tue, Mar 26, 2013 at 1:13 PM, Ben Greear wrote: >>> Can you cat out the /debug/ieee80211/wiphy0/ath9k/xmit >>> file when it gets in this hung state? I saw issues where >>> the xmit queues got hung in our AR9380 NIC systems and >>> ended up adding an ugly bit of cleanup/reset logic to >>> get them working again... >> >> Dumps are attached on to the bug. I remember being hopeful when >> reading your thread that we stumbled on the same issue, but the >> symptoms don't look the same to me because pending-frames goes back to >> 0 in my case. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Chadd Date: Wed, 27 Mar 2013 09:33:38 -0700 Subject: [ath9k-devel] Auth Packet TX Delay In-Reply-To: References: <201303251712.19808.chunkeey@googlemail.com> <5151D752.3080303@candelatech.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Good catch! Can you add that to the bugzilla bug please? Adrian On 26 March 2013 20:11, Robert Shade wrote: > Think I found it: In ath_reset_internal, before we reset, we call > ath_prepare_reset, which calls ath9k_hw_disable_interrupts. If the > channel change fails, we never call ath_complete_reset, which calls > ath9k_hw_enable_interrupts. > > ath9k_hw_{enable|disable}_interrupts calls definitely needs to be > balanced. Looking at an old log, IER never gets re-enabled after the > channel set failure. > > Any suggestions on the proper cleanup? Could we just call > ath_complete_reset anyway? Some sort of special handling? > > On Tue, Mar 26, 2013 at 8:55 PM, Robert Shade wrote: >> On Tue, Mar 26, 2013 at 1:13 PM, Ben Greear wrote: >>> Can you cat out the /debug/ieee80211/wiphy0/ath9k/xmit >>> file when it gets in this hung state? I saw issues where >>> the xmit queues got hung in our AR9380 NIC systems and >>> ended up adding an ugly bit of cleanup/reset logic to >>> get them working again... >> >> Dumps are attached on to the bug. I remember being hopeful when >> reading your thread that we stumbled on the same issue, but the >> symptoms don't look the same to me because pending-frames goes back to >> 0 in my case.