Re: WARNING: at drivers/net/wireless/ath/ath9k/recv.c:536 ath_stoprecv+0xc8/0xda[ath9k]()

From: Justin P. Mattock
Date: Wed Mar 09 2011 - 17:10:13 EST


On 03/08/2011 05:03 PM, Felix Fietkau wrote:
On 2011-03-08 10:03 PM, Justin P. Mattock wrote:
On 03/08/2011 11:59 AM, Ben Greear wrote:
On 03/08/2011 11:45 AM, Brian Prodoehl wrote:
On Tue, Mar 8, 2011 at 2:27 PM, Ben Greear<greearb@xxxxxxxxxxxxxxx>
wrote:
On 03/08/2011 10:49 AM, Justin P. Mattock wrote:

On 03/07/2011 07:22 AM, Mohammed Shafi wrote:

On Mon, Mar 7, 2011 at 8:42 PM, John W.
Linville<linville@xxxxxxxxxxxxx> wrote:

On Sun, Mar 06, 2011 at 12:47:05AM -0800, Justin Mattock wrote:

full dmesg here:
http://fpaste.org/5JQp/
let me know if I need to supply any info(also I can try a bisect,
but
am in the middle of changing residencies, so it might not be right
away)

One of the Atheros guys suggested that you change a DMA timeout
value.
Did you try that?

John it looks like increasing the timeout also does not seems to help.
A user reported this issue in ath9k developer list and he told that
increasing the timeout did not fix this issue.


John
--
John W. Linville Someday the world will need a hero, and you
linville@xxxxxxxxxxxxx might be all we have. Be ready.
--
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



at barnes and noble, and I see this has fired off again. will see if I
can reproduce and bisect.

This problem goes way back, and the driver has had lots of fixes in the
last few months, so I'm not sure if bisecting is going to
do you any good.

Thanks,
Ben

The warnings have been around since you added the check for the
problem, right? I remember initially it was a WARN_ON, and I'd get a
steady flood of backtraces, and then it was switched to a
WARN_ON_ONCE. I see these on every platform I have (x86_64, IXP425
and AR71xx) with AR9002 and AR9003.

I don't think I added the original check, but either way, it's
an old problem and bisecting it is unlikely to help.

I can't believe that the Atheros guys really are unable reproduce
this, but I can believe that it might be very difficult to
actually understand and fix.

At least in my testing, I see it quite often, but it doesn't
seem to cause any serious harm. We do occasionally see crashes,
especially on module unload for a heavily utilized system, or
one that is constantly trying and failing to associate,
so it could be related to this.

Also, my patches to decrease scan and work_work related channel changes
made this harder to hit for our test cases.

Thanks,
Ben



well I would do the bisect if I can easily reproduce this, but if this
has been back since 2.6.2* or the initial release of ath9k then doing
the bisect wont work.

as for the warning message itself, seems the system is fine after this
hits(just fires of on certain locations).

Justin P. Mattock
Please try this patch (posted to linux-wireless@) and see if it fixes
this issue in your tests.

diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index cb559e3..a9c3f46 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -413,9 +413,7 @@ u32 ath_calcrxfilter(struct ath_softc *sc)
* mode interface or when in monitor mode. AP mode does not need this
* since it receives all in-BSS frames anyway.
*/
- if (((sc->sc_ah->opmode != NL80211_IFTYPE_AP)&&
- (sc->rx.rxfilter& FIF_PROMISC_IN_BSS)) ||
- (sc->sc_ah->is_monitoring))
+ if (sc->sc_ah->is_monitoring)
rfilt |= ATH9K_RX_FILTER_PROM;

if (sc->rx.rxfilter& FIF_CONTROL)




patch applied: here is what I am seeing:

[ 1532.142246] FIREWALL:INPUT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1e:e5:7a:64:79:08:00 SRC=192.168.180.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
[ 1534.089408] FIREWALL:INPUT IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:de:9c:0f:ef:08:00 SRC=192.168.180.213 DST=192.168.180.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=10897 PROTO=UDP SPT=138 DPT=138 LEN=209
[ 1575.870714] FIREWALL:INPUT IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:40:a6:d9:b8:58:7c:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=64945 PROTO=UDP SPT=68 DPT=67 LEN=308
[ 1579.323946] ath: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0x41d1a
[ 1658.504988] FIREWALL:INPUT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1e:e5:7a:64:79:08:00 SRC=192.168.180.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
[ 1681.342000] FIREWALL:INPUT IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:c0:a8:db:bd:af:08:00 SRC=192.168.180.54 DST=192.168.180.255 LEN=240 TOS=0x00 PREC=0x00 TTL=64 ID=19778 PROTO=UDP SPT=138 DPT=138 LEN=220

full dmesg is here:
http://fpaste.org/jwTK/

Justin P. Mattock


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/