linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ferry Huberts <mailings@hupie.com>
To: Sven Eckelmann <sven.eckelmann@open-mesh.com>,
	ath9k-devel@lists.ath9k.org
Cc: linux-wireless@vger.kernel.org, ath9k-devel@qca.qualcomm.com,
	Simon Wunderlich <simon.wunderlich@open-mesh.com>
Subject: Re: [ath9k-devel] [RFC v2 2/2] ath9k: Reset chip on potential deaf state
Date: Mon, 21 Nov 2016 10:07:43 +0100	[thread overview]
Message-ID: <d23407cb-a1c0-860a-3436-5e72402a080b@hupie.com> (raw)
In-Reply-To: <20161117083614.19188-2-sven.eckelmann@open-mesh.com>



On 17/11/16 09:36, Sven Eckelmann wrote:
> 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".
>
> Signed-off-by: Simon Wunderlich <simon.wunderlich@open-mesh.com>
> [sven.eckelmann@open-mesh.com: port to recent ath9k, add commit message]
> Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
> ---
> v2:
>  - reduce amount of possible goto-raptor attacks by one (thanks Kalle Valo)
>
> This problem was discovered in mesh setups. It was noticed that some nodes


What kind of setup?
Using 802.11s?

I ask this because I have almost completed a patch for authsae that 
checks rekey.

The problems there might show as the behaviour described here.


> were not able to see their neighbors (mostly after running for a while) -
> even when those neighbors received data from them via IBSS. A simple `iw
> dev wlan0 scan` fixed the problem for them. But the problem seems to
> reappear after while(tm) in a large enough(tm) mesh.
>
> This patch is a little bit obscure because it requires CONFIG_ATH9K_DEBUGFS
> to actually work. But there still seems to be potential interest in
> Freifunk communities or Freifunk meta-projects (e.g. freifunk-gluon). It is
> currently not known if it helps them but publishing this to allow them to
> test and play around with it will not hurt :)
> ---
>  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 9c6fee7..3987ad5 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -996,6 +996,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 608b370..6d5c253 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.c
> +++ b/drivers/net/wireless/ath/ath9k/debug.c
> @@ -768,6 +768,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 0d77abbf6..6f186bd 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.h
> +++ b/drivers/net/wireless/ath/ath9k/debug.h
> @@ -53,6 +53,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 04195d5..ae99c02 100644
> --- a/drivers/net/wireless/ath/ath9k/link.c
> +++ b/drivers/net/wireless/ath/ath9k/link.c
> @@ -158,13 +158,59 @@ static bool ath_hw_hang_deadbeef(struct ath_softc *sc)
>  	return true;
>  }
>
> +static bool ath_hw_hang_deaf(struct ath_softc *sc)
> +{
> +#ifndef CONFIG_ATH9K_DEBUGFS
> +	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;
> +
> +	/* save current data */
> +	sc->last_check_time = jiffies;
> +	if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
> +		sc->last_check_interrupts = sc->debug.stats.istats.rxlp;
> +	else
> +		sc->last_check_interrupts = sc->debug.stats.istats.rxok;
> +
> +	/* sanity check, should be 30 seconds */
> +	if (interval > 40000 || interval < 20000)
> +		return false;
> +
> +	/* should be at least one interrupt per second */
> +	interrupt_per_s = interrupts / (interval / 1000);
> +	if (interrupt_per_s >= 1)
> +		return false;
> +
> +	ath_dbg(common, RESET,
> +		"RX deaf hang is detected. Schedule chip reset\n");
> +	ath9k_queue_reset(sc, RESET_TYPE_DEAF);
> +
> +	return true;
> +#endif
> +}
> +
>  void ath_hw_hang_work(struct work_struct *work)
>  {
>  	struct ath_softc *sc = container_of(work, struct ath_softc,
>  					    hw_hang_work.work);
>
> -	ath_hw_hang_deadbeef(sc);
> +	if (ath_hw_hang_deadbeef(sc))
> +		goto requeue_worker;
> +
> +	ath_hw_hang_deaf(sc);
>
> +requeue_worker:
>  	ieee80211_queue_delayed_work(sc->hw, &sc->hw_hang_work,
>  				     msecs_to_jiffies(ATH_HANG_WORK_INTERVAL));
>  }
>

-- 
Ferry Huberts

  reply	other threads:[~2016-11-21  9:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17  8:36 [RFC v2 1/2] ath9k: work around AR_CFG 0xdeadbeef chip hang Sven Eckelmann
2016-11-17  8:36 ` [RFC v2 2/2] ath9k: Reset chip on potential deaf state Sven Eckelmann
2016-11-21  9:07   ` Ferry Huberts [this message]
2016-11-21  9:10     ` [ath9k-devel] " Sven Eckelmann
2016-11-21  9:15       ` Ferry Huberts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d23407cb-a1c0-860a-3436-5e72402a080b@hupie.com \
    --to=mailings@hupie.com \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=ath9k-devel@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=simon.wunderlich@open-mesh.com \
    --cc=sven.eckelmann@open-mesh.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).