From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wi0-f182.google.com ([209.85.212.182]:43968 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754161Ab3CXVw6 (ORCPT ); Sun, 24 Mar 2013 17:52:58 -0400 Received: by mail-wi0-f182.google.com with SMTP id hi18so6009508wib.3 for ; Sun, 24 Mar 2013 14:52:56 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Sun, 24 Mar 2013 14:52:56 -0700 Message-ID: (sfid-20130324_225302_880342_E03EE253) Subject: Re: Auth Packet TX Delay From: Adrian Chadd To: Robert Shade Cc: linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 24 March 2013 11:55, Robert Shade wrote: > I've done some more testing on this and it looks like the auth packets > aren't delayed, they're never sent. The "TX Complete" messages are > from the queue being purged before a reset due to channel change. Ew, ok. > It only gets in this state when it's unable to change the channel due > to the timeout on setting the AR_PHY_AGC_CONTROL register. One thing > that does look interesting is that, when we fail to change the > channel, ath_complete_reset is never called and therefore > ieee80211_wake_queues is never called either. Are stop/wake queues > calls supposed to be balanced? I'll leave that up to Felix. > Based on your suggestions, I've been testing a few days with the > following patch and I have yet to see any DMA messages or the auth > stuck state. I had to check for SC_OP_INVALID because the initial > reset in ath9k_start would cause a kernel panic when the system was > being initialized from a powered off state. I don't know enough about > the internals to know if I should expect that, but I'll need to set up > a serial console in order to capture the panic. Hm, so it's doing some fast channel changes? Just disable fast channel change entirely and re-test? And why not just force a cold reset always? Why bother checking for the queue to be stopped? Adrian From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Chadd Date: Sun, 24 Mar 2013 14:52:56 -0700 Subject: [ath9k-devel] Auth Packet TX Delay In-Reply-To: References: 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 On 24 March 2013 11:55, Robert Shade wrote: > I've done some more testing on this and it looks like the auth packets > aren't delayed, they're never sent. The "TX Complete" messages are > from the queue being purged before a reset due to channel change. Ew, ok. > It only gets in this state when it's unable to change the channel due > to the timeout on setting the AR_PHY_AGC_CONTROL register. One thing > that does look interesting is that, when we fail to change the > channel, ath_complete_reset is never called and therefore > ieee80211_wake_queues is never called either. Are stop/wake queues > calls supposed to be balanced? I'll leave that up to Felix. > Based on your suggestions, I've been testing a few days with the > following patch and I have yet to see any DMA messages or the auth > stuck state. I had to check for SC_OP_INVALID because the initial > reset in ath9k_start would cause a kernel panic when the system was > being initialized from a powered off state. I don't know enough about > the internals to know if I should expect that, but I'll need to set up > a serial console in order to capture the panic. Hm, so it's doing some fast channel changes? Just disable fast channel change entirely and re-test? And why not just force a cold reset always? Why bother checking for the queue to be stopped? Adrian