Good catch! Can you add that to the bugzilla bug please?
Adrian
On 26 March 2013 20:11, Robert Shade <robert.shade@xxxxxxxxx> 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 <robert.shade@xxxxxxxxx> wrote:
>> On Tue, Mar 26, 2013 at 1:13 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
