* [PATCH v2 1/2] mac80211: add offload channel switch support
From: wey-yi.w.guy @ 2010-05-06 15:25 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Wey-Yi Guy
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Adding support to offload the channel switch operation to driver if
driver can support the function.
The original approach, mac80211 utilize the mac_config callback function
and set the CHANNEL_CHANGE flag which is difficult to separate the true
channel switch request from all the other channel changes condition;
with this offload approach, driver has more control on how to handle the
channel switch request from AP, also can provide more accurate timing
calculation
The drivers like to support the channel switch offloading function will have
to provide the mactime information (at least for mgmt and action frames)
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
v2: use "mactime" instead of timestamp in the frame body, the driver has to provide the mactime if need to support the channel switch function
---
include/net/mac80211.h | 32 ++++++++++++++++++++++++++++
net/mac80211/driver-ops.h | 11 +++++++++
net/mac80211/driver-trace.h | 49 +++++++++++++++++++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/mlme.c | 48 ++++++++++++++++++++++++++++++++++++++---
5 files changed, 138 insertions(+), 5 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 2879c8e..dc5ae23 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -708,6 +708,26 @@ struct ieee80211_conf {
};
/**
+ * struct ieee80211_channel_switch - holds the channel switch data
+ *
+ * The information provided in this structure is required for channel switch
+ * operation.
+ *
+ * @timestamp: value in microseconds of the 64-bit Time Synchronization
+ * Function (TSF) timer when the channel switch ie received.
+ * @block_tx: set to true if no more future frames transmission within the BSS
+ * until the scheduled channel switch
+ * @channel: pointer to ieee80211_channel contain then new channel information
+ * @count: specified the number of TBTT's until the channel switch event.
+ */
+struct ieee80211_channel_switch {
+ u64 timestamp;
+ bool block_tx;
+ struct ieee80211_channel *channel;
+ u8 count;
+};
+
+/**
* struct ieee80211_vif - per-interface data
*
* Data in this structure is continually present for driver
@@ -1694,6 +1714,8 @@ struct ieee80211_ops {
int (*testmode_cmd)(struct ieee80211_hw *hw, void *data, int len);
#endif
void (*flush)(struct ieee80211_hw *hw, bool drop);
+ void (*channel_switch)(struct ieee80211_hw *hw,
+ struct ieee80211_channel_switch *ch_switch);
};
/**
@@ -2444,6 +2466,16 @@ void ieee80211_cqm_rssi_notify(struct ieee80211_vif *vif,
enum nl80211_cqm_rssi_threshold_event rssi_event,
gfp_t gfp);
+/**
+ * ieee80211_chswitch_done - Complete channel switch process
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ * @is_seccess: make the channel switch successful or not
+ *
+ * Complete the channel switch post-process: set the new operational channel
+ * and wake up the suspended queues.
+ */
+void ieee80211_chswitch_done(struct ieee80211_vif *vif, bool is_success);
+
/* Rate control API */
/**
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 997008e..5662bb5 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -373,4 +373,15 @@ static inline void drv_flush(struct ieee80211_local *local, bool drop)
if (local->ops->flush)
local->ops->flush(&local->hw, drop);
}
+
+static inline void drv_channel_switch(struct ieee80211_local *local,
+ struct ieee80211_channel_switch *ch_switch)
+{
+ might_sleep();
+
+ local->ops->channel_switch(&local->hw, ch_switch);
+
+ trace_drv_channel_switch(local, ch_switch);
+}
+
#endif /* __MAC80211_DRIVER_OPS */
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index ce734b5..cd1ae9f 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -774,6 +774,34 @@ TRACE_EVENT(drv_flush,
)
);
+TRACE_EVENT(drv_channel_switch,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_channel_switch *ch_switch),
+
+ TP_ARGS(local, ch_switch),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ __field(u64, timestamp)
+ __field(bool, block_tx)
+ __field(u16, freq)
+ __field(u8, count)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ __entry->timestamp = ch_switch->timestamp;
+ __entry->block_tx = ch_switch->block_tx;
+ __entry->freq = ch_switch->channel->center_freq;
+ __entry->count = ch_switch->count;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT " new freq:%u count:%d",
+ LOCAL_PR_ARG, __entry->freq, __entry->count
+ )
+);
+
/*
* Tracing for API calls that drivers call.
*/
@@ -992,6 +1020,27 @@ TRACE_EVENT(api_sta_block_awake,
)
);
+TRACE_EVENT(api_chswitch_done,
+ TP_PROTO(struct ieee80211_sub_if_data *sdata, bool is_success),
+
+ TP_ARGS(sdata, is_success),
+
+ TP_STRUCT__entry(
+ VIF_ENTRY
+ __field(bool, is_success)
+ ),
+
+ TP_fast_assign(
+ VIF_ASSIGN;
+ __entry->is_success = is_success;
+ ),
+
+ TP_printk(
+ VIF_PR_FMT " chswitch:%d",
+ VIF_PR_ARG, __entry->is_success
+ )
+);
+
/*
* Tracing for internal functions
* (which may also be called in response to driver calls)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4e73660..be9dda9 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -999,7 +999,8 @@ int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
- struct ieee80211_bss *bss);
+ struct ieee80211_bss *bss,
+ u64 timestamp);
void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 358226f..19b53a8 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -340,7 +340,11 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
sdata->local->oper_channel = sdata->local->csa_channel;
- ieee80211_hw_config(sdata->local, IEEE80211_CONF_CHANGE_CHANNEL);
+ if (!sdata->local->ops->channel_switch) {
+ /* call "hw_config" only if doing sw channel switch */
+ ieee80211_hw_config(sdata->local,
+ IEEE80211_CONF_CHANGE_CHANNEL);
+ }
/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->local->oper_channel;
@@ -352,6 +356,22 @@ static void ieee80211_chswitch_work(struct work_struct *work)
mutex_unlock(&ifmgd->mtx);
}
+void ieee80211_chswitch_done(struct ieee80211_vif *vif, bool is_success)
+{
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+
+ sdata = vif_to_sdata(vif);
+ ifmgd = &sdata->u.mgd;
+
+ trace_api_chswitch_done(sdata, is_success);
+ if (!is_success)
+ sdata->local->csa_channel = sdata->local->oper_channel;
+
+ ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
+}
+EXPORT_SYMBOL(ieee80211_chswitch_done);
+
static void ieee80211_chswitch_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
@@ -368,7 +388,8 @@ static void ieee80211_chswitch_timer(unsigned long data)
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
- struct ieee80211_bss *bss)
+ struct ieee80211_bss *bss,
+ u64 timestamp)
{
struct cfg80211_bss *cbss =
container_of((void *)bss, struct cfg80211_bss, priv);
@@ -396,6 +417,23 @@ void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
sdata->local->csa_channel = new_ch;
+ if (sdata->local->ops->channel_switch) {
+ /* use driver's channel switch callback */
+ struct ieee80211_channel_switch ch_switch;
+ memset(&ch_switch, 0, sizeof(ch_switch));
+ ch_switch.timestamp = timestamp;
+ if (sw_elem->mode) {
+ ch_switch.block_tx = true;
+ ieee80211_stop_queues_by_reason(&sdata->local->hw,
+ IEEE80211_QUEUE_STOP_REASON_CSA);
+ }
+ ch_switch.channel = new_ch;
+ ch_switch.count = sw_elem->count;
+ ifmgd->flags |= IEEE80211_STA_CSA_RECEIVED;
+ drv_channel_switch(sdata->local, &ch_switch);
+ return;
+ }
+ /* mac80211 handle channel switch */
if (sw_elem->count <= 1) {
ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
} else {
@@ -1315,7 +1353,8 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
ETH_ALEN) == 0)) {
struct ieee80211_channel_sw_ie *sw_elem =
(struct ieee80211_channel_sw_ie *)elems->ch_switch_elem;
- ieee80211_sta_process_chanswitch(sdata, sw_elem, bss);
+ ieee80211_sta_process_chanswitch(sdata, sw_elem,
+ bss, rx_status->mactime);
}
}
@@ -1647,7 +1686,8 @@ static void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
ieee80211_sta_process_chanswitch(sdata,
&mgmt->u.action.u.chan_switch.sw_elem,
- (void *)ifmgd->associated->priv);
+ (void *)ifmgd->associated->priv,
+ rx_status->mactime);
break;
}
mutex_unlock(&ifmgd->mtx);
--
1.5.6.3
^ permalink raw reply related
* Re: 2.6.33.2: Turn tx power off/on for Atheros card
From: Yegor Yefremov @ 2010-05-06 14:52 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev
In-Reply-To: <r2xf69abfc31005050326oe123cb60s131ab4969341ef57@mail.gmail.com>
On Wed, May 5, 2010 at 12:26 PM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> I'm using kernel 2.6.33.2 with AR2413 WLAN card. Issuing
>
> iwconfig wlan0 txpower off
>
> turns txpower off. I can see this status by iwconfig wlan0 and the
> communication with AP terminates. But when I turn the txpower on
>
> iwconfig wlan0 txpower on
>
> nothing happens. Though iwconfig shows the previous tx power value.
> Only ifconfig wlan0 down and then up recovers the transmission.
>
> Is it a known bug or I'm doing something wrong?
I made some debugging and found out that after iwconfig wlan0 txpower
off dev_close() will be invoked, so that local->open_count will be 0.
The next time txpower on will be called, it will be checked if
local->open_count > 0 and this conditions fails, so no hardware
configuration will be made.
I've made a quick and dirty hack, that opens the wireless device by
enabling the txpower, if it was closed before. Is there any proper
solution? Is it really necessary to close device to tunr txpower off?
Best regards,
Yegor
Index: b/net/wireless/wext-compat.c
===================================================================
--- a/net/wireless/wext-compat.c 2010-04-30 05:02:05.000000000 +0200
+++ b/net/wireless/wext-compat.c 2010-05-06 16:31:20.000000000 +0200
@@ -15,6 +15,7 @@
#include <linux/slab.h>
#include <net/iw_handler.h>
#include <net/cfg80211.h>
+#include "../mac80211/ieee80211_i.h"
#include "wext-compat.h"
#include "core.h"
@@ -824,6 +825,7 @@
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+ struct ieee80211_local *local = wiphy_priv(wdev->wiphy);
enum tx_power_setting type;
int dbm = 0;
@@ -861,6 +863,8 @@
type = TX_POWER_LIMITED;
}
}
+ if(!local->open_count)
+ dev_open(wdev->netdev);
} else {
rfkill_set_sw_state(rdev->rfkill, true);
schedule_work(&rdev->rfkill_sync);
^ permalink raw reply
* Re: 2.6.34-rc6 pci bridge problems
From: Bjorn Helgaas @ 2010-05-06 15:09 UTC (permalink / raw)
To: Christian Lamparter; +Cc: dhlii, linux-wireless, linux-kernel, linux-pci
In-Reply-To: <201005052159.55871.chunkeey@googlemail.com>
On Wednesday, May 05, 2010 01:59:55 pm Christian Lamparter wrote:
> On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> > When I build out of the wireless-testing git tree (puled today)
> > 2.6.34-rc6 using my current systems .config I get a very quick error
> > on boot about PCI bridge windows.
> > googling the error indicates this is a know 2.6.34 problem and that
> > there are fixes in other 2.6.34 trees.
> > I have been unable to find the actual patches or I would just apply
> > them to wireless-testing.
I made significant changes in the way we handle PCI bridge windows,
and I'm eager to fix any issues in that area. But "very quick error
on boot" doesn't give me any information to work with.
Please attach your complete dmesg output, serial console log (with
"ignore_loglevel"), digital photo of the error, or other specific
details.
Bjorn
^ permalink raw reply
* b43: force_pio must be set in your kernel conf
From: Jan Engelhardt @ 2010-05-06 15:16 UTC (permalink / raw)
To: linux-wireless
Hi,
I have here some typical windowscentric Dell laptop with a b43 chipset
that refuses to work due to something with DMA.
lspci:
08:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev
01)
08:00.0 0280: 14e4:4315 (rev 01)
I installed the firmware using one of opensuse's scripts
(install_bcm43xx_firmware, though it handles b43 and b43legacy according
to the script's inner comments), which retrieves
wl_apsta_mimo.o from
mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
and runs fwcutter on it. In dmesg, I then find on modprobe b43
verbose=3:
b43 ssb0:0: firmware: requesting b43/ucode15.fw
b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
b43-phy0 debug: Chip initialized
b43-phy0 debug: 64-bit DMA initialized
b43-phy0 debug: QoS enabled
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
b43-phy0 ERROR: Fatal DMA error: 0x400, 0x0, 0x0, 0x0, 0x0, 0x0
b43-phy0 ERROR: This device does not support DMA on your system. Please
use PIO instead.
b43-phy0 ERROR: CONFIG_B43_FORCE_PIO must be set in your kernel
configuration.
ADDRCONF(NETDEV_UP): wlan0: link is not ready
So, can I get PIO mode for free without recompiling? (Since
CONFIG_B43_PIO=y already.) What other info needs to be provided to help
resolve this?
System is a 2.6.33.2-x86_64.
thanks,
Jan
^ permalink raw reply
* Re: b43: force_pio must be set in your kernel conf
From: Larry Finger @ 2010-05-06 15:36 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-wireless
In-Reply-To: <alpine.LSU.2.01.1005061707140.32387@obet.zrqbmnf.qr>
On 05/06/2010 10:16 AM, Jan Engelhardt wrote:
> Hi,
>
>
> I have here some typical windowscentric Dell laptop with a b43 chipset
> that refuses to work due to something with DMA.
>
> lspci:
> 08:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev
> 01)
> 08:00.0 0280: 14e4:4315 (rev 01)
>
> I installed the firmware using one of opensuse's scripts
> (install_bcm43xx_firmware, though it handles b43 and b43legacy according
> to the script's inner comments), which retrieves
>
> wl_apsta_mimo.o from
> mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
>
> and runs fwcutter on it. In dmesg, I then find on modprobe b43
> verbose=3:
>
> b43 ssb0:0: firmware: requesting b43/ucode15.fw
> b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
> b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
> b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
> b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
> b43-phy0 debug: Chip initialized
> b43-phy0 debug: 64-bit DMA initialized
> b43-phy0 debug: QoS enabled
> b43-phy0 debug: Wireless interface started
> b43-phy0 debug: Adding Interface type 2
> b43-phy0 ERROR: Fatal DMA error: 0x400, 0x0, 0x0, 0x0, 0x0, 0x0
> b43-phy0 ERROR: This device does not support DMA on your system. Please
> use PIO instead.
> b43-phy0 ERROR: CONFIG_B43_FORCE_PIO must be set in your kernel
> configuration.
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
>
>
> So, can I get PIO mode for free without recompiling? (Since
> CONFIG_B43_PIO=y already.) What other info needs to be provided to help
> resolve this?
>
> System is a 2.6.33.2-x86_64.
In the latest mainline kernel (2.6.34-rc6), the fallback to PIO is
automatic. For a 2.6.33 kernel, you will need to rebuild the kernel or
install the latest compat-wireless package. Your distro may already
provide it.
We are working on this problem. Keep watching this list for trial
patches. Unfortunately, none of the developers have a machine that
suffers from this problem. It seems to be associated with Intel
processors (mostly netbooks with Atom chips) and the Phoenix BIOS.
Larry
^ permalink raw reply
* Re: [PATCH] iwlwifi: recalculate average tpt if not current
From: reinette chatre @ 2010-05-06 16:11 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
Adel Gadllah
In-Reply-To: <1272909307.7879.5759.camel@rchatre-DESK>
Hi John,
On Mon, 2010-05-03 at 10:55 -0700, reinette chatre wrote:
> From: Reinette Chatre <reinette.chatre@intel.com>
>
> We currently have this check as a BUG_ON, which is being hit by people.
> Previously it was an error with a recalculation if not current, return that
> code.
>
> The BUG_ON was introduced by:
> commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
> Author: Guy Cohen <guy.cohen@intel.com>
> Date: Tue Sep 9 10:54:54 2008 +0800
>
> iwlwifi: Added support for 3 antennas
>
> ... the portion adding the BUG_ON is reverted since we are encountering the error
> and BUG_ON was created with assumption that error is not encountered.
>
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> ---
I noticed this patch in your wireless-next-2.6 pull request. Since it is
addressing a system hang issue, could it perhaps be included in
wireless-2.6 also? I should have included the bug report reference for
this purpose, sorry ... it is
https://bugzilla.redhat.com/show_bug.cgi?id=588021
Reinette
^ permalink raw reply
* Re: kernel BUG in iwl-agn-rs.c:2076, WAS: iwlagn + some accesspoint == hardlock
From: reinette chatre @ 2010-05-06 16:28 UTC (permalink / raw)
To: Christian Borntraeger
Cc: John W. Linville, NilsRadtkelkml@think-future.de,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <201005061114.35480.borntraeger@de.ibm.com>
Hi Christian,
On Thu, 2010-05-06 at 02:14 -0700, Christian Borntraeger wrote:
> Am Montag 03 Mai 2010 21:22:19 schrieb John W. Linville:
> > > /* Sanity-check TPT calculations */
> > > BUG_ON(window->average_tpt != ((window->success_ratio *
> > > tbl->expected_tpt[index] + 64) / 128));
> >
> > Interestingly enough, we have been discussing this line of code today. Could you try the patch here?
> >
> > http://marc.info/?l=linux-wireless&m=127290931304496&w=2
>
> I also see a hard lockup some time after connection to my companies
> wireless network. My private network does not seem to trigger that bug.
> Unfortunately the kernel is not able to switch back graphics, so I
> cannot tell if I see the same BUG - even if the problem description is
> the same.
It will be hard to debug this without some logs. Can you perhaps run
with netconsole for a while? Is it possible to trigger this when not in
X to be able to get some information about where issue is?
> For reference, the patch above does not help on my T61p.
>
> It started soon after 2.6.34-rc4. Before and with rc4 I had to
> apply this http://patchwork.ozlabs.org/patch/49850/mbox/ patch to avoid
> the other crash. With only this patch on top of rc4 everything seemed to
> work fine, so the lockup seems to be triggered by one of the other patches.
> Sometimes it takes some minutes to crash, which makes it hard to bisect
> the problem.
Below seven iwlwifi patches were added after rc4. If you are unable to
bisect ... perhaps you can run a while by reverting more and more from
this list?
f2fa1b015e9c199e45c836c769d94db595150731 iwlwifi: correct 6000 EEPROM regulatory address
88be026490ed89c2ffead81a52531fbac5507e01 iwlwifi: fix scan races
8b9fce77737ae9983f61ec56cd53f52fb738b2c7 iwlwifi: work around bogus active chains detection
ece6444c2fe80dab679beb5f0d58b091f1933b00 iwlwifi: need check for valid qos packet before free
de0f60ea94e132c858caa64a44b2012e1e8580b0 iwlwifi: avoid Tx queue memory allocation in interface down
04f2dec1c3d375c4072613880f28f43b66524876 iwlwifi: use consistent table for tx data collect
dd48744964296b5713032ea1d66eb9e3d990e287 iwlwifi: fix DMA allocation warnings
Reinette
^ permalink raw reply
* Re: [PATCH] rt2x00: Fix RF3052 channel initialization
From: Gertjan van Wingerde @ 2010-05-06 16:49 UTC (permalink / raw)
To: Ivo van Doorn, John Linville; +Cc: linux-wireless, users
In-Reply-To: <201005061445.47170.IvDoorn@gmail.com>
On 05/06/10 14:45, Ivo van Doorn wrote:
> Update channel initialization for the RF3052 chipset.
> According to the Ralink drivers, the rt3x array must be
> used for this chipset, rather then the rt2x array.
>
> Furthermore RF3052 supports the 5GHz band, extend
> the rt3x array with the 5GHz channels, and use them
> for the RF3052 chip.
>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 67 ++++++++++++++++++++++++++----
> 1 files changed, 58 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index e37bbea..6c0abc3 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -2219,7 +2219,7 @@ int rt2800_init_eeprom(struct rt2x00_dev *rt2x00dev)
> EXPORT_SYMBOL_GPL(rt2800_init_eeprom);
>
> /*
> - * RF value list for rt28x0
> + * RF value list for rt28xx
> * Supports: 2.4 GHz (all) & 5.2 GHz (RF2850 & RF2750)
> */
> static const struct rf_channel rf_vals[] = {
> @@ -2294,10 +2294,10 @@ static const struct rf_channel rf_vals[] = {
> };
>
> /*
> - * RF value list for rt3070
> - * Supports: 2.4 GHz
> + * RF value list for rt3xxx
> + * Supports: 2.4 GHz (all) & 5.2 GHz (RF3052)
> */
> -static const struct rf_channel rf_vals_302x[] = {
> +static const struct rf_channel rf_vals_3x[] = {
> {1, 241, 2, 2 },
> {2, 241, 2, 7 },
> {3, 242, 2, 2 },
> @@ -2312,6 +2312,51 @@ static const struct rf_channel rf_vals_302x[] = {
> {12, 246, 2, 7 },
> {13, 247, 2, 2 },
> {14, 248, 2, 4 },
> +
> + /* 802.11 UNI / HyperLan 2 */
> + {36, 0x56, 0, 4},
> + {38, 0x56, 0, 6},
> + {40, 0x56, 0, 8},
> + {44, 0x57, 0, 0},
> + {46, 0x57, 0, 2},
> + {48, 0x57, 0, 4},
> + {52, 0x57, 0, 8},
> + {54, 0x57, 0, 10},
> + {56, 0x58, 0, 0},
> + {60, 0x58, 0, 4},
> + {62, 0x58, 0, 6},
> + {64, 0x58, 0, 8},
> +
> + /* 802.11 HyperLan 2 */
> + {100, 0x5b, 0, 8},
> + {102, 0x5b, 0, 10},
> + {104, 0x5c, 0, 0},
> + {108, 0x5c, 0, 4},
> + {110, 0x5c, 0, 6},
> + {112, 0x5c, 0, 8},
> + {116, 0x5d, 0, 0},
> + {118, 0x5d, 0, 2},
> + {120, 0x5d, 0, 4},
> + {124, 0x5d, 0, 8},
> + {126, 0x5d, 0, 10},
> + {128, 0x5e, 0, 0},
> + {132, 0x5e, 0, 4},
> + {134, 0x5e, 0, 6},
> + {136, 0x5e, 0, 8},
> + {140, 0x5f, 0, 0},
> +
> + /* 802.11 UNII */
> + {149, 0x5f, 0, 9},
> + {151, 0x5f, 0, 11},
> + {153, 0x60, 0, 1},
> + {157, 0x60, 0, 5},
> + {159, 0x60, 0, 7},
> + {161, 0x60, 0, 9},
> + {165, 0x61, 0, 1},
> + {167, 0x61, 0, 3},
> + {169, 0x61, 0, 5},
> + {171, 0x61, 0, 7},
> + {173, 0x61, 0, 9},
> };
>
> int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> @@ -2352,11 +2397,11 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> spec->supported_rates = SUPPORT_RATE_CCK | SUPPORT_RATE_OFDM;
>
> if (rt2x00_rf(rt2x00dev, RF2820) ||
> - rt2x00_rf(rt2x00dev, RF2720) ||
> - rt2x00_rf(rt2x00dev, RF3052)) {
> + rt2x00_rf(rt2x00dev, RF2720)) {
> spec->num_channels = 14;
> spec->channels = rf_vals;
> - } else if (rt2x00_rf(rt2x00dev, RF2850) || rt2x00_rf(rt2x00dev, RF2750)) {
> + } else if (rt2x00_rf(rt2x00dev, RF2850) ||
> + rt2x00_rf(rt2x00dev, RF2750)) {
> spec->supported_bands |= SUPPORT_BAND_5GHZ;
> spec->num_channels = ARRAY_SIZE(rf_vals);
> spec->channels = rf_vals;
> @@ -2364,8 +2409,12 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> rt2x00_rf(rt2x00dev, RF2020) ||
> rt2x00_rf(rt2x00dev, RF3021) ||
> rt2x00_rf(rt2x00dev, RF3022)) {
> - spec->num_channels = ARRAY_SIZE(rf_vals_302x);
> - spec->channels = rf_vals_302x;
> + spec->num_channels = 14;
> + spec->channels = rf_vals_3x;
> + } else if (rt2x00_rf(rt2x00dev, RF3052)) {
> + spec->supported_bands |= SUPPORT_BAND_5GHZ;
> + spec->num_channels = ARRAY_SIZE(rf_vals_3x);
> + spec->channels = rf_vals_3x;
> }
>
> /*
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Gertjan van Wingerde @ 2010-05-06 16:57 UTC (permalink / raw)
To: Helmut Schaa, John Linville; +Cc: linux-wireless, Ivo van Doorn
In-Reply-To: <201005061229.04897.helmut.schaa@googlemail.com>
On 05/06/10 12:29, Helmut Schaa wrote:
> Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
> used by the Ralink driver nor specified in 802.11.
>
> Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
> Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
> 11g + CTS protected connections. Add a comment to the code why we don't use 10us
> for CCK SIFS value.
>
> The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
> Ralink drivers).
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Good catch.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index e37bbea..f786068 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -1415,9 +1415,16 @@ int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
>
> rt2800_register_write(rt2x00dev, EXP_ACK_TIME, 0x002400ca);
>
> + /*
> + * Usually the CCK SIFS time should be set to 10 and the OFDM SIFS
> + * time should be set to 16. However, the original Ralink driver uses
> + * 16 for both and indeed using a value of 10 for CCK SIFS results in
> + * connection problems with 11g + CTS protection. Hence, use the same
> + * defaults as the Ralink driver: 16 for both, CCK and OFDM SIFS.
> + */
> rt2800_register_read(rt2x00dev, XIFS_TIME_CFG, ®);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, 32);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, 32);
> + rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, 16);
> + rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, 16);
> rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_XIFS_TIME, 4);
> rt2x00_set_field32(®, XIFS_TIME_CFG_EIFS, 314);
> rt2x00_set_field32(®, XIFS_TIME_CFG_BB_RXEND_ENABLE, 1);
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00: rt2800: don't overwrite SIFS values on erp changes
From: Gertjan van Wingerde @ 2010-05-06 16:59 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Ivo van Doorn
In-Reply-To: <201005061229.44923.helmut.schaa@googlemail.com>
On 05/06/10 12:29, Helmut Schaa wrote:
> The SIFS value is a constant and doesn't need to be updated on erp changes.
> Furthermore the code used 10us for both, the OFDM SIFS and CCK SIFS time
> which broke CTS protected 11g connections (see patch "rt2x00: rt2800: update
> initial SIFS values" for details).
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index f786068..858455f 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -640,8 +640,6 @@ void rt2800_config_erp(struct rt2x00_dev *rt2x00dev, struct rt2x00lib_erp *erp)
> rt2800_register_write(rt2x00dev, BKOFF_SLOT_CFG, reg);
>
> rt2800_register_read(rt2x00dev, XIFS_TIME_CFG, ®);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, erp->sifs);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, erp->sifs);
> rt2x00_set_field32(®, XIFS_TIME_CFG_EIFS, erp->eifs);
> rt2800_register_write(rt2x00dev, XIFS_TIME_CFG, reg);
>
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Ivo Van Doorn @ 2010-05-06 17:01 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005061229.04897.helmut.schaa@googlemail.com>
On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
> used by the Ralink driver nor specified in 802.11.
>
> Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
> Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
> 11g + CTS protected connections. Add a comment to the code why we don't use 10us
> for CCK SIFS value.
>
> The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
> Ralink drivers).
Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
Perhaps we should remove it in there, and no longer pass it from
rt2x00lib. That way there can't be any confusion about which drivers
uses the sifs field and whcih do not.
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
But that is really a different issue then this fix. So:
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index e37bbea..f786068 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -1415,9 +1415,16 @@ int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
>
> rt2800_register_write(rt2x00dev, EXP_ACK_TIME, 0x002400ca);
>
> + /*
> + * Usually the CCK SIFS time should be set to 10 and the OFDM SIFS
> + * time should be set to 16. However, the original Ralink driver uses
> + * 16 for both and indeed using a value of 10 for CCK SIFS results in
> + * connection problems with 11g + CTS protection. Hence, use the same
> + * defaults as the Ralink driver: 16 for both, CCK and OFDM SIFS.
> + */
> rt2800_register_read(rt2x00dev, XIFS_TIME_CFG, ®);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, 32);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, 32);
> + rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, 16);
> + rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, 16);
> rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_XIFS_TIME, 4);
> rt2x00_set_field32(®, XIFS_TIME_CFG_EIFS, 314);
> rt2x00_set_field32(®, XIFS_TIME_CFG_BB_RXEND_ENABLE, 1);
> --
> 1.6.4.2
>
>
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00: rt2800: don't overwrite SIFS values on erp changes
From: Ivo Van Doorn @ 2010-05-06 17:02 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005061229.44923.helmut.schaa@googlemail.com>
On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> The SIFS value is a constant and doesn't need to be updated on erp changes.
> Furthermore the code used 10us for both, the OFDM SIFS and CCK SIFS time
> which broke CTS protected 11g connections (see patch "rt2x00: rt2800: update
> initial SIFS values" for details).
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index f786068..858455f 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -640,8 +640,6 @@ void rt2800_config_erp(struct rt2x00_dev *rt2x00dev, struct rt2x00lib_erp *erp)
> rt2800_register_write(rt2x00dev, BKOFF_SLOT_CFG, reg);
>
> rt2800_register_read(rt2x00dev, XIFS_TIME_CFG, ®);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, erp->sifs);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, erp->sifs);
> rt2x00_set_field32(®, XIFS_TIME_CFG_EIFS, erp->eifs);
> rt2800_register_write(rt2x00dev, XIFS_TIME_CFG, reg);
>
> --
> 1.6.4.2
>
>
^ permalink raw reply
* 2.6.34-rc5-mmotm0428 - 2 RCU whinges in mac80211
From: Valdis.Kletnieks @ 2010-05-06 17:35 UTC (permalink / raw)
To: Andrew Morton, Johannes Berg, David S. Miller, John W. Linville
Cc: linux-kernel, netdev, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 5105 bytes --]
Spotted these in my dmesg, hopefully somebody is interested...
[ 54.076863] wlan0: deauthenticating from 00:11:20:a4:4c:11 by local choice (reason=3)
[ 54.080580]
[ 54.080581] ===================================================
[ 54.080584] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 54.080586] ---------------------------------------------------
[ 54.080589] net/mac80211/sta_info.c:858 invoked rcu_dereference_check() without protection!
[ 54.080591]
[ 54.080591] other info that might help us debug this:
[ 54.080592]
[ 54.080594]
[ 54.080595] rcu_scheduler_active = 1, debug_locks = 1
[ 54.080597] no locks held by hald/3362.
[ 54.080599]
[ 54.080599] stack backtrace:
[ 54.080602] Pid: 3362, comm: hald Not tainted 2.6.34-rc5-mmotm0428 #1
[ 54.080604] Call Trace:
[ 54.080607] <IRQ> [<ffffffff81064eb9>] lockdep_rcu_dereference+0x9d/0xa5
[ 54.080619] [<ffffffff815649f9>] ieee80211_find_sta_by_hw+0x46/0x10f
[ 54.080623] [<ffffffff81564ad9>] ieee80211_find_sta+0x17/0x19
[ 54.080628] [<ffffffff8136e1ee>] iwlagn_tx_queue_reclaim+0xe7/0x1bd
[ 54.080632] [<ffffffff81371da3>] iwlagn_rx_reply_tx+0x4e9/0x5a6
[ 54.080638] [<ffffffff8136501f>] iwl_rx_handle+0x268/0x3fe
[ 54.080642] [<ffffffff813664ea>] iwl_irq_tasklet+0x2d3/0x3e4
[ 54.080647] [<ffffffff8103e337>] tasklet_action+0x79/0xd7
[ 54.080651] [<ffffffff8103fd54>] __do_softirq+0x15a/0x2a2
[ 54.080656] [<ffffffff8100358c>] call_softirq+0x1c/0x34
[ 54.080659] [<ffffffff81004ad8>] do_softirq+0x44/0xf0
[ 54.080663] [<ffffffff8103f3ba>] irq_exit+0x4a/0xb3
[ 54.080667] [<ffffffff81004211>] do_IRQ+0xa7/0xbe
[ 54.080671] [<ffffffff8159cd93>] ret_from_intr+0x0/0xf
[ 54.080673] <EOI>
[ 54.114898] wlan0: authenticate with 00:11:20:a4:4c:11 (try 1)
[ 54.122103] wlan0: authenticated
[ 54.122472] wlan0: associate with 00:11:20:a4:4c:11 (try 1)
[ 54.128267] wlan0: RX AssocResp from 00:11:20:a4:4c:11 (capab=0x31 status=0 aid=10)
[ 54.128271] wlan0: associated
[ 54.132990] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 54.133333] cfg80211: Calling CRDA for country: US
[ 54.135752]
[ 54.135753] ===================================================
[ 54.135756] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 54.135758] ---------------------------------------------------
[ 54.135760] net/mac80211/sta_info.c:858 invoked rcu_dereference_check() without protection!
[ 54.135763]
[ 54.135763] other info that might help us debug this:
[ 54.135764]
[ 54.135766]
[ 54.135767] rcu_scheduler_active = 1, debug_locks = 1
[ 54.135769] 1 lock held by udevd/2933:
[ 54.135771] #0: (policy_rwlock){.+.+..}, at: [<ffffffff811d4f60>] security_compute_av+0x29/0x259
[ 54.135781]
[ 54.135782] stack backtrace:
[ 54.135785] Pid: 2933, comm: udevd Not tainted 2.6.34-rc5-mmotm0428 #1
[ 54.135787] Call Trace:
[ 54.135790] <IRQ> [<ffffffff81064eb9>] lockdep_rcu_dereference+0x9d/0xa5
[ 54.135800] [<ffffffff81564a49>] ieee80211_find_sta_by_hw+0x96/0x10f
[ 54.135804] [<ffffffff81564ad9>] ieee80211_find_sta+0x17/0x19
[ 54.135809] [<ffffffff8136e1ee>] iwlagn_tx_queue_reclaim+0xe7/0x1bd
[ 54.135813] [<ffffffff81371da3>] iwlagn_rx_reply_tx+0x4e9/0x5a6
[ 54.135819] [<ffffffff8136501f>] iwl_rx_handle+0x268/0x3fe
[ 54.135823] [<ffffffff813664ea>] iwl_irq_tasklet+0x2d3/0x3e4
[ 54.135828] [<ffffffff8103e337>] tasklet_action+0x79/0xd7
[ 54.135832] [<ffffffff8103fd54>] __do_softirq+0x15a/0x2a2
[ 54.135837] [<ffffffff8100358c>] call_softirq+0x1c/0x34
[ 54.135841] [<ffffffff81004ad8>] do_softirq+0x44/0xf0
[ 54.135844] [<ffffffff8103f3ba>] irq_exit+0x4a/0xb3
[ 54.135847] [<ffffffff81004211>] do_IRQ+0xa7/0xbe
[ 54.135852] [<ffffffff8159cd93>] ret_from_intr+0x0/0xf
[ 54.135854] <EOI> [<ffffffff811ce48b>] ? avtab_search_node+0x6c/0x7b
[ 54.135862] [<ffffffff811d4cdb>] context_struct_compute_av+0x136/0x271
[ 54.135867] [<ffffffff811d506b>] security_compute_av+0x134/0x259
[ 54.135872] [<ffffffff811c2560>] avc_has_perm_noaudit+0x22e/0x537
[ 54.135876] [<ffffffff811c289f>] avc_has_perm+0x36/0x69
[ 54.135880] [<ffffffff810c52cd>] ? __do_fault+0x254/0x3f1
[ 54.135885] [<ffffffff811c4bca>] current_has_perm+0x3a/0x3f
[ 54.135888] [<ffffffff811c4c7d>] selinux_task_create+0x17/0x19
[ 54.135893] [<ffffffff811beced>] security_task_create+0x11/0x13
[ 54.135898] [<ffffffff81036dae>] copy_process+0x8d/0x11ed
[ 54.135901] [<ffffffff810c5434>] ? __do_fault+0x3bb/0x3f1
[ 54.135905] [<ffffffff8107c26b>] ? rcu_read_lock+0x0/0x35
[ 54.135909] [<ffffffff810380b2>] do_fork+0x1a4/0x3b5
[ 54.135913] [<ffffffff8107c2c1>] ? rcu_read_unlock+0x21/0x23
[ 54.135917] [<ffffffff8107dc56>] ? audit_filter_syscall+0xb4/0xc8
[ 54.135921] [<ffffffff81059044>] ? up_read+0x1e/0x36
[ 54.135924] [<ffffffff8105d760>] ? current_kernel_time+0x28/0x50
[ 54.135929] [<ffffffff81009705>] sys_clone+0x23/0x25
[ 54.135933] [<ffffffff810029d3>] stub_clone+0x13/0x20
[ 54.135936] [<ffffffff8100266b>] ? system_call_fastpath+0x16/0x1b
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: RTL 8187b - naughty behaviour
From: seno @ 2010-05-06 17:36 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4BB7660A.3030900@lwfinger.net>
Hi Larry,
I'm running Mandriva 2010 x86_64 (2.6.31.13) and have a 8187b chipset installed:
0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network
Adapter
As many other linux users report, this chipset is supported but offers only
limited performance, especially compared to results when using windows.
Some time ago I connected to a Linksys wrt 54 GL router with Linksys firmware
and recently I installed DD-wrt on that router, but perfomance remaind at the
same (poor) level; meaning there must be something wrong with the rtl8187 linux
modul.
Right now the router is ~10 meters away and iwconfig wlan0 output is
IEEE 802.11bg ESSID:"xxx"
Mode:Managed Frequency:2.412 GHz Access Point: 00:14:BF:4A:ED:F9
Bit Rate=18 Mb/s Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx [3]
Power Management:off
Link Quality=70/70 Signal level=-33 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Right after booting, I can reach a wireless download rate of ~ 10mbit/s (I have
10 mbit cable internet). After a while, it seems that the wireless rate drops
to 1 mbit/s although iwconfig wlan0 stills shows a bit rate of 11 or 18 mbit/s.
That means, I get stuck at a download speed of ~ 130 K/s -unless I come closer
to the router, 1 meter ie, then the wireless speed goes up again.
The router status shows
Wireless Packet Info
Received (RX)
45915806 OK, 10 errors
Transmitted (TX)
81142592 OK, 746 errors
If the machine with the 8187b chip is connected, I get a lot of TX errors on
the router.
While linux shows good connection quality, the router indicates a bad signal
quality:
Signal Noise SNR Signal Quality
-74 -94 20 24%
-I installed the latest package from linux wireless, driver loaded but for some
reason it was not able to connect to a wpa2 network (iwconfig wlan0 never shot
enc key), so I uninstalled that again.
-I booted a Mandirva 2010.0 x86 live cd to see if the problem is the same on 32
bit system, and yes, it is.
-I found a 'newer' driver rtl8187B_linux_26.1056.1112.2009.release.tar.gz on
ubuntu forum - compiled, installed but for any reason driver did not load
correctly and something ooopsed (I blacklisted rtl8187 and set r8187 as alias
for wlan0).
Any idea what I could do to get some better performance with the 8187b chipset?
^ permalink raw reply
* Re: 2.6.34-rc5-mmotm0428 - 2 RCU whinges in mac80211
From: Johannes Berg @ 2010-05-06 17:58 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, David S. Miller, John W. Linville, linux-kernel,
netdev, linux-wireless
In-Reply-To: <5820.1273167313@localhost>
On Thu, 2010-05-06 at 13:35 -0400, Valdis.Kletnieks@vt.edu wrote:
> Spotted these in my dmesg, hopefully somebody is interested...
>
> [ 54.076863] wlan0: deauthenticating from 00:11:20:a4:4c:11 by local choice (reason=3)
> [ 54.080580]
> [ 54.080581] ===================================================
> [ 54.080584] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 54.080586] ---------------------------------------------------
> [ 54.080589] net/mac80211/sta_info.c:858 invoked rcu_dereference_check() without protection!
I'm pretty sure I fixed those so there should be a patch on its way to
or in mainline somewhere.
johannes
^ permalink raw reply
* Re: The case of the bogus SSID
From: Steve deRosier @ 2010-05-06 18:12 UTC (permalink / raw)
To: pigiron; +Cc: linux-wireless
In-Reply-To: <20100505120131.2b9f4e06@atom.pigiron.org>
On Wed, May 5, 2010 at 10:01 AM, pigiron <pigiron@gmx.com> wrote:
> I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the ieee80211.h file, and recently the same 52 was also assigned to WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{} structure.
>
I can't answer the rest of your question, but AFAIK, the element IDs
for 802.11s mesh haven't been approved yet as the 802.11s draft
contains a note to that effect. The current ANA database sheet I
could find (Feb 2010) does have 52 assigned to Neighbor Report, and
the mesh element IDs are nowhere to be found.
- Steve
^ permalink raw reply
* Re: RTL 8187b - naughty behaviour
From: Larry Finger @ 2010-05-06 18:20 UTC (permalink / raw)
To: seno; +Cc: linux-wireless
In-Reply-To: <loom.20100506T185847-345@post.gmane.org>
On 05/06/2010 12:36 PM, seno wrote:
> Hi Larry,
>
> I'm running Mandriva 2010 x86_64 (2.6.31.13) and have a 8187b chipset installed:
>
> 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network
> Adapter
>
> As many other linux users report, this chipset is supported but offers only
> limited performance, especially compared to results when using windows.
>
> Some time ago I connected to a Linksys wrt 54 GL router with Linksys firmware
> and recently I installed DD-wrt on that router, but perfomance remaind at the
> same (poor) level; meaning there must be something wrong with the rtl8187 linux
> modul.
>
> Right now the router is ~10 meters away and iwconfig wlan0 output is
>
> IEEE 802.11bg ESSID:"xxx"
> Mode:Managed Frequency:2.412 GHz Access Point: 00:14:BF:4A:ED:F9
> Bit Rate=18 Mb/s Tx-Power=27 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx [3]
> Power Management:off
> Link Quality=70/70 Signal level=-33 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> Right after booting, I can reach a wireless download rate of ~ 10mbit/s (I have
> 10 mbit cable internet). After a while, it seems that the wireless rate drops
> to 1 mbit/s although iwconfig wlan0 stills shows a bit rate of 11 or 18 mbit/s.
> That means, I get stuck at a download speed of ~ 130 K/s -unless I come closer
> to the router, 1 meter ie, then the wireless speed goes up again.
>
> The router status shows
>
> Wireless Packet Info
> Received (RX)
> 45915806 OK, 10 errors
> Transmitted (TX)
> 81142592 OK, 746 errors
>
> If the machine with the 8187b chip is connected, I get a lot of TX errors on
> the router.
>
> While linux shows good connection quality, the router indicates a bad signal
> quality:
>
> Signal Noise SNR Signal Quality
> -74 -94 20 24%
>
> -I installed the latest package from linux wireless, driver loaded but for some
> reason it was not able to connect to a wpa2 network (iwconfig wlan0 never shot
> enc key), so I uninstalled that again.
> -I booted a Mandirva 2010.0 x86 live cd to see if the problem is the same on 32
> bit system, and yes, it is.
> -I found a 'newer' driver rtl8187B_linux_26.1056.1112.2009.release.tar.gz on
> ubuntu forum - compiled, installed but for any reason driver did not load
> correctly and something ooopsed (I blacklisted rtl8187 and set r8187 as alias
> for wlan0).
>
> Any idea what I could do to get some better performance with the 8187b chipset?
I do not understand the poor performance. I have a device with the
rtl8187b chip - USB IDs 0bda:8187. That is an ID for an rtl8187, but it
does have the B chip. I use tcpperf to measure the transmit speed. At 2
m from the AP with an indicated signal of -17 dBm, my throughput is 13
Mb/s. At 10 m with a signal of -49 dBm, the transmit speed is 3.5 Mb/s.
On the download using speedtest.net, I got 11.3 Mb/s at 2 m, and 2.64 at
10 m. I got 0.49 Mb/s upload at both distances as that is the speed of
my line.
What happens if you use iwconfig to force a particular rate? At what
setting is your throughput maximized. I don't think there is a problem
with the rate setting mechanism, but that would test it.
Larry
^ permalink raw reply
* Re: [PATCH] iwlwifi: recalculate average tpt if not current
From: John W. Linville @ 2010-05-06 18:22 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
Adel Gadllah
In-Reply-To: <1273162268.2226.2503.camel@rchatre-DESK>
On Thu, May 06, 2010 at 09:11:08AM -0700, reinette chatre wrote:
> On Mon, 2010-05-03 at 10:55 -0700, reinette chatre wrote:
> > From: Reinette Chatre <reinette.chatre@intel.com>
> >
> > We currently have this check as a BUG_ON, which is being hit by people.
> > Previously it was an error with a recalculation if not current, return that
> > code.
> >
> > The BUG_ON was introduced by:
> > commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
> > Author: Guy Cohen <guy.cohen@intel.com>
> > Date: Tue Sep 9 10:54:54 2008 +0800
> >
> > iwlwifi: Added support for 3 antennas
> >
> > ... the portion adding the BUG_ON is reverted since we are encountering the error
> > and BUG_ON was created with assumption that error is not encountered.
> >
> > Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> > ---
>
> I noticed this patch in your wireless-next-2.6 pull request. Since it is
> addressing a system hang issue, could it perhaps be included in
> wireless-2.6 also? I should have included the bug report reference for
> this purpose, sorry ... it is
> https://bugzilla.redhat.com/show_bug.cgi?id=588021
I didn't send it that way because a) that code has been there for a
really long time; and b) the reporter couldn't reliably reproduce
the bug and therefore can't reliably test the fix. While I agree
that the fix looks harmless, no update is zero-risk.
Can you reliably hit that code? Has it been tested enough that we
should risk holding-up 2.6.34's release for it?
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: 2.6.34-rc5-mmotm0428 - 2 RCU whinges in mac80211
From: Valdis.Kletnieks @ 2010-05-06 18:29 UTC (permalink / raw)
To: Johannes Berg
Cc: Andrew Morton, David S. Miller, John W. Linville, linux-kernel,
netdev, linux-wireless
In-Reply-To: <1273168696.23199.0.camel@jlt3.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
On Thu, 06 May 2010 19:58:16 +0200, Johannes Berg said:
> On Thu, 2010-05-06 at 13:35 -0400, Valdis.Kletnieks@vt.edu wrote:
> > Spotted these in my dmesg, hopefully somebody is interested...
> >
> > [ 54.076863] wlan0: deauthenticating from 00:11:20:a4:4c:11 by local choice (reason=3)
> > [ 54.080580]
> > [ 54.080581] ===================================================
> > [ 54.080584] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 54.080586] ---------------------------------------------------
> > [ 54.080589] net/mac80211/sta_info.c:858 invoked rcu_dereference_check() without protection!
>
> I'm pretty sure I fixed those so there should be a patch on its way to
> or in mainline somewhere.
Oh, OK. I didn't remember seeing them mentioned before, but I must have
missed somebody else's post about it due to the lkml firehose effect. I've
moved these to my "whinge if it isn't fixed in the next -mmotm" queue.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] rt2x00: rt2800: use correct txop value in tx descriptor
From: Gertjan van Wingerde @ 2010-05-06 18:32 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Ivo van Doorn
In-Reply-To: <201005061229.58509.helmut.schaa@googlemail.com>
On 05/06/10 12:29, Helmut Schaa wrote:
> rt2800 devices use a different enumeration to specify what IFS values should
> be used on frame transmission compared to the other rt2x00 devices. Hence,
> create a new enum called txop that contains the valid values.
>
> Furthermore use TXOP_HTTXOP as default on HT devices which means that the
> hardware should select the correct IFS value on its own.
>
> I'm not sure if we have the need to specify one of the other txop values
> in the future but as far as I could see TXOP_HTTXOP is used by the Ralink
> drivers for all normal data frames and should be a reasonable default.
>
> This patch doesn't really fix anything as until now the IFS_BACKOFF(=0)
> value was used as txop which luckily mapped to TXOP_HTTXOP(=0).
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
> drivers/net/wireless/rt2x00/rt2x00ht.c | 2 ++
> drivers/net/wireless/rt2x00/rt2x00queue.h | 2 ++
> drivers/net/wireless/rt2x00/rt2x00reg.h | 10 ++++++++++
> 5 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
> index f08b6a3..df2c3fb 100644
> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
> @@ -643,7 +643,7 @@ static int rt2800pci_write_tx_data(struct queue_entry* entry,
> rt2x00_set_field32(&word, TXWI_W0_AMPDU,
> test_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags));
> rt2x00_set_field32(&word, TXWI_W0_MPDU_DENSITY, txdesc->mpdu_density);
> - rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->ifs);
> + rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->txop);
> rt2x00_set_field32(&word, TXWI_W0_MCS, txdesc->mcs);
> rt2x00_set_field32(&word, TXWI_W0_BW,
> test_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags));
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index e3f3a97..c9e1320 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -417,7 +417,7 @@ static void rt2800usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
> rt2x00_set_field32(&word, TXWI_W0_AMPDU,
> test_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags));
> rt2x00_set_field32(&word, TXWI_W0_MPDU_DENSITY, txdesc->mpdu_density);
> - rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->ifs);
> + rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->txop);
> rt2x00_set_field32(&word, TXWI_W0_MCS, txdesc->mcs);
> rt2x00_set_field32(&word, TXWI_W0_BW,
> test_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags));
> diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> index 1056c92..5483fec 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> @@ -66,4 +66,6 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> +
> + txdesc->txop = TXOP_HTTXOP;
> }
I am not too sure about this part. If I look at the Ralink vendor driver, they are most of the time
using IFS_BACKOFF (value 3). Why did you put this on TXOP_HTTXOP?
> diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
> index 94a48c1..36a957a 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00queue.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
> @@ -299,6 +299,7 @@ enum txentry_desc_flags {
> * @retry_limit: Max number of retries.
> * @aifs: AIFS value.
> * @ifs: IFS value.
> + * @txop: IFS value for 11n capable chips.
> * @cw_min: cwmin value.
> * @cw_max: cwmax value.
> * @cipher: Cipher type used for encryption.
> @@ -328,6 +329,7 @@ struct txentry_desc {
> short retry_limit;
> short aifs;
> short ifs;
> + short txop;
> short cw_min;
> short cw_max;
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00reg.h b/drivers/net/wireless/rt2x00/rt2x00reg.h
> index 603bfc0..894ff78 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00reg.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00reg.h
> @@ -101,6 +101,16 @@ enum ifs {
> };
>
> /*
> + * IFS values for HT devices
> + */
> +enum txop {
> + TXOP_HTTXOP = 0,
> + TXOP_PIFS = 1,
> + TXOP_SIFS = 2,
> + TXOP_BACKOFF = 3,
> +};
> +
> +/*
> * Cipher types for hardware encryption
> */
> enum cipher {
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Helmut Schaa @ 2010-05-06 18:38 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <s2ma32f33a41005061001w5e7258f0p3715ec238a00a4f4@mail.gmail.com>
Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
> On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
> > Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
> > used by the Ralink driver nor specified in 802.11.
> >
> > Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
> > Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
> > 11g + CTS protected connections. Add a comment to the code why we don't use 10us
> > for CCK SIFS value.
> >
> > The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
> > Ralink drivers).
>
> Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
> Perhaps we should remove it in there, and no longer pass it from
> rt2x00lib. That way there can't be any confusion about which drivers
> uses the sifs field and whcih do not.
Yes, wouldn't be too bad I guess. But all non 2800 drivers use the same sifs
value, so we could just leave the define in rt2x00.h and remove the sifs value
from the config_erp calback and use the define in all other places?
Nevertheless, I'm not sure why the rt2800 devices don't like the 10us CCK
SIFS value (which is defined in 802.11) but I wasn't able to get CTS to self
working correctly with it set to 10 (the actual data frame was sent out
way too late after the CTS frame, somtimes with delays >100us). Using the 16us
also for CCK (as the ralink drivers do) results in perfect CTS & data frame
timing. Maybe it's a hardware issue and the (ralink) driver just works around
it?
Helmut
^ permalink raw reply
* Re: [PATCH] compat-wireless: updates for orinoco
From: Luis R. Rodriguez @ 2010-05-06 18:49 UTC (permalink / raw)
To: Luis Rodriguez
Cc: Johannes Berg, Hauke Mehrtens, linux-wireless@vger.kernel.org
In-Reply-To: <20100505222347.GC32666@tux>
On Wed, May 05, 2010 at 03:23:47PM -0700, Luis Rodriguez wrote:
> On Tue, May 04, 2010 at 11:45:03PM -0700, Johannes Berg wrote:
> > On Tue, 2010-05-04 at 16:26 -0700, Luis R. Rodriguez wrote:
> >
> > > void netdev_attach_ops(struct net_device *dev,
> > > const struct net_device_ops *ops)
> > > {
> > > #define SET_NETDEVOP(_op) (_op ? _op : NULL)
> >
> > isn't that like the dumbest macro ever?
>
> That's subjective, I am lazy.
You're right this is dumb :P
Luis
^ permalink raw reply
* Re: [PATCH] iwlwifi: recalculate average tpt if not current
From: reinette chatre @ 2010-05-06 18:50 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
Adel Gadllah
In-Reply-To: <20100506182232.GB4167@tuxdriver.com>
Hi John,
On Thu, 2010-05-06 at 11:22 -0700, John W. Linville wrote:
> On Thu, May 06, 2010 at 09:11:08AM -0700, reinette chatre wrote:
> > I noticed this patch in your wireless-next-2.6 pull request. Since it is
> > addressing a system hang issue, could it perhaps be included in
> > wireless-2.6 also? I should have included the bug report reference for
> > this purpose, sorry ... it is
> > https://bugzilla.redhat.com/show_bug.cgi?id=588021
>
> I didn't send it that way because a) that code has been there for a
> really long time; and b) the reporter couldn't reliably reproduce
> the bug and therefore can't reliably test the fix. While I agree
> that the fix looks harmless, no update is zero-risk.
>
> Can you reliably hit that code? Has it been tested enough that we
> should risk holding-up 2.6.34's release for it?
Good point ... we have not seen this BUG being hit before and it seems
to have been there since 2.6.28. In addition to the report in RedHat
bugzilla there is a lkml thread that seems to be related to this code
also (http://lkml.org/lkml/2010/5/3/229 ) ... but that reporter did not
seem to test this patch and my last reply to that thread bounced to his
email address.
We thus seem to have two recent reports of users hitting the BUG, which
may mean some other recent change in driver causes this BUG to be hit,
not really just the presence of the BUG code itself.
As far as testing goes ... this patch has just been merged and will from
now on be included in our regression testing. Unfortunately this had not
been exercised much yet since I just merged.
I guess we will proceed with the "wait and see" here and forward this
patch to stable if the BUG is encountered again.
Reinette
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Ivo Van Doorn @ 2010-05-06 18:51 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005062038.24982.helmut.schaa@googlemail.com>
On Thu, May 6, 2010 at 8:38 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
>> On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
>> <helmut.schaa@googlemail.com> wrote:
>> > Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
>> > used by the Ralink driver nor specified in 802.11.
>> >
>> > Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
>> > Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
>> > 11g + CTS protected connections. Add a comment to the code why we don't use 10us
>> > for CCK SIFS value.
>> >
>> > The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
>> > Ralink drivers).
>>
>> Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
>> Perhaps we should remove it in there, and no longer pass it from
>> rt2x00lib. That way there can't be any confusion about which drivers
>> uses the sifs field and whcih do not.
>
> Yes, wouldn't be too bad I guess. But all non 2800 drivers use the same sifs
> value, so we could just leave the define in rt2x00.h and remove the sifs value
> from the config_erp calback and use the define in all other places?
Well I would still remove the define in that case. I think some of the
legacy drivers
work with different SIFS values but always accepted the value which we used in
the define. So I would still remove the define, and then each driver
is free to set
the value as used in the legacy drivers.
> Nevertheless, I'm not sure why the rt2800 devices don't like the 10us CCK
> SIFS value (which is defined in 802.11) but I wasn't able to get CTS to self
> working correctly with it set to 10 (the actual data frame was sent out
> way too late after the CTS frame, somtimes with delays >100us). Using the 16us
> also for CCK (as the ralink drivers do) results in perfect CTS & data frame
> timing. Maybe it's a hardware issue and the (ralink) driver just works around
> it?
Yes, I expect it to be case. This kind of odd values are used in the
legacy drivers
for other settings as well.
Ivo
^ permalink raw reply
* Re: [PATCH 3/3] rt2x00: rt2800: use correct txop value in tx descriptor
From: Helmut Schaa @ 2010-05-06 18:57 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John Linville, linux-wireless, Ivo van Doorn
In-Reply-To: <4BE30B3B.2000900@gmail.com>
Am Donnerstag 06 Mai 2010 schrieb Gertjan van Wingerde:
> On 05/06/10 12:29, Helmut Schaa wrote:
[...]
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > index 1056c92..5483fec 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> > +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > @@ -66,4 +66,6 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> > __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> > if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> > __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> > +
> > + txdesc->txop = TXOP_HTTXOP;
> > }
>
> I am not too sure about this part. If I look at the Ralink vendor driver, they are most of the time
> using IFS_BACKOFF (value 3). Why did you put this on TXOP_HTTXOP?
>From what I saw in the ralink driver IFS_BACKOFF is only used for management frames, IFS_SIFS only
for subsequent frames in a fragment burst and IFS_HTTXOPS for "normal" data frames. But that's
just the result of a _quick_ review. So I might be wrong here as well :)
To be honest I don't really know what the device does in case IFS_HTTXOPS is set but that was
the value we've passed to the driver before ;) (==IFS_BACKOFF on all other ralink chips) and it
works quite well. I also tried IFS_BACKOFF and I wasn't able to see a difference when using
legacy (11b & 11g) rates (neither on the device itself nor with a second machine monitoring
the traffic).
But I agree that we have to dig further on when to use which value but nevertheless the patch
shouldn't cause any harm but is meant as a base for further improvements.
If you want to we can also wait with this one until we completely figured out what to do?
Helmut
^ 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