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 <nbd@xxxxxxxx>
> >
> > 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
