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

[Felix Fietkau <nbd@openwrt.org>]

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@candelatech.com>
>>> 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@tuxdriver.com> 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@tuxdriver.com 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@vger.kernel.org
>>>>>>> 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)