Issam Hamdi <ih@xxxxxxxxxxxxxxxxxx> writes:
> From: Simon Wunderlich <simon.wunderlich@xxxxxxxxxxxxx>
>
> 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?
As for the code itself, see below:
> This patch originally developed by "Simon Wunderlich <simon.wunderlich@xxxxxxxxxxxxx>"
> and "Sven Eckelmann <sven.eckelmann@xxxxxxxxxxxxx>"
>
> Co-developed-by: Simon Wunderlich <sw@xxxxxxxxxxxxxxxxxx>
> Co-developed-by: Sven Eckelmann <se@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Issam Hamdi <ih@xxxxxxxxxxxxxxxxxx>
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h | 3 ++
> drivers/net/wireless/ath/ath9k/debug.c | 1 +
> drivers/net/wireless/ath/ath9k/debug.h | 1 +
> drivers/net/wireless/ath/ath9k/link.c | 48 +++++++++++++++++++++++++-
> 4 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
> index c1ce081445a9..2b98c69fa37f 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -1026,6 +1026,9 @@ struct ath_softc {
> short nbcnvifs;
> unsigned long ps_usecount;
>
> + unsigned long last_check_time;
> + u32 last_check_interrupts;
> +
> struct ath_rx rx;
> struct ath_tx tx;
> struct ath_beacon beacon;
> diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
> index 6b2469a01f17..4128cf691166 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.c
> +++ b/drivers/net/wireless/ath/ath9k/debug.c
> @@ -751,6 +751,7 @@ static int read_file_reset(struct seq_file *file, void *data)
> [RESET_TX_DMA_ERROR] = "Tx DMA stop error",
> [RESET_RX_DMA_ERROR] = "Rx DMA stop error",
> [RESET_TYPE_DEADBEEF] = "deadbeef hang",
> + [RESET_TYPE_DEAF] = "deaf hang",
> };
> int i;
>
> diff --git a/drivers/net/wireless/ath/ath9k/debug.h b/drivers/net/wireless/ath/ath9k/debug.h
> index 6ebb6053a8c1..76e27860455c 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.h
> +++ b/drivers/net/wireless/ath/ath9k/debug.h
> @@ -54,6 +54,7 @@ enum ath_reset_type {
> RESET_TX_DMA_ERROR,
> RESET_RX_DMA_ERROR,
> RESET_TYPE_DEADBEEF,
> + RESET_TYPE_DEAF,
> __RESET_TYPE_MAX
> };
>
> diff --git a/drivers/net/wireless/ath/ath9k/link.c b/drivers/net/wireless/ath/ath9k/link.c
> index 37438960c278..d1762cc3129d 100644
> --- a/drivers/net/wireless/ath/ath9k/link.c
> +++ b/drivers/net/wireless/ath/ath9k/link.c
> @@ -162,13 +162,59 @@ static bool ath_hw_hang_deadbeef(struct ath_softc *sc)
> return true;
> }
>
> +static bool ath_hw_hang_deaf(struct ath_softc *sc)
> +{
> +#if !defined(CPTCFG_ATH9K_DEBUGFS) || defined(CPTCFG_ATH9K_TX99)
> + return false;
> +#else
> + struct ath_common *common = ath9k_hw_common(sc->sc_ah);
> + u32 interrupts, interrupt_per_s;
> + unsigned int interval;
> +
> + /* get historic data */
> + interval = jiffies_to_msecs(jiffies - sc->last_check_time);
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
> + interrupts = sc->debug.stats.istats.rxlp;
> + else
> + interrupts = sc->debug.stats.istats.rxok;
> +
> + interrupts -= sc->last_check_interrupts;
Relying on the debugfs counters for this seems like an odd roundabout
way of going about things. Why not just record the last time an RX
interrupt was received directly in the interrupt handler code, and then
have the watchdog check if that time was too far in the past?
Recording both TX and RX times may even help distinguish between 'deaf'
and 'idle' (cf the comment above): if we transmitted something, but got
no RX, that's a good indication of the deaf state; but if nothing
happened in either direction, it's probably just the network that's
idle. I think? :)
-Toke
