Hey, On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote: > On 2017-01-26 10:50, Simon Wunderlich wrote: > > Hey Felix, > > > > On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote: > >> Various chips occasionally run into a state where the tx path still > >> appears to be working normally, but the rx path is deaf. > >> > >> There is no known register signature to check for this state explicitly, > >> so use the lack of rx interrupts as an indicator. > >> > >> This detection is prone to false positives, since a device could also > >> simply be in an environment where there are no frames on the air. > >> However, in this case doing a reset should be harmless since it's > >> obviously not interrupting any real activity. To avoid confusion, call > >> the reset counters in this case "Rx path inactive" instead of something > >> like "Rx path deaf", since it may not be an indication of a real > >> hardware failure. > >> > >> Signed-off-by: Felix Fietkau <[email protected]> > > > > As we observed in the field, it may happen that there are still RX > > interrupts triggered, but just a very low number - in which case I > > believe your version wouldn't fix the problem. Therefore we had a > > threshold in our original patch [1]. > > It seems that you were seeing something different than what I was seeing > in my tests. Though it could be that my issues were actually caused by > something else. I had queued up these changes a while back before I > finally found and fixed the IRQ issue.
What we found a good threshold was to check for less than 1 RX interrupt per
second, and check the mean average (about) every 30 seconds. If there is any
other AP or a station connected, it will not reset the chip, and also there
will be no reset on short outages.
However, Access Points "alone" somewhere without users may still accumulate a
lot of false resets. Your name choice is better than ours in this regard, lets
hope users understand that as well. :)
>
> > We would also appreciate if you can at least briefly mention our work if
> > you resend/rework our stuff.
>
> Sorry about that. I rebased this from older experimental patches and
> forgot to put in all the relevant context.
Cool, thanks!
Simon
signature.asc
Description: This is a digitally signed message part.
