* Re: [PATCH] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-07-26 16:34 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: ath5k-devel, linux-wireless, Luis R. Rodriguez
In-Reply-To: <20100528100901.14580.1322.stgit@fate.lan>
Hi,
Just want to summarize and finally put that problem to rest.
Was the patch that removes & sets on CONFIG_PCIEASPM? accepted?
Is it possible to check that all ath5k pcie devices that must not use
L0s actually have the 'PCI_EXP_DEVCAP_RBER' disabled (this bit causes
pcie device be marked as legacy, and ASPM is disabled on it)
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: Hardware needs to know when EAP nego is complete
From: Jouni Malinen @ 2010-07-26 14:30 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: johannes, linux-wireless, Coelho Luciano Roth
In-Reply-To: <1280142400.6475.33.camel@wimaxnb.nmp.nokia.com>
On Mon, Jul 26, 2010 at 02:06:40PM +0300, Juuso Oikarinen wrote:
> There are lots of timing issues involved, and there is a priority
> between WLAN an BT. To ensure BT A2DP and SCO work properly, BT needs to
> have enough priority at the expense of WLAN performance. While this
> works well enough when connected, during WLAN association and especially
> during EAP negotiation the priority needs to be more on the WLAN side to
> ensure reliability.
Could you please explain why EAP negotiation is a special case? It is
using data frames just like any other operation after it..
> So, what this all boils down to is that the wl1271 driver needs to know
> when the association, including the possible EAP negotations are fully
> complete, to be able to adjust the priority.
This sounds like a horrible hack and really, the unreliability during
EAP should likely fixed in some other way.
> Currently, there is no such information available to the driver. In fact
> this information is not available anywhere in the kernel level either
> (as the details of the EAP negotiation, needed keys etc are controlled
> in user-space), so the trigger would need to come from user-space.
That's not actually true.. At least when run with wpa_supplicant is
setting operation state to IF_OPER_UP when the full authentication
sequence (i.e., not only EAP, but also the following 4-way handshake
with EAPOL-Key frames) is done (and IF_OPER_DORMANT when not ready).
This is needed for other purposes to indicate when real data traffic can
be sent, e.g., for DHCP clients.
I don't think I would support the idea of using that information to
change the WLAN vs. BT priority without some additional data on what
exactly goes wrong during EAP negotiation, but at least the information
should already be in the kernel, so we do not need to change nl80211 for
this.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] mac80211: simplify key locking
From: Johannes Berg @ 2010-07-26 14:27 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John Linville, linux-wireless
In-Reply-To: <20100726142058.GA7324@jm.kir.nu>
On Mon, 2010-07-26 at 07:20 -0700, Jouni Malinen wrote:
> Well, the latter one may indeed do that since debugfs_remove_recursive()
> survives NULL pointer. However, the former one does not.
> ieee80211_key_disable_hw_accel() has a key->local dereference and it
> oopses without the "if (key->local)" part here (before checking whether
> the key is uploaded to hardware). I started first making that handle
> unlinked keys, but since this gets called before
> ieee80211_key_enable_hw_accel() in the problem case, it looked more
> logical to fix the caller not to get to the disable function in the
> first place.
Oh, indeed, that comes before the check. I agree then, this patch seems
like the best fix.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: simplify key locking
From: Jouni Malinen @ 2010-07-26 14:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1280130178.3693.1.camel@jlt3.sipsolutions.net>
On Mon, Jul 26, 2010 at 09:42:58AM +0200, Johannes Berg wrote:
> On Sun, 2010-07-25 at 18:39 -0700, Jouni Malinen wrote:
> > - ieee80211_key_disable_hw_accel(key);
> > + if (key->local)
> > + ieee80211_key_disable_hw_accel(key);
>
>
> > - ieee80211_debugfs_key_remove(key);
> > + if (key->local)
> > + ieee80211_debugfs_key_remove(key);
>
> These might look odd, but they're fine on a key that hasn't been used
> since it couldn't have been uploaded to hardware, or put into debugfs,
> so they'll just exit right away.
Well, the latter one may indeed do that since debugfs_remove_recursive()
survives NULL pointer. However, the former one does not.
ieee80211_key_disable_hw_accel() has a key->local dereference and it
oopses without the "if (key->local)" part here (before checking whether
the key is uploaded to hardware). I started first making that handle
unlinked keys, but since this gets called before
ieee80211_key_enable_hw_accel() in the problem case, it looked more
logical to fix the caller not to get to the disable function in the
first place.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: Hardware needs to know when EAP nego is complete
From: Juuso Oikarinen @ 2010-07-26 11:42 UTC (permalink / raw)
To: ext Johannes Berg
Cc: linux-wireless@vger.kernel.org,
Coelho Luciano (Nokia-MS/Helsinki)
In-Reply-To: <1280143430.3693.7.camel@jlt3.sipsolutions.net>
On Mon, 2010-07-26 at 13:23 +0200, ext Johannes Berg wrote:
> On Mon, 2010-07-26 at 14:06 +0300, Juuso Oikarinen wrote:
> >
> >
> > Thoughts? Ideas? Would this be acceptable?
>
> I really don't like this. You _can_ figure out if a given frame is EAP
> by looking at its ethertype (but don't implement WAPI then!) ... can't
> you just give it priority _by frame_?
I don't like it either, but my hands are bound. With this chip I cannot
give priority by frame. The way it works on that chip is that after
association you tell the chip to change mode, and that's it - no going
back.
> Also, it doesn't make any sense, since if you really care then you want
> rekeying to also have priority...
Yep, this is a problem I too have been thinking about. However, with
this chip, you cannot change the priority back for re-keying. So
essentially, those negotiations are done with the "lowered" WLAN
priority, and if they happen to fail the connection manager will as
result end up associating again with increased priority.
The fact is we need this to be done this way. I have been thinking about
all possible ways to do this hack inside the driver, triggering on
setting of keys etc, but as far as I can tell it's not doable without
assumptions having unacceptable impact on functionality.
We'll have to consider some driver-specific hack-interface then, along
with a correspondingly hacked user-space connection manager. This will
just cause other users of the wl1271 driver ending up with dysfunctional
BT-WLAN coex.
-Juuso
> johannes
>
^ permalink raw reply
* Re: Hardware needs to know when EAP nego is complete
From: Johannes Berg @ 2010-07-26 11:23 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless, Coelho Luciano Roth
In-Reply-To: <1280142400.6475.33.camel@wimaxnb.nmp.nokia.com>
On Mon, 2010-07-26 at 14:06 +0300, Juuso Oikarinen wrote:
> Hello Johannes, hello all,
>
> As you may know the wl1271 hardware implements WLAN-Bluetooth
> co-existence by toggling a single antenna between WLAN and Bluetooth.
>
> To pull this off, several quirks are required, for instance WLAN must be
> forced to full-PSM so that antenna-time for BT can be made available.
> This is implemented by the wl1271 driver with the help of the mac80211.
>
> There are lots of timing issues involved, and there is a priority
> between WLAN an BT. To ensure BT A2DP and SCO work properly, BT needs to
> have enough priority at the expense of WLAN performance. While this
> works well enough when connected, during WLAN association and especially
> during EAP negotiation the priority needs to be more on the WLAN side to
> ensure reliability.
>
> The wl1271 driver starts association with the priority on WLAN, which
> means that BT performance is compromised. The wl1271 driver should
> change the priority to BT after association and the EAP negotiations are
> complete, to make sure BT is performing acceptably.
>
> So, what this all boils down to is that the wl1271 driver needs to know
> when the association, including the possible EAP negotations are fully
> complete, to be able to adjust the priority.
>
> Currently, there is no such information available to the driver. In fact
> this information is not available anywhere in the kernel level either
> (as the details of the EAP negotiation, needed keys etc are controlled
> in user-space), so the trigger would need to come from user-space.
>
> To enable this, an operand would be needed to nl80211 to indicate
> completion of association (including the EAP negotiations.)
> Corresponding functions would then be needed on the cfg80211 ops and
> mac80211 ops.
>
> User-space would then call the operand when association is complete. For
> open/WEP AP's the operand would be called immediately after association,
> and for WPA AP's the operand would be called once the EAP negotiations
> are complete.
>
>
> Thoughts? Ideas? Would this be acceptable?
I really don't like this. You _can_ figure out if a given frame is EAP
by looking at its ethertype (but don't implement WAPI then!) ... can't
you just give it priority _by frame_?
Also, it doesn't make any sense, since if you really care then you want
rekeying to also have priority...
johannes
^ permalink raw reply
* Hardware needs to know when EAP nego is complete
From: Juuso Oikarinen @ 2010-07-26 11:06 UTC (permalink / raw)
To: johannes, linux-wireless; +Cc: Coelho Luciano Roth
Hello Johannes, hello all,
As you may know the wl1271 hardware implements WLAN-Bluetooth
co-existence by toggling a single antenna between WLAN and Bluetooth.
To pull this off, several quirks are required, for instance WLAN must be
forced to full-PSM so that antenna-time for BT can be made available.
This is implemented by the wl1271 driver with the help of the mac80211.
There are lots of timing issues involved, and there is a priority
between WLAN an BT. To ensure BT A2DP and SCO work properly, BT needs to
have enough priority at the expense of WLAN performance. While this
works well enough when connected, during WLAN association and especially
during EAP negotiation the priority needs to be more on the WLAN side to
ensure reliability.
The wl1271 driver starts association with the priority on WLAN, which
means that BT performance is compromised. The wl1271 driver should
change the priority to BT after association and the EAP negotiations are
complete, to make sure BT is performing acceptably.
So, what this all boils down to is that the wl1271 driver needs to know
when the association, including the possible EAP negotations are fully
complete, to be able to adjust the priority.
Currently, there is no such information available to the driver. In fact
this information is not available anywhere in the kernel level either
(as the details of the EAP negotiation, needed keys etc are controlled
in user-space), so the trigger would need to come from user-space.
To enable this, an operand would be needed to nl80211 to indicate
completion of association (including the EAP negotiations.)
Corresponding functions would then be needed on the cfg80211 ops and
mac80211 ops.
User-space would then call the operand when association is complete. For
open/WEP AP's the operand would be called immediately after association,
and for WPA AP's the operand would be called once the EAP negotiations
are complete.
Thoughts? Ideas? Would this be acceptable?
-Juuso
^ permalink raw reply
* iw dev wlan0 link - "Not connected"
From: Zhongliang Zhao @ 2010-07-26 9:29 UTC (permalink / raw)
To: linux-wireless
Dear all,
When I use "iw dev wlan0 link" to get information on wlan0 (basically to
check the channel used on wlan0),
it says: " Not connected "
Can someone tell me how to fix this?
Many thanks.
Zhongliang Zhao
^ permalink raw reply
* Re: iwlwifi connection problems
From: Johannes Berg @ 2010-07-26 9:17 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: Alex Romosan, linux-wireless@vger.kernel.org
In-Reply-To: <1279917523.10769.1.camel@wwguy-huron>
On Fri, 2010-07-23 at 13:38 -0700, Guy, Wey-Yi wrote:
> Hi Johannes,
>
> On Fri, 2010-07-23 at 13:14 -0700, Alex Romosan wrote:
> > since kernel 2.6.35-rc3 (i didn't try 1 or 2) i haven't been able to
> > connect to a hidden wireless access point using the iwlwifi driver. i
> > can connect to open ones though (the ones that broadcast their name).
> > 2.6.34 worked without any problems. any ideas?
> >
> > this is with the driver in the standard linux kernel (2.6.35-rc6 is the
> > latest one i tried).
>
> Do you aware any changes?
Nope, and it works fine here on wireless-testing.
johannes
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Johannes Berg @ 2010-07-26 8:32 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: ilw, linux-wireless
In-Reply-To: <20100726082754.GA14881@comet.dominikbrodowski.net>
On Mon, 2010-07-26 at 10:27 +0200, Dominik Brodowski wrote:
> > > the problem didn't reappear when using wireless-testing plus your patch. As
> > > I can't reproduce it -- it just happened every once in a while (maybe once a
> > > day?) -- this doesn't necessarily mean the bug is fixed, but...
> >
> > Alright, thanks. I don't suppose you tried wireless-testing w/o the
> > patch?
>
> No. Shall I?
Well, I'd be interested in whether or not my patch fixed it, but I think
I'll push it upstream anyway.
johannes
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Dominik Brodowski @ 2010-07-26 8:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: ilw, linux-wireless
In-Reply-To: <1280132498.3693.2.camel@jlt3.sipsolutions.net>
On Mon, Jul 26, 2010 at 10:21:38AM +0200, Johannes Berg wrote:
> On Mon, 2010-07-26 at 10:17 +0200, Dominik Brodowski wrote:
> > Hey,
> >
> > On Fri, Jul 23, 2010 at 10:33:10AM +0200, Johannes Berg wrote:
> > > > > Oh, it's against wireless-testing, which apparently has some other mods
> > > > > there. I'll have to see if any other patch needs to go into .35 too.
> > > >
> > > > That's fine, I'll just test wireless-testing plus your patch from now on ;)
> > >
> > > Hah, ok, I made a note to backport the patch for you, guess I'll delete
> > > it. Wouldn't have gotten around to it today anyway I think.
> >
> > the problem didn't reappear when using wireless-testing plus your patch. As
> > I can't reproduce it -- it just happened every once in a while (maybe once a
> > day?) -- this doesn't necessarily mean the bug is fixed, but...
>
> Alright, thanks. I don't suppose you tried wireless-testing w/o the
> patch?
No. Shall I?
Best,
Dominik
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Johannes Berg @ 2010-07-26 8:21 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: ilw, linux-wireless
In-Reply-To: <20100726081713.GA14192@comet.dominikbrodowski.net>
On Mon, 2010-07-26 at 10:17 +0200, Dominik Brodowski wrote:
> Hey,
>
> On Fri, Jul 23, 2010 at 10:33:10AM +0200, Johannes Berg wrote:
> > > > Oh, it's against wireless-testing, which apparently has some other mods
> > > > there. I'll have to see if any other patch needs to go into .35 too.
> > >
> > > That's fine, I'll just test wireless-testing plus your patch from now on ;)
> >
> > Hah, ok, I made a note to backport the patch for you, guess I'll delete
> > it. Wouldn't have gotten around to it today anyway I think.
>
> the problem didn't reappear when using wireless-testing plus your patch. As
> I can't reproduce it -- it just happened every once in a while (maybe once a
> day?) -- this doesn't necessarily mean the bug is fixed, but...
Alright, thanks. I don't suppose you tried wireless-testing w/o the
patch?
johannes
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Dominik Brodowski @ 2010-07-26 8:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: ilw, linux-wireless
In-Reply-To: <1279873990.3745.1.camel@jlt3.sipsolutions.net>
Hey,
On Fri, Jul 23, 2010 at 10:33:10AM +0200, Johannes Berg wrote:
> > > Oh, it's against wireless-testing, which apparently has some other mods
> > > there. I'll have to see if any other patch needs to go into .35 too.
> >
> > That's fine, I'll just test wireless-testing plus your patch from now on ;)
>
> Hah, ok, I made a note to backport the patch for you, guess I'll delete
> it. Wouldn't have gotten around to it today anyway I think.
the problem didn't reappear when using wireless-testing plus your patch. As
I can't reproduce it -- it just happened every once in a while (maybe once a
day?) -- this doesn't necessarily mean the bug is fixed, but...
Best,
Dominik
^ permalink raw reply
* Re: [PATCH] mac80211: simplify key locking
From: Johannes Berg @ 2010-07-26 7:42 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John Linville, linux-wireless
In-Reply-To: <20100726013953.GA29386@jm.kir.nu>
On Sun, 2010-07-25 at 18:39 -0700, Jouni Malinen wrote:
> The following seems to be more or less minimal patch with that
> approach to get rid of this oops with FT protocol.. Is this what you
> were looking for?
Well so to answer both your emails :-)
> - ieee80211_key_disable_hw_accel(key);
> + if (key->local)
> + ieee80211_key_disable_hw_accel(key);
> - ieee80211_debugfs_key_remove(key);
> + if (key->local)
> + ieee80211_debugfs_key_remove(key);
These might look odd, but they're fine on a key that hasn't been used
since it couldn't have been uploaded to hardware, or put into debugfs,
so they'll just exit right away.
The rest of the patch is exactly what I was thinking of.
johannes
^ permalink raw reply
* Re: ath5k phy0: unsupported jumbo
From: Vladimir Linevich @ 2010-07-26 7:06 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <43e72e891001251025s1e3fa358v31527d1b5f7e3436@mail.gmail.com>
I've found that this bug is a result of poor hardware ASPM support.
It is a hardware bug that is worked around in windows driver by
disabling PCIE ASPM L0S.
There's a solution - turn ASPM L0S off for this device.
---
1. Download enable-aspm
kernel org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
2. Get your root complex:
$ lspci -tv
0000:00
...
+-1c.2-[0000:03]----00.0 Atheros Communications Inc. AR5001 Wireless Network
Adapter
...
00:1c.2
3. Get your endpoint:
$ lspci
...
03:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network
Adapter (rev 01)
...
= 03:00.0
4. Now you neet to edit your enable-aspm
# You just need to modify these three values:
ROOT_COMPLEX="00:1c.2"
ENDPOINT="03:00.0"
ASPM_SETTING=2
5. Now executing:
vo-one@acerone:~$ sudo bash enable-aspm
[sudo] password for vo-one:
Root complex:
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev
02)
0x50 : 0x43 --> 0x42 ... [SUCCESS]]
L1 only
Endpoint:
03:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network
Adapter (rev 01)
0x70 : 0x4B --> 0x4A ... [SUCCESS]]
L1 only
6. Making the script executed at system startup:
sudo chmod +x enable-aspm
sudo cp enable-aspm /usr/bin
sudo cat "enable-aspm" > /etc/rc.conf
hope that helps
^ permalink raw reply
* Re: BUG at arch/x86/mm/physaddr.c:5
From: Jike Song @ 2010-07-26 6:13 UTC (permalink / raw)
To: Ortwin Glück
Cc: linux-kernel, Felix Fietkau, Vasanthakumar Thiagarajan,
lrodriguez, jmalinen, Sujith.Manoharan, senthilkumar,
linux-wireless
In-Reply-To: <4C499E6F.8030507@odi.ch>
2010/7/23 Ortwin Glück <odi@odi.ch>:
> On 23.07.2010 10:04, Jike Song wrote:
>> Seems to be a logical error? Does the following patch remove your Oops?
>
> Looking at the init code I agree. Yes, the patch fixes the OOPS. I am sure
> because the OOPS occurred at every boot and now it's gone.
>
> Thanks!
>
> Ortwin
Hi Maintainers,
Since Ortwin has confirmed this patch , would you give me an ACK/NAK please?
--
Thanks,
Jike
>From 1414829dcc5b53ef4802f5de2b9be58e2ca0fb23 Mon Sep 17 00:00:00 2001
From: Jike Song <albcamus@gmail.com>
Date: Mon, 26 Jul 2010 13:42:41 +0800
Subject: [PATCH] ath9k: fix wrong DMA direction in RX tasklet
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Commit b5c80475abaad015699384ca64ef8229fdd88758 introduced edma
support for RX, hence bidirectional DMA support. But it
specified the DMA type as DMA_FROM_DEVICE by mistake.
Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Jike Song <albcamus@gmail.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index ca6065b..e3e5291 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -844,9 +844,9 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
int dma_type;
if (edma)
- dma_type = DMA_FROM_DEVICE;
- else
dma_type = DMA_BIDIRECTIONAL;
+ else
+ dma_type = DMA_FROM_DEVICE;
qtype = hp ? ATH9K_RX_QUEUE_HP : ATH9K_RX_QUEUE_LP;
spin_lock_bh(&sc->rx.rxbuflock);
--
1.6.2
^ permalink raw reply related
* Re: [PATCH] mac80211: simplify key locking
From: Jouni Malinen @ 2010-07-26 1:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1279962385.8223.2.camel@jlt3.sipsolutions.net>
On Sat, Jul 24, 2010 at 11:06:25AM +0200, Johannes Berg wrote:
> The fix should be passing in the local pointer to ieee80211_key_free() I
> guess. Can you try that?
The following seems to be more or less minimal patch with that
approach to get rid of this oops with FT protocol.. Is this what you
were looking for?
---
net/mac80211/cfg.c | 6 +++---
net/mac80211/key.c | 13 ++++++-------
net/mac80211/key.h | 3 ++-
net/mac80211/sta_info.c | 2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
--- wireless-testing.orig/net/mac80211/cfg.c 2010-07-24 10:48:00.000000000 -0700
+++ wireless-testing/net/mac80211/cfg.c 2010-07-24 10:49:20.000000000 -0700
@@ -158,7 +158,7 @@ static int ieee80211_add_key(struct wiph
if (mac_addr) {
sta = sta_info_get_bss(sdata, mac_addr);
if (!sta) {
- ieee80211_key_free(key);
+ ieee80211_key_free(sdata->local, key);
err = -ENOENT;
goto out_unlock;
}
@@ -192,7 +192,7 @@ static int ieee80211_del_key(struct wiph
goto out_unlock;
if (sta->key) {
- ieee80211_key_free(sta->key);
+ ieee80211_key_free(sdata->local, sta->key);
WARN_ON(sta->key);
ret = 0;
}
@@ -205,7 +205,7 @@ static int ieee80211_del_key(struct wiph
goto out_unlock;
}
- ieee80211_key_free(sdata->keys[key_idx]);
+ ieee80211_key_free(sdata->local, sdata->keys[key_idx]);
WARN_ON(sdata->keys[key_idx]);
ret = 0;
--- wireless-testing.orig/net/mac80211/key.c 2010-07-24 10:47:31.000000000 -0700
+++ wireless-testing/net/mac80211/key.c 2010-07-25 18:05:57.000000000 -0700
@@ -323,13 +323,15 @@ static void __ieee80211_key_destroy(stru
if (!key)
return;
- ieee80211_key_disable_hw_accel(key);
+ if (key->local)
+ ieee80211_key_disable_hw_accel(key);
if (key->conf.alg == ALG_CCMP)
ieee80211_aes_key_free(key->u.ccmp.tfm);
if (key->conf.alg == ALG_AES_CMAC)
ieee80211_aes_cmac_key_free(key->u.aes_cmac.tfm);
- ieee80211_debugfs_key_remove(key);
+ if (key->local)
+ ieee80211_debugfs_key_remove(key);
kfree(key);
}
@@ -410,15 +412,12 @@ static void __ieee80211_key_free(struct
__ieee80211_key_destroy(key);
}
-void ieee80211_key_free(struct ieee80211_key *key)
+void ieee80211_key_free(struct ieee80211_local *local,
+ struct ieee80211_key *key)
{
- struct ieee80211_local *local;
-
if (!key)
return;
- local = key->sdata->local;
-
mutex_lock(&local->key_mtx);
__ieee80211_key_free(key);
mutex_unlock(&local->key_mtx);
--- wireless-testing.orig/net/mac80211/key.h 2010-07-24 10:47:52.000000000 -0700
+++ wireless-testing/net/mac80211/key.h 2010-07-24 10:48:55.000000000 -0700
@@ -135,7 +135,8 @@ struct ieee80211_key *ieee80211_key_allo
void ieee80211_key_link(struct ieee80211_key *key,
struct ieee80211_sub_if_data *sdata,
struct sta_info *sta);
-void ieee80211_key_free(struct ieee80211_key *key);
+void ieee80211_key_free(struct ieee80211_local *local,
+ struct ieee80211_key *key);
void ieee80211_set_default_key(struct ieee80211_sub_if_data *sdata, int idx);
void ieee80211_set_default_mgmt_key(struct ieee80211_sub_if_data *sdata,
int idx);
--- wireless-testing.orig/net/mac80211/sta_info.c 2010-07-24 10:48:03.000000000 -0700
+++ wireless-testing/net/mac80211/sta_info.c 2010-07-24 10:49:33.000000000 -0700
@@ -647,7 +647,7 @@ static int __must_check __sta_info_destr
return ret;
if (sta->key) {
- ieee80211_key_free(sta->key);
+ ieee80211_key_free(local, sta->key);
WARN_ON(sta->key);
}
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: Master mode in rtl8187
From: August @ 2010-07-26 1:14 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: linux-wireless
In-Reply-To: <AANLkTinZG-kHrS-s_94Bq4JNXuyf6kWzqsVRAVjdGQ3c@mail.gmail.com>
I've followed the driver of the rtl818x in 26.34 and draw some
pictures of source.However, some additional work interrupted me.
The address is http://augustseu-blog.appspot.com/2010/06/6/Wlan.html
If it was any helpful,
2010/7/25 Hin-Tak Leung <hintak.leung@gmail.com>:
> On 7/21/10, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> On 07/21/2010 01:17 PM, Ben Gamari wrote:
>>> Hey all,
>>>
>>> I recently purchased a Netgear WG111v2 (based on rtl8187b) and after
>>> seeing scattered reports[1] that master mode may be supported by the
>>> rtl8187 driver. Unfortunately, hostapd throws up when it attempts to put
>>> the card into master mode. Is master mode supported by this driver? I've
>>> tried both 2.6.34 as well as the latest wireless-testing tree and
>>> neither seem to work.
>>
>> My WG111V2 has an RTL8187L chip in it, not an RTL8187B. No, master mode is
>> NOT
>> supported by this driver. Adding that feature has been on my list of things
>> to
>> do, but the priority is very low. I really have little desire to convert my
>> $600
>> laptop into a $40 access point.
>>
>>> I noticed there was a patch[2] sent out a few years back, but it seems
>>> no one followed up. While I don't have much experience working with
>>> wireless hardware I've done kernel driver work before, so with some
>>> guidance I might be able to finish up that patch. Any input would be
>>> greatly appreciated. Thanks!
>>
>>> [1]
>>> http://osdir.com/ml/linux.kernel.wireless.general/2007-07/msg00289.html
>>> [2]
>>> http://osdir.com/ml/linux.kernel.wireless.general/2007-06/msg00455.html
>>
>> That patch is useless. The rtl8187 driver and mac80211 have changed so much
>> that
>> it cannot be made to apply, and would not be likely to work.
>>
>> One other thing to consider. The RTL8187L has only a single transmit queue.
>> Will
>> the device be able to transmit beacons with an appropriate timing accuracy?
>>
>> To modify the driver, you will need to study some other driver that does
>> work in
>> master mode.
>
> There were some discussion a while back that some generic master mode
> support for all mac80211-based drivers might eventually happen. Is
> that still the case?
>
> Hin-Tak
> --
> 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
>
--
---------------------------------
Best Regards
张杰
ADD：苏州 工业园区 文景路 东南大学苏州研究院
^ permalink raw reply
* Re: [PATCH] mac80211: simplify key locking
From: Jouni Malinen @ 2010-07-26 1:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1279962385.8223.2.camel@jlt3.sipsolutions.net>
On Sat, Jul 24, 2010 at 11:06:25AM +0200, Johannes Berg wrote:
> I removed the comment because the linked vs. not linked handling is a
> bit different now I think ... I don't think we should restore the NULL
> handling as it was before, since __ieee80211_key_free() should be able
> to handle this now.
>
> The fix should be passing in the local pointer to ieee80211_key_free() I
> guess. Can you try that?
__ieee80211_key_free() handles this, but the function it calls does
not.. ieee80211_key_disable_hw_accel() dereferences key->local before
checking whether the key has been uploaded to hardware (which this key
would not be).. Would you like the local pointer to be passed to
ieee80211_key_disable_hw_accel(), too? Or make __ieee80211_key_destroy()
skip that call if key->local == NULL? Actually, calling
__ieee80211_key_destroy() with not-yet-linked key is somewhat odd from
the debugfs view point, too (ieee80211_debugfs_key_remove() gets called
even when matching _key_add has not happened).
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* wl1251 blocking soon after association(before it blocked about 30min after association)
From: Denis 'GNUtoo' Carikli @ 2010-07-25 22:14 UTC (permalink / raw)
To: linux-wireless
hi, I'm still fighting with my wl1251_sdio issues on my htcdream under
GNU/Linux(not android).
I've found that patch for wl1271:
http://www.spinics.net/lists/linux-wireless/msg46931.html
,and I rebased it for wl1251(should I send a git patch for it?).
but I've still some issues.
Here on a public wireless access point I have:
[ 315.377563] wl1251: intr: 0x8
[ 315.377624] wl1251: RX: FW +1
[ 315.377624] wl1251: RX counter: 8
[ 315.377655] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.377777] wl1251: rx skb 0xc6b8ed80: 55 B
[ 315.557312] wl1251: IRQ
[ 315.557403] wl1251: IRQ work
[ 315.557556] wl1251: intr: 0x9
[ 315.557586] wl1251: RX: FW +2
[ 315.557617] wl1251: RX counter: 10
[ 315.557617] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.557739] wl1251: rx skb 0xc69eb6c0: 135 B
[ 315.557922] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 315.558044] wl1251: rx skb 0xc69eb6c0: 135 B
[ 315.558197] wl1251: RX: FW +2
[ 315.558227] wl1251: RX counter: 12
[ 315.558227] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.558349] wl1251: rx skb 0xc69eb6c0: 135 B
[ 315.558441] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 315.558563] wl1251: rx skb 0xc69eb6c0: 109 B
[ 315.558715] wl1251: RX: FW and host in sync
[ 315.558746] wl1251: RX counter: 12
[ 315.558776] wl1251: INTR is 0
[ 315.567382] wl1251: IRQ
[ 315.569396] wl1251: IRQ work
[ 315.569580] wl1251: intr: 0x1
[ 315.569641] wl1251: RX: FW +1
[ 315.569641] wl1251: RX counter: 13
[ 315.569671] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.569793] wl1251: rx skb 0xc4026240: 141 B beacon
[ 315.587310] wl1251: IRQ
[ 315.587493] wl1251: IRQ work
[ 315.587646] wl1251: intr: 0x8
[ 315.587707] wl1251: RX: FW +1
[ 315.587738] wl1251: RX counter: 14
[ 315.587738] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.587860] wl1251: rx skb 0xc4026240: 115 B beacon
[ 315.627288] wl1251: IRQ
[ 315.627410] wl1251: IRQ work
[ 315.627563] wl1251: intr: 0x9
[ 315.627624] wl1251: RX: FW +2
[ 315.627624] wl1251: RX counter: 0
[ 315.627655] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.627777] wl1251: rx skb 0xc4026300: 145 B
[ 315.627929] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 315.628051] wl1251: rx skb 0xc4026300: 145 B
[ 315.637390] wl1251: IRQ
[ 315.639068] wl1251: IRQ work
[ 315.639251] wl1251: intr: 0x1
[ 315.639312] wl1251: RX: FW +1
[ 315.639343] wl1251: RX counter: 1
[ 315.639343] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.639465] wl1251: rx skb 0xc6a2ec00: 145 B
[ 315.767364] wl1251: IRQ
[ 315.767517] wl1251: IRQ work
[ 315.767669] wl1251: intr: 0x18
[ 315.767730] wl1251: RX: FW +1
[ 315.767761] wl1251: RX counter: 2
[ 315.767761] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.767883] wl1251: rx skb 0xc6b8e780: 24 B
[ 315.767974] wl1251: WL1251_ACX_INTR_EVENT (0x11)
[ 315.768005] wl1251: EVENT on mbox 0
[ 315.768066] wl1251: MBOX DUMP:
[ 315.768096] wl1251: vector: 0x8
[ 315.768096] wl1251: mask: 0xe73f7f57
[ 315.768096] wl1251: vector: 0x8
[ 315.768127] wl1251: status: 0x8d, channels: 51995
[ 315.768188] wl1251: mac80211 config ch 1 psm off power 20
[ 315.768218] wl1251: mac80211 config ch 1 psm off power 20
[ 315.768218] wl1251: mac80211 hw scan completed
[ 315.827362] wl1251: IRQ
[ 315.827514] wl1251: IRQ work
[ 315.827636] wl1251: intr: 0x1
[ 315.827697] wl1251: RX: FW +1
[ 315.827728] wl1251: RX counter: 3
[ 315.827728] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.827850] wl1251: rx skb 0xc6afc780: 24 B
[ 315.947326] wl1251: IRQ
[ 315.947448] wl1251: IRQ work
[ 315.947601] wl1251: intr: 0x8
[ 315.947662] wl1251: RX: FW +1
[ 315.947692] wl1251: RX counter: 4
[ 315.947692] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 315.947814] wl1251: rx skb 0xc6afc000: 24 B
[ 316.067352] wl1251: IRQ
[ 316.067474] wl1251: IRQ work
[ 316.067626] wl1251: intr: 0x1
[ 316.067687] wl1251: RX: FW +1
[ 316.067687] wl1251: RX counter: 5
[ 316.067718] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 316.067810] wl1251: rx skb 0xc4026e40: 24 B
[ 316.177368] wl1251: IRQ
[ 316.177459] wl1251: IRQ work
[ 316.177581] wl1251: intr: 0x8
[ 316.177642] wl1251: RX: FW +1
[ 316.177673] wl1251: RX counter: 6
[ 316.177673] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 316.177795] wl1251: rx skb 0xc6ab8600: 24 B
[ 316.237304] wl1251: IRQ
[ 316.237396] wl1251: IRQ work
[ 316.237548] wl1251: intr: 0x1
[ 316.237609] wl1251: RX: FW +1
[ 316.237640] wl1251: RX counter: 7
[ 316.237640] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 316.237731] wl1251: rx skb 0xc6a2e0c0: 24 B
[ 316.347351] wl1251: IRQ
[ 316.347473] wl1251: IRQ work
[ 316.347625] wl1251: intr: 0x8
[ 316.347686] wl1251: RX: FW +1
[ 316.347686] wl1251: RX counter: 8
[ 316.347717] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 316.347808] wl1251: rx skb 0xc6b8e600: 24 B
[ 316.877349] wl1251: IRQ
[ 316.877441] wl1251: IRQ work
[ 316.877563] wl1251: intr: 0x1
[ 316.877624] wl1251: RX: FW +1
[ 316.877624] wl1251: RX counter: 9
[ 316.877655] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 316.877746] wl1251: rx skb 0xc69eb540: 16 B
[ 317.027404] wl1251: IRQ
[ 317.027526] wl1251: IRQ work
[ 317.027679] wl1251: intr: 0x9
[ 317.027740] wl1251: RX: FW +2
[ 317.027770] wl1251: RX counter: 11
[ 317.027770] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.027923] wl1251: rx skb 0xc6afc780: 265 B beacon
[ 317.028015] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 317.028137] wl1251: rx skb 0xc6afc540: 265 B beacon
[ 317.037353] wl1251: IRQ
[ 317.039031] wl1251: IRQ work
[ 317.039215] wl1251: intr: 0x8
[ 317.039276] wl1251: RX: FW +1
[ 317.039306] wl1251: RX counter: 12
[ 317.039306] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.039459] wl1251: rx skb 0xc40266c0: 251 B beacon
[ 317.057312] wl1251: IRQ
[ 317.057434] wl1251: IRQ work
[ 317.057586] wl1251: intr: 0x1
[ 317.057617] wl1251: RX: FW +1
[ 317.057647] wl1251: RX counter: 13
[ 317.057647] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.057769] wl1251: rx skb 0xc4026e40: 24 B
[ 317.127349] wl1251: IRQ
[ 317.127471] wl1251: IRQ work
[ 317.127624] wl1251: intr: 0x8
[ 317.127685] wl1251: RX: FW +1
[ 317.127685] wl1251: RX counter: 14
[ 317.127716] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.127838] wl1251: rx skb 0xc6ab8f00: 265 B beacon
[ 317.137329] wl1251: IRQ
[ 317.138793] wl1251: IRQ work
[ 317.138977] wl1251: intr: 0x1
[ 317.139038] wl1251: RX: FW +1
[ 317.139068] wl1251: RX counter: 15
[ 317.139068] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.139221] wl1251: rx skb 0xc6a2e300: 277 B beacon
[ 317.237365] wl1251: IRQ
[ 317.237457] wl1251: IRQ work
[ 317.237579] wl1251: intr: 0x9
[ 317.237640] wl1251: RX: FW +2
[ 317.237670] wl1251: RX counter: 1
[ 317.237670] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.237792] wl1251: rx skb 0xc6b8e3c0: 265 B beacon
[ 317.237915] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 317.238037] wl1251: rx skb 0xc6b8e780: 277 B beacon
[ 317.337310] wl1251: IRQ
[ 317.337371] wl1251: IRQ work
[ 317.337524] wl1251: intr: 0x9
[ 317.337585] wl1251: RX: FW +2
[ 317.337585] wl1251: RX counter: 3
[ 317.337615] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.337738] wl1251: rx skb 0xc69ebd80: 265 B beacon
[ 317.337860] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 317.337982] wl1251: rx skb 0xc69ebf00: 265 B beacon
[ 317.338134] wl1251: RX: FW +1
[ 317.338134] wl1251: RX counter: 4
[ 317.338165] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.338287] wl1251: rx skb 0xc6afcb40: 251 B beacon
[ 317.447357] wl1251: IRQ
[ 317.447479] wl1251: IRQ work
[ 317.447631] wl1251: intr: 0x1
[ 317.447692] wl1251: RX: FW +1
[ 317.447692] wl1251: RX counter: 5
[ 317.447723] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.447845] wl1251: rx skb 0xc40263c0: 251 B beacon
[ 317.547363] wl1251: IRQ
[ 317.547485] wl1251: IRQ work
[ 317.547637] wl1251: intr: 0x9
[ 317.547698] wl1251: RX: FW +2
[ 317.547698] wl1251: RX counter: 7
[ 317.547729] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.547851] wl1251: rx skb 0xc6ab8600: 265 B beacon
[ 317.547943] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 317.548095] wl1251: rx skb 0xc6ab8780: 277 B beacon
[ 317.647338] wl1251: IRQ
[ 317.647460] wl1251: IRQ work
[ 317.647583] wl1251: intr: 0x8
[ 317.647644] wl1251: RX: FW +1
[ 317.647674] wl1251: RX counter: 8
[ 317.647674] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.647827] wl1251: rx skb 0xc6a2e480: 251 B beacon
[ 317.957336] wl1251: IRQ
[ 317.957427] wl1251: IRQ work
[ 317.957550] wl1251: intr: 0x1
[ 317.957611] wl1251: RX: FW +1
[ 317.957641] wl1251: RX counter: 9
[ 317.957641] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 317.957763] wl1251: rx skb 0xc6b8e300: 24 B
[ 321.817321] wl1251: IRQ
[ 321.817413] wl1251: IRQ work
[ 321.817565] wl1251: intr: 0x8
[ 321.817626] wl1251: RX: FW +1
[ 321.817626] wl1251: RX counter: 10
[ 321.817657] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 321.817749] wl1251: rx skb 0xc6b8e6c0: 24 B
[ 324.857330] wl1251: IRQ
[ 324.857421] wl1251: IRQ work
[ 324.857574] wl1251: intr: 0x1
[ 324.857604] wl1251: RX: FW +1
[ 324.857635] wl1251: RX counter: 11
[ 324.857635] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 324.857757] wl1251: rx skb 0xc69eb540: 24 B
[ 325.837463] wl1251: mac80211 config ch 1 psm off power 20
[ 325.837493] wl1251: mac80211 config ch 6 psm off power 20
[ 325.837524] wl1251: acx frame rates
[ 325.837524] wl1251: cmd configure
[ 325.857513] wl1251: cmd join ch 6 100/1
[ 325.897399] wlan0: authenticate with 00:09:5b:3b:ea:f0 (try 1)
[ 325.897735] wl1251: tx id 0 skb 0xc6afc840 payload 30 rate 0x1 queue
3
[ 325.907348] wl1251: IRQ
[ 325.908203] wl1251: IRQ work
[ 325.908386] wl1251: intr: 0xa
[ 325.908447] wl1251: RX: FW +2
[ 325.908477] wl1251: RX counter: 13
[ 325.908477] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 325.908599] wl1251: rx skb 0xc4026300: 30 B
[ 325.908721] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 325.908905] wl1251: rx skb 0xc40260c0: 61 B beacon
[ 325.908996] wl1251: WL1251_ACX_INTR_TX_RESULT
[ 325.909576] wl1251: tx status id 0 skb 0xc6afc840 failures 0 rate 0x1
status 0x0 ()
[ 325.909790] wl1251: RX: FW and host in sync
[ 325.909790] wl1251: RX counter: 13
[ 325.909820] wl1251: INTR is 0
[ 325.909881] wlan0: authenticated
[ 325.910095] wlan0: associate with 00:09:5b:3b:ea:f0 (try 1)
[ 325.912994] wl1251: tx id 0 skb 0xc4026300 payload 44 rate 0x1 queue
3
[ 325.917327] wl1251: IRQ
[ 325.919250] wl1251: IRQ work
[ 325.919433] wl1251: intr: 0xa
[ 325.919525] wl1251: RX: FW +1
[ 325.919525] wl1251: RX counter: 14
[ 325.919525] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 325.919647] wl1251: rx skb 0xc6ab8000: 36 B
[ 325.919769] wl1251: WL1251_ACX_INTR_TX_RESULT
[ 325.921508] wl1251: tx status id 0 skb 0xc4026300 failures 0 rate 0x1
status 0x0 ()
[ 325.921752] wlan0: RX AssocResp from 00:09:5b:3b:ea:f0 (capab=0x1
status=0 aid=114)
[ 325.921783] wlan0: associated
[ 325.922546] wl1251: mac80211 conf tx 0
[ 325.922576] wl1251: acx ac cfg 3 cw_ming 7 cw_max 15 aifs 2 txop 3264
[ 325.922576] wl1251: cmd configure
[ 325.937438] wl1251: acx tid cfg 3 type 1 tsid 3 ps_scheme 0
ack_policy 0
[ 325.937500] wl1251: cmd configure
[ 325.957489] wl1251: mac80211 conf tx 1
[ 325.957519] wl1251: acx ac cfg 2 cw_ming 15 cw_max 31 aifs 2 txop
6016
[ 325.957550] wl1251: cmd configure
[ 325.977478] wl1251: acx tid cfg 2 type 1 tsid 2 ps_scheme 0
ack_policy 0
[ 325.977508] wl1251: cmd configure
[ 325.997528] wl1251: mac80211 conf tx 2
[ 325.997558] wl1251: acx ac cfg 0 cw_ming 31 cw_max 1023 aifs 3 txop 0
[ 325.997589] wl1251: cmd configure
[ 326.017364] wl1251: IRQ
[ 326.017578] wl1251: acx tid cfg 0 type 1 tsid 0 ps_scheme 0
ack_policy 0
[ 326.017608] wl1251: cmd configure
[ 326.027313] wl1251: IRQ
[ 326.037322] wl1251: IRQ
[ 326.037536] wl1251: mac80211 conf tx 3
[ 326.037567] wl1251: acx ac cfg 1 cw_ming 31 cw_max 1023 aifs 7 txop 0
[ 326.037597] wl1251: cmd configure
[ 326.047393] wl1251: IRQ
[ 326.057342] wl1251: IRQ
[ 326.057556] wl1251: acx tid cfg 1 type 1 tsid 1 ps_scheme 0
ack_policy 0
[ 326.057586] wl1251: cmd configure
[ 326.067382] wl1251: IRQ
[ 326.077362] wl1251: IRQ
[ 326.077575] wl1251: mac80211 bss info changed
[ 326.077606] wl1251: mac80211 bss info changed
[ 326.077636] wl1251: cmd template 21
[ 326.087371] wl1251: IRQ
[ 326.097381] wl1251: IRQ
[ 326.097564] wl1251: cmd template 31
[ 326.098663] wl1251: acx frame rates
[ 326.098693] wl1251: cmd configure
[ 326.107330] wl1251: IRQ
[ 326.117340] wl1251: IRQ
[ 326.117553] wl1251: cmd join ch 6 100/1
[ 326.127319] wl1251: IRQ
[ 326.137329] wl1251: IRQ
[ 326.147369] wl1251: IRQ
[ 326.157318] wl1251: IRQ
[ 326.157409] wl1251: cmd template 30
[ 326.167327] wl1251: IRQ
[ 326.177337] wl1251: IRQ
[ 326.177520] wl1251: acx aid
[ 326.177551] wl1251: cmd configure
[ 326.187316] wl1251: IRQ
[ 326.197357] wl1251: IRQ
[ 326.197814] wl1251: IRQ work
[ 326.197937] wl1251: intr: 0x9
[ 326.197998] wl1251: RX: FW +2
[ 326.198028] wl1251: RX counter: 0
[ 326.198028] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 326.198242] wl1251: rx skb 0xc40260c0: 61 B beacon
[ 326.198364] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 326.198760] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 326.199981] wl1251: rx skb 0xc4026300: 61 B beacon
[ 326.200408] wl1251: tx id 0 skb 0xc6afccc0 payload 24 rate 0x1 queue
3
[ 326.200592] wl1251: mac80211 configure filter
[ 326.207366] wl1251: IRQ
[ 326.209320] wl1251: IRQ work
[ 326.209503] wl1251: intr: 0x2
[ 326.209564] wl1251: RX: FW and host in sync
[ 326.209594] wl1251: RX counter: 0
[ 326.209594] wl1251: WL1251_ACX_INTR_TX_RESULT
[ 326.210510] wl1251: tx status id 0 skb 0xc6afccc0 failures 0 rate 0x1
status 0x0 ()
[ 326.217590] wl1251: IRQ
[ 326.218841] wl1251: tx id 0 skb 0xc6ab8d80 payload 108 rate 0x1 queue
0
[ 326.218933] wl1251: IRQ work
[ 326.219024] wl1251: intr: 0x1
[ 326.219055] wl1251: RX: FW +1
[ 326.219085] wl1251: RX counter: 1
[ 326.219085] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 326.219299] wl1251: rx skb 0xc6ab8000: 61 B beacon
[ 326.227294] wl1251: IRQ
[ 326.227478] wl1251: IRQ work
[ 326.227630] wl1251: intr: 0x2
[ 326.227691] wl1251: RX: FW and host in sync
[ 326.227691] wl1251: RX counter: 1
[ 326.227722] wl1251: WL1251_ACX_INTR_TX_RESULT
[ 326.228912] wl1251: tx status id 0 skb 0xc6ab8d80 failures 0 rate 0x1
status 0x0 ()
[ 326.317413] wl1251: mac80211 config ch 6 psm on power 20
[ 326.317443] wl1251: psm enabled
[ 326.317443] wl1251: acx tbtt and dtim
[ 326.317474] wl1251: cmd configure
[ 326.327362] wl1251: IRQ
[ 326.337341] wl1251: IRQ
[ 326.337554] wl1251: entering psm
[ 326.337554] wl1251: acx beacon filter opt
[ 326.337585] wl1251: cmd configure
[ 326.347320] wl1251: IRQ
[ 326.357330] wl1251: IRQ
[ 326.357513] wl1251: acx wake up conditions
[ 326.357543] wl1251: cmd configure
[ 326.367340] wl1251: IRQ
[ 326.377349] wl1251: IRQ
[ 326.377563] wl1251: cmd set ps mode
[ 326.387329] wl1251: IRQ
[ 326.397369] wl1251: IRQ
[ 326.397583] wl1251: sleep auth psm/elp
[ 326.397613] wl1251: acx sleep auth
[ 326.397613] wl1251: cmd configure
[ 326.407379] wl1251: IRQ
[ 326.417327] wl1251: IRQ
[ 326.417541] wl1251: IRQ work
[ 326.417663] wl1251: intr: 0x8
[ 326.417724] wl1251: RX: FW +1
[ 326.417724] wl1251: RX counter: 2
[ 326.417755] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 326.417968] wl1251: rx skb 0xc69eb6c0: 61 B beacon
[ 326.427368] wl1251: IRQ
[ 326.428833] wl1251: elp work
[ 326.428863] wl1251: chip to elp
[ 326.428924] wl1251: IRQ work
[ 326.428924] wl1251: waking up chip from elp
[ 326.428985] wl1251: wakeup time: 0 ms
[ 326.429138] wl1251: intr: 0x1
[ 326.429168] wl1251: RX: FW +1
[ 326.429199] wl1251: RX counter: 3
[ 326.429199] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 326.429443] wl1251: rx skb 0xc6afc540: 61 B beacon
[ 326.438903] wl1251: elp work
[ 326.438934] wl1251: chip to elp
[ 326.522308] mmc0:0001: error -110 reading SDIO_CCCR_INTx
[ 327.027587] wl1251: mac80211 config ch 6 psm off power 20
[ 327.027618] wl1251: waking up chip from elp
[ 327.027679] mmc0: Command CRC error
[ 327.027709] wl1251: ERROR sdio_writeb failed (-84)
[ 327.147369] wl1251: ERROR elp wakeup timeout
[ 327.147460] wl1251: mac80211 config ch 6 psm on power 20
[ 327.147491] wl1251: waking up chip from elp
[ 327.267333] wl1251: ERROR elp wakeup timeout
[ 327.267364] wl1251: waking up chip from elp
[ 327.347381] wl1251: wakeup time: 80 ms
[ 327.347625] wl1251: tx id 0 skb 0xc4026540 payload 96 rate 0x1 queue
0
[ 327.347717] wl1251: mac80211 config ch 6 psm off power 20
[ 327.347717] wl1251: psm disabled
[ 327.347747] wl1251: leaving psm
[ 327.347747] wl1251: sleep auth cam
[ 327.347778] wl1251: acx sleep auth
[ 327.347778] wl1251: cmd configure
[ 327.367462] wl1251: acx beacon filter opt
[ 327.367492] wl1251: cmd configure
[ 327.387451] wl1251: acx wake up conditions
[ 327.387512] wl1251: cmd configure
[ 327.407470] wl1251: cmd set ps mode
[ 327.407714] wl1251: mac80211 config ch 6 psm on power 20
[ 327.407745] wl1251: psm enabled
[ 327.407745] wl1251: acx tbtt and dtim
[ 327.407775] wl1251: cmd configure
[ 327.427459] wl1251: entering psm
[ 327.427490] wl1251: acx beacon filter opt
[ 327.427490] wl1251: cmd configure
[ 327.447479] wl1251: acx wake up conditions
[ 327.447540] wl1251: cmd configure
[ 327.467498] wl1251: cmd set ps mode
[ 327.487487] wl1251: sleep auth psm/elp
[ 327.487518] wl1251: acx sleep auth
[ 327.487548] wl1251: cmd configure
[ 327.507446] wl1251: elp work
[ 327.507476] wl1251: chip to elp
[ 327.507537] wl1251: waking up chip from elp
[ 327.507598] wl1251: wakeup time: 0 ms
[ 327.509338] wl1251: tx id 1 skb 0xc40263c0 payload 108 rate 0x1 queue
0
[ 327.518310] wl1251: elp work
[ 327.518341] wl1251: chip to elp
[ 327.527343] wl1251: IRQ
[ 327.528289] wl1251: IRQ work
[ 327.528320] wl1251: waking up chip from elp
[ 327.528411] wl1251: wakeup time: 0 ms
[ 327.528533] wl1251: intr: 0x2
[ 327.528594] wl1251: RX: FW and host in sync
[ 327.528625] wl1251: RX counter: 3
[ 327.528625] wl1251: WL1251_ACX_INTR_TX_RESULT
[ 327.530090] wl1251: tx status id 0 skb 0xc4026540 failures 0 rate 0x1
status 0x0 ()
[ 327.530151] wl1251: tx status id 1 skb 0xc40263c0 failures 0 rate 0x1
status 0x0 ()
[ 327.538848] wl1251: elp work
[ 327.538879] wl1251: chip to elp
[ 327.612335] mmc0:0001: error -110 reading SDIO_CCCR_INTx
[ 328.027679] wl1251: mac80211 config ch 6 psm off power 20
[ 328.027709] wl1251: waking up chip from elp
[ 328.027770] mmc0: Command CRC error
[ 328.027801] wl1251: ERROR sdio_writeb failed (-84)
[ 328.147369] wl1251: ERROR elp wakeup timeout
[ 328.147460] wl1251: mac80211 config ch 6 psm on power 20
[ 328.147460] wl1251: waking up chip from elp
[ 328.267364] wl1251: ERROR elp wakeup timeout
[ 328.267395] wl1251: waking up chip from elp
[ 328.387298] wl1251: ERROR elp wakeup timeout
[ 328.622344] mmc0:0001: error -110 reading SDIO_CCCR_INTx
[ 329.627349] mmc0: Command CRC error
[ 329.627410] mmc0:0001: error -84 reading SDIO_CCCR_INTx
[ 330.637390] wl1251: IRQ
[ 330.637481] wl1251: IRQ work
[ 330.637512] wl1251: waking up chip from elp
[ 330.637573] wl1251: wakeup time: 0 ms
[ 330.637725] wl1251: intr: 0x29
[ 330.637756] wl1251: RX: FW +2
[ 330.637786] wl1251: RX counter: 5
[ 330.637786] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 330.637939] wl1251: rx skb 0xc6b8e3c0: 299 B
[ 330.638031] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 330.638153] wl1251: rx skb 0xc6b8e3c0: 274 B
[ 330.638244] wl1251: WL1251_ACX_INTR_EVENT (0x29)
[ 330.638244] wl1251: EVENT on mbox 1
[ 330.638305] wl1251: MBOX DUMP:
[ 330.638336] wl1251: vector: 0x20
[ 330.638336] wl1251: mask: 0xe73f7f57
[ 330.638336] wl1251: vector: 0x20
[ 330.821960] wl1251: RX: FW +1
[ 330.822021] wl1251: RX counter: 6
[ 330.822021] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 330.822204] wl1251: rx skb 0xc6afc180: 403 B
[ 330.828277] wl1251: elp work
[ 330.828338] wl1251: chip to elp
[ 330.842346] mmc0:0001: error -110 reading SDIO_CCCR_INTx
[ 331.847412] mmc0: Command CRC error
[ 331.847473] mmc0:0001: error -84 reading SDIO_CCCR_INTx
[ 332.027648] wl1251: mac80211 config ch 6 psm off power 20
[ 332.027679] wl1251: waking up chip from elp
[ 332.147399] wl1251: ERROR elp wakeup timeout
[ 332.147491] wl1251: mac80211 config ch 6 psm on power 20
[ 332.147491] wl1251: waking up chip from elp
[ 332.267395] wl1251: ERROR elp wakeup timeout
[ 332.267425] wl1251: waking up chip from elp
[ 332.387451] wl1251: ERROR elp wakeup timeout
[ 332.862396] mmc0:0001: error -110 reading SDIO_CCCR_INTx
[ 333.867401] mmc0: Command CRC error
[ 333.867492] mmc0:0001: error -84 reading SDIO_CCCR_INTx
[ 334.877380] wl1251: IRQ
[ 334.877471] wl1251: IRQ work
[ 334.877502] wl1251: waking up chip from elp
[ 334.877563] wl1251: wakeup time: 0 ms
[ 334.877716] wl1251: intr: 0x9
[ 334.877777] wl1251: RX: FW +2
[ 334.877777] wl1251: RX counter: 8
[ 334.877807] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 334.877960] wl1251: rx skb 0xc4026780: 418 B
[ 334.878051] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 334.878173] wl1251: rx skb 0xc4026780: 84 B
[ 334.878295] wl1251: RX: FW +2
[ 334.878295] wl1251: RX counter: 10
[ 334.878326] wl1251: WL1251_ACX_INTR_RX0_DATA
[ 334.878417] wl1251: rx skb 0xc4026780: 187 B
[ 334.878509] wl1251: WL1251_ACX_INTR_RX1_DATA
[ 336.878479] mmc0: Data timeout
[ 336.880310] wl1251: ERROR sdio read failed (-110)
[ 336.880462] wl1251: IRQ
[ 336.880493] wl1251: WARNING curr ID:1, last ID inc:2
[ 337.027191] wlan0: no IPv6 routers present
Then it is blocked.
Ifconfig wlan0 down is blocked for instance.
should I trace the problem with the kernel "detect soft lockup" and
"detect hang task" detection?
I did iwlist wlan0 scan | grep ESSID
iwconfig wlan0 essid EssidName
Note that I recently rebased against a more recent 2.6.32 android
kernel.
so at first I tought that it was blocking very early because of that(it
didn't some time ago,it blocked after 30 min or something like that)
but I tried the old kernel with the recent compat-wireless.
So it may be the compat-wireless version which causes the very rapid
block
Denis.
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: drago01 @ 2010-07-25 21:25 UTC (permalink / raw)
To: Guy, Wey-Yi W; +Cc: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <E9954878DD1FB34FAE5187FB88C58A350120C54D7D@orsmsx506.amr.corp.intel.com>
On Sat, Jul 24, 2010 at 6:34 AM, Guy, Wey-Yi W <wey-yi.w.guy@intel.com> wrote:
>
> Great, thank you very much for testing it. I will prepare the patch for upstream.
OK, thanks please don't forgot about stable as it seems that both .33
and .34 are affected too.
> Btw, I also have patch to help the other problem you encounter.
OK, thanks I'll test it once it shows up.
^ permalink raw reply
* Compat-wireless release for 2010-07-25 is baked
From: Compat-wireless cronjob account @ 2010-07-25 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
493730 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5764 - backport from compat module
7211 - total backport code
1.4605 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2467 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100723
compat-wireless release: compat-wireless-2010-07-13-4-g04898a5
^ permalink raw reply
* [PATCH 2.6.35] iwlagn: Improve aggregation failure error messages
From: Andy Lutomirski @ 2010-07-25 17:14 UTC (permalink / raw)
To: Wey-Yi Guy, ilw, linux-wireless, linville; +Cc: Andy Lutomirski
82ca9341763107615a15da6e59b9535d49eb91c3 added scary looking
but harmless error messages. Make them clearer and make the
actual failure message show up with the same severity as the
harmless one.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
---
This is probably 2.6.35 material. There is no functional regression
here, but 2.6.34 worked pretty well and 2.6.35 *looks* like it's not
working if you read the logs.
There is no functional change in this patch.
Thanks,
Andy
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index cf4a95b..f38ee24 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -300,8 +300,9 @@ static int rs_tl_turn_on_agg_for_tid(struct iwl_priv *priv,
struct ieee80211_sta *sta)
{
int ret = -EAGAIN;
+ u32 load = rs_tl_get_load(lq_data, tid);
- if (rs_tl_get_load(lq_data, tid) > IWL_AGG_LOAD_THRESHOLD) {
+ if (load > IWL_AGG_LOAD_THRESHOLD) {
IWL_DEBUG_HT(priv, "Starting Tx agg: STA: %pM tid: %d\n",
sta->addr, tid);
ret = ieee80211_start_tx_ba_session(sta, tid);
@@ -311,13 +312,15 @@ static int rs_tl_turn_on_agg_for_tid(struct iwl_priv *priv,
* this might be cause by reloading firmware
* stop the tx ba session here
*/
- IWL_DEBUG_HT(priv, "Fail start Tx agg on tid: %d\n",
+ IWL_ERR(priv, "Fail start Tx agg on tid: %d\n",
tid);
ieee80211_stop_tx_ba_session(sta, tid,
WLAN_BACK_INITIATOR);
}
- } else
- IWL_ERR(priv, "Fail finding valid aggregation tid: %d\n", tid);
+ } else {
+ IWL_ERR(priv, "Aggregation not enabled for tid %d "
+ "because load = %u\n", tid, load);
+ }
return ret;
}
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
From: Ohad Ben-Cohen @ 2010-07-25 14:05 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Roger Quadros, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Tony Lindgren, Pandita Vikram, Kalle Valo
In-Reply-To: <alpine.LFD.2.00.1007250953400.25246@xanadu.home>
On Sun, Jul 25, 2010 at 4:56 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Sun, 25 Jul 2010, Ohad Ben-Cohen wrote:
>
>> On Thu, Jul 22, 2010 at 2:35 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
>> > On 07/21/2010 08:33 PM, ext Ohad Ben-Cohen wrote:
>> >>
>> >> Add support for an SDIO device to stay powered off even without
>> >> the presence of an SDIO function driver. A host should explicitly
>> >> ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO
>> >> function driver should know it needs to call sdio_claim_power
>> >> before accessing the device.
>> >>
>> >> Signed-off-by: Ohad Ben-Cohen<ohad@wizery.com>
>> >
>> > Shouldn't this be the default behaviour? If there is no function driver for
>> > any of the functions of the card, then sdio core shold power off the card.
>> >
>> > I don't see a need for a special capability flag for this.
>> >
>> > in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability
>>
>> Totally agree.
>>
>> I didn't want to change the current behavior of the cards/funcs so I
>> looked for a way to explicitly power down only specific cards.
>>
>> Alternatively we could power down all cards at the end
>> mmc_attach_sdio, and then power them up selectively in sdio_bus_probe,
>> just before calling probe. If the probe succeeds, the function driver
>> takes over. If the probe fails, we can power them down again.
>
> Exactly!
Ok, v3 is on the way :)
(featuring no special host CAP, fix locking issues, and power down
unclaimed cards also on resume)
^ permalink raw reply
* Re: [PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
From: Nicolas Pitre @ 2010-07-25 13:56 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Roger Quadros, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Tony Lindgren, Pandita Vikram, Kalle Valo
In-Reply-To: <AANLkTimfJnC7onDT83DWLb7sR7+evJB3eymt5Z6JYkAt@mail.gmail.com>
On Sun, 25 Jul 2010, Ohad Ben-Cohen wrote:
> On Thu, Jul 22, 2010 at 2:35 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
> > On 07/21/2010 08:33 PM, ext Ohad Ben-Cohen wrote:
> >>
> >> Add support for an SDIO device to stay powered off even without
> >> the presence of an SDIO function driver. A host should explicitly
> >> ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO
> >> function driver should know it needs to call sdio_claim_power
> >> before accessing the device.
> >>
> >> Signed-off-by: Ohad Ben-Cohen<ohad@wizery.com>
> >
> > Shouldn't this be the default behaviour? If there is no function driver for
> > any of the functions of the card, then sdio core shold power off the card.
> >
> > I don't see a need for a special capability flag for this.
> >
> > in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability
>
> Totally agree.
>
> I didn't want to change the current behavior of the cards/funcs so I
> looked for a way to explicitly power down only specific cards.
>
> Alternatively we could power down all cards at the end
> mmc_attach_sdio, and then power them up selectively in sdio_bus_probe,
> just before calling probe. If the probe succeeds, the function driver
> takes over. If the probe fails, we can power them down again.
Exactly!
> Is that what you meant ?
>
> This would work both if the sdio function driver is already loaded, or
> will only be loaded at a later time. But I'm not too fond of the extra
> power on/off cycles that it will introduce for each card..
This is still way better than introducing knowledge about specific cards
in the host drivers.
Nicolas
^ 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