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
