* [PATCH V2] b43: Work around mac80211 race condition that may transmit one packet after queue is stopped
From: Larry Finger @ 2009-07-29 15:54 UTC (permalink / raw)
To: John W Linville, Michael Buesch; +Cc: Johannes Berg, linux-wireless
As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497,
mac80211 has a bug that allows a call to the TX routine after the queues have
been stopped. This situation will only occur under extreme stress. Although
b43 does not crash when this condition occurs, it does generate a WARN_ON and
also logs a queue overrun message. This patch recognizes b43 is not at fault
and logs a message only when the most verbose debugging mode is enabled. In
the unlikely event that the queue is not stopped when the DMA queue becomes
full, then a warning is issued.
During testing of this patch with one output stream running repeated tcpperf
writes and a second running a flood ping, this routine was entered with
the DMA ring stopped about once per hour. The condition where the DMA queue is
full but the ring has not been stopped has never been seen by me.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
This patch is 2.6.32 material.
Larry
---
V2 - put WARN_ON in if statement.
dma.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing/drivers/net/wireless/b43/dma.c
@@ -1334,13 +1334,22 @@ int b43_dma_tx(struct b43_wldev *dev, st
spin_lock_irqsave(&ring->lock, flags);
B43_WARN_ON(!ring->tx);
- /* Check if the queue was stopped in mac80211,
- * but we got called nevertheless.
- * That would be a mac80211 bug. */
- B43_WARN_ON(ring->stopped);
- if (unlikely(free_slots(ring) < TX_SLOTS_PER_FRAME)) {
- b43warn(dev->wl, "DMA queue overflow\n");
+ if (unlikely(ring->stopped)) {
+ /* We get here only because of a bug in mac80211.
+ * Because of a race, one packet may be queued after
+ * the queue is stopped, thus we got called when we shouldn't.
+ * For now, just refuse the transmit. */
+ if (b43_debug(dev, B43_DBG_DMAVERBOSE))
+ b43err(dev->wl, "Packet after queue stopped\n");
+ err = -ENOSPC;
+ goto out_unlock;
+ }
+
+ if (unlikely(WARN_ON(free_slots(ring) < TX_SLOTS_PER_FRAME))) {
+ /* If we get here, we have a real error with the queue
+ * full, but queues not stopped. */
+ b43err(dev->wl, "DMA queue overflow\n");
err = -ENOSPC;
goto out_unlock;
}
^ permalink raw reply
* Re: [PATCH] b43: Work around mac80211 race condition that may transmit one packet after queue is stopped
From: Larry Finger @ 2009-07-29 15:42 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John W Linville, Michael Buesch, Johannes Berg, linux-wireless
In-Reply-To: <69e28c910907290543t7532bd07g2ffdc2a04973a6f8@mail.gmail.com>
Gábor Stefanik wrote:
> On Wed, Jul 29, 2009 at 3:21 AM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>> As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497,
>> mac80211 has a bug that allows a call to the TX routine after the queues have
>> been stopped. This situation will only occur under extreme stress. Although
>> b43 does not crash when this condition occurs, it does generate a WARN_ON and
>> also logs a queue overrun message. This patch recognizes b43 is not at fault
>> and logs a message only when the most verbose debugging mode is enabled. In
>> the unlikely event that the queue is not stopped when the DMA queue becomes
>> full, then a warning is issued.
>>
>> During testing of this patch with one output stream running repeated tcpperf
>> writes and a second running a flood ping, this routine was entered with
>> the DMA ring stopped about once per hour. The condition where the DMA queue is
>> full but the ring has not been stopped has never been seen by me.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>>
>> John,
>>
>> This patch is 2.6.32 material.
>>
>> Larry
>> ---
>>
>> Index: wireless-testing/drivers/net/wireless/b43/dma.c
>> ===================================================================
>> --- wireless-testing.orig/drivers/net/wireless/b43/dma.c
>> +++ wireless-testing/drivers/net/wireless/b43/dma.c
>> @@ -1334,13 +1334,23 @@ int b43_dma_tx(struct b43_wldev *dev, st
>> spin_lock_irqsave(&ring->lock, flags);
>>
>> B43_WARN_ON(!ring->tx);
>> - /* Check if the queue was stopped in mac80211,
>> - * but we got called nevertheless.
>> - * That would be a mac80211 bug. */
>> - B43_WARN_ON(ring->stopped);
>> +
>> + if (unlikely(ring->stopped)) {
>> + /* We get here only because of a bug in mac80211.
>> + * Because of a race, one packet may be queued after
>> + * the queue is stopped, thus we got called when we shouldn't.
>> + * For now, just refuse the transmit. */
>> + if (b43_debug(dev, B43_DBG_DMAVERBOSE))
>> + b43err(dev->wl, "Packet after queue stopped\n");
>> + err = -ENOSPC;
>> + goto out_unlock;
>> + }
>>
>> if (unlikely(free_slots(ring) < TX_SLOTS_PER_FRAME)) {
>> - b43warn(dev->wl, "DMA queue overflow\n");
>> + /* If we get here, we have a real error with the queue
>> + * full, but queues not stopped. */
>> + b43err(dev->wl, "DMA queue overflow\n");
>> + WARN_ON(1);
>
> Is this really the best way to do this? Any reason why not have the
> WARN_ON in the if-condition?
I did it this way because my preference is to see the text saying why
there was a warning before the traceback part of the warning; however,
as I do not expect to ever see this warning, I will resubmit. The
argument for putting the WARN_ON in the if statement is that the size
of the object code is decreased by 7 bytes and one line is removed
from the source. The important thing is that the x86_64 code for the
expected branch is exactly the same for the two cases.
One interesting thing is that gcc 4.3.2 for x86_64 does not seem to
pay any attention to the "unlikely" hint. The compiled code is the
same for "if(cond)" and "if(unlikely(cond))".
Larry
^ permalink raw reply
* Re: [PATCH] wireless-regdb: TH gets 5 GHz enabled as of new regulatory rules
From: Luis R. Rodriguez @ 2009-07-29 15:18 UTC (permalink / raw)
To: Phattanon Duangdara; +Cc: linux-wireless, Michael Green, David Quan
In-Reply-To: <f7de31c0907290313x148e2851i26df034c8e701a8c@mail.gmail.com>
Note: this e-mail is in a public mailing list.
Adding Michael and David. Michael, I'd appreciate your review on this,
if possible.
Phattanon, thanks for your review of the TH document and sharing it
with us. Please see my reply inline below.
On Wed, Jul 29, 2009 at 3:13 AM, Phattanon Duangdara<sfalpha@gmail.com> wrote:
> I corrected redgb from my knowledge.
Did you see my patch? I corrected TH to be:
country TH:
(2402 - 2482 @ 20), (N/A, 20)
(5170 - 5250 @ 20), (3, 17)
(5250 - 5330 @ 20), (3, 20), DFS
(5490 - 5710 @ 20), (3, 20), DFS
(5735 - 5835 @ 20), (3, 30)
> For 5150-5350 is for Indoor Use Only.
> Most of the regulartory
What do you mean by that? Do you mean that the document refers to FCC
and ETSI/ITU standard for regulatory purposes for some items?
> refer _either_ FCC or ETSI/ITU standard, so I
> guess that from the document 40MHz can also be used (same as US)
> because TH regulatory mostly cover all bandwidth on 40MHz.
Are you saying the Thailand document refers to FCC for max allowed
bandwidth spacing and therefore US max bandwidth spacing should be
used (ie allow 40 MHz width channels)?
> I corrected power but What a field before power is (that is now N/A below) ?
The rules can be read as follows:
(start - end @ max bandwidth spacing), (max antenna gain, max eirp)
> # TH Data (2008) from
> http://www.ratchakitcha.soc.go.th/DATA/PDF/2551/E/042/64.PDF
> country TH:
> (2402 - 2472 @ 40), (N/A, 20)
> (5170 - 5250 @ 40), (N/A, 23), NO-OUTDOOR
> (5250 - 5330 @ 40), (N/A, 23), NO-OUTDOOR, DFS
> (5490 - 5710 @ 40), (N/A, 30), DFS
> (5735 - 5835 @ 30), (N/A, 30)
Michael, does your concur with this?
> Summary I got from the document
>
> 2400-2500 MHz
> Max Power (e.i.r.p): 100mW
> Bandwidth: Not specified
> Usage: Not specified
> Ref Standard (either):
Either, does that mean either FCC, or ETSI or ITU, you take a pick?
That would seem pretty vague for regulatory purposes.
> EN 300 328-2 : Electromagnetic compatibility and Radio spectrum Matters
> (ERM); Wideband Transmission systems; Data transmission
> equipment operating in the 2,4 GHz ISM band and using
> spread spectrum modulation techniques; Part 2: Harmonized
> EN covering essential requirements under article 3.2 of R&TTE
> Directive
Did this come from the TH document?
> FCC Part 15.247 : Code of Federal Regulations (USA); Title 47
> Telecommunication; Chapter 1 Federal Communications
> Commission; Part 15 Radio Frequency Devices; Subpart C –
> Intentional Radiators; §15.247 Operation within the bands 902–
> 928 MHz, 2400–2483.5 MHz, and 5725–5850 MHz
This too?? I ask because I see FCC mentioned.
> 5150-5350 MHz
> Max Power (e.i.r.p): 200mW, Density 10mW/MHz (0.25mW/25KHz)
> Bandwidth: Not specified
> Usage: Indoor applications only, DFS is must
Thanks, did this came from the TH document?
> Resolution 229 (WRC-03)
> (Radio Regulations) - Use of the bands 5 150-5 250 MHz, 5 250-5 350
> MHz and 5 470-5 725
> MHz by the mobile service for the implementation of wireless access
> systems including
> radio local area networks
>
> Recommendation ITU-R M. 1652 (Annex 1): Dynamic
> frequency selection (DFS) in wireless access systems including radio
> local area networks
> for the purpose of protecting the radiocommunication service in the 5 GHz band
>
> Ref Standard (either):
>
> ETSI EN 301 893 : Broadband Radio Access Networks (BRAN); 5 GHz high
> performance RLAN; Harmonized EN covering essential
> requirements of article 3.2 of the R&TTE Directive
>
> FCC Part 15.407 : Code of Federal Regulations (USA); Title 47
> Telecommunications; Chapter 1 Federal Communications
> Commission; Part 15 Radio Frequency Devices; Subpart E –
> Unlicensed National Information Infrastructure Devices;
> § 15.407 General technical requirements
>
>
>
> 5450-5725 MHz
> Max Power (e.i.r.p): 1W, Density 50mW/MHz
> Bandwidth: Not specified
> Usage: Not specified, DFS is must
>
> Resolution 229 (WRC-03)
> (Radio Regulations) - Use of the bands 5 150-5 250 MHz, 5 250-5 350
> MHz and 5 470-5 725
> MHz by the mobile service for the implementation of wireless access
> systems including
> radio local area networks
>
> Recommendation ITU-R M. 1652 (Annex 1): Dynamic
> frequency selection (DFS) in wireless access systems including radio
> local area networks
> for the purpose of protecting the radiocommunication service in the 5 GHz band
>
> Ref Standard (either):
>
> ETSI EN 301 893 : Broadband Radio Access Networks (BRAN); 5 GHz high
> performance RLAN; Harmonized EN covering essential
> requirements of article 3.2 of the R&TTE Directive
>
> Code of Federal Regulations (USA); Title 47
> Telecommunications; Chapter 1 Federal Communications
> Commission; Part 15 Radio Frequency Devices; Subpart E –
> Unlicensed National Information Infrastructure Devices;
> § 15.407 General technical requirements
>
> 5725-5850 MHz
> Max Power (e.i.r.p): 1W
> Bandwidth: Not specified
> Usage: Not specified
> Ref Standard (either):
>
> FCC Part 15.247 : Code of Federal Regulations (USA); Title 47
> Telecommunication; Chapter 1 Federal Communications
> Commission; Part 15 Radio Frequency Devices; Subpart C –
> Intentional Radiators; §15.247 Operation within the bands 902–
> 928 MHz, 2400–2483.5 MHz, and 5725–5850 MHz
>
> Code of Federal Regulations (USA); Title 47
> Telecommunications; Chapter 1 Federal Communications
> Commission; Part 15 Radio Frequency Devices; Subpart E –
> Unlicensed National Information Infrastructure Devices;
> § 15.407 General technical requirements
>
> Phattanon,
>
> On Thu, Jul 23, 2009 at 12:51 AM, Luis R.
> Rodriguez<lrodriguez@atheros.com> wrote:
>> Phattanon Duangdara reported the National Telecommunication
>> Commisions of Thailand has announced new regulatory rules
>> about 5GHz for RLAN last year.
>>
>> I have verified this matches our documentation internally
>> at Atheros.
>>
>> Reference in Thai Language:
>> http://www.ratchakitcha.soc.go.th/DATA/PDF/2551/E/042/64.PDF
>>
>> Cc: Michael Green <michael.green@atheros.com>
>> Cc: David Quan <david.quan@atheros.com>
>> Reported-by: Phattanon Duangdara <sfalpha@gmail.com>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> db.txt | 6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/db.txt b/db.txt
>> index fad098d..01536d6 100644
>> --- a/db.txt
>> +++ b/db.txt
>> @@ -534,7 +534,11 @@ country TW:
>> (5735 - 5815 @ 40), (3, 30)
>>
>> country TH:
>> - (2402 - 2482 @ 40), (N/A, 20)
>> + (2402 - 2482 @ 20), (N/A, 20)
>> + (5170 - 5250 @ 20), (3, 17)
>> + (5250 - 5330 @ 20), (3, 20), DFS
>> + (5490 - 5710 @ 20), (3, 20), DFS
>> + (5735 - 5835 @ 20), (3, 30)
>>
>> country TT:
>> (2402 - 2482 @ 40), (N/A, 20)
>> --
>> 1.6.3.3
>>
>>
> --
> 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
* [PATCH 1/2] ath5k: update PCU opmode whenever a new interface is added
From: Bob Copeland @ 2009-07-29 14:29 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
Previously, we would store the operating mode at interface up time,
but only update the PCU registers when the next reset happened.
The result is that if beacon configuration (ops->bss_info_changed)
happens before ops->config, we will program the wrong things into
the timer registers. Consequently, beacons won't work in AP mode
until after a reset (channel change, scan etc.).
This is fragile anyway so just program the opmode as soon as
mac80211 gives it to us.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 7db32ce..55ee976 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1117,6 +1117,8 @@ ath5k_mode_setup(struct ath5k_softc *sc)
struct ath5k_hw *ah = sc->ah;
u32 rfilt;
+ ah->ah_op_mode = sc->opmode;
+
/* configure rx filter */
rfilt = sc->filter_flags;
ath5k_hw_set_rx_filter(ah, rfilt);
@@ -2768,6 +2770,7 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
}
ath5k_hw_set_lladdr(sc->ah, conf->mac_addr);
+ ath5k_mode_setup(sc);
ret = 0;
end:
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/2] ath5k: fix CAB queue operation
From: Bob Copeland @ 2009-07-29 14:29 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
In-Reply-To: <1248877744-7273-1-git-send-email-me@bobcopeland.com>
We need to process tx descriptors for all queues (currently main tx
queue and cabq) which may have triggered the TX completion interrupt.
Otherwise, the queues can get stuck after sending a few frames.
Also, the CAB queue does need to be DBA (DMA beacon alert) gated, as
in ath9k and madwifi, instead of beacon sent gated or the CAB frames
may not be sent at the right time.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 5 ++++-
drivers/net/wireless/ath/ath5k/qcu.c | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 55ee976..3a1c156 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2000,9 +2000,12 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
static void
ath5k_tasklet_tx(unsigned long data)
{
+ int i;
struct ath5k_softc *sc = (void *)data;
- ath5k_tx_processq(sc, sc->txq);
+ for (i=0; i < AR5K_NUM_TX_QUEUES; i++)
+ if (sc->txqs[i].setup && (sc->ah->ah_txq_isr & BIT(i)))
+ ath5k_tx_processq(sc, &sc->txqs[i]);
}
diff --git a/drivers/net/wireless/ath/ath5k/qcu.c b/drivers/net/wireless/ath/ath5k/qcu.c
index 6d5aaf0..d7d5d11 100644
--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -409,7 +409,7 @@ int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
case AR5K_TX_QUEUE_CAB:
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
- AR5K_QCU_MISC_FRSHED_BCN_SENT_GT |
+ AR5K_QCU_MISC_FRSHED_DBA_GT |
AR5K_QCU_MISC_CBREXP_DIS |
AR5K_QCU_MISC_CBREXP_BCN_DIS);
--
1.6.2.5
^ permalink raw reply related
* [PATCH] mac80211: fix sparse warnings/errors
From: Johannes Berg @ 2009-07-29 13:46 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
sparse complains about a shadowed variable, which
we can just rename, and lots of stuff if the API
tracer is enabled, so kick out the tracer code in
a sparse run -- the macros just confuse it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/driver-trace.c | 3 +++
net/mac80211/iface.c | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
--- wireless-testing.orig/net/mac80211/driver-trace.c 2009-07-29 15:43:22.000000000 +0200
+++ wireless-testing/net/mac80211/driver-trace.c 2009-07-29 15:45:38.000000000 +0200
@@ -1,6 +1,9 @@
/* bug in tracepoint.h, it should include this */
#include <linux/module.h>
+/* sparse isn't too happy with all macros... */
+#ifndef __CHECKER__
#include "driver-ops.h"
#define CREATE_TRACE_POINTS
#include "driver-trace.h"
+#endif
--- wireless-testing.orig/net/mac80211/iface.c 2009-07-29 15:42:46.000000000 +0200
+++ wireless-testing/net/mac80211/iface.c 2009-07-29 15:43:11.000000000 +0200
@@ -401,7 +401,7 @@ static int ieee80211_stop(struct net_dev
/* APs need special treatment */
if (sdata->vif.type == NL80211_IFTYPE_AP) {
- struct ieee80211_sub_if_data *vlan, *tmp;
+ struct ieee80211_sub_if_data *vlan, *tmpsdata;
struct beacon_data *old_beacon = sdata->u.ap.beacon;
/* remove beacon */
@@ -410,7 +410,7 @@ static int ieee80211_stop(struct net_dev
kfree(old_beacon);
/* down all dependent devices, that is VLANs */
- list_for_each_entry_safe(vlan, tmp, &sdata->u.ap.vlans,
+ list_for_each_entry_safe(vlan, tmpsdata, &sdata->u.ap.vlans,
u.vlan.list)
dev_close(vlan->dev);
WARN_ON(!list_empty(&sdata->u.ap.vlans));
^ permalink raw reply
* Re: BUG: ifdown doesn't notify cfg80211
From: Holger Schurig @ 2009-07-29 12:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <200907291325.51598.hs4233@mail.mn-solutions.de>
> # iw dev eth1 connect -w MNHS key 0:11111
> eth1 (phy #0): connected to 00:13:19:80:da:30
> # ifconfig eth1 down
> # ifconfig eth1 up
> # iw dev eth1 connect -w MNHS key 0:11111
> command failed: Operation already in progress (-114)
As Johannes pointed out on IRC, this happens only if you used
iwconfig eth1 key s:11111
iwconfig eth1 essid MNHS
previously on the device. Seems that the CFG80211-configuration
doesn't delete the WEXT-configuration remnants. And as soon as
you "ifup" the device, it starts associating based on old WEXT
data, resulting in the busy.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] b43: Work around mac80211 race condition that may transmit one packet after queue is stopped
From: Gábor Stefanik @ 2009-07-29 12:43 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, Johannes Berg, linux-wireless
In-Reply-To: <4a6fa3fe.kYeW+HADItDIXTLm%Larry.Finger@lwfinger.net>
On Wed, Jul 29, 2009 at 3:21 AM, Larry Finger<Larry.Finger@lwfinger.net> wr=
ote:
> As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/3=
6497,
> mac80211 has a bug that allows a call to the TX routine after the queues =
have
> been stopped. This situation will only occur under extreme stress. Althou=
gh
> b43 does not crash when this condition occurs, it does generate a WARN_ON=
and
> also logs a queue overrun message. This patch recognizes b43 is not at fa=
ult
> and logs a message only when the most verbose debugging mode is enabled. =
In
> the unlikely event that the queue is not stopped when the DMA queue becom=
es
> full, then a warning is issued.
>
> During testing of this patch with one output stream running repeated tcpp=
erf
> writes and a second running a flood ping, this routine was entered with
> the DMA ring stopped about once per hour. The condition where the DMA que=
ue is
> full but the ring has not been stopped has never been seen by me.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> John,
>
> This patch is 2.6.32 material.
>
> Larry
> ---
>
> Index: wireless-testing/drivers/net/wireless/b43/dma.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- wireless-testing.orig/drivers/net/wireless/b43/dma.c
> +++ wireless-testing/drivers/net/wireless/b43/dma.c
> @@ -1334,13 +1334,23 @@ int b43_dma_tx(struct b43_wldev *dev, st
> =A0 =A0 =A0 =A0spin_lock_irqsave(&ring->lock, flags);
>
> =A0 =A0 =A0 =A0B43_WARN_ON(!ring->tx);
> - =A0 =A0 =A0 /* Check if the queue was stopped in mac80211,
> - =A0 =A0 =A0 =A0* but we got called nevertheless.
> - =A0 =A0 =A0 =A0* That would be a mac80211 bug. */
> - =A0 =A0 =A0 B43_WARN_ON(ring->stopped);
> +
> + =A0 =A0 =A0 if (unlikely(ring->stopped)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We get here only because of a bug in mac=
80211.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Because of a race, one packet may be q=
ueued after
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the queue is stopped, thus we got call=
ed when we shouldn't.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* For now, just refuse the transmit. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (b43_debug(dev, B43_DBG_DMAVERBOSE))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b43err(dev->wl, "Packet aft=
er queue stopped\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENOSPC;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_unlock;
> + =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0if (unlikely(free_slots(ring) < TX_SLOTS_PER_FRAME)) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 b43warn(dev->wl, "DMA queue overflow\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* If we get here, we have a real error wit=
h the queue
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* full, but queues not stopped. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 b43err(dev->wl, "DMA queue overflow\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 WARN_ON(1);
Is this really the best way to do this? Any reason why not have the
WARN_ON in the if-condition?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -ENOSPC;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_unlock;
> =A0 =A0 =A0 =A0}
> --
> 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 =A0http://vger.kernel.org/majordomo-info.html
>
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: zd1211rw couldn't load firmware. Error number -145 with Kernel 2.6.30
From: Mladen Horvat @ 2009-07-29 12:08 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <200907291350.27426.hs4233@mail.mn-solutions.de>
Holger Schurig <hs4233@...> writes:
>
> > [ 415.271000] usb 1-1: upload_firmware()
> > firmware device id 0x4810 is equal to the actual device id
>
> Looks like your firmware could be successfully loaded and checked
> by the driver.
>
> > [ 416.350000] usb 1-1: USB control request for firmware
> > upload failed. Error number -145
>
> Looks like an URB (USB request block) couldn't transferred to the
> device. As you speak about an embedded device: are you sure that
> your USB hardware works correctly?
>
Hello Holger,
thanks for your fast answer.
I hope to be sure that the usb hardware works correctly.
As i said, the same stb only booted with a rt73usb wlan stick attached has no
problems with the firmware upload and also wpa-supplicant connection and
everything works on wlan0. only problem are these two zd1211b usb sticks in the
zd1211rw driver.
the same stb running a kernel 2.6.12 and the original vendor driver 2.22.00
works without problems..
so i think i can exclude a hardware bug on the usb/stb side.
Hope this helps.
If any other logs are needed i will provide them.
Regards
Mladen
^ permalink raw reply
* Re: zd1211rw couldn't load firmware. Error number -145 with Kernel 2.6.30
From: Holger Schurig @ 2009-07-29 11:50 UTC (permalink / raw)
To: Mladen Horvat; +Cc: linux-wireless
In-Reply-To: <loom.20090729T111851-320@post.gmane.org>
> [ 415.271000] usb 1-1: upload_firmware()
> firmware device id 0x4810 is equal to the actual device id
Looks like your firmware could be successfully loaded and checked
by the driver.
> [ 416.350000] usb 1-1: USB control request for firmware
> upload failed. Error number -145
Looks like an URB (USB request block) couldn't transferred to the
device. As you speak about an embedded device: are you sure that
your USB hardware works correctly?
--
http://www.holgerschurig.de
^ permalink raw reply
* zd1211rw couldn't load firmware. Error number -145 with Kernel 2.6.30
From: Mladen Horvat @ 2009-07-29 11:28 UTC (permalink / raw)
To: linux-wireless
Hello all,
i am running Kernel 2.6.30 on a embedded linux stb and trying with two
different zd1211b usb wlan sticks to get the zd1211rw driver running.
just as a remark: an rt73usb stick works without problems.
Dont know what you need. so here is some informations:
uname -a
Linux dm7025 2.6.30-dm7025 #1 Tue Jul 28 20:25:28 CEST 2009 mips unknown
lsmod
Tainted: P
arc4 1536 2 - Live 0xc05c5000
ecb 2880 2 - Live 0xc05bc000
cryptomgr 87872 0 - Live 0xc059d000
crypto_hash 11840 1 cryptomgr, Live 0xc057a000
crypto_blkcipher 13232 2 ecb,cryptomgr, Live 0xc056c000
aead 7168 1 cryptomgr, Live 0xc0560000
pcompress 1952 1 cryptomgr, Live 0xc0558000
crypto_algapi 18176 7
arc4,ecb,cryptomgr,crypto_hash,crypto_blkcipher,aead,pcompress, Live 0xc054a000
zd1211rw 78736 0 - Live 0xc0527000
mac80211 174976 1 zd1211rw, Live 0xc04d6000
crypto 13360 8
ecb,cryptomgr,crypto_hash,crypto_blkcipher,aead,pcompress,crypto_algapi,
mac80211, Live
0xc048c000
cfg80211 79216 2 zd1211rw,mac80211, Live 0xc046e000
rfmod 3808 1 - Live 0xc0448000 (P)
dreambox_keyboard 5248 0 - Live 0xc043d000 (P)
dreambox_rc2 5248 1 dreambox_keyboard, Live 0xc0431000 (P)
xilleon 222592 6 - Live 0xc0185000 (P)
alps_bsbe1_c01a 19568 1 xilleon, Live 0xc0132000 (P)
alps_bsbe1 5264 1 xilleon, Live 0xc0124000 (P)
avs 11168 1 xilleon, Live 0xc0117000 (P)
alps_bsbe2 44480 1 xilleon, Live 0xc0103000 (P)
lnb_ctrl 5664 3 alps_bsbe1_c01a,alps_bsbe1,alps_bsbe2, Live 0xc00f0000 (P)
tu1216 44912 1 xilleon, Live 0xc00de000
cu1216mk3 9504 1 xilleon, Live 0xc00c9000 (P)
stb_core 52704 10
dreambox_keyboard,dreambox_rc2,xilleon,alps_bsbe1_c01a,avs,alps_bsbe2,
lnb_ctrl,cu1216mk3,
Live 0xc00b1000 (P)
pata_xilleon 3888 1 - Live 0xc0095000
lcd 30800 1 - Live 0xc0084000 (P)
fp 21840 4 xilleon,avs,lcd, Live 0xc0072000 (P)
Output from DMESG:
[ 279.131000] cfg80211: Calling CRDA to update world regulatory domain
[ 279.509000] zd1211rw usb_init()
[ 279.520000] usbcore: registered new interface driver zd1211rw
[ 279.526000] zd1211rw initialized
[ 292.405000] usb 1-1: new full speed USB device using ohci_hcd
and address 2
[ 292.557000] usb 1-1: configuration #1 chosen from 1 choice
[ 292.573000] usb 1-1: print_id() 050d:705c v4810 full
[ 292.686000] usb 1-1: reset full speed USB device using ohci_hcd
and address 2
[ 292.829000] zd1211rw 1-1:1.0: zd_chip_read_mac_addr_fw()
[ 293.308000] phy0: Selected rate control algorithm 'pid'
[ 293.309000] zd1211rw 1-1:1.0: probe() successful
[ 293.309000] zd1211rw 1-1:1.0: phy0
[ 359.661000] warning: `vsftpd' uses 32-bit capabilities (legacy support in use)
[ 408.957000] zd1211rw 1-1:1.0: zd_usb_init_hw()
[ 408.957000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_ub
[ 408.957000] usb 1-1: firmware: requesting zd1211/zd1211b_ub
[ 409.022000] usb 1-1: upload_firmware() firmware device id 0x4810 is equal
to
the actual device id
[ 409.022000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_uphr
[ 409.022000] usb 1-1: firmware: requesting zd1211/zd1211b_uphr
[ 409.079000] usb 1-1: upload_code() transfer size 4018
[ 409.094000] usb 1-1: upload_code() firmware confirm return value 0x01
[ 414.094000] zd1211rw 1-1:1.0: zd_usb_init_hw()
couldn't reset configuration. Error number -145
[ 415.226000] zd1211rw 1-1:1.0: zd_usb_init_hw()
[ 415.226000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_ub
[ 415.226000] usb 1-1: firmware: requesting zd1211/zd1211b_ub
[ 415.271000] usb 1-1: upload_firmware()
firmware device id 0x4810 is equal to the actual device id
[ 415.271000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_uphr
[ 415.271000] usb 1-1: firmware: requesting zd1211/zd1211b_uphr
[ 415.350000] usb 1-1: upload_code() transfer size 4018
[ 416.350000] usb 1-1: USB control request for firmware upload failed.
Error number -145
[ 416.358000] usb 1-1: Could not upload firmware code uph. Error number -145
[ 416.365000] zd1211rw 1-1:1.0: couldn't load firmware. Error number -145
[ 432.484000] zd1211rw 1-1:1.0: zd_usb_init_hw()
[ 432.484000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_ub
[ 432.484000] usb 1-1: firmware: requesting zd1211/zd1211b_ub
[ 432.529000] usb 1-1: upload_firmware()
firmware device id 0x4810 is equal to the actual device id
[ 432.529000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_uphr
[ 432.529000] usb 1-1: firmware: requesting zd1211/zd1211b_uphr
[ 432.608000] usb 1-1: upload_code() transfer size 4018
[ 433.608000] usb 1-1: USB control request for firmware upload failed.
Error number -145
[ 433.616000] usb 1-1: Could not upload firmware code uph. Error number -145
[ 433.623000] zd1211rw 1-1:1.0: couldn't load firmware. Error number -145
[ 434.827000] eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
output from lsusb
Bus 001 Device 002: ID 050d:705c Belkin Components
the Firmware Files are located with correct right under /lib/firmware/zd1211
any idea on this ?
Regards
Mladen
^ permalink raw reply
* Re: BUG: ifdown doesn't notify cfg80211
From: Holger Schurig @ 2009-07-29 11:25 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <200907291310.50121.hs4233@mail.mn-solutions.de>
On Wednesday 29 July 2009 13:10:50 Holger Schurig wrote:
> # iw dev eth1 connect -w MNHS key 0:11111
> eth1 (phy #0): connected to 00:13:19:80:da:30
> # ifconfig eth1 down
> # iw dev eth1 connect -w MNHS key 0:11111
> # ifconfig eth1 down
Oops, a copy'n'paste error. I didn't send those two lines twice
at this point. The correct sequence I did:
# iw dev eth1 connect -w MNHS key 0:11111
eth1 (phy #0): connected to 00:13:19:80:da:30
# ifconfig eth1 down
# ifconfig eth1 up
# iw dev eth1 connect -w MNHS key 0:11111
command failed: Operation already in progress (-114)
--
http://www.holgerschurig.de
^ permalink raw reply
* BUG: ifdown doesn't notify cfg80211
From: Holger Schurig @ 2009-07-29 11:10 UTC (permalink / raw)
To: linux-wireless
# iw dev eth1 connect -w MNHS key 0:11111
eth1 (phy #0): connected to 00:13:19:80:da:30
# ifconfig eth1 down
# iw dev eth1 connect -w MNHS key 0:11111
# ifconfig eth1 down
# ifconfig eth1 up
# iw dev eth1 connect -w MNHS key 0:11111
command failed: Operation already in progress (-114)
Only when I do "iw dev eth1 disconnect" can I connect again.
Shouldn't downing the interface clear the "I'm connected" state?
--
http://www.holgerschurig.de
^ permalink raw reply
* Pulling rt73 USB stick oopses the kernel
From: Michael Buesch @ 2009-07-29 10:24 UTC (permalink / raw)
To: linux-wireless
Pulling a rt73 USB stick in operation (packets were injected into the monitor)
does oops the kernel as follows:
[ 630.304883] rt73usb 2-6:1.0: firmware: requesting rt73.bin
[ 630.417740] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 700.489876] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 743.571488] device wlan1 entered promiscuous mode
[ 829.207708] usb 2-6: USB disconnect, address 4
[ 829.208272] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x3040 with error -19.
[ 829.208355] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x3040 with error -19.
[ 829.208436] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x3028 with error -19.
[ 829.208516] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x3064 with error -19.
[ 829.208595] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x0c failed for offset 0x0000 with error -19.
[ 829.208687] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x0a failed for offset 0x0000 with error -19.
[ 829.209622] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x0a failed for offset 0x0000 with error -19.
[ 829.209832] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x0a failed for offset 0x0000 with error -19.
[ 829.210187] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x0a failed for offset 0x0000 with error -19.
[ 829.223337] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x3040 with error -19.
[ 829.223424] phy1 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x3040 with error -19.
[ 829.269467] =============================================================================
[ 829.269554] BUG kmalloc-16: Redzone overwritten
[ 829.269615] -----------------------------------------------------------------------------
[ 829.269618]
[ 829.269746] INFO: 0xf56c4b50-0xf56c4b53. First byte 0xb instead of 0xcc
[ 829.269821] INFO: Allocated in rt2x00usb_probe+0xb5/0x1c1 [rt2x00usb] age=104615 cpu=0 pid=3965
[ 829.269902] INFO: Slab 0xc20bc880 objects=64 used=53 fp=0xf56c4b80 flags=0x40000083
[ 829.269940] INFO: Object 0xf56c4b40 @offset=2880 fp=0xf56c4b80
[ 829.269940]
[ 829.269940] Bytes b4 0xf56c4b30: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
[ 829.269940] Object 0xf56c4b40: 00 00 00 00 0c 2c 00 00 86 07 00 00 51 a2 06 00 .....,......Q¢..
[ 829.269940] Redzone 0xf56c4b50: 0b 2a 0d 00 .*..
[ 829.269940] Padding 0xf56c4b78: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[ 829.269940] Pid: 810, comm: khubd Not tainted 2.6.31-rc4-wl #2
[ 829.269940] Call Trace:
[ 829.269940] [<c10bff6b>] print_trailer+0xd3/0x108
[ 829.269940] [<c10c0066>] check_bytes_and_report+0xc6/0xe3
[ 829.269940] [<c10c010f>] check_object+0x53/0x1ea
[ 829.269940] [<c10c1d28>] __slab_free+0x1e7/0x2c8
[ 829.269940] [<c10c2120>] kfree+0xc9/0x137
[ 829.269940] [<f86fb05f>] ? rt2x00usb_free_reg+0x11/0x48 [rt2x00usb]
[ 829.269940] [<f86fb05f>] ? rt2x00usb_free_reg+0x11/0x48 [rt2x00usb]
[ 829.269940] [<f86fb05f>] rt2x00usb_free_reg+0x11/0x48 [rt2x00usb]
[ 829.269940] [<f86fb0b5>] rt2x00usb_disconnect+0x1f/0x40 [rt2x00usb]
[ 829.269940] [<f8063357>] usb_unbind_interface+0xdf/0x116 [usbcore]
[ 829.269940] [<c11f7247>] __device_release_driver+0x53/0x96
[ 829.269940] [<c11f732a>] device_release_driver+0x18/0x23
[ 829.269940] [<c11f6992>] bus_remove_device+0x70/0x94
[ 829.269940] [<c11f4fff>] device_del+0x103/0x186
[ 829.269940] [<f8060462>] usb_disable_device+0x79/0xe4 [usbcore]
[ 829.269940] [<f805b69f>] usb_disconnect+0x8a/0xee [usbcore]
[ 829.269940] [<f805c804>] hub_thread+0x691/0x125d [usbcore]
[ 829.269940] [<c1020100>] ? chk_conflict+0x13e/0x16c
[ 829.269940] [<c12dbdab>] ? _spin_unlock_irqrestore+0x39/0x68
[ 829.269940] [<c1057cdb>] ? trace_hardirqs_on_caller+0x102/0x146
[ 829.269940] [<c1047699>] ? autoremove_wake_function+0x0/0x3a
[ 829.269940] [<f805c173>] ? hub_thread+0x0/0x125d [usbcore]
[ 829.269940] [<c104738c>] kthread+0x6f/0x75
[ 829.269940] [<c104731d>] ? kthread+0x0/0x75
[ 829.269940] [<c1003977>] kernel_thread_helper+0x7/0x1a
[ 829.269940] FIX kmalloc-16: Restoring 0xf56c4b50-0xf56c4b53=0xcc
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] wireless-regdb: TH gets 5 GHz enabled as of new regulatory rules
From: Phattanon Duangdara @ 2009-07-29 10:13 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1248285108-10059-1-git-send-email-lrodriguez@atheros.com>
I corrected redgb from my knowledge.
For 5150-5350 is for Indoor Use Only.
Most of the regulartory refer _either_ FCC or ETSI/ITU standard, so I
guess that from the document 40MHz can also be used (same as US)
because TH regulatory mostly cover all bandwidth on 40MHz.
I corrected power but What a field before power is (that is now N/A below) ?
# TH Data (2008) from
http://www.ratchakitcha.soc.go.th/DATA/PDF/2551/E/042/64.PDF
country TH:
(2402 - 2472 @ 40), (N/A, 20)
(5170 - 5250 @ 40), (N/A, 23), NO-OUTDOOR
(5250 - 5330 @ 40), (N/A, 23), NO-OUTDOOR, DFS
(5490 - 5710 @ 40), (N/A, 30), DFS
(5735 - 5835 @ 30), (N/A, 30)
Summary I got from the document
2400-2500 MHz
Max Power (e.i.r.p): 100mW
Bandwidth: Not specified
Usage: Not specified
Ref Standard (either):
EN 300 328-2 : Electromagnetic compatibility and Radio spectrum Matters
(ERM); Wideband Transmission systems; Data transmission
equipment operating in the 2,4 GHz ISM band and using
spread spectrum modulation techniques; Part 2: Harmonized
EN covering essential requirements under article 3.2 of R&TTE
Directive
FCC Part 15.247 : Code of Federal Regulations (USA); Title 47
Telecommunication; Chapter 1 Federal Communications
Commission; Part 15 Radio Frequency Devices; Subpart C –
Intentional Radiators; §15.247 Operation within the bands 902–
928 MHz, 2400–2483.5 MHz, and 5725–5850 MHz
5150-5350 MHz
Max Power (e.i.r.p): 200mW, Density 10mW/MHz (0.25mW/25KHz)
Bandwidth: Not specified
Usage: Indoor applications only, DFS is must
Resolution 229 (WRC-03)
(Radio Regulations) - Use of the bands 5 150-5 250 MHz, 5 250-5 350
MHz and 5 470-5 725
MHz by the mobile service for the implementation of wireless access
systems including
radio local area networks
Recommendation ITU-R M. 1652 (Annex 1): Dynamic
frequency selection (DFS) in wireless access systems including radio
local area networks
for the purpose of protecting the radiocommunication service in the 5 GHz band
Ref Standard (either):
ETSI EN 301 893 : Broadband Radio Access Networks (BRAN); 5 GHz high
performance RLAN; Harmonized EN covering essential
requirements of article 3.2 of the R&TTE Directive
FCC Part 15.407 : Code of Federal Regulations (USA); Title 47
Telecommunications; Chapter 1 Federal Communications
Commission; Part 15 Radio Frequency Devices; Subpart E –
Unlicensed National Information Infrastructure Devices;
§ 15.407 General technical requirements
5450-5725 MHz
Max Power (e.i.r.p): 1W, Density 50mW/MHz
Bandwidth: Not specified
Usage: Not specified, DFS is must
Resolution 229 (WRC-03)
(Radio Regulations) - Use of the bands 5 150-5 250 MHz, 5 250-5 350
MHz and 5 470-5 725
MHz by the mobile service for the implementation of wireless access
systems including
radio local area networks
Recommendation ITU-R M. 1652 (Annex 1): Dynamic
frequency selection (DFS) in wireless access systems including radio
local area networks
for the purpose of protecting the radiocommunication service in the 5 GHz band
Ref Standard (either):
ETSI EN 301 893 : Broadband Radio Access Networks (BRAN); 5 GHz high
performance RLAN; Harmonized EN covering essential
requirements of article 3.2 of the R&TTE Directive
Code of Federal Regulations (USA); Title 47
Telecommunications; Chapter 1 Federal Communications
Commission; Part 15 Radio Frequency Devices; Subpart E –
Unlicensed National Information Infrastructure Devices;
§ 15.407 General technical requirements
5725-5850 MHz
Max Power (e.i.r.p): 1W
Bandwidth: Not specified
Usage: Not specified
Ref Standard (either):
FCC Part 15.247 : Code of Federal Regulations (USA); Title 47
Telecommunication; Chapter 1 Federal Communications
Commission; Part 15 Radio Frequency Devices; Subpart C –
Intentional Radiators; §15.247 Operation within the bands 902–
928 MHz, 2400–2483.5 MHz, and 5725–5850 MHz
Code of Federal Regulations (USA); Title 47
Telecommunications; Chapter 1 Federal Communications
Commission; Part 15 Radio Frequency Devices; Subpart E –
Unlicensed National Information Infrastructure Devices;
§ 15.407 General technical requirements
Phattanon,
On Thu, Jul 23, 2009 at 12:51 AM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> Phattanon Duangdara reported the National Telecommunication
> Commisions of Thailand has announced new regulatory rules
> about 5GHz for RLAN last year.
>
> I have verified this matches our documentation internally
> at Atheros.
>
> Reference in Thai Language:
> http://www.ratchakitcha.soc.go.th/DATA/PDF/2551/E/042/64.PDF
>
> Cc: Michael Green <michael.green@atheros.com>
> Cc: David Quan <david.quan@atheros.com>
> Reported-by: Phattanon Duangdara <sfalpha@gmail.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> db.txt | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index fad098d..01536d6 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -534,7 +534,11 @@ country TW:
> (5735 - 5815 @ 40), (3, 30)
>
> country TH:
> - (2402 - 2482 @ 40), (N/A, 20)
> + (2402 - 2482 @ 20), (N/A, 20)
> + (5170 - 5250 @ 20), (3, 17)
> + (5250 - 5330 @ 20), (3, 20), DFS
> + (5490 - 5710 @ 20), (3, 20), DFS
> + (5735 - 5835 @ 20), (3, 30)
>
> country TT:
> (2402 - 2482 @ 40), (N/A, 20)
> --
> 1.6.3.3
>
>
^ permalink raw reply
* Re: ar9170 DWA 160A
From: Chunkeey @ 2009-07-29 9:43 UTC (permalink / raw)
To: linux-wireless, Luis R. Rodriguez, otus-devel; +Cc: Felix Bitterli
"Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
> We have these listed on ar9170 wiki page as under Dlink DWA160A:
>
> 0x07d1:0x3c10
> 0x0846:0x9010
>
> A user just reported thy purchased DWA160 by mistake thinking it was
> the same but it turns out it has some other wireless chipset.
hmm, did you check D-Link's product & support side?
http://www.dlink.com/products/?pid=DWA-160
lists two different revisions:
- DWA 160A (usbid 0x07d1:0x3c10) ar9170 chip
- DWA 160B (usbid 0x07d1:0x3c11) rt2870 chip
---
> Do any of you have a DWA160A that is claimed by ar9170 or should
> we remove this from the list?
http://www.ubuntu-forum.de/artikel/45079/kompilierungsfehler-compat-wireless-hilfe-beim-beheben.html
"@Fremdkoeperfalle: [...] mein D-Link DWA -160 funktioniert." => ~ "my D-LINK DWA-160 works."
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
^ permalink raw reply
* [PATCH 3/3] ath9k: Remove unused ath9k_hw_intrget()
From: Vasanthakumar Thiagarajan @ 2009-07-29 9:35 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
In-Reply-To: <1248860123-12079-2-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 5 -----
drivers/net/wireless/ath/ath9k/hw.h | 1 -
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 431854c..7a0a6ae 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -3152,11 +3152,6 @@ bool ath9k_hw_getisr(struct ath_hw *ah, enum ath9k_int *masked)
return true;
}
-enum ath9k_int ath9k_hw_intrget(struct ath_hw *ah)
-{
- return ah->mask_reg;
-}
-
enum ath9k_int ath9k_hw_set_interrupts(struct ath_hw *ah, enum ath9k_int ints)
{
u32 omask = ah->mask_reg;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 2e196df..93a8930 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -612,7 +612,6 @@ void ath9k_hw_configpcipowersave(struct ath_hw *ah, int restore);
/* Interrupt Handling */
bool ath9k_hw_intrpend(struct ath_hw *ah);
bool ath9k_hw_getisr(struct ath_hw *ah, enum ath9k_int *masked);
-enum ath9k_int ath9k_hw_intrget(struct ath_hw *ah);
enum ath9k_int ath9k_hw_set_interrupts(struct ath_hw *ah, enum ath9k_int ints);
void ath9k_hw_btcoex_enable(struct ath_hw *ah);
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/3] ath9k: Maintain monotonicity of PER while going across different phy
From: Vasanthakumar Thiagarajan @ 2009-07-29 9:35 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
In-Reply-To: <1248860123-12079-1-git-send-email-vasanth@atheros.com>
Monotonicity of packet error rate should be kept when moving
from one phy to another (legacy to ht, ht single stream to dual,
etc). Current code skips updating per for other phys.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/rc.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index 59ad47c..16a2717 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -1041,9 +1041,6 @@ static void ath_rc_update_ht(struct ath_softc *sc,
/* Monotonicity is kept only for rates below the current rate. */
if (ath_rc_priv->per[tx_rate] < last_per) {
for (rate = tx_rate - 1; rate >= 0; rate--) {
- if (rate_table->info[rate].phy !=
- rate_table->info[tx_rate].phy)
- break;
if (ath_rc_priv->per[rate] >
ath_rc_priv->per[rate+1]) {
--
1.5.5.1
^ permalink raw reply related
* [PATCH 1/3] ath9k: Update rate control for 11NA HT40 mode
From: Vasanthakumar Thiagarajan @ 2009-07-29 9:35 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
Now the lowest rate in 11na ht40 mode is 13.5Mbps this shortens the
range when compared to 11na ht20 mode where the lowest rate is 6.5Mbps.
To improve the range, make 6.5Mbps as the lowest rate in 11na ht40 mode,
this improves the range by approximately 2dB. 11ng ht40 does not have
this issue as it also has basic rates (1, 2, 5.5 and 11).
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/rc.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index a07efa2..59ad47c 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -44,7 +44,7 @@ static const struct ath_rate_table ar5416_11na_ratetable = {
{ VALID, VALID, WLAN_RC_PHY_OFDM, 54000, /* 54 Mb */
29300, 0x0c, 0x00, 108,
4, 7, 7, 7, 7, 0 },
- { VALID_20, VALID_20, WLAN_RC_PHY_HT_20_SS, 6500, /* 6.5 Mb */
+ { VALID_2040, VALID_2040, WLAN_RC_PHY_HT_20_SS, 6500, /* 6.5 Mb */
6400, 0x80, 0x00, 0,
0, 8, 24, 8, 24, 3216 },
{ VALID_20, VALID_20, WLAN_RC_PHY_HT_20_SS, 13000, /* 13 Mb */
@@ -463,8 +463,6 @@ static int ath_rc_valid_phyrate(u32 phy, u32 capflag, int ignore_cw)
if (!ignore_cw && WLAN_RC_PHY_HT(phy))
if (WLAN_RC_PHY_40(phy) && !(capflag & WLAN_RC_40_FLAG))
return 0;
- if (!WLAN_RC_PHY_40(phy) && (capflag & WLAN_RC_40_FLAG))
- return 0;
return 1;
}
--
1.5.5.1
^ permalink raw reply related
* [PATCH v2] cfg80211: keep track of current_bss for userspace SME
From: Johannes Berg @ 2009-07-29 9:23 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1248855029.13742.15.camel@johannes.local>
When a userspace SME is active, we're currently not
keeping track of the BSS properly for reporting the
current link and for internal use. Additionally, it
looks like there is a possible BSS leak in that the
BSS never gets removed from auth_bsses[]. To fix it,
pass the BSS struct to __cfg80211_connect_result in
this case.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
v2: hold already is a counter, so no race necessary
net/wireless/core.c | 3 ++-
net/wireless/core.h | 8 +++++++-
net/wireless/mlme.c | 38 ++++++++++++++++++++++++--------------
net/wireless/sme.c | 35 ++++++++++++++++++-----------------
4 files changed, 51 insertions(+), 33 deletions(-)
--- wireless-testing.orig/net/wireless/core.c 2009-07-29 01:08:03.000000000 +0200
+++ wireless-testing/net/wireless/core.c 2009-07-29 01:08:58.000000000 +0200
@@ -314,7 +314,8 @@ static void cfg80211_process_events(stru
ev->cr.req_ie, ev->cr.req_ie_len,
ev->cr.resp_ie, ev->cr.resp_ie_len,
ev->cr.status,
- ev->cr.status == WLAN_STATUS_SUCCESS);
+ ev->cr.status == WLAN_STATUS_SUCCESS,
+ NULL);
break;
case EVENT_ROAMED:
__cfg80211_roamed(wdev, ev->rm.bssid,
--- wireless-testing.orig/net/wireless/core.h 2009-07-29 01:08:03.000000000 +0200
+++ wireless-testing/net/wireless/core.h 2009-07-29 10:17:21.000000000 +0200
@@ -127,6 +127,11 @@ static inline struct cfg80211_internal_b
return container_of(pub, struct cfg80211_internal_bss, pub);
}
+static inline void cfg80211_ref_bss(struct cfg80211_internal_bss *bss)
+{
+ kref_get(&bss->ref);
+}
+
static inline void cfg80211_hold_bss(struct cfg80211_internal_bss *bss)
{
atomic_inc(&bss->hold);
@@ -323,7 +328,8 @@ void cfg80211_mlme_down(struct cfg80211_
void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
const u8 *req_ie, size_t req_ie_len,
const u8 *resp_ie, size_t resp_ie_len,
- u16 status, bool wextev);
+ u16 status, bool wextev,
+ struct cfg80211_bss *bss);
/* SME */
int __cfg80211_connect(struct cfg80211_registered_device *rdev,
--- wireless-testing.orig/net/wireless/mlme.c 2009-07-29 01:08:03.000000000 +0200
+++ wireless-testing/net/wireless/mlme.c 2009-07-29 10:21:45.000000000 +0200
@@ -61,7 +61,7 @@ void cfg80211_send_rx_assoc(struct net_d
struct ieee80211_mgmt *mgmt = (struct ieee80211_mgmt *)buf;
u8 *ie = mgmt->u.assoc_resp.variable;
int i, ieoffs = offsetof(struct ieee80211_mgmt, u.assoc_resp.variable);
- bool done;
+ struct cfg80211_internal_bss *bss = NULL;
wdev_lock(wdev);
@@ -69,22 +69,32 @@ void cfg80211_send_rx_assoc(struct net_d
nl80211_send_rx_assoc(rdev, dev, buf, len, GFP_KERNEL);
- __cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, ie, len - ieoffs,
- status_code,
- status_code == WLAN_STATUS_SUCCESS);
-
if (status_code == WLAN_STATUS_SUCCESS) {
- for (i = 0; wdev->current_bss && i < MAX_AUTH_BSSES; i++) {
- if (wdev->auth_bsses[i] == wdev->current_bss) {
- cfg80211_unhold_bss(wdev->auth_bsses[i]);
- cfg80211_put_bss(&wdev->auth_bsses[i]->pub);
+ for (i = 0; i < MAX_AUTH_BSSES; i++) {
+ if (!wdev->auth_bsses[i])
+ continue;
+ if (memcmp(wdev->auth_bsses[i]->pub.bssid, mgmt->bssid,
+ ETH_ALEN) == 0) {
+ bss = wdev->auth_bsses[i];
wdev->auth_bsses[i] = NULL;
- done = true;
+ /* additional reference to drop hold */
+ cfg80211_ref_bss(bss);
break;
}
}
- WARN_ON(!done);
+ WARN_ON(!bss);
+ }
+
+ /* this consumes one bss reference (unless bss is NULL) */
+ __cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, ie, len - ieoffs,
+ status_code,
+ status_code == WLAN_STATUS_SUCCESS,
+ bss ? &bss->pub : NULL);
+ /* drop hold now, and also reference acquired above */
+ if (bss) {
+ cfg80211_unhold_bss(bss);
+ cfg80211_put_bss(&bss->pub);
}
wdev_unlock(wdev);
@@ -144,7 +154,7 @@ static void __cfg80211_send_deauth(struc
} else if (wdev->sme_state == CFG80211_SME_CONNECTING) {
__cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
}
}
@@ -241,7 +251,7 @@ void cfg80211_send_auth_timeout(struct n
if (wdev->sme_state == CFG80211_SME_CONNECTING)
__cfg80211_connect_result(dev, addr, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
for (i = 0; addr && i < MAX_AUTH_BSSES; i++) {
if (wdev->authtry_bsses[i] &&
@@ -275,7 +285,7 @@ void cfg80211_send_assoc_timeout(struct
if (wdev->sme_state == CFG80211_SME_CONNECTING)
__cfg80211_connect_result(dev, addr, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
for (i = 0; addr && i < MAX_AUTH_BSSES; i++) {
if (wdev->auth_bsses[i] &&
--- wireless-testing.orig/net/wireless/sme.c 2009-07-29 01:07:07.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2009-07-29 01:10:28.000000000 +0200
@@ -182,7 +182,7 @@ void cfg80211_conn_work(struct work_stru
wdev->conn->params.bssid,
NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
wdev_unlock(wdev);
}
@@ -247,7 +247,7 @@ static void __cfg80211_sme_scan_done(str
wdev->conn->params.bssid,
NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
}
}
@@ -305,7 +305,7 @@ void cfg80211_sme_rx_auth(struct net_dev
schedule_work(&rdev->conn_work);
} else if (status_code != WLAN_STATUS_SUCCESS) {
__cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, NULL, 0,
- status_code, false);
+ status_code, false, NULL);
} else if (wdev->sme_state == CFG80211_SME_CONNECTING &&
wdev->conn->state == CFG80211_CONN_AUTHENTICATING) {
wdev->conn->state = CFG80211_CONN_ASSOCIATE_NEXT;
@@ -316,10 +316,10 @@ void cfg80211_sme_rx_auth(struct net_dev
void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
const u8 *req_ie, size_t req_ie_len,
const u8 *resp_ie, size_t resp_ie_len,
- u16 status, bool wextev)
+ u16 status, bool wextev,
+ struct cfg80211_bss *bss)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
- struct cfg80211_bss *bss;
#ifdef CONFIG_WIRELESS_EXT
union iwreq_data wrqu;
#endif
@@ -361,6 +361,12 @@ void __cfg80211_connect_result(struct ne
}
#endif
+ if (wdev->current_bss) {
+ cfg80211_unhold_bss(wdev->current_bss);
+ cfg80211_put_bss(&wdev->current_bss->pub);
+ wdev->current_bss = NULL;
+ }
+
if (status == WLAN_STATUS_SUCCESS &&
wdev->sme_state == CFG80211_SME_IDLE)
goto success;
@@ -368,12 +374,6 @@ void __cfg80211_connect_result(struct ne
if (wdev->sme_state != CFG80211_SME_CONNECTING)
return;
- if (wdev->current_bss) {
- cfg80211_unhold_bss(wdev->current_bss);
- cfg80211_put_bss(&wdev->current_bss->pub);
- wdev->current_bss = NULL;
- }
-
if (wdev->conn)
wdev->conn->state = CFG80211_CONN_IDLE;
@@ -386,10 +386,12 @@ void __cfg80211_connect_result(struct ne
return;
}
- bss = cfg80211_get_bss(wdev->wiphy, NULL, bssid,
- wdev->ssid, wdev->ssid_len,
- WLAN_CAPABILITY_ESS,
- WLAN_CAPABILITY_ESS);
+ success:
+ if (!bss)
+ bss = cfg80211_get_bss(wdev->wiphy, NULL, bssid,
+ wdev->ssid, wdev->ssid_len,
+ WLAN_CAPABILITY_ESS,
+ WLAN_CAPABILITY_ESS);
if (WARN_ON(!bss))
return;
@@ -397,7 +399,6 @@ void __cfg80211_connect_result(struct ne
cfg80211_hold_bss(bss_from_pub(bss));
wdev->current_bss = bss_from_pub(bss);
- success:
wdev->sme_state = CFG80211_SME_CONNECTED;
cfg80211_upload_connect_keys(wdev);
}
@@ -788,7 +789,7 @@ int __cfg80211_disconnect(struct cfg8021
else if (wdev->sme_state == CFG80211_SME_CONNECTING)
__cfg80211_connect_result(dev, NULL, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- wextev);
+ wextev, NULL);
return 0;
}
^ permalink raw reply
* The problem of driver of rtl8187 wireless card
From: gu gu @ 2009-07-29 9:24 UTC (permalink / raw)
To: linux-wireless
Dear Sir,
Rencently,I do a job to transplant a wireless wifi-card connected by the USB,which was designed baseing the chip rtl8187 for ARM board.But in the process i have some trouble in writing the driver programe.
My linux kernel is Version-2.6.25.10,It is true that the kernel have the driver for the chip rtl8187 .When I connected the wifi card through the USB port ,the kernel can recoganize the card "Manufacturer_Realtek_RTL8187",So it's sure that the driver of RTL8187 is no problem.But when I ping it to the AP,the missing of datapackets and the delay are both terrible.and more , there is nothing accepted by the wireless router when i typed the "ping".
so i think there is some bug exist in the driver for RTL8187 of kernel ,isn't it? (ps: I have set several parameter,such essid ,IP address...)
So I download a "compat-wireless-2.6-old" packet.following the " Readme",i added the KLIB & KLIB_BUILD in the Makefile and "make" it.It is well to generate some modules with the typing".o"! but has not compiled the file rtl8187 or generated a "rtl8187.o".
and so i wanna to know how to solve this problem. i need some help from u,
Thank you for your attention!
Gu C.L.
___________________________________________________________
好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/
^ permalink raw reply
* Re: [PATCH] b43: Work around mac80211 race condition that may transmit one packet after queue is stopped
From: Michael Buesch @ 2009-07-29 9:00 UTC (permalink / raw)
To: Larry Finger; +Cc: John W Linville, Johannes Berg, linux-wireless
In-Reply-To: <4a6fa3fe.kYeW+HADItDIXTLm%Larry.Finger@lwfinger.net>
On Wednesday 29 July 2009 03:21:02 Larry Finger wrote:
> As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497,
> mac80211 has a bug that allows a call to the TX routine after the queues have
> been stopped. This situation will only occur under extreme stress. Although
> b43 does not crash when this condition occurs, it does generate a WARN_ON and
> also logs a queue overrun message. This patch recognizes b43 is not at fault
> and logs a message only when the most verbose debugging mode is enabled. In
> the unlikely event that the queue is not stopped when the DMA queue becomes
> full, then a warning is issued.
>
> During testing of this patch with one output stream running repeated tcpperf
> writes and a second running a flood ping, this routine was entered with
> the DMA ring stopped about once per hour. The condition where the DMA queue is
> full but the ring has not been stopped has never been seen by me.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> John,
>
> This patch is 2.6.32 material.
ack
>
> Larry
> ---
>
> Index: wireless-testing/drivers/net/wireless/b43/dma.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/b43/dma.c
> +++ wireless-testing/drivers/net/wireless/b43/dma.c
> @@ -1334,13 +1334,23 @@ int b43_dma_tx(struct b43_wldev *dev, st
> spin_lock_irqsave(&ring->lock, flags);
>
> B43_WARN_ON(!ring->tx);
> - /* Check if the queue was stopped in mac80211,
> - * but we got called nevertheless.
> - * That would be a mac80211 bug. */
> - B43_WARN_ON(ring->stopped);
> +
> + if (unlikely(ring->stopped)) {
> + /* We get here only because of a bug in mac80211.
> + * Because of a race, one packet may be queued after
> + * the queue is stopped, thus we got called when we shouldn't.
> + * For now, just refuse the transmit. */
> + if (b43_debug(dev, B43_DBG_DMAVERBOSE))
> + b43err(dev->wl, "Packet after queue stopped\n");
> + err = -ENOSPC;
> + goto out_unlock;
> + }
>
> if (unlikely(free_slots(ring) < TX_SLOTS_PER_FRAME)) {
> - b43warn(dev->wl, "DMA queue overflow\n");
> + /* If we get here, we have a real error with the queue
> + * full, but queues not stopped. */
> + b43err(dev->wl, "DMA queue overflow\n");
> + WARN_ON(1);
> err = -ENOSPC;
> goto out_unlock;
> }
>
>
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] mac80211: disable beacons before removing the associated interface
From: Johannes Berg @ 2009-07-29 8:13 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Bob Copeland
From: Bob Copeland <me@bobcopeland.com>
When downing interfaces, it's a good idea to tell the driver to
stop sending beacons; that way the driver doesn't need special
code in ops->remove_interface() when it should already handle the
case in bss_info_changed().
This fixes a potential crash with at least ath5k since the vif
pointer will be nullified while beacon interrupts are still active.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/iface.c | 10 ++++++++++
net/mac80211/main.c | 3 ++-
net/mac80211/pm.c | 4 ++++
3 files changed, 16 insertions(+), 1 deletion(-)
--- wireless-testing.orig/net/mac80211/iface.c 2009-07-29 10:06:06.000000000 +0200
+++ wireless-testing/net/mac80211/iface.c 2009-07-29 10:11:35.000000000 +0200
@@ -522,6 +522,16 @@ static int ieee80211_stop(struct net_dev
ieee80211_scan_completed(&local->hw, true);
}
+ /*
+ * Disable beaconing for AP and mesh, IBSS can't
+ * still be joined to a network at this point.
+ */
+ if (sdata->vif.type == NL80211_IFTYPE_AP ||
+ sdata->vif.type == NL80211_IFTYPE_MESH_POINT) {
+ ieee80211_bss_info_change_notify(sdata,
+ BSS_CHANGED_BEACON_ENABLED);
+ }
+
conf.vif = &sdata->vif;
conf.type = sdata->vif.type;
conf.mac_addr = dev->dev_addr;
--- wireless-testing.orig/net/mac80211/main.c 2009-07-29 10:06:06.000000000 +0200
+++ wireless-testing/net/mac80211/main.c 2009-07-29 10:11:35.000000000 +0200
@@ -198,7 +198,8 @@ void ieee80211_bss_info_change_notify(st
}
if (changed & BSS_CHANGED_BEACON_ENABLED) {
- if (test_bit(SCAN_SW_SCANNING, &local->scanning)) {
+ if (local->quiescing || !netif_running(sdata->dev) ||
+ test_bit(SCAN_SW_SCANNING, &local->scanning)) {
sdata->vif.bss_conf.enable_beacon = false;
} else {
/*
--- wireless-testing.orig/net/mac80211/pm.c 2009-07-29 10:06:06.000000000 +0200
+++ wireless-testing/net/mac80211/pm.c 2009-07-29 10:11:35.000000000 +0200
@@ -96,6 +96,10 @@ int __ieee80211_suspend(struct ieee80211
if (!netif_running(sdata->dev))
continue;
+ /* disable beaconing */
+ ieee80211_bss_info_change_notify(sdata,
+ BSS_CHANGED_BEACON_ENABLED);
+
conf.vif = &sdata->vif;
conf.type = sdata->vif.type;
conf.mac_addr = sdata->dev->dev_addr;
^ permalink raw reply
* [PATCH] cfg80211: keep track of current_bss for userspace SME
From: Johannes Berg @ 2009-07-29 8:10 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When a userspace SME is active, we're currently not
keeping track of the BSS properly for reporting the
current link and for internal use. Additionally, it
looks like there is a possible BSS leak in that the
BSS never gets removed from auth_bsses[]. To fix it,
pass the BSS struct to __cfg80211_connect_result in
this case.
This patch leaves a small race condition window in
which the BSS may be recycled because it isn't held,
I'll fix that separately by making the hold info a
refcount.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/core.c | 3 ++-
net/wireless/core.h | 3 ++-
net/wireless/mlme.c | 29 ++++++++++++++++-------------
net/wireless/sme.c | 35 ++++++++++++++++++-----------------
4 files changed, 38 insertions(+), 32 deletions(-)
--- wireless-testing.orig/net/wireless/core.c 2009-07-29 01:08:03.000000000 +0200
+++ wireless-testing/net/wireless/core.c 2009-07-29 01:08:58.000000000 +0200
@@ -314,7 +314,8 @@ static void cfg80211_process_events(stru
ev->cr.req_ie, ev->cr.req_ie_len,
ev->cr.resp_ie, ev->cr.resp_ie_len,
ev->cr.status,
- ev->cr.status == WLAN_STATUS_SUCCESS);
+ ev->cr.status == WLAN_STATUS_SUCCESS,
+ NULL);
break;
case EVENT_ROAMED:
__cfg80211_roamed(wdev, ev->rm.bssid,
--- wireless-testing.orig/net/wireless/core.h 2009-07-29 01:08:03.000000000 +0200
+++ wireless-testing/net/wireless/core.h 2009-07-29 01:08:21.000000000 +0200
@@ -323,7 +323,8 @@ void cfg80211_mlme_down(struct cfg80211_
void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
const u8 *req_ie, size_t req_ie_len,
const u8 *resp_ie, size_t resp_ie_len,
- u16 status, bool wextev);
+ u16 status, bool wextev,
+ struct cfg80211_bss *bss);
/* SME */
int __cfg80211_connect(struct cfg80211_registered_device *rdev,
--- wireless-testing.orig/net/wireless/mlme.c 2009-07-29 01:08:03.000000000 +0200
+++ wireless-testing/net/wireless/mlme.c 2009-07-29 01:44:03.000000000 +0200
@@ -61,7 +61,7 @@ void cfg80211_send_rx_assoc(struct net_d
struct ieee80211_mgmt *mgmt = (struct ieee80211_mgmt *)buf;
u8 *ie = mgmt->u.assoc_resp.variable;
int i, ieoffs = offsetof(struct ieee80211_mgmt, u.assoc_resp.variable);
- bool done;
+ struct cfg80211_internal_bss *bss = NULL;
wdev_lock(wdev);
@@ -69,24 +69,27 @@ void cfg80211_send_rx_assoc(struct net_d
nl80211_send_rx_assoc(rdev, dev, buf, len, GFP_KERNEL);
- __cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, ie, len - ieoffs,
- status_code,
- status_code == WLAN_STATUS_SUCCESS);
-
if (status_code == WLAN_STATUS_SUCCESS) {
- for (i = 0; wdev->current_bss && i < MAX_AUTH_BSSES; i++) {
- if (wdev->auth_bsses[i] == wdev->current_bss) {
+ for (i = 0; i < MAX_AUTH_BSSES; i++) {
+ if (!wdev->auth_bsses[i])
+ continue;
+ if (memcmp(wdev->auth_bsses[i]->pub.bssid, mgmt->bssid,
+ ETH_ALEN) == 0) {
+ bss = wdev->auth_bsses[i];
cfg80211_unhold_bss(wdev->auth_bsses[i]);
- cfg80211_put_bss(&wdev->auth_bsses[i]->pub);
wdev->auth_bsses[i] = NULL;
- done = true;
break;
}
}
- WARN_ON(!done);
+ WARN_ON(!bss);
}
+ /* this consumes the 'bss' reference, if not NULL */
+ __cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, ie, len - ieoffs,
+ status_code,
+ status_code == WLAN_STATUS_SUCCESS,
+ bss ? &bss->pub : NULL);
wdev_unlock(wdev);
}
EXPORT_SYMBOL(cfg80211_send_rx_assoc);
@@ -144,7 +147,7 @@ static void __cfg80211_send_deauth(struc
} else if (wdev->sme_state == CFG80211_SME_CONNECTING) {
__cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
}
}
@@ -241,7 +244,7 @@ void cfg80211_send_auth_timeout(struct n
if (wdev->sme_state == CFG80211_SME_CONNECTING)
__cfg80211_connect_result(dev, addr, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
for (i = 0; addr && i < MAX_AUTH_BSSES; i++) {
if (wdev->authtry_bsses[i] &&
@@ -275,7 +278,7 @@ void cfg80211_send_assoc_timeout(struct
if (wdev->sme_state == CFG80211_SME_CONNECTING)
__cfg80211_connect_result(dev, addr, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
for (i = 0; addr && i < MAX_AUTH_BSSES; i++) {
if (wdev->auth_bsses[i] &&
--- wireless-testing.orig/net/wireless/sme.c 2009-07-29 01:07:07.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2009-07-29 01:10:28.000000000 +0200
@@ -182,7 +182,7 @@ void cfg80211_conn_work(struct work_stru
wdev->conn->params.bssid,
NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
wdev_unlock(wdev);
}
@@ -247,7 +247,7 @@ static void __cfg80211_sme_scan_done(str
wdev->conn->params.bssid,
NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- false);
+ false, NULL);
}
}
@@ -305,7 +305,7 @@ void cfg80211_sme_rx_auth(struct net_dev
schedule_work(&rdev->conn_work);
} else if (status_code != WLAN_STATUS_SUCCESS) {
__cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, NULL, 0,
- status_code, false);
+ status_code, false, NULL);
} else if (wdev->sme_state == CFG80211_SME_CONNECTING &&
wdev->conn->state == CFG80211_CONN_AUTHENTICATING) {
wdev->conn->state = CFG80211_CONN_ASSOCIATE_NEXT;
@@ -316,10 +316,10 @@ void cfg80211_sme_rx_auth(struct net_dev
void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
const u8 *req_ie, size_t req_ie_len,
const u8 *resp_ie, size_t resp_ie_len,
- u16 status, bool wextev)
+ u16 status, bool wextev,
+ struct cfg80211_bss *bss)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
- struct cfg80211_bss *bss;
#ifdef CONFIG_WIRELESS_EXT
union iwreq_data wrqu;
#endif
@@ -361,6 +361,12 @@ void __cfg80211_connect_result(struct ne
}
#endif
+ if (wdev->current_bss) {
+ cfg80211_unhold_bss(wdev->current_bss);
+ cfg80211_put_bss(&wdev->current_bss->pub);
+ wdev->current_bss = NULL;
+ }
+
if (status == WLAN_STATUS_SUCCESS &&
wdev->sme_state == CFG80211_SME_IDLE)
goto success;
@@ -368,12 +374,6 @@ void __cfg80211_connect_result(struct ne
if (wdev->sme_state != CFG80211_SME_CONNECTING)
return;
- if (wdev->current_bss) {
- cfg80211_unhold_bss(wdev->current_bss);
- cfg80211_put_bss(&wdev->current_bss->pub);
- wdev->current_bss = NULL;
- }
-
if (wdev->conn)
wdev->conn->state = CFG80211_CONN_IDLE;
@@ -386,10 +386,12 @@ void __cfg80211_connect_result(struct ne
return;
}
- bss = cfg80211_get_bss(wdev->wiphy, NULL, bssid,
- wdev->ssid, wdev->ssid_len,
- WLAN_CAPABILITY_ESS,
- WLAN_CAPABILITY_ESS);
+ success:
+ if (!bss)
+ bss = cfg80211_get_bss(wdev->wiphy, NULL, bssid,
+ wdev->ssid, wdev->ssid_len,
+ WLAN_CAPABILITY_ESS,
+ WLAN_CAPABILITY_ESS);
if (WARN_ON(!bss))
return;
@@ -397,7 +399,6 @@ void __cfg80211_connect_result(struct ne
cfg80211_hold_bss(bss_from_pub(bss));
wdev->current_bss = bss_from_pub(bss);
- success:
wdev->sme_state = CFG80211_SME_CONNECTED;
cfg80211_upload_connect_keys(wdev);
}
@@ -788,7 +789,7 @@ int __cfg80211_disconnect(struct cfg8021
else if (wdev->sme_state == CFG80211_SME_CONNECTING)
__cfg80211_connect_result(dev, NULL, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
- wextev);
+ wextev, NULL);
return 0;
}
^ permalink raw reply
* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Kalle Valo @ 2009-07-29 7:45 UTC (permalink / raw)
To: chris2553
Cc: Luis Correia, Johannes Berg, Pavel Roskin, linux-wireless,
Ivo van Doorn
In-Reply-To: <200907290803.46110.chris2553@googlemail.com>
Chris Clayton <chris2553@sky.com> writes:
> 4. Are there any plans to be able to switch power-saving on/off on a
> driver-by-driver basis. It seems to me, although I'm happy to be
> corrected, that it is either on or off for a given kernel, depending
> on CONFIG_MAC80211_DEFAULT_PS.
mac80211 drivers can control power save with IEEE80211_HW_SUPPORTS_PS
flag. Also it can runtime from user space with 'iwconfig wlan0 power
off'. nl80211 interface is on my todo list.
--
Kalle Valo
^ 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