lkml.org 
[lkml]   [2011]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: WARNING: at drivers/net/wireless/ath/ath9k/recv.c:536 ath_stoprecv+0xc8/0xda [ath9k]()
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


\
 
 \ /
  Last update: 2011-03-08 22:07    [W:0.388 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site