* Re: [PATCH v2 2/2] cfg80211/nl80211: Add packet coalesce support
From: Johannes Berg @ 2013-06-11 11:32 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Bing Zhao, linux-wireless@vger.kernel.org, Luis R. Rodriguez,
Jouni Malinen, Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho
In-Reply-To: <5FF020A1CFFEEC49BD1E09530C4FF5950F313C2CB5@SC-VEXCH1.marvell.com>
On Mon, 2013-06-03 at 09:47 -0700, Amitkumar Karwar wrote:
> "iw coalesce add" was used, because command for adding multiple rules
> at the same time will be a bit lengthy(user will need to enter
> multiple lists of packet patterns) and syntax check in iw will also
> need some efforts.
I think that this is so much unlike all other nl80211 settings where
they're either refused or replace previous ones entirely that I would
rather not have it. Take connecting for instance, wext allowed you to
set all parameters one by one, etc. This is a bit similar. Also, this
disallows doing checks on the entire configuration easily.
Personally, I see iw as a bit of a test tool so I'm not too concerned
about its sometimes odd command line, but I know giving it lots of
things can be awkward. For TCP wakeup, I've made it parse a small file,
maybe that's an option here as well?
> > Otherwise you're going to have very awkward races and need
> > to always clear etc. The code would also be easier, though obviously
> > you'd need to be able to specify multiple rules at the same time.
>
> For "iw coalesce set" also user needs to always clear the settings
> using "iw coalesce disable". Also similar to "coalesce set", for
> "coalesce add" we clear the settings and free allocations while
> unloading the driver.
>
> Please let us know if you prefer "coalesce set" over "coalesce add".
I would much prefer just having set/clear over piecewise configuration.
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: update mesh beacon on workqueue
From: Johannes Berg @ 2013-06-11 11:30 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, open80211s, Bob Copeland
In-Reply-To: <1370895442-21784-2-git-send-email-thomas@cozybit.com>
On Mon, 2013-06-10 at 13:17 -0700, Thomas Pedersen wrote:
> + struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
> + u32 bit;
> +
> + /* if we race with running work, worst case this work becomes a noop */
> + for_each_set_bit(bit, (unsigned long *)&changed,
> + sizeof(changed) * BITS_PER_BYTE)
This isn't valid, it happens to work on little endian platforms but will
fail on big endian 64-bit ones, because you have this in memory (0 is
the lowest order nibble):
76 54 32 10 -- -- -- --
and now you point an unsigned long pointer to it, so you interpret the
"--" as the lowest bits.
More generally, I'd argue that mesh is being a bit odd here, flushing
stations turing mesh stop can and will actually cause a BSS info update
after the mesh interface has already been stopped (beaconing has been
disabled in the driver.) This seems rather odd. Maybe it would be better
to move the beacon update out of mesh_sta_cleanup() and into
ieee80211_mesh_housekeeping() in some way? Although it'd also have to be
done in the station handling in cfg.c but that shouldn't be a problem?
Note also that the way you did this is rather odd, ieee80211_stop_mesh()
could cause to schedule out to the workqueue for the update, but then
the update won't happen. It's a bit racy though, because you could stop
and restart the mesh and then the workqueue runs or something? Overall
this approach seems a bit brittle?
johannes
^ permalink raw reply
* Re: [PATCH v2 1/2] mac80211: fix mesh deadlock
From: Johannes Berg @ 2013-06-11 11:15 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, open80211s, Bob Copeland
In-Reply-To: <1370895442-21784-1-git-send-email-thomas@cozybit.com>
On Mon, 2013-06-10 at 13:17 -0700, Thomas Pedersen wrote:
> The patch "cfg80211/mac80211: use cfg80211 wdev mutex in
> mac80211" introduced several deadlocks by converting the
> ifmsh->mtx to wdev->mtx. Solve these by:
>
> 1. drop the cancel_work_sync() in ieee80211_stop_mesh().
> Instead make the mesh work conditional on whether the mesh
> is running or not.
> 2. lock the mesh work with sdata_lock() to protect beacon
> updates and prevent races with wdev->mesh_id_len or
> cfg80211.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 0/2] mac80211 fixes
From: Johannes Berg @ 2013-06-11 11:12 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <1370940280-7876-1-git-send-email-siwu@hrz.tu-chemnitz.de>
On Tue, 2013-06-11 at 10:44 +0200, Simon Wunderlich wrote:
> Here are two small mac80211 fixes:
> * I've been seeing a warning when doing DFS tests, which was triggered
> by aborting the CAC when killing hostapd
> * the rate control fix was sent as part of the v3 series of
> "Add support for 5 and 10 MHz channels", but since it's an trivial
> yet important fix I'm adding it to this series too.
Applied, thanks.
johannes
^ permalink raw reply
* [PATCH 2/2] mac80211: Fix rate control mask matching call
From: Simon Wunderlich @ 2013-06-11 8:44 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Simon Wunderlich, Felix Fietkau,
Mathias Kretschmer
In-Reply-To: <1370940280-7876-1-git-send-email-siwu@hrz.tu-chemnitz.de>
The order of parameters was mixed up, introduced in commit
"mac80211: improve the rate control API"
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/rate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index d3f414f..a02bef3 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -615,7 +615,7 @@ static void rate_control_apply_mask(struct ieee80211_sub_if_data *sdata,
if (rates[i].idx < 0)
break;
- rate_idx_match_mask(&rates[i], sband, mask, chan_width,
+ rate_idx_match_mask(&rates[i], sband, chan_width, mask,
mcs_mask);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] mac80211: abort CAC in stop_ap()
From: Simon Wunderlich @ 2013-06-11 8:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <1370940280-7876-1-git-send-email-siwu@hrz.tu-chemnitz.de>
When a CAC is running and stop_ap is called (e.g. when hostapd is killed
while performing CAC), the CAC must be aborted immediately.
Otherwise ieee80211_stop_ap() will try to stop it when it's too late -
wdev->channel is already NULL and the abort event can not be generated.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
net/mac80211/cfg.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3062210..7f89fc0 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1071,6 +1071,12 @@ static int ieee80211_stop_ap(struct wiphy *wiphy, struct net_device *dev)
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
+ if (sdata->wdev.cac_started) {
+ cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
+ WARN_ON(local->suspended);
+ cfg80211_cac_event(sdata->dev, NL80211_RADAR_CAC_ABORTED,
+ GFP_KERNEL);
+ }
drv_stop_ap(sdata->local, sdata);
/* free all potentially still buffered bcast frames */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] mac80211 fixes
From: Simon Wunderlich @ 2013-06-11 8:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
Here are two small mac80211 fixes:
* I've been seeing a warning when doing DFS tests, which was triggered
by aborting the CAC when killing hostapd
* the rate control fix was sent as part of the v3 series of
"Add support for 5 and 10 MHz channels", but since it's an trivial
yet important fix I'm adding it to this series too.
Cheers,
Simon
Simon Wunderlich (2):
mac80211: abort CAC in stop_ap()
mac80211: Fix rate control mask matching call
net/mac80211/cfg.c | 6 ++++++
net/mac80211/rate.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
--
1.7.10.4
^ permalink raw reply
* Re: Intel Centrino Wireless-N 2200 Tech Support
From: Emmanuel Grumbach @ 2013-06-11 5:41 UTC (permalink / raw)
To: Edward Seyler; +Cc: linux-wireless
In-Reply-To: <20130611042801.GA217@FermiDesk>
> # dmesg | grep iwl
>
> [ 9.868028] iwlwifi 0000:03:00.0: irq 44 for MSI/MSI-X
> [ 9.942668] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1
> [ 10.015848] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
> [ 10.015861] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
> [ 10.015866] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
> [ 10.015872] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
> [ 10.015877] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P enabled
> [ 10.015884] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 2200 BGN, REV=0x104
> [ 10.015912] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
> [ 10.056013] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
> [ 280.878663] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
> [ 280.886234] iwlwifi 0000:03:00.0: Radio type=0x2-0x0-0x0
> [ 285.886692] iwlwifi 0000:03:00.0: Failed to load firmware chunk!
> [ 285.886888] iwlwifi 0000:03:00.0: Could not load the [0] uCode section
> [ 285.887299] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110
> [ 285.887516] iwlwifi 0000:03:00.0: Unable to initialize device.
>
This is really weird...
Can you compile with CONFIG_IWLWIFI_DEBUG?
I will then need a few debug prints.
I recently changed this flow to speed up the fw loading process on
platform that can afford a bit amount of DMA, but I just tested it
(again) and it works even if there is not big DMA chunk available.
^ permalink raw reply
* RE: [Ilw] IMPO: URGENT: LINUX IWLEGACY WIRELESS DRIVERS & LINUX VERSION QUESTION
From: Grumbach, Emmanuel @ 2013-06-11 5:36 UTC (permalink / raw)
To: Deniz Kazanci, linux-wireless@vger.kernel.org
Cc: ilw@linux.intel.com, sgruszka@redhat.com
In-Reply-To: <CADvhgjjp2dSCB1yNkOp-XaTkBNQXo3uqaBKU10HVgVwrXPs0jg@mail.gmail.com>
DQpQbGVhc2UgcmVzZW5kIHdpdGhvdXQgc3ViamVjdCBpbiBjYXBpdGFscywgdGhlbiB5b3UnbGwg
aGF2ZSBhIGNoYW5jZSB0byBnbyB0cm91Z2ggdGhlIHNwYW0gZmlsdGVyIG9mIHRoZSBtYWlsaW5n
IGxpc3QuDQoNCg0KSGVsbG8sDQoNCldlIGFyZSBuZXcgdG8gbGludXggZW52aXJvbm1lbnQgYWZ0
ZXIgV2luZG93czsgYW5kIGhhdmUgYSBMZW5vdm8gVjIwMCB3aGljaA0KaGFzIGFuIEludGVswq4g
UFJPL1dpcmVsZXNzIDM5NDVBQkcgY2FyZC4gV2Ugd291bGQgbGlrZSB0byBkb3dubG9hZCBGZWRv
cmENCjE4IG9yIE9wZW5TdXNlIDEyLjMuDQoNCkkgbmVlZCB5b3VyIHVyZ2VudCBoZWxwIHdpdGgg
dGhlIGZvbGxvd2luZyBpdGVtcyBwbGVhc2U6DQoxLiBIb3cgZG8gd2UgY2hhbmdlIHRoZSB0ZXJt
aW5hbCBpbnRvIHJvb3Qgd2hlbiB3ZSBhcmUgbG9nZ2VkIGluIGZyb20gdGhlDQphZG1pbmlzdHJh
dGl2ZSBwcml2aWxpZ2VkIHVzZXIgYWNjb3VudD8NCjIuIEluIHRoZSBodHRwOi8vd2lyZWxlc3Mu
a2VybmVsLm9yZy9lbi91c2Vycy9Ecml2ZXJzL2l3bGVnYWN5IHNpdGUsIDUNCmRpZmZlcmVudCBs
aW5rcyB0byBmaXJtd2FyZSBpcyBnaXZlbiBhcyBiZWxvdzoNCktlcm5lbHMgwqAvIEZpcm13YXJl
DQoyLjYuMjQrIMKgLyBpd2x3aWZpLTM5NDUtdWNvZGUtMi4xNC4xLjUudGd6DQoyLjYuMjQrIMKg
LyBpd2x3aWZpLTM5NDUtdWNvZGUtMTUuMjguMS42LnRneg0KMi42LjI0KyDCoC8gaXdsd2lmaS0z
OTQ1LXVjb2RlLTE1LjI4LjEuOC50Z3oNCjIuNi4yOSsgwqAvIGl3bHdpZmktMzk0NS11Y29kZS0x
NS4yOC4yLjgudGd6DQoyLjYuMjkrIMKgLyBpd2x3aWZpLTM5NDUtdWNvZGUtMTUuMzIuMi45LnRn
eg0KV2hpY2ggb2YgdGhlIGFib3ZlIHByb2dyYW1zIGRvIHdlIGhhdmUgdG8gcnVuIG9uIHRoZSBs
YWJ0b3AgcGxlYXNlPyBXaGF0DQp3b3VsZCBiZSB0aGUgc3RlcHMgdG8gaW5zdGFsbCB0aGUgZHJp
dmVyIHBsZWFzZSBpbiBwbGFpbiBFbmdsaXNoLSB3ZSBmb3VuZA0KdGhlIGxhbmd1YWdlIGdpdmVu
IGluIHRoZSB3ZWJzaXRlIHF1aXRlIGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kPyBUaGFuayB5b3Uu
Lg0KMy4gV2UgYXJlIHVzaW5nIGhlIGxhYnRvYiBmb3IgYnVzaW5lc3MgcHVycG9zZXMgaG93ZXZl
ciB1c2Ugb2YgaW50ZXJuZXQgYW5kDQpvdXRsb29rIGFsb25nIHdpdGggdGhlIG9mZmljZSBwcm9k
dWN0cyBzb21lIChhbHNvIFByb2plY3QgTWFuYWdlbWVudCBUb29scw0KbGlrZSBNUyBQcm9qZWN0
IHNvbWV0aW1lcyksIHNvbWUgbXVzaWMgbGlzdGVuaW5nIGFuZCBzb21lIHZpZGVvIHdhdGNoaW5n
DQpzdWZmaWNlIG91ciBuZWVkcyBvZiB0aGUgY29tcHV0ZXIuIEFtb25nIE9wZW5TdXNlIGFuZCBG
ZWRvcmEgKG9yIG90aGVycyksDQp3aGljaCBvbmUgb2YgdGhlIHByb2R1Y3RzIHdvdWxkIHlvdSBy
ZWNvbW1lbmQgYXMgcGVyIGJlaW5nIHVzZXIgZnJpZW5kbHksDQpyZWxpYWJsZSwgZmFzdCBwbGVh
c2Ugd2l0aCBhIExlbm92byBWMjAwIHBsZWFzZT8NCg0KV2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0
byBoZWFyaW5nIGJhY2sgZnJvbSB5b3Ugc29vbi4gVGhhbmsgeW91IGtpbmRseSBmb3INCnlvdXIg
aW5mb3JtYXRpb24gYW5kIGF0dGVudGlvbi4NCg0KS2luZCBSZWdhcmRzLA0KRGVuaXogS0FaQU5D
SQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KQSBtZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3Vw
IG9mIGNvbXBhbmllcwoKVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFp
biBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg
cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMgc3Ry
aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCwg
cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuCg==
^ permalink raw reply
* Intel Centrino Wireless-N 2200 Tech Support
From: Edward Seyler @ 2013-06-11 4:28 UTC (permalink / raw)
To: linux-wireless
I am having difficulty using my Intel Centrino Wireless-N 2200 PCI-E wireless card. The card is visible but cannot be set "up," either from "ip link" or wpa_supplicant. I am using Arch Linux but have also observed this problem in Ubuntu 12.04 LTS. I have downloaded the firmware from http://wireless.kernel.org/en/users/Drivers/iwlwifi and followed the instructions there on how to copy it into /lib/firmware. Installing Arch Linux's "compat-drivers-patched" package had no effect. Removing all other PCI/PCI-E devices had no effect. My wired ethernet connection is fully functional. Below is the output of several commands that may be relevant, all run as root. Any assistance would be greatly appreciated. Please let me know if I can provide any additional information.
Thank you,
Edward Seyler
# wpa_supplicant -i wlp3s0 -c /etc/wpa_supplicant/my_wpa.conf -D nl80211 -dd
wpa_supplicant v2.0
Successfully initialized wpa_supplicant
Initializing interface 'wlp3s0' conf '/etc/wpa_supplicant/my_wpa.conf' driver 'nl80211' ctrl_interface 'N/A' bridge 'N/A'
Configuration file '/etc/wpa_supplicant/my_wpa.conf' -> '/etc/wpa_supplicant/my_wpa.conf'
Reading configuration file '/etc/wpa_supplicant/my_wpa.conf'
Line: 1 - start of a new network block
BSSID - hexdump(len=6): e0 46 9a 79 75 46
PSK - hexdump(len=32): [REMOVED]
Priority group 0
id=0 ssid=''
nl80211: interface wlp3s0 in phy phy0
rfkill: initial event: idx=0 type=1 op=0 soft=0 hard=0
nl80211: Set mode ifindex 3 iftype 2 (STATION)
nl80211: Subscribe to mgmt frames with non-AP handle 0x1b26740
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 04 0a
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 04 0b
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 04 0c
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 04 0d
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=6): 04 09 50 6f 9a 09
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=5): 7f 50 6f 9a 09
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=1): 06
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 0a 07
nl80211: Register frame type=0xd0 nl_handle=0x1b26740
nl80211: Register frame match - hexdump(len=2): 0a 11
Could not set interface wlp3s0 flags (UP): Connection timed out
nl80211: Could not set interface 'wlp3s0' UP
netlink: Operstate: linkmode=0, operstate=6
nl80211: Set mode ifindex 3 iftype 2 (STATION)
nl80211: Unsubscribe mgmt frames handle 0x1b26740 (mode change)
wlp3s0: Failed to initialize driver interface
Failed to add interface wlp3s0
wlp3s0: Cancelling scan request
wlp3s0: Cancelling authentication timeout
(running this command, or ip link set wlp3s0 up, a second time causes the system to lock up)
# dmesg | grep iwl
[ 9.868028] iwlwifi 0000:03:00.0: irq 44 for MSI/MSI-X
[ 9.942668] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1
[ 10.015848] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
[ 10.015861] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[ 10.015866] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[ 10.015872] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[ 10.015877] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P enabled
[ 10.015884] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 2200 BGN, REV=0x104
[ 10.015912] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
[ 10.056013] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 280.878663] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
[ 280.886234] iwlwifi 0000:03:00.0: Radio type=0x2-0x0-0x0
[ 285.886692] iwlwifi 0000:03:00.0: Failed to load firmware chunk!
[ 285.886888] iwlwifi 0000:03:00.0: Could not load the [0] uCode section
[ 285.887299] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110
[ 285.887516] iwlwifi 0000:03:00.0: Unable to initialize device.
# uname -a
Linux FermiDesk 3.9.5-1-ARCH #1 SMP PREEMPT Sat Jun 8 09:22:45 CEST 2013 x86_64 GNU/Linux
# lspci -vvv | tail -n 35
03:00.0 Network controller: Intel Corporation Centrino Wireless-N 2200 (rev c4)
Subsystem: Intel Corporation Centrino Wireless-N 2200 BGN
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 44
Region 0: Memory at efffe000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41d1
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <32us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 9c-4e-36-ff-ff-19-1a-8c
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether bc:5f:f4:82:28:91 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 9c:4e:36:19:1a:8c brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 100
link/none
# iwconfig
tun0 no wireless extensions.
enp0s7 no wireless extensions.
lo no wireless extensions.
wlp3s0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
# rfkill list all
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
# lsmod | grep iw
iwldvm 173046 0
mac80211 495646 1 iwldvm
iwlwifi 143110 1 iwldvm
cfg80211 454778 3 iwlwifi,mac80211,iwldvm
compat 1357 4 cfg80211,iwlwifi,mac80211,iwldvm
^ permalink raw reply
* Re: [RFT/RFC 0/4] iwlegacy: workaround for firmware frame tx rejection
From: Jake Edge @ 2013-06-11 3:41 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20130610143848.7afd5acc@chukar.edge2.net>
On Mon, 10 Jun 2013 14:38:48 -0600 Jake Edge wrote:
> > Please apply it together with this mac80211 patch:
> > http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> > which I already posted and is queued to upstream. Not having
> > it may cause troubles and influence negatively this set test.
>
> I tried it on both 3.9 (without 4/4 since it doesn't have that
> workaround in it) and on 3.10-rc4 and in both cases, i get the same
> behavior: it tries to connect many times and fails, then eventually
> connects (after like 20 tries from KDE network manager) ...
actually, i spoke too soon, the 3.10-rc4 has not been able to connect
at all, after many hours of trying. I manually went in and selected
the other 2.4GHz SSID (rather than the 5GHz it had been trying) and it
connected right away, fwiw ...
jake
--
Jake Edge - LWN - jake@lwn.net - http://lwn.net
^ permalink raw reply
* [PATCH RESEND] mwifiex: enable/disable tx_amsdu support via module parameter
From: Bing Zhao @ 2013-06-10 22:39 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Avinash Patil <patila@marvell.com>
This patch disables tx_amsdu support in mwifiex by default.
tx_amdsu support can be enabled via module parameter at load time.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/wmm.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c
index 4be3d33..944e884 100644
--- a/drivers/net/wireless/mwifiex/wmm.c
+++ b/drivers/net/wireless/mwifiex/wmm.c
@@ -37,6 +37,9 @@
/* Offset for TOS field in the IP header */
#define IPTOS_OFFSET 5
+static bool enable_tx_amsdu;
+module_param(enable_tx_amsdu, bool, 0644);
+
/* WMM information IE */
static const u8 wmm_info_ie[] = { WLAN_EID_VENDOR_SPECIFIC, 0x07,
0x00, 0x50, 0xf2, 0x02,
@@ -1233,7 +1236,7 @@ mwifiex_dequeue_tx_packet(struct mwifiex_adapter *adapter)
mwifiex_send_delba(priv, tid_del, ra, 1);
}
}
- if (mwifiex_is_amsdu_allowed(priv, tid) &&
+ if (enable_tx_amsdu && mwifiex_is_amsdu_allowed(priv, tid) &&
mwifiex_is_11n_aggragation_possible(priv, ptr,
adapter->tx_buf_size))
mwifiex_11n_aggregate_pkt(priv, ptr, INTF_HEADER_LEN,
--
1.8.2.3
^ permalink raw reply related
* [PATCH RESEND] mwifiex: fix regression issue for usb interface
From: Bing Zhao @ 2013-06-10 22:39 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Amitkumar Karwar <akarwar@marvell.com>
PATCH "mwifiex: scan delay timer cleanup in unload path" adds code
to cancel scan delay timer in unload path. It causes a regression
for USB interface.
USB8797 card gets enumerated twice. First enumeration is for
firmware download and second enumeration expects firmware
initialization.
It was observed that we are trying del_timer_sync() without setting
up the timer when remove handler is called after first enumeration.
This patch moves setup_timer() call to appropriate place so that
timer is setup for both the enumerations.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/init.c | 81 ------------------------------------
drivers/net/wireless/mwifiex/main.c | 82 +++++++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+), 81 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c
index c7f11c0..2fe31dc 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -52,84 +52,6 @@ static int mwifiex_add_bss_prio_tbl(struct mwifiex_private *priv)
return 0;
}
-static void scan_delay_timer_fn(unsigned long data)
-{
- struct mwifiex_private *priv = (struct mwifiex_private *)data;
- struct mwifiex_adapter *adapter = priv->adapter;
- struct cmd_ctrl_node *cmd_node, *tmp_node;
- unsigned long flags;
-
- if (adapter->surprise_removed)
- return;
-
- if (adapter->scan_delay_cnt == MWIFIEX_MAX_SCAN_DELAY_CNT) {
- /*
- * Abort scan operation by cancelling all pending scan
- * commands
- */
- spin_lock_irqsave(&adapter->scan_pending_q_lock, flags);
- list_for_each_entry_safe(cmd_node, tmp_node,
- &adapter->scan_pending_q, list) {
- list_del(&cmd_node->list);
- mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
- }
- spin_unlock_irqrestore(&adapter->scan_pending_q_lock, flags);
-
- spin_lock_irqsave(&adapter->mwifiex_cmd_lock, flags);
- adapter->scan_processing = false;
- adapter->scan_delay_cnt = 0;
- adapter->empty_tx_q_cnt = 0;
- spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, flags);
-
- if (priv->scan_request) {
- dev_dbg(adapter->dev, "info: aborting scan\n");
- cfg80211_scan_done(priv->scan_request, 1);
- priv->scan_request = NULL;
- } else {
- priv->scan_aborting = false;
- dev_dbg(adapter->dev, "info: scan already aborted\n");
- }
- goto done;
- }
-
- if (!atomic_read(&priv->adapter->is_tx_received)) {
- adapter->empty_tx_q_cnt++;
- if (adapter->empty_tx_q_cnt == MWIFIEX_MAX_EMPTY_TX_Q_CNT) {
- /*
- * No Tx traffic for 200msec. Get scan command from
- * scan pending queue and put to cmd pending queue to
- * resume scan operation
- */
- adapter->scan_delay_cnt = 0;
- adapter->empty_tx_q_cnt = 0;
- spin_lock_irqsave(&adapter->scan_pending_q_lock, flags);
- cmd_node = list_first_entry(&adapter->scan_pending_q,
- struct cmd_ctrl_node, list);
- list_del(&cmd_node->list);
- spin_unlock_irqrestore(&adapter->scan_pending_q_lock,
- flags);
-
- mwifiex_insert_cmd_to_pending_q(adapter, cmd_node,
- true);
- queue_work(adapter->workqueue, &adapter->main_work);
- goto done;
- }
- } else {
- adapter->empty_tx_q_cnt = 0;
- }
-
- /* Delay scan operation further by 20msec */
- mod_timer(&priv->scan_delay_timer, jiffies +
- msecs_to_jiffies(MWIFIEX_SCAN_DELAY_MSEC));
- adapter->scan_delay_cnt++;
-
-done:
- if (atomic_read(&priv->adapter->is_tx_received))
- atomic_set(&priv->adapter->is_tx_received, false);
-
- return;
-}
-
/*
* This function initializes the private structure and sets default
* values to the members.
@@ -211,9 +133,6 @@ int mwifiex_init_priv(struct mwifiex_private *priv)
priv->scan_block = false;
- setup_timer(&priv->scan_delay_timer, scan_delay_timer_fn,
- (unsigned long)priv);
-
return mwifiex_add_bss_prio_tbl(priv);
}
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index 5bc7ef8..4858719 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -28,6 +28,84 @@ const char driver_version[] = "mwifiex " VERSION " (%s) ";
static char *cal_data_cfg;
module_param(cal_data_cfg, charp, 0);
+static void scan_delay_timer_fn(unsigned long data)
+{
+ struct mwifiex_private *priv = (struct mwifiex_private *)data;
+ struct mwifiex_adapter *adapter = priv->adapter;
+ struct cmd_ctrl_node *cmd_node, *tmp_node;
+ unsigned long flags;
+
+ if (adapter->surprise_removed)
+ return;
+
+ if (adapter->scan_delay_cnt == MWIFIEX_MAX_SCAN_DELAY_CNT) {
+ /*
+ * Abort scan operation by cancelling all pending scan
+ * commands
+ */
+ spin_lock_irqsave(&adapter->scan_pending_q_lock, flags);
+ list_for_each_entry_safe(cmd_node, tmp_node,
+ &adapter->scan_pending_q, list) {
+ list_del(&cmd_node->list);
+ mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
+ }
+ spin_unlock_irqrestore(&adapter->scan_pending_q_lock, flags);
+
+ spin_lock_irqsave(&adapter->mwifiex_cmd_lock, flags);
+ adapter->scan_processing = false;
+ adapter->scan_delay_cnt = 0;
+ adapter->empty_tx_q_cnt = 0;
+ spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, flags);
+
+ if (priv->scan_request) {
+ dev_dbg(adapter->dev, "info: aborting scan\n");
+ cfg80211_scan_done(priv->scan_request, 1);
+ priv->scan_request = NULL;
+ } else {
+ priv->scan_aborting = false;
+ dev_dbg(adapter->dev, "info: scan already aborted\n");
+ }
+ goto done;
+ }
+
+ if (!atomic_read(&priv->adapter->is_tx_received)) {
+ adapter->empty_tx_q_cnt++;
+ if (adapter->empty_tx_q_cnt == MWIFIEX_MAX_EMPTY_TX_Q_CNT) {
+ /*
+ * No Tx traffic for 200msec. Get scan command from
+ * scan pending queue and put to cmd pending queue to
+ * resume scan operation
+ */
+ adapter->scan_delay_cnt = 0;
+ adapter->empty_tx_q_cnt = 0;
+ spin_lock_irqsave(&adapter->scan_pending_q_lock, flags);
+ cmd_node = list_first_entry(&adapter->scan_pending_q,
+ struct cmd_ctrl_node, list);
+ list_del(&cmd_node->list);
+ spin_unlock_irqrestore(&adapter->scan_pending_q_lock,
+ flags);
+
+ mwifiex_insert_cmd_to_pending_q(adapter, cmd_node,
+ true);
+ queue_work(adapter->workqueue, &adapter->main_work);
+ goto done;
+ }
+ } else {
+ adapter->empty_tx_q_cnt = 0;
+ }
+
+ /* Delay scan operation further by 20msec */
+ mod_timer(&priv->scan_delay_timer, jiffies +
+ msecs_to_jiffies(MWIFIEX_SCAN_DELAY_MSEC));
+ adapter->scan_delay_cnt++;
+
+done:
+ if (atomic_read(&priv->adapter->is_tx_received))
+ atomic_set(&priv->adapter->is_tx_received, false);
+
+ return;
+}
+
/*
* This function registers the device and performs all the necessary
* initializations.
@@ -75,6 +153,10 @@ static int mwifiex_register(void *card, struct mwifiex_if_ops *if_ops,
adapter->priv[i]->adapter = adapter;
adapter->priv_num++;
+
+ setup_timer(&adapter->priv[i]->scan_delay_timer,
+ scan_delay_timer_fn,
+ (unsigned long)adapter->priv[i]);
}
mwifiex_init_lock_list(adapter);
--
1.8.2.3
^ permalink raw reply related
* [PATCH] mwifiex: Add module parameter for regdomain
From: Bing Zhao @ 2013-06-10 22:40 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao,
Paul Stewart
From: Avinash Patil <patila@marvell.com>
Allow a regulatory domain country code to be specified at boot
using a module argument. This overrides the firmware regulatory
mode.
This patch also enables uAP to operate in 11a mode with hostapd.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/cfg80211.c | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index 00a8281..0d27952 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -20,6 +20,9 @@
#include "cfg80211.h"
#include "main.h"
+static char *reg_alpha2;
+module_param(reg_alpha2, charp, 0);
+
static const struct ieee80211_iface_limit mwifiex_ap_sta_limits[] = {
{
.max = 2, .types = BIT(NL80211_IFTYPE_STATION),
@@ -2475,6 +2478,17 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
#endif
};
+static bool mwifiex_is_valid_alpha2(const char *alpha2)
+{
+ if (!alpha2 || strlen(alpha2) != 2)
+ return false;
+
+ if (isalpha(alpha2[0]) && isalpha(alpha2[1]))
+ return true;
+
+ return false;
+}
+
/*
* This function registers the device with CFG802.11 subsystem.
*
@@ -2527,6 +2541,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
WIPHY_FLAG_AP_PROBE_RESP_OFFLOAD |
WIPHY_FLAG_AP_UAPSD |
WIPHY_FLAG_CUSTOM_REGULATORY |
+ WIPHY_FLAG_STRICT_REGULATORY |
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
wiphy_apply_custom_regulatory(wiphy, &mwifiex_world_regdom_custom);
@@ -2568,10 +2583,16 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
wiphy_free(wiphy);
return ret;
}
- country_code = mwifiex_11d_code_2_region(priv->adapter->region_code);
- if (country_code)
- dev_info(adapter->dev,
- "ignoring F/W country code %2.2s\n", country_code);
+
+ if (reg_alpha2 && mwifiex_is_valid_alpha2(reg_alpha2)) {
+ wiphy_info(wiphy, "driver hint alpha2: %2.2s\n", reg_alpha2);
+ regulatory_hint(wiphy, reg_alpha2);
+ } else {
+ country_code = mwifiex_11d_code_2_region(adapter->region_code);
+ if (country_code)
+ wiphy_info(wiphy, "ignoring F/W country code %2.2s\n",
+ country_code);
+ }
adapter->wiphy = wiphy;
return ret;
--
1.8.2.3
^ permalink raw reply related
* Re: [RFT/RFC 0/4] iwlegacy: workaround for firmware frame tx rejection
From: Jake Edge @ 2013-06-10 20:38 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1369311660-15378-1-git-send-email-sgruszka@redhat.com>
On Thu, 23 May 2013 14:20:56 +0200 Stanislaw Gruszka wrote:
> Jake, please test this set and check if it not cause association
> problems you reported earlier this month.
sorry it took me so long to get back to this, but i just tested and it
doesn't fix the problem here ...
> Please apply it together with this mac80211 patch:
> http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> which I already posted and is queued to upstream. Not having
> it may cause troubles and influence negatively this set test.
I tried it on both 3.9 (without 4/4 since it doesn't have that
workaround in it) and on 3.10-rc4 and in both cases, i get the same
behavior: it tries to connect many times and fails, then eventually
connects (after like 20 tries from KDE network manager) ...
jake
--
Jake Edge - LWN - jake@lwn.net - http://lwn.net
^ permalink raw reply
* [PATCH v2 2/2] mac80211: update mesh beacon on workqueue
From: Thomas Pedersen @ 2013-06-10 20:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, open80211s, Bob Copeland, Thomas Pedersen
In-Reply-To: <1370895442-21784-1-git-send-email-thomas@cozybit.com>
Fixes yet another deadlock on calling sta_info_flush()
with the sdata_lock() held. Should make it easier to
reason about locking in the future, since the sdata_lock()
is now held on all mesh work.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
v2:
read all changed bits & drop macro (Johannes)
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mesh.c | 44 ++++++++++++++++++++++++++++++++------------
net/mac80211/mesh.h | 2 ++
3 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 7a6f1a0..f79156d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -543,6 +543,7 @@ struct ieee80211_if_mesh {
struct timer_list mesh_path_root_timer;
unsigned long wrkq_flags;
+ unsigned long mbss_changed;
u8 mesh_id[IEEE80211_MAX_MESH_ID_LEN];
size_t mesh_id_len;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index d5faf91..2499679 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -161,11 +161,8 @@ void mesh_sta_cleanup(struct sta_info *sta)
del_timer_sync(&sta->plink_timer);
}
- if (changed) {
- sdata_lock(sdata);
+ if (changed)
ieee80211_mbss_info_change_notify(sdata, changed);
- sdata_unlock(sdata);
- }
}
int mesh_rmc_init(struct ieee80211_sub_if_data *sdata)
@@ -719,14 +716,15 @@ ieee80211_mesh_rebuild_beacon(struct ieee80211_sub_if_data *sdata)
void ieee80211_mbss_info_change_notify(struct ieee80211_sub_if_data *sdata,
u32 changed)
{
- if (sdata->vif.bss_conf.enable_beacon &&
- (changed & (BSS_CHANGED_BEACON |
- BSS_CHANGED_HT |
- BSS_CHANGED_BASIC_RATES |
- BSS_CHANGED_BEACON_INT)))
- if (ieee80211_mesh_rebuild_beacon(sdata))
- return;
- ieee80211_bss_info_change_notify(sdata, changed);
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ u32 bit;
+
+ /* if we race with running work, worst case this work becomes a noop */
+ for_each_set_bit(bit, (unsigned long *)&changed,
+ sizeof(changed) * BITS_PER_BYTE)
+ set_bit(BIT(bit), &ifmsh->mbss_changed);
+ set_bit(MESH_WORK_MBSS_CHANGED, &ifmsh->wrkq_flags);
+ ieee80211_queue_work(&sdata->local->hw, &sdata->work);
}
int ieee80211_start_mesh(struct ieee80211_sub_if_data *sdata)
@@ -969,6 +967,26 @@ out:
sdata_unlock(sdata);
}
+static void mesh_bss_info_changed(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ u32 bit, changed = 0;
+
+ for_each_set_bit(bit, (unsigned long *)&ifmsh->mbss_changed,
+ sizeof(changed) * BITS_PER_BYTE)
+ changed |= test_and_clear_bit(BIT(bit), &ifmsh->mbss_changed);
+
+ if (sdata->vif.bss_conf.enable_beacon &&
+ (changed & (BSS_CHANGED_BEACON |
+ BSS_CHANGED_HT |
+ BSS_CHANGED_BASIC_RATES |
+ BSS_CHANGED_BEACON_INT)))
+ if (ieee80211_mesh_rebuild_beacon(sdata))
+ return;
+
+ ieee80211_bss_info_change_notify(sdata, changed);
+}
+
void ieee80211_mesh_work(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
@@ -999,6 +1017,8 @@ void ieee80211_mesh_work(struct ieee80211_sub_if_data *sdata)
if (test_and_clear_bit(MESH_WORK_DRIFT_ADJUST, &ifmsh->wrkq_flags))
mesh_sync_adjust_tbtt(sdata);
+ if (test_and_clear_bit(MESH_WORK_MBSS_CHANGED, &ifmsh->wrkq_flags))
+ mesh_bss_info_changed(sdata);
out:
sdata_unlock(sdata);
}
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 8b4d9a3..be28f9b 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -57,6 +57,7 @@ enum mesh_path_flags {
* grow
* @MESH_WORK_ROOT: the mesh root station needs to send a frame
* @MESH_WORK_DRIFT_ADJUST: time to compensate for clock drift relative to other
+ * @MESH_WORK_MBSS_CHANGED: rebuild beacon and notify driver of BSS changes
* mesh nodes
*/
enum mesh_deferred_task_flags {
@@ -65,6 +66,7 @@ enum mesh_deferred_task_flags {
MESH_WORK_GROW_MPP_TABLE,
MESH_WORK_ROOT,
MESH_WORK_DRIFT_ADJUST,
+ MESH_WORK_MBSS_CHANGED,
};
/**
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 1/2] mac80211: fix mesh deadlock
From: Thomas Pedersen @ 2013-06-10 20:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, open80211s, Bob Copeland, Thomas Pedersen
The patch "cfg80211/mac80211: use cfg80211 wdev mutex in
mac80211" introduced several deadlocks by converting the
ifmsh->mtx to wdev->mtx. Solve these by:
1. drop the cancel_work_sync() in ieee80211_stop_mesh().
Instead make the mesh work conditional on whether the mesh
is running or not.
2. lock the mesh work with sdata_lock() to protect beacon
updates and prevent races with wdev->mesh_id_len or
cfg80211.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
net/mac80211/mesh.c | 29 +++++++++++++++++------------
net/mac80211/mesh_plink.c | 7 +------
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 73a597b..d5faf91 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -579,9 +579,7 @@ static void ieee80211_mesh_housekeeping(struct ieee80211_sub_if_data *sdata)
mesh_path_expire(sdata);
changed = mesh_accept_plinks_update(sdata);
- sdata_lock(sdata);
ieee80211_mbss_info_change_notify(sdata, changed);
- sdata_unlock(sdata);
mod_timer(&ifmsh->housekeeping_timer,
round_jiffies(jiffies +
@@ -788,12 +786,10 @@ void ieee80211_stop_mesh(struct ieee80211_sub_if_data *sdata)
sdata->vif.bss_conf.enable_beacon = false;
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
- sdata_lock(sdata);
bcn = rcu_dereference_protected(ifmsh->beacon,
lockdep_is_held(&sdata->wdev.mtx));
rcu_assign_pointer(ifmsh->beacon, NULL);
kfree_rcu(bcn, rcu_head);
- sdata_unlock(sdata);
/* flush STAs and mpaths on this iface */
sta_info_flush(sdata);
@@ -806,14 +802,6 @@ void ieee80211_stop_mesh(struct ieee80211_sub_if_data *sdata)
del_timer_sync(&sdata->u.mesh.housekeeping_timer);
del_timer_sync(&sdata->u.mesh.mesh_path_root_timer);
del_timer_sync(&sdata->u.mesh.mesh_path_timer);
- /*
- * If the timer fired while we waited for it, it will have
- * requeued the work. Now the work will be running again
- * but will not rearm the timer again because it checks
- * whether the interface is running, which, at this point,
- * it no longer is.
- */
- cancel_work_sync(&sdata->work);
local->fif_other_bss--;
atomic_dec(&local->iff_allmultis);
@@ -954,6 +942,12 @@ void ieee80211_mesh_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt;
u16 stype;
+ sdata_lock(sdata);
+
+ /* mesh already went down */
+ if (!sdata->wdev.mesh_id_len)
+ goto out;
+
rx_status = IEEE80211_SKB_RXCB(skb);
mgmt = (struct ieee80211_mgmt *) skb->data;
stype = le16_to_cpu(mgmt->frame_control) & IEEE80211_FCTL_STYPE;
@@ -971,12 +965,20 @@ void ieee80211_mesh_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
ieee80211_mesh_rx_mgmt_action(sdata, mgmt, skb->len, rx_status);
break;
}
+out:
+ sdata_unlock(sdata);
}
void ieee80211_mesh_work(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ sdata_lock(sdata);
+
+ /* mesh already went down */
+ if (!sdata->wdev.mesh_id_len)
+ goto out;
+
if (ifmsh->preq_queue_len &&
time_after(jiffies,
ifmsh->last_preq + msecs_to_jiffies(ifmsh->mshcfg.dot11MeshHWMPpreqMinInterval)))
@@ -996,6 +998,9 @@ void ieee80211_mesh_work(struct ieee80211_sub_if_data *sdata)
if (test_and_clear_bit(MESH_WORK_DRIFT_ADJUST, &ifmsh->wrkq_flags))
mesh_sync_adjust_tbtt(sdata);
+
+out:
+ sdata_unlock(sdata);
}
void ieee80211_mesh_notify_scan_completed(struct ieee80211_local *local)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 6c4da99..09bebed 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -517,9 +517,7 @@ void mesh_neighbour_update(struct ieee80211_sub_if_data *sdata,
ieee80211_mps_frame_release(sta, elems);
out:
rcu_read_unlock();
- sdata_lock(sdata);
ieee80211_mbss_info_change_notify(sdata, changed);
- sdata_unlock(sdata);
}
static void mesh_plink_timer(unsigned long data)
@@ -1070,9 +1068,6 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata,
rcu_read_unlock();
- if (changed) {
- sdata_lock(sdata);
+ if (changed)
ieee80211_mbss_info_change_notify(sdata, changed);
- sdata_unlock(sdata);
- }
}
--
1.7.10.4
^ permalink raw reply related
* Re: pull-request: iwlwifi-next 2013-06-05
From: John W. Linville @ 2013-06-10 19:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1370416113.8920.10.camel@jlt4.sipsolutions.net>
On Wed, Jun 05, 2013 at 09:08:33AM +0200, Johannes Berg wrote:
> Hi,
>
> And just like the fixes for old code never end, also the fixes for new
> code :-) But I also have some new features. I also had to merge
> wireless-next to get a cfg80211 change that the D3 test feature depends
> on.
>
> Here I mostly have various fixes for AP/GO mode, Bluetooth coexistence
> and power save modes. The only new thing is the introduction of "D3
> test" mode, accessible through debugfs for D3 firmware debugging.
>
> Please pull.
>
> Thanks,
> johannes
>
> The following changes since commit a910e4a94f6923c8c988565525f017f687bf7205:
>
> cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets (2013-05-29 15:26:40 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git for-john
>
> for you to fetch changes up to fded313ec045024d4f769ce6b3e41fe343c167b0:
>
> iwlwifi: mvm: don't request SMPS on non-STA iface (2013-06-05 09:06:13 +0200)
Pulling now...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Power saving features for iwl4965
From: Pedro Francisco @ 2013-06-10 19:31 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Tino Keitel, ML linux-wireless
In-Reply-To: <CAJZjf_xoCOTFsLAB29uLKeW7+O+k255Amspn6GKFMysc7CTsBg@mail.gmail.com>
On Sun, Jun 9, 2013 at 1:28 AM, Pedro Francisco
<pedrogfrancisco@gmail.com> wrote:
> On Mon, Jun 3, 2013 at 3:18 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> On Mon, Jun 03, 2013 at 10:52:39AM +0200, Tino Keitel wrote:
>>> (...)
>>> It would be really nice to have proper power management in a current
>>> kernel, as the laptop gets noticeably hotter with the current iwlegacy
>>> driver. That's why I still use a 3.1.10 kernel with an old
>>> forward-ported iwlagn driver.
>>
>> Could you try this experimental patch? (...)
>
> I am trying the iwlegacy powersave patch along with CPU scheduler BFS
> and IO scheduler BFQ.
>
> I've got this today: (...)
>
> $ uname -a
> Linux s2 3.9.4-301.local.fc19.i686
>
> I have just made a clean boot (as in, this has not happened after a
> resume for suspend or hibernation).
>
> May it be related to the patch? Or may heavy IO with out-of-tree CPU
> scheduler BFS and out-of-tree IO scheduler BFQ be responsible for the
> warnings?
I also got a SYSASSERT:
[Jun 9 10:35] iwl3945 0000:02:00.0: Read idx for DMA queue txq_id (2)
idx 186 is out of range [0-256] 186 186
(...)
[ +0,000164] iwl3945 0000:02:00.0: Read idx for DMA queue txq_id (2)
idx 185 is out of range [0-256] 186 186
[Jun 9 10:36] iwl3945 0000:02:00.0: Microcode SW error detected.
Restarting 0x82000008.
[ +0,000008] iwl3945 0000:02:00.0: Loaded firmware version: 15.32.2.9
[ +0,000034] iwl3945 0000:02:00.0: Start IWL Error Log Dump:
[ +0,000004] iwl3945 0000:02:00.0: Status: 0x000302E4, count: 1
[ +0,000004] iwl3945 0000:02:00.0: Desc Time asrtPC
blink2 ilink1 nmiPC Line
[ +0,000224] iwl3945 0000:02:00.0: SYSASSERT (0x5) 0228106348
0x008B6 0x0035E 0x0031C 0x00000 267
[ +0,000010] iwl3945 0000:02:00.0: Error Reply type 0x00000001 cmd
UNKNOWN (0xFC) seq 0x2099 ser 0x00FC0000
[ +0,000466] iwl3945 0000:02:00.0: Can't stop Rx DMA.
[ +0,001647] ieee80211 phy0: Hardware restart was requested
[Jun 9 10:38] iwl3945 0000:02:00.0: Read idx for DMA queue txq_id (2)
idx 186 is out of range [0-256] 186 186
(...)
I disabled powersave (but kept running the same kernel) and none of
the errors appeared again.
^ permalink raw reply
* Re: Anyone know of a pci to multiple-mini-pci-e adapter?
From: Oleksij Rempel @ 2013-06-10 18:48 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Ben Greear, linux-wireless@vger.kernel.org
In-Reply-To: <CACna6rynqCQTgaJzptjdQreQM4WLJW9MFKS3kBONaHNgkGsLRQ@mail.gmail.com>
Am 10.06.2013 20:37, schrieb Rafał Miłecki:
> 2013/6/10 Ben Greear <greearb@candelatech.com>:
>> On 06/10/2013 02:45 AM, Rafał Miłecki wrote:
>>>
>>> 2013/4/24 Ben Greear <greearb@candelatech.com>:
>>>>
>>>> I'm trying to find a way to cram multiple wifi NICs into a single
>>>> (x4 or higher) pcie slot.
>>>>
>>>> There are a great many pci-e to mini-pci-e adapters, but everything
>>>> I can find has only a single mini-pci-e slot on it....
>>>>
>>>> If someone knows of such a beast, or has suggestions for someone
>>>> who might could make them, please let me know.
>>>
>>>
>>> Ben, I wonder if you have found anything...?
>>
>>
>> I found a company that will make them for me, but I'll need to
>> order 200 of them as minimum order.
>>
>> Want some? :)
>
> Maybe 2 ;) So you still have to found another ~100 people willing some ;)
>
how match will it cost?
--
Regards,
Oleksij
^ permalink raw reply
* Re: Anyone know of a pci to multiple-mini-pci-e adapter?
From: Rafał Miłecki @ 2013-06-10 18:37 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <51B6043F.8010603@candelatech.com>
2013/6/10 Ben Greear <greearb@candelatech.com>:
> On 06/10/2013 02:45 AM, Rafał Miłecki wrote:
>>
>> 2013/4/24 Ben Greear <greearb@candelatech.com>:
>>>
>>> I'm trying to find a way to cram multiple wifi NICs into a single
>>> (x4 or higher) pcie slot.
>>>
>>> There are a great many pci-e to mini-pci-e adapters, but everything
>>> I can find has only a single mini-pci-e slot on it....
>>>
>>> If someone knows of such a beast, or has suggestions for someone
>>> who might could make them, please let me know.
>>
>>
>> Ben, I wonder if you have found anything...?
>
>
> I found a company that will make them for me, but I'll need to
> order 200 of them as minimum order.
>
> Want some? :)
Maybe 2 ;) So you still have to found another ~100 people willing some ;)
--
Rafał
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: update mesh beacon on workqueue
From: Thomas Pedersen @ 2013-06-10 18:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, open80211s
In-Reply-To: <1370847386.8535.0.camel@jlt4.sipsolutions.net>
On Sun, Jun 9, 2013 at 11:56 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sun, 2013-06-09 at 19:41 -0700, Thomas Pedersen wrote:
>
>> > +static void mesh_bss_info_changed(struct ieee80211_sub_if_data *sdata)
>> > +{
>> > + struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
>> > +#define TEST_CHANGED_BIT(bit) \
>> > + test_and_clear_bit(bit, &ifmsh->mbss_changed)
>> > +
>> > + u32 changed = TEST_CHANGED_BIT(BSS_CHANGED_BEACON) |
>> > + TEST_CHANGED_BIT(BSS_CHANGED_HT) |
>> > + TEST_CHANGED_BIT(BSS_CHANGED_BASIC_RATES) |
>> > + TEST_CHANGED_BIT(BSS_CHANGED_BEACON_INT);
>> > +#undef TEST_CHANGED_BIT
>>
>> Uhhh we should read all the bits here. Will fix and resubmit as v2.
>
> Now that you're quoting it I'd also say that the macro isn't really
> best, does removing it really make the code so much worse?
No, it won't be there in v2. Thanks.
--
Thomas
^ permalink raw reply
* RE: [PATCH v2 2/2] cfg80211/nl80211: Add packet coalesce support
From: Bing Zhao @ 2013-06-10 17:52 UTC (permalink / raw)
To: Amitkumar Karwar, 'Johannes Berg'
Cc: linux-wireless@vger.kernel.org, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho
In-Reply-To: <5FF020A1CFFEEC49BD1E09530C4FF5950F313C2CB5@SC-VEXCH1.marvell.com>
Hi Johannes,
> > Can you please change this to "iw coalesce set" and make it set all the
> > rules in one?
>
> "iw coalesce add" was used, because command for adding multiple rules at the same time will be a bit
> lengthy(user will need to enter multiple lists of packet patterns) and syntax check in iw will also
> need some efforts.
>
> > Otherwise you're going to have very awkward races and need
> > to always clear etc. The code would also be easier, though obviously
> > you'd need to be able to specify multiple rules at the same time.
>
> For "iw coalesce set" also user needs to always clear the settings using "iw coalesce disable". Also
> similar to "coalesce set", for "coalesce add" we clear the settings and free allocations while
> unloading the driver.
>
> Please let us know if you prefer "coalesce set" over "coalesce add".
Could you please confirm your preference for "coalesce set" over "coalesce add"?
Thanks,
Bing
^ permalink raw reply
* Re: Anyone know of a pci to multiple-mini-pci-e adapter?
From: Ben Greear @ 2013-06-10 16:52 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CACna6rx9yb-gt-UCXy3CfSSuC=1_7Zh=294CrM0deDEgFDGCYw@mail.gmail.com>
On 06/10/2013 02:45 AM, Rafał Miłecki wrote:
> 2013/4/24 Ben Greear <greearb@candelatech.com>:
>> I'm trying to find a way to cram multiple wifi NICs into a single
>> (x4 or higher) pcie slot.
>>
>> There are a great many pci-e to mini-pci-e adapters, but everything
>> I can find has only a single mini-pci-e slot on it....
>>
>> If someone knows of such a beast, or has suggestions for someone
>> who might could make them, please let me know.
>
> Ben, I wonder if you have found anything...?
I found a company that will make them for me, but I'll need to
order 200 of them as minimum order.
Want some? :)
Thanks,
Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 0/5] add master channel switch announcement support
From: Felix Fietkau @ 2013-06-10 15:38 UTC (permalink / raw)
To: Simon Wunderlich
Cc: linux-wireless, Johannes Berg, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <20130610151154.GA1640@pandem0nium>
On 2013-06-10 5:11 PM, Simon Wunderlich wrote:
> Hey Felix,
>
> On Fri, Jun 07, 2013 at 07:33:16PM +0200, Felix Fietkau wrote:
>> On 2013-06-07 7:05 PM, Simon Wunderlich wrote:
>> > This is the follow up from the RFC posted a month ago. This patchset adds generic
>> > channel switch support for AP. This is required for DFS operation
>> > (e.g. Wi-Fi Alliance requires this for 802.11h certification). This will also
>> > be required for IBSS-DFS later.
>> >
>> > The rough design is:
>> > * userspace asks kernel to switch a channel using the new NL80211_CMD_CHANNEL_SWITCH
>> > command. It supplies IE information for the time while staying on the old channel and
>> > announcing the switch, and IE information for after the switch to the new channel.
>> > * IE information contains the beacon and optionally probe responses, which should
>> > include (E)CSA IEs for the CSA case. Furthermore an offset is provided (for beacon
>> > and probe response) to point to the counter field within the channel switch IEs.
>> > * The driver gets the new beacons passed and must set them, and decrement the
>> > counter field. When it reaches 0, the channel is changed and userspace notified.
>> >
>> > Discussion points:
>> > * Assembling all these IE information is a little bit tedious but doable (I've
>> > patched hostapd).
>> > * Other future users like IBSS/MESH will not get the beacon/probe response IEs, as they
>> > generate these beacons themselves. Therefore they need the COUNT attribute, which
>> > is kind of duplicate right now.
>> > * Userspace must generate/handle all IEs, which lifts the previous limitations of
>> > the RFC (e.g. no change of band allowed, no operation mode change allowed).
>> > * it currently works for me [TM] on my ath9k based machine
>> I think this is a bit racy. Just because the driver gets a beacon from
>> mac80211 doesn't mean that the beacon will be sent *immediately*. I'd
>> recommend calling back from the driver into mac80211 on beacon tx
>> completion. Also, it might make sense to skip CAB queue transmissions in
>> this case.
>
> mhm, you're right, changing channel might race with sending the beacon as it's
> set right now. I'd change it to:
>
> * update the counter within get_beacon() (as done now)
> * perform the channel switch after beacon transmission is completed (not sure how to get this
> event practically yet ... :] )
>
> What do you think?
>
> This must probably handle stuck/lost beacons too - is there any completion function
> called for stuck beacons?
Right now there are no mac80211 callbacks for either completed or missed
beacon tx. Inside ath9k, on AR93xx+, beacons get normal tx completion
events. For older chipsets the status descriptor must be checked
explicitly - see the implementation of drv_tx_last_beacon.
To get the timing right for checking tx completion of the beacon, you
can let the normal pre-AR93xx tx completion function check the beacon
queue if CSA was indicated via a flag or something.
As for stuck beacon, you can hook into the beacon tasklet function.
If the driver knows that a CSA is imminent, it can send the notification
on a stuck beacon event even before it hits the hw reset (which it only
does after several consecutive stuck beacon events).
- Felix
^ 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