Messages in this thread | | | Date | Tue, 08 Mar 2011 11:59:22 -0800 | From | Ben Greear <> | Subject | Re: WARNING: at drivers/net/wireless/ath/ath9k/recv.c:536 ath_stoprecv+0xc8/0xda [ath9k]() |
| |
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
| |