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

[Ben Greear <greearb@candelatech.com>]

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com