From: Robert Shade <robert.shade@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org Subject: Re: Auth Packet TX Delay Date: Sun, 24 Mar 2013 14:55:25 -0400 [thread overview] Message-ID: <CAMgrJ3aDhKgPjWx_znDCJVeibTChHAORnFS4Cv6fF56SvV=sNA@mail.gmail.com> (raw) In-Reply-To: <CAJ-Vmok-iP+=6EK+mG+jqnEPY2gPLhypjcGKxceEvy=EG59Ngw@mail.gmail.com> I've done some more testing on this and it looks like the auth packets aren't delayed, they're never sent. The "TX Complete" messages are from the queue being purged before a reset due to channel change. It only gets in this state when it's unable to change the channel due to the timeout on setting the AR_PHY_AGC_CONTROL register. One thing that does look interesting is that, when we fail to change the channel, ath_complete_reset is never called and therefore ieee80211_wake_queues is never called either. Are stop/wake queues calls supposed to be balanced? Felix's "ath9k_hw: improve reset reliability after errors" did help a bit, but I still get the DMA errors periodically and it eventually got into the state where the calibration fails leading to not sending any auth packets. Based on your suggestions, I've been testing a few days with the following patch and I have yet to see any DMA messages or the auth stuck state. I had to check for SC_OP_INVALID because the initial reset in ath9k_start would cause a kernel panic when the system was being initialized from a powered off state. I don't know enough about the internals to know if I should expect that, but I'll need to set up a serial console in order to capture the panic. diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index 07e2526..05eebdb 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1456,6 +1456,7 @@ static bool ath9k_hw_set_reset_reg(struct ath_hw *ah, u32 type) static bool ath9k_hw_chip_reset(struct ath_hw *ah, struct ath9k_channel *chan) { + struct ath_softc *sc = ah->hw->priv; int reset_type = ATH9K_RESET_WARM; if (AR_SREV_9280(ah)) { @@ -1463,9 +1464,12 @@ static bool ath9k_hw_chip_reset(struct ath_hw *ah, reset_type = ATH9K_RESET_POWER_ON; else reset_type = ATH9K_RESET_COLD; - } else if (ah->chip_fullsleep || REG_READ(ah, AR_Q_TXE) || - (REG_READ(ah, AR_CR) & AR_CR_RXE)) + } else if (AR_SREV_9160(ah) && !test_bit(SC_OP_INVALID, &sc->sc_flags)) { + reset_type = ATH9K_RESET_COLD; + } else if (ah->chip_fullsleep || REG_READ(ah, AR_Q_TXE) || + (REG_READ(ah, AR_CR) & AR_CR_RXE)) { reset_type = ATH9K_RESET_COLD; + } if (!ath9k_hw_set_reset_reg(ah, reset_type)) return false; diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index 6e66f9c..09b4699 100644 --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/net/wireless/ath/ath9k/main.c @@ -252,7 +252,7 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan) struct ath_hw *ah = sc->sc_ah; struct ath_common *common = ath9k_hw_common(ah); struct ath9k_hw_cal_data *caldata = NULL; - bool fastcc = true; + bool fastcc = !AR_SREV_9160(ah); int r; __ath_cancel_work(sc); -- On Sat, Feb 9, 2013 at 2:39 AM, Adrian Chadd <adrian@freebsd.org> wrote: > > On 8 February 2013 10:48, Robert Shade <robert.shade@gmail.com> wrote: > > Maybe I have the terminology wrong, but I thought a cold reset meant > > toggling the PCI reset line. > > That's a very very cold reset line, that resets the PCI bus glue > inside the chip. > > There's a bunch of different reset lines; most of the device can be > reset without resetting the PCI/PCIe host interface. > > So a "cold" reset here is resetting almost everything inside the chip > by pulling down those reset lines and stopping/restarting clocks. > > > Adrian
WARNING: multiple messages have this Message-ID (diff)
From: Robert Shade <robert.shade@gmail.com> To: ath9k-devel@lists.ath9k.org Subject: [ath9k-devel] Auth Packet TX Delay Date: Sun, 24 Mar 2013 14:55:25 -0400 [thread overview] Message-ID: <CAMgrJ3aDhKgPjWx_znDCJVeibTChHAORnFS4Cv6fF56SvV=sNA@mail.gmail.com> (raw) In-Reply-To: <CAJ-Vmok-iP+=6EK+mG+jqnEPY2gPLhypjcGKxceEvy=EG59Ngw@mail.gmail.com> I've done some more testing on this and it looks like the auth packets aren't delayed, they're never sent. The "TX Complete" messages are from the queue being purged before a reset due to channel change. It only gets in this state when it's unable to change the channel due to the timeout on setting the AR_PHY_AGC_CONTROL register. One thing that does look interesting is that, when we fail to change the channel, ath_complete_reset is never called and therefore ieee80211_wake_queues is never called either. Are stop/wake queues calls supposed to be balanced? Felix's "ath9k_hw: improve reset reliability after errors" did help a bit, but I still get the DMA errors periodically and it eventually got into the state where the calibration fails leading to not sending any auth packets. Based on your suggestions, I've been testing a few days with the following patch and I have yet to see any DMA messages or the auth stuck state. I had to check for SC_OP_INVALID because the initial reset in ath9k_start would cause a kernel panic when the system was being initialized from a powered off state. I don't know enough about the internals to know if I should expect that, but I'll need to set up a serial console in order to capture the panic. diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index 07e2526..05eebdb 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1456,6 +1456,7 @@ static bool ath9k_hw_set_reset_reg(struct ath_hw *ah, u32 type) static bool ath9k_hw_chip_reset(struct ath_hw *ah, struct ath9k_channel *chan) { + struct ath_softc *sc = ah->hw->priv; int reset_type = ATH9K_RESET_WARM; if (AR_SREV_9280(ah)) { @@ -1463,9 +1464,12 @@ static bool ath9k_hw_chip_reset(struct ath_hw *ah, reset_type = ATH9K_RESET_POWER_ON; else reset_type = ATH9K_RESET_COLD; - } else if (ah->chip_fullsleep || REG_READ(ah, AR_Q_TXE) || - (REG_READ(ah, AR_CR) & AR_CR_RXE)) + } else if (AR_SREV_9160(ah) && !test_bit(SC_OP_INVALID, &sc->sc_flags)) { + reset_type = ATH9K_RESET_COLD; + } else if (ah->chip_fullsleep || REG_READ(ah, AR_Q_TXE) || + (REG_READ(ah, AR_CR) & AR_CR_RXE)) { reset_type = ATH9K_RESET_COLD; + } if (!ath9k_hw_set_reset_reg(ah, reset_type)) return false; diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index 6e66f9c..09b4699 100644 --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/net/wireless/ath/ath9k/main.c @@ -252,7 +252,7 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan) struct ath_hw *ah = sc->sc_ah; struct ath_common *common = ath9k_hw_common(ah); struct ath9k_hw_cal_data *caldata = NULL; - bool fastcc = true; + bool fastcc = !AR_SREV_9160(ah); int r; __ath_cancel_work(sc); -- On Sat, Feb 9, 2013 at 2:39 AM, Adrian Chadd <adrian@freebsd.org> wrote: > > On 8 February 2013 10:48, Robert Shade <robert.shade@gmail.com> wrote: > > Maybe I have the terminology wrong, but I thought a cold reset meant > > toggling the PCI reset line. > > That's a very very cold reset line, that resets the PCI bus glue > inside the chip. > > There's a bunch of different reset lines; most of the device can be > reset without resetting the PCI/PCIe host interface. > > So a "cold" reset here is resetting almost everything inside the chip > by pulling down those reset lines and stopping/restarting clocks. > > > Adrian
next prev parent reply other threads:[~2013-03-24 18:55 UTC|newest] Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-20 18:45 [ath9k-devel] Auth Packet TX Delay Robert Shade 2013-01-15 22:06 ` Robert Shade 2013-01-15 22:06 ` [ath9k-devel] " Robert Shade 2013-01-16 23:09 ` Adrian Chadd 2013-01-16 23:09 ` [ath9k-devel] " Adrian Chadd 2013-01-17 1:00 ` Robert Shade 2013-01-17 1:00 ` [ath9k-devel] " Robert Shade 2013-01-17 3:12 ` Adrian Chadd 2013-01-17 3:12 ` [ath9k-devel] " Adrian Chadd 2013-02-06 2:51 ` Robert Shade 2013-02-06 2:51 ` [ath9k-devel] " Robert Shade 2013-02-06 3:08 ` Adrian Chadd 2013-02-06 3:08 ` [ath9k-devel] " Adrian Chadd 2013-02-06 12:53 ` Robert Shade 2013-02-06 12:53 ` [ath9k-devel] " Robert Shade 2013-02-06 22:58 ` Robert Shade 2013-02-06 22:58 ` [ath9k-devel] " Robert Shade 2013-02-07 5:06 ` Adrian Chadd 2013-02-07 5:06 ` [ath9k-devel] " Adrian Chadd 2013-02-07 16:25 ` David Littell 2013-02-07 16:25 ` David Littell 2013-02-07 19:43 ` Robert Shade 2013-02-07 19:43 ` [ath9k-devel] " Robert Shade 2013-02-07 21:40 ` Adrian Chadd 2013-02-07 21:40 ` [ath9k-devel] " Adrian Chadd 2013-02-08 18:48 ` Robert Shade 2013-02-08 18:48 ` [ath9k-devel] " Robert Shade 2013-02-09 7:39 ` Adrian Chadd 2013-02-09 7:39 ` [ath9k-devel] " Adrian Chadd 2013-03-24 18:55 ` Robert Shade [this message] 2013-03-24 18:55 ` Robert Shade 2013-03-24 21:52 ` Adrian Chadd 2013-03-24 21:52 ` [ath9k-devel] " Adrian Chadd 2013-03-24 22:40 ` Robert Shade 2013-03-24 22:40 ` [ath9k-devel] " Robert Shade 2013-03-24 22:58 ` Christian Lamparter 2013-03-24 22:58 ` [ath9k-devel] " Christian Lamparter 2013-03-25 0:03 ` Adrian Chadd 2013-03-25 0:03 ` [ath9k-devel] " Adrian Chadd 2013-03-25 2:23 ` Adrian Chadd 2013-03-25 2:23 ` [ath9k-devel] " Adrian Chadd 2013-03-25 16:12 ` Christian Lamparter 2013-03-25 16:12 ` [ath9k-devel] " Christian Lamparter 2013-03-25 16:45 ` Adrian Chadd 2013-03-25 16:45 ` [ath9k-devel] " Adrian Chadd 2013-03-26 12:21 ` Robert Shade 2013-03-26 12:21 ` [ath9k-devel] " Robert Shade 2013-03-26 13:23 ` Robert Shade 2013-03-26 13:23 ` [ath9k-devel] " Robert Shade 2013-03-26 16:28 ` Adrian Chadd 2013-03-26 16:28 ` [ath9k-devel] " Adrian Chadd 2013-03-26 16:29 ` Robert Shade 2013-03-26 16:29 ` [ath9k-devel] " Robert Shade 2013-03-26 17:13 ` Ben Greear 2013-03-26 17:13 ` Ben Greear 2013-03-26 17:16 ` Adrian Chadd 2013-03-26 17:16 ` Adrian Chadd 2013-03-26 17:27 ` Ben Greear 2013-03-26 17:27 ` Ben Greear 2013-03-26 17:33 ` Adrian Chadd 2013-03-26 17:33 ` Adrian Chadd 2013-03-26 17:45 ` Ben Greear 2013-03-26 17:45 ` Ben Greear 2013-03-27 0:55 ` Robert Shade 2013-03-27 0:55 ` Robert Shade 2013-03-27 3:11 ` Robert Shade 2013-03-27 3:11 ` Robert Shade 2013-03-27 16:33 ` Adrian Chadd 2013-03-27 16:33 ` Adrian Chadd 2013-03-26 17:14 ` Adrian Chadd 2013-03-26 17:14 ` [ath9k-devel] " Adrian Chadd 2013-03-26 14:13 ` Marco Fonseca 2013-03-26 14:13 ` [ath9k-devel] " Marco Fonseca
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='CAMgrJ3aDhKgPjWx_znDCJVeibTChHAORnFS4Cv6fF56SvV=sNA@mail.gmail.com' \ --to=robert.shade@gmail.com \ --cc=adrian@freebsd.org \ --cc=ath9k-devel@lists.ath9k.org \ --cc=linux-wireless@vger.kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.