* Re: ath5k: Weird Retransmission Behaviour
From: Bob Copeland @ 2010-12-08 16:08 UTC (permalink / raw)
To: Bruno Randolf; +Cc: Jonathan Guerin, linux-wireless, ath5k-devel, nbd
In-Reply-To: <201012061714.15863.br1@einfach.org>
On Mon, Dec 6, 2010 at 3:14 AM, Bruno Randolf <br1@einfach.org> wrote:
> But it seems weird that there are so many retransmissions. The default maximum
> numbers of retransmissions should be 7 for short frames and 4 for long frames
> (dot11[Short|Long]RetryLimit), and this is what is set as defaults in mac80211
> (local->hw.conf.short_frame_max_tx_count). Seems we are getting many
> retransmissions from minstel, i added some debug prints:
>
I posted a patch for this about a week ago to linux-wireless.
AFAICT minstrel doesn't use these configuration parrameters
at all (but PID does).
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] ath9k: Check for NULL sta in ath_tx_start
From: Ben Greear @ 2010-12-08 15:40 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Vasanth Thiagarajan, Luis R. Rodriguez, greearb@gmail.com,
linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
In-Reply-To: <20101208051745.GA24465@vasanth-laptop>
On 12/07/2010 09:17 PM, Vasanthakumar Thiagarajan wrote:
> On Tue, Dec 07, 2010 at 10:43:38PM +0530, Ben Greear wrote:
>> On 12/07/2010 12:31 AM, Vasanthakumar Thiagarajan wrote:
>>> On Tue, Dec 07, 2010 at 01:19:22PM +0530, Ben Greear wrote:
>>>> On 12/06/2010 11:42 PM, Vasanthakumar Thiagarajan wrote:
>>>>> On Tue, Dec 07, 2010 at 11:06:24AM +0530, Ben Greear wrote:
>>>>>> On 12/06/2010 09:21 PM, Luis R. Rodriguez wrote:
>>>>>>> On Mon, Dec 6, 2010 at 9:13 PM,<greearb@gmail.com> wrote:
>>>>>>>> From: Ben Greear<greearb@candelatech.com>
>>>>>>>>
>>>>>>>> It can be NULL according to docs, and logging showed it
>>>>>>>> to be NULL in practice.
>>>>>>>>
>>>>>>>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>>>>>>>
>>>>>>> Does this fix an oops? If so can you explain and provide the trace and
>>>>>>> resubmit and cc stable in the commit log?
>>>>>>
>>>>>> I think it fixes the TID corruption I posted about earlier. It seems
>>>>>> so obvious though, that I'm curious why no one else sees problems,
>>>>>> and why I didn't see more crashes in my setup.
>>>>>>
>>>>>> (The paprd code appears to send with null STA, for instance, and my
>>>>>> printks showed lots of NULL stas in my 16-sta test setup, though I
>>>>>> don't think I'm using the paprd code path.)
>>>>>
>>>>> paprd is used only with>= AR9003.
>>>>
>>>> Whoever coded it up hopefully had that hardware...so why didn't
>>>> they see lots of crashes?
>>>
>>> I myself tested it lot of times, but did not see any crash, weird.
>>
>> Looks like the offending change when in recently (11/4/10, one of Felix's
>> patches).
>>
>> That is probably why no one else is hitting this yet, and it
>> isn't needed for stable I'm guessing....
>
> Nice, care to send a patch?. Yeah, it is not needed for stable.
The same patch I originally posted to to start this thread
should do just fine.
If someone really wants an oops report, I can add an artificial BUG_ON
to catch this, but for whatever reason, it normally just crashes things
weirdly and perhaps sometimes screwed up the file-system, so I'd rather
just have the patch go in as it is..I think it is obviously more correct
than the existing code.
Thanks,
Ben
>
> Vasanth
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] wireless: Remove spurious warning in mlme.c
From: Ben Greear @ 2010-12-08 15:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1291795903.3562.5.camel@jlt3.sipsolutions.net>
On 12/08/2010 12:11 AM, Johannes Berg wrote:
> On Tue, 2010-12-07 at 14:06 -0800, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> Seems that we should not be warning if all of the
>> authtry_bsses are already NULL.
>
> Do you keep running into the warning? I'd really like to understand how
> it happens -- it seems to point to a mac80211 bug.
>
> So don't really like this patch.
Yes, it's easily repeatable in my setup when using wpa_supplicant
for non-encrypted VIFS. I was using around 80 VIFS for most of this testing.
I posted the backtrace to no comment several weeks ago:
http://www.spinics.net/lists/linux-wireless/msg59525.html
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* b43 N PHY status report
From: Larry Finger @ 2010-12-08 15:15 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: b43-dev, wireless
In-Reply-To: <AANLkTikp9ErFopLZVmXMjN3tXF2L62SwEEcujKeOBLYC@mail.gmail.com>
Rafał,
The N PHY driver is remarkably stable. So far, my link has been up for nearly 16
hours under normal conditions - I have not yet tried any stress tests. Other
than the PHY errors that you noted, my link has only reported 2 other unusual
events. I have had 3 "Deauthentication for reason 3" from which it recovered in
one try. Also logged are 9 instances of "RX: Packet size underrun (2)/Packet
dropped" events. Again, these caused no problems.
Larry
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Add antenna availability information
From: John W. Linville @ 2010-12-08 14:31 UTC (permalink / raw)
To: Bruno Randolf; +Cc: johannes, linux-wireless
In-Reply-To: <20101208034429.24218.50707.stgit@localhost6.localdomain6>
On Wed, Dec 08, 2010 at 12:44:29PM +0900, Bruno Randolf wrote:
> Add a field to wiphy for the hardware to report the availble antennas for
> configuration. Only if this is set to something bigger than zero, will the
> anntenna configuration ops be executed.
>
> Allthough this could be a simple number of antennas, I defined it as a bitmap
> of antennas which are available for configuration, since it's more consistent
> with the rest of the antenna API and there could be cases where the
> hardware allows only configuration of certain antennas. As it does not make
> much of a difference in size or normal usage, I think it's better to be able to
> support this, in case the need arises.
>
> The antenna configuration is now also checked against the availabe antennas and
> rejected if it does not match.
>
> Signed-off-by: Bruno Randolf <br1@einfach.org>
>
> v2: reject antenna configurations which don't match the available antennas
> ---
Please either put the "v2" part before the "Signed-off-by" or
(preferably) after the "---" line. Also, make sure to use 3 "-"
characters -- often you use only 2 of them and the results from
applying with "git am" are messy.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] ath: Missed to clear key4 of micentry
From: John W. Linville @ 2010-12-08 14:33 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless, stable
In-Reply-To: <1291818665-6660-1-git-send-email-rmanoharan@atheros.com>
On Wed, Dec 08, 2010 at 08:01:05PM +0530, Rajkumar Manoharan wrote:
> key4 of micentry is used, if ATH_CRYPT_CAP_MIC_COMBINED is set.
> But is not cleared on key cache reset.
>
> Cc: stable@kernel.org
> Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Which results in...?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] ath: Missed to clear key4 of micentry
From: Rajkumar Manoharan @ 2010-12-08 14:31 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Rajkumar Manoharan, stable
key4 of micentry is used, if ATH_CRYPT_CAP_MIC_COMBINED is set.
But is not cleared on key cache reset.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
drivers/net/wireless/ath/key.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/key.c b/drivers/net/wireless/ath/key.c
index 29a2961..5d465e5 100644
--- a/drivers/net/wireless/ath/key.c
+++ b/drivers/net/wireless/ath/key.c
@@ -58,6 +58,8 @@ bool ath_hw_keyreset(struct ath_common *common, u16 entry)
REG_WRITE(ah, AR_KEYTABLE_KEY1(micentry), 0);
REG_WRITE(ah, AR_KEYTABLE_KEY2(micentry), 0);
REG_WRITE(ah, AR_KEYTABLE_KEY3(micentry), 0);
+ if (common->crypt_caps & ATH_CRYPT_CAP_MIC_COMBINED)
+ REG_WRITE(ah, AR_KEYTABLE_KEY4(micentry), 0);
}
--
1.7.3.3
^ permalink raw reply related
* Re: [ath9k-devel] [PATCH] ath9k: Make DMA warning in ath_stoprecv WARN_ON_ONCE.
From: John W. Linville @ 2010-12-08 14:23 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: greearb@gmail.com, ath9k-devel@venema.h4ckr.net,
linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTi=pXQ1D7Pxc3c==pxHH662dKogscfGjHrACxAvS@mail.gmail.com>
On Tue, Dec 07, 2010 at 03:05:46PM -0800, Luis R. Rodriguez wrote:
> On Mon, Dec 6, 2010 at 2:02 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Mon, Dec 6, 2010 at 1:59 PM, Luis R. Rodriguez
> > <lrodriguez@atheros.com> wrote:
> >> On Mon, Dec 06, 2010 at 01:13:07PM -0800, greearb@gmail.com wrote:
> >>> From: Ben Greear <greearb@candelatech.com>
> >>>
> >>> This decreases spammage in the log. A single line message
> >>> will still be printed, so users can be aware that problem
> >>> exists.
> >>>
> >>> Signed-off-by: Ben Greear <greearb@candelatech.com>
> >>
> >> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >
> > You forgot to address linville, and no need to send to ath9k-devel if
> > you already know the patch is good.
>
> Ben, your patch did not get merged in today's pick of patches by John
> but I like it and want to resuse the same definition in my new patches
> so I will resubmit in my new series. Thanks.
Put down the crack pipe... :-)
commit d7fd1b50a51be3fe6554fbab8953fa8a3ff4009b
Author: Ben Greear <greearb@candelatech.com>
Date: Mon Dec 6 13:13:07 2010 -0800
ath9k: Make DMA warning in ath_stoprecv WARN_ON_ONCE.
This decreases spammage in the log. A single line message
will still be printed, so users can be aware that problem
exists.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH v5 2/2] ath9k: Add change_interface callback
From: Rajkumar Manoharan @ 2010-12-08 14:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Rajkumar Manoharan
In-Reply-To: <1291817335-5973-1-git-send-email-rmanoharan@atheros.com>
Add support to change interface type
without bringing down the interface.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
v2: - ieee80211_iftype_p2p not needed
- missed to store p2p value
v3: nbcnvifs has to be checked while changing to beaconing mode
v4: rebased
v5: s/ath_print/ath_[err/dbg]/
drivers/net/wireless/ath/ath9k/main.c | 90 +++++++++++++++++++++++++--------
1 files changed, 69 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 699dbaa..8637806 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1425,13 +1425,78 @@ out:
return ret;
}
+static void ath9k_reclaim_beacon(struct ath_softc *sc,
+ struct ieee80211_vif *vif)
+{
+ struct ath_vif *avp = (void *)vif->drv_priv;
+
+ /* Disable SWBA interrupt */
+ sc->sc_ah->imask &= ~ATH9K_INT_SWBA;
+ ath9k_ps_wakeup(sc);
+ ath9k_hw_set_interrupts(sc->sc_ah, sc->sc_ah->imask);
+ ath9k_hw_stoptxdma(sc->sc_ah, sc->beacon.beaconq);
+ tasklet_kill(&sc->bcon_tasklet);
+ ath9k_ps_restore(sc);
+
+ ath_beacon_return(sc, avp);
+ sc->sc_flags &= ~SC_OP_BEACONS;
+
+ if (sc->nbcnvifs > 0) {
+ /* Re-enable beaconing */
+ sc->sc_ah->imask |= ATH9K_INT_SWBA;
+ ath9k_ps_wakeup(sc);
+ ath9k_hw_set_interrupts(sc->sc_ah, sc->sc_ah->imask);
+ ath9k_ps_restore(sc);
+ }
+}
+
+static int ath9k_change_interface(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ enum nl80211_iftype new_type,
+ bool p2p)
+{
+ struct ath_wiphy *aphy = hw->priv;
+ struct ath_softc *sc = aphy->sc;
+ struct ath_common *common = ath9k_hw_common(sc->sc_ah);
+
+ ath_dbg(common, ATH_DBG_CONFIG, "Change Interface\n");
+ mutex_lock(&sc->mutex);
+
+ switch (new_type) {
+ case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_ADHOC:
+ if (sc->nbcnvifs >= ATH_BCBUF) {
+ ath_err(common, "No beacon slot available\n");
+ return -ENOBUFS;
+ }
+ break;
+ case NL80211_IFTYPE_STATION:
+ /* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
+ del_timer_sync(&common->ani.timer);
+ if ((vif->type == NL80211_IFTYPE_AP) ||
+ (vif->type == NL80211_IFTYPE_ADHOC))
+ ath9k_reclaim_beacon(sc, vif);
+ break;
+ default:
+ ath_err(common, "Interface type %d not yet supported\n",
+ vif->type);
+ mutex_unlock(&sc->mutex);
+ return -ENOTSUPP;
+ }
+ vif->type = new_type;
+ vif->p2p = p2p;
+
+ mutex_unlock(&sc->mutex);
+ return 0;
+}
+
static void ath9k_remove_interface(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
- struct ath_vif *avp = (void *)vif->drv_priv;
ath_dbg(common, ATH_DBG_CONFIG, "Detach Interface\n");
@@ -1444,26 +1509,8 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
/* Reclaim beacon resources */
if ((sc->sc_ah->opmode == NL80211_IFTYPE_AP) ||
(sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC) ||
- (sc->sc_ah->opmode == NL80211_IFTYPE_MESH_POINT)) {
- /* Disable SWBA interrupt */
- sc->sc_ah->imask &= ~ATH9K_INT_SWBA;
- ath9k_ps_wakeup(sc);
- ath9k_hw_set_interrupts(sc->sc_ah, sc->sc_ah->imask);
- ath9k_hw_stoptxdma(sc->sc_ah, sc->beacon.beaconq);
- ath9k_ps_restore(sc);
- tasklet_kill(&sc->bcon_tasklet);
- }
-
- ath_beacon_return(sc, avp);
- sc->sc_flags &= ~SC_OP_BEACONS;
-
- if (sc->nbcnvifs) {
- /* Re-enable SWBA interrupt */
- sc->sc_ah->imask |= ATH9K_INT_SWBA;
- ath9k_ps_wakeup(sc);
- ath9k_hw_set_interrupts(sc->sc_ah, sc->sc_ah->imask);
- ath9k_ps_restore(sc);
- }
+ (sc->sc_ah->opmode == NL80211_IFTYPE_MESH_POINT))
+ ath9k_reclaim_beacon(sc, vif);
sc->nvifs--;
@@ -2108,6 +2155,7 @@ struct ieee80211_ops ath9k_ops = {
.start = ath9k_start,
.stop = ath9k_stop,
.add_interface = ath9k_add_interface,
+ .change_interface = ath9k_change_interface,
.remove_interface = ath9k_remove_interface,
.config = ath9k_config,
.configure_filter = ath9k_configure_filter,
--
1.7.3.3
^ permalink raw reply related
* [PATCH 2.6.37 v3 1/2] ath9k: fix beacon resource related race condition
From: Rajkumar Manoharan @ 2010-12-08 14:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Rajkumar Manoharan
The beacon tasklet is accesssing the bslot info for beacon generation.
Meanwhile the same slot can be freed on interface deletion.
Current the remove_interface disables the beacon alert after freeing the
slot. This leads to null pointer access.
This patch disables SWBA and kills the beacon tasklet to prevent access
to the slot to be freed. After releasing the slot, swba will be enabled
again based on the availablity of beaconing interfaces.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
v2: updated commit log
v3: s/ath_print/ath_[err/dbg]/
drivers/net/wireless/ath/ath9k/main.c | 21 +++++++--------------
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 3e0c8a1..699dbaa 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1432,8 +1432,6 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
struct ath_softc *sc = aphy->sc;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
struct ath_vif *avp = (void *)vif->drv_priv;
- bool bs_valid = false;
- int i;
ath_dbg(common, ATH_DBG_CONFIG, "Detach Interface\n");
@@ -1447,26 +1445,21 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
if ((sc->sc_ah->opmode == NL80211_IFTYPE_AP) ||
(sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC) ||
(sc->sc_ah->opmode == NL80211_IFTYPE_MESH_POINT)) {
+ /* Disable SWBA interrupt */
+ sc->sc_ah->imask &= ~ATH9K_INT_SWBA;
ath9k_ps_wakeup(sc);
+ ath9k_hw_set_interrupts(sc->sc_ah, sc->sc_ah->imask);
ath9k_hw_stoptxdma(sc->sc_ah, sc->beacon.beaconq);
ath9k_ps_restore(sc);
+ tasklet_kill(&sc->bcon_tasklet);
}
ath_beacon_return(sc, avp);
sc->sc_flags &= ~SC_OP_BEACONS;
- for (i = 0; i < ARRAY_SIZE(sc->beacon.bslot); i++) {
- if (sc->beacon.bslot[i] == vif) {
- printk(KERN_DEBUG "%s: vif had allocated beacon "
- "slot\n", __func__);
- sc->beacon.bslot[i] = NULL;
- sc->beacon.bslot_aphy[i] = NULL;
- } else if (sc->beacon.bslot[i])
- bs_valid = true;
- }
- if (!bs_valid && (sc->sc_ah->imask & ATH9K_INT_SWBA)) {
- /* Disable SWBA interrupt */
- sc->sc_ah->imask &= ~ATH9K_INT_SWBA;
+ if (sc->nbcnvifs) {
+ /* Re-enable SWBA interrupt */
+ sc->sc_ah->imask |= ATH9K_INT_SWBA;
ath9k_ps_wakeup(sc);
ath9k_hw_set_interrupts(sc->sc_ah, sc->sc_ah->imask);
ath9k_ps_restore(sc);
--
1.7.3.3
^ permalink raw reply related
* Re: [ath5k-devel] ath5k: Weird Retransmission Behaviour
From: Jonathan Guerin @ 2010-12-08 8:12 UTC (permalink / raw)
To: Bruno Randolf
Cc: Nick Kossifidis, ath5k-devel, linux-wireless, bjorn.smedman, nbd
In-Reply-To: <201012081706.54459.br1@einfach.org>
On Wed, Dec 8, 2010 at 6:06 PM, Bruno Randolf <br1@einfach.org> wrote:
>> > When ath5k doesn't get retry limits from above it uses the following
>> > defaults on dcu.
>> > For now i don't think we use local->hw.conf.short_frame_max_tx_count
>> > for that so the
>> > default is ah_limit_tx_retries (AR5K_INIT_TX_RETRY) but seems it's
>> > wrong and we should
>> > fix it...
>> >
>> > /* Tx retry limits */
>> > #define AR5K_INIT_SH_RETRY 10
>> > #define AR5K_INIT_LG_RETRY AR5K_INIT_SH_RETRY
>> > /* For station mode */
>> > #define AR5K_INIT_SSH_RETRY 32
>> > #define AR5K_INIT_SLG_RETRY AR5K_INIT_SSH_RETRY
>> > #define AR5K_INIT_TX_RETRY 10
>
> I just sent a patch cleaning up this mess. Could you please check it?
> Unfortunately i didn't find way to really test re-transmissions, yet.
> Jonathan, could you give it a try in your test setup with my patch, and play
> with the numbers (just hardcode them in ath5k_hw_set_tx_retry_limits) to see
> if they actually have an effect?
Added to my todo for tomorrow - I'll try to do it if I have some spare time!
Cheers,
Jonathan
>
> As noted in my patch, this does not change the high number of retries we get
> from the rate control. That's a separate issue.
>
> bruno
>
^ permalink raw reply
* Re: [PATCH] wireless: Remove spurious warning in mlme.c
From: Johannes Berg @ 2010-12-08 8:11 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1291759599-14698-1-git-send-email-greearb@candelatech.com>
On Tue, 2010-12-07 at 14:06 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Seems that we should not be warning if all of the
> authtry_bsses are already NULL.
Do you keep running into the warning? I'd really like to understand how
it happens -- it seems to point to a mac80211 bug.
So don't really like this patch.
johannes
^ permalink raw reply
* Re: [ath5k-devel] ath5k: Weird Retransmission Behaviour
From: Bruno Randolf @ 2010-12-08 8:06 UTC (permalink / raw)
To: Jonathan Guerin
Cc: Nick Kossifidis, ath5k-devel, linux-wireless, bjorn.smedman, nbd
In-Reply-To: <AANLkTimS03cqqG8TCN1MTGF0DRQ51hrFkSPrbah2Z4gO@mail.gmail.com>
> > When ath5k doesn't get retry limits from above it uses the following
> > defaults on dcu.
> > For now i don't think we use local->hw.conf.short_frame_max_tx_count
> > for that so the
> > default is ah_limit_tx_retries (AR5K_INIT_TX_RETRY) but seems it's
> > wrong and we should
> > fix it...
> >
> > /* Tx retry limits */
> > #define AR5K_INIT_SH_RETRY 10
> > #define AR5K_INIT_LG_RETRY AR5K_INIT_SH_RETRY
> > /* For station mode */
> > #define AR5K_INIT_SSH_RETRY 32
> > #define AR5K_INIT_SLG_RETRY AR5K_INIT_SSH_RETRY
> > #define AR5K_INIT_TX_RETRY 10
I just sent a patch cleaning up this mess. Could you please check it?
Unfortunately i didn't find way to really test re-transmissions, yet.
Jonathan, could you give it a try in your test setup with my patch, and play
with the numbers (just hardcode them in ath5k_hw_set_tx_retry_limits) to see
if they actually have an effect?
As noted in my patch, this does not change the high number of retries we get
from the rate control. That's a separate issue.
bruno
^ permalink raw reply
* Re: [PATCH 2.6.37 v2 1/2] ath9k: fix beacon resource related race condition
From: Rajkumar Manoharan @ 2010-12-08 7:18 UTC (permalink / raw)
To: linville; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1291723939-19262-1-git-send-email-rmanoharan@atheros.com>
On Tue, Dec 07, 2010 at 05:42:18PM +0530, Rajkumar Manoharan wrote:
> The beacon tasklet is accesssing the bslot info for beacon generation.
> Meanwhile the same slot can be freed on interface deletion.
> Current the remove_interface disables the beacon alert after freeing the slot.
> This may leads to null pointer access.
>
> This patch disables SWBA and kills the beacon tasklet to prevent access
> to the slot to be freed. After releasing the slot, swba will be enabled again
> upon the availablity of beaconing interfaces.
>
> Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
John,
I respin the patches on 2.6.37-rc5-wl and send it again. Sorry for inconvenience.
--
Rajkumar
^ permalink raw reply
* Re: [PATCH] ath9k: Check for NULL sta in ath_tx_start
From: Vasanthakumar Thiagarajan @ 2010-12-08 5:17 UTC (permalink / raw)
To: Ben Greear
Cc: Vasanth Thiagarajan, Luis R. Rodriguez, greearb@gmail.com,
linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
In-Reply-To: <4CFE6B42.8000806@candelatech.com>
On Tue, Dec 07, 2010 at 10:43:38PM +0530, Ben Greear wrote:
> On 12/07/2010 12:31 AM, Vasanthakumar Thiagarajan wrote:
> > On Tue, Dec 07, 2010 at 01:19:22PM +0530, Ben Greear wrote:
> >> On 12/06/2010 11:42 PM, Vasanthakumar Thiagarajan wrote:
> >>> On Tue, Dec 07, 2010 at 11:06:24AM +0530, Ben Greear wrote:
> >>>> On 12/06/2010 09:21 PM, Luis R. Rodriguez wrote:
> >>>>> On Mon, Dec 6, 2010 at 9:13 PM,<greearb@gmail.com> wrote:
> >>>>>> From: Ben Greear<greearb@candelatech.com>
> >>>>>>
> >>>>>> It can be NULL according to docs, and logging showed it
> >>>>>> to be NULL in practice.
> >>>>>>
> >>>>>> Signed-off-by: Ben Greear<greearb@candelatech.com>
> >>>>>
> >>>>> Does this fix an oops? If so can you explain and provide the trace and
> >>>>> resubmit and cc stable in the commit log?
> >>>>
> >>>> I think it fixes the TID corruption I posted about earlier. It seems
> >>>> so obvious though, that I'm curious why no one else sees problems,
> >>>> and why I didn't see more crashes in my setup.
> >>>>
> >>>> (The paprd code appears to send with null STA, for instance, and my
> >>>> printks showed lots of NULL stas in my 16-sta test setup, though I
> >>>> don't think I'm using the paprd code path.)
> >>>
> >>> paprd is used only with>= AR9003.
> >>
> >> Whoever coded it up hopefully had that hardware...so why didn't
> >> they see lots of crashes?
> >
> > I myself tested it lot of times, but did not see any crash, weird.
>
> Looks like the offending change when in recently (11/4/10, one of Felix's
> patches).
>
> That is probably why no one else is hitting this yet, and it
> isn't needed for stable I'm guessing....
Nice, care to send a patch?. Yeah, it is not needed for stable.
Vasanth
^ permalink raw reply
* [PATCH v3] cfg80211: Add antenna availability information
From: Bruno Randolf @ 2010-12-08 4:59 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless
Add a field to wiphy for the hardware to report the availble antennas for
configuration. Only if this is set to something bigger than zero, will the
anntenna configuration ops be executed.
Allthough this could be a simple number of antennas, I defined it as a bitmap
of antennas which are available for configuration, since it's more consistent
with the rest of the antenna API and there could be cases where the
hardware allows only configuration of certain antennas. As it does not make
much of a difference in size or normal usage, I think it's better to be able to
support this, in case the need arises.
The antenna configuration is now also checked against the availabe antennas and
rejected if it does not match.
Signed-off-by: Bruno Randolf <br1@einfach.org>
--
v3: always apply available antenna mask (for "all" antennas case).
v2: reject antenna configurations which don't match the available antennas
---
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 15 +++++++++++++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8764c9a..ef6f15d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1465,6 +1465,9 @@ struct ieee80211_txrx_stypes {
* @mgmt_stypes: bitmasks of frame subtypes that can be subscribed to or
* transmitted through nl80211, points to an array indexed by interface
* type
+ *
+ * @available_antennas: bitmap of antennas which are available to configure.
+ * antenna configuration commands will be rejected unless this is set.
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -1504,6 +1507,8 @@ struct wiphy {
u8 max_num_pmkids;
+ u32 available_antennas;
+
/* If multiple wiphys are registered and you're handed e.g.
* a regular netdev with assigned ieee80211_ptr, you won't
* know whether it points to a wiphy your driver has registered
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 2cf0333..5da02bd 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -547,7 +547,7 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
if (dev->wiphy.flags & WIPHY_FLAG_CONTROL_PORT_PROTOCOL)
NLA_PUT_FLAG(msg, NL80211_ATTR_CONTROL_PORT_ETHERTYPE);
- if (dev->ops->get_antenna) {
+ if (dev->wiphy.available_antennas && dev->ops->get_antenna) {
u32 tx_ant = 0, rx_ant = 0;
int res;
res = dev->ops->get_antenna(&dev->wiphy, &tx_ant, &rx_ant);
@@ -1045,7 +1045,7 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX] &&
info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]) {
u32 tx_ant, rx_ant;
- if (!rdev->ops->set_antenna) {
+ if (!rdev->wiphy.available_antennas || !rdev->ops->set_antenna) {
result = -EOPNOTSUPP;
goto bad_res;
}
@@ -1053,6 +1053,17 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
tx_ant = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX]);
rx_ant = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]);
+ /* reject antenna configurations which don't match the
+ * available antenna mask, except for the "all" mask */
+ if ((~tx_ant && (tx_ant & ~rdev->wiphy.available_antennas)) ||
+ (~rx_ant && (rx_ant & ~rdev->wiphy.available_antennas))) {
+ result = -EINVAL;
+ goto bad_res;
+ }
+
+ tx_ant = tx_ant & rdev->wiphy.available_antennas;
+ rx_ant = rx_ant & rdev->wiphy.available_antennas;
+
result = rdev->ops->set_antenna(&rdev->wiphy, tx_ant, rx_ant);
if (result)
goto bad_res;
^ permalink raw reply related
* Re: [PATCH v2] cfg80211: Add antenna availability information
From: Bruno Randolf @ 2010-12-08 4:49 UTC (permalink / raw)
To: johannes; +Cc: linville, linux-wireless
In-Reply-To: <20101208034429.24218.50707.stgit@localhost6.localdomain6>
Ah, please ignore this one and wait for v3...
bruno
On Wed December 8 2010 12:44:29 Bruno Randolf wrote:
> Add a field to wiphy for the hardware to report the availble antennas for
> configuration. Only if this is set to something bigger than zero, will the
> anntenna configuration ops be executed.
>
> Allthough this could be a simple number of antennas, I defined it as a
> bitmap of antennas which are available for configuration, since it's more
> consistent with the rest of the antenna API and there could be cases where
> the hardware allows only configuration of certain antennas. As it does not
> make much of a difference in size or normal usage, I think it's better to
> be able to support this, in case the need arises.
>
> The antenna configuration is now also checked against the availabe antennas
> and rejected if it does not match.
>
> Signed-off-by: Bruno Randolf <br1@einfach.org>
>
> v2: reject antenna configurations which don't match the available antennas
> ---
> include/net/cfg80211.h | 5 +++++
> net/wireless/nl80211.c | 12 ++++++++++--
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 8764c9a..ef6f15d 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1465,6 +1465,9 @@ struct ieee80211_txrx_stypes {
> * @mgmt_stypes: bitmasks of frame subtypes that can be subscribed to or
> * transmitted through nl80211, points to an array indexed by interface
> * type
> + *
> + * @available_antennas: bitmap of antennas which are available to
> configure. + * antenna configuration commands will be rejected unless
this
> is set. */
> struct wiphy {
> /* assign these fields before you register the wiphy */
> @@ -1504,6 +1507,8 @@ struct wiphy {
>
> u8 max_num_pmkids;
>
> + u32 available_antennas;
> +
> /* If multiple wiphys are registered and you're handed e.g.
> * a regular netdev with assigned ieee80211_ptr, you won't
> * know whether it points to a wiphy your driver has registered
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 2cf0333..4f6ff31 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -547,7 +547,7 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32
> pid, u32 seq, int flags, if (dev->wiphy.flags &
> WIPHY_FLAG_CONTROL_PORT_PROTOCOL)
> NLA_PUT_FLAG(msg, NL80211_ATTR_CONTROL_PORT_ETHERTYPE);
>
> - if (dev->ops->get_antenna) {
> + if (dev->wiphy.available_antennas && dev->ops->get_antenna) {
> u32 tx_ant = 0, rx_ant = 0;
> int res;
> res = dev->ops->get_antenna(&dev->wiphy, &tx_ant, &rx_ant);
> @@ -1045,7 +1045,7 @@ static int nl80211_set_wiphy(struct sk_buff *skb,
> struct genl_info *info) if (info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX] &&
> info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]) {
> u32 tx_ant, rx_ant;
> - if (!rdev->ops->set_antenna) {
> + if (!rdev->wiphy.available_antennas || !rdev->ops->set_antenna) {
> result = -EOPNOTSUPP;
> goto bad_res;
> }
> @@ -1053,6 +1053,14 @@ static int nl80211_set_wiphy(struct sk_buff *skb,
> struct genl_info *info) tx_ant =
> nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX]); rx_ant =
> nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]);
>
> + /* reject antenna configurations which don't match the
> + * available antenna mask, except for the "all" mask */
> + if ((~tx_ant && (tx_ant & ~rdev->wiphy.available_antennas)) ||
> + (~rx_ant && (rx_ant & ~rdev->wiphy.available_antennas))) {
> + result = -EINVAL;
> + goto bad_res;
> + }
> +
> result = rdev->ops->set_antenna(&rdev->wiphy, tx_ant, rx_ant);
> if (result)
> goto bad_res;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] nl80211: Export available antennas
From: Bruno Randolf @ 2010-12-08 3:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1291714540.3607.0.camel@jlt3.sipsolutions.net>
On Tue December 7 2010 18:35:40 Johannes Berg wrote:
> On Tue, 2010-12-07 at 11:17 +0900, Bruno Randolf wrote:
> > On Mon December 6 2010 17:33:20 Johannes Berg wrote:
> > > > > Finally, you should check for nl80211 that the given tx/rx masks
> > > > > fall into the available antennas mask.
> > > >
> > > > Allright, I can do that. Would you prefer to reject the command in
> > > > this case or just apply the available mask?
> > >
> > > I'd reject it, since userspace could have checked whether it was valid.
> >
> > Hmm, been thinking about it: the "iw phyX set antenna all" will not work
> > in that case. Unless we get the available antennas before setting "all"
> > in iw, which seems like a lot of overhead...
> >
> > Alternatively we can either apply the mask in mac80211 or just hand the
> > antenna masks as they are to the driver, which is what we do now.
>
> I think I'd be more happy with treating ~0 as special (which it is
> anyway, apply the mask to it) and allowing that to not match the mask.
> That way, the most common errors still don't have to be handled in the
> driver.
Allright. Sent a patch for this.
bruno
^ permalink raw reply
* [PATCH v2] cfg80211: Add antenna availability information
From: Bruno Randolf @ 2010-12-08 3:44 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless
Add a field to wiphy for the hardware to report the availble antennas for
configuration. Only if this is set to something bigger than zero, will the
anntenna configuration ops be executed.
Allthough this could be a simple number of antennas, I defined it as a bitmap
of antennas which are available for configuration, since it's more consistent
with the rest of the antenna API and there could be cases where the
hardware allows only configuration of certain antennas. As it does not make
much of a difference in size or normal usage, I think it's better to be able to
support this, in case the need arises.
The antenna configuration is now also checked against the availabe antennas and
rejected if it does not match.
Signed-off-by: Bruno Randolf <br1@einfach.org>
v2: reject antenna configurations which don't match the available antennas
---
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 12 ++++++++++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8764c9a..ef6f15d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1465,6 +1465,9 @@ struct ieee80211_txrx_stypes {
* @mgmt_stypes: bitmasks of frame subtypes that can be subscribed to or
* transmitted through nl80211, points to an array indexed by interface
* type
+ *
+ * @available_antennas: bitmap of antennas which are available to configure.
+ * antenna configuration commands will be rejected unless this is set.
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -1504,6 +1507,8 @@ struct wiphy {
u8 max_num_pmkids;
+ u32 available_antennas;
+
/* If multiple wiphys are registered and you're handed e.g.
* a regular netdev with assigned ieee80211_ptr, you won't
* know whether it points to a wiphy your driver has registered
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 2cf0333..4f6ff31 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -547,7 +547,7 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
if (dev->wiphy.flags & WIPHY_FLAG_CONTROL_PORT_PROTOCOL)
NLA_PUT_FLAG(msg, NL80211_ATTR_CONTROL_PORT_ETHERTYPE);
- if (dev->ops->get_antenna) {
+ if (dev->wiphy.available_antennas && dev->ops->get_antenna) {
u32 tx_ant = 0, rx_ant = 0;
int res;
res = dev->ops->get_antenna(&dev->wiphy, &tx_ant, &rx_ant);
@@ -1045,7 +1045,7 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX] &&
info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]) {
u32 tx_ant, rx_ant;
- if (!rdev->ops->set_antenna) {
+ if (!rdev->wiphy.available_antennas || !rdev->ops->set_antenna) {
result = -EOPNOTSUPP;
goto bad_res;
}
@@ -1053,6 +1053,14 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
tx_ant = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX]);
rx_ant = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]);
+ /* reject antenna configurations which don't match the
+ * available antenna mask, except for the "all" mask */
+ if ((~tx_ant && (tx_ant & ~rdev->wiphy.available_antennas)) ||
+ (~rx_ant && (rx_ant & ~rdev->wiphy.available_antennas))) {
+ result = -EINVAL;
+ goto bad_res;
+ }
+
result = rdev->ops->set_antenna(&rdev->wiphy, tx_ant, rx_ant);
if (result)
goto bad_res;
^ permalink raw reply related
* Re: [PATCH 0/4] Make N-PHY support experimental
From: Larry Finger @ 2010-12-08 3:37 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Rafał Miłecki, linux-wireless, John W. Linville,
b43-dev
In-Reply-To: <AANLkTikp9ErFopLZVmXMjN3tXF2L62SwEEcujKeOBLYC@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
As shown in the NetworkManager log attached, Authentication is successful, but
DHCP fails. Either the transmit data is improperly encrypted, or the decryption
fails. I will use wireshark to sort that out. Note: Using software encryption
makes no difference.
Larry
[-- Attachment #2: nm.log --]
[-- Type: text/x-log, Size: 19096 bytes --]
Dec 7 21:13:37 larrylap NetworkManager: <info> (wlan5): device state change: 8 -> 3 (reason 0)
Dec 7 21:13:37 larrylap NetworkManager: <info> (wlan5): deactivating device (reason: 0).
Dec 7 21:13:37 larrylap NetworkManager: <info> (wlan5): canceled DHCP transaction, dhcp client pid 5982
Dec 7 21:13:37 larrylap NetworkManager: <WARN> check_one_route(): (wlan5) error -34 returned from rtnl_route_del(): Sucess#012
Dec 7 21:13:37 larrylap NetworkManager: <debug> [1291778017.386964] run_netconfig(): Spawning '/sbin/netconfig modify --service NetworkManager'
Dec 7 21:13:37 larrylap NetworkManager: <debug> [1291778017.403700] write_to_netconfig(): Writing to netconfig: INTERFACE='wlan5'#012
Dec 7 21:13:37 larrylap NetworkManager: <info> Clearing nscd hosts cache.
Dec 7 21:13:37 larrylap NetworkManager: <info> Activation (wlan5) starting connection 'lwfdjf_rad'
Dec 7 21:13:37 larrylap NetworkManager: <info> (wlan5): device state change: 3 -> 4 (reason 0)
Dec 7 21:13:37 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec 7 21:13:37 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec 7 21:13:37 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec 7 21:13:37 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec 7 21:13:37 larrylap NetworkManager: <info> (wlan5): supplicant connection state: completed -> disconnected
Dec 7 21:13:37 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec 7 21:13:37 larrylap NetworkManager: <info> (wlan5): device state change: 4 -> 5 (reason 0)
Dec 7 21:13:37 larrylap NetworkManager: <info> Activation (wlan5/wireless): connection 'lwfdjf_rad' has security, and secrets exist. No new secrets needed
.
Dec 7 21:13:37 larrylap NetworkManager: <info> Config: added 'ssid' value 'lwfdjf_rad'
Dec 7 21:13:37 larrylap NetworkManager: <info> Config: added 'scan_ssid' value '1'
Dec 7 21:13:37 larrylap NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Dec 7 21:13:37 larrylap NetworkManager: <info> Config: added 'psk' value '<omitted>'
Dec 7 21:13:37 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec 7 21:13:37 larrylap NetworkManager: <info> Config: set interface ap_scan to 1
Dec 7 21:13:37 larrylap NetworkManager: <info> (wlan5): supplicant connection state: disconnected -> scanning
Dec 7 21:13:37 larrylap nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/autofs' exited with error status 1.
Dec 7 21:13:38 larrylap NetworkManager: <info> (wlan5): supplicant connection state: scanning -> associating
Dec 7 21:13:38 larrylap NetworkManager: <info> (wlan5): supplicant connection state: associating -> associated
Dec 7 21:13:38 larrylap NetworkManager: <info> (wlan5): supplicant connection state: associated -> 4-way handshake
Dec 7 21:13:38 larrylap NetworkManager: <info> (wlan5): supplicant connection state: 4-way handshake -> group handshake
Dec 7 21:13:38 larrylap NetworkManager: <info> (wlan5): supplicant connection state: group handshake -> completed
Dec 7 21:13:38 larrylap NetworkManager: <info> Activation (wlan5/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'lwfdjf_rad'.
Dec 7 21:13:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) scheduled.
Dec 7 21:13:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) started...
Dec 7 21:13:38 larrylap NetworkManager: <info> (wlan5): device state change: 5 -> 7 (reason 0)
Dec 7 21:13:38 larrylap NetworkManager: <info> Activation (wlan5) Beginning DHCP transaction (timeout in 45 seconds)
Dec 7 21:13:38 larrylap NetworkManager: <info> dhclient started with pid 7150
Dec 7 21:13:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) scheduled...
Dec 7 21:13:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) complete.
Dec 7 21:13:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) started...
Dec 7 21:13:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) complete.
Dec 7 21:13:38 larrylap NetworkManager: <info> DHCP: device wlan5 state changed normal exit -> preinit
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): device state change: 7 -> 3 (reason 0)
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): deactivating device (reason: 0).
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): canceled DHCP transaction, dhcp client pid 7150
Dec 7 21:14:19 larrylap NetworkManager: <info> Activation (wlan5) starting connection 'Larry_wep'
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): device state change: 3 -> 4 (reason 0)
Dec 7 21:14:19 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec 7 21:14:19 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec 7 21:14:19 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec 7 21:14:19 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec 7 21:14:19 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): device state change: 4 -> 5 (reason 0)
Dec 7 21:14:19 larrylap NetworkManager: <info> Activation (wlan5/wireless): access point 'Larry_wep' has security, but secrets are required.
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): device state change: 5 -> 6 (reason 0)
Dec 7 21:14:19 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): supplicant connection state: completed -> disconnected
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): device state change: 6 -> 3 (reason 38)
Dec 7 21:14:19 larrylap NetworkManager: <info> (wlan5): deactivating device (reason: 38).
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) starting connection 'lwfdjf_rad'
Dec 7 21:14:23 larrylap NetworkManager: <info> (wlan5): device state change: 3 -> 4 (reason 0)
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec 7 21:14:23 larrylap NetworkManager: <info> (wlan5): device state change: 4 -> 5 (reason 0)
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5/wireless): access point 'lwfdjf_rad' has security, but secrets are required.
Dec 7 21:14:23 larrylap NetworkManager: <info> (wlan5): device state change: 5 -> 6 (reason 0)
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec 7 21:14:23 larrylap NetworkManager: <WARN> secrets_update_setting(): Failed to update connection secrets: 1 802-1x
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec 7 21:14:23 larrylap NetworkManager: <info> (wlan5): device state change: 6 -> 4 (reason 0)
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec 7 21:14:23 larrylap NetworkManager: <info> (wlan5): device state change: 4 -> 5 (reason 0)
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5/wireless): connection 'lwfdjf_rad' has security, and secrets exist. No new secrets needed.
Dec 7 21:14:23 larrylap NetworkManager: <info> Config: added 'ssid' value 'lwfdjf_rad'
Dec 7 21:14:23 larrylap NetworkManager: <info> Config: added 'scan_ssid' value '1'
Dec 7 21:14:23 larrylap NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Dec 7 21:14:23 larrylap NetworkManager: <info> Config: added 'psk' value '<omitted>'
Dec 7 21:14:23 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec 7 21:14:23 larrylap NetworkManager: <info> Config: set interface ap_scan to 1
Dec 7 21:14:23 larrylap NetworkManager: <info> (wlan5): supplicant connection state: disconnected -> scanning
Dec 7 21:14:24 larrylap NetworkManager: <info> (wlan5): supplicant connection state: scanning -> associating
Dec 7 21:14:24 larrylap NetworkManager: <info> (wlan5): supplicant connection state: associating -> associated
Dec 7 21:14:24 larrylap NetworkManager: <info> (wlan5): supplicant connection state: associated -> 4-way handshake
Dec 7 21:14:24 larrylap NetworkManager: <info> (wlan5): supplicant connection state: 4-way handshake -> group handshake
Dec 7 21:14:24 larrylap NetworkManager: <info> (wlan5): supplicant connection state: group handshake -> completed
Dec 7 21:14:24 larrylap NetworkManager: <info> Activation (wlan5/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'lwfdjf_rad'.
Dec 7 21:14:24 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) scheduled.
Dec 7 21:14:24 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) started...
Dec 7 21:14:24 larrylap NetworkManager: <info> (wlan5): device state change: 5 -> 7 (reason 0)
Dec 7 21:14:24 larrylap NetworkManager: <info> Activation (wlan5) Beginning DHCP transaction (timeout in 45 seconds)
Dec 7 21:14:24 larrylap NetworkManager: <info> dhclient started with pid 7177
Dec 7 21:14:24 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) scheduled...
Dec 7 21:14:24 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) complete.
Dec 7 21:14:24 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) started...
Dec 7 21:14:24 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) complete.
Dec 7 21:14:24 larrylap NetworkManager: <info> DHCP: device wlan5 state changed normal exit -> preinit
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): device state change: 7 -> 3 (reason 0)
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): deactivating device (reason: 0).
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): canceled DHCP transaction, dhcp client pid 7177
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) starting connection 'Larry_wep'
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): device state change: 3 -> 4 (reason 0)
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): supplicant connection state: completed -> disconnected
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): device state change: 4 -> 5 (reason 0)
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5/wireless): access point 'Larry_wep' has security, but secrets are required.
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): device state change: 5 -> 6 (reason 0)
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec 7 21:14:32 larrylap NetworkManager: <WARN> secrets_update_setting(): Failed to update connection secrets: 1 802-1x
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) scheduled...
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) started...
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): device state change: 6 -> 4 (reason 0)
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) scheduled...
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 1 of 5 (Device Prepare) complete.
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) starting...
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): device state change: 4 -> 5 (reason 0)
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5/wireless): connection 'Larry_wep' has security, and secrets exist. No new secrets needed.
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: added 'ssid' value 'Larry_wep'
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: added 'scan_ssid' value '1'
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: added 'key_mgmt' value 'NONE'
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: added 'wep_key0' value '<omitted>'
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: added 'wep_key1' value '<omitted>'
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: added 'wep_key2' value '<omitted>'
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: added 'wep_key3' value '<omitted>'
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: added 'wep_tx_keyidx' value '0'
Dec 7 21:14:32 larrylap NetworkManager: <info> Activation (wlan5) Stage 2 of 5 (Device Configure) complete.
Dec 7 21:14:32 larrylap NetworkManager: <info> Config: set interface ap_scan to 1
Dec 7 21:14:32 larrylap NetworkManager: <info> (wlan5): supplicant connection state: disconnected -> scanning
Dec 7 21:14:34 larrylap NetworkManager: <info> (wlan5): supplicant connection state: scanning -> associating
Dec 7 21:14:34 larrylap NetworkManager: <info> (wlan5): supplicant connection state: associating -> associated
Dec 7 21:14:34 larrylap NetworkManager: <info> (wlan5): supplicant connection state: associated -> completed
Dec 7 21:14:34 larrylap NetworkManager: <info> Activation (wlan5/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'Larry_wep'.
Dec 7 21:14:34 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) scheduled.
Dec 7 21:14:34 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) started...
Dec 7 21:14:34 larrylap NetworkManager: <info> (wlan5): device state change: 5 -> 7 (reason 0)
Dec 7 21:14:34 larrylap NetworkManager: <info> Activation (wlan5) Beginning DHCP transaction (timeout in 45 seconds)
Dec 7 21:14:34 larrylap NetworkManager: <info> dhclient started with pid 7187
Dec 7 21:14:34 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) scheduled...
Dec 7 21:14:34 larrylap NetworkManager: <info> Activation (wlan5) Stage 3 of 5 (IP Configure Start) complete.
Dec 7 21:14:34 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) started...
Dec 7 21:14:34 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP6 Configure Get) complete.
Dec 7 21:14:34 larrylap NetworkManager: <info> DHCP: device wlan5 state changed normal exit -> preinit
Dec 7 21:14:38 larrylap NetworkManager: <info> DHCP: device wlan5 state changed preinit -> reboot
Dec 7 21:14:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP4 Configure Get) scheduled...
Dec 7 21:14:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP4 Configure Get) started...
Dec 7 21:14:38 larrylap NetworkManager: <info> address 192.168.3.102
Dec 7 21:14:38 larrylap NetworkManager: <info> prefix 24 (255.255.255.0)
Dec 7 21:14:38 larrylap NetworkManager: <info> gateway 192.168.3.1
Dec 7 21:14:38 larrylap NetworkManager: <info> nameserver '192.168.2.1'
Dec 7 21:14:38 larrylap NetworkManager: <info> domain name 'lan'
Dec 7 21:14:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 5 of 5 (IP Configure Commit) scheduled...
Dec 7 21:14:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 4 of 5 (IP4 Configure Get) complete.
Dec 7 21:14:38 larrylap NetworkManager: <info> Activation (wlan5) Stage 5 of 5 (IP Configure Commit) started...
Dec 7 21:14:39 larrylap NetworkManager: <debug> [1291778079.043901] run_netconfig(): Spawning '/sbin/netconfig modify --service NetworkManager'
Dec 7 21:14:39 larrylap NetworkManager: <debug> [1291778079.056161] write_to_netconfig(): Writing to netconfig: INTERFACE='wlan5'#012
Dec 7 21:14:39 larrylap NetworkManager: <debug> [1291778079.056433] write_to_netconfig(): Writing to netconfig: DNSSEARCH='lan lan'#012
Dec 7 21:14:39 larrylap NetworkManager: <debug> [1291778079.056500] write_to_netconfig(): Writing to netconfig: DNSSERVERS='192.168.2.1'#012
Dec 7 21:14:39 larrylap NetworkManager: <info> Clearing nscd hosts cache.
Dec 7 21:14:39 larrylap NetworkManager: <info> (wlan5): device state change: 7 -> 8 (reason 0)
Dec 7 21:14:39 larrylap NetworkManager: <debug> [1291778079.088730] run_netconfig(): Spawning '/sbin/netconfig modify --service NetworkManager'
Dec 7 21:14:39 larrylap NetworkManager: <debug> [1291778079.119134] write_to_netconfig(): Writing to netconfig: INTERFACE='wlan5'#012
Dec 7 21:14:39 larrylap NetworkManager: <debug> [1291778079.119375] write_to_netconfig(): Writing to netconfig: DNSSEARCH='lan lan'#012
Dec 7 21:14:39 larrylap NetworkManager: <debug> [1291778079.119435] write_to_netconfig(): Writing to netconfig: DNSSERVERS='192.168.2.1'#012
Dec 7 21:14:39 larrylap NetworkManager: <info> Clearing nscd hosts cache.
Dec 7 21:14:39 larrylap NetworkManager: <info> Policy set 'Larry_wep' (wlan5) as default for routing and DNS.
Dec 7 21:14:39 larrylap NetworkManager: <info> Activation (wlan5) successful, device activated.
Dec 7 21:14:39 larrylap NetworkManager: <info> Activation (wlan5) Stage 5 of 5 (IP Configure Commit) complete.
Dec 7 21:14:39 larrylap nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/autofs' exited with error status 1.
^ permalink raw reply
* Re: [PATCH 2/2] ath9k_htc: Fix suspend/resume
From: Sujith @ 2010-12-08 2:04 UTC (permalink / raw)
To: John W. Linville; +Cc: Sujith, Luis R. Rodriguez, linux-wireless
In-Reply-To: <20101207194646.GG2700@tuxdriver.com>
John W. Linville wrote:
> Obviously I didn't overlook it, or I wouldn't have asked about whether
> or not it should go to 2.6.37...
Sorry, I saw the other patch [1/2] merged and thought that you missed this.
> > Applying 4/5 and 5/5 from your series seems to fix the issue though.
> > I am able to suspend/resume without hiccups with UB95.
>
> But now this begs the question of whether this should be applied at all?
Yes, this is needed for ath9k_htc.
Sujith
^ permalink raw reply
* Re: [PATCH 1/4] b43: N-PHY: update init tables
From: ikorot @ 2010-12-08 1:55 UTC (permalink / raw)
To: Larry Finger; +Cc: Hauke Mehrtens, linux-wireless, b43-dev
Larry,
-----Original Message-----
>From: Larry Finger <Larry.Finger@lwfinger.net>
>Sent: Dec 7, 2010 12:00 PM
>To: ikorot@earthlink.net
>Cc: Hauke Mehrtens <hauke@hauke-m.de>, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
>Subject: Re: [PATCH 1/4] b43: N-PHY: update init tables
>
>On 12/07/2010 01:49 PM, ikorot@earthlink.net wrote:
>>> One reason is that these tables changed from non-zero to zero values between
>>> Broadcom driver 4.174.64.19 and 5.10.56.46. As they might change again, I think
>>> we should retain the full version.
>>
>> Is there a way to check for version of the driver?
>> This way whoever uses old one won't be screwed...
>
>That will not be a problem as no older version of b43 works at all with b43. To
>help you understand this change, when the 4.174.64.19 Broadcom driver was
>reverse-engineered, the tables had non-zero values. Rafel later compared the
>trace dumps of b43 with the latest version of wl and found that the values are
>now zero. When I rechecked driver 5.10.56.46, I found them to be zero there as
>well and changed the specs.
Well, it maybe feasible to keep the old values and check
the version of the driver, since you are saying yourself
that the value might be changing in the future.
Maybe for couple of releases only?
Thank you.
>
>Larry
^ permalink raw reply
* Re: [PATCH] ath5k: Use capabilities information for the number of TX queues
From: Bruno Randolf @ 2010-12-08 1:13 UTC (permalink / raw)
To: John W. Linville; +Cc: ath5k-devel, linux-wireless
In-Reply-To: <20101207140120.GA2700@tuxdriver.com>
On Tue December 7 2010 23:01:21 John W. Linville wrote:
> On Tue, Dec 07, 2010 at 11:08:12AM +0900, Bruno Randolf wrote:
> > One thing I missed in my WME series: Older hardware does not have enough
> > hardware queues to support WME. In this case we just set up one data
> > queue. Use the capability information to decide how many queues to set
> > up.
> >
> > Signed-off-by: Bruno Randolf <br1@einfach.org>
> >
> > --
> >
> > resend, seems like it got lost somewhere in a queue ;)
>
> Did you originally post with a different subject? The MARC archive
> doesn't seem to see any prior posting.
Sorry, I accidentially posted only to the ath5k lists before. My fault.
bruno
^ permalink raw reply
* Re: [PATCH 2.6.37] ath9k: fix a DMA related race condition on reset
From: Ben Greear @ 2010-12-08 0:46 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1291576673-1462-1-git-send-email-nbd@openwrt.org>
On 12/05/2010 11:17 AM, Felix Fietkau wrote:
> When ath_drain_all_txq fails to stop DMA, it issues a hw reset. This reset
> happens at a very problematic point in time, when the hardware rx path has
> not been stopped yet. This could lead to memory corruption, hardware hangs
> or other issues.
> To fix these issues, simply remove the reset entirely and check the tx DMA
> stop status to prevent problems with fast channel changes.
Should we put this change into wireless-testing as well?
Thanks,
Ben
>
> Signed-off-by: Felix Fietkau<nbd@openwrt.org>
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
> drivers/net/wireless/ath/ath9k/main.c | 5 +++--
> drivers/net/wireless/ath/ath9k/xmit.c | 22 ++++++----------------
> 3 files changed, 10 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
> index 0d0bec3..0963071 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -329,7 +329,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp);
> struct ath_txq *ath_txq_setup(struct ath_softc *sc, int qtype, int subtype);
> void ath_tx_cleanupq(struct ath_softc *sc, struct ath_txq *txq);
> int ath_tx_setup(struct ath_softc *sc, int haltype);
> -void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx);
> +bool ath_drain_all_txq(struct ath_softc *sc, bool retry_tx);
> void ath_draintxq(struct ath_softc *sc,
> struct ath_txq *txq, bool retry_tx);
> void ath_tx_node_init(struct ath_softc *sc, struct ath_node *an);
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index dace215..928ef68 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -244,11 +244,12 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
> * the relevant bits of the h/w.
> */
> ath9k_hw_set_interrupts(ah, 0);
> - ath_drain_all_txq(sc, false);
> + stopped = ath_drain_all_txq(sc, false);
>
> spin_lock_bh(&sc->rx.pcu_lock);
>
> - stopped = ath_stoprecv(sc);
> + if (!ath_stoprecv(sc))
> + stopped = false;
>
> /* XXX: do not flush receive queue here. We don't want
> * to flush data frames already in queue because of
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index f2ade24..aff0478 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -1120,7 +1120,7 @@ void ath_draintxq(struct ath_softc *sc, struct ath_txq *txq, bool retry_tx)
> }
> }
>
> -void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
> +bool ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
> {
> struct ath_hw *ah = sc->sc_ah;
> struct ath_common *common = ath9k_hw_common(sc->sc_ah);
> @@ -1128,7 +1128,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
> int i, npend = 0;
>
> if (sc->sc_flags& SC_OP_INVALID)
> - return;
> + return true;
>
> /* Stop beacon queue */
> ath9k_hw_stoptxdma(sc->sc_ah, sc->beacon.beaconq);
> @@ -1142,25 +1142,15 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
> }
> }
>
> - if (npend) {
> - int r;
> -
> - ath_print(common, ATH_DBG_FATAL,
> - "Failed to stop TX DMA. Resetting hardware!\n");
> -
> - spin_lock_bh(&sc->sc_resetlock);
> - r = ath9k_hw_reset(ah, sc->sc_ah->curchan, ah->caldata, false);
> - if (r)
> - ath_print(common, ATH_DBG_FATAL,
> - "Unable to reset hardware; reset status %d\n",
> - r);
> - spin_unlock_bh(&sc->sc_resetlock);
> - }
> + if (npend)
> + ath_print(common, ATH_DBG_FATAL, "Failed to stop TX DMA!\n");
>
> for (i = 0; i< ATH9K_NUM_TX_QUEUES; i++) {
> if (ATH_TXQ_SETUP(sc, i))
> ath_draintxq(sc,&sc->tx.txq[i], retry_tx);
> }
> +
> + return !npend;
> }
>
> void ath_tx_cleanupq(struct ath_softc *sc, struct ath_txq *txq)
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/2] ath9k_htc: Fix suspend/resume
From: Luis R. Rodriguez @ 2010-12-07 23:18 UTC (permalink / raw)
To: John W. Linville; +Cc: Sujith, linux-wireless
In-Reply-To: <20101207194646.GG2700@tuxdriver.com>
On Tue, Dec 7, 2010 at 11:46 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Tue, Dec 07, 2010 at 09:39:10AM +0530, Sujith wrote:
>> Luis R. Rodriguez wrote:
>> > Just curious, if you revert this patch and apply the ones I just
>> > posted, does it fix it, or is this patch required either way?
>>
>> Well, I don't see this patch in -testing, -next-2.6 or -2.6.
>> Maybe Linville overlooked this patch.
>
> Obviously I didn't overlook it, or I wouldn't have asked about whether
> or not it should go to 2.6.37...
>
>> Applying 4/5 and 5/5 from your series seems to fix the issue though.
>> I am able to suspend/resume without hiccups with UB95.
>
> But now this begs the question of whether this should be applied at all?
As I reviewed with Johannes the driver must ensure the device remains
idle after we get the last stop() call. So this patch seems fine, I'd
even consider removing the check for the if (!(hif_dev->flags &
HIF_USB_START)) and also call ath9k_htc_suspend(hif_dev->htc_handle);
upon resume to ensure it is kept in full sleep then as well.
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox