From: Ben Greear <greearb@candelatech.com>
To: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Paul Stewart <pstew@google.com>
Subject: Re: [PATCH 1/2] ath9k: recover the chip from tx/rx stuck
Date: Wed, 01 Feb 2012 11:35:13 -0800 [thread overview]
Message-ID: <4F2993F1.1020203@candelatech.com> (raw)
In-Reply-To: <1328112335-19265-1-git-send-email-rmanohar@qca.qualcomm.com>
On 02/01/2012 08:05 AM, Rajkumar Manoharan wrote:
> In the following scenario, where the distance b/w STA and AP is ~10m
> or in a shield environment by placing an attenuator with reduced AP
> txpower, the station started reporting with beacon loss and got
> disconnected whenever the chariot endpoint was initiated with BiDi
> traffic. In such state, two different stuck cases were observed.
>
> * rx clear is stuck at low for more than 100ms
> * dcu chain and complete state is stuck.
>
> This patch detects the stuck state if the beacons are not received for
> more than 300ms. In the above matching conditions, trigger a chip
> reset to recover. This issue was originally reported in 3.0 kernel with
> AR9382 chip by having two stations associated with two different APs in
> the same channel and was attenuated/controlled by Azimuth ADEPT-n box.
>
> Cc: Paul Stewart<pstew@google.com>
> Reported-by: Gary Morain<gmorain@google.com>
> Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
Some more comments below.....
> +static bool ath9k_check_dcu_chain_state(u32 dma_dbg, int max_limit,
> + int *hang_state, int *hang_pos)
> +{
> + static u32 hang_sign[] = {5, 6, 9};
> + u32 chain_state, dcs_pos, i;
> +
> + for (dcs_pos = 0; dcs_pos< max_limit; dcs_pos++) {
> + chain_state = (dma_dbg>> (5 * dcs_pos))& 0x1f;
> + for (i = 0; i< 3; i++) {
> + if (chain_state == hang_sign[i]) {
> + *hang_state = chain_state;
> + *hang_pos = dcs_pos;
> + return true;
> + }
> + }
> + }
> + return false;
> +}
Perhaps you could add some comments to the code above to describe
what the '5, 6, 9' and other constants mean?
> +#define DCU_COMPLETE_STATE 1
> +#define NUM_STATUS_READS 50
> +static bool ath9k_detect_mac_hang(struct ath_hw *ah)
> +{
> + u32 chain_state, comp_state, dcs_reg = AR_DMADBG_4;
> + u32 i, hang_pos, hang_state;
> +
> + comp_state = REG_READ(ah, AR_DMADBG_6);
> +
> + if ((comp_state& 0x3) != DCU_COMPLETE_STATE) {
> + ath_dbg(ath9k_hw_common(ah), RESET,
> + "MAC Hang signature not found at DCU complete\n");
> + return false;
> + }
Same with the 0x3 (maybe #define what those bits mean and or them together instead
of using the 0x3?)
> +
> + chain_state = REG_READ(ah, dcs_reg);
> + if (ath9k_check_dcu_chain_state(chain_state, 6,&hang_state,&hang_pos))
> + goto hang_check_iter;
And why did you choose a '6' here?
> +
> + dcs_reg = AR_DMADBG_5;
> + chain_state = REG_READ(ah, dcs_reg);
> + if (ath9k_check_dcu_chain_state(chain_state, 4,&hang_state,&hang_pos))
> + goto hang_check_iter;
And the '4'?
> +void ath_start_rx_poll(struct ath_softc *sc, const u32 msec)
> +{
> + if (!AR_SREV_9300_20_OR_LATER(sc->sc_ah))
> + return;
> +
> + if (!(sc->sc_flags& SC_OP_PRIM_STA_VIF))
> + return;
> +
> + mod_timer(&sc->rx_poll_timer, jiffies + msecs_to_jiffies(msec));
> +}
Since the rx-poll timer isn't started when SC_OP_PRIM_STA_VIF is
not set, should you always call the ath_start_rx_poll method
even if ani is disabled in the ath9k_bss_iter method since
the PRIM_STA_VIF flag is set earlier in that code)?
> static int ath9k_add_interface(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif)
> @@ -1948,6 +2086,8 @@ static void ath9k_bss_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
> if (!common->disable_ani) {
> sc->sc_flags |= SC_OP_ANI_RUN;
> ath_start_ani(common);
> + sc->rx.stop_rx_poll = false;
> + ath_start_rx_poll(sc, 300);
> }
>
> }
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2012-02-01 19:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-01 16:05 [PATCH 1/2] ath9k: recover the chip from tx/rx stuck Rajkumar Manoharan
2012-02-01 16:05 ` [PATCH 2/2] ath9k_hw: improve ANI processing and rx desensitizing parameters Rajkumar Manoharan
2012-02-02 22:09 ` Adrian Chadd
2012-02-03 5:56 ` Rajkumar Manoharan
2012-02-04 10:28 ` Adrian Chadd
2012-02-06 7:10 ` Rajkumar Manoharan
2012-02-07 21:41 ` Adrian Chadd
2012-02-10 0:55 ` Adrian Chadd
2012-02-01 17:31 ` [PATCH 1/2] ath9k: recover the chip from tx/rx stuck Ben Greear
2012-02-01 18:50 ` Rajkumar Manoharan
2012-02-01 19:03 ` Ben Greear
2012-02-01 19:35 ` Ben Greear [this message]
2012-02-02 3:49 ` Rajkumar Manoharan
2012-02-02 3:08 ` Sujith Manoharan
2012-02-02 3:56 ` Rajkumar Manoharan
2012-02-02 4:09 ` Sujith Manoharan
2012-02-02 4:46 ` Rajkumar Manoharan
[not found] ` <CAJ-VmomK0cD5rYbSYOQ7xwJLADdbD=a4JVG1bcd4QdTpV+uN2Q@mail.gmail.com>
2012-02-03 6:04 ` Rajkumar Manoharan
2012-02-04 10:30 ` Adrian Chadd
2012-02-02 4:56 ` Sujith Manoharan
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=4F2993F1.1020203@candelatech.com \
--to=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=pstew@google.com \
--cc=rmanohar@qca.qualcomm.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).