Re: [PATCH 2/2] wifi: ath9k: Reset chip on potential deaf state

[Simon Wunderlich <sw@simonwunderlich.de>]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

On Tuesday, November 5, 2024 2:02:31 PM CET Toke Høiland-Jørgensen wrote:
> Issam Hamdi <ih@simonwunderlich.de> writes:
> > From: Simon Wunderlich <simon.wunderlich@open-mesh.com>
> > 
> > The chip is switching seemingly random into a state which can be described
> > as "deaf". No or nearly no interrupts are generated anymore for incoming
> > packets. Existing links either break down after a while and new links will
> > not be established.
> > 
> > The driver doesn't know if there is no other device available or if it
> > ended up in an "deaf" state. Resetting the chip proactively avoids
> > permanent problems in case the chip really was in its "deaf" state but
> > maybe causes unnecessary resets in case it wasn't "deaf".
> 
> Proactively resetting the device if there is no traffic on the network
> for four seconds seems like a tad aggressive. Do you have any
> information on under which conditions this actually happens in practice?
> I assume this is a patch that has been lying around in openwrt for a
> while, or something?

Hi Toke,

this patch has been around for a long time (8 years or so?), and it has been 
integrated in various vendor firmwares (at least three I know of) as well as 
mesh community firmwares [1]. The circumstances leading to this "deafness" is 
still unclear, but we see that some particular chips (especially 2-stream 11n 
SoCs, but also others) can go 'deaf' when running AP or mesh (or both) after 
some time. It's probably a hardware issue, and doing a channel scan to trigger 
a chip reset (which one normally can't do on an AP interface) recovers the 
hardware. This patch provides a workaround within the kernel.

We submitted it only as RFC back then [2], and since we had colleagues 
suffering the same problem again we though we give it another shot to finally 
get it integrated upstream. :)

The idea is that if the radio is idle anyway, a quick reset (which takes a few 
tens of ms maximum) doesn't hurt much, and it helps to recover non-functional 
APs or mesh points.

Cheers,
      Simon

[1] https://github.com/freifunk-gluon/gluon/pull/2114
[2] https://patchwork.kernel.org/project/linux-wireless/patch/
20161117083614.19188-2-sven.eckelmann@open-mesh.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]