Date: Sun, 13 Jan 2013 12:31:50 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Sven Hazejager <sven@hazejager.nl> Cc: freebsd-wireless@freebsd.org Subject: Re: freebsd-head and spectral scan Message-ID: <CAJ-Vmok02db878Ab9ChGH6ZK2Jm%2Bmr353Ff-kkGqh3OS7Gmt9w@mail.gmail.com> In-Reply-To: <CAJ-VmokVG6n-okGX3WrO5AtDCYV1%2BL7zc%2Bk6wSh-Nnxx=hrUiQ@mail.gmail.com> References: <CAJ-Vmok1-1wKXwOOms4z6X6w%2BJZL%2Boy6GyrotOB3OzJaTFE%2BWg@mail.gmail.com> <CAKwdyT6FLJSBLTJ72fuapSahrV6eZhkTU_BmN-=GBjd6vdaiFQ@mail.gmail.com> <CAJ-VmokVG6n-okGX3WrO5AtDCYV1%2BL7zc%2Bk6wSh-Nnxx=hrUiQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, The reason I haven't (yet) written any particular directions up on this is because I'm still trying to come up with relevant workarounds for spectral scan on the AR9280, when it's active with traffic. Since some of you will likely enable it with traffic and then discover that things hang (and frequently), I'd like to make sure the general case recoverable. What I've discovered thus far: * In STA mode, the beacon timer programming doesn't happen after a watchdog reset. * In STA mode, a beacon miss event can be indicative of RX deafness, so the right thing to do there is a no-loss reset. A reset does fix the RX deafness hang issue, but it doesn't reprogram the beacon timers, so subsequent beacon miss interrupts don't occur. * If I overflow the RX queue, the recovery doesn't .. recover. This may be a failure mode that's very specific to "RX queue overflow with PHY errors" rather than "RX queue overflow with data." At this stage, the RX just totally hangs until a reset occurs. I've fixed #1 and #2, and #3 is an interesting side-case. Once #2 was fixed, #3 immediately results in missed beacons, which results in a reset. But if too many missed beacons occur due to deafness, the association session is reset. So what I may do is: * Add the code to -HEAD to correctly reprogram the beacon timer after a missed beacon -> hardware reset; * Always reset the hardware after a beacon miss, in case it's a hang that we haven't yet detected; * Add the spectral scan related signatures to the HAL, so the ath_bmiss_proc() code doesn't call ieee80211_beacon_miss() and thus disassociate things. I'll also see if a full reset rather than a warm reset fixes whatever the bad PHY hardware state is that's causing things to continuously get stuck. Once that's done, I'll release some updated instructions so people can tinker with it, along with "this can hang all kinds of things and decrease performance, be careful" warnings. I may even wrap the code up in a github project or something and make a port. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmok02db878Ab9ChGH6ZK2Jm%2Bmr353Ff-kkGqh3OS7Gmt9w>