| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4D77FAB4.4010204@gmail.com> Date: Wed, 09 Mar 2011 14:09:56 -0800 From: "Justin P. Mattock" <justinmattock@...il.com> To: Felix Fietkau <nbd@...nwrt.org> CC: Ben Greear <greearb@...delatech.com>, Brian Prodoehl <bprodoehl@...il.com>, Mohammed Shafi <shafi.wireless@...il.com>, "John W. Linville" <linville@...driver.com>, linux-wireless@...r.kernel.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, ath9k-devel@...eros.com Subject: Re: WARNING: at drivers/net/wireless/ath/ath9k/recv.c:536 ath_stoprecv+0xc8/0xda [ath9k]() 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@...delatech.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@...driver.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@...driver.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@...r.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) > > 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists