* iwlwifi 4965 uCode available
From: reinette chatre @ 2009-07-09 21:21 UTC (permalink / raw)
To: linux-wireless, ipw3945-devel
Version 228.61.2.24 of uCode for Intel Wireless WiFi Link 4965AGN is now
available for download from
http://intellinuxwireless.org/?n=Downloads
Changes:
-- More graceful handling of Rx hangs (NMI)
-- More reliable scanning
-- Wait 10 seconds after association before power down
-- Reset receiver via retune after missing beacons
-- Disable TGK measurement when receiving packet
-- More reliable Tx of ACK/BA/CTS
Reinette
^ permalink raw reply
* [PATCH] ath9k: Fix enabling OFDM weak signal detection
From: Steven Luo @ 2009-07-09 21:12 UTC (permalink / raw)
To: John W. Linville
Cc: Luis R. Rodriguez, Jouni Malinen, Sujith Manoharan,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
linux-wireless, ath9k-devel
From: Steven Luo <steven@steven676.net>
It seems that OFDM weak signal detection should be enabled after an ANI
state reset, as indicated by the initial setting of ofdmWeakSigDetectOff
and what the open Atheros HAL does. Unfortunately, the reversed sense
of ofdmWeakSigDetectOff (true if weak signal detection is NOT enabled)
seems to have resulted in a mixup here, causing weak signal detection to
be disabled.
This patch significantly improves reception and throughput from distant
stations for my AR5416-based AP running compat-wireless 2009-06-25.
Signed-off-by: Steven Luo <steven@steven676.net>
Cc: stable@kernel.org
---
--- a/drivers/net/wireless/ath/ath9k/ani.c 2009-06-24 21:14:00.000000000 -0700
+++ b/drivers/net/wireless/ath/ath9k/ani.c 2009-07-06 02:45:57.000000000 -0700
@@ -482,7 +482,7 @@ void ath9k_ani_reset(struct ath_hw *ah)
ath9k_hw_ani_control(ah, ATH9K_ANI_SPUR_IMMUNITY_LEVEL, 0);
ath9k_hw_ani_control(ah, ATH9K_ANI_FIRSTEP_LEVEL, 0);
ath9k_hw_ani_control(ah, ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
- !ATH9K_ANI_USE_OFDM_WEAK_SIG);
+ ATH9K_ANI_USE_OFDM_WEAK_SIG);
ath9k_hw_ani_control(ah, ATH9K_ANI_CCK_WEAK_SIGNAL_THR,
ATH9K_ANI_CCK_WEAK_SIG_THR);
^ permalink raw reply
* Re: p54usb - problems with "no probe,response from AP ..."
From: Christian Lamparter @ 2009-07-09 21:01 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4A5645A3.9000906@lwfinger.net>
On Thursday 09 July 2009 21:31:47 Larry Finger wrote:
> Christian,
>
> I have not gotten very far with the problem in the subject; however, I
> have a few things to report:
>
> I got a dump of the TX queues when the disassociation event came
> through. All were normal.
normal? as in completely empty? or just a soft dribble (possibly stalled)?
> I tested with 2.6.31-rc2 from Linus's tree. It does _NOT_ have the
> problem, thus it is something that was introduced in the process of
> splitting p54common.{ch} into the component parts.
>
> In comparing the code, I see that the variable 'cached_beacon' was
> eliminated and the code that handles beacons was changed. When I made
> the following change, the "no probe response" message went away - the
> interface just hangs:
cached_beacon is only relevant when you run an AP/MESH/(IBSS).
The cached_beacon code was removed because its very racy
(we never knew whenever the pointer was still valid, as p54_free_skb
could have freed that buffer already and did not NULL out the reference).
The replacement "beacon_req_id" suffers from the same flaw,
but at least its save against 2x kfree_skb.
so no, can you still toggle the LEDs (e.g /sys/class interface)
when the interface hangs? or is there some traffic
on a cooked monitor interface?
(iw phy phyX interface add monX type monitor; ifconfig monX up)
what could be related to that issue... and maybe even explain why I don't have
the very same issues are transmission errors:
---
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index e44460f..c0c2817 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -111,10 +111,12 @@ static void p54u_rx_cb(struct urb *urb)
struct p54u_rx_info *info = (struct p54u_rx_info *)skb->cb;
struct ieee80211_hw *dev = info->dev;
struct p54u_priv *priv = dev->priv;
+ int err;
skb_unlink(skb, &priv->rx_queue);
if (unlikely(urb->status)) {
+ printk(KERN_INFO "lost rx urb (%d)\n", urb->status);
dev_kfree_skb_irq(skb);
return;
}
@@ -153,7 +155,8 @@ static void p54u_rx_cb(struct urb *urb)
}
skb_queue_tail(&priv->rx_queue, skb);
usb_anchor_urb(urb, &priv->submitted);
- if (usb_submit_urb(urb, GFP_ATOMIC)) {
+ if ((err = usb_submit_urb(urb, GFP_ATOMIC))) {
+ printk(KERN_INFO "could not resubmit rx urb (%d)\n", err);
skb_unlink(skb, &priv->rx_queue);
usb_unanchor_urb(urb);
dev_kfree_skb_irq(skb);
@@ -244,9 +247,11 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev, struct sk_buff *skb)
struct p54u_priv *priv = dev->priv;
struct urb *data_urb;
struct lm87_tx_hdr *hdr = (void *)skb->data - sizeof(*hdr);
+ int err;
data_urb = usb_alloc_urb(0, GFP_ATOMIC);
if (!data_urb) {
+ printk(KERN_ERR "could not alloc tx urb - oom\n");
p54_free_skb(dev, skb);
return;
}
@@ -261,7 +266,8 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev, struct sk_buff *skb)
data_urb->transfer_flags |= URB_ZERO_PACKET;
usb_anchor_urb(data_urb, &priv->submitted);
- if (usb_submit_urb(data_urb, GFP_ATOMIC)) {
+ if ((err = usb_submit_urb(data_urb, GFP_ATOMIC))) {
+ printk(KERN_ERR "xmit urb failed (%d)\n", err);
usb_unanchor_urb(data_urb);
p54_free_skb(dev, skb);
}
---
if that doesn't work out (which will inevitably happen)...
I'm really out of ideas and if you can I request an (usbmon -iX -s 2400) dump
for inspiration from a crash/stall. Of course, it doesn't need to be
the whole log (~ 5 before and 20 after the freeze/disassoc) should be
more than enough to hopefully spot that *********** bug inside the driver.
Regards,
Chr
^ permalink raw reply related
* Re: Problem with p54 driver and ibss mode
From: Kalle Valo @ 2009-07-09 19:55 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Max Filippov, Alexander Wenzel, linux-wireless
In-Reply-To: <200907092056.53055.chunkeey@web.de>
Christian Lamparter <chunkeey@web.de> writes:
>> These data for sure must reside on /dev/mtdblk1 partition, but
>> they're probably somehow coded/obfuscated. I couldn't find anything
>> similar to MAC of my own n810 there.
>
> well, this is c0ffee comes from nokia's stlc45xx-driver.
> Unfortunately, they don't say how to get the device eeprom from the
> mtdblk1 partition. However, they certainly provide a tool stlc45xx-cal
> (available at: http://stlc45xx.garage.maemo.org/ ) which can be used
> to locate the eeprom's calibration data.
stlc45xx-cal pushes the device specific calibration data and sets the
MAC address. It's recommended to run it to get optimal performance.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6 2.6.31 and w-t] iwlwifi: only show active power level via sysfs
From: Kalle Valo @ 2009-07-09 19:49 UTC (permalink / raw)
To: Reinette Chatre; +Cc: linville, linux-wireless, ipw3945-devel, stable
In-Reply-To: <1247160821-14989-3-git-send-email-reinette.chatre@intel.com>
Reinette Chatre <reinette.chatre@intel.com> writes:
> From: Reinette Chatre <reinette.chatre@intel.com>
>
> This changes the power_level file to adhere to the "one value
> per file" sysfs rule. The user will know which power level was
> requested as it will be the number just written to this file. It
> is thus not necessary to create a new sysfs file for this value.
>
> In addition it fixes a problem where powertop's parsing expects
> this value to be the first value in this file without any descriptions.
In the future we need to drop all the driver private interfaces and use
nl80211/wext instead[1]. As this patch shows, they just create problems
for us. I recommend deprecating the file in question as soon as possible
and instead start using proper interfaces.
[1] Even though nl80211 is lacking power save support, but that will be
fixed soon. Use wext for now.
--
Kalle Valo
^ permalink raw reply
* p54usb - problems with "no probe,response from AP ..."
From: Larry Finger @ 2009-07-09 19:31 UTC (permalink / raw)
To: Chr; +Cc: wireless
Christian,
I have not gotten very far with the problem in the subject; however, I
have a few things to report:
I got a dump of the TX queues when the disassociation event came
through. All were normal.
I tested with 2.6.31-rc2 from Linus's tree. It does _NOT_ have the
problem, thus it is something that was introduced in the process of
splitting p54common.{ch} into the component parts.
In comparing the code, I see that the variable 'cached_beacon' was
eliminated and the code that handles beacons was changed. When I made
the following change, the "no probe response" message went away - the
interface just hangs:
Index: wireless-testing/drivers/net/wireless/p54/txrx.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/p54/txrx.c
+++ wireless-testing/drivers/net/wireless/p54/txrx.c
@@ -386,7 +386,8 @@ static void p54_rx_frame_sent(struct p54
priv->beacon_req_id = cpu_to_le32(0);
dev_kfree_skb_any(entry);
- return ;
+ p54_wake_queues(priv);
+ return;
}
/*
Any thoughts?
Larry
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Christian Lamparter @ 2009-07-09 18:56 UTC (permalink / raw)
To: Max Filippov; +Cc: Alexander Wenzel, linux-wireless
In-Reply-To: <200907092157.21784.jcmvbkbc@gmail.com>
On Thursday 09 July 2009 19:57:20 Max Filippov wrote:
> В сообщении от Thursday 09 July 2009 Alexander Wenzel написал(a):
^^
> > Hi!
> > >> I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
> > >> to work on a Nokia N810... So far, without any success.
> > >> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
> > > As far as I can see, this is check that incoming STA and your STA have
> > > different MAC addresses. If you don't set up MAC manually on both
> > > devices and make it unique, chances high that they are equal.
> >
> > You saved my day :D Finally it works...! Thanks for the hint.
> >
> > [ 214.478668] wlan0: Selected IBSS BSSID 56:97:1a:24:11:6c based on configured SSID
> >
> > # iw dev wlan0 station dump
> > Station 00:02:ee:c0:ff:ee (on wlan0)
> > inactive time: 429 ms
> > rx bytes: 8964
> > tx bytes: 408
> > signal: 55 dBm
> > tx bitrate: 1.0 MBit/s
> >
> > I just checked the other N810 devices and every device has
> > the same mac address. And here we go... [p54spi_eeprom.h:39]
> > 0x00, 0x02, 0xee, 0xc0, 0xff, 0xee,
> >
> > The original kernel with default os shows the correct address.
> > When booting a different os with the with the original or custom
> > kernel it shows the 'coffee' address.
> > So is there a way to let the kernel receive and set the
> > correct mac address of the wlan device?
> > I guess my problem is this line:
> > [ 3685.320800] cx3110x spi2.0: loading default eeprom...
>
> You're right. I guess that easiest way to deal with it is to save blob from p54spi_eeprom.h into a file
> 3826.eeprom in the same directory as 3826.arm and fix MAC address in it, according to comments in p54spi_eeprom.h
>
> These data for sure must reside on /dev/mtdblk1 partition, but they're probably somehow coded/obfuscated.
> I couldn't find anything similar to MAC of my own n810 there.
well, this is c0ffee comes from nokia's stlc45xx-driver.
Unfortunately, they don't say how to get the device eeprom from the mtdblk1
partition. However, they certainly provide a tool stlc45xx-cal
(available at: http://stlc45xx.garage.maemo.org/ ) which can be used
to locate the eeprom's calibration data.
and by the way. If there is no mac field inside the eeprom image,
the driver will generate a random one all the time...
Regards,
Chr
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Bob Copeland @ 2009-07-09 18:44 UTC (permalink / raw)
To: Jasin Colegrove; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <6c354a1a0907091136v5619efb5oc6a8a89ec24d4e74@mail.gmail.com>
On Thu, Jul 9, 2009 at 2:36 PM, Jasin
Colegrove<j.wholesalesupply@gmail.com> wrote:
> When running git bisect it keeps building 2.6.29-rc kernels. I thought
> v2.6.29 was in the future compared to 2.6.29-rc7 for example.
> running the command git bisect start v2.6.29-rc7 v2.6.29 disagrees
> though and tells me.
>
> It co's a commit somewhere around 2.6.29-rc7 which ultimately was a
> bad commit. Am I misunderstanding how this all works? Sorry to be a
> pain
That confuses everyone the first time. Basically the way it works
is that a commit that was authored before 2.6.29 will still be checked
since it was only merged in 2.6.29.
+--- B -- D -+
/ \
-- A -- C ---- E -- F -- G
e.g. in the above graph, imagine E is 2.6.29 and G is 2.6.30. Commits
B and D were written from a base of 2.6.29-rc6 (say) but merged at time
F between 2.6.29 and 2.6.30. The bisect will check both parents of F if
it needs to since that's when it actually hit the mainline.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Jasin Colegrove @ 2009-07-09 18:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <43e72e890907091050p7bc08a25s86f9bb7a1c8740aa@mail.gmail.com>
I got one more question and it's driving me mad. I am really confused...
When running git bisect it keeps building 2.6.29-rc kernels. I thought
v2.6.29 was in the future compared to 2.6.29-rc7 for example.
running the command git bisect start v2.6.29-rc7 v2.6.29 disagrees
though and tells me.
$ git bisect start v2.6.29-rc7 v2.6.29
Some good revs are not ancestor of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistake good and bad revs?
But, when I run the command
$ git bisect start v2.6.30 v2.6.29
It co's a commit somewhere around 2.6.29-rc7 which ultimately was a
bad commit. Am I misunderstanding how this all works? Sorry to be a
pain
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Johannes Berg @ 2009-07-09 18:15 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890907091053s59ed356er22c59944efec9a01@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]
On Thu, 2009-07-09 at 10:53 -0700, Luis R. Rodriguez wrote:
> On Thu, Jul 9, 2009 at 4:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> > Hi!
> >
> > With the recent work I've done in cfg80211 for nl80211 and wext, we've
> > mostly removed wext code everywhere. The only thing missing right now is
> > the key support, and I think then we can declare cfg80211's wext compat
> > layer pretty much done in terms of what mac80211 had -- orinoco will
> > need the sensitivity (or AP density) thing but I'm not sure how we
> > should do that since it's a value that is hardware dependent -- we'll
> > need to have very good discovery code for the allowed values (unlike
> > wext where you can set 0..3 and don't know what that means). Anyway,
> > that wasn't the point of this email.
> >
> > Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
> > -Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
> > "disconnect".
>
> When do we disconnect like this? Upon initialization of wpa_supplicant
> -Dwext -Dnl80211 ?
When you shut down wpa_supplicant -Dwext it does that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Problem with p54 driver and ibss mode
From: Max Filippov @ 2009-07-09 17:57 UTC (permalink / raw)
To: Alexander Wenzel; +Cc: linux-wireless
In-Reply-To: <4A560E4B.6080209@fgan.de>
В сообщении от Thursday 09 July 2009 Alexander Wenzel написал(a):
> Hi!
> >> I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
> >> to work on a Nokia N810... So far, without any success.
> >> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
> > As far as I can see, this is check that incoming STA and your STA have
> > different MAC addresses. If you don't set up MAC manually on both
> > devices and make it unique, chances high that they are equal.
>
> You saved my day :D Finally it works...! Thanks for the hint.
>
> [ 214.478668] wlan0: Selected IBSS BSSID 56:97:1a:24:11:6c based on configured SSID
>
> # iw dev wlan0 station dump
> Station 00:02:ee:c0:ff:ee (on wlan0)
> inactive time: 429 ms
> rx bytes: 8964
> tx bytes: 408
> signal: 55 dBm
> tx bitrate: 1.0 MBit/s
>
> I just checked the other N810 devices and every device has
> the same mac address. And here we go... [p54spi_eeprom.h:39]
> 0x00, 0x02, 0xee, 0xc0, 0xff, 0xee,
>
> The original kernel with default os shows the correct address.
> When booting a different os with the with the original or custom
> kernel it shows the 'coffee' address.
> So is there a way to let the kernel receive and set the
> correct mac address of the wlan device?
> I guess my problem is this line:
> [ 3685.320800] cx3110x spi2.0: loading default eeprom...
You're right. I guess that easiest way to deal with it is to save blob from p54spi_eeprom.h into a file
3826.eeprom in the same directory as 3826.arm and fix MAC address in it, according to comments in p54spi_eeprom.h
These data for sure must reside on /dev/mtdblk1 partition, but they're probably somehow coded/obfuscated.
I couldn't find anything similar to MAC of my own n810 there.
Thanks.
-- Max
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Luis R. Rodriguez @ 2009-07-09 17:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247139797.2144.27.camel@johannes.local>
On Thu, Jul 9, 2009 at 4:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> Hi!
>
> With the recent work I've done in cfg80211 for nl80211 and wext, we've
> mostly removed wext code everywhere. The only thing missing right now is
> the key support, and I think then we can declare cfg80211's wext compat
> layer pretty much done in terms of what mac80211 had -- orinoco will
> need the sensitivity (or AP density) thing but I'm not sure how we
> should do that since it's a value that is hardware dependent -- we'll
> need to have very good discovery code for the allowed values (unlike
> wext where you can set 0..3 and don't know what that means). Anyway,
> that wasn't the point of this email.
>
> Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
> -Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
> "disconnect".
When do we disconnect like this? Upon initialization of wpa_supplicant
-Dwext -Dnl80211 ?
Luis
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Luis R. Rodriguez @ 2009-07-09 17:50 UTC (permalink / raw)
To: Bob Copeland; +Cc: Jasin Colegrove, linux-wireless
In-Reply-To: <b6c5339f0907091048v665dcdf6i659e94de95038856@mail.gmail.com>
On Thu, Jul 9, 2009 at 10:48 AM, Bob Copeland<me@bobcopeland.com> wrote:
> On Thu, Jul 9, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>
>>>> $git bisect start v2.6.30-rc4 v2.6.29 -- drivers/net net/
>
>> I'd add net/mac80211 and net/wireless in there as well, just to be safe.
>
> net/ was already in there :)
Ah yes :)
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Johannes Berg @ 2009-07-09 17:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <1247159625.28654.30.camel@mj>
[-- Attachment #1: Type: text/plain, Size: 517 bytes --]
On Thu, 2009-07-09 at 13:13 -0400, Pavel Roskin wrote:
> I think using random data is a problem by itself. Are we exposing
> random pieces of kernel memory in probe requests? That's bad.
You misunderstood. wpa_supplicant _explicitly_ tells us it _wants_ to
use that 32-byte random SSID. It's just like it telling us it wants to
use the ssid "foobar" or "Pavel's House" or ... I don't see what we can
do, other than actually take it seriously and at least attempt to
connect to that network.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Bob Copeland @ 2009-07-09 17:48 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Jasin Colegrove, linux-wireless
In-Reply-To: <43e72e890907091002r2dd36efevbfbce06155beb7e5@mail.gmail.com>
On Thu, Jul 9, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>> $git bisect start v2.6.30-rc4 v2.6.29 -- drivers/net net/
> I'd add net/mac80211 and net/wireless in there as well, just to be safe.
net/ was already in there :)
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH 6/6] iwlagn: fix minimum number of queues setting
From: Reinette Chatre @ 2009-07-09 17:33 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In-Reply-To: <1247160821-14989-6-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
We need to provide a reasonable minimum that will result in a
working setup if used. Set minimum to be 10 to provide for
4 standard TX queues + 1 command queue + 2 (unused) HCCA queues +
4 HT queues (one per AC).
We allow the user to change the number of queues used via a module
parameter and use this minimum value to check if it is valid. Without
this patch a user can select a value for the number of queues that
will result in a failing setup.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Tomas Winkler <tomas.winkler@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-dev.h | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 1a2fe37..b989d5c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -258,8 +258,10 @@ struct iwl_channel_info {
#define IWL_TX_FIFO_HCCA_2 6
#define IWL_TX_FIFO_NONE 7
-/* Minimum number of queues. MAX_NUM is defined in hw specific files */
-#define IWL_MIN_NUM_QUEUES 4
+/* Minimum number of queues. MAX_NUM is defined in hw specific files.
+ * Set the minimum to accommodate the 4 standard TX queues, 1 command
+ * queue, 2 (unused) HCCA queues, and 4 HT queues (one for each AC) */
+#define IWL_MIN_NUM_QUEUES 10
/* Power management (not Tx power) structures */
--
1.5.6.3
^ permalink raw reply related
* [PATCH 4/6 2.6.31 and w-t] iwlwifi: only update byte count table during aggregation
From: Reinette Chatre @ 2009-07-09 17:33 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In-Reply-To: <1247160821-14989-4-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
The byte count table is only used for aggregation. Updating it
in other cases caused fragmented frames to be dropped.
This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-tx.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 753fca3..7073069 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -873,7 +873,8 @@ int iwl_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
iwl_print_hex_dump(priv, IWL_DL_TX, (u8 *)tx_cmd->hdr, hdr_len);
/* Set up entry for this TFD in Tx byte-count array */
- priv->cfg->ops->lib->txq_update_byte_cnt_tbl(priv, txq,
+ if (info->flags & IEEE80211_TX_CTL_AMPDU)
+ priv->cfg->ops->lib->txq_update_byte_cnt_tbl(priv, txq,
le16_to_cpu(tx_cmd->len));
pci_dma_sync_single_for_device(priv->pci_dev, txcmd_phys,
--
1.5.6.3
^ permalink raw reply related
* [PATCH 5/6] iwl3945: cleanup number of queues settings
From: Reinette Chatre @ 2009-07-09 17:33 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In-Reply-To: <1247160821-14989-5-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
* Rename maximum number of queue (TFD_QUEUE_MAX) to IWL39_NUM_QUEUES to
be consistent with rest of iwlwifi.
* Remove unused defines.
* Fix loops that iterate over number of TX queues to stop when maximum is reached
(currently it is maximum + 1).
* Remove queues_num module parameter as it is not used.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-3945-hw.h | 7 ++-----
drivers/net/wireless/iwlwifi/iwl-3945.c | 8 ++++----
drivers/net/wireless/iwlwifi/iwl-3945.h | 3 ---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 15 +--------------
4 files changed, 7 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945-hw.h b/drivers/net/wireless/iwlwifi/iwl-3945-hw.h
index 73f93a0..b569c6f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945-hw.h
+++ b/drivers/net/wireless/iwlwifi/iwl-3945-hw.h
@@ -232,9 +232,8 @@ struct iwl3945_eeprom {
#define PCI_CFG_REV_ID_BIT_BASIC_SKU (0x40) /* bit 6 */
#define PCI_CFG_REV_ID_BIT_RTP (0x80) /* bit 7 */
-#define TFD_QUEUE_MIN 0
-#define TFD_QUEUE_MAX 5 /* 4 DATA + 1 CMD */
-
+/* 4 DATA + 1 CMD. There are 2 HCCA queues that are not used. */
+#define IWL39_NUM_QUEUES 5
#define IWL_NUM_SCAN_RATES (2)
#define IWL_DEFAULT_TX_RETRY 15
@@ -280,8 +279,6 @@ struct iwl3945_eeprom {
/* Size of uCode instruction memory in bootstrap state machine */
#define IWL39_MAX_BSM_SIZE IWL39_RTC_INST_SIZE
-#define IWL39_MAX_NUM_QUEUES 8
-
static inline int iwl3945_hw_valid_rtc_data_addr(u32 addr)
{
return (addr >= IWL39_RTC_DATA_LOWER_BOUND) &&
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index b0246db..1227ed2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -963,7 +963,7 @@ static int iwl3945_txq_ctx_reset(struct iwl_priv *priv)
goto error;
/* Tx queue(s) */
- for (txq_id = 0; txq_id <= priv->hw_params.max_txq_num; txq_id++) {
+ for (txq_id = 0; txq_id < priv->hw_params.max_txq_num; txq_id++) {
slots_num = (txq_id == IWL_CMD_QUEUE_NUM) ?
TFD_CMD_SLOTS : TFD_TX_CMD_SLOTS;
rc = iwl_tx_queue_init(priv, &priv->txq[txq_id], slots_num,
@@ -1140,7 +1140,7 @@ void iwl3945_hw_txq_ctx_free(struct iwl_priv *priv)
int txq_id;
/* Tx queues */
- for (txq_id = 0; txq_id <= priv->hw_params.max_txq_num; txq_id++)
+ for (txq_id = 0; txq_id < priv->hw_params.max_txq_num; txq_id++)
if (txq_id == IWL_CMD_QUEUE_NUM)
iwl_cmd_queue_free(priv);
else
@@ -1156,7 +1156,7 @@ void iwl3945_hw_txq_ctx_stop(struct iwl_priv *priv)
iwl_write_prph(priv, ALM_SCD_MODE_REG, 0);
/* reset TFD queues */
- for (txq_id = 0; txq_id <= priv->hw_params.max_txq_num; txq_id++) {
+ for (txq_id = 0; txq_id < priv->hw_params.max_txq_num; txq_id++) {
iwl_write_direct32(priv, FH39_TCSR_CONFIG(txq_id), 0x0);
iwl_poll_direct_bit(priv, FH39_TSSR_TX_STATUS,
FH39_TSSR_TX_STATUS_REG_MSK_CHNL_IDLE(txq_id),
@@ -2552,7 +2552,7 @@ int iwl3945_hw_set_hw_params(struct iwl_priv *priv)
}
/* Assign number of Usable TX queues */
- priv->hw_params.max_txq_num = TFD_QUEUE_MAX;
+ priv->hw_params.max_txq_num = IWL39_NUM_QUEUES;
priv->hw_params.tfd_size = sizeof(struct iwl3945_tfd);
priv->hw_params.rx_buf_size = IWL_RX_BUF_SIZE_3K;
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.h b/drivers/net/wireless/iwlwifi/iwl-3945.h
index fbb3a57..f2ffc48 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.h
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.h
@@ -111,9 +111,6 @@ enum iwl3945_antenna {
#define IWL_TX_FIFO_HCCA_2 6
#define IWL_TX_FIFO_NONE 7
-/* Minimum number of queues. MAX_NUM is defined in hw specific files */
-#define IWL_MIN_NUM_QUEUES 4
-
#define IEEE80211_DATA_LEN 2304
#define IEEE80211_4ADDR_LEN 30
#define IEEE80211_HLEN (IEEE80211_4ADDR_LEN)
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 7ff95f8..c9b3ea9 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -89,7 +89,7 @@ MODULE_LICENSE("GPL");
/* module parameters */
struct iwl_mod_params iwl3945_mod_params = {
- .num_of_queues = IWL39_MAX_NUM_QUEUES,
+ .num_of_queues = IWL39_NUM_QUEUES, /* Not used */
.sw_crypto = 1,
.restart_fw = 1,
/* the rest are 0 by default */
@@ -3947,15 +3947,6 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
priv = hw->priv;
SET_IEEE80211_DEV(hw, &pdev->dev);
- if ((iwl3945_mod_params.num_of_queues > IWL39_MAX_NUM_QUEUES) ||
- (iwl3945_mod_params.num_of_queues < IWL_MIN_NUM_QUEUES)) {
- IWL_ERR(priv,
- "invalid queues_num, should be between %d and %d\n",
- IWL_MIN_NUM_QUEUES, IWL39_MAX_NUM_QUEUES);
- err = -EINVAL;
- goto out_ieee80211_free_hw;
- }
-
/*
* Disabling hardware scan means that mac80211 will perform scans
* "the hard way", rather than using device's scan.
@@ -4272,10 +4263,6 @@ module_param_named(debug, iwl3945_mod_params.debug, uint, 0444);
MODULE_PARM_DESC(debug, "debug output mask");
module_param_named(disable_hw_scan, iwl3945_mod_params.disable_hw_scan, int, 0444);
MODULE_PARM_DESC(disable_hw_scan, "disable hardware scanning (default 0)");
-
-module_param_named(queues_num, iwl3945_mod_params.num_of_queues, int, 0444);
-MODULE_PARM_DESC(queues_num, "number of hw queues.");
-
module_param_named(fw_restart3945, iwl3945_mod_params.restart_fw, int, 0444);
MODULE_PARM_DESC(fw_restart3945, "restart firmware in case of error");
--
1.5.6.3
^ permalink raw reply related
* [PATCH 1/6] iwlwifi: move show_qos to debugfs
From: Reinette Chatre @ 2009-07-09 17:33 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy, Reinette Chatre
In-Reply-To: <1247160821-14989-1-git-send-email-reinette.chatre@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This move the show_qos file from sysfs to debugfs because the "one
value per file" sysfs rule.
The file is located in
/sys/kernel/debug/ieee80211/phy0/iwlagn/data
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn.c | 21 ---------------------
drivers/net/wireless/iwlwifi/iwl-debug.h | 1 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 25 +++++++++++++++++++++++++
3 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 1d4e9ca..13279b1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2629,26 +2629,6 @@ static ssize_t show_power_level(struct device *d,
static DEVICE_ATTR(power_level, S_IWUSR | S_IRUSR, show_power_level,
store_power_level);
-static ssize_t show_qos(struct device *d,
- struct device_attribute *attr, char *buf)
-{
- struct iwl_priv *priv = dev_get_drvdata(d);
- char *p = buf;
- int q;
-
- for (q = 0; q < AC_NUM; q++) {
- p += sprintf(p, "\tcw_min\tcw_max\taifsn\ttxop\n");
- p += sprintf(p, "AC[%d]\t%u\t%u\t%u\t%u\n", q,
- priv->qos_data.def_qos_parm.ac[q].cw_min,
- priv->qos_data.def_qos_parm.ac[q].cw_max,
- priv->qos_data.def_qos_parm.ac[q].aifsn,
- priv->qos_data.def_qos_parm.ac[q].edca_txop);
- }
-
- return p - buf + 1;
-}
-
-static DEVICE_ATTR(qos, S_IRUGO, show_qos, NULL);
static ssize_t show_statistics(struct device *d,
struct device_attribute *attr, char *buf)
@@ -2749,7 +2729,6 @@ static struct attribute *iwl_sysfs_entries[] = {
&dev_attr_debug_level.attr,
#endif
&dev_attr_version.attr,
- &dev_attr_qos.attr,
NULL
};
diff --git a/drivers/net/wireless/iwlwifi/iwl-debug.h b/drivers/net/wireless/iwlwifi/iwl-debug.h
index 65bbce0..1555676 100644
--- a/drivers/net/wireless/iwlwifi/iwl-debug.h
+++ b/drivers/net/wireless/iwlwifi/iwl-debug.h
@@ -82,6 +82,7 @@ struct iwl_debugfs {
struct dentry *file_channels;
struct dentry *file_status;
struct dentry *file_interrupt;
+ struct dentry *file_qos;
} dbgfs_data_files;
struct dir_rf_files {
struct dentry *file_disable_sensitivity;
diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
index f32ac74..e38ec81 100644
--- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
@@ -566,6 +566,28 @@ static ssize_t iwl_dbgfs_interrupt_write(struct file *file,
return count;
}
+static ssize_t iwl_dbgfs_qos_read(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct iwl_priv *priv = (struct iwl_priv *)file->private_data;
+ int pos = 0, i;
+ char buf[256];
+ const size_t bufsz = sizeof(buf);
+ ssize_t ret;
+
+ for (i = 0; i < AC_NUM; i++) {
+ pos += scnprintf(buf + pos, bufsz - pos,
+ "\tcw_min\tcw_max\taifsn\ttxop\n");
+ pos += scnprintf(buf + pos, bufsz - pos,
+ "AC[%d]\t%u\t%u\t%u\t%u\n", i,
+ priv->qos_data.def_qos_parm.ac[i].cw_min,
+ priv->qos_data.def_qos_parm.ac[i].cw_max,
+ priv->qos_data.def_qos_parm.ac[i].aifsn,
+ priv->qos_data.def_qos_parm.ac[i].edca_txop);
+ }
+ ret = simple_read_from_buffer(user_buf, count, ppos, buf, pos);
+ return ret;
+}
DEBUGFS_READ_WRITE_FILE_OPS(sram);
DEBUGFS_WRITE_FILE_OPS(log_event);
@@ -576,6 +598,7 @@ DEBUGFS_READ_FILE_OPS(tx_statistics);
DEBUGFS_READ_FILE_OPS(channels);
DEBUGFS_READ_FILE_OPS(status);
DEBUGFS_READ_WRITE_FILE_OPS(interrupt);
+DEBUGFS_READ_FILE_OPS(qos);
/*
* Create the debugfs files and directories
@@ -612,6 +635,7 @@ int iwl_dbgfs_register(struct iwl_priv *priv, const char *name)
DEBUGFS_ADD_FILE(channels, data);
DEBUGFS_ADD_FILE(status, data);
DEBUGFS_ADD_FILE(interrupt, data);
+ DEBUGFS_ADD_FILE(qos, data);
DEBUGFS_ADD_BOOL(disable_sensitivity, rf, &priv->disable_sens_cal);
DEBUGFS_ADD_BOOL(disable_chain_noise, rf,
&priv->disable_chain_noise_cal);
@@ -646,6 +670,7 @@ void iwl_dbgfs_unregister(struct iwl_priv *priv)
DEBUGFS_REMOVE(priv->dbgfs->dbgfs_data_files.file_channels);
DEBUGFS_REMOVE(priv->dbgfs->dbgfs_data_files.file_status);
DEBUGFS_REMOVE(priv->dbgfs->dbgfs_data_files.file_interrupt);
+ DEBUGFS_REMOVE(priv->dbgfs->dbgfs_data_files.file_qos);
DEBUGFS_REMOVE(priv->dbgfs->dir_data);
DEBUGFS_REMOVE(priv->dbgfs->dbgfs_rf_files.file_disable_sensitivity);
DEBUGFS_REMOVE(priv->dbgfs->dbgfs_rf_files.file_disable_chain_noise);
--
1.5.6.3
^ permalink raw reply related
* [PATCH 3/6] iwlwifi: fix permissions on debugfs files
From: Reinette Chatre @ 2009-07-09 17:33 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In-Reply-To: <1247160821-14989-3-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
debugfs files are created with 644 permissions which gives everybody
read access. This presents a security issue if a user opens the file and
holds it open at the time the driver removes the file. At this point
invalid memory will be accessed.
Fix this by only allowing root to read debugfs files.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
index e38ec81..0b9e824 100644
--- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
@@ -49,7 +49,8 @@
#define DEBUGFS_ADD_FILE(name, parent) do { \
dbgfs->dbgfs_##parent##_files.file_##name = \
- debugfs_create_file(#name, 0644, dbgfs->dir_##parent, priv, \
+ debugfs_create_file(#name, S_IWUSR | S_IRUSR, \
+ dbgfs->dir_##parent, priv, \
&iwl_dbgfs_##name##_ops); \
if (!(dbgfs->dbgfs_##parent##_files.file_##name)) \
goto err; \
@@ -57,7 +58,8 @@
#define DEBUGFS_ADD_BOOL(name, parent, ptr) do { \
dbgfs->dbgfs_##parent##_files.file_##name = \
- debugfs_create_bool(#name, 0644, dbgfs->dir_##parent, ptr); \
+ debugfs_create_bool(#name, S_IWUSR | S_IRUSR, \
+ dbgfs->dir_##parent, ptr); \
if (IS_ERR(dbgfs->dbgfs_##parent##_files.file_##name) \
|| !dbgfs->dbgfs_##parent##_files.file_##name) \
goto err; \
@@ -65,7 +67,7 @@
#define DEBUGFS_ADD_X32(name, parent, ptr) do { \
dbgfs->dbgfs_##parent##_files.file_##name = \
- debugfs_create_x32(#name, 0444, dbgfs->dir_##parent, ptr); \
+ debugfs_create_x32(#name, S_IRUSR, dbgfs->dir_##parent, ptr); \
if (IS_ERR(dbgfs->dbgfs_##parent##_files.file_##name) \
|| !dbgfs->dbgfs_##parent##_files.file_##name) \
goto err; \
--
1.5.6.3
^ permalink raw reply related
* [PATCH 2/6 2.6.31 and w-t] iwlwifi: only show active power level via sysfs
From: Reinette Chatre @ 2009-07-09 17:33 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre, stable
In-Reply-To: <1247160821-14989-2-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
This changes the power_level file to adhere to the "one value
per file" sysfs rule. The user will know which power level was
requested as it will be the number just written to this file. It
is thus not necessary to create a new sysfs file for this value.
In addition it fixes a problem where powertop's parsing expects
this value to be the first value in this file without any descriptions.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
cc: stable@kernel.org
---
Needed in 2.6.31 and 2.6.30 because without it powertop
is not able to parse the power level correctly.
Applies to both wireless-testing and 2.6.31, but not to 2.6.30.
Backporting will be done at the time this patch becomes available in
2.6.31. Will resend to stable@kernel.org at that time. Now just adding
stable@kernel.org as cc to bring patch to your attention.
drivers/net/wireless/iwlwifi/iwl-agn.c | 4 +---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 13279b1..ad50022 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2617,12 +2617,10 @@ static ssize_t show_power_level(struct device *d,
struct device_attribute *attr, char *buf)
{
struct iwl_priv *priv = dev_get_drvdata(d);
- int mode = priv->power_data.user_power_setting;
int level = priv->power_data.power_mode;
char *p = buf;
- p += sprintf(p, "INDEX:%d\t", level);
- p += sprintf(p, "USER:%d\n", mode);
+ p += sprintf(p, "%d\n", level);
return p - buf + 1;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 303c4b4..7ff95f8 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -3573,12 +3573,10 @@ static ssize_t show_power_level(struct device *d,
struct device_attribute *attr, char *buf)
{
struct iwl_priv *priv = dev_get_drvdata(d);
- int mode = priv->power_data.user_power_setting;
int level = priv->power_data.power_mode;
char *p = buf;
- p += sprintf(p, "INDEX:%d\t", level);
- p += sprintf(p, "USER:%d\n", mode);
+ p += sprintf(p, "%d\n", level);
return p - buf + 1;
}
--
1.5.6.3
^ permalink raw reply related
* [PATCH 0/6] iwlwifi driver updates 07/09/2009
From: Reinette Chatre @ 2009-07-09 17:33 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
John,
We include two fixes targeting 2.6.31. One is needed for powertop
to be able to parse the sysfs information correctly. The second fix
is needed to be able to transfer fragmented frames in certain
environments. The rest of the series include a security fix and cleanup.
I do not know if patch 3/6 (the security fix) can be considered as 2.6.31
material. It does apply cleanly if you wish to take it.
[PATCH 1/6] iwlwifi: move show_qos to debugfs
[PATCH 2/6 2.6.31 and w-t] iwlwifi: only show active power level via sysfs
[PATCH 3/6] iwlwifi: fix permissions on debugfs files
[PATCH 4/6 2.6.31 and w-t] iwlwifi: only update byte count table during aggregation
[PATCH 5/6] iwl3945: cleanup number of queues settings
[PATCH 6/6] iwlagn: fix minimum number of queues setting
Thank you
Reinette
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Pavel Roskin @ 2009-07-09 17:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247139797.2144.27.camel@johannes.local>
On Thu, 2009-07-09 at 13:43 +0200, Johannes Berg wrote:
> Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
> -Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
> "disconnect". When then the interface is brought UP again, the cfg80211
> code assumes that you set configuration while it was DOWN, and tries to
> recover that configuration. This means it will start scanning for the
> network, which means -Dnl80211 gets -EBUSY for the scan and it all gets
> very delayed. This also happens if you set an SSID with iwconfig before
> using -Dnl80211.
I'm seeing delay is I start wpa_supplicant with -Dwext on the current
wireless-testing. I don't use -Dnl80211 on that system at all, as it
has stock Fedora 11 wpa_supplicant without nl80211 support.
I think using random data is a problem by itself. Are we exposing
random pieces of kernel memory in probe requests? That's bad.
> Do we just ignore that issue? It's only added timeout and people using
> purely nl80211 will never have a problem.
>
> I'm all for ignoring wext issues, but I can also see people complain
> about things like this. Not sure what mac80211 did, did it just ignore
> settings while interfaces were down? I never really made sense of that
> code.
If your description is correct, I think the fix should be easy.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Luis R. Rodriguez @ 2009-07-09 17:02 UTC (permalink / raw)
To: Bob Copeland; +Cc: Jasin Colegrove, linux-wireless
In-Reply-To: <b6c5339f0907090955v7b99a7ebq26e7cc67ab2493f5@mail.gmail.com>
On Thu, Jul 9, 2009 at 9:55 AM, Bob Copeland<me@bobcopeland.com> wrote:
> On Thu, Jul 9, 2009 at 12:42 PM, Jasin
> Colegrove<j.wholesalesupply@gmail.com> wrote:
>>> BTW, can you (re?)post the "Atheros AR5212 chip found (MAC xxx,
>>> PHY xxxx)?"
>>>
>> What exact information do you want and where can I find it?
>
> Run 'dmesg'; a string like the above is printed out when the module
> loads. In case there was something broken specifically for your
> chipset, the mac/phy versions will help narrow it down.
>
>> $git bisect start v2.6.30-rc4 v2.6.29 -- drivers/net net/
>>
>> Is that what you where hinting at? I wasted a whole day trying to fix
>> errors in drivers/staging before I was told I could just disable
>> compilation of staging with one switch. Oh well...
>
> Yes, that's what I meant. And it does help to have a relatively
> slimmed down .config, especially when bisecting. :\
I'd add net/mac80211 and net/wireless in there as well, just to be safe.
Luis
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Bob Copeland @ 2009-07-09 16:55 UTC (permalink / raw)
To: Jasin Colegrove; +Cc: linux-wireless
In-Reply-To: <6c354a1a0907090942o66c4e1b8ue2c952cf7ed7bf9a@mail.gmail.com>
On Thu, Jul 9, 2009 at 12:42 PM, Jasin
Colegrove<j.wholesalesupply@gmail.com> wrote:
>> BTW, can you (re?)post the "Atheros AR5212 chip found (MAC xxx,
>> PHY xxxx)?"
>>
> What exact information do you want and where can I find it?
Run 'dmesg'; a string like the above is printed out when the module
loads. In case there was something broken specifically for your
chipset, the mac/phy versions will help narrow it down.
> $git bisect start v2.6.30-rc4 v2.6.29 -- drivers/net net/
>
> Is that what you where hinting at? I wasted a whole day trying to fix
> errors in drivers/staging before I was told I could just disable
> compilation of staging with one switch. Oh well...
Yes, that's what I meant. And it does help to have a relatively
slimmed down .config, especially when bisecting. :\
--
Bob Copeland %% www.bobcopeland.com
^ 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