Luis R. Rodriguez | 1 Oct 2009 01:12
Picon
Gravatar

Re: SME warning on 2.6.32-rc<bleh>

On Tue, Sep 29, 2009 at 12:24 PM, Luis R. Rodriguez <mcgrof@...> wrote:
> I believe the problem comes from the assumption from cfg80211 that
> previous deauthentications would have gone through before we run
> __cfg80211_disconnected() and are using wext or nl80211
> connec/disconnectt. Under certain conditions (clearly not known yet)
> this is not true and we'll end up asking mac80211 to deauthenticate us
> from a BSS we already deauthenticated to end end up with an -ENOLINK
> on our mac80211 cfg80211 deauth ops. It seems this race was expected
> all along on mac80211 ieee80211_mgd_deauth():
>
>        /*
>         * cfg80211 should catch this ... but it's racy since
>         * we can receive a deauth frame, process it, hand it
>         * to cfg80211 while that's in a locked section already
>         * trying to tell us that the user wants to disconnect.
>         */
>        if (!bssid) {
>                mutex_unlock(&ifmgd->mtx);
>                return -ENOLINK;
>        }
>
> So it seems we do need to address that race but I'm not yet sure how.
>
> Here is a warning from the latest wireless-testing. Unfortunately I
> cannot reproduce in a systematic way, I've tried even different boot
> configuration (mem=300M) and CPU pegged at 800 MHz thinking the race
> occurs when mac80211 takes its sweet time deathenticating but that
> wasn't the case.

OK so I just got this again today with a cardbus card. The curious
(Continue reading)

Luis R. Rodriguez | 1 Oct 2009 01:19
Picon
Gravatar

Re: SME warning on 2.6.32-rc<bleh>

On Wed, Sep 30, 2009 at 4:12 PM, Luis R. Rodriguez <mcgrof@...> wrote:
> On Tue, Sep 29, 2009 at 12:24 PM, Luis R. Rodriguez <mcgrof@...> wrote:
>> I believe the problem comes from the assumption from cfg80211 that
>> previous deauthentications would have gone through before we run
>> __cfg80211_disconnected() and are using wext or nl80211
>> connec/disconnectt. Under certain conditions (clearly not known yet)
>> this is not true and we'll end up asking mac80211 to deauthenticate us
>> from a BSS we already deauthenticated to end end up with an -ENOLINK
>> on our mac80211 cfg80211 deauth ops. It seems this race was expected
>> all along on mac80211 ieee80211_mgd_deauth():
>>
>>        /*
>>         * cfg80211 should catch this ... but it's racy since
>>         * we can receive a deauth frame, process it, hand it
>>         * to cfg80211 while that's in a locked section already
>>         * trying to tell us that the user wants to disconnect.
>>         */
>>        if (!bssid) {
>>                mutex_unlock(&ifmgd->mtx);
>>                return -ENOLINK;
>>        }
>>
>> So it seems we do need to address that race but I'm not yet sure how.
>>
>> Here is a warning from the latest wireless-testing. Unfortunately I
>> cannot reproduce in a systematic way, I've tried even different boot
>> configuration (mem=300M) and CPU pegged at 800 MHz thinking the race
>> occurs when mac80211 takes its sweet time deathenticating but that
>> wasn't the case.
>
(Continue reading)

David Miller | 1 Oct 2009 01:33
Favicon

Re: [PATCH] net: fix NOHZ: local_softirq_pending 08

From: Oliver Hartkopp <oliver@...>
Date: Wed, 30 Sep 2009 20:18:25 +0200

> Socket buffers that are generated and received inside softirqs or from process
> context must not use netif_rx() that's intended to be used from irq context only.
> 
> This patch introduces a new helper function netif_rx_ti(skb) that tests for
> in_interrupt() before invoking netif_rx() or netif_rx_ni().
> 
> It fixes the ratelimited kernel warning
> 
>         NOHZ: local_softirq_pending 08
> 
> in the mac80211 and can subsystems.
> 
> Signed-off-by: Oliver Hartkopp <oliver@...>

I bet all of these code paths can use netif_receive_skb() or
don't need this conditional blob at all.

Looking at some specific cases in this patch:

1) VCAN:  This RX routine is only invoked from the drivers
   ->ndo_start_xmit() handler, and therefore like the loopback
   driver we know that BH's are already disabled and therefore
   it can always use netif_rx() safely.

   Why did you convert this case?

   And if this needs to be converted, why doesn't loopback need
(Continue reading)

John W. Linville | 1 Oct 2009 03:19
Favicon

[PATCH 1/3] wireless: implement basic ethtool support for cfg80211 devices

Signed-off-by: John W. Linville <linville@...>
---
 net/wireless/Makefile  |    2 +-
 net/wireless/core.c    |    3 +++
 net/wireless/ethtool.c |   27 +++++++++++++++++++++++++++
 net/wireless/ethtool.h |   10 ++++++++++
 4 files changed, 41 insertions(+), 1 deletions(-)
 create mode 100644 net/wireless/ethtool.c
 create mode 100644 net/wireless/ethtool.h

diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index c814150..f07c8dc 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
 <at>  <at>  -10,7 +10,7  <at>  <at>  obj-$(CONFIG_WEXT_SPY) += wext-spy.o
 obj-$(CONFIG_WEXT_PRIV) += wext-priv.o

 cfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o
-cfg80211-y += mlme.o ibss.o sme.o chan.o
+cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o
 cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
 cfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o

diff --git a/net/wireless/core.c b/net/wireless/core.c
index c761532..faada5c 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
 <at>  <at>  -21,6 +21,7  <at>  <at> 
 #include "sysfs.h"
 #include "debugfs.h"
(Continue reading)

John W. Linville | 1 Oct 2009 03:19
Favicon

[PATCH 3/3] at76c50x-usb: set firmware and hardware version in wiphy

From: Kalle Valo <kalle.valo@...>

Set firmware and hardware version in wiphy so that user space can access
it.

(Modification from original in favor of cfg80211 ethtool support. -- JWL)

Cc: Kalle Valo <kalle.valo@...>
Signed-off-by: John W. Linville <linville@...>
---
 drivers/net/wireless/at76c50x-usb.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index 8e1a55d..533954d 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
 <at>  <at>  -2217,6 +2217,8  <at>  <at>  static struct ieee80211_supported_band at76_supported_band = {
 static int at76_init_new_device(struct at76_priv *priv,
 				struct usb_interface *interface)
 {
+	struct wiphy *wiphy;
+	size_t len;
 	int ret;

 	/* set up the endpoint information */
 <at>  <at>  -2254,6 +2256,7  <at>  <at>  static int at76_init_new_device(struct at76_priv *priv,
 	priv->device_unplugged = 0;

 	/* mac80211 initialisation */
(Continue reading)

Bing Zhao | 1 Oct 2009 05:04
Favicon

[PATCH v2] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688

From: Amitkumar Karwar <akarwar@...>

Add timer based auto deep sleep feature in libertas driver which can be
configured using iwconfig command. This is tested on SD8688, SD8686 cards
with firmware versions 10.38.1.p25, 9.70.4.p0 respectively on 32-bit and 64-bit
platforms. Tests have been done for USB/CS cards to make sure that the patch
won't break USB/CS code. We didn't test the if_spi driver.

Signed-off-by: Amitkumar Karwar <akarwar@...>
Signed-off-by: Bing Zhao <bzhao@...>
---
 drivers/net/wireless/libertas/README    |   26 ++++-
 drivers/net/wireless/libertas/cmd.c     |   72 ++++++++++++-
 drivers/net/wireless/libertas/cmdresp.c |   12 ++
 drivers/net/wireless/libertas/debugfs.c |   46 ++++++++
 drivers/net/wireless/libertas/decl.h    |    4 +
 drivers/net/wireless/libertas/dev.h     |   18 +++
 drivers/net/wireless/libertas/host.h    |    1 +
 drivers/net/wireless/libertas/if_cs.c   |    3 +
 drivers/net/wireless/libertas/if_sdio.c |   56 +++++++++
 drivers/net/wireless/libertas/if_sdio.h |    3 +-
 drivers/net/wireless/libertas/if_spi.c  |    3 +
 drivers/net/wireless/libertas/if_usb.c  |    3 +
 drivers/net/wireless/libertas/main.c    |  111 ++++++++++++++++---
 drivers/net/wireless/libertas/scan.c    |   11 ++
 drivers/net/wireless/libertas/wext.c    |  185 ++++++++++++++++++++++++++++++-
 15 files changed, 533 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/libertas/README b/drivers/net/wireless/libertas/README
index ab6a2d5..635002d 100644
(Continue reading)

Malte Gell | 1 Oct 2009 06:32
Picon
Picon

PATCH ar9170usb LEDs are confused

Hello,

I first noticed the LEDs are confused, when I ran my AVM Fritz USBN N under 
Windows, where the LEDs had the right order. I made a little patch that put 
the assoc and the tx LEDs in the right order.

That patch was built against compat-wireless-2009-09-29.

Regards
Malte
Attachment (ar9170-led.patch): text/x-patch, 643 bytes
Holger Schurig | 1 Oct 2009 09:42
Picon
Favicon

Re: [PATCH v2] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688

> Tests have been done for USB/CS cards to make sure that the patch
> won't break USB/CS code.

Side question: which firmware are you using on CS cards?

--

-- 
http://www.holgerschurig.de
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kalle Valo | 1 Oct 2009 09:49
Picon
Picon
Favicon

Re: unused header file drivers/net/wireless/wl12xx/wl1251_netlink.h?

"Robert P. J. Day" <rpjday@...> writes:

>   as best i can tell, that header file is entirely unreferenced by
> anything in the tree.  just an observation.

Yes, it's unused. I added it accidentally a long time ago when I
rebased a big pile of patches. I'll send a patch to remove it.

Thanks for reporting this.

--

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Holger Schurig | 1 Oct 2009 09:57
Picon
Favicon

Re: [PATCH]: nl80211: report age of scan results

> If anyone gets interested enough in trying to figure out whether
> scan results are from the time after the last scan (more exactly than 
> just guessing based on age), he/she can add that later and probably
> using something like a sequence number for scan requests, etc.

Hmm, what would a scan-sequence help in the case when mac80211 updates
a BSS because of a received beacon?

E.g.:

scan trigger, seq 5:
  find AP 'XXX', signal -50
  find AP 'YYY', signal -60
scan trigger, seq 6:
  find AP 'ZZZ', signal -55
normal operation:
  beacon for 'YYY' comes in, signal -45
scan-dump:
  get 'XXX', signal -50, seq 5
  get 'ZZZ', signal -55, seq 6
  get 'YYY', signal -45, but with which seq?

--

-- 
http://www.holgerschurig.de
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)


Gmane