On 03/26/2013 09:29 AM, Robert Shade wrote:
On Tue, Mar 26, 2013 at 12:28 PM, Adrian Chadd <adrian@xxxxxxxxxxx> wrote:
On 26 March 2013 05:21, Robert Shade <robert.shade@xxxxxxxxx> wrote:
I'll get a bug together, but I wanted to report that even with the
patch above (fastcc disabled/cold reset always), it still eventually
was unable to change the channel. As soon as that failed, it's back
into the state where it never seems to xmit anything in the data
queues and can't associate.
Even after a cold reset?
Yes, which is why I'm curious about the start/stop queues calls. It
looks to my (untrained) eye that it's simply not processing the data
queue.
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...
Here's the related email thread.
https://patchwork.kernel.org/patch/2174221/
My work-around was too ugly for upstream, but if you decide you
want to try it out, I'm curious to know if it fixes your
problems.
You can find my tree here:
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.7.dev.y/.git;a=summary
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
