* Re: [PATCH] mac80211: simplify key locking
From: Jouni Malinen @ 2010-07-24 5:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1275380359.3621.17.camel@jlt3.sipsolutions.net>
On Tue, Jun 01, 2010 at 10:19:19AM +0200, Johannes Berg wrote:
> net/mac80211/key.c
commit ad0e2b5a00dbec303e4682b403bb6703d11dcdb2
> void ieee80211_key_free(struct ieee80211_key *key)
> - if (!key->sdata) {
> - /* The key has not been linked yet, simply free it
> - * and don't Oops */
It looks like this function can still be called with key->sdata == NULL
in some cases and that does indeed result in an oops below:
> + local = key->sdata->local;
I've seen this issue pop up in FT testing and based on a quick code
review, at least ieee80211_add_key() calls ieee80211_key_free() in an
error case (sta not found) without having first called
ieee80211_key_link(). Which one is wrong - the caller or the freeing
function? Should we just restore the previous key->sdata == NULL handler
here?
I'd guess that the sta-not-found part is caused by FT trying to
configure PTK before association in the FT protocol roaming case
(wpa_supplicant tries to do this as soon as it knows the key because
that works with some drivers and is needed to avoid race condition with
encrypted frames; as a workaround, it will do this again after
association if the previous attempt failed).
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: ath9k - D-link DWA-552
From: Pavel Roskin @ 2010-07-24 6:28 UTC (permalink / raw)
To: Andy Pyles; +Cc: linux-wireless
In-Reply-To: <AANLkTimnFGidxLvnR+=WXykQyf4NNAJBkxuqZ3HWRdeh@mail.gmail.com>
On Fri, 2010-07-23 at 22:30 -0400, Andy Pyles wrote:
> Hi Pavel,
>
> Incidentally this is the output after adding that id to pci.c:
>
> [ 1211.423855] Backport based on linux-next.git next-20100720
> [ 1211.437076] cfg80211: World regulatory domain updated:
> [ 1211.437080] (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ 1211.437084] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 1211.437087] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 1211.437089] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 1211.437092] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 1211.437095] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 1211.447705] ath9k 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> [ 1211.447794] ath9k 0000:05:02.0: Failed to initialize device
> [ 1211.447830] ath9k 0000:05:02.0: PCI INT A disabled
> [ 1211.447859] ath9k: probe of 0000:05:02.0 failed with error -95
You may want to post it to ath9k-devel@lists.ath9k.org
It looks like a hardware problem. Either the device is broken, or it's
an experimental chip that is not supported by ath9k. There have been
patches removing support for cards that have never been sold (or were
not supposed to be sold). Maybe your card ended up with an experimental
chip by mistake.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] mac80211: Don't set per-BSS QoS for monitor interfaces
From: Johannes Berg @ 2010-07-24 7:35 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Sujith, linville, linux-wireless
In-Reply-To: <AANLkTim0Zv8E6Kc60W9m6krL-FOzXiJpeHTGgoR2DH9i@mail.gmail.com>
On Fri, 2010-07-23 at 10:29 -0700, Luis R. Rodriguez wrote:
> On Thu, Jul 22, 2010 at 11:01 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Fri, 2010-07-23 at 10:47 +0530, Sujith wrote:
> >> In AP mode, there is no need to notify the driver about QoS
> >> changes for the monitor interface that is created. The warning
> >> in ieee80211_bss_info_change_notify() would be hit otherwise.
> >
> > Makes sense.
> >
> > Acked-by: Johannes Berg <johannes@sipsolutions.net>
> >> Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
>
> Stable?
Err, no, the change that does this isn't going in until .36 I think.
johannes
^ permalink raw reply
* Re: Atheros 0cf3:b003
From: sergi @ 2010-07-24 8:04 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTimpwMyfcvRGnJ1JfZP+F=4nFNT5Ra3pB3vse1LM@mail.gmail.com>
Luis R. Rodriguez <mcgrof@...> writes:
>
> 2010/7/23 Maximi89 <maximi89@...>:
> > Hola Luis, conoces ese ID?, Atheros 0cf3:b003
> > Es efectivamente un AR9271?
>
> No, cual tarjeta es esa? Las que tenemos son estos:
>
> { },
> };
>
> Stephen, have you heard of 0cf3:b003 as an ar9271 or HB94 card?
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Hola Luis yo fui quien le mando la consulta a maximiliano,,mi lapiz usb es de
la casa Ubiquiti modelo wifistation ext y ahi dicen k tiene el atheros 9271..y
el id k me sale es el mencionado,,tanto en Mac,Linux y con Everest en win,uso
Ubuntu Ultimate 2.7 con kernel 2.6.32-24 y nada k no me funciona,Podria cmbiar
el Id para k sea compatible?? ..bueno muchas gracias por tu atencion
^ permalink raw reply
* Re: [PATCH] mac80211: simplify key locking
From: Johannes Berg @ 2010-07-24 9:06 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John Linville, linux-wireless
In-Reply-To: <20100724053301.GA6773@jm.kir.nu>
On Fri, 2010-07-23 at 22:33 -0700, Jouni Malinen wrote:
> On Tue, Jun 01, 2010 at 10:19:19AM +0200, Johannes Berg wrote:
>
> > net/mac80211/key.c
> commit ad0e2b5a00dbec303e4682b403bb6703d11dcdb2
>
> > void ieee80211_key_free(struct ieee80211_key *key)
>
> > - if (!key->sdata) {
> > - /* The key has not been linked yet, simply free it
> > - * and don't Oops */
>
> It looks like this function can still be called with key->sdata == NULL
> in some cases and that does indeed result in an oops below:
>
> > + local = key->sdata->local;
>
>
> I've seen this issue pop up in FT testing and based on a quick code
> review, at least ieee80211_add_key() calls ieee80211_key_free() in an
> error case (sta not found) without having first called
> ieee80211_key_link(). Which one is wrong - the caller or the freeing
> function? Should we just restore the previous key->sdata == NULL handler
> here?
I think it's just another stupid bug.
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?
johannes
^ permalink raw reply
* [PATCH] rt2x00: Fix regression for rt2500pci
From: Ivo van Doorn @ 2010-07-24 17:32 UTC (permalink / raw)
To: John W. Linville; +Cc: users, linux-wireless
Since commit:
commit f1aa4c541e98afa8b770a75ccaa8504d0bff44a7
Author: Ivo van Doorn <ivdoorn@gmail.com>
Date: Tue Jun 29 21:38:55 2010 +0200
rt2x00: Write the BSSID to register when interface is added
mananged mode in rt2500pci was broken, due to intf->bssid containing
random data rather then the expected 00:00:00:00:00:00
This is corrected by sending the BSSID to rt2x00lib_config_intf
only in AP mode where the bssid is set to a valid value.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2x00mac.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index 4d8d232..235e037 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -273,17 +273,24 @@ int rt2x00mac_add_interface(struct ieee80211_hw *hw,
mutex_init(&intf->beacon_skb_mutex);
intf->beacon = entry;
- if (vif->type == NL80211_IFTYPE_AP)
- memcpy(&intf->bssid, vif->addr, ETH_ALEN);
- memcpy(&intf->mac, vif->addr, ETH_ALEN);
-
/*
* The MAC adddress must be configured after the device
* has been initialized. Otherwise the device can reset
* the MAC registers.
+ * The BSSID address must only be configured in AP mode,
+ * however we should not send an empty BSSID address for
+ * STA interfaces at this time, since this can cause
+ * invalid behavior in the device.
*/
- rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
- intf->mac, intf->bssid);
+ memcpy(&intf->mac, vif->addr, ETH_ALEN);
+ if (vif->type == NL80211_IFTYPE_AP) {
+ memcpy(&intf->bssid, vif->addr, ETH_ALEN);
+ rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
+ intf->mac, intf->bssid);
+ } else {
+ rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
+ intf->mac, NULL);
+ }
/*
* Some filters depend on the current working mode. We can force
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: orphan the atmel wireless driver
From: Simon Kelley @ 2010-07-24 18:59 UTC (permalink / raw)
To: John W. Linville; +Cc: Dan Williams, linux-wireless
In-Reply-To: <20100723132847.GC6678@tuxdriver.com>
John W. Linville wrote:
> On Fri, Jul 23, 2010 at 10:07:35AM +0100, Simon Kelley wrote:
>> Dan Williams wrote:
>>> On Thu, 2010-07-22 at 14:31 -0400, John W. Linville wrote:
>>>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>> Aww, how sad :(. I'll take it since I still have some of this
>>> hardware. Not that I'll do much with it, but if the patches are simple
>>> I'm happy to test+ack them.
>>>
>> Thanks Dan, whilst I still have the hardware, I no longer have a
>> convenient PCMCIA slot into which to plug it.
>>
>> This hardware is well orphaned: it never made is past 802.11b, and there
>> have been no new models for a long time. Nevertheless, if the existing
>> code can be kept functional, that would be good.
>
> Is the existing code functional? The device I have seems to only
> half work -- I suppose I need to figure that out...
>
> John
I'm not aware of any problems. I'll try and test a new kernel when I can
find a PCMCIA-full laptop. If the problem turns out to be your hardware,
John, I can send you another card.
Cheers,
Simon.
^ permalink raw reply
* Compat-wireless release for 2010-07-24 is baked
From: Compat-wireless cronjob account @ 2010-07-24 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
* Re: Master mode in rtl8187
From: Hin-Tak Leung @ 2010-07-24 21:26 UTC (permalink / raw)
To: Larry Finger; +Cc: Ben Gamari, linux-wireless
In-Reply-To: <4C474851.4000809@lwfinger.net>
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
^ permalink raw reply
* Re: [PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
From: Ohad Ben-Cohen @ 2010-07-25 10:40 UTC (permalink / raw)
To: Mark Brown
Cc: Roger Quadros, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org, Kalle Valo,
Pandita Vikram, linux@arm.linux.org.uk, Nicolas Pitre,
Tony Lindgren, San Mehat, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20100723091503.GA12300@rakim.wolfsonmicro.main>
On Fri, Jul 23, 2010 at 12:15 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Jul 23, 2010 at 02:13:38AM +0300, Ohad Ben-Cohen wrote:
>> On Thu, Jul 22, 2010 at 2:16 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
>> > .dev_name = "mmci-omap-hs.2"
>
>> I already set the .dev member of the consumer in a similar manner to
>> how all other regulators are configured in this board - please check
>> out patch 13:
>
>> https://patchwork.kernel.org/patch/113418/
>
>> Does this look reasonable to you ?
>
> You should really be using dev_name in preference to dev these days
> unless there's a *very* good reason.
Changed, thank you.
I'll submit the updated patch now as a standalone patch as it has no
dependencies on the whole series, and it could only help to start
trimming that series down.
>
^ permalink raw reply
* [PATCH] omap: zoom: add fixed regulator device for wl1271
From: Ohad Ben-Cohen @ 2010-07-25 11:14 UTC (permalink / raw)
To: linux-omap
Cc: linux-wireless, linux-mmc, Mark Brown, linux-arm-kernel,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
San Mehat, Roger Quadros, Tony Lindgren, Nicolas Pitre,
Pandita Vikram, Kalle Valo, Ohad Ben-Cohen
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
This patch is a follow-up to a previous wl1271 discussion,
thus all original recipients are CC'ed.
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..de88635 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
#include <linux/gpio.h>
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -27,6 +28,8 @@
#include "mux.h"
#include "hsmmc.h"
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,11 @@ static struct regulator_consumer_supply zoom_vmmc2_supply = {
.supply = "vmmc",
};
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = "vmmc",
+ .dev_name = "mmci-omap-hs.2",
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +159,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies = &zoom_vsim_supply,
};
+static struct regulator_init_data zoom_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &zoom_vmmc3_supply,
+};
+
+static struct fixed_voltage_config zoom_vwlan = {
+ .supply_name = "vwl1271",
+ .microvolts = 1800000, /* 1.8V */
+ .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = &zoom_vmmc3,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &zoom_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = "external",
@@ -280,6 +314,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
+ platform_device_register(&omap_vwlan_device);
usb_musb_init(&musb_board_data);
enable_board_wakeup_source();
}
--
1.7.0.4
^ 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 12:40 UTC (permalink / raw)
To: Roger Quadros
Cc: 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, Nicolas Pitre, Pandita Vikram,
Kalle Valo
In-Reply-To: <4C482D01.1040109@nokia.com>
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.
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..
Thanks,
Ohad.
> flag, it seems more like a request from the board to keep the card powered
> off.
>
> regards,
> -roger
>
^ 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
* 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
* [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
* 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
* 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
* 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: [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
* 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: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: 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: 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: [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: 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
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