* Re: iwlagn unexpected AddBA Req
From: reinette chatre @ 2010-04-19 17:50 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <m2p43e72e891004012145s2f344f7fo9b12044e9b895c06@mail.gmail.com>
On Thu, 2010-04-01 at 21:45 -0700, Luis R. Rodriguez wrote:
> [ 117.491303] unexpected AddBA Req from 00:22:6b:56:fd:e9 on tid 0
> [ 178.467383] unexpected AddBA Req from 00:22:6b:56:fd:e9 on tid 0
> [ 239.447236] unexpected AddBA Req from 00:22:6b:56:fd:e9 on tid 0
>
> I get a lof of these at spurious times against my WRT610N using
> today's wireless-testing on iwlagn.
If you still have this setup available, could you please try out the
recent patch "mac80211: pass HT changes to driver when off
channel" (http://thread.gmane.org/gmane.linux.kernel.wireless.general/49855 ) ?
Thank you
Reinette
^ permalink raw reply
* [PATCH] mac80211: pass HT changes to driver when off channel
From: Reinette Chatre @ 2010-04-19 17:46 UTC (permalink / raw)
To: johannes; +Cc: linville, linux-wireless, Reinette Chatre
From: Reinette Chatre <reinette.chatre@intel.com>
Since "mac80211: make off-channel work generic" drivers have not been
notified of configuration changes after association or authentication. This
caused more dependence on current state to ensure driver will be notified
when configuration changes occur. One such problem arises if off-channel is
in progress when HT information changes. Since HT is only enabled on the
"oper_channel" the driver will never be notified of this change. Usually
the driver is notified soon after of a BSS information change
(BSS_CHANGED_HT) ... but since the driver did not get a notification that
this is a HT channel the new BSS information does not make sense.
Fix this by also changing the off-channel information when HT is enabled
and thus cause driver to be notified correctly.
This fixes a problem in 4965 when associated with 5GHz 40MHz channel.
Without this patch the system can associate but is unable to transfer any
data, not even ping.
See http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2158
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
net/mac80211/mlme.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 35d8502..3133681 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -175,6 +175,8 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
ht_changed = conf_is_ht(&local->hw.conf) != enable_ht ||
channel_type != local->hw.conf.channel_type;
+ if (local->tmp_channel)
+ local->tmp_channel_type = channel_type;
local->oper_channel_type = channel_type;
if (ht_changed) {
--
1.6.3.3
^ permalink raw reply related
* Re: rc80211_minstrel.c:70 WARNING with 2.6.34-rc4
From: Felix Fietkau @ 2010-04-19 17:41 UTC (permalink / raw)
To: Richard Zidlicky; +Cc: Pavel Roskin, linux-wireless
In-Reply-To: <20100419174100.GA5312@linux-m68k.org>
On 2010-04-19 7:41 PM, Richard Zidlicky wrote:
>
> Hi,
>
>> > I am getting tons of these http://www.kerneloops.org/submitresult.php?number=3048061,
>> > appears every packet triggers that.
>>
>> The warning comes from the function rix_to_ndx() in rc80211_minstrel.c:
>>
>> /* convert mac80211 rate index to local array index */
>> static inline int
>> rix_to_ndx(struct minstrel_sta_info *mi, int rix)
>> {
>> int i = rix;
>> for (i = rix; i >= 0; i--)
>> if (mi->r[i].rix == rix)
>> break;
>> WARN_ON(i < 0);
>> return i;
>> }
>>
>> > Can provide lots of debugging info.
>>
>> My impression is that WARN_ON is not warranted in that function, but it
>> would be interesting to know how you got to that point.
>
> I am using the rt73usb, WEP, adhoc, fixed rate(11M) on both ends:
>
> wlan0 IEEE 802.11bg ESSID:"XXXXXXXX"
> Mode:Ad-Hoc Frequency:2.442 GHz Cell: F6:B2:CB:FC:62:6C
> Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key: XXXXXXXXXX
> Power Management:on
>
> It is 2.6.34-rc4, no compat-wireless.
>
> As of unusual circumstances - the rt73usb driver has some bug that causes
> very high retransmit rates. On the opposite end the ath5k driver complains "cant
> handle jumbo frames".
> I had it perfectly working some time ago but need to figure out which off the many
> patches did it and apply it to the new kernel.
> This might stress minstrel more than needed but otoh it was my impression that the
> warning was triggered by every single packet.
>
> Let me know if you want any more info.
This warning typically shows up, whenever the driver reports a rate to
minstrel in the tx status that is not part of the supported/negotiated
rate set - that's the reason the index lookup above fails.
- Felix
^ permalink raw reply
* Re: rc80211_minstrel.c:70 WARNING with 2.6.34-rc4
From: Richard Zidlicky @ 2010-04-19 17:41 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <1271694855.9026.51.camel@mj>
Hi,
> > I am getting tons of these http://www.kerneloops.org/submitresult.php?number=3048061,
> > appears every packet triggers that.
>
> The warning comes from the function rix_to_ndx() in rc80211_minstrel.c:
>
> /* convert mac80211 rate index to local array index */
> static inline int
> rix_to_ndx(struct minstrel_sta_info *mi, int rix)
> {
> int i = rix;
> for (i = rix; i >= 0; i--)
> if (mi->r[i].rix == rix)
> break;
> WARN_ON(i < 0);
> return i;
> }
>
> > Can provide lots of debugging info.
>
> My impression is that WARN_ON is not warranted in that function, but it
> would be interesting to know how you got to that point.
I am using the rt73usb, WEP, adhoc, fixed rate(11M) on both ends:
wlan0 IEEE 802.11bg ESSID:"XXXXXXXX"
Mode:Ad-Hoc Frequency:2.442 GHz Cell: F6:B2:CB:FC:62:6C
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key: XXXXXXXXXX
Power Management:on
It is 2.6.34-rc4, no compat-wireless.
As of unusual circumstances - the rt73usb driver has some bug that causes
very high retransmit rates. On the opposite end the ath5k driver complains "cant
handle jumbo frames".
I had it perfectly working some time ago but need to figure out which off the many
patches did it and apply it to the new kernel.
This might stress minstrel more than needed but otoh it was my impression that the
warning was triggered by every single packet.
Let me know if you want any more info.
Richard
^ permalink raw reply
* Re: Request for releasing b43-fwcutter
From: Rafał Miłecki @ 2010-04-19 16:45 UTC (permalink / raw)
To: Michael Buesch; +Cc: b43-dev, linux-wireless
In-Reply-To: <201004191753.44213.mb@bu3sch.de>
W dniu 19 kwietnia 2010 17:53 użytkownik Michael Buesch <mb@bu3sch.de> napisał:
> On Monday 19 April 2010 16:54:23 Rafał Miłecki wrote:
>> Could you consider releasing new version of b43-fwcutter, as we
>> already have LP-PHY support in kernel, please? AFAIK ppl need to use
>> git version currently to extract firmware.
>
> Good idea. I released b43-fwcutter-013.
Thanks, http://wireless.kernel.org/en/users/Drivers/b43 updated.
--
Rafał
^ permalink raw reply
* Re: rc80211_minstrel.c:70 WARNING with 2.6.34-rc4
From: Pavel Roskin @ 2010-04-19 16:34 UTC (permalink / raw)
To: Richard Zidlicky; +Cc: linux-wireless
In-Reply-To: <20100418085653.GA7345@linux-m68k.org>
On Sun, 2010-04-18 at 10:56 +0200, Richard Zidlicky wrote:
> Hi,
>
> I am getting tons of these http://www.kerneloops.org/submitresult.php?number=3048061,
> appears every packet triggers that.
The warning comes from the function rix_to_ndx() in rc80211_minstrel.c:
/* convert mac80211 rate index to local array index */
static inline int
rix_to_ndx(struct minstrel_sta_info *mi, int rix)
{
int i = rix;
for (i = rix; i >= 0; i--)
if (mi->r[i].rix == rix)
break;
WARN_ON(i < 0);
return i;
}
> Can provide lots of debugging info.
My impression is that WARN_ON is not warranted in that function, but it
would be interesting to know how you got to that point.
What driver are you using? What is the mode for the interface? What is
your hardware? Is there anything unusual you do that triggers the
warning? Are you using 5 GHz band by any chance? Are you using
2.6.34-rc4 or it's compat-wireless compiled for another kernel?
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [rt2x00] rt3070 fails to initialize with rt2800usb
From: Ivo van Doorn @ 2010-04-19 16:25 UTC (permalink / raw)
To: Walter; +Cc: linux-wireless, users
In-Reply-To: <79507.95340.qm@web56807.mail.re3.yahoo.com>
On Monday 19 April 2010, Walter wrote:
> > Thats odd, in compar-wireless, it already contains the
> > lines:
> >
> > #ifdef CONFIG_RT2800USB_RT30XX
> > <..snip..>
> > /* Ralink */
> > { USB_DEVICE(0x148f, 0x2070),
> > USB_DEVICE_DATA(&rt2800usb_ops) },
> > { USB_DEVICE(0x148f, 0x3070),
> > USB_DEVICE_DATA(&rt2800usb_ops) },
> > { USB_DEVICE(0x148f, 0x3071),
> > USB_DEVICE_DATA(&rt2800usb_ops) },
> > { USB_DEVICE(0x148f, 0x3072),
> > USB_DEVICE_DATA(&rt2800usb_ops) },
> > <..snip..>
> > #endif
> >
> > So adding the USB ID does not need to be added.
> >
> > Ivo
>
> It is odd. I followed exactly the same logic you have, but I'm adamant the module doesn't recognize the VID of card as it is. Lets get factual:
>
> compat-wireless from March 28th. default install (make && make install) here is the output when the rt2800usb is loaded:
>
> [21902.553231] Generic kernel compatibility enabled based on linux-next next-20100113
> [21902.596351] cfg80211: Calling CRDA to update world regulatory domain
> [21902.695076] usbcore: registered new interface driver rt2800usb
> [21902.714019] cfg80211: World regulatory domain updated:
> [21902.714026] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [21902.714032] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [21902.714036] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [21902.714041] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [21902.714045] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [21902.714050] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>
> modinfo rt2800usb |grep 3070 -- returns nothing
>
> as soon as I add the 148f:rt3070 to:
>
> /* Ralink */
> { USB_DEVICE(0x148f, 0x2770), USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x2870), USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x3070), USB_DEVICE_DATA(&rt2800usb_ops) }, <--- manually added
> /* Samsung */
>
> rt2800usb recognizes the chip and initializes all operations:
>
> [22310.272382] usb 5-2.4: new high speed USB device using ehci_hcd and address 10
> [22310.381269] usb 5-2.4: configuration #1 chosen from 1 choice
> [22310.416482] phy1: Selected rate control algorithm 'minstrel'
> [22310.417403] Registered led device: rt2800usb-phy1::radio
> [22310.417456] Registered led device: rt2800usb-phy1::assoc
> [22310.417505] Registered led device: rt2800usb-phy1::quality
> [22310.479159] udev: renamed network interface wlan0 to wlan2
> [22310.483779] rt2800usb 5-2.4:1.0: firmware: requesting rt2870.bin
>
> Now, modinfo rt2800usb |grep 3070 -- shows its OK:
>
> alias: usb:v148Fp3070d*dc*dsc*dp*ic*isc*ip*
>
>
> This is a longstanding bug from at least few months or so, I thought you were experimenting/adjusting the code and I figured it would be temporary, but it has been so long that I thought I had to report this now.
>
> Walter.
Just checked the wireless-compat package, but are you sure that the config file contains:
CONFIG_RT2800USB_RT30XX=y
and not the default:
# CONFIG_RT2800USB_RT30XX=y
Note the prefixed '#' which should be removed to enable the configuration option.
Ivo
^ permalink raw reply
* Re: [rt2x00] rt3070 fails to initialize with rt2800usb
From: Walter @ 2010-04-19 16:13 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: linux-wireless, users
> Thats odd, in compar-wireless, it already contains the
> lines:
>
> #ifdef CONFIG_RT2800USB_RT30XX
> <..snip..>
> /* Ralink */
> { USB_DEVICE(0x148f, 0x2070),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x3070),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x3071),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x3072),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> <..snip..>
> #endif
>
> So adding the USB ID does not need to be added.
>
> Ivo
It is odd. I followed exactly the same logic you have, but I'm adamant the module doesn't recognize the VID of card as it is. Lets get factual:
compat-wireless from March 28th. default install (make && make install) here is the output when the rt2800usb is loaded:
[21902.553231] Generic kernel compatibility enabled based on linux-next next-20100113
[21902.596351] cfg80211: Calling CRDA to update world regulatory domain
[21902.695076] usbcore: registered new interface driver rt2800usb
[21902.714019] cfg80211: World regulatory domain updated:
[21902.714026] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[21902.714032] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[21902.714036] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[21902.714041] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[21902.714045] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[21902.714050] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
modinfo rt2800usb |grep 3070 -- returns nothing
as soon as I add the 148f:rt3070 to:
/* Ralink */
{ USB_DEVICE(0x148f, 0x2770), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x148f, 0x2870), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x148f, 0x3070), USB_DEVICE_DATA(&rt2800usb_ops) }, <--- manually added
/* Samsung */
rt2800usb recognizes the chip and initializes all operations:
[22310.272382] usb 5-2.4: new high speed USB device using ehci_hcd and address 10
[22310.381269] usb 5-2.4: configuration #1 chosen from 1 choice
[22310.416482] phy1: Selected rate control algorithm 'minstrel'
[22310.417403] Registered led device: rt2800usb-phy1::radio
[22310.417456] Registered led device: rt2800usb-phy1::assoc
[22310.417505] Registered led device: rt2800usb-phy1::quality
[22310.479159] udev: renamed network interface wlan0 to wlan2
[22310.483779] rt2800usb 5-2.4:1.0: firmware: requesting rt2870.bin
Now, modinfo rt2800usb |grep 3070 -- shows its OK:
alias: usb:v148Fp3070d*dc*dsc*dp*ic*isc*ip*
This is a longstanding bug from at least few months or so, I thought you were experimenting/adjusting the code and I figured it would be temporary, but it has been so long that I thought I had to report this now.
Walter.
^ permalink raw reply
* Re: [PATCH] mac80211: document IEEE80211_CONF_CHANGE_QoS
From: Pavel Roskin @ 2010-04-19 15:57 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Reinette Chatre, John W. Linville, wey-yi.w.guy,
Johannes Berg
In-Reply-To: <20100419092451.GA2696@dhcp-lab-161.englab.brq.redhat.com>
On Mon, 2010-04-19 at 11:24 +0200, Stanislaw Gruszka wrote:
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index dcf3c5f..97b2222 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -610,6 +610,7 @@ enum ieee80211_conf_flags {
> * @IEEE80211_CONF_CHANGE_RETRY_LIMITS: retry limits changed
> * @IEEE80211_CONF_CHANGE_IDLE: Idle flag changed
> * @IEEE80211_CONF_CHANGE_SMPS: Spatial multiplexing powersave mode changed
> + * @IEEE80211_CONF_CHANGE_QoS: Quality of service was enabled or disabled
Let's make it uppercase, please. The actual code is already uppercase.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Request for releasing b43-fwcutter
From: Michael Buesch @ 2010-04-19 15:53 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: b43-dev, linux-wireless
In-Reply-To: <k2kb170af451004190754udb8e9960h8a3cfe703566e76f@mail.gmail.com>
On Monday 19 April 2010 16:54:23 Rafał Miłecki wrote:
> Could you consider releasing new version of b43-fwcutter, as we
> already have LP-PHY support in kernel, please? AFAIK ppl need to use
> git version currently to extract firmware.
Good idea. I released b43-fwcutter-013.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH v3 42/97] ath9k: Make bf_desc of ath_buf opaque
From: Pavel Roskin @ 2010-04-19 15:53 UTC (permalink / raw)
To: Felix Fietkau
Cc: Luis R. Rodriguez, linville, linux-wireless,
Vasanthakumar Thiagarajan
In-Reply-To: <4BC8E027.1030807@openwrt.org>
On Sat, 2010-04-17 at 00:09 +0200, Felix Fietkau wrote:
> > The obvious downside is that bf_desc becomes compatible with pointers of
> > any type.
> Because on AR9300 where it's used, it points to a struct ar9003_txc instead.
OK, fair enough.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] ath9k-htc: speedup disconnect handling
From: tom.leiming @ 2010-04-19 15:44 UTC (permalink / raw)
To: Sujith.Manoharan, lrodriguez; +Cc: linux-wireless, linville, Ming Lei
From: Ming Lei <tom.leiming@gmail.com>
This patch detects the disconnect in wmi register write path,
then speedup the disconnect handling.
---
drivers/net/wireless/ath/ath9k/hw.c | 2 ++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/wmi.c | 8 ++++++++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 9aa40df..bcc48ff 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -111,6 +111,8 @@ bool ath9k_hw_wait(struct ath_hw *ah, u32 reg, u32 mask, u32 val, u32 timeout)
BUG_ON(timeout < AH_TIME_QUANTUM);
for (i = 0; i < (timeout / AH_TIME_QUANTUM); i++) {
+ if (AR_SREV_9271(ah) && ah->htc_disconnected)
+ break;
if ((REG_READ(ah, reg) & mask) == val)
return true;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 8158e8e..6b22158 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -635,6 +635,7 @@ struct ath_hw {
u32 ah_flags;
bool htc_reset_init;
+ bool htc_disconnected;
enum nl80211_iftype opmode;
enum ath9k_power_mode power_mode;
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index dc6c6fc..fbd44c7 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -279,6 +279,9 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
if (!wmi)
return -EINVAL;
+ if (ah->htc_disconnected)
+ return -ENODEV;
+
skb = alloc_skb(headroom + cmd_len, GFP_ATOMIC);
if (!skb)
return -ENOMEM;
@@ -324,6 +327,11 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
return 0;
out:
+ if (ret == -ENODEV) {
+ ah->htc_disconnected = 1;
+ ath_print(common, ATH_DBG_WMI,"HTC disconnected!\n");
+ }
+
ath_print(common, ATH_DBG_WMI,
"WMI failure for: %s\n", wmi_cmd_to_name(cmd_id));
mutex_unlock(&wmi->op_mutex);
--
1.6.2.5
^ permalink raw reply related
* Re: b43 'hardware blocked' but only keyboard/led touch button
From: Matthew Garrett @ 2010-04-19 15:06 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <20100419150050.GA28290@frolo.macqel>
On Mon, Apr 19, 2010 at 05:00:50PM +0200, Philippe De Muyter wrote:
> On Mon, Apr 19, 2010 at 03:51:07PM +0100, Matthew Garrett wrote:
> > On Mon, Apr 19, 2010 at 01:53:29PM +0200, Philippe De Muyter wrote:
> >
> > > and the blue/red led doesn't change color, and wifi state does not change
> > > either.
> >
> > What's the output of the rfkill command now?
>
> Sorry, I cannot answer before friday (not my laptop).
No problem. The best command to run will be
rfkill list
and then just attach the output.
Thanks,
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: b43 'hardware blocked' but only keyboard/led touch button
From: Philippe De Muyter @ 2010-04-19 15:00 UTC (permalink / raw)
To: Matthew Garrett; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <20100419145107.GB8017@srcf.ucam.org>
On Mon, Apr 19, 2010 at 03:51:07PM +0100, Matthew Garrett wrote:
> On Mon, Apr 19, 2010 at 01:53:29PM +0200, Philippe De Muyter wrote:
>
> > and the blue/red led doesn't change color, and wifi state does not change
> > either.
>
> What's the output of the rfkill command now?
Sorry, I cannot answer before friday (not my laptop).
Philippe
^ permalink raw reply
* Request for releasing b43-fwcutter
From: Rafał Miłecki @ 2010-04-19 14:54 UTC (permalink / raw)
To: Michael Buesch; +Cc: b43-dev, linux-wireless
Hi Michael,
Could you consider releasing new version of b43-fwcutter, as we
already have LP-PHY support in kernel, please? AFAIK ppl need to use
git version currently to extract firmware.
--
Rafał
^ permalink raw reply
* Re: b43 'hardware blocked' but only keyboard/led touch button
From: Matthew Garrett @ 2010-04-19 14:51 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <20100419115329.GA5306@frolo.macqel>
On Mon, Apr 19, 2010 at 01:53:29PM +0200, Philippe De Muyter wrote:
> and the blue/red led doesn't change color, and wifi state does not change
> either.
What's the output of the rfkill command now?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value
From: Johannes Berg @ 2010-04-19 14:43 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1271409274-17162-3-git-send-email-juuso.oikarinen@nokia.com>
On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> Now that the mac80211 is choosing dynamic ps timeouts based on the ps-qos
> network latency configuration, configure a default value of -1 as the dynamic
> ps timeout in cfg80211. This value allows the mac80211 to determine the value
> to be used.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> net/wireless/core.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index 6ac70c1..37d0e0a 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -705,7 +705,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block * nb,
> wdev->ps = true;
> else
> wdev->ps = false;
> - wdev->ps_timeout = 100;
> + /* allow mac80211 to determine the timeout */
> + wdev->ps_timeout = -1;
> if (rdev->ops->set_power_mgmt)
> if (rdev->ops->set_power_mgmt(wdev->wiphy, dev,
> wdev->ps,
Does that need some API doc updates to indicate, as part of the cfg80211
API, that -1 means some way of setting it by default?
Or actually, wouldn't it make sense to move the pm_qos logic here (into
cfg80211)?
johannes
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Johannes Berg @ 2010-04-19 14:42 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1271409274-17162-2-git-send-email-juuso.oikarinen@nokia.com>
On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> Determine the dynamic PS timeout based on the configured ps-qos network
> latency. For backwards wext compatibility, allow the dynamic PS timeout
> configured by the cfg80211 to overrule the automatically determined value.
This seems OK, but I fear that you'll write applications setting the
pm_qos network latency just to affect this parameter?
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> include/net/mac80211.h | 5 ++++-
> net/mac80211/cfg.c | 4 ++--
> net/mac80211/main.c | 2 ++
> net/mac80211/mlme.c | 14 ++++++++++++++
> 4 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index dcf3c5f..243e4ab 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -661,6 +661,9 @@ enum ieee80211_smps_mode {
> * @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
> * powersave documentation below. This variable is valid only when
> * the CONF_PS flag is set.
> + * @dynamic_ps_forced_timeout: The dynamic powersave timeout (in ms) configured
> + * by cfg80211 (essentially, wext) If set, this value overrules the value
> + * chosen by mac80211 based on ps qos network latency.
> *
> * @power_level: requested transmit power (in dBm)
> *
> @@ -680,7 +683,7 @@ enum ieee80211_smps_mode {
> */
> struct ieee80211_conf {
> u32 flags;
> - int power_level, dynamic_ps_timeout;
> + int power_level, dynamic_ps_timeout, dynamic_ps_forced_timeout;
> int max_sleep_period;
>
> u16 listen_interval;
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 7dd7cda..9a1a91c 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1388,11 +1388,11 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
> return -EOPNOTSUPP;
>
> if (enabled == sdata->u.mgd.powersave &&
> - timeout == conf->dynamic_ps_timeout)
> + timeout == conf->dynamic_ps_forced_timeout)
> return 0;
>
> sdata->u.mgd.powersave = enabled;
> - conf->dynamic_ps_timeout = timeout;
> + conf->dynamic_ps_forced_timeout = timeout;
>
> /* no change, but if automatic follow powersave */
> mutex_lock(&sdata->u.mgd.mtx);
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index 4afe851..ebcca0e 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -569,6 +569,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
>
> local->hw.conf.listen_interval = local->hw.max_listen_interval;
>
> + local->hw.conf.dynamic_ps_forced_timeout = -1;
> +
> result = sta_info_start(local);
> if (result < 0)
> goto fail_sta_info;
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 35d8502..6402997 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -476,6 +476,7 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
> {
> struct ieee80211_sub_if_data *sdata, *found = NULL;
> int count = 0;
> + int timeout;
>
> if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS)) {
> local->ps_sdata = NULL;
> @@ -509,6 +510,19 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
> beaconint_us = ieee80211_tu_to_usec(
> found->vif.bss_conf.beacon_int);
>
> + timeout = local->hw.conf.dynamic_ps_forced_timeout;
> + if (timeout < 0) {
> + if (latency <= 50000)
> + timeout = 300;
> + else if (latency <= 2000000000)
> + timeout = 100;
> + else if (latency <= 2100000000)
> + timeout = 50;
> + else
> + timeout = 0;
Is it even possible to set it larger than 2000 seconds?
johannes
^ permalink raw reply
* Re: [PATCH 8/9] ath9k: add support for Tx and Rx STBC
From: Felix Fietkau @ 2010-04-19 12:28 UTC (permalink / raw)
To: Björn Smedman
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
lrodriguez@atheros.com
In-Reply-To: <g2i133e8d7e1004190522n7dff80c3v1238a9f72cff734f@mail.gmail.com>
On 19.04.2010, at 14:22, Björn Smedman <bjorn.smedman@venatech.se>
wrote:
> Hi all,
>
> Is STBC not supported on any chipsets other than
> AR_SREV_9280_10_OR_LATER(ah)?
Right. AR9160 and older do not support this - at least according to
sources and datasheets.
- Felix
^ permalink raw reply
* Re: [PATCH 8/9] ath9k: add support for Tx and Rx STBC
From: Björn Smedman @ 2010-04-19 12:22 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <1271602602-8538-8-git-send-email-nbd@openwrt.org>
Hi all,
Is STBC not supported on any chipsets other than AR_SREV_9280_10_OR_LATER(ah)?
/Björn
On Sun, Apr 18, 2010 at 4:56 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> Supported only for single stream rates by the hardware
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> ---
> drivers/net/wireless/ath/ath9k/init.c | 6 ++++++
> drivers/net/wireless/ath/ath9k/mac.h | 8 +++++++-
> drivers/net/wireless/ath/ath9k/xmit.c | 2 ++
> 3 files changed, 15 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index 2c0630e..8c79548 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -216,6 +216,12 @@ static void setup_ht_cap(struct ath_softc *sc,
> else
> max_streams = 2;
>
> + if (AR_SREV_9280_10_OR_LATER(ah)) {
> + if (max_streams >= 2)
> + ht_info->cap |= IEEE80211_HT_CAP_TX_STBC;
> + ht_info->cap |= (1 << IEEE80211_HT_CAP_RX_STBC_SHIFT);
> + }
> +
> /* set up supported mcs set */
> memset(&ht_info->mcs, 0, sizeof(ht_info->mcs));
> tx_streams = count_streams(common->tx_chainmask, max_streams);
> diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
> index 66d0d5e..00f3e0c 100644
> --- a/drivers/net/wireless/ath/ath9k/mac.h
> +++ b/drivers/net/wireless/ath/ath9k/mac.h
> @@ -37,6 +37,8 @@
> AR_2040_##_index : 0) \
> |((_series)[_index].RateFlags & ATH9K_RATESERIES_HALFGI ? \
> AR_GI##_index : 0) \
> + |((_series)[_index].RateFlags & ATH9K_RATESERIES_STBC ? \
> + AR_STBC##_index : 0) \
> |SM((_series)[_index].ChSel, AR_ChainSel##_index))
>
> #define CCK_SIFS_TIME 10
> @@ -434,7 +436,10 @@ struct ar5416_desc {
> #define AR_ChainSel3_S 17
> #define AR_RTSCTSRate 0x0ff00000
> #define AR_RTSCTSRate_S 20
> -#define AR_TxCtlRsvd70 0xf0000000
> +#define AR_STBC0 0x10000000
> +#define AR_STBC1 0x20000000
> +#define AR_STBC2 0x40000000
> +#define AR_STBC3 0x80000000
>
> #define AR_TxRSSIAnt00 0x000000ff
> #define AR_TxRSSIAnt00_S 0
> @@ -647,6 +652,7 @@ enum ath9k_rx_filter {
> #define ATH9K_RATESERIES_RTS_CTS 0x0001
> #define ATH9K_RATESERIES_2040 0x0002
> #define ATH9K_RATESERIES_HALFGI 0x0004
> +#define ATH9K_RATESERIES_STBC 0x0008
>
> struct ath9k_11n_rate_series {
> u32 Tries;
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index 2237658..b0d345a 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -1607,6 +1607,8 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf)
> series[i].Rate = rix | 0x80;
> series[i].PktDuration = ath_pkt_duration(sc, rix, bf,
> is_40, is_sgi, is_sp);
> + if (rix < 8 && (tx_info->flags & IEEE80211_TX_CTL_STBC))
> + series[i].RateFlags |= ATH9K_RATESERIES_STBC;
> continue;
> }
>
> --
> 1.6.4.2
>
> --
> 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
>
--
Venatech AB
Ideon Innovation
Ole Römers väg 12
SE-22370 LUND
Sweden
+46 (0) 46 286 86 20
info@venatech.se
http://www.venatech.se
^ permalink raw reply
* Re: b43 'hardware blocked' but only keyboard/led touch button
From: Philippe De Muyter @ 2010-04-19 11:53 UTC (permalink / raw)
To: Matthew Garrett; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <20100330193129.GA31847@srcf.ucam.org>
On Tue, Mar 30, 2010 at 08:31:29PM +0100, Matthew Garrett wrote:
> On Tue, Mar 30, 2010 at 09:26:29PM +0200, Philippe De Muyter wrote:
>
> > I must also add that I currently cannot boot without acpi=off
>
> That's your bug, then.
I now boot with acpi.
Summary : I have a hp pavilion dv6-1300sb laptop with a b43 wifi device,
and a touchkey to disable or enable wifi with a red/blue led as feedback.
hp-wmi is loaded
when I touch the wifi key, I get the following messages (with 2.6.34-rc4) :
[ 256.039395] atkbd.c: Unknown key pressed (translated set 2, code 0x94 on isa0060/serio0).
[ 256.039408] atkbd.c: Use 'setkeycodes e014 <keycode>' to make it known.
[ 256.062313] atkbd.c: Unknown key released (translated set 2, code 0x94 on isa0060/serio0).
[ 256.062321] atkbd.c: Use 'setkeycodes e014 <keycode>' to make it known.
and the blue/red led doesn't change color, and wifi state does not change
either.
Any hint ?
Philippe
^ permalink raw reply
* Re: [PATCH] mac80211: fix stopping RX BA session from timer
From: Kalle Valo @ 2010-04-19 11:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1271667624.3873.12.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> Kalle reported that his system deadlocks since my
> recent work in this area. The reason quickly became
> apparent: we try to cancel_timer_sync() a timer
> from within itself. Fix that by making the function
> aware of the context it is called from.
I have now tested this for an hour and I can't reproduce the problem
anymore, earlier I was able to reproduce at least within a minute or
so. So I'm confident that the problem I saw is this fixed by this
patch.
Thank you very much for fixing this so quickly.
> Reported-by: Kalle Valo <kvalo@adurom.com>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Kalle Valo <kvalo@adurom.com>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Felix Fietkau @ 2010-04-19 10:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <1271672347.3873.18.camel@jlt3.sipsolutions.net>
On 2010-04-19 12:19 PM, Johannes Berg wrote:
> On Mon, 2010-04-19 at 12:14 +0200, Felix Fietkau wrote:
>> On 2010-04-19 11:09 AM, Johannes Berg wrote:
>> > On Mon, 2010-04-19 at 11:06 +0200, Felix Fietkau wrote:
>> >> On 2010-04-19 10:59 AM, Johannes Berg wrote:
>> >> > On Mon, 2010-04-19 at 10:45 +0200, Felix Fietkau wrote:
>> >> >> On 2010-04-19 7:57 AM, Johannes Berg wrote:
>> >> >> > On Sun, 2010-04-18 at 18:05 +0200, Felix Fietkau wrote:
>> >> >> >
>> >> >> >> >> + * @IEEE80211_TX_CTL_STBC: tells the driver to use Space-Time Block Coding
>> >> >> >> >> + * (STBC) for this frame.
>> >> >> >> >> */
>> >> >> >> >> enum mac80211_tx_control_flags {
>> >> >> >> >> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
>> >> >> >> >> @@ -299,6 +301,7 @@ enum mac80211_tx_control_flags {
>> >> >> >> >> IEEE80211_TX_INTFL_HAS_RADIOTAP = BIT(20),
>> >> >> >> >> IEEE80211_TX_INTFL_NL80211_FRAME_TX = BIT(21),
>> >> >> >> >> IEEE80211_TX_CTL_LDPC = BIT(22),
>> >> >> >> >> + IEEE80211_TX_CTL_STBC = BIT(23),
>> >> >> >> >
>> >> >> >> > What if the # of streams is different? That doesn't look sufficient.
>> >> >> >
>> >> >> >> Hm, you're right. I initially thought the combination of the MCS index
>> >> >> >> and the STBC flag would be enough, but there are still some corner cases.
>> >> >> >
>> >> >> > Hm actually I guess that should be sufficient? What corner case are you
>> >> >> > thinking of?
>> >> >> Support for multi-rate retry and STBC with more than one stream on one
>> >> >> side, using rates from both MCS0-7 and MCS8-15 in the rate series.
>> >> >> Rx STBC for only one stream on the other side.
>> >> >
>> >> > So the flag should be per rate entry instead, no?
>> >
>> >> Well, I think if we use two bits in the tx control flags, we don't need
>> >> it to be per rate entry.
>> >
>> > But then you can't probe stbc properly, can you?
>> I'm not sure we even need to probe STBC. In all of the drivers that I've
>> looked at, it's always enabled if the peer supports it.
>> I'm not aware of any situation where it would make the reception worse,
>> aside from hardware damage of course ;)
>
> Ok ... I guess two bits then so you don't have to look up sta capability
> when doing the hw programming?
Right. I'll send a new series later.
- Felix
^ permalink raw reply
* Re: [PATCH 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Johannes Berg @ 2010-04-19 10:19 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <4BCC2D1E.4000408@openwrt.org>
On Mon, 2010-04-19 at 12:14 +0200, Felix Fietkau wrote:
> On 2010-04-19 11:09 AM, Johannes Berg wrote:
> > On Mon, 2010-04-19 at 11:06 +0200, Felix Fietkau wrote:
> >> On 2010-04-19 10:59 AM, Johannes Berg wrote:
> >> > On Mon, 2010-04-19 at 10:45 +0200, Felix Fietkau wrote:
> >> >> On 2010-04-19 7:57 AM, Johannes Berg wrote:
> >> >> > On Sun, 2010-04-18 at 18:05 +0200, Felix Fietkau wrote:
> >> >> >
> >> >> >> >> + * @IEEE80211_TX_CTL_STBC: tells the driver to use Space-Time Block Coding
> >> >> >> >> + * (STBC) for this frame.
> >> >> >> >> */
> >> >> >> >> enum mac80211_tx_control_flags {
> >> >> >> >> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
> >> >> >> >> @@ -299,6 +301,7 @@ enum mac80211_tx_control_flags {
> >> >> >> >> IEEE80211_TX_INTFL_HAS_RADIOTAP = BIT(20),
> >> >> >> >> IEEE80211_TX_INTFL_NL80211_FRAME_TX = BIT(21),
> >> >> >> >> IEEE80211_TX_CTL_LDPC = BIT(22),
> >> >> >> >> + IEEE80211_TX_CTL_STBC = BIT(23),
> >> >> >> >
> >> >> >> > What if the # of streams is different? That doesn't look sufficient.
> >> >> >
> >> >> >> Hm, you're right. I initially thought the combination of the MCS index
> >> >> >> and the STBC flag would be enough, but there are still some corner cases.
> >> >> >
> >> >> > Hm actually I guess that should be sufficient? What corner case are you
> >> >> > thinking of?
> >> >> Support for multi-rate retry and STBC with more than one stream on one
> >> >> side, using rates from both MCS0-7 and MCS8-15 in the rate series.
> >> >> Rx STBC for only one stream on the other side.
> >> >
> >> > So the flag should be per rate entry instead, no?
> >
> >> Well, I think if we use two bits in the tx control flags, we don't need
> >> it to be per rate entry.
> >
> > But then you can't probe stbc properly, can you?
> I'm not sure we even need to probe STBC. In all of the drivers that I've
> looked at, it's always enabled if the peer supports it.
> I'm not aware of any situation where it would make the reception worse,
> aside from hardware damage of course ;)
Ok ... I guess two bits then so you don't have to look up sta capability
when doing the hw programming?
johannes
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: Use high bitrates for ACK/CTS
From: Gábor Stefanik @ 2010-04-19 10:14 UTC (permalink / raw)
To: Bruno Randolf; +Cc: Stanislaw Gruszka, linville, ath5k-devel, linux-wireless
In-Reply-To: <201004190924.25709.br1@einfach.org>
On Mon, Apr 19, 2010 at 2:24 AM, Bruno Randolf <br1@einfach.org> wrote:
> On Friday 16 April 2010 22:59:07 Stanislaw Gruszka wrote:
>> On Mon, 12 Apr 2010 16:38:47 +0900
>>
>> Bruno Randolf <br1@einfach.org> wrote:
>> > There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB
>> > and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower
>> > bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah,
>> > false) actually resulted in high bitrates, which i think is what we want
>> > anyways. Cleared the confusion and added some documentation.
>>
>> I thought ACK and other control frames have to be modulated at slow/robust
>> bitrates, but can't remember where I read that ...
>
> this has been discussed on ath5k-devel before. i'm copying it here. please let
> me know if i missed something...
>
> (https://lists.ath5k.org/pipermail/ath5k-devel/2010-March/003391.html)
>
> control frames have to be sent at one of the lower bitrates - one of the
> "basic rates". in G mode these are 1, 2, 5.5, 11, 6, 12, 24Mbps.
Aren't basic rates defined so as to exclude any OFDM rates? I.e. are
6M, 12M and 24M really basic rates?
>
> this is from the 802.11g spec:
> "a STA responding to a received frame shall transmit its Control Response
> (either CTS or ACK) frames at the highest rate in the BSSBasicRateSet that is
> less than or equal to the rate of the immediately previous frame in the frame
> exchange sequence (as defined in 9.7)"
>
> basically we have to make a tradeoff here: using lower rates for ACK/CTS will
> improve reliability, but lower performance. for example i could get only
> 10Mbps truput with ACK/CTS at the lowest bitrates and RTS/CTS enabled
> (iwconfig wlan0 rts 250) and i can get more than 20Mbps with higher bitrates.
> so i think it's worth to use high bitrates. actually also this should be
> tuneable for the user, too...
>
> bruno
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ 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