* Re: [PATCH] Assign next hop address to pending mesh frames once the path is resolved.
From: Johannes Berg @ 2009-07-08 10:40 UTC (permalink / raw)
To: Javier Cardona; +Cc: linux-wireless, devel
In-Reply-To: <1247032403-8312-1-git-send-email-javier@cozybit.com>
[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]
On Tue, 2009-07-07 at 22:53 -0700, Javier Cardona wrote:
> Regression. Frames transmitted when a mesh path was wating to be resolved were
> being transmitted with an invalid Receiver Address.
> - rcu_assign_pointer(mpath->next_hop, sta);
> + struct sk_buff *skb, *skb_first = NULL;
> + struct ieee80211_hdr *hdr;
> +
> + rcu_read_lock();
> + mpath->next_hop = sta;
> +
> + while ((skb = skb_dequeue(&mpath->frame_queue)) != skb_first) {
> + if (!skb_first)
> + skb_first = skb;
> + hdr = (struct ieee80211_hdr *) skb->data;
> + memcpy(hdr->addr1, sta->sta.addr, ETH_ALEN);
> + skb_queue_tail(&mpath->frame_queue, skb);
> + }
> + if (skb_first)
> + skb_queue_tail(&mpath->frame_queue, skb_first);
> +
> + rcu_read_unlock();
Since skb queues have a locks, why use rcu too?
Also I think you should probably use a different pattern -- this looks
prone to breakage, maybe something like
sk_buff_head tmpq;
unsigned long flags;
__skb_queue_head_init(&tmpq);
spin_lock_irqsave(&frame_queue->lock);
while (skb = __skb_dequeue(&frame_queue)) {
hdr = (struct ieee80211_hdr *) skb->data;
memcpy(hdr->addr1, sta->sta.addr, ETH_ALEN);
__skb_queue_tail(&tmpq, skb);
}
skb_queue_splice(&tmpq, frame_queue);
spin_unlock_irqrestore(&frame_queue->lock);
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Possible memory leak in net/wireless/scan.c
From: Johannes Berg @ 2009-07-08 10:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-wireless, linux-kernel
In-Reply-To: <1247042784.6595.7.camel@pc1117.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On Wed, 2009-07-08 at 09:46 +0100, Catalin Marinas wrote:
> Anyway, I run it from some ARM embedded systems at ~200MHz and 256MB of
> RAM to dual core x86 at 2GHz with 3GB of RAM. I also ran it on quemu in
> the past (but, well, in the embedded world I'm pretty used with
> emulators taking 10 min to boot the kernel).
:)
> But it can slow things down since it tracks every memory allocation and
> it needs to look up the pointer in an rb tree.
It was so slow I gave up after a while. But then my real purpose was
testing something, not waiting for kmemleak, so I guess I just didn't
wait long enough :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: mac80211 and broadcast frames
From: David Ross @ 2009-07-08 10:06 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4A544B15.8030106@mrs.ro>
Valentin Manea wrote:
> I've found the code in ath9k and you are right, it always chooses
> the lowest rate.
> So, basically to transmit multicast frames at a better bitrate I
> have to hack the rate control algorithm, right?
>
> Thanks,
> Valentin
If you want to still be an 802.11 device then you may only use one of
the basic rates, no extended rates, viz:
"All frames with multicast and broadcast in the Address 1 field that
have a UP of zero shall be transmitted at one of the rates included in
the BSSBasicRateSet parameter, regardless of their type or subtype."
(from the 2007 edition of the standard).
- David Ross.
^ permalink raw reply
* Re: a question about marvell sd8686's wmm_config_change event
From: fengzeheng @ 2009-07-08 10:10 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, dcbw
In-Reply-To: <200907080948.00065.hs4233@mail.mn-solutions.de>
Hi, Holger and dan
Sorry for my previous wrong message. I go through all the beacon
frames again and found that Ruckus AP update WMM
IE:wmm_parameter_set_update_counter. But it's strange that other
elements of wmm settings remain unchanged, RUCKUS just update the
update_counter for none of wmm settings updated actually ..........
thanks
2009/7/8 Holger Schurig <hs4233@mail.mn-solutions.de>:
> On Tuesday 07 July 2009 18:28:47 fengzeheng wrote:
>> hi, dan and all
>> My wireless card sd8686 reports that wmm_config_change
>> about every 2 seconds though wmm's setting in AP's beacons
>> don't change. seems that driver receive
>> MACREG_INT_CODE_WMM_STATUS_CHANGE event from firmware every 2
>> seconds. And according
>
> Hmm, if the firmware sends you a
> MACREG_INT_CODE_WMM_STATUS_CHANGE but you're sure that the
> beacons don't change, then the firmware seems to be buggy.
>
> Not sure if Marvell got sane and opened up their support for
> no-NDA-holders, but you could try and file a bug there.
>
>
> And we should look into the libertas driver if we always loose a
> packet whenever we get a MACREG :-)
>
> Greetings, Holger
>
> --
> http://www.holgerschurig.de
>
--
Best Regards
Feng zeheng
^ permalink raw reply
* Re: Possible memory leak in net/wireless/scan.c
From: Catalin Marinas @ 2009-07-08 8:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel
In-Reply-To: <1247022413.4755.56.camel@johannes.local>
On Wed, 2009-07-08 at 05:06 +0200, Johannes Berg wrote:
> On Tue, 2009-07-07 at 18:04 +0100, Catalin Marinas wrote:
> > Hi,
> >
> > I'm investigating several kmemleak reports like the one below (it could
> > as well be a false positive but it needs more digging):
>
> By the way, what kind of machine do you need for kmemleak to be
> feasible? I tried booting a kernel with it in kvm on my 2 ghz laptop,
> and that was completely unfeasible.
What do you mean by unfeasible?
There are some patches in my kmemleak branch which I'll push upstream
again (important ones are the renicing of the kmemleak thread and a few
more cond_resched calls):
http://www.linux-arm.org/git?p=linux-2.6.git;a=shortlog;h=kmemleak
There are 3 more patches under discussion to track the bootmem
allocations (which dropped the number of false positives to 0 on my
laptop).
Anyway, I run it from some ARM embedded systems at ~200MHz and 256MB of
RAM to dual core x86 at 2GHz with 3GB of RAM. I also ran it on quemu in
the past (but, well, in the embedded world I'm pretty used with
emulators taking 10 min to boot the kernel).
But it can slow things down since it tracks every memory allocation and
it needs to look up the pointer in an rb tree.
--
Catalin
^ permalink raw reply
* Re: a question about marvell sd8686's wmm_config_change event
From: Holger Schurig @ 2009-07-08 7:48 UTC (permalink / raw)
To: linux-wireless; +Cc: fengzeheng, dcbw
In-Reply-To: <5135d20a0907070928o19322c3waf41a7b59d4b309e@mail.gmail.com>
On Tuesday 07 July 2009 18:28:47 fengzeheng wrote:
> hi, dan and all
> My wireless card sd8686 reports that wmm_config_change
> about every 2 seconds though wmm's setting in AP's beacons
> don't change. seems that driver receive
> MACREG_INT_CODE_WMM_STATUS_CHANGE event from firmware every 2
> seconds. And according
Hmm, if the firmware sends you a
MACREG_INT_CODE_WMM_STATUS_CHANGE but you're sure that the
beacons don't change, then the firmware seems to be buggy.
Not sure if Marvell got sane and opened up their support for
no-NDA-holders, but you could try and file a bug there.
And we should look into the libertas driver if we always loose a
packet whenever we get a MACREG :-)
Greetings, Holger
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: BUG REPORT: libertas causing kernel lockups
From: Holger Schurig @ 2009-07-08 7:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Alexander Barinov
In-Reply-To: <1246957007.4755.1.camel@johannes.local>
> Yes, but the patch that I quoted makes it allowable to sleep
> there, so it must be something else. Is it maybe using the
> RTNL there? Or using schedule_work() and then waiting for it
> or something that the work triggers, which will deadlock on
> the RTNL if there's something in front of it on the queue that
> needs the RTNL, because get_wireless_stats is executed under
> RTNL? (lockdep couldn't find that particular case because it
> knows nothing about completions)
Again this is all from my memory, around the 2.6.25
time. "iwconfig" or "cat /proc/net/wireless" ended up in
drivers/net/wireless/libertas/wext.c, AFAIK in
lbs_get_wireless_stats(). This calls
lbs_cmd_with_response(priv, CMD_802_11_GET_LOG, &log);
this is a macro calling lbs_cmd(). This thingy then does
__lbs_cmd_async(), which creates a "command node", queues this,
and calls
wake_up_interruptible(&priv->waitq);
(cmd.c, around line 2050) to get the queue handled (e.g. sending
the command to the firmware). And I think that this wake_up-call
calls __schedule() now.
Later, lbs_cmd() does this:
might_sleep();
wait_event_interruptible(cmdnode->cmdwait_q,
cmdnode->cmdwaitqwoken);
But AFAIK this isn't problematic.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: BUG REPORT: libertas causing kernel lockups
From: Holger Schurig @ 2009-07-08 7:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Alexander Barinov
In-Reply-To: <20090708003734.0d57b389@dream>
> Sorry for asking a potentially stupid question as I am no way
> a wireless hardware expert, but can this bug be caused by
> wrong firmware version?
AFAIK not.
> BTW, it is really hard to find a patch you are talking about
> in the archive.
It's dead easy:
$ cd linux-git
$ git show 87057825824973f29cf2f37cff1e549170b2d7e6
Or you can go via the web-interface: start at
http://git.kernel.org, search Linus' tree and you end up at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary.
Now select any commitdiff, and substitute in the URL the
hex-thingy from above. And voila, you're at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=87057825824973f29cf2f37cff1e549170b2d7e6
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: mac80211 and broadcast frames
From: Valentin Manea @ 2009-07-08 7:30 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John W. Linville, David Ross, linux-wireless
In-Reply-To: <43e72e890907070915y5fd131b7l6aa845a0785f8c76@mail.gmail.com>
On 07/07/2009 07:15 PM, Luis R. Rodriguez wrote:
> On Tue, Jul 7, 2009 at 7:48 AM, John W. Linville<linville@tuxdriver.com> wrote:
>> On Tue, Jul 07, 2009 at 09:10:52PM +1000, David Ross wrote:
>>> Actually it is required to be a mutual BASIC rate (not extended rates) -
>>> not necessarily the "lowest possible" - David.
>> True, but FWIW I think all of our rate scaling algorithms choose the
>> lowest rate.
>
> And then iwlwifi and ath9k have their own rate control algo, and at
> least ath9k uses the lowest valid rate IIRC.
>
> Luis
I've found the code in ath9k and you are right, it always chooses the
lowest rate.
So, basically to transmit multicast frames at a better bitrate I have
to hack the rate control algorithm, right?
Thanks,
Valentin
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Jasin Colegrove @ 2009-07-08 6:58 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20090707030719.GC7199@hash.localnet>
On Mon, Jul 6, 2009 at 11:07 PM, Bob Copeland<me@bobcopeland.com> wrote:
>> Colegrove<j.wholesalesupply@gmail.com> wrote:
>> > Thanks bob for the reply. I did not mean to shout, but someone else
>> > told me that I should make it very clear that I was not subscribed.
>> > But, now I am so it doesn't matter :)
>
> No worries, but whoever said that is wrong as far as vger.kernel.org
> mailing lists go, as everyone just does reply-all. (Also, top-posting
> is frowned upon.)
>
>> I have found the bad commit.
>
>> $ git bisect good
>> 1e3e6e8fe2f422f75619b1110f78bb638ae905b9 is first bad commit
>> commit 1e3e6e8fe2f422f75619b1110f78bb638ae905b9
>> Author: Nick Kossifidis <mick@madwifi-project.org>
>> Date: Mon Feb 9 06:15:42 2009 +0200
>>
>> ath5k: Disable BMISS interrupts
>
> Hmm, so that's a pretty weird commit to end up with. Can you
> now try whatever your baseline kernel was, with just this patch
> reverted and see if it works for you?
I haven't tried this yet, but I started up gitk and realized that the
last good commit was the one previous to the bad commit. They where
made 3 minutes apart in the ath5k dir. So I am assuming that the
"Disable BMISS interrupts was not actually at fault. It just doesn't
seem logical now that i look at it.
>
> We don't actually do anything with BMISS yet so the only thing it
> could do is slow down your computer.
>
> Another possibility is that something happened between that
> commit and your last good ath5k commit, elsewhere in the tree,
> so a bisect would need to be done over the whole tree instead of
> just the ath5k directory.
So I started another bisect of drivers/net/. Is this the main tree you
where talking about or do you think I need to go further into the main
tree? If so, how far?
>
> A third possibility is the issue comes and goes, or is timing
> related, in which case bisection really isn't useful.
I don't think this is the case, Only because I haven't noticed it to
be intermittent. Either wicd works on reboot of a new kernel or it
doesn't. Any attempts to get it working fail until I restart with a
good commit of the kernel.
>
>> Do you still think it would be wise to file a bug report for this
>> issue. I have yet to try the latest compat-wireless.
>
> Give 2.6.30.1 a shot as it includes a couple of fixes, otherwise
> bugzilla is probably the best bet.
I tried this and this is where the mystery deepens. With .30.1 it
seems that I can connect to my neighbors network using dhcp but I
still can not hook to my own using a static IP. I have not actually
tried conneting with .30.1/dhcp to my own network, but that is the
next step for me if the bisect on drivers/net fails to provide any
stellar results. Once again, downgrading to kernel .29 fixes
everything without changing any of my other settings. I am still 110%
positive this is a kernel module/driver issue. It does make sense, no?
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
If you have any other bright ideas keep them coming.
^ permalink raw reply
* [PATCH] Assign next hop address to pending mesh frames once the path is resolved.
From: Javier Cardona @ 2009-07-08 5:53 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, johannes, Javier Cardona
Regression. Frames transmitted when a mesh path was wating to be resolved were
being transmitted with an invalid Receiver Address.
Signed-off-by: Javier Cardona <javier@cozybit.com>
---
net/mac80211/mesh.h | 2 +-
net/mac80211/mesh_pathtbl.c | 18 +++++++++++++++++-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 2a2ed18..1827725 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -61,7 +61,7 @@ enum mesh_path_flags {
* retry
* @discovery_retries: number of discovery retries
* @flags: mesh path flags, as specified on &enum mesh_path_flags
- * @state_lock: mesh pat state lock
+ * @state_lock: mesh path state lock
*
*
* The combination of dst and sdata is unique in the mesh path table. Since the
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index ae98766..75a13ee 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -55,7 +55,23 @@ static DEFINE_RWLOCK(pathtbl_resize_lock);
*/
void mesh_path_assign_nexthop(struct mesh_path *mpath, struct sta_info *sta)
{
- rcu_assign_pointer(mpath->next_hop, sta);
+ struct sk_buff *skb, *skb_first = NULL;
+ struct ieee80211_hdr *hdr;
+
+ rcu_read_lock();
+ mpath->next_hop = sta;
+
+ while ((skb = skb_dequeue(&mpath->frame_queue)) != skb_first) {
+ if (!skb_first)
+ skb_first = skb;
+ hdr = (struct ieee80211_hdr *) skb->data;
+ memcpy(hdr->addr1, sta->sta.addr, ETH_ALEN);
+ skb_queue_tail(&mpath->frame_queue, skb);
+ }
+ if (skb_first)
+ skb_queue_tail(&mpath->frame_queue, skb_first);
+
+ rcu_read_unlock();
}
--
1.5.4.3
^ permalink raw reply related
* Re: Possible memory leak in net/wireless/scan.c
From: Johannes Berg @ 2009-07-08 3:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-wireless, linux-kernel
In-Reply-To: <1246986269.9451.105.camel@pc1117.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
On Tue, 2009-07-07 at 18:04 +0100, Catalin Marinas wrote:
> Hi,
>
> I'm investigating several kmemleak reports like the one below (it could
> as well be a false positive but it needs more digging):
By the way, what kind of machine do you need for kmemleak to be
feasible? I tried booting a kernel with it in kvm on my 2 ghz laptop,
and that was completely unfeasible.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Question on UAPSD support on b43
From: Ramesh @ 2009-07-07 22:29 UTC (permalink / raw)
To: Linux-Wireless
Hello,
I am a newbie to linux-wireless. I have a linux image built based on
the latest source wireless-testing.git, I would like to understand /
study the current U-APSD support on the station side - I have a linux
box running hostAPD for the AP and a b43 based mini-pci on a laptop
for the station. I am not sure of the U-APSD support in the firmware
for the b43 device - Is anyone aware of the power save support on the
b43 firmware? If not much support is available - could someone suggest
an alternative device for the station side?
Thanks
Ramesh
^ permalink raw reply
* Re: Possible memory leak in net/wireless/scan.c
From: Johannes Berg @ 2009-07-07 21:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-wireless, linux-kernel
In-Reply-To: <1247002168.5710.1.camel@pc1117.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Tue, 2009-07-07 at 22:29 +0100, Catalin Marinas wrote:
> > > if (found) {
> > > - kref_get(&found->ref);
> > > found->pub.beacon_interval = res->pub.beacon_interval;
> > > found->pub.tsf = res->pub.tsf;
> > > found->pub.signal = res->pub.signal;
> > >
> > > I'll try this later today to see if it fixes the leak. If that's not
> > > correct, I'll post more information about the content of the reported
> > > object (in general, it shouldn't be on any valid list or rb tree since
> > > kmemleak can't find it).
> >
> > I have already sent that exact patch.
>
> OK. I can now confirm that it fixes the memory leak.
Great, thanks for checking.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] cfg80211: fix two buglets
From: Johannes Berg @ 2009-07-07 21:46 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
This fixes two small bugs:
1) the connect variable is already initialised, and the
assignment to auth_type overwrites the previous setting
with a wrong value
2) when all authentication attempts fail, we need to report
that we couldn't connect
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/nl80211.c | 4 ----
net/wireless/sme.c | 5 ++---
2 files changed, 2 insertions(+), 7 deletions(-)
--- wireless-testing.orig/net/wireless/nl80211.c 2009-07-07 23:39:04.000000000 +0200
+++ wireless-testing/net/wireless/nl80211.c 2009-07-07 23:39:05.000000000 +0200
@@ -3695,10 +3695,6 @@ static int nl80211_connect(struct sk_buf
wiphy = &rdev->wiphy;
- connect.bssid = NULL;
- connect.channel = NULL;
- connect.auth_type = NL80211_AUTHTYPE_OPEN_SYSTEM;
-
if (info->attrs[NL80211_ATTR_MAC])
connect.bssid = nla_data(info->attrs[NL80211_ATTR_MAC]);
connect.ssid = nla_data(info->attrs[NL80211_ATTR_SSID]);
--- wireless-testing.orig/net/wireless/sme.c 2009-07-07 23:39:01.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2009-07-07 23:39:05.000000000 +0200
@@ -296,9 +296,8 @@ void cfg80211_sme_rx_auth(struct net_dev
wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
schedule_work(&rdev->conn_work);
} else if (status_code != WLAN_STATUS_SUCCESS) {
- wdev->sme_state = CFG80211_SME_IDLE;
- kfree(wdev->conn);
- wdev->conn = NULL;
+ __cfg80211_connect_result(dev, mgmt->bssid, NULL, 0, NULL, 0,
+ status_code, false);
} else if (wdev->sme_state == CFG80211_SME_CONNECTING &&
wdev->conn->state == CFG80211_CONN_AUTHENTICATING) {
wdev->conn->state = CFG80211_CONN_ASSOCIATE_NEXT;
^ permalink raw reply
* [PATCH] cfg80211: fix race in giwrate
From: Johannes Berg @ 2009-07-07 21:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
cfg80211_wext_giwrate doesn't lock the wdev, so it
cannot access current_bss race-free. Also, there's
little point in trying to ask the driver for an AP
that it never told us about, so avoid that case.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/wext-compat.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- wireless-testing.orig/net/wireless/wext-compat.c 2009-07-07 23:39:01.000000000 +0200
+++ wireless-testing/net/wireless/wext-compat.c 2009-07-07 23:39:11.000000000 +0200
@@ -1127,7 +1127,7 @@ int cfg80211_wext_giwrate(struct net_dev
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
/* we are under RTNL - globally locked - so can use a static struct */
static struct station_info sinfo;
- u8 *addr;
+ u8 addr[ETH_ALEN];
int err;
if (wdev->iftype != NL80211_IFTYPE_STATION)
@@ -1136,12 +1136,15 @@ int cfg80211_wext_giwrate(struct net_dev
if (!rdev->ops->get_station)
return -EOPNOTSUPP;
+ err = 0;
+ wdev_lock(wdev);
if (wdev->current_bss)
- addr = wdev->current_bss->pub.bssid;
- else if (wdev->wext.connect.bssid)
- addr = wdev->wext.connect.bssid;
+ memcpy(addr, wdev->current_bss->pub.bssid, ETH_ALEN);
else
- return -EOPNOTSUPP;
+ err = -EOPNOTSUPP;
+ wdev_unlock(wdev);
+ if (err)
+ return err;
err = rdev->ops->get_station(&rdev->wiphy, dev, addr, &sinfo);
if (err)
^ permalink raw reply
* Re: Possible memory leak in net/wireless/scan.c
From: Catalin Marinas @ 2009-07-07 21:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel
In-Reply-To: <1246986768.4755.43.camel@johannes.local>
On Tue, 2009-07-07 at 19:12 +0200, Johannes Berg wrote:
> On Tue, 2009-07-07 at 18:04 +0100, Catalin Marinas wrote:
>
> > diff --git a/net/wireless/scan.c b/net/wireless/scan.c
> > index e95b638..f8e71b3 100644
> > --- a/net/wireless/scan.c
> > +++ b/net/wireless/scan.c
> > @@ -366,7 +366,6 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
> > found = rb_find_bss(dev, res);
> >
> > if (found) {
> > - kref_get(&found->ref);
> > found->pub.beacon_interval = res->pub.beacon_interval;
> > found->pub.tsf = res->pub.tsf;
> > found->pub.signal = res->pub.signal;
> >
> > I'll try this later today to see if it fixes the leak. If that's not
> > correct, I'll post more information about the content of the reported
> > object (in general, it shouldn't be on any valid list or rb tree since
> > kmemleak can't find it).
>
> I have already sent that exact patch.
OK. I can now confirm that it fixes the memory leak.
Thanks.
--
Catalin
^ permalink raw reply
* Re: ath5k and ap mode
From: Pavel Roskin @ 2009-07-07 21:21 UTC (permalink / raw)
To: Bob Copeland; +Cc: tomek, linux-wireless
In-Reply-To: <b6c5339f0907071243i7380ef9cm857fd189025a92a9@mail.gmail.com>
On Tue, 2009-07-07 at 15:43 -0400, Bob Copeland wrote:
> On Tue, Jul 7, 2009 at 3:25 PM, Pavel Roskin<proski@gnu.org> wrote:
> >
> > WPA: Countermeasures - dropped EAPOL request.
> >
> > I'm using WPA-PSK (WPA1 only) to simplify the configuration. My
> > impression is that we need a serious effort to weed out such problems.
>
> Hmm, does the same happen with nohwcrypt=1?
"Pairwise with unexpected replay counter" is still there. But the
timeouts (deauthenticated due to local deauth request" in hostapd and
"Authentication with 00:00:00:00:00:00 timed out" in wpa_supplicant) are
gone, so the association happens quicker, after a few complaints about
the counters.
I tried CCMP and WPA2, and "Pairwise with unexpected replay counter"
still happens.
I'm using the current hostapd from git, but it's working with MadWifi
without such issues.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: 2.6.31-rc2: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-07-07 20:41 UTC (permalink / raw)
To: Frans Pop
Cc: linux-kernel, bunk, akpm, torvalds, kernel-testers, netdev,
linux-wireless
In-Reply-To: <200907072125.47762.elendil@planet.nl>
On Tuesday 07 July 2009, Frans Pop wrote:
> > If you know of any other unresolved regressions from 2.6.30, please let
> > me know either and I'll add them to the list.
>
> Please add: http://lkml.org/lkml/2009/6/29/88
>
> Reinette Chatre is handling the bug and posted a patch in
> http://lkml.org/lkml/2009/6/30/224
Added as http://bugzilla.kernel.org/show_bug.cgi?id=13742.
Thanks,
Rafael
^ permalink raw reply
* Re: BUG REPORT: libertas causing kernel lockups
From: Alexander Barinov @ 2009-07-07 20:37 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200907070859.39413.hs4233@mail.mn-solutions.de>
On Tue, 7 Jul 2009 08:59:39 +0200
Holger Schurig <hs4233@mail.mn-solutions.de> wrote:
> > By executing 'cat /proc/net/wireless' I get the same bug:
>
> I haven't tested your exact but, but I've the following in my
> mind, back from about 1 year ago when I did lots of libertas and
> libertas_cs work:
>
> Access wireless stats made the libertas driver (in wext.c) issue
> a command towards the firmware in the hardware. I think it was
> the command to get the current SNR/RSSI/whatever.
>
> The libertas command-response-cycle does sleep, so you could
> trigger a bug. I once had a patch (and I think I posted that
> patch). The patch lied, by providing the last SNR/RSSI/whatever,
> and issueing a "get SNR/RSSI/whatever" in the background, just
> storing the result. So just one "cat /proc/net/wireless" returns
> bogus, but a continues command returns "valid" info, e.g. when
> doing "watch iwconfig eth1".
Sorry for asking a potentially stupid question as I am no way a
wireless hardware expert, but can this bug be caused by wrong firmware
version?
BTW, it is really hard to find a patch you are talking about in the
archive. Could you please give some clues on the key words to search
(besides your name and "patch", of cause)?
^ permalink raw reply
* Re: ath5k and ap mode
From: Bob Copeland @ 2009-07-07 19:43 UTC (permalink / raw)
To: Pavel Roskin; +Cc: tomek, linux-wireless
In-Reply-To: <1246994723.3393.14.camel@mj>
On Tue, Jul 7, 2009 at 3:25 PM, Pavel Roskin<proski@gnu.org> wrote:
>
> WPA: Countermeasures - dropped EAPOL request.
>
> I'm using WPA-PSK (WPA1 only) to simplify the configuration. My
> impression is that we need a serious effort to weed out such problems.
Hmm, does the same happen with nohwcrypt=1?
ISTR ath9k had a patch sometime last year having to do with the key
cache and AP mode, probably applies here too.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: 2.6.31-rc2: Reported regressions from 2.6.30
From: Frans Pop @ 2009-07-07 19:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-kernel, bunk, akpm, torvalds, kernel-testers, netdev,
linux-wireless
In-Reply-To: <35kKlbXMqWN.A.RXD.D0oUKB@chimera>
> If you know of any other unresolved regressions from 2.6.30, please let
> me know either and I'll add them to the list.
Please add: http://lkml.org/lkml/2009/6/29/88
Reinette Chatre is handling the bug and posted a patch in
http://lkml.org/lkml/2009/6/30/224
Thanks,
FJP
^ permalink raw reply
* Re: ath5k and ap mode
From: Pavel Roskin @ 2009-07-07 19:25 UTC (permalink / raw)
To: Bob Copeland; +Cc: tomek, linux-wireless
In-Reply-To: <b6c5339f0907070719l2db5aec3rc20160eabd41fd0a@mail.gmail.com>
On Tue, 2009-07-07 at 10:19 -0400, Bob Copeland wrote:
> On Tue, Jul 7, 2009 at 5:39 AM, tomek<paladyn11@gmail.com> wrote:
> > Hi.
> >
> > When ap-mode will working in driver ath5k?
>
> It will be enabled in 2.6.31... whether it works then or not is
> anyone's guess :)
I've just tested the mainline Linux git
(git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git)
and indeed, the AP support is there, so it will be in 2.6.31.
> (fyi, I'm currently waiting on some hw to arrive to do thorough
> testing of ath5k AP mode; some people say it works for them, but I'm
> still seeing some bugs here.)
My testing shows that ath5k is very unreliable in the AP mode, unlike
MadWifi. Sometimes hostapd reports this:
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: associated (aid 1)
wlan3: STA 00:17:c4:3b:fc:88 WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
wlan3: STA 00:17:c4:3b:fc:88 WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
wlan3: STA 00:17:c4:3b:fc:88 RADIUS: starting accounting session 4A538811-00000003
wlan3: STA 00:17:c4:3b:fc:88 WPA: pairwise key handshake completed (WPA)
wlan3: STA 00:17:c4:3b:fc:88 WPA: received EAPOL-Key 4/4 Pairwise with unexpected replay counter
wlan3: STA 00:17:c4:3b:fc:88 WPA: group key handshake completed (WPA)
At other times, it prints stuff like this:
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: associated (aid 1)
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: associated (aid 1)
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: deauthenticated due to local deauth request
wpa_supplicant on the client side reports strange messages too, for
instance:
Authentication with 00:00:00:00:00:00 timed out.
or
WPA: Countermeasures - dropped EAPOL request.
I'm using WPA-PSK (WPA1 only) to simplify the configuration. My
impression is that we need a serious effort to weed out such problems.
Also, I'm running the current wireless-testing.git on the client side,
and it take some time for wpa_supplicant to start, as it reports:
ioctl[SIOCSIWSCAN]: Device or resource busy
Failed to initiate AP scan.
It looks like the station spends too much time in the busy state. It
used to work better in the 2.6.30-rcX-wl days.
That's not meant to be a bugreport, more like a summary of all issues
I've seen.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: current status of 802.11s mesh in ath5k ?
From: Andrey Yurovsky @ 2009-07-07 18:42 UTC (permalink / raw)
To: Bob Copeland; +Cc: Hans Maes, linux-wireless
In-Reply-To: <20090705120515.GA6329@hash.localnet>
On Sun, Jul 5, 2009 at 5:05 AM, Bob Copeland<me@bobcopeland.com> wrote:
> On Fri, Jun 19, 2009 at 10:42:22AM -0700, Andrey Yurovsky wrote:
>> > I have been working on a patch to rework the beaconing, namely using
>> > bss_conf->enable_beacon and calling beacon_config whenever the beacon
>> > interval or beacon changes, that might fix it but I'm not too familiar
>> > with mesh details to say.
>>
>> 'looking forward to that patch. From the driver side, there's not
>> much difference between mesh beaconing and AP or IBSS beaconing.
>
> Can you check whether my most recent patch (I think it was 2/5 in the
> ath5k series) helps? I looked at mac80211 and it seems we set
> enable_beacon properly in mesh mode so that should configure beaconing
> to start.
Thanks Bob, I confirm that your patch fixes mesh beaconing.
-Andrey
^ permalink raw reply
* [PATCH] Atheros Kconfig needs to be dependent on WLAN_80211
From: Jay Sternberg @ 2009-07-07 18:18 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
Atheros top level menu needs a "depends WLAN_80211" to properly indent
within menuconfig and xconfig interfaces.
This is purely a visual issue but it effects all subsequent drivers.
The issue is the top level menu does not include a dependency on
WLAN_80211 so within the tree structure, Atheros is at the same level as
WLAN_80211 but when WLAN_80211 collapsed, the menu disappears along with
all subsequent drives, so it is really a subordinate.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com>
---
drivers/net/wireless/ath/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/Kconfig
b/drivers/net/wireless/ath/Kconfig
index d26e7b4..eb0337c 100644
--- a/drivers/net/wireless/ath/Kconfig
+++ b/drivers/net/wireless/ath/Kconfig
@@ -1,5 +1,6 @@
config ATH_COMMON
tristate "Atheros Wireless Cards"
+ depends on WLAN_80211
depends on ATH5K || ATH9K || AR9170_USB
source "drivers/net/wireless/ath/ath5k/Kconfig"
--
1.5.4.3
^ permalink raw reply related
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