* Re: [PATCH] minstrel_ht: mark minstrel_mcs_groups as static
From: Felix Fietkau @ 2010-06-24 16:47 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1277392602-10578-1-git-send-email-linville@tuxdriver.com>
On 2010-06-24 5:16 PM, John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> net/mac80211/rc80211_minstrel_ht.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
> index 7a04951..a8f658c 100644
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -59,7 +59,7 @@
> * groups, based on the number of streams and flags (HT40, SGI) that they
> * use.
> */
> -const struct mcs_group minstrel_mcs_groups[] = {
> +static const struct mcs_group minstrel_mcs_groups[] = {
NACK. minstrel_ht debugfs needs this. The proper fix for the warning is
to add this one to a header file instead.
- Felix
^ permalink raw reply
* Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Helmut Schaa @ 2010-06-24 16:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <1277394714.3870.8.camel@jlt3.sipsolutions.net>
Am Donnerstag 24 Juni 2010 schrieb Johannes Berg:
> a) You get a new beacon from mac80211 each time you send it. Then you
> don't have to worry about the set_tim() callback at all -- don't
> assign it!
>
> b) You need to get a new beacon frame from mac80211 only when it
> changes. You can do this from set_tim(). HOWEVER: since you're not
> getting a new one from mac80211 all the time anyway, you NEED to
> have the driver or firmware overwrite the DTIM count, like b43's
> firmware for example will do.
>
> Ok so maybe there are more possibilities like the firmware filling the
> TIM IE differently and you would use set_tim() differently then.
>
> However, *fundamentally*, any time you don't get a new skb from mac80211
> for each transmitted beacon you NEED to overwrite the DTIM count in it.
So, to answer my own question:
mac80211 behaves as designed and we need to fix rt2x00 to correctly update
the DTIM parameters when we stick to the set_tim callback for updating the
beacon template (option b).
Or we would implement option a) to get a new beacon prior to transmission
and would get a correct DTIM count from mac80211.
Thanks for the clarification,
Helmut
^ permalink raw reply
* Re: intel 5100/iwlagn bug in 2.6.35-rc2 during large file transfer
From: Richard Farina @ 2010-06-24 16:12 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1277225293.25793.2257.camel@rchatre-DESK>
reinette chatre wrote:
> On Wed, 2010-06-16 at 19:56 -0700, Richard Farina wrote:
>
>> The repeated line appears ad infinitum filling my dmesg buffer. This of
>> hangcheck timer seem to trigger with every large file transfer on my
>> intel 5100. What would you like me to do to provide a more useful
>> output as this is currently extremely easy to reproduce. Kernel 2.6.34
>> using compat-wireless stable 2.6.35-rc2
>>
>> Thanks,
>> Rick Farina
>>
>> phy0: failed to reallocate TX buffer
>> phy0: failed to reallocate TX buffer
>> phy0: failed to reallocate TX buffer
>> phy0: failed to reallocate TX buffer
>> phy0: failed to reallocate TX buffer
>> phy0: failed to reallocate TX buffer
>> phy0: failed to reallocate TX buffer
>>
>
> First mac80211 runs out of memory ... it cannot even allocate enough
> memory for a skb header.
>
>
>> net_ratelimit: 22 callbacks suppressed
>> __alloc_pages_slowpath: 3799 callbacks suppressed
>> swapper: page allocation failure. order:1, mode:0x4020
>> Pid: 0, comm: swapper Not tainted 2.6.34-pentoo #5
>> Call Trace:
>> <IRQ> [<ffffffff8109cb74>] __alloc_pages_nodemask+0x571/0x5b9
>> [<ffffffff816732e9>] ? skb_release_data+0xc4/0xc9
>> [<ffffffffa04701e4>] iwlagn_rx_allocate+0x98/0x25a [iwlagn]
>>
>
> Next driver runs out of memory.
>
> Note that the above are all atomic allocations that fail and should be
> able to recover.
>
> Is your system low on memory? Are you running applications that take a
> lot of memory? Does your wifi connection drop or otherwise suffer at the
> time you see these messages?
>
>
I have 4GB of RAM on this system, I often run a VM which wastes like
half that but that still leaves 2GB for linux and I'm running XFCE4 so
not exactly a memory hog. It's possible that firefox leaks ram until I'm
out but that would be a LOT of leak, much more than I usually see.
Yeah, as you may guess these errors cause my wifi connection to slow
drastically. If I had to guess, since this happens when I make a large
file transfer it is likely that something related is leaking RAM. I'm
using wget or axel to download and NFS to dump the files on a NAS. I'll
try to trigger this again and watch memory usage to see if I can find
something other than the driver that could be leaking. Failing that,
what do I need to enable to find a leak in the driver?
Thanks,
Rick Farina
> Reinette
>
>
>
>
>
^ permalink raw reply
* Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Johannes Berg @ 2010-06-24 15:54 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <1277394837.3870.9.camel@jlt3.sipsolutions.net>
On Thu, 2010-06-24 at 17:53 +0200, Johannes Berg wrote:
> On Thu, 2010-06-24 at 17:51 +0200, Johannes Berg wrote:
>
> > b) You need to get a new beacon frame from mac80211 only when it
> > changes. You can do this from set_tim(). HOWEVER: since you're not
> > getting a new one from mac80211 all the time anyway, you NEED to
> > have the driver or firmware overwrite the DTIM count, like b43's
> > firmware for example will do.
>
> Oh and "when it changes" doesn't include DTIM period changes, obviously.
Er, it does include "DTIM period" changes (shouldn't actually happen
anyway), I meant "DTIM count field changes".
johannes
^ permalink raw reply
* Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Johannes Berg @ 2010-06-24 15:53 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <1277394714.3870.8.camel@jlt3.sipsolutions.net>
On Thu, 2010-06-24 at 17:51 +0200, Johannes Berg wrote:
> b) You need to get a new beacon frame from mac80211 only when it
> changes. You can do this from set_tim(). HOWEVER: since you're not
> getting a new one from mac80211 all the time anyway, you NEED to
> have the driver or firmware overwrite the DTIM count, like b43's
> firmware for example will do.
Oh and "when it changes" doesn't include DTIM period changes, obviously.
johannes
^ permalink raw reply
* Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Johannes Berg @ 2010-06-24 15:51 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <201006241521.47623.helmut.schaa@googlemail.com>
On Thu, 2010-06-24 at 15:21 +0200, Helmut Schaa wrote:
> I've just reviewed the beacon handling in rt2x00 in AP mode and experienced
> some inconsistencies. The DTIM count is not correctly updated: sometimes
> multiple beacons are sent out using the same DTIM count.
Er, so there's your problem already.
> rt2x00 calls ieee80211_beacon_get_tim right after the current beacon was
> sent out to fetch the next one. However, rt2x00 also implements the set_tim
> callback and updates the beacon in each call to set_tim. As far as I
> understood the code in mac80211 the set_tim callback is called when the
> first frame for a powersaving station gets queued.
>
> Since every call to ieee80211_beacon_get_tim updates the DTIM count the
> following can happen (assuming a DTIM period of 2):
>
> - the hw sends out the current beacon (DTIM count == 0)
> - call to ieee80211_beacon_get_tim fetches the next beacon (DTIM count == 1)
> - the first frame for a PS STA gets queued -> set_tim
> - again call ieee80211_beacon_get_tim (DTIM count == 0)
> - hw sends out the beacon with incorrect DTIM count
>
> A proper way of fixing this issue would be not to use the set_tim callback but
> just fetch the next beacon right before it gets send out (like ath* does).
> However, that's not easily possible with rt2x00 devices older then rt2800 as
> they only generate beacon_done interrupts (which is obviously too late for
> fetching the current beacon ;) ).
>
> So, is the current implementation in rt2x00 supposed to work and mac80211
> needs fixing?
>
> Could we add a parameter to ieee80211_beacon_get_tim that indicates if a _new_
> beacon should be generated or if the _current_ beacon should be updated in
> response to the set_tim callback?
>
> Any other ideas?
No, your entire description makes no sense. There are two possibilities:
a) You get a new beacon from mac80211 each time you send it. Then you
don't have to worry about the set_tim() callback at all -- don't
assign it!
b) You need to get a new beacon frame from mac80211 only when it
changes. You can do this from set_tim(). HOWEVER: since you're not
getting a new one from mac80211 all the time anyway, you NEED to
have the driver or firmware overwrite the DTIM count, like b43's
firmware for example will do.
Ok so maybe there are more possibilities like the firmware filling the
TIM IE differently and you would use set_tim() differently then.
However, *fundamentally*, any time you don't get a new skb from mac80211
for each transmitted beacon you NEED to overwrite the DTIM count in it.
johannes
^ permalink raw reply
* [PATCH] minstrel_ht: make *idx unsigned in minstrel_downgrade_rate
From: John W. Linville @ 2010-06-24 15:19 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
net/mac80211/rc80211_minstrel_ht.c:440:46: warning: incorrect type in argument 2 (different signedness)
net/mac80211/rc80211_minstrel_ht.c:440:46: expected int *idx
net/mac80211/rc80211_minstrel_ht.c:440:46: got unsigned int *<noident>
net/mac80211/rc80211_minstrel_ht.c:446:46: warning: incorrect type in argument 2 (different signedness)
net/mac80211/rc80211_minstrel_ht.c:446:46: expected int *idx
net/mac80211/rc80211_minstrel_ht.c:446:46: got unsigned int *<noident>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/rc80211_minstrel_ht.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index a8f658c..ae91ad9 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -328,7 +328,8 @@ minstrel_next_sample_idx(struct minstrel_ht_sta *mi)
}
static void
-minstrel_downgrade_rate(struct minstrel_ht_sta *mi, int *idx, bool primary)
+minstrel_downgrade_rate(struct minstrel_ht_sta *mi, unsigned int *idx,
+ bool primary)
{
int group, orig_group;
--
1.7.0.1
^ permalink raw reply related
* [PATCH] minstrel_ht: mark minstrel_mcs_groups as static
From: John W. Linville @ 2010-06-24 15:16 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/rc80211_minstrel_ht.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 7a04951..a8f658c 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -59,7 +59,7 @@
* groups, based on the number of streams and flags (HT40, SGI) that they
* use.
*/
-const struct mcs_group minstrel_mcs_groups[] = {
+static const struct mcs_group minstrel_mcs_groups[] = {
MCS_GROUP(1, 0, 0),
MCS_GROUP(2, 0, 0),
#if MINSTREL_MAX_STREAMS >= 3
--
1.7.0.1
^ permalink raw reply related
* [PATCH] wireless: mark reg_mutex as static
From: John W. Linville @ 2010-06-24 15:27 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/reg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 994c7c5..1ac2bdd 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -80,7 +80,7 @@ static const struct ieee80211_regdomain *country_ie_regdomain;
* - country_ie_regdomain
* - last_request
*/
-DEFINE_MUTEX(reg_mutex);
+static DEFINE_MUTEX(reg_mutex);
#define assert_reg_lock() WARN_ON(!mutex_is_locked(®_mutex))
/* Used to queue up regulatory hints */
--
1.7.0.1
^ permalink raw reply related
* [PATCH] mac80211: don't shadow mgmt variable in ieee80211_rx_h_action
From: John W. Linville @ 2010-06-24 15:14 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
net/mac80211/rx.c:2059:39: warning: symbol 'mgmt' shadows an earlier one
net/mac80211/rx.c:1916:31: originally declared here
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/rx.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 1f76352..ab58a5d 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2056,11 +2056,11 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
nskb = skb_copy_expand(rx->skb, local->hw.extra_tx_headroom, 0,
GFP_ATOMIC);
if (nskb) {
- struct ieee80211_mgmt *mgmt = (void *)nskb->data;
+ struct ieee80211_mgmt *nmgmt = (void *)nskb->data;
- mgmt->u.action.category |= 0x80;
- memcpy(mgmt->da, mgmt->sa, ETH_ALEN);
- memcpy(mgmt->sa, rx->sdata->vif.addr, ETH_ALEN);
+ nmgmt->u.action.category |= 0x80;
+ memcpy(nmgmt->da, nmgmt->sa, ETH_ALEN);
+ memcpy(nmgmt->sa, rx->sdata->vif.addr, ETH_ALEN);
memset(nskb->cb, 0, sizeof(nskb->cb));
--
1.7.0.1
^ permalink raw reply related
* [PATCH] rtl8180: mark rtl8180_beacon_work static
From: John W. Linville @ 2010-06-24 15:09 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180_dev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index 515817d..4270502 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -671,7 +671,7 @@ static u64 rtl8180_get_tsf(struct ieee80211_hw *dev)
(u64)(rtl818x_ioread32(priv, &priv->map->TSFT[1])) << 32;
}
-void rtl8180_beacon_work(struct work_struct *work)
+static void rtl8180_beacon_work(struct work_struct *work)
{
struct rtl8180_vif *vif_priv =
container_of(work, struct rtl8180_vif, beacon_work.work);
--
1.7.0.1
^ permalink raw reply related
* Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: John W. Linville @ 2010-06-24 14:32 UTC (permalink / raw)
To: Helmut Schaa
Cc: linux-wireless, Johannes Berg, Ivo van Doorn,
Gertjan van Wingerde
In-Reply-To: <201006241521.47623.helmut.schaa@googlemail.com>
On Thu, Jun 24, 2010 at 03:21:47PM +0200, Helmut Schaa wrote:
> So, is the current implementation in rt2x00 supposed to work and mac80211
> needs fixing?
>
> Could we add a parameter to ieee80211_beacon_get_tim that indicates if a _new_
> beacon should be generated or if the _current_ beacon should be updated in
> response to the set_tim callback?
>
> Any other ideas?
Since we seem to want to allow ieee80211_beacon_get_tim to be called
from the set_tim callbacks, maybe we could manage bss->dtim_count
somewhere other than ieee80211_beacon_add_tim?
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
* rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Helmut Schaa @ 2010-06-24 13:21 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Ivo van Doorn, Gertjan van Wingerde
Hi,
I've just reviewed the beacon handling in rt2x00 in AP mode and experienced
some inconsistencies. The DTIM count is not correctly updated: sometimes
multiple beacons are sent out using the same DTIM count.
rt2x00 calls ieee80211_beacon_get_tim right after the current beacon was
sent out to fetch the next one. However, rt2x00 also implements the set_tim
callback and updates the beacon in each call to set_tim. As far as I
understood the code in mac80211 the set_tim callback is called when the
first frame for a powersaving station gets queued.
Since every call to ieee80211_beacon_get_tim updates the DTIM count the
following can happen (assuming a DTIM period of 2):
- the hw sends out the current beacon (DTIM count == 0)
- call to ieee80211_beacon_get_tim fetches the next beacon (DTIM count == 1)
- the first frame for a PS STA gets queued -> set_tim
- again call ieee80211_beacon_get_tim (DTIM count == 0)
- hw sends out the beacon with incorrect DTIM count
A proper way of fixing this issue would be not to use the set_tim callback but
just fetch the next beacon right before it gets send out (like ath* does).
However, that's not easily possible with rt2x00 devices older then rt2800 as
they only generate beacon_done interrupts (which is obviously too late for
fetching the current beacon ;) ).
So, is the current implementation in rt2x00 supposed to work and mac80211
needs fixing?
Could we add a parameter to ieee80211_beacon_get_tim that indicates if a _new_
beacon should be generated or if the _current_ beacon should be updated in
response to the set_tim callback?
Any other ideas?
Thanks,
Helmut
^ permalink raw reply
* [PATCH] ath9k: Wakeup the chip in an appropriate place in ath_paprd_calibrate()
From: Vasanthakumar Thiagarajan @ 2010-06-24 11:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Move ath9k_ps_wakeup() down just before accessing hw registers.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 6d57877..efbf535 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -268,7 +268,6 @@ void ath_paprd_calibrate(struct work_struct *work)
int time_left;
int i;
- ath9k_ps_wakeup(sc);
skb = alloc_skb(len, GFP_KERNEL);
if (!skb)
return;
@@ -289,6 +288,7 @@ void ath_paprd_calibrate(struct work_struct *work)
qnum = sc->tx.hwq_map[WME_AC_BE];
txctl.txq = &sc->tx.txq[qnum];
+ ath9k_ps_wakeup(sc);
ar9003_paprd_init_table(ah);
for (chain = 0; chain < AR9300_MAX_CHAINS; chain++) {
if (!(ah->caps.tx_chainmask & BIT(chain)))
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/3] ath9k: Restore ps state in ath_paprd_calibrate() upon failure to allocate skb
From: Vasanthakumar Thiagarajan @ 2010-06-24 11:01 UTC (permalink / raw)
To: linville@tuxdriver.com; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1277372566-22883-2-git-send-email-vasanth@atheros.com>
On Thu, Jun 24, 2010 at 03:12:45PM +0530, Vasanthakumar Thiagarajan wrote:
> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index 6d57877..484d113 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -271,7 +271,7 @@ void ath_paprd_calibrate(struct work_struct *work)
> ath9k_ps_wakeup(sc);
> skb = alloc_skb(len, GFP_KERNEL);
> if (!skb)
> - return;
> + goto fail_paprd;
>
> tx_info = IEEE80211_SKB_CB(skb);
Please drop this particular patch, ath9k_ps_wakeup() does not need
to be there before alloc_skb() in the first place. I'll send a cleaner one.
Vasanth
^ permalink raw reply
* [PATCH 3/3] ath9k: Remove unused paprd_txok
From: Vasanthakumar Thiagarajan @ 2010-06-24 9:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1277372566-22883-1-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 -
drivers/net/wireless/ath/ath9k/xmit.c | 6 ++----
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 6c561fa..72d5e52 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -563,7 +563,6 @@ struct ath_softc {
struct mutex mutex;
struct work_struct paprd_work;
struct completion paprd_complete;
- int paprd_txok;
u32 intrstatus;
u32 sc_flags; /* SC_OP_* */
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index edbeffb..c41185b 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1948,12 +1948,10 @@ static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
if (bf->bf_state.bfs_paprd) {
if (time_after(jiffies,
bf->bf_state.bfs_paprd_timestamp +
- msecs_to_jiffies(ATH_PAPRD_TIMEOUT))) {
+ msecs_to_jiffies(ATH_PAPRD_TIMEOUT)))
dev_kfree_skb_any(skb);
- } else {
- sc->paprd_txok = txok;
+ else
complete(&sc->paprd_complete);
- }
} else {
ath_tx_complete(sc, skb, bf->aphy, tx_flags);
ath_debug_stat_tx(sc, txq, bf, ts);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] ath9k: Restore ps state in ath_paprd_calibrate() upon failure to allocate skb
From: Vasanthakumar Thiagarajan @ 2010-06-24 9:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1277372566-22883-1-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 6d57877..484d113 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -271,7 +271,7 @@ void ath_paprd_calibrate(struct work_struct *work)
ath9k_ps_wakeup(sc);
skb = alloc_skb(len, GFP_KERNEL);
if (!skb)
- return;
+ goto fail_paprd;
tx_info = IEEE80211_SKB_CB(skb);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] ath9k: Fix bug in paprd
From: Vasanthakumar Thiagarajan @ 2010-06-24 9:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
It is possbile that the transmission of paprd test frame
might not get completed in 100ms if tx is stuck. Freeing
this skb upon timeout in ath_paprd_calibrate() will result
in accessing already freed memory when the associated pending
buffer is drained in txq. This patch fixes this issue.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 3 +++
drivers/net/wireless/ath/ath9k/main.c | 5 +++--
drivers/net/wireless/ath/ath9k/xmit.c | 12 ++++++++++--
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 6218890..6c561fa 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -226,6 +226,7 @@ struct ath_buf_state {
int bfs_retries;
u8 bf_type;
u8 bfs_paprd;
+ unsigned long bfs_paprd_timestamp;
u32 bfs_keyix;
enum ath9k_key_type bfs_keytype;
};
@@ -425,6 +426,8 @@ int ath_beaconq_config(struct ath_softc *sc);
#define ATH_LONG_CALINTERVAL 30000 /* 30 seconds */
#define ATH_RESTART_CALINTERVAL 1200000 /* 20 minutes */
+#define ATH_PAPRD_TIMEOUT 100 /* msecs */
+
void ath_paprd_calibrate(struct work_struct *work);
void ath_ani_calibrate(unsigned long data);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 41a317d..6d57877 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -310,13 +310,13 @@ void ath_paprd_calibrate(struct work_struct *work)
break;
time_left = wait_for_completion_timeout(&sc->paprd_complete,
- 100);
+ msecs_to_jiffies(ATH_PAPRD_TIMEOUT));
if (!time_left) {
ath_print(ath9k_hw_common(ah), ATH_DBG_CALIBRATE,
"Timeout waiting for paprd training on "
"TX chain %d\n",
chain);
- break;
+ goto fail_paprd;
}
if (!ar9003_paprd_is_done(ah))
@@ -334,6 +334,7 @@ void ath_paprd_calibrate(struct work_struct *work)
ath_paprd_activate(sc);
}
+fail_paprd:
ath9k_ps_restore(sc);
}
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 20221b8..edbeffb 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1644,6 +1644,8 @@ static int ath_tx_setup_buffer(struct ieee80211_hw *hw, struct ath_buf *bf,
}
bf->bf_state.bfs_paprd = txctl->paprd;
+ if (txctl->paprd)
+ bf->bf_state.bfs_paprd_timestamp = jiffies;
bf->bf_flags = setup_tx_flags(skb, use_ldpc);
bf->bf_keytype = get_hw_crypto_keytype(skb);
@@ -1944,8 +1946,14 @@ static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
dma_unmap_single(sc->dev, bf->bf_dmacontext, skb->len, DMA_TO_DEVICE);
if (bf->bf_state.bfs_paprd) {
- sc->paprd_txok = txok;
- complete(&sc->paprd_complete);
+ if (time_after(jiffies,
+ bf->bf_state.bfs_paprd_timestamp +
+ msecs_to_jiffies(ATH_PAPRD_TIMEOUT))) {
+ dev_kfree_skb_any(skb);
+ } else {
+ sc->paprd_txok = txok;
+ complete(&sc->paprd_complete);
+ }
} else {
ath_tx_complete(sc, skb, bf->aphy, tx_flags);
ath_debug_stat_tx(sc, txq, bf, ts);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] rt2500usb: fallback to SW encryption for TKIP+AES
From: Gertjan van Wingerde @ 2010-06-24 6:15 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ivo Van Doorn, rt2x00 Users List, linux-wireless
In-Reply-To: <201006231257.17684.linux@rainbow-software.org>
On 06/23/10 12:57, Ondrej Zary wrote:
> On Tuesday 22 June 2010, Ondrej Zary wrote:
>> On Tuesday 22 June 2010 21:35:18 Gertjan van Wingerde wrote:
>>> On 06/22/10 12:38, Ondrej Zary wrote:
>>>> Hello,
>>>> I'm (again) trying to solve (debug) a weird problem with Asus WL-167G:
>>>> 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink
>>>> RT2500USB]
>>>>
>>>> The problem only appears when HW encryption is enabled and connecting
>>>> to an AP configured as WPA2 TKIP+AES.
>>>>
>>>> HW encryption works when the AP is configured as TKIP-only or AES-only.
>>>> It also works when AP is configured as TKIP+AES but wpa_supplicant is
>>>> forced to use TKIP as pairwise cipher (pairwise=TKIP)
>>>>
>>>> SW encryption works always.
>>>>
>>>> The problem is that no packets are transmitted. I can't see DHCP
>>>> broadcasts on other machine using tcpdump. But when I run tcpdump on
>>>> the rt2500usb, I see broadcasts from the other machine, so receive
>>>> seems to work fine.
>>>>
>>>> Added some printk()s to the driver, 6 packets from unsuccessful DHCP:
>>>> [ 371.760073] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 371.852062] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 371.944054] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.036068] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.128056] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.220053] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.312053] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.404055] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.496101] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.588077] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.688073] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.272513] wlan1: authenticate with 00:13:d4:0f:f3:19 (try 1)
>>>> [ 373.272552] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.274533] wlan1: authenticated
>>>> [ 373.274564] wlan1: associate with 00:13:d4:0f:f3:19 (try 1)
>>>> [ 373.274581] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.277696] wlan1: RX AssocResp from 00:13:d4:0f:f3:19 (capab=0x411
>>>> status=0 aid=1) [ 373.277704] wlan1: associated
>>>> [ 373.308247] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.308392] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.315999] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.340306] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 373.340318] rt2500usb_config_key key->hw_key_idx=0 SET_KEY
>>>> hw_key_idx = 0 OK [ 373.344521] rt2x00crypto_key_to_cipher: ALG_TKIP
>>>> [ 373.344527] rt2500usb_config_key key->hw_key_idx=0 SET_KEY
>>>> hw_key_idx = 1 OK [ 373.412083] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 375.160233] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 375.160246] rt2x00crypto_tx_overhead=8
>>>> [ 375.160254] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 375.240078] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 381.163494] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 381.163507] rt2x00crypto_tx_overhead=8
>>>> [ 381.163515] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 381.244066] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 388.165180] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 388.165194] rt2x00crypto_tx_overhead=8
>>>> [ 388.165201] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 388.244069] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 399.169468] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 399.169481] rt2x00crypto_tx_overhead=8
>>>> [ 399.169489] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 399.248067] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 404.080428] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 404.180066] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 410.168836] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 410.168850] rt2x00crypto_tx_overhead=8
>>>> [ 410.168858] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 410.248068] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 414.374545] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 414.472061] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 422.169686] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 422.169699] rt2x00crypto_tx_overhead=8
>>>> [ 422.169706] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 422.252069] rt2500usb_write_tx_desc: key_idx=0
>>>>
>>>> Seems that it's trying to use CCMP, which is good. I wonder if the keys
>>>> are properly handled in rt2500usb_config_key. They seem to be uploaded
>>>> to the HW correctly (one at index 0, one at 1) - but can't tell without
>>>> any HW docs.
>>>>
>>>> I did some framedumps before but don't know what to do with them (what
>>>> to look for):
>>>> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
>>>> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.tx
>>>> t
>>>>
>>>> Anything else I can try?
>>>
>>> Hi Ondrej,
>>>
>>> Did you also test what happens if you configure the AP to be TKIP+AES and
>>> force wpa-supplicant to use AES pairwise key?
>>> If my analysis below is correct then that may work as well.
>>
>> That does not work - it's probably the same case as default options (TKIP
>> group key + AES pairwise key).
>>
>>> If my reading of the rt2570 data sheet is correct, then the rt2570 will
>>> only support one encryption mechanism at the time. That means that it is
>>> not possible to upload 1 TKIP key and 1 AES key at the same time to the
>>> hardware. All the configured keys have to be of the same encryption
>>> algorithm.
>>> Presumably this is why the HW encryption engine fails, as the keys are
>>> set with mixed settings.
>>> Based on that, I don't think that rt2500usb can support this TKIP+AES
>>> setting on wpa-supplicant.
>>
>> If this is true, then the driver should fall back to SW encryption in this
>> case.
>
> HW crypto in rt2500usb does not seem to support keys with different ciphers,
> which breaks TKIP+AES mode. Fall back to software encryption to fix it.
>
> This should fix long-standing problems with rt2500usb and WPA, such as:
> http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
> https://bugzilla.redhat.com/show_bug.cgi?id=484888
>
> Also tested that it does not break WEP, TKIP-only and AES-only modes.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Yes, this seems to be the right thing to do.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
>
> diff -urp linux-2.6.35-rc3-orig/drivers/net/wireless/rt2x00/rt2500usb.c linux-2.6.35-rc3/drivers/net/wireless/rt2x00/rt2500usb.c
> --- linux-2.6.35-rc3-orig/drivers/net/wireless/rt2x00/rt2500usb.c 2010-06-12 04:14:04.000000000 +0200
> +++ linux-2.6.35-rc3/drivers/net/wireless/rt2x00/rt2500usb.c 2010-06-23 12:18:43.000000000 +0200
> @@ -348,6 +348,7 @@ static int rt2500usb_config_key(struct r
> int timeout;
> u32 mask;
> u16 reg;
> + enum cipher curr_cipher;
>
> if (crypto->cmd == SET_KEY) {
> /*
> @@ -358,6 +359,7 @@ static int rt2500usb_config_key(struct r
> mask = TXRX_CSR0_KEY_ID.bit_mask;
>
> rt2500usb_register_read(rt2x00dev, TXRX_CSR0, ®);
> + curr_cipher = rt2x00_get_field16(reg, TXRX_CSR0_ALGORITHM);
> reg &= mask;
>
> if (reg && reg == mask)
> @@ -366,6 +368,14 @@ static int rt2500usb_config_key(struct r
> reg = rt2x00_get_field16(reg, TXRX_CSR0_KEY_ID);
>
> key->hw_key_idx += reg ? ffz(reg) : 0;
> + /*
> + * Hardware requires that all keys use the same cipher
> + * (e.g. TKIP-only, AES-only, but not TKIP+AES).
> + * If this is not the first key, compare the cipher with the
> + * first one and fall back to SW crypto if not the same.
> + */
> + if (key->hw_key_idx > 0 && crypto->cipher != curr_cipher)
> + return -EOPNOTSUPP;
>
> /*
> * The encryption key doesn't fit within the CSR cache,
>
>
^ permalink raw reply
* RE: [PATCH 1/3] Libertas: cfg80211 support
From: Johannes Berg @ 2010-06-24 6:03 UTC (permalink / raw)
To: Kiran Divekar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <25B60CDC2F704E4E9D88FFD52780CB4C04D64A250E@SC-VEXCH1.marvell.com>
On Wed, 2010-06-23 at 22:38 -0700, Kiran Divekar wrote:
> > +drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in
> > assignment (different base types)
> > +drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short
> > [unsigned] [usertype] capability
> > +drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16
> > [usertype] <noident>
> > +drivers/net/wireless/libertas/cmdresp.c:106:5: warning: symbol
> > 'lbs_ret_802_11d_domain_info' was not declared. Should it be static?
> >
>
> These errors did not show up during my compilation. I will now make
> sure to check with various kernel configs. Any other things should I
> test?
These are sparse errors, you need to
make C=2 CF=-D__CHECK_ENDIAN__ drivers/net/wireless/libertas/
johannes
^ permalink raw reply
* RE: [PATCH 1/3] Libertas: cfg80211 support
From: Kiran Divekar @ 2010-06-24 5:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1277281556.3642.6.camel@jlt3.sipsolutions.net>
> On Mon, 2010-06-14 at 22:01 +0530, Kiran Divekar wrote:
> > Holger Schurig's patch (https://patchwork.kernel.org/patch/64286/)
> > is rebased to latest wireless-testing tree.
Hi Johannes, John,
>
>
> +drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in
> assignment (different base types)
> +drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short
> [unsigned] [usertype] capability
> +drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16
> [usertype] <noident>
> +drivers/net/wireless/libertas/cmdresp.c:106:5: warning: symbol
> 'lbs_ret_802_11d_domain_info' was not declared. Should it be static?
>
These errors did not show up during my compilation. I will now make sure to check with various kernel configs. Any other things should I test?
> I'm guessing this patchset is at fault.
>
> Johannes
- Kiran
^ permalink raw reply
* Re: [PATCH] ath9k: Fix the LED behaviour in idle unassociated state.
From: Vasanthakumar Thiagarajan @ 2010-06-24 4:56 UTC (permalink / raw)
To: Pavel Roskin
Cc: Vivek Natarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1277315740.3562.6.camel@mj>
On Wed, Jun 23, 2010 at 11:25:40PM +0530, Pavel Roskin wrote:
> On Wed, 2010-06-23 at 12:08 +0530, Vivek Natarajan wrote:
> > LED should be ON when the radio is put into FULL SLEEP mode during the idle
> > unassociated state.
>
> Why? Is there any written policy for the LED behavior? I think we want
> to conserve power if sleeping, which means turning LEDs off.
There is no written policy for this behaviour, may be the comment
needs to be changed. It makes sense to turn off the LED to save
power but turning off the LED while wireless interface is still up
is kind of misleading, also this one we got as a requirement
internally and did not want to maintain any private patch.
>
> Or is it a workaround for some quirk in Atheros hardware?
nope.
>
> In any case, I don't like the new comment. The comment says "Keep the
> LED on...", but the code is still turning the LED off.
yeah, this comment seems to be implicit. thanks for the review.
Vasanth
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Björn Smedman @ 2010-06-23 23:56 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <4C22601E.5050101@openwrt.org>
2010/6/23 Felix Fietkau <nbd@openwrt.org>:
> On 2010-06-23 8:47 PM, Björn Smedman wrote:
[snip]
>> But on the other hand doesn't that also mean that MRR rates and counts
>> in the tx status will be incorrect? I.e. one set of rates/counts used
>> to transmit the aggregate (first subframe) and (possibly) another set
>> reported back in tx status (first acked/expired subframe)?
> No, MRR info is just fine. The retry stats are reported for the whole
> A-MPDU, not for indvididual subframes. It's always present in the last
> descriptor of the whole batch. Also, since my code cleanup a while ago,
> the converted rx/tx status info is not longer part of the allocated
> descriptor space, but instead kept on stack in the function that
> processes the tx status. This on stack tx status is then passed to the
> rc update function, which sends the data to mac80211 along with the
> AMPDU tx status report.
That part looks reasonable to me. The part I don't understand is how
ath_tx_rc_update() builds the 'status' field of the
'ieee80211_tx_info' struct. The way I read the code we rely on the
compiler laying out the 'status' field on top of the 'control' field
(both members of an anonymous union) so that rates and counts align.
Since the 'control' field was (presumably) used to set up the tx we
already have a 'status' field that is almost correct. We only have to
remove the retries that where not actually needed from the counts. But
the presumption seems incorrect in the aggregation case. We may be
adjusting an MRR series that has never been used to control tx, right?
> - Felix
>
/Björn
^ permalink raw reply
* PCI error for some CM9 chipsets when using ath5k
From: Peizhao Hu @ 2010-06-23 23:36 UTC (permalink / raw)
To: linux-wireless
Hi
I have a number of CM9 cards that crash every time I reload ath5k (compat-wireless-2010-05-24) with the following error message. The strange thing is that it only happen to my newer CM9 cards (AR5213A-001 chipset), older version cards (AR5213A-00 chipset) work fine. The same card works fine if I use madwifi as the driver. When I replace the CM9 card with a EMP-8602 PLUS-S card, the ath5k seems working ok as well.
Anyone know why and how to fix it?
dmesg output when I reload the driver
========================
ath_rate_minstrel: unloaded
wlan: mac acl policy unregistered
wlan: driver unloaded
ath_pci: driver unloaded
ath_hal: driver unloaded
ath9k: Driver unloaded
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: AU
ath5k 0000:00:14.0: registered as 'phy0'
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
phy0: Selected rate control algorithm 'minstrel'
ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy0: RF5112B multiband radio found (0x36)
cfg80211: Calling CRDA for country: US
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (300 mBi, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
error message right after the reload
====================
root@OpenWrt:/# PCI error 1 at PCI addr 0x10008020
Data bus error, epc == 87c468e0, ra == 87c468d8
Oops[#1]:
Cpu 0
$ 0 : 00000000 806b0000 deadc0de b0000000
$ 4 : 00000002 b0008034 b0000000 00000000
$ 8 : 0000000a 00000000 00000001 0000004d
$12 : 00000050 87defb98 ca62c1d6 87defc40
$16 : 87e24000 00008024 00008020 00000001
$20 : 00001f30 00001ef0 000003e8 018003e8
$24 : 00000000 8f1bbcdc
$28 : 87dee000 87defce0 00000064 87c468d8
Hi : 00000000
Lo : 00000000
epc : 87c468e0 ath5k_hw_reset_tsf+0x44/0x90 [ath5k]
Tainted: P
ra : 87c468d8 ath5k_hw_reset_tsf+0x3c/0x90 [ath5k]
Status: 1800f403 KERNEL EXL IE
Cause : 1080001c
PrId : 00019374 (MIPS 24Kc)
Modules linked in: ath9k ath9k_common ath9k_hw ath5k ath mac80211 cfg80211 ohci_hcd nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_c
onntrack_ftp ipt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ehci_hcd pppoe pppox ipt_REJECT
xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables nfs ppp_async ppp_generic slhc lockd sun
rpc usbcore nls_base crc_ccitt compat_firmware_class compat arc4 aes_generic deflate ecb cbc leds_gpio button_hotplug gpio_buttons input_polldev input_core [
last unloaded: cfg80211]
Process phy0 (pid: 729, threadinfo=87dee000, task=87884488, tls=00000000)
Stack : 802d0000 806c0c99 806c0c5c 00000000 000003e8 00008030 00008034 87e24000
00000001 87c46ae8 00000002 87defdd0 00000064 87c4e6c8 00000000 87defdd0
00000003 8772e2c0 8772e2c0 87e78200 8772e564 00000002 87defdd0 87e87710
87defdd0 8018d8f0 8755e4e0 00009920 87e787e4 87e8d8d4 00000001 5077ec03
87defdd0 87e78200 8772e2c0 00000000 fffffffe 8772e564 00000000 00000000
...
Call Trace:
[<87c468e0>] ath5k_hw_reset_tsf+0x44/0x90 [ath5k]
[<87c46ae8>] ath5k_hw_init_beacon+0x1bc/0x254 [ath5k]
[<87e87710>] __ieee80211_sta_join_ibss+0x6c/0x43c [mac80211]
[<87e8884c>] ieee80211_ibss_work+0x55c/0x6f8 [mac80211]
[<8008e47c>] worker_thread+0x134/0x1d8
[<80091e60>] kthread+0x7c/0x88
[<8006cbac>] kernel_thread_helper+0x10/0x18
Code: 00642021 8e0400ac 8e060098 <3c030100> 02202821 00439825 0244280b 00c52821 0c05fe7e
--
Regard;
Peizhao Hu
^ permalink raw reply
* Re: [PATCH 3/3] libertas: mark lbs_ret_802_11d_domain_info static
From: Dan Williams @ 2010-06-23 23:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, dkiran, Johannes Berg
In-Reply-To: <1277303846-17257-3-git-send-email-linville@tuxdriver.com>
On Wed, 2010-06-23 at 10:37 -0400, John W. Linville wrote:
> Probably little risk of namespace polution, but good practice... :-)
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/cmdresp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/cmdresp.c b/drivers/net/wireless/libertas/cmdresp.c
> index b4bc103..a0d9482 100644
> --- a/drivers/net/wireless/libertas/cmdresp.c
> +++ b/drivers/net/wireless/libertas/cmdresp.c
> @@ -103,7 +103,7 @@ static int lbs_ret_reg_access(struct lbs_private *priv,
> * @param resp pointer to command response buffer
> * @return 0; -1
> */
> -int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
> +static int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
> {
> struct cmd_ds_802_11d_domain_info *domaininfo =
> &resp->params.domaininforesp;
^ 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