* Re: [PATCH 0/8] iwlwifi update for 2.6.36
From: John W. Linville @ 2010-08-04 19:03 UTC (permalink / raw)
To: Wey-Yi Guy; +Cc: linux-wireless, ipw3945-devel
In-Reply-To: <1280590452-10655-1-git-send-email-wey-yi.w.guy@intel.com>
On Sat, Jul 31, 2010 at 08:34:04AM -0700, Wey-Yi Guy wrote:
> We move "Thermal throttling" related functions out of power management
> into it own file.
> We also reduce the warning level for "BA scd_flow not match" to
> avoid flood the syslog when condition detected.
> We also track IBSS manager status with uCode beacon notification.
>
> Johannes Berg (2):
> iwlwifi: fix compile warning
>
> Wey-Yi Guy (6):
> iwlwifi: BA scd_flow not match condition detected
> iwlagn: fix typo in ucode_bt_stats_read debugfs
I'm applying these directly as fixes intended for 2.6.36. I will
apply the others to wireless-next-2.6 after the merge window closes
for 2.6.36.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 0/8] iwlwifi update for 2.6.36
From: Guy, Wey-Yi @ 2010-08-04 19:17 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <20100804190320.GQ17666@tuxdriver.com>
Hi John,
On Wed, 2010-08-04 at 20:03 +0100, John W. Linville wrote:
> On Sat, Jul 31, 2010 at 08:34:04AM -0700, Wey-Yi Guy wrote:
> > We move "Thermal throttling" related functions out of power management
> > into it own file.
> > We also reduce the warning level for "BA scd_flow not match" to
> > avoid flood the syslog when condition detected.
> > We also track IBSS manager status with uCode beacon notification.
> >
> > Johannes Berg (2):
>
> > iwlwifi: fix compile warning
> >
> > Wey-Yi Guy (6):
>
> > iwlwifi: BA scd_flow not match condition detected
> > iwlagn: fix typo in ucode_bt_stats_read debugfs
>
> I'm applying these directly as fixes intended for 2.6.36. I will
> apply the others to wireless-next-2.6 after the merge window closes
> for 2.6.36.
>
Thank you very much
Wey
^ permalink raw reply
* Re: [wt PATCH 0/5] libertas: make association work again
From: John W. Linville @ 2010-08-04 19:34 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <1280949346.11056.1.camel@dcbw.foobar.com>
On Wed, Aug 04, 2010 at 02:15:46PM -0500, Dan Williams wrote:
> On Wed, 2010-08-04 at 09:46 +0200, Johannes Berg wrote:
> > On Wed, 2010-08-04 at 00:41 -0500, Dan Williams wrote:
> > > On Fri, 2010-07-30 at 08:35 +0200, Johannes Berg wrote:
> > > > On Thu, 2010-07-29 at 23:07 -0700, Dan Williams wrote:
> > > > > This series makes libertas actually associate with APs after the
> > > > > cfg80211 conversion. There was a pretty big TODO where if cfg80211
> > > > > didn't pass in the BSSID of the AP to associate with, then libertas
> > > > > would fail because the firmware really, really, really wants a BSSID.
> > > > > So lets do a scan to find that BSSID. The other notable change is
> > > > > a fix to make sure all supported rates are included in the firmware's
> > > > > association request, lack of which caused some APs to deny the attempt.
> > > >
> > > > I'm a bit tempted to say we could use the connect logic in cfg80211 to
> > > > provide this? cfg80211 _already_ provides this if the hardware wants
> > > > auth()/assoc() rather than connect() calls, so it seems fairly simple to
> > > > also (optionally) do it here?
> > >
> > > Yeah, I thought about that too. Do you want me to work on that now
> > > instead of letting this patch through? I can revert the relevant bits
> > > of this later if that's acceptable too.
> >
> > Either way works for me since I don't care about any cruft in
> > libertas ;)
>
> John, if you don't mind applying this patch I'll work on generic
> scan-before-connect support in cfg80211 in a further patch series.
OK...which of these need to be in 2.6.36?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Pull request: bluetooth-next-2.6 2010-08-04
From: Marcel Holtmann @ 2010-08-04 20:38 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
Hi John,
I have four more bug fixes for the 2.6.36 merge window. All of them
are pretty straight forward.
They are still based on your wireless-next-2.6 tree. I hope that is
no problem for you. I can rebase them quickly if needed.
Regards
Marcel
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-next-2.6.git master
This will update the following files:
include/net/bluetooth/hci_core.h | 2 +-
net/bluetooth/hci_core.c | 2 +-
net/bluetooth/hci_sock.c | 8 +++-----
net/bluetooth/hci_sysfs.c | 3 +--
net/bluetooth/l2cap.c | 24 +++++++++++++++++++++---
net/bluetooth/rfcomm/tty.c | 2 +-
6 files changed, 28 insertions(+), 13 deletions(-)
through these ChangeSets:
David Miller (1):
Bluetooth: Use list_head for HCI blacklist head
Gustavo F. Padovan (2):
Bluetooth: Remove __exit from rfcomm_cleanup_ttys()
Bluetooth: Don't send RFC for Basic Mode if only it is supported
Ville Tervo (1):
Bluetooth: Check result code of L2CAP information response
^ permalink raw reply
* Compat-wireless for 2.6.35 final - 802.11, Bluetooth, Ethernet backported
From: Luis R. Rodriguez @ 2010-08-04 21:50 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth, netdev; +Cc: linux-kernel
Linus released 2.6.35 so we get our respective compat-wireless-2.6.35
released which backports the kernel's 802.11, Bluetooth and some
Ethernet drivers down to kernels >= 2.6.27. Goal is to always backport
all drivers down to the oldest supported 2.6. kenrel release listed on
kernel.org. Some drivers are backported to even further older kernels
(ath9k should go down to 2.6.23), to enable only one driver use the
./scripts/driver-select script. You can get compat-wireless-2.6.35
from:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/compat-wireless-2.6.35-0.tar.bz2
sha1sum: a718b6377136560894e7919304d0cf7a5106815b
compat-wireless code metrics
491756 - Total lines of upstream code being pulled
1394 - backport code changes
1163 - backport code additions
231 - backport code deletions
5737 - backport from compat module
7131 - total lines of backport code
1.45 - % of code consists of backport work
Base tree: linux-2.6-allstable.git
Base tree version: v2.6.35
compat-wireless release: compat-wireless-v2.6.35-0
Since we can have extra fixes within compat.git / compat-wireless.git
for stable releases in between stable kernel extra version updates I'm
started to rely on -release_number tag postfixes to the release tag.
So this release has the -0 release number, if we get a new fix/update
on this package before 2.6.35.1 we'll have compat-wireless-2.6.35-1,
and so on.
Changes that went into the Linux kernel for this release:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/ChangeLog-2.6.35-wireless
This comes from:
git log v2.6.34..HEAD \
net/wireless/ \
net/mac80211/ \
net/rfkill/ \
drivers/net/wireless/ \
net/bluetooth/ \
drivers/net/atl1c/ \
drivers/net/atl1e/ \
drivers/net/atlx/ \
drivers/bluetooth/ \
include/linux/nl80211.h \
include/linux/rfkill.h \
include/net/cfg80211.h \
include/net/regulatory.h \
include/net/cfg80211.h
For more information see:
http://wireless.kernel.org/en/users/Download/stable
compat-wireless makes use of the compat.git tree which provides a
generic Linux kernel compatibility module which besides providing
generic kernel helpers also backports the new rfkill, pm-qos and
firmware_class stuff. The updates from compat since the 2.6.34 kernel
release are:
Hauke Mehrtens (7):
compat: backport eth_change_mtu and eth_validate_addr
compat: move kparam_{block,unblock}_sysfs_write
compat: move usb_{alloc,free}_coherent
compat: update bitops.h and wireless.h
compat: move kparam_{block,unblock}_sysfs_write
compat: backport small functions and defines
compat: use kernel pm_qos_params.h
Luis R. Rodriguez (11):
compat: add new way to backport the usage of net_device_ops
compat: add the rest of the missing netdev_attach_ops()
compat: add the ndo_select_queue for netdev_attach_ops()
compat: add compat_version read-only module parameter
Modify the compat print
Add the COMPAT_BASE_TREE and COMPAT_BASE_TREE_VERSION
Add a COMPAT_PROJECT tag
Fix the syntax for the defines passed for compat
Remove the stupid SET_NETDEVOP
compat: create the udev directories for compat_firmware file
compat: backport USHRT_MAX, SHRT_MAX and SHRT_MIN
Rajkumar Manoharan (1):
compat: Fix panic caused by NULL pointer derefence in rtnl_fill_ifinfo
compat-wireless changes since the compat-wireless-2.6.34 release are:
Bruno Randolf (1):
compat-wireless: fix 07-change-default-rate-alg.patch
Hauke Mehrtens (23):
compat-wireless: rename {free,alloc}_ieee80211 to {free,alloc}_libipw
compat-wireless: fix building of iwmc3200wifi
compat-wireless: remove some uneeded header files
compat-wireless: update config symbols
compat-wireless: add orinoco to compat-wireless
compat-wireless: remove rename {free,alloc}_ieee80211 patch
compat-wireless: refresh patch to apply again
compat-wireless: Backport changes in pcmcia system
compat-wireless: fix use of device_create
compat-wireless: use wireless_handlers for wext functions.
compat-wireless: backport convert multicast list to list_head.
compat-wireless: Remove use of sdio quirks attribute
compat-wireless: include net and trace includes form compat.
compat-wireless: refresh patches
compat-wireless: updates for orinoco
compat-wireless: backport pm_qos_{add,remove,update}_request
compat-wireless: make patches apply again
Revert "compat-wireless: fix 07-change-default-rate-alg.patch"
compat-wireless: Update Readme to reflect changes
compat-wireless: update clean scripts
compat-wireless: use /etc/init.d/ and not sudo service
compat-wireless: run refresh only on last applied directory
compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
Luis R. Rodriguez (77):
./scripts/admin-update.sh refresh
./scripts/admin-update.sh refres
admin-update refresh the patches
driver-select: enable listing of ath9k_htc
driver-select: fix selecting ath9k_htc
admin-update refresh
Fix patches/06-header-changes.patch
Fix patches/13-trace.patch
admin-update refresh
admin-update refresh
admin-update refresh
Update USB makefile for new driver ipheth.o
./scripts/admin-update.sh refresh
compat-wireless: make use of new netdev_attach_ops() for orinoco
scripts/admin-update.sh refresh
Make rndis_host use netdev_attach_ops()
usbnet: use netdev_attach_ops()
rndis_wlan: fix backport of netdev_attach_ops() usage
rndis_wlan: use netdev_attach_ops()
mac80211: use netdev_attach_ops()
admin-update refresh
b44: use netdev_attach_ops()
ipw2100: use netdev_attach_ops()
ipw2200: use netdev_attach_ops()
libertas: use netdev_attach_ops()
mac80211_hwsim: use netdevice_attach_ops()
bnep, atl1e, atl1c: use netdev_attach_ops()
atl1: use netdev_attach_ops()
atl2: use netdev_attach_ops()
./scripts/admin-update.sh refresh
./scripts/admin-update.sh refresh
Change admin-update.sh to use system version files
Remove double line on admin-update.sh
Split up the NOSTDINC_FLAGS into a few lines
Use the defines to tag the compat module
Fix dependency on on WEXT
Fix the CREL compat-wireless release name on top level Makefile
Fix gen-compat-autoconf.sh for new version name changes
Fix scripts/driver-select due to new version changes
Add the compat to the unload of the modules
compat-wireless: add linux-next-pending, crap patch dirs and nagometer
rm -rf drivers when running scripts/admin-update.sh
compat-wireless: add a set of pending patches for linux-wireless
compat-wireless: add the Kconfig for drivers
compat-wireless: add some Atheros crap patches
compat-wireless: run ./scripts/compat_firmware_install
compat-wireless: remove some new files upon make clean
compat-wireless: add the new versioning files to .gitignore
Revert "compat-wireless: run ./scripts/compat_firmware_install"
compat-wireless: remove pending patches as of next-20100525
compat-wireless: ./scripts/admin-update.sh refresh
compat-wireless: fix backport code calculation
compat-wireless: only copy existing Kconfig files
compat-wireless: ./scripts/admin-update.sh -p refresh
compat-wireless: fix typo for used color for nagometer
compat-wireless: add new set of pending patches for 2010-05-25
compat-wireless: update the atheros crap patches
compat-wireless: clarify usage of linux-next-cherry-pick for bleeding edge
compat-wireless: remove two pending patches now upstream
compat-wireless: add pending fix patch for ath9k
compat-wireless: fixes offsets for
07-change-default-rate-alg.patch for 2.6.35-rc1
./scripts/admin-update.sh refresh
compat-wireless: fix hunks for crap/0002-ath9k-Add-pktlog-support.patch
compat-wireless: accept extra arguments for scripts/gen-stable-release.sh
Remove sucked in patch post 2.6.35-rc1
compat-wireless: add -n -p -c support for gen-stable-release.sh
compat-wireless: optimize branch selection on gen-stable-release.sh
compat-wireless: update the usage() print for gen-stable-release.sh
compat-wireless: fix target kernel expecations on gen-stable-release.sh
compat-wireless: Drop all the linux-next-pending patches
compat-wireless: remove the crap patches
compat-wireless: refresh hunks for 2.6.35-rc2
compat-wireless: refresh hunks for 2.6.35-rc2 as of June 11 2010
compat-wireless: fix patch patches/25-multicast-list_head.patch
for BT bnet
compat-wireless: ./scripts/admin-update.sh refresh
compta-wireless: update unload script
compat-wireless: refresh patches for 2.6.36-rc6
Paul Fertser (1):
compat-wireless: driver-select: add b43 to the list
Pavel Roskin (9):
compat-wireless: disable rt2800 if crc_ccitt is not available
compat-wireless: disable wl1251 SPI and wl1271 if crc7 is not available
compat-wireless: add support for ath9k_htc
compat-wireless: update 22-multiqueue.patch for the current linux-next
compat-wireless: remove patch part dealing with net/net_namespace.h
compat-wireless: remove 13-trace.patch, it's handled in compat now
compat-wireless: remove 25-device_create.patch, it's handled by compat
compat-wireless: find the actual remote URL
compat-wireless: fix fallbacks for unknown branch, remote or remote URL
Walter Goldens (2):
compat-wireless, unload rt2800usb
compat-wireless: rt2x00 added to driver-select
Thanks to the contributors!
Luis
^ permalink raw reply
* GIT: net-*2.6 rebased...
From: David Miller @ 2010-08-04 23:21 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, sfr
Both net-2.6 and net-next-2.6 have been rebased.
To be honest, if you've been pulling from my tree you can just keep
doing so if you want, it will look just as if I had merged Linus's
tree into net-2.6 et al.
All work will go into net-2.6 for the time being, this means only
bug fixes and such.
Once -rc1 goes out, changes can start flowing into net-next-2.6
once more.
Please adhere to these rules, it helps keep the tree stable and
preserve the limited sanity still remaining in folks like Stephen
Rothwell. :-)
Thanks.
^ permalink raw reply
* [PATCH 1/3 v2] mac80211: put rx handlers into separate functions
From: Christian Lamparter @ 2010-08-04 23:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, John W. Linville
This patch takes the reorder logic from the RX path and
moves it into separate routines to make the expired frame
release accessible.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
WIP -> v1:
- no changes
v1 -> v2:
- rearrange code and get rid of the forward declaration
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index fa0f37e..fccd5f7 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -583,6 +583,57 @@ static void ieee80211_release_reorder_frames(struct ieee80211_hw *hw,
*/
#define HT_RX_REORDER_BUF_TIMEOUT (HZ / 10)
+static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
+ struct tid_ampdu_rx *tid_agg_rx,
+ struct sk_buff_head *frames)
+{
+ int index;
+
+ /* release the buffer until next missing frame */
+ index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn) %
+ tid_agg_rx->buf_size;
+ if (!tid_agg_rx->reorder_buf[index] &&
+ tid_agg_rx->stored_mpdu_num > 1) {
+ /*
+ * No buffers ready to be released, but check whether any
+ * frames in the reorder buffer have timed out.
+ */
+ int j;
+ int skipped = 1;
+ for (j = (index + 1) % tid_agg_rx->buf_size; j != index;
+ j = (j + 1) % tid_agg_rx->buf_size) {
+ if (!tid_agg_rx->reorder_buf[j]) {
+ skipped++;
+ continue;
+ }
+ if (!time_after(jiffies, tid_agg_rx->reorder_time[j] +
+ HT_RX_REORDER_BUF_TIMEOUT))
+ break;
+
+#ifdef CONFIG_MAC80211_HT_DEBUG
+ if (net_ratelimit())
+ printk(KERN_DEBUG "%s: release an RX reorder "
+ "frame due to timeout on earlier "
+ "frames\n",
+ wiphy_name(hw->wiphy));
+#endif
+ ieee80211_release_reorder_frame(hw, tid_agg_rx,
+ j, frames);
+
+ /*
+ * Increment the head seq# also for the skipped slots.
+ */
+ tid_agg_rx->head_seq_num =
+ (tid_agg_rx->head_seq_num + skipped) & SEQ_MASK;
+ skipped = 0;
+ }
+ } else while (tid_agg_rx->reorder_buf[index]) {
+ ieee80211_release_reorder_frame(hw, tid_agg_rx, index, frames);
+ index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn) %
+ tid_agg_rx->buf_size;
+ }
+}
+
/*
* As this function belongs to the RX path it must be under
* rcu_read_lock protection. It returns false if the frame
@@ -643,49 +694,7 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
tid_agg_rx->reorder_buf[index] = skb;
tid_agg_rx->reorder_time[index] = jiffies;
tid_agg_rx->stored_mpdu_num++;
- /* release the buffer until next missing frame */
- index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn) %
- tid_agg_rx->buf_size;
- if (!tid_agg_rx->reorder_buf[index] &&
- tid_agg_rx->stored_mpdu_num > 1) {
- /*
- * No buffers ready to be released, but check whether any
- * frames in the reorder buffer have timed out.
- */
- int j;
- int skipped = 1;
- for (j = (index + 1) % tid_agg_rx->buf_size; j != index;
- j = (j + 1) % tid_agg_rx->buf_size) {
- if (!tid_agg_rx->reorder_buf[j]) {
- skipped++;
- continue;
- }
- if (!time_after(jiffies, tid_agg_rx->reorder_time[j] +
- HT_RX_REORDER_BUF_TIMEOUT))
- break;
-
-#ifdef CONFIG_MAC80211_HT_DEBUG
- if (net_ratelimit())
- printk(KERN_DEBUG "%s: release an RX reorder "
- "frame due to timeout on earlier "
- "frames\n",
- wiphy_name(hw->wiphy));
-#endif
- ieee80211_release_reorder_frame(hw, tid_agg_rx,
- j, frames);
-
- /*
- * Increment the head seq# also for the skipped slots.
- */
- tid_agg_rx->head_seq_num =
- (tid_agg_rx->head_seq_num + skipped) & SEQ_MASK;
- skipped = 0;
- }
- } else while (tid_agg_rx->reorder_buf[index]) {
- ieee80211_release_reorder_frame(hw, tid_agg_rx, index, frames);
- index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn) %
- tid_agg_rx->buf_size;
- }
+ ieee80211_sta_reorder_release(hw, tid_agg_rx, frames);
return true;
}
@@ -2267,19 +2276,46 @@ static void ieee80211_rx_cooked_monitor(struct ieee80211_rx_data *rx,
dev_kfree_skb(skb);
}
+static void ieee80211_rx_handlers_result(struct ieee80211_rx_data *rx,
+ ieee80211_rx_result res)
+{
+ switch (res) {
+ case RX_DROP_MONITOR:
+ I802_DEBUG_INC(rx->sdata->local->rx_handlers_drop);
+ if (rx->sta)
+ rx->sta->rx_dropped++;
+ /* fall through */
+ case RX_CONTINUE: {
+ struct ieee80211_rate *rate = NULL;
+ struct ieee80211_supported_band *sband;
+ struct ieee80211_rx_status *status;
+
+ status = IEEE80211_SKB_RXCB((rx->skb));
+
+ sband = rx->local->hw.wiphy->bands[status->band];
+ if (!(status->flag & RX_FLAG_HT))
+ rate = &sband->bitrates[status->rate_idx];
+
+ ieee80211_rx_cooked_monitor(rx, rate);
+ break;
+ }
+ case RX_DROP_UNUSABLE:
+ I802_DEBUG_INC(rx->sdata->local->rx_handlers_drop);
+ if (rx->sta)
+ rx->sta->rx_dropped++;
+ dev_kfree_skb(rx->skb);
+ break;
+ case RX_QUEUED:
+ I802_DEBUG_INC(rx->sdata->local->rx_handlers_queued);
+ break;
+ }
+}
-static void ieee80211_invoke_rx_handlers(struct ieee80211_sub_if_data *sdata,
- struct ieee80211_rx_data *rx,
- struct sk_buff *skb,
- struct ieee80211_rate *rate)
+static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
+ struct sk_buff_head *frames)
{
- struct sk_buff_head reorder_release;
ieee80211_rx_result res = RX_DROP_MONITOR;
-
- __skb_queue_head_init(&reorder_release);
-
- rx->skb = skb;
- rx->sdata = sdata;
+ struct sk_buff *skb;
#define CALL_RXH(rxh) \
do { \
@@ -2288,17 +2324,7 @@ static void ieee80211_invoke_rx_handlers(struct ieee80211_sub_if_data *sdata,
goto rxh_next; \
} while (0);
- /*
- * NB: the rxh_next label works even if we jump
- * to it from here because then the list will
- * be empty, which is a trivial check
- */
- CALL_RXH(ieee80211_rx_h_passive_scan)
- CALL_RXH(ieee80211_rx_h_check)
-
- ieee80211_rx_reorder_ampdu(rx, &reorder_release);
-
- while ((skb = __skb_dequeue(&reorder_release))) {
+ while ((skb = __skb_dequeue(frames))) {
/*
* all the other fields are valid across frames
* that belong to an aMPDU since they are on the
@@ -2316,42 +2342,58 @@ static void ieee80211_invoke_rx_handlers(struct ieee80211_sub_if_data *sdata,
CALL_RXH(ieee80211_rx_h_remove_qos_control)
CALL_RXH(ieee80211_rx_h_amsdu)
#ifdef CONFIG_MAC80211_MESH
- if (ieee80211_vif_is_mesh(&sdata->vif))
+ if (ieee80211_vif_is_mesh(&rx->sdata->vif))
CALL_RXH(ieee80211_rx_h_mesh_fwding);
#endif
CALL_RXH(ieee80211_rx_h_data)
/* special treatment -- needs the queue */
- res = ieee80211_rx_h_ctrl(rx, &reorder_release);
+ res = ieee80211_rx_h_ctrl(rx, frames);
if (res != RX_CONTINUE)
goto rxh_next;
CALL_RXH(ieee80211_rx_h_action)
CALL_RXH(ieee80211_rx_h_mgmt)
+ rxh_next:
+ ieee80211_rx_handlers_result(rx, res);
+
#undef CALL_RXH
+ }
+}
+
+static void ieee80211_invoke_rx_handlers(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_rx_data *rx,
+ struct sk_buff *skb,
+ struct ieee80211_rate *rate)
+{
+ struct sk_buff_head reorder_release;
+ ieee80211_rx_result res = RX_DROP_MONITOR;
+
+ __skb_queue_head_init(&reorder_release);
+
+ rx->skb = skb;
+ rx->sdata = sdata;
+
+#define CALL_RXH(rxh) \
+ do { \
+ res = rxh(rx); \
+ if (res != RX_CONTINUE) \
+ goto rxh_next; \
+ } while (0);
+
+ CALL_RXH(ieee80211_rx_h_passive_scan)
+ CALL_RXH(ieee80211_rx_h_check)
+
+ ieee80211_rx_reorder_ampdu(rx, &reorder_release);
+
+ ieee80211_rx_handlers(rx, &reorder_release);
+ return;
rxh_next:
- switch (res) {
- case RX_DROP_MONITOR:
- I802_DEBUG_INC(sdata->local->rx_handlers_drop);
- if (rx->sta)
- rx->sta->rx_dropped++;
- /* fall through */
- case RX_CONTINUE:
- ieee80211_rx_cooked_monitor(rx, rate);
- break;
- case RX_DROP_UNUSABLE:
- I802_DEBUG_INC(sdata->local->rx_handlers_drop);
- if (rx->sta)
- rx->sta->rx_dropped++;
- dev_kfree_skb(rx->skb);
- break;
- case RX_QUEUED:
- I802_DEBUG_INC(sdata->local->rx_handlers_queued);
- break;
- }
- }
+ ieee80211_rx_handlers_result(rx, res);
+
+#undef CALL_RXH
}
/* main receive path */
^ permalink raw reply related
* [PATCH 2/3 v2] mac80211: remove unused rate function parameter
From: Christian Lamparter @ 2010-08-04 23:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, John W. Linville
This patch removes a few stale parameters and variables
which survived the last, large rx-path reorganization:
"mac80211: correctly place aMPDU RX reorder code"
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
WIP -> v2:
- no changes
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index fccd5f7..118c2e2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -538,20 +538,12 @@ static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
int index,
struct sk_buff_head *frames)
{
- struct ieee80211_supported_band *sband;
- struct ieee80211_rate *rate = NULL;
struct sk_buff *skb = tid_agg_rx->reorder_buf[index];
- struct ieee80211_rx_status *status;
if (!skb)
goto no_frame;
- status = IEEE80211_SKB_RXCB(skb);
-
- /* release the reordered frames to stack */
- sband = hw->wiphy->bands[status->band];
- if (!(status->flag & RX_FLAG_HT))
- rate = &sband->bitrates[status->rate_idx];
+ /* release the frame from the reorder ring buffer */
tid_agg_rx->stored_mpdu_num--;
tid_agg_rx->reorder_buf[index] = NULL;
__skb_queue_tail(frames, skb);
@@ -2364,8 +2356,7 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
static void ieee80211_invoke_rx_handlers(struct ieee80211_sub_if_data *sdata,
struct ieee80211_rx_data *rx,
- struct sk_buff *skb,
- struct ieee80211_rate *rate)
+ struct sk_buff *skb)
{
struct sk_buff_head reorder_release;
ieee80211_rx_result res = RX_DROP_MONITOR;
@@ -2489,8 +2480,7 @@ static int prepare_for_handlers(struct ieee80211_sub_if_data *sdata,
* be called with rcu_read_lock protection.
*/
static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
- struct sk_buff *skb,
- struct ieee80211_rate *rate)
+ struct sk_buff *skb)
{
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
struct ieee80211_local *local = hw_to_local(hw);
@@ -2598,7 +2588,7 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
prev->name);
goto next;
}
- ieee80211_invoke_rx_handlers(prev, &rx, skb_new, rate);
+ ieee80211_invoke_rx_handlers(prev, &rx, skb_new);
next:
prev = sdata;
}
@@ -2614,7 +2604,7 @@ next:
}
}
if (prev)
- ieee80211_invoke_rx_handlers(prev, &rx, skb, rate);
+ ieee80211_invoke_rx_handlers(prev, &rx, skb);
else
dev_kfree_skb(skb);
}
@@ -2700,7 +2690,7 @@ void ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb)
return;
}
- __ieee80211_rx_handle_packet(hw, skb, rate);
+ __ieee80211_rx_handle_packet(hw, skb);
rcu_read_unlock();
^ permalink raw reply related
* [PATCH 3/3 v2] mac80211: AMPDU rx reorder timeout timer
From: Christian Lamparter @ 2010-08-04 23:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, John W. Linville
This patch introduces a new timer, which will release
queued-up MPDUs from the reorder buffer, whenever
they've waited for more than HT_RX_REORDER_BUF_TIMEOUT
(which is at around 100 ms).
The advantage of having a dedicated timer, instead of
relying on a constant stream of freshly arriving aMPDUs
to release the old ones, is particularly observable when
even a small fraction of MPDUs are forever lost at
low network speeds.
Previously under these circumstances frames would become
stuck in the reorder buffer and the network stack of both
HT peers throttled back, instead of revving up and
gunning the pipes.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
WIP -> v1:
- thread-safe ampdu reordering
- do the reorder release in the timer
v1 -> v2:
- update documentation entries
- refine locking
NB:
I hope the timed release stuff is now probably protected against
races from the RX - path. The code was tested and nothing blew up,
that said the testbed only had a puny single-core Pentium M engine...
But nevertheless, it managed to hold tcp speed high enough to
qualify as an 11n device (~ 60mbps) over the bad link.
---
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 965b272..58eab9e 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -86,6 +86,7 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
tid, 0, reason);
del_timer_sync(&tid_rx->session_timer);
+ del_timer_sync(&tid_rx->reorder_timer);
call_rcu(&tid_rx->rcu_head, ieee80211_free_tid_rx);
}
@@ -120,6 +121,20 @@ static void sta_rx_agg_session_timer_expired(unsigned long data)
ieee80211_queue_work(&sta->local->hw, &sta->ampdu_mlme.work);
}
+static void sta_rx_agg_reorder_timer_expired(unsigned long data)
+{
+ u8 *ptid = (u8 *)data;
+ u8 *timer_to_id = ptid - *ptid;
+ struct sta_info *sta = container_of(timer_to_id, struct sta_info,
+ timer_to_tid[0]);
+
+ rcu_read_lock();
+ spin_lock(&sta->lock);
+ ieee80211_release_reorder_timeout(sta, *ptid);
+ spin_unlock(&sta->lock);
+ rcu_read_unlock();
+}
+
static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *da, u16 tid,
u8 dialog_token, u16 status, u16 policy,
u16 buf_size, u16 timeout)
@@ -251,11 +266,18 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
goto end;
}
+ spin_lock_init(&tid_agg_rx->reorder_lock);
+
/* rx timer */
tid_agg_rx->session_timer.function = sta_rx_agg_session_timer_expired;
tid_agg_rx->session_timer.data = (unsigned long)&sta->timer_to_tid[tid];
init_timer(&tid_agg_rx->session_timer);
+ /* rx reorder timer */
+ tid_agg_rx->reorder_timer.function = sta_rx_agg_reorder_timer_expired;
+ tid_agg_rx->reorder_timer.data = (unsigned long)&sta->timer_to_tid[tid];
+ init_timer(&tid_agg_rx->reorder_timer);
+
/* prepare reordering buffer */
tid_agg_rx->reorder_buf =
kcalloc(buf_size, sizeof(struct sk_buff *), GFP_ATOMIC);
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 65e0ed6..0a46f8f 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1131,6 +1131,7 @@ void ieee80211_start_tx_ba_cb(struct ieee80211_vif *vif, u8 *ra, u16 tid);
void ieee80211_stop_tx_ba_cb(struct ieee80211_vif *vif, u8 *ra, u8 tid);
void ieee80211_ba_session_work(struct work_struct *work);
void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid);
+void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid);
/* Spectrum management */
void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 118c2e2..8c0044a 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -572,6 +572,8 @@ static void ieee80211_release_reorder_frames(struct ieee80211_hw *hw,
* frames that have not yet been received are assumed to be lost and the skb
* can be released for processing. This may also release other skb's from the
* reorder buffer if there are no additional gaps between the frames.
+ *
+ * Callers must hold tid_agg_rx->reorder_lock.
*/
#define HT_RX_REORDER_BUF_TIMEOUT (HZ / 10)
@@ -579,7 +581,7 @@ static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
struct tid_ampdu_rx *tid_agg_rx,
struct sk_buff_head *frames)
{
- int index;
+ int index, j;
/* release the buffer until next missing frame */
index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn) %
@@ -590,7 +592,6 @@ static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
* No buffers ready to be released, but check whether any
* frames in the reorder buffer have timed out.
*/
- int j;
int skipped = 1;
for (j = (index + 1) % tid_agg_rx->buf_size; j != index;
j = (j + 1) % tid_agg_rx->buf_size) {
@@ -600,7 +601,7 @@ static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
}
if (!time_after(jiffies, tid_agg_rx->reorder_time[j] +
HT_RX_REORDER_BUF_TIMEOUT))
- break;
+ goto set_release_timer;
#ifdef CONFIG_MAC80211_HT_DEBUG
if (net_ratelimit())
@@ -624,6 +625,25 @@ static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn) %
tid_agg_rx->buf_size;
}
+
+ if (tid_agg_rx->stored_mpdu_num) {
+ j = index = seq_sub(tid_agg_rx->head_seq_num,
+ tid_agg_rx->ssn) % tid_agg_rx->buf_size;
+
+ for (; j != (index - 1) % tid_agg_rx->buf_size;
+ j = (j + 1) % tid_agg_rx->buf_size) {
+ if (tid_agg_rx->reorder_buf[j])
+ break;
+ }
+
+ set_release_timer:
+
+ mod_timer(&tid_agg_rx->reorder_timer,
+ tid_agg_rx->reorder_time[j] +
+ HT_RX_REORDER_BUF_TIMEOUT);
+ } else {
+ del_timer(&tid_agg_rx->reorder_timer);
+ }
}
/*
@@ -641,14 +661,16 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
u16 mpdu_seq_num = (sc & IEEE80211_SCTL_SEQ) >> 4;
u16 head_seq_num, buf_size;
int index;
+ bool ret = true;
buf_size = tid_agg_rx->buf_size;
head_seq_num = tid_agg_rx->head_seq_num;
+ spin_lock(&tid_agg_rx->reorder_lock);
/* frame with out of date sequence number */
if (seq_less(mpdu_seq_num, head_seq_num)) {
dev_kfree_skb(skb);
- return true;
+ goto out;
}
/*
@@ -669,7 +691,7 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
/* check if we already stored this frame */
if (tid_agg_rx->reorder_buf[index]) {
dev_kfree_skb(skb);
- return true;
+ goto out;
}
/*
@@ -679,7 +701,8 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
if (mpdu_seq_num == tid_agg_rx->head_seq_num &&
tid_agg_rx->stored_mpdu_num == 0) {
tid_agg_rx->head_seq_num = seq_inc(tid_agg_rx->head_seq_num);
- return false;
+ ret = false;
+ goto out;
}
/* put the frame in the reordering buffer */
@@ -688,7 +711,9 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
tid_agg_rx->stored_mpdu_num++;
ieee80211_sta_reorder_release(hw, tid_agg_rx, frames);
- return true;
+ out:
+ spin_unlock(&tid_agg_rx->reorder_lock);
+ return ret;
}
/*
@@ -2387,6 +2412,37 @@ static void ieee80211_invoke_rx_handlers(struct ieee80211_sub_if_data *sdata,
#undef CALL_RXH
}
+/*
+ * This function makes calls into the RX path. Therefore the
+ * caller must hold the sta_info->lock and everything has to
+ * be under rcu_read_lock protection as well.
+ */
+void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid)
+{
+ struct sk_buff_head frames;
+ struct ieee80211_rx_data rx = { };
+
+ __skb_queue_head_init(&frames);
+
+ /* construct rx struct */
+ rx.sta = sta;
+ rx.sdata = sta->sdata;
+ rx.local = sta->local;
+ rx.queue = tid;
+ rx.flags |= IEEE80211_RX_RA_MATCH;
+
+ if (unlikely(test_bit(SCAN_HW_SCANNING, &sta->local->scanning) ||
+ test_bit(SCAN_OFF_CHANNEL, &sta->local->scanning)))
+ rx.flags |= IEEE80211_RX_IN_SCAN;
+
+ spin_lock(&sta->ampdu_mlme.tid_rx[tid]->reorder_lock);
+ ieee80211_sta_reorder_release(&sta->local->hw,
+ sta->ampdu_mlme.tid_rx[tid], &frames);
+ spin_unlock(&sta->ampdu_mlme.tid_rx[tid]->reorder_lock);
+
+ ieee80211_rx_handlers(&rx, &frames);
+}
+
/* main receive path */
static int prepare_for_handlers(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 54262e7..810c5ce 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -103,6 +103,7 @@ struct tid_ampdu_tx {
* @reorder_buf: buffer to reorder incoming aggregated MPDUs
* @reorder_time: jiffies when skb was added
* @session_timer: check if peer keeps Tx-ing on the TID (by timeout value)
+ * @reorder_timer: releases expired frames from the reorder buffer.
* @head_seq_num: head sequence number in reordering buffer.
* @stored_mpdu_num: number of MPDUs in reordering buffer
* @ssn: Starting Sequence Number expected to be aggregated.
@@ -110,20 +111,25 @@ struct tid_ampdu_tx {
* @timeout: reset timer value (in TUs).
* @dialog_token: dialog token for aggregation session
* @rcu_head: RCU head used for freeing this struct
+ * @reorder_lock: serializes access to reorder buffer, see below.
*
* This structure is protected by RCU and the per-station
* spinlock. Assignments to the array holding it must hold
- * the spinlock, only the RX path can access it under RCU
- * lock-free. The RX path, since it is single-threaded,
- * can even modify the structure without locking since the
- * only other modifications to it are done when the struct
- * can not yet or no longer be found by the RX path.
+ * the spinlock.
+ *
+ * The @reorder_lock is used to protect the variables and
+ * arrays such as @reorder_buf, @reorder_time, @head_seq_num,
+ * @stored_mpdu_num and @reorder_time from being corrupted by
+ * concurrent access of the RX path and the expired frame
+ * release timer.
*/
struct tid_ampdu_rx {
struct rcu_head rcu_head;
+ spinlock_t reorder_lock;
struct sk_buff **reorder_buf;
unsigned long *reorder_time;
struct timer_list session_timer;
+ struct timer_list reorder_timer;
u16 head_seq_num;
u16 stored_mpdu_num;
u16 ssn;
^ permalink raw reply related
* ath5k : Channel 149 thru 161 not working with compat-wireless-2.6.34.1
From: Gopal Raman @ 2010-08-05 0:15 UTC (permalink / raw)
To: linux-wireless
Hi
I have an internal ath5k (0x17AB:0x8331) NIC and with the old madwifi style
drivers (ath_pci ver 0.9.4.5) channels 149 thru 161 work fine. I'm able to rx/tx
frames.
With compat-wireless-2.6.34.1 running on 2.6.27.48 kernel, I can't receive (nor
tx) on channels 149 thru 161. The driver sets the channel without any errors.
But can't rx any frames. When I force transmit on these channels nothing is seen
on the air. Channels 36 thru 60 work fine
Is this a known issue ?
Thanks
-gopal
^ permalink raw reply
* Re: ath5k : Channel 149 thru 161 not working with compat-wireless-2.6.34.1
From: Gopal Raman @ 2010-08-05 0:57 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <loom.20100805T020816-848@post.gmane.org>
>
Gopal Raman <graman@...> writes:
Another piece of information is that when the channel is set to 149, 'cat
/proc/interrupts' hardly increments whereas on channel 36 it goes up
real fast. Also 'iw ph0 info' does show that channels 149 thru 161
in its output.
-gopal
^ permalink raw reply
* Re: ath5k : Channel 149 thru 161 not working with compat-wireless-2.6.34.1
From: Jonathan Guerin @ 2010-08-05 2:20 UTC (permalink / raw)
To: Gopal Raman; +Cc: linux-wireless
In-Reply-To: <loom.20100805T025322-892@post.gmane.org>
I found issues when switching to ath5k where the wrong antenna was selected.
Try forcing the antenna (especially if you don't have 1 of them
plugged in) and see how you go:
http://www.mail-archive.com/ath5k-devel@lists.ath5k.org/msg02979.html
Cheers,
--
Jonathan Guerin
On Thu, Aug 5, 2010 at 10:57 AM, Gopal Raman <graman@arubanetworks.com> wrote:
>
>
>>
>
> Gopal Raman <graman@...> writes:
>
> Another piece of information is that when the channel is set to 149, 'cat
> /proc/interrupts' hardly increments whereas on channel 36 it goes up
> real fast. Also 'iw ph0 info' does show that channels 149 thru 161
> in its output.
> -gopal
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: GIT: net-*2.6 rebased...
From: Stephen Rothwell @ 2010-08-05 4:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
In-Reply-To: <20100804.162141.15218463.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
Hi Dave,
On Wed, 04 Aug 2010 16:21:41 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> Please adhere to these rules, it helps keep the tree stable and
> preserve the limited sanity still remaining in folks like Stephen
> Rothwell. :-)
Now I am not sure if I should be insulted :-)
/me locks up all his sharp objects
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: GIT: net-*2.6 rebased...
From: Arnd Hannemann @ 2010-08-05 7:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless, sfr
In-Reply-To: <20100804.162141.15218463.davem@davemloft.net>
Hi,
Am 05.08.2010 01:21, schrieb David Miller:
>
> Both net-2.6 and net-next-2.6 have been rebased.
>
> To be honest, if you've been pulling from my tree you can just keep
> doing so if you want, it will look just as if I had merged Linus's
> tree into net-2.6 et al.
I there something broken with the trees on git.kernel.org?
if I try to fetch from net-next-2.6, I get:
fatal: The remote end hung up unexpectedly
if I try to clone net-2.6:
(e.g. git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
I get lots of errors reading the tags "does not point to a valid object!" and then:
remote: error: Could not read 3cfc2c42c1cbc8e238bb9c0612c0df4565e3a8b4
remote: fatal: Failed to traverse parents of commit 7aaaaa1e44b2a4047dfe05f304a5090eb995cf44
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
I'm using git version 1.7.1.
Best regards,
Arnd
^ permalink raw reply
* Re: GIT: net-*2.6 rebased...
From: Changli Gao @ 2010-08-05 8:02 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: David Miller, netdev, linux-wireless, sfr
In-Reply-To: <4C5A6EFE.7040703@arndnet.de>
On Thu, Aug 5, 2010 at 3:57 PM, Arnd Hannemann <arnd@arndnet.de> wrote:
> Hi,
>
> Am 05.08.2010 01:21, schrieb David Miller:
>>
>> Both net-2.6 and net-next-2.6 have been rebased.
>>
>> To be honest, if you've been pulling from my tree you can just keep
>> doing so if you want, it will look just as if I had merged Linus's
>> tree into net-2.6 et al.
>
> I there something broken with the trees on git.kernel.org?
>
> if I try to fetch from net-next-2.6, I get:
> fatal: The remote end hung up unexpectedly
>
> if I try to clone net-2.6:
> (e.g. git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
>
> I get lots of errors reading the tags "does not point to a valid object!" and then:
> remote: error: Could not read 3cfc2c42c1cbc8e238bb9c0612c0df4565e3a8b4
> remote: fatal: Failed to traverse parents of commit 7aaaaa1e44b2a4047dfe05f304a5090eb995cf44
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
>
> I'm using git version 1.7.1.
>
me 2 for net-next-2.6
localhost linux # git pull
fatal: The remote end hung up unexpectedly
localhost linux # git version
git version 1.7.1
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH] cfg80211: deauth doesn't always imply disconnect
From: Johannes Berg @ 2010-08-05 8:20 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
When an AP sends a deauth frame, or we send one
to an AP, that only means we lost our connection
if we were actually connected to that AP. Check
this to avoid sending spurious "disconnected"
events and breaking "iw ... link" reporting.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/mlme.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- wireless-testing.orig/net/wireless/mlme.c 2010-08-04 17:33:11.000000000 +0200
+++ wireless-testing/net/wireless/mlme.c 2010-08-04 23:01:37.000000000 +0200
@@ -149,7 +149,7 @@ void __cfg80211_send_deauth(struct net_d
struct ieee80211_mgmt *mgmt = (struct ieee80211_mgmt *)buf;
const u8 *bssid = mgmt->bssid;
int i;
- bool found = false;
+ bool found = false, was_current = false;
ASSERT_WDEV_LOCK(wdev);
@@ -159,6 +159,7 @@ void __cfg80211_send_deauth(struct net_d
cfg80211_put_bss(&wdev->current_bss->pub);
wdev->current_bss = NULL;
found = true;
+ was_current = true;
} else for (i = 0; i < MAX_AUTH_BSSES; i++) {
if (wdev->auth_bsses[i] &&
memcmp(wdev->auth_bsses[i]->pub.bssid, bssid, ETH_ALEN) == 0) {
@@ -183,7 +184,7 @@ void __cfg80211_send_deauth(struct net_d
nl80211_send_deauth(rdev, dev, buf, len, GFP_KERNEL);
- if (wdev->sme_state == CFG80211_SME_CONNECTED) {
+ if (wdev->sme_state == CFG80211_SME_CONNECTED && was_current) {
u16 reason_code;
bool from_ap;
^ permalink raw reply
* Re: GIT: net-*2.6 rebased...
From: David Miller @ 2010-08-05 8:46 UTC (permalink / raw)
To: arnd; +Cc: netdev, linux-wireless, sfr
In-Reply-To: <4C5A6EFE.7040703@arndnet.de>
From: Arnd Hannemann <arnd@arndnet.de>
Date: Thu, 05 Aug 2010 09:57:50 +0200
> if I try to fetch from net-next-2.6, I get:
> fatal: The remote end hung up unexpectedly
>
> if I try to clone net-2.6:
> (e.g. git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
>
> I get lots of errors reading the tags "does not point to a valid object!" and then:
> remote: error: Could not read 3cfc2c42c1cbc8e238bb9c0612c0df4565e3a8b4
> remote: fatal: Failed to traverse parents of commit 7aaaaa1e44b2a4047dfe05f304a5090eb995cf44
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
Hmmm, since I can I tried an ssh based clone and it works.
But indeed if I try to use the git:// URL it fails.
Oh I see, the alternates files in those repos are completely broken.
They have:
/home/davem/git/../torvalds/linux-2.6.git/objects
/home/davem/git is a symlink to /pub/scm/linux/kernel/git/davem
so if I login and "cd git" then:
git clone --shared --bare ../torvalds/linux-2.6.git net-next-2.6.git
which is how I always create my trees, we get that unusable 'alternates'
path above.
The ".." works when my GIT directory is the working directory, but
not as part of the symlink include path to get there.
I fixed the alternates file but it will take some time for the fix
to propagate from master.kernel.org
Let me know if it doesn't work even after an hour or so.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3 v2] mac80211: AMPDU rx reorder timeout timer
From: Johannes Berg @ 2010-08-05 9:04 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John W. Linville
In-Reply-To: <201008050136.41821.chunkeey@googlemail.com>
On Thu, 2010-08-05 at 01:36 +0200, Christian Lamparter wrote:
> This patch introduces a new timer, which will release
> queued-up MPDUs from the reorder buffer, whenever
> they've waited for more than HT_RX_REORDER_BUF_TIMEOUT
> (which is at around 100 ms).
>
> The advantage of having a dedicated timer, instead of
> relying on a constant stream of freshly arriving aMPDUs
> to release the old ones, is particularly observable when
> even a small fraction of MPDUs are forever lost at
> low network speeds.
>
> Previously under these circumstances frames would become
> stuck in the reorder buffer and the network stack of both
> HT peers throttled back, instead of revving up and
> gunning the pipes.
>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
> WIP -> v1:
> - thread-safe ampdu reordering
> - do the reorder release in the timer
>
> v1 -> v2:
> - update documentation entries
> - refine locking
>
> NB:
> I hope the timed release stuff is now probably protected against
> races from the RX - path. The code was tested and nothing blew up,
> that said the testbed only had a puny single-core Pentium M engine...
>
> But nevertheless, it managed to hold tcp speed high enough to
> qualify as an 11n device (~ 60mbps) over the bad link.
This set looks fine to me. I may do some cleanup afterwards wrt. the rx
struct :-)
johannes
^ permalink raw reply
* Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Jens Axboe @ 2010-08-05 9:02 UTC (permalink / raw)
To: Tejun Heo
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Maciej Rutecki,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI, Linus Torvalds, stable@kernel.org
In-Reply-To: <4C598E6B.7050405@gmail.com>
On 2010-08-04 17:59, Tejun Heo wrote:
> bd_prepare_to_claim() incorrectly allowed multiple attempts for
> exclusive open to progress in parallel if the attempting holders are
> identical. This triggered BUG_ON() as reported in the following bug.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16393
>
> __bd_abort_claiming() is used to finish claiming blocks and doesn't
> work if multiple openers are inside a claiming block. Allowing
> multiple parallel open attempts to continue doesn't gain anything as
> those are serialized down in the call chain anyway. Fix it by always
> allowing only single open attempt in a claiming block.
>
> This problem can easily be reproduced by adding a delay after
> bd_prepare_to_claim() and attempting to mount two partitions of a
> disk.
>
> stable: only applicable to v2.6.35
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
> Cc: stable@kernel.org
Thanks Tejun, applied.
--
Jens Axboe
Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
^ permalink raw reply
* Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Jens Axboe @ 2010-08-05 9:20 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Tejun Heo, Rafael J. Wysocki, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI, Linus Torvalds, stable@kernel.org
In-Reply-To: <20100805091704.GA1772@arch.tripp.de>
On 2010-08-05 11:17, Markus Trippelsdorf wrote:
> On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
>> On 2010-08-04 17:59, Tejun Heo wrote:
>>> bd_prepare_to_claim() incorrectly allowed multiple attempts for
>>> exclusive open to progress in parallel if the attempting holders are
>>> identical. This triggered BUG_ON() as reported in the following bug.
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=16393
>>>
>>> __bd_abort_claiming() is used to finish claiming blocks and doesn't
>>> work if multiple openers are inside a claiming block. Allowing
>>> multiple parallel open attempts to continue doesn't gain anything as
>>> those are serialized down in the call chain anyway. Fix it by always
>>> allowing only single open attempt in a claiming block.
>>>
>>> This problem can easily be reproduced by adding a delay after
>>> bd_prepare_to_claim() and attempting to mount two partitions of a
>>> disk.
>>>
>>> stable: only applicable to v2.6.35
>>>
>>> Signed-off-by: Tejun Heo <tj@kernel.org>
>>> Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
>>> Cc: stable@kernel.org
>>
>> Thanks Tejun, applied.
>
> It's already in mainline:
> e75aa85892b2ee78c79edac720868cbef16e62eb
Irk, had not noticed yet, my for-2.6.36 branch isn't fully merged
up yet. Thanks for the heads-up.
--
Jens Axboe
Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
^ permalink raw reply
* Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Markus Trippelsdorf @ 2010-08-05 9:17 UTC (permalink / raw)
To: Jens Axboe
Cc: Tejun Heo, Rafael J. Wysocki, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI, Linus Torvalds, stable@kernel.org
In-Reply-To: <4C5A7E33.3060101@fusionio.com>
On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
> On 2010-08-04 17:59, Tejun Heo wrote:
> > bd_prepare_to_claim() incorrectly allowed multiple attempts for
> > exclusive open to progress in parallel if the attempting holders are
> > identical. This triggered BUG_ON() as reported in the following bug.
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=16393
> >
> > __bd_abort_claiming() is used to finish claiming blocks and doesn't
> > work if multiple openers are inside a claiming block. Allowing
> > multiple parallel open attempts to continue doesn't gain anything as
> > those are serialized down in the call chain anyway. Fix it by always
> > allowing only single open attempt in a claiming block.
> >
> > This problem can easily be reproduced by adding a delay after
> > bd_prepare_to_claim() and attempting to mount two partitions of a
> > disk.
> >
> > stable: only applicable to v2.6.35
> >
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
> > Cc: stable@kernel.org
>
> Thanks Tejun, applied.
It's already in mainline:
e75aa85892b2ee78c79edac720868cbef16e62eb
--
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
^ permalink raw reply
* [ath9k]: Beaconing process in ad-hoc mode
From: Jónatan Muñoz @ 2010-08-05 11:55 UTC (permalink / raw)
To: linux-wireless
Dear All,
I am working in a project where I need to modified the currently beaconing
system for adhoc mode in ath9k, what I want to achieve is that each station
in an adhoc network send periodically a beacon. As I know, when a station in
the network receives a beacon before sending its own beacon, cancels the
transmission, updates its hw tsf based on the received beacon and waits for
a chance to send the beacon during next TBTT.
For my goal, I think that I should comment the part where the transmission
of the beacon is cancelled. In this way, each station will send a beacon
each 100TU (~100 ms). I know that this mean a increased traffic load on the
network, but it is so much important for the project to obtain a beacon for
each station each 100ms.
Right now, I am looking at the source code of ath9k, I am trying to modify
the file beacon.c, but I don’t find the way to get my purpose. Could anyone
help me to find the right place at the code that I have to modify? I am a
bit lost and any help would be greatly appreciated.
Thanks in advance.
PD: Please excuse my poor English
John
------------------------------------------
Jónatan Muñoz
Email: jmunoz@umh.es
Ubiquitous Wireless Communications Research Laboratory
Uwicore, http://www.uwicore.umh.es
Signal Theory and Communications Division
University Miguel Hernández of Elche
Avenida de la Universidad s/n
Edificio Quorum V P2 012
03202, Elche (Alicante)
Spain
Tel: +34 96522 2031 /+34 669256708
Fax: +34 96665 8903
------------------------------------------
^ permalink raw reply
* bdm 4353 802.11n monitor mode you can?
From: Arthur Moreira @ 2010-08-05 11:57 UTC (permalink / raw)
To: linux-wireless
Someone can put the broadcom card 802.11n bcmw 4353 in monitor mode?
Arthur Moreira
^ permalink raw reply
* [PATCH 11/15] net: mac80211: Fix a typo.
From: Andrea Gelmini @ 2010-08-05 13:51 UTC (permalink / raw)
To: gelma
Cc: Andrea Gelmini, Stefano Brivio, Mattias Nissler, John W. Linville,
Johannes Berg, David S. Miller, Stephen Hemminger,
Alexey Dobriyan, Tejun Heo, linux-wireless, netdev
In-Reply-To: <1281016299-23958-1-git-send-email-andrea.gelmini@gelma.net>
"userpace" -> "userspace"
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
net/mac80211/rc80211_pid_debugfs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_pid_debugfs.c b/net/mac80211/rc80211_pid_debugfs.c
index 47438b4..135f36f 100644
--- a/net/mac80211/rc80211_pid_debugfs.c
+++ b/net/mac80211/rc80211_pid_debugfs.c
@@ -162,7 +162,7 @@ static ssize_t rate_control_pid_events_read(struct file *file, char __user *buf,
file_info->next_entry = (file_info->next_entry + 1) %
RC_PID_EVENT_RING_SIZE;
- /* Print information about the event. Note that userpace needs to
+ /* Print information about the event. Note that userspace needs to
* provide large enough buffers. */
length = length < RC_PID_PRINT_BUF_SIZE ?
length : RC_PID_PRINT_BUF_SIZE;
--
1.7.2.1.85.g2d089
^ permalink raw reply related
* Re: bdm 4353 802.11n monitor mode you can?
From: Larry Finger @ 2010-08-05 13:54 UTC (permalink / raw)
To: Arthur Moreira; +Cc: wireless
In-Reply-To: <AANLkTi=Q7FXWnH9dyH3mPX7G+JDBNVb0NWuYjqd_VN2F@mail.gmail.com>
On 08/05/2010 06:57 AM, Arthur Moreira wrote:
> Someone can put the broadcom card 802.11n bcmw 4353 in monitor mode?
The Broadcom wl hybrid driver does not support monitor mode, and that is the
only driver for 802.11n Broadcom chips. Until we finish getting b43 running on
such devices, you will not have that option.
Complain to Broadcom.
Larry
^ 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