* Re: kmemleak reports on wireless-testing master-2009-09-04 + kmemleak tree
From: Luis R. Rodriguez @ 2009-09-04 22:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-wireless
In-Reply-To: <1252103579.21380.10.camel@pc1117.cambridge.arm.com>
On Fri, Sep 4, 2009 at 3:32 PM, Catalin Marinas<catalin.marinas@arm.com> wrote:
> On Fri, 2009-09-04 at 15:15 -0700, Luis R. Rodriguez wrote:
>> I get these with today's wireless-testing + pulling Catalin's kmemleak
>> tree. I nothing upon bootup, and then after a while I force a scan and
>> get (besides some other acpi stuff):
>>
>> unreferenced object 0xffff880039c7d700 (size 256):
>> comm "events/1", pid 10, jiffies 4295050369
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<ffffffff814e9d55>] kmemleak_alloc+0x25/0x60
>> [<ffffffff81118a83>] kmem_cache_alloc_node+0x193/0x200
>> [<ffffffff8141dc6a>] __alloc_skb+0x4a/0x180
>> [<ffffffff814ddb82>] wireless_send_event+0x1f2/0x410
>> [<ffffffffa01b7084>] ___cfg80211_scan_done+0xe4/0x110 [cfg80211]
>> [<ffffffffa01b70d6>] __cfg80211_scan_done+0x26/0x50 [cfg80211]
>> [<ffffffff8106de80>] worker_thread+0x1d0/0x380
>> [<ffffffff81073266>] kthread+0xa6/0xb0
>> [<ffffffff810130ca>] child_rip+0xa/0x20
>> [<ffffffffffffffff>] 0xffffffffffffffff
>
> If you force a few scans, do we still get the same objects reported as
> leaks?
Just tried it, and yes.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: clear cfg80211_inform_bss() from kmemleak reports
From: Luis R. Rodriguez @ 2009-09-04 22:48 UTC (permalink / raw)
To: Catalin Marinas
Cc: John W. Linville, Johannes Berg, Luis Rodriguez,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <1252103067.21380.1.camel@pc1117.cambridge.arm.com>
On Fri, Sep 4, 2009 at 3:24 PM, Catalin Marinas<catalin.marinas@arm.com> wrote:
> On Fri, 2009-09-04 at 14:58 -0700, Luis R. Rodriguez wrote:
>> On Fri, Sep 4, 2009 at 2:21 PM, Luis R. Rodriguez<lrodriguez@atheros.com> wrote:
>>
>> > BTW I should not I got this kmemleak report after using the clear
>> > command by painting objects black. I'll test it now with your
>> > suggested changes.
>>
>> So I pulled your git://linux-arm.org/linux-2.6 master into my tree and
>> didn't even need a 'clear' command now, the output of
>> /sys/kernel/debug/kmemleak is empty :), so I suspect you have quite a
>> few changes which should help avoid getting false positives.
>>
>> Will these changes make it for 2.6.32?
>
> The kmemleak branch is planned for the upcoming merging window.
Ah great.
> I don't
> think you need to merge the master branch as it has a lot of
> arm-specific code.
That was a goof, thanks, I'll rebase onto your kmemleak branch.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: clear cfg80211_inform_bss() from kmemleak reports
From: Luis R. Rodriguez @ 2009-09-05 0:03 UTC (permalink / raw)
To: Catalin Marinas
Cc: John W. Linville, Johannes Berg, Luis Rodriguez,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <43e72e890909041548i553d63b6k1602eeb52920c4ec@mail.gmail.com>
On Fri, Sep 4, 2009 at 3:48 PM, Luis R. Rodriguez<lrodriguez@atheros.com> wrote:
> On Fri, Sep 4, 2009 at 3:24 PM, Catalin Marinas<catalin.marinas@arm.com> wrote:
>> On Fri, 2009-09-04 at 14:58 -0700, Luis R. Rodriguez wrote:
>>> On Fri, Sep 4, 2009 at 2:21 PM, Luis R. Rodriguez<lrodriguez@atheros.com> wrote:
>>>
>>> > BTW I should not I got this kmemleak report after using the clear
>>> > command by painting objects black. I'll test it now with your
>>> > suggested changes.
>>>
>>> So I pulled your git://linux-arm.org/linux-2.6 master into my tree and
>>> didn't even need a 'clear' command now, the output of
>>> /sys/kernel/debug/kmemleak is empty :), so I suspect you have quite a
>>> few changes which should help avoid getting false positives.
>>>
>>> Will these changes make it for 2.6.32?
>>
>> The kmemleak branch is planned for the upcoming merging window.
>
> Ah great.
>
>> I don't
>> think you need to merge the master branch as it has a lot of
>> arm-specific code.
>
> That was a goof, thanks, I'll rebase onto your kmemleak branch.
I rebased and I still get these, even if I scan every now and then,
they stay up there.
On wireless_send_event() I can follow the allocated skb put onto the
skb queue wext_nlevents, and then schedule work is supposed to process
it on wireless_nlevent_process(). From there I am able to follow the
skb onto netlink_unicast() (for unicast data) but I do not see where
this ends up being freed. The compskb is set onto the
skb_shinfo(skb)->frag_list and not sure if netlink_unicast() ever
frees that.
Luis
^ permalink raw reply
* [patch 35/71] iwl3945: fix rfkill switch
From: Greg KH @ 2009-09-05 0:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Stanislaw Gruszka, Zhu Yi,
Reinette Chatre, linux-wireless, John W. Linville
In-Reply-To: <20090905001824.GA18171@kroah.com>
2.6.30-stable review patch. If anyone has any objections, please let us know.
------------------
From: Stanislaw Gruszka <sgruszka@redhat.com>
(Not needed upstream, due to the major rewrite in 2.6.31)
Due to rfkill and iwlwifi mishmash of SW / HW killswitch representation,
we have race conditions which make unable turn wifi radio on, after enable
and disable again killswitch. I can observe this problem on my laptop
with iwl3945 device.
In rfkill core HW switch and SW switch are separate 'states'. Device can
be only in one of 3 states: RFKILL_STATE_SOFT_BLOCKED, RFKILL_STATE_UNBLOCKED,
RFKILL_STATE_HARD_BLOCKED. Whereas in iwlwifi driver we have separate bits
STATUS_RF_KILL_HW and STATUS_RF_KILL_SW for HW and SW switches - radio can be
turned on, only if both bits are cleared.
In this particular race conditions, radio can not be turned on if in driver
STATUS_RF_KILL_SW bit is set, and rfkill core is in state
RFKILL_STATE_HARD_BLOCKED, because rfkill core is unable to call
rfkill->toggle_radio(). This situation can be entered in case:
- killswitch is turned on
- rfkill core 'see' button change first and move to RFKILL_STATE_SOFT_BLOCKED
also call ->toggle_radio() and STATE_RF_KILL_SW in driver is set
- iwl3945 get info about button from hardware to set STATUS_RF_KILL_HW bit and
force rfkill to move to RFKILL_STATE_HARD_BLOCKED
- killsiwtch is turend off
- driver clear STATUS_RF_KILL_HW
- rfkill core is unable to clear STATUS_RF_KILL_SW in driver
Additionally call to rfkill_epo() when STATUS_RF_KILL_HW in driver is set
cause move to the same situation.
In 2.6.31 this problem is fixed due to _total_ rewrite of rfkill subsystem.
This is a quite small fix for 2.6.30.x in iwlwifi driver. We are changing
internal rfkill state to always have below relations true:
STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=1 <-> RFKILL_STATUS_SOFT_BLOCKED
STATUS_RF_KILL_HW=0 STATUS_RF_KILL_SW=1 <-> RFKILL_STATUS_SOFT_BLOCKED
STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=0 <-> RFKILL_STATUS_HARD_BLOCKED
STATUS_RF_KILL_HW=0 STATUS_RF_KILL_SW=0 <-> RFKILL_STATUS_UNBLOCKED
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Acked-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-rfkill.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
--- a/drivers/net/wireless/iwlwifi/iwl-rfkill.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rfkill.c
@@ -53,22 +53,31 @@ static int iwl_rfkill_soft_rf_kill(void
switch (state) {
case RFKILL_STATE_UNBLOCKED:
if (iwl_is_rfkill_hw(priv)) {
+ /* pass error to rfkill core, make it state HARD
+ * BLOCKED (rfkill->mutex taken) and disable
+ * software kill switch */
err = -EBUSY;
- goto out_unlock;
+ priv->rfkill->state = RFKILL_STATE_HARD_BLOCKED;
}
iwl_radio_kill_sw_enable_radio(priv);
break;
case RFKILL_STATE_SOFT_BLOCKED:
iwl_radio_kill_sw_disable_radio(priv);
+ /* rfkill->mutex is taken */
+ if (priv->rfkill->state == RFKILL_STATE_HARD_BLOCKED) {
+ /* force rfkill core state to be SOFT BLOCKED,
+ * otherwise core will be unable to disable software
+ * kill switch */
+ priv->rfkill->state = RFKILL_STATE_SOFT_BLOCKED;
+ }
break;
default:
IWL_WARN(priv, "we received unexpected RFKILL state %d\n",
state);
break;
}
-out_unlock:
- mutex_unlock(&priv->mutex);
+ mutex_unlock(&priv->mutex);
return err;
}
@@ -132,14 +141,11 @@ void iwl_rfkill_set_hw_state(struct iwl_
if (!priv->rfkill)
return;
- if (iwl_is_rfkill_hw(priv)) {
+ if (iwl_is_rfkill_sw(priv))
+ rfkill_force_state(priv->rfkill, RFKILL_STATE_SOFT_BLOCKED);
+ else if (iwl_is_rfkill_hw(priv))
rfkill_force_state(priv->rfkill, RFKILL_STATE_HARD_BLOCKED);
- return;
- }
-
- if (!iwl_is_rfkill_sw(priv))
- rfkill_force_state(priv->rfkill, RFKILL_STATE_UNBLOCKED);
else
- rfkill_force_state(priv->rfkill, RFKILL_STATE_SOFT_BLOCKED);
+ rfkill_force_state(priv->rfkill, RFKILL_STATE_UNBLOCKED);
}
EXPORT_SYMBOL(iwl_rfkill_set_hw_state);
^ permalink raw reply
* Re: driver_nl80211 broken again
From: Maxim Levitsky @ 2009-09-05 2:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1251147515.20161.3.camel@johannes.local>
On Mon, 2009-08-24 at 22:58 +0200, Johannes Berg wrote:
> On Mon, 2009-08-24 at 23:06 +0300, Maxim Levitsky wrote:
>
> > This is typical output of iwconfig, after failure
> > (and I know that this output means trouble):
>
> Hmm, thanks for the info and especially the log. Unfortunately, I can't
> reproduce this at all.
>
> Can you run wpa_supplicant with timing info (add -t to the command line)
> and at the same time run "iw event -t" please?
>
> johannes
I have finally got to the bottom of this, ad it doesn't look good.
There are two bugs that overlap:
1 - when connecting again to the access point (same or another),
wpa_supplicant does the following:
deassoc
auth
assoc
So it assumes that deassoc command disconnects completely, but it not
longer true.
Yet, I have tried to make its dissassoc function do both, but it failed.
I used following patch:
diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index c68dd82..50afeeb 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -1278,8 +1278,10 @@ void wpa_supplicant_disassociate(struct wpa_supplicant *wpa_s,
if (!is_zero_ether_addr(wpa_s->bssid)) {
if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_USER_SPACE_MLME)
ieee80211_sta_disassociate(wpa_s, reason_code);
- else
+ else {
wpa_drv_disassociate(wpa_s, wpa_s->bssid, reason_code);
+ wpa_drv_deauthenticate(wpa_s, wpa_s->bssid, reason_code);
+ }
addr = wpa_s->bssid;
}
wpa_clear_keys(wpa_s, addr);
I got this.
EAPOL: startWhen --> 0
EAPOL: disable timer tick
wpa_driver_nl80211_disassociate
wpa_driver_nl80211_deauthenticate
nl80211: MLME command failed: ret=-67 (Link has been severed)
However, this "hack", did the trick:
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 97a278a..60c4355 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2561,7 +2561,7 @@ int ieee80211_mgd_disassoc(struct ieee80211_sub_if_data *sdata,
return -ENOLINK;
}
- ieee80211_set_disassoc(sdata, false);
+ ieee80211_set_disassoc(sdata, true);
mutex_unlock(&ifmgd->mtx);
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 79d2eec..fec34a7 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -222,7 +222,7 @@ static void __cfg80211_send_disassoc(struct net_device *dev,
for (i = 0; i < MAX_AUTH_BSSES; i++) {
if (wdev->authtry_bsses[i] || wdev->auth_bsses[i])
continue;
- wdev->auth_bsses[i] = wdev->current_bss;
+ /*wdev->auth_bsses[i] = wdev->current_bss;*/
wdev->current_bss = NULL;
done = true;
cfg80211_sme_disassoc(dev, i);
With this ugly hack, everything works just fine.
-----------------------------------------------------------------------------------------------
2 - independent of the above, the ieee80211_set_disassoc
doesn't work right if deauth==false.
If it is, then a work item is added to station work thread, and it is
never removed:
} else {
struct ieee80211_mgd_work *wk = ifmgd->old_associate_work;
wk->state = IEEE80211_MGD_STATE_IDLE;
list_add(&wk->list, &ifmgd->work_list);
}
iee80211_sta_work just ignores the IEEE80211_MGD_STATE_IDLE, thus it
work item remains forever.
This breaks scanning, since __ieee80211_start_scan will refuses to run
until, ifmgd->work_list is empty.
Best regards,
Maxim Levitsky
^ permalink raw reply related
* [PATCH] ssb: Fail ssb modinit, if attach of the buses failed.
From: Michael Buesch @ 2009-09-05 9:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
SSB modinit should not succeed, if busattach failed.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
drivers/ssb/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- wireless-testing.orig/drivers/ssb/main.c
+++ wireless-testing/drivers/ssb/main.c
@@ -1358,8 +1358,10 @@ static int __init ssb_modinit(void)
ssb_buses_lock();
err = ssb_attach_queued_buses();
ssb_buses_unlock();
- if (err)
+ if (err) {
bus_unregister(&ssb_bustype);
+ goto out;
+ }
err = b43_pci_ssb_bridge_init();
if (err) {
@@ -1375,7 +1377,7 @@ static int __init ssb_modinit(void)
/* don't fail SSB init because of this */
err = 0;
}
-
+out:
return err;
}
/* ssb must be initialized after PCI but before the ssb drivers.
--
Greetings, Michael.
^ permalink raw reply
* Re: kmemleak reports on wireless-testing master-2009-09-04 + kmemleak tree
From: Johannes Berg @ 2009-09-05 9:27 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Catalin Marinas
In-Reply-To: <43e72e890909041515s38e7c502kf552a5cf90e99d94@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
On Fri, 2009-09-04 at 15:15 -0700, Luis R. Rodriguez wrote:
> I get these with today's wireless-testing + pulling Catalin's kmemleak
> tree. I nothing upon bootup, and then after a while I force a scan and
> get (besides some other acpi stuff):
>
> unreferenced object 0xffff880039c7d700 (size 256):
> comm "events/1", pid 10, jiffies 4295050369
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<ffffffff814e9d55>] kmemleak_alloc+0x25/0x60
> [<ffffffff81118a83>] kmem_cache_alloc_node+0x193/0x200
> [<ffffffff8141dc6a>] __alloc_skb+0x4a/0x180
> [<ffffffff814ddb82>] wireless_send_event+0x1f2/0x410
Do you have CONFIG_COMPAT? And if you do, can you figure out whether
this is "skb" or "compskb"?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Atheros Linux wireless drivers home page - and two new driver projects
From: Jon Fairbairn @ 2009-09-05 10:03 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1252080405.24673.11.camel@mj>
Pavel Roskin <proski@gnu.org> writes:
> I have fixed http://wireless.kernel.org/en/users/Drivers/ath5k
Jolly good; I've been using it for a while, though it occasionally
fails. Did my message about ath5k + hostapd occasionally sulks get
through?
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* compat-wireless-2009-09-05: error: implicit declaration of function ?kmemleak_ignore?
From: Sedat Dilek @ 2009-09-05 10:55 UTC (permalink / raw)
To: mcgrof; +Cc: linux-wireless
Hi Luis,
todays compat-wireless (2009-09-05) is broken.
Error looks like this:
[...]
CC [M] /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/mac80211/rc80211_minstrel.o
LD [M] /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/mac80211/mac80211.o
LD /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/rfkill/built-in.o
LD /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/built-in.o
CC [M] /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/core.o
CC [M] /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/sysfs.o
CC [M] /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/radiotap.o
CC [M] /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/util.o
CC [M] /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/reg.o
CC [M] /home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/scan.o
/home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/scan.c:
In function ‘cfg80211_inform_bss’:
/home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/scan.c:503:
error: implicit declaration of function ‘kmemleak_ignore’
make[5]: *** [/home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless/scan.o]
Error 1
make[4]: *** [/home/sd/src/compat-wireless/compat-wireless-2009-09-05/net/wireless]
Error 2
make[3]: *** [_module_/home/sd/src/compat-wireless/compat-wireless-2009-09-05]
Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-rc8-radeonkms-686'
This fixed the issue here:
----- SNIP -----
--- net/wireless/scan.c.orig 2009-09-05 06:57:36.000000000 +0200
+++ net/wireless/scan.c 2009-09-05 12:38:09.644616605 +0200
@@ -15,6 +15,7 @@
#include "core.h"
#include "nl80211.h"
#include "wext-compat.h"
+#include <linux/kmemleak.h>
#define IEEE80211_SCAN_RESULT_EXPIRE (15 * HZ)
----- SNAP -----
Kind Regards,
Sedat
^ permalink raw reply
* compat-wireless compilation error on 2.6.29 kernel
From: Riccardo Gori @ 2009-09-05 10:45 UTC (permalink / raw)
To: linux-wireless
Hello, I'm trying to compile compat-wireless-2009-09-05 and it gives me the following error:
$ ./scripts/driver-select ath5k
$ make
...snip...
CC [M] /home/riccardo/Download/compat-wireless-2009-09-05/net/wireless/scan.o
/home/riccardo/Download/compat-wireless-2009-09-05/net/wireless/scan.c: In function ‘cfg80211_inform_bss’:
/home/riccardo/Download/compat-wireless-2009-09-05/net/wireless/scan.c:503: error: implicit declaration of function ‘kmemleak_ignore’
make[3]: *** [/home/riccardo/Download/compat-wireless-2009-09-05/net/wireless/scan.o] Error 1
make[2]: *** [/home/riccardo/Download/compat-wireless-2009-09-05/net/wireless] Error 2
make[1]: *** [_module_/home/riccardo/Download/compat-wireless-2009-09-05] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.29.6-217.2.16.fc11.i586'
make: *** [modules] Error 2
I'm using the 2.6.29 fedora 11 kernel.
Commenting out line 503:
kmemleak_ignore(res);
solve the compilation problem
Thanks,
Riccardo
^ permalink raw reply
* otus: conformance test limits implementation for MKK and ETSI
From: Joerg Albert @ 2009-09-05 12:23 UTC (permalink / raw)
To: Luis R. Rodriguez, Christian Lamparter
Cc: linux-wireless@vger.kernel.org,
otus-devel@lists.madwifi-project.org
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hi,
I've read [1] about the ctl groups, looked into otus' hal/hpmain.c (lines 3700 ff.)
and dumped the ctl index and data in the eeprom of my WNDA3100
It seems like the otus driver skips ctl (and heavy clip) application for the groups CTL_MKK and
CTL_ETSI. On the other hand I've found ctl data for these groups in the eeprom (see attachment).
Is this intended behaviour or a bug in the otus driver?
[1] http://linuxwireless.org/en/users/Drivers/ath
[-- Attachment #2: ar9170_ctl_dump_eeprom.txt --]
[-- Type: text/plain, Size: 5632 bytes --]
WNDA3100
========
ar9170_calc_ctl: ctl_grp 0x10 freq 2412
ar9170_calc_ctl: eeprom ctl_index: 0x10
chain 0: 76(0x1a) 80(0x5a) 104(0x1e) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
chain 1: 76(0x1a) 80(0x5a) 104(0x1e) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
ar9170_calc_ctl: eeprom ctl_index: 0x16
chain 0: 76(0x19) 80(0x5a) 104(0x1e) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
chain 1: 76(0x19) 80(0x5a) 104(0x1e) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
ar9170_calc_ctl: eeprom ctl_index: 0x18
chain 0: 78(0x18) 86(0x59) 102(0x1e) 142(0x62) 158(0x62) 178(0x22) 191(0x62) 199(0x62)
chain 1: 78(0x18) 86(0x59) 102(0x1e) 142(0x62) 158(0x62) 178(0x22) 191(0x62) 199(0x62)
ar9170_calc_ctl: eeprom ctl_index: 0x11
chain 0: 112(0x26) 117(0x66) 162(0x26) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x26) 117(0x66) 162(0x26) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x12
chain 0: 112(0x24) 117(0x64) 162(0x22) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x24) 117(0x64) 162(0x22) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x15
chain 0: 112(0x23) 117(0x64) 162(0x21) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x23) 117(0x64) 162(0x21) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x17
chain 0: 122(0x1d) 127(0x64) 147(0x64) 152(0x1b) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 122(0x1d) 127(0x64) 147(0x64) 152(0x1b) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x40
chain 0: 74(0x62) 80(0x62) 92(0x62) 104(0x62) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 74(0x62) 80(0x62) 92(0x62) 104(0x62) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x46
chain 0: 74(0x62) 80(0x62) 92(0x62) 104(0x62) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 74(0x62) 80(0x62) 92(0x62) 104(0x62) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x41
chain 0: 112(0x24) 117(0x64) 172(0x24) 184(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x24) 117(0x64) 172(0x24) 184(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x42
chain 0: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x45
chain 0: 112(0x22) 117(0x62) 152(0x22) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x22) 117(0x62) 152(0x22) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x30
chain 0: 76(0x22) 92(0x62) 104(0x22) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
chain 1: 76(0x22) 92(0x62) 104(0x22) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
ar9170_calc_ctl: eeprom ctl_index: 0x36
chain 0: 76(0x22) 80(0x62) 104(0x22) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
chain 1: 76(0x22) 80(0x62) 104(0x22) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
ar9170_calc_ctl: eeprom ctl_index: 0x38
chain 0: 78(0x22) 86(0x62) 102(0x22) 142(0x62) 158(0x62) 174(0x22) 0(0x00) 0(0x00)
chain 1: 78(0x22) 86(0x62) 102(0x22) 142(0x62) 158(0x62) 174(0x22) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x31
chain 0: 112(0x26) 117(0x66) 172(0x26) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x26) 117(0x66) 172(0x26) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x32
chain 0: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x35
chain 0: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x37
chain 0: 122(0x23) 127(0x63) 147(0x63) 152(0x23) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 122(0x23) 127(0x63) 147(0x63) 152(0x23) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x00
chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x00
chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x00
chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x00
chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_calc_ctl: eeprom ctl_index: 0x00
chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
ar9170_get_max_edge_power: freq 2412 max_edge_power 38
ar9170_get_max_edge_power: freq 2412 max_edge_power 36
ar9170_get_max_edge_power: freq 2412 max_edge_power 35
ar9170_calc_ctl: ctl_mode 5 pwr_cal[0] 24 -> 23
ar9170_get_max_edge_power: freq 2422 max_edge_power 29
ar9170_calc_ctl: ctl_mode 7 pwr_cal[0] 23 -> 1d
ar9170_calc_ctl: ctl_mode 7 pwr_cal[1] 22 -> 1d
ar9170_calc_ctl: ctl_mode 7 pwr_cal[2] 22 -> 1d
ar9170_calc_ctl: ctl_mode 7 pwr_cal[3] 22 -> 1d
ar9170_calc_ctl: ctl_mode 7 pwr_cal[4] 22 -> 1d
ar9170_calc_ctl: ctl_mode 7 pwr_cal[5] 22 -> 1d
ar9170_calc_ctl: ctl_mode 7 pwr_cal[6] 20 -> 1d
^ permalink raw reply
* Re: Atheros Linux wireless drivers home page - and two new driver projects
From: michael @ 2009-09-05 11:46 UTC (permalink / raw)
To: Xavier Bestel
Cc: Luis R. Rodriguez, Dan Williams, Stefan Lippers-Hollmann,
Len Widra, linux-wireless, linux-kernel, Stephen Chen,
Bob Copeland, Jouni Malinen, Harald Welte, Paul Fertser,
Michael Renzmann, Nick Kossifidis, b_yogesh_snowy, devel,
Werner Almesberger, Witold Sowa
In-Reply-To: <1252101647.11934.0.camel@bip>
Hi,
Xavier Bestel wrote:
> Le vendredi 04 septembre 2009 à 09:51 -0700, Luis R. Rodriguez a écrit :
>> On Fri, Sep 4, 2009 at 9:18 AM, Xavier Bestel<xavier.bestel@free.fr> wrote:
>>> On Fri, 2009-09-04 at 12:06 -0400, Pavel Roskin wrote:
>>>> On Fri, 2009-09-04 at 13:53 +0200, Xavier Bestel wrote:
>>>>> On Thu, 2009-09-03 at 15:54 -0700, Luis R. Rodriguez wrote:
>>>>>> I'm pleased to announce the new home page to Atheros Linux wireless drivers:
>>>>>>
>>>>>> http://wireless.kernel.org/en/users/Drivers/Atheros
>>>>> ath5k is marked as not master-mode capable. I thought this had been
>>>>> fixed for 2.6.31 ?
>>>> The above page makes no such statements. I have fixed
>>>> http://wireless.kernel.org/en/users/Drivers/ath5k
>>> Right, thanks.
>>>
>>>> https://madwifi-project.org/wiki/UserDocs/ath5kAccessPoint still needs a
>>>> lot of work, or maybe it should be removed as obsolete.
>>> Yes, I miss access-point functionality in NetworkManager :)
>> BTW a GSoC project this year was to add AP support to Network Manager.
>> As far I can tell the Witold Sowa finished this so you should be able
>> to test this.
>
> Awesome.
>
>> Witold, can you update the wiki page on this project with details as
>> to how people can test this?
>>
>> http://wireless.kernel.org/en/developers/GSoC/2009/Add_AP_Support_to_Network_Manager
>>
>> Luis
>>
Is there any plan to support the ar6k athereos wifi card?
Michael
>
>
>
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
>
^ permalink raw reply
* Re: driver_nl80211 broken again
From: Johannes Berg @ 2009-09-05 13:07 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless
In-Reply-To: <1252116503.2398.26.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
Hi Maxim,
Thanks for the analysis! I won't have time to look this weekend, and I'm
not sure I will early next week, and certainly not until the week after
then, but I'll leave your mail marked unread and will look later.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 1/2] ath,ar9170: move CTL_ defines into regd.h
From: Joerg Albert @ 2009-09-05 14:07 UTC (permalink / raw)
To: John W. Linville, Luis R. Rodriguez, Christian Lamparter
Cc: linux-wireless@vger.kernel.org
The ar9170 driver needs the defines for conformance test limit groups
and cannot include regd_common.h
Signed-off-by: Joerg Albert <jal2@gmx.de>
---
drivers/net/wireless/ath/regd.h | 6 ++++++
drivers/net/wireless/ath/regd_common.h | 6 ------
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 4d3c536..c1dd857 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -22,6 +22,12 @@
#include "ath.h"
+enum ctl_group {
+ CTL_FCC = 0x10,
+ CTL_MKK = 0x40,
+ CTL_ETSI = 0x30,
+};
+
#define NO_CTL 0xff
#define SD_NO_CTL 0xE0
#define NO_CTL 0xff
diff --git a/drivers/net/wireless/ath/regd_common.h b/drivers/net/wireless/ath/regd_common.h
index ad6d938..9847af7 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -154,12 +154,6 @@ enum EnumRd {
DEBUG_REG_DMN = 0x01ff,
};
-enum ctl_group {
- CTL_FCC = 0x10,
- CTL_MKK = 0x40,
- CTL_ETSI = 0x30,
-};
-
/* Regpair to CTL band mapping */
static struct reg_dmn_pair_mapping regDomainPairs[] = {
/* regpair, 5 GHz CTL, 2 GHz CTL */
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/2] ath,ar9170: implemented conformance test limit calc. for tx power
From: Joerg Albert @ 2009-09-05 14:07 UTC (permalink / raw)
To: John W. Linville, Christian Lamparter; +Cc: linux-wireless@vger.kernel.org
apply the conformance test limits (CTL) stored in the eeprom upon
the values calculated for the tx power (ar->power_*).
This is based on the implementation in the vendor driver
(hal/hpmain.c, line 3700 ff.) with one difference:
If any ctl mode isn't found in the eeprom, we fall back to the "lower",
legacy modes (5GHT20,11A or 2GHT20,11G,11B). Otus only did 5GHT20->11A.
Currently CTL are applied for the FCC group only.
Signed-off-by: Joerg Albert <jal2@gmx.de>
---
The above diff is due to my AVM Fritz! USB stick having no *HT* CTL groups
in the eeprom at all.
Furthermore I moved the "TODO: heavy clip ..." to an, IMHO, better place.
drivers/net/wireless/ath/ar9170/phy.c | 165 ++++++++++++++++++++++++++++++++-
1 files changed, 164 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
index 108ebfe..b3e5cf3 100644
--- a/drivers/net/wireless/ath/ar9170/phy.c
+++ b/drivers/net/wireless/ath/ar9170/phy.c
@@ -556,7 +556,6 @@ int ar9170_init_phy(struct ar9170 *ar, enum ieee80211_band band)
if (err)
return err;
- /* TODO: (heavy clip) regulatory domain power level fine-tuning. */
err = ar9170_init_phy_from_eeprom(ar, is_2ghz, is_40mhz);
if (err)
return err;
@@ -1238,6 +1237,164 @@ static int ar9170_set_freq_cal_data(struct ar9170 *ar,
return ar9170_regwrite_result();
}
+static u8 ar9170_get_max_edge_power(struct ar9170 *ar,
+ struct ar9170_calctl_edges edges[],
+ u32 freq)
+{
+/* TODO: move somewhere else */
+#define AR5416_MAX_RATE_POWER 63
+
+ int i;
+ u8 rc = AR5416_MAX_RATE_POWER;
+ u8 f;
+ if (freq < 3000)
+ f = freq - 2300;
+ else
+ f = (freq - 4800) / 5;
+
+ for (i = 0; i < AR5416_NUM_BAND_EDGES; i++) {
+ if (edges[i].channel == 0xff)
+ break;
+ if (f == edges[i].channel) {
+ /* exact freq match */
+ rc = edges[i].power_flags & ~AR9170_CALCTL_EDGE_FLAGS;
+ break;
+ }
+ if (i > 0 && f < edges[i].channel) {
+ if (f > edges[i-1].channel &&
+ edges[i-1].power_flags & AR9170_CALCTL_EDGE_FLAGS) {
+ /* lower channel has the inband flag set */
+ rc = edges[i-1].power_flags &
+ ~AR9170_CALCTL_EDGE_FLAGS;
+ }
+ break;
+ }
+ }
+
+ if (i == AR5416_NUM_BAND_EDGES) {
+ if (f > edges[i-1].channel &&
+ edges[i-1].power_flags & AR9170_CALCTL_EDGE_FLAGS) {
+ /* lower channel has the inband flag set */
+ rc = edges[i-1].power_flags &
+ ~AR9170_CALCTL_EDGE_FLAGS;
+ }
+ }
+ return rc;
+}
+
+/* calculate the conformance test limits and apply them to ar->power*
+ * (derived from otus hal/hpmain.c, line 3706 ff.)
+ */
+static void ar9170_calc_ctl(struct ar9170 *ar, u32 freq, enum ar9170_bw bw)
+{
+ u8 ctl_grp; /* CTL group */
+ u8 ctl_idx; /* CTL index */
+ int i, j;
+ struct ctl_modes {
+ u8 ctl_mode;
+ u8 max_power;
+ u8 *pwr_cal_data;
+ int pwr_cal_len;
+ } *modes;
+
+ /* order is relevant in the mode_list_*: we fall back to the
+ * lower indices if any mode is missed in the EEPROM.
+ */
+ struct ctl_modes mode_list_2ghz[] = {
+ { CTL_11B, 0, ar->power_2G_cck, 4 },
+ { CTL_11G, 0, ar->power_2G_ofdm, 4 },
+ { CTL_2GHT20, 0, ar->power_2G_ht20, 8 },
+ { CTL_2GHT40, 0, ar->power_2G_ht40, 8 },
+ };
+ struct ctl_modes mode_list_5ghz[] = {
+ { CTL_11A, 0, ar->power_5G_leg, 4 },
+ { CTL_5GHT20, 0, ar->power_5G_ht20, 8 },
+ { CTL_5GHT40, 0, ar->power_5G_ht40, 8 },
+ };
+ int nr_modes;
+
+#define EDGES(c, n) (ar->eeprom.ctl_data[c].control_edges[n])
+
+ /* TODO: investigate the differences between OTUS'
+ * hpreg.c::zfHpGetRegulatoryDomain() and
+ * ath/regd.c::ath_regd_get_band_ctl() -
+ * e.g. for FCC3_WORLD the OTUS procedure
+ * always returns CTL_FCC, while the one in ath/ delivers
+ * CTL_ETSI for 2GHz and CTL_FCC for 5GHz.
+ */
+ ctl_grp = ath_regd_get_band_ctl(&ar->common.regulatory,
+ ar->hw->conf.channel->band);
+
+ /* ctl group not found - either invalid band (NO_CTL) or ww roaming */
+ if (ctl_grp == NO_CTL || ctl_grp == SD_NO_CTL)
+ ctl_grp = CTL_FCC;
+
+ if (ctl_grp != CTL_FCC)
+ /* skip CTL and heavy clip for CTL_MKK and CTL_ETSI */
+ return;
+
+ if (ar->hw->conf.channel->band == IEEE80211_BAND_2GHZ) {
+ modes = mode_list_2ghz;
+ nr_modes = ARRAY_SIZE(mode_list_2ghz);
+ } else {
+ modes = mode_list_5ghz;
+ nr_modes = ARRAY_SIZE(mode_list_5ghz);
+ }
+
+ for (i = 0; i < nr_modes; i++) {
+ u8 c = ctl_grp | modes[i].ctl_mode;
+ for (ctl_idx = 0; ctl_idx < AR5416_NUM_CTLS; ctl_idx++)
+ if (c == ar->eeprom.ctl_index[ctl_idx])
+ break;
+ if (ctl_idx < AR5416_NUM_CTLS) {
+ int f_off = 0;
+
+ /* adjust freq for 40MHz */
+ if (modes[i].ctl_mode == CTL_2GHT40 ||
+ modes[i].ctl_mode == CTL_5GHT40) {
+ if (bw == AR9170_BW_40_BELOW)
+ f_off = -10;
+ else
+ f_off = 10;
+ }
+
+ modes[i].max_power =
+ ar9170_get_max_edge_power(ar, EDGES(ctl_idx, 1),
+ freq+f_off);
+
+ /* TODO: check if the regulatory max. power is
+ * controlled by cfg80211 for DFS
+ * (hpmain applies it to max_power itself for DFS freq)
+ */
+
+ } else {
+ /* Workaround in otus driver, hpmain.c, line 3906:
+ * if no data for 5GHT20 are found, take the
+ * legacy 5G value.
+ * We extend this here to fallback from any other *HT or
+ * 11G, too.
+ */
+ int k = i;
+
+ modes[i].max_power = AR5416_MAX_RATE_POWER;
+ while (k-- > 0) {
+ if (modes[k].max_power !=
+ AR5416_MAX_RATE_POWER) {
+ modes[i].max_power = modes[k].max_power;
+ break;
+ }
+ }
+ }
+
+ /* apply max power to pwr_cal_data (ar->power_*) */
+ for (j = 0; j < modes[i].pwr_cal_len; j++) {
+ modes[i].pwr_cal_data[j] = min(modes[i].pwr_cal_data[j],
+ modes[i].max_power);
+ }
+ }
+#undef EDGES
+}
+
static int ar9170_set_power_cal(struct ar9170 *ar, u32 freq, enum ar9170_bw bw)
{
struct ar9170_calibration_target_power_legacy *ctpl;
@@ -1340,6 +1497,12 @@ static int ar9170_set_power_cal(struct ar9170 *ar, u32 freq, enum ar9170_bw bw)
ctph[idx + 1].power[n]);
}
+
+ /* calc. conformance test limits and apply to ar->power*[] */
+ ar9170_calc_ctl(ar, freq, bw);
+
+ /* TODO: (heavy clip) regulatory domain power level fine-tuning. */
+
/* set ACK/CTS TX power */
ar9170_regwrite_begin(ar);
--
1.6.0.4
^ permalink raw reply related
* at76c50x-usb Broken was: [PATCH] mac80211: allow configure_filter callback to sleep
From: Jason Andryuk @ 2009-09-05 14:11 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
On Mon, Aug 17, 2009 at 10:24 AM, Kalle Valo<kalle.valo@iki.fi> wrote:
> BTW, at76c50x-usb is broken currently. The change of providing bssid to
> the driver only after association broke it. I don't have time to fix it
> right now, but I try to find some time next week.
Do you know the commit that broke at76c50x-usb? Was it "mac80211:
unify config_interface and bss_info_changed" or something else?
Thanks,
Jason
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Theodore Tso @ 2009-09-05 14:28 UTC (permalink / raw)
To: Mel Gorman
Cc: Luis R. Rodriguez, Bartlomiej Zolnierkiewicz, Aneesh Kumar K.V,
Zhu Yi, Andrew Morton, Johannes Weiner, Pekka Enberg,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Mel Gorman, netdev@vger.kernel.org, linux-mm@kvack.org,
James Ketrenos, Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <20090903124913.GA26110@csn.ul.ie>
On Thu, Sep 03, 2009 at 01:49:14PM +0100, Mel Gorman wrote:
> >
> > This looks very similar to the kmemleak ext4 reports upon a mount. If
> > it is the same issue, which from the trace it seems it is, then this
> > is due to an extra kmalloc() allocation and this apparently will not
> > get fixed on 2.6.31 due to the closeness of the merge window and the
> > non-criticalness this issue has been deemed.
No, it's a different problem.
> I suspect the more pressing concern is why is this kmalloc() resulting in
> an order-5 allocation request? What size is the buffer being requested?
> Was that expected? What is the contents of /proc/slabinfo in case a buffer
> that should have required order-1 or order-2 is using a higher order for
> some reason.
It's allocating 68,000 bytes for the mb_history structure, which is
used for debugging purposes. That's why it's optional and we continue
if it's not allocated. We should fix it to use vmalloc() and I'm
inclined to turn it off by default since it's not worth the overhead,
and most ext4 users won't find it useful or interesting.
- Ted
^ permalink raw reply
* Re: [PATCH 0/5] b43: Prepare driver for sleeping busses
From: Larry Finger @ 2009-09-05 16:20 UTC (permalink / raw)
To: Michael Buesch
Cc: John Linville, Albert Herranz, linux-wireless, Broadcom Wireless
In-Reply-To: <200909042247.37655.mb@bu3sch.de>
Michael Buesch wrote:
> This patchset is the first series to remove atomic sections
> from the b43 driver to allow running b43 on a slow bus like
> SDIO that needs to sleep for register accesses.
I have installed this patch set and find no problems. It compiles
correctly after each step is installed, which ensures proper
bisection. The code appears to work correctly.
I also tested the stand-alone version of interrupt threading without
problems.
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
^ permalink raw reply
* Re: [PATCH 1/2] ath,ar9170: move CTL_ defines into regd.h
From: Luis R. Rodriguez @ 2009-09-05 19:33 UTC (permalink / raw)
To: Joerg Albert
Cc: John W. Linville, Christian Lamparter,
linux-wireless@vger.kernel.org
In-Reply-To: <4AA270AF.2010902@gmx.de>
On Sat, Sep 5, 2009 at 7:07 AM, Joerg Albert<jal2@gmx.de> wrote:
> The ar9170 driver needs the defines for conformance test limit groups
> and cannot include regd_common.h
>
> Signed-off-by: Joerg Albert <jal2@gmx.de>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Just please test compilation of ath5k and ath9k as well.
Luis
^ permalink raw reply
* Re: kmemleak reports on wireless-testing master-2009-09-04 + kmemleak tree
From: Luis R. Rodriguez @ 2009-09-05 19:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Catalin Marinas
In-Reply-To: <1252142821.1175.10.camel@johannes.local>
On Sat, Sep 5, 2009 at 2:27 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-09-04 at 15:15 -0700, Luis R. Rodriguez wrote:
>> I get these with today's wireless-testing + pulling Catalin's kmemleak
>> tree. I nothing upon bootup, and then after a while I force a scan and
>> get (besides some other acpi stuff):
>>
>> unreferenced object 0xffff880039c7d700 (size 256):
>> comm "events/1", pid 10, jiffies 4295050369
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<ffffffff814e9d55>] kmemleak_alloc+0x25/0x60
>> [<ffffffff81118a83>] kmem_cache_alloc_node+0x193/0x200
>> [<ffffffff8141dc6a>] __alloc_skb+0x4a/0x180
>> [<ffffffff814ddb82>] wireless_send_event+0x1f2/0x410
>
> Do you have CONFIG_COMPAT?
Indeed, CONFIG_COMPAT=y
> And if you do, can you figure out whether
> this is "skb" or "compskb"?
How would I do that?
Luis
^ permalink raw reply
* Re: otus: conformance test limits implementation for MKK and ETSI
From: Luis R. Rodriguez @ 2009-09-05 19:37 UTC (permalink / raw)
To: Joerg Albert
Cc: Christian Lamparter, linux-wireless@vger.kernel.org,
otus-devel@lists.madwifi-project.org, Stephen Chen
In-Reply-To: <4AA25846.70007@gmx.de>
On Sat, Sep 5, 2009 at 5:23 AM, Joerg Albert<jal2@gmx.de> wrote:
> Hi,
>
> I've read [1] about the ctl groups, looked into otus' hal/hpmain.c (lines 3700 ff.)
> and dumped the ctl index and data in the eeprom of my WNDA3100
>
> It seems like the otus driver skips ctl (and heavy clip) application for the groups CTL_MKK and
> CTL_ETSI. On the other hand I've found ctl data for these groups in the eeprom (see attachment).
> Is this intended behaviour or a bug in the otus driver?
Not too sure but most likely a mistake on the driver, the CTLs should
always be read and used.
Luis
>
> [1] http://linuxwireless.org/en/users/Drivers/ath
>
> WNDA3100
> ========
>
> ar9170_calc_ctl: ctl_grp 0x10 freq 2412
> ar9170_calc_ctl: eeprom ctl_index: 0x10
> chain 0: 76(0x1a) 80(0x5a) 104(0x1e) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
> chain 1: 76(0x1a) 80(0x5a) 104(0x1e) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
> ar9170_calc_ctl: eeprom ctl_index: 0x16
> chain 0: 76(0x19) 80(0x5a) 104(0x1e) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
> chain 1: 76(0x19) 80(0x5a) 104(0x1e) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
> ar9170_calc_ctl: eeprom ctl_index: 0x18
> chain 0: 78(0x18) 86(0x59) 102(0x1e) 142(0x62) 158(0x62) 178(0x22) 191(0x62) 199(0x62)
> chain 1: 78(0x18) 86(0x59) 102(0x1e) 142(0x62) 158(0x62) 178(0x22) 191(0x62) 199(0x62)
> ar9170_calc_ctl: eeprom ctl_index: 0x11
> chain 0: 112(0x26) 117(0x66) 162(0x26) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x26) 117(0x66) 162(0x26) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x12
> chain 0: 112(0x24) 117(0x64) 162(0x22) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x24) 117(0x64) 162(0x22) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x15
> chain 0: 112(0x23) 117(0x64) 162(0x21) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x23) 117(0x64) 162(0x21) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x17
> chain 0: 122(0x1d) 127(0x64) 147(0x64) 152(0x1b) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 122(0x1d) 127(0x64) 147(0x64) 152(0x1b) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x40
> chain 0: 74(0x62) 80(0x62) 92(0x62) 104(0x62) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 74(0x62) 80(0x62) 92(0x62) 104(0x62) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x46
> chain 0: 74(0x62) 80(0x62) 92(0x62) 104(0x62) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 74(0x62) 80(0x62) 92(0x62) 104(0x62) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x41
> chain 0: 112(0x24) 117(0x64) 172(0x24) 184(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x24) 117(0x64) 172(0x24) 184(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x42
> chain 0: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x45
> chain 0: 112(0x22) 117(0x62) 152(0x22) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x22) 117(0x62) 152(0x22) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x30
> chain 0: 76(0x22) 92(0x62) 104(0x22) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
> chain 1: 76(0x22) 92(0x62) 104(0x22) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
> ar9170_calc_ctl: eeprom ctl_index: 0x36
> chain 0: 76(0x22) 80(0x62) 104(0x22) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
> chain 1: 76(0x22) 80(0x62) 104(0x22) 140(0x62) 160(0x62) 180(0x62) 189(0x62) 205(0x22)
> ar9170_calc_ctl: eeprom ctl_index: 0x38
> chain 0: 78(0x22) 86(0x62) 102(0x22) 142(0x62) 158(0x62) 174(0x22) 0(0x00) 0(0x00)
> chain 1: 78(0x22) 86(0x62) 102(0x22) 142(0x62) 158(0x62) 174(0x22) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x31
> chain 0: 112(0x26) 117(0x66) 172(0x26) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x26) 117(0x66) 172(0x26) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x32
> chain 0: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x35
> chain 0: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 112(0x24) 117(0x64) 172(0x24) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x37
> chain 0: 122(0x23) 127(0x63) 147(0x63) 152(0x23) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 122(0x23) 127(0x63) 147(0x63) 152(0x23) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x00
> chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x00
> chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x00
> chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x00
> chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_calc_ctl: eeprom ctl_index: 0x00
> chain 0: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> chain 1: 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00) 0(0x00)
> ar9170_get_max_edge_power: freq 2412 max_edge_power 38
> ar9170_get_max_edge_power: freq 2412 max_edge_power 36
> ar9170_get_max_edge_power: freq 2412 max_edge_power 35
> ar9170_calc_ctl: ctl_mode 5 pwr_cal[0] 24 -> 23
> ar9170_get_max_edge_power: freq 2422 max_edge_power 29
> ar9170_calc_ctl: ctl_mode 7 pwr_cal[0] 23 -> 1d
> ar9170_calc_ctl: ctl_mode 7 pwr_cal[1] 22 -> 1d
> ar9170_calc_ctl: ctl_mode 7 pwr_cal[2] 22 -> 1d
> ar9170_calc_ctl: ctl_mode 7 pwr_cal[3] 22 -> 1d
> ar9170_calc_ctl: ctl_mode 7 pwr_cal[4] 22 -> 1d
> ar9170_calc_ctl: ctl_mode 7 pwr_cal[5] 22 -> 1d
> ar9170_calc_ctl: ctl_mode 7 pwr_cal[6] 20 -> 1d
>
>
^ permalink raw reply
* compat-wireless fixed
From: Luis R. Rodriguez @ 2009-09-05 19:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Riccardo Gori, Sedat Dilek
Haven't tried building it myself but I think it should be fixed now.
git-describe for wireless-testing.git says: v2.6.31-rc8-34797-g4910edb
This is a bleeding edge compat-wireless release based on: master-2009-09-04
This is compat-release: master-2009-09-04
Luis
^ permalink raw reply
* Re: [PATCH 1/2] ath,ar9170: move CTL_ defines into regd.h
From: Joerg Albert @ 2009-09-05 20:32 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Christian Lamparter,
linux-wireless@vger.kernel.org
In-Reply-To: <43e72e890909051233s3df12787oa1c59a8b9728c271@mail.gmail.com>
On 09/05/2009 09:33 PM, Luis R. Rodriguez wrote:
> On Sat, Sep 5, 2009 at 7:07 AM, Joerg Albert<jal2@gmx.de> wrote:
>> The ar9170 driver needs the defines for conformance test limit groups
>> and cannot include regd_common.h
>>
>> Signed-off-by: Joerg Albert <jal2@gmx.de>
>
> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
> Just please test compilation of ath5k and ath9k as well.
They compile fine.
Sometime we should IMHO unify the CTL_* defines in the driver below ath/.
Currently ath5k, ath9k and regd.h have separate definitions for the modes, e.g.
~/src/wireless.gits/wireless-testing/drivers/net/wireless/ath$ fgrep -r --include=*.h CTL_11A *
ath5k/eeprom.h: AR5K_CTL_11A = 0,
ath9k/eeprom.h:#define CTL_11A 0
ath9k/eeprom.h:#define CTL_11A_EXT (CTL_11A | EXT_ADDITIVE)
regd.h:#define CTL_11A 0
Regards,
Joerg.
^ permalink raw reply
* Re: [PATCH 1/2] ath,ar9170: move CTL_ defines into regd.h
From: Luis R. Rodriguez @ 2009-09-05 20:41 UTC (permalink / raw)
To: Joerg Albert
Cc: John W. Linville, Christian Lamparter,
linux-wireless@vger.kernel.org
In-Reply-To: <4AA2CAEC.3000908@gmx.de>
On Sat, Sep 5, 2009 at 1:32 PM, Joerg Albert<jal2@gmx.de> wrote:
> On 09/05/2009 09:33 PM, Luis R. Rodriguez wrote:
>> On Sat, Sep 5, 2009 at 7:07 AM, Joerg Albert<jal2@gmx.de> wrote:
>>> The ar9170 driver needs the defines for conformance test limit groups
>>> and cannot include regd_common.h
>>>
>>> Signed-off-by: Joerg Albert <jal2@gmx.de>
>>
>> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>>
>> Just please test compilation of ath5k and ath9k as well.
>
> They compile fine.
>
> Sometime we should IMHO unify the CTL_* defines in the driver below ath/.
> Currently ath5k, ath9k and regd.h have separate definitions for the modes, e.g.
>
> ~/src/wireless.gits/wireless-testing/drivers/net/wireless/ath$ fgrep -r --include=*.h CTL_11A *
> ath5k/eeprom.h: AR5K_CTL_11A = 0,
> ath9k/eeprom.h:#define CTL_11A 0
> ath9k/eeprom.h:#define CTL_11A_EXT (CTL_11A | EXT_ADDITIVE)
> regd.h:#define CTL_11A 0
right, that's the idea of ath.ko, to unify as much as we can, step by
step. If you see anything else to be shared just send a patch.
Luis
^ permalink raw reply
* iwlagn: order 2 page allocation failures
From: Frans Pop @ 2009-09-06 7:40 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, ipw3945-devel
Got a couple of page allocation failures today while viewing fairly
large images. System was struggling for a bit to reorganize memory
and swap, but nothing really serious. Everything recovered fairly
quickly.
Anything to look into?
System: HP 2510p; 2.6.31-rc7-56-g7c0a57d; Debian stable, KDE desktop
10:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 4965 AG or AGN
[Kedron] Network Connection [8086:4229] (rev 61)
Cheers,
FJP
kernel: swapper: page allocation failure. order:2, mode:0x4020
kernel: Pid: 0, comm: swapper Not tainted 2.6.31-rc7 #15
kernel: Call Trace:
kernel: <IRQ> [<ffffffff8107909a>] __alloc_pages_nodemask+0x542/0x58a
kernel: [<ffffffff811d8a29>] ? skb_queue_tail+0x41/0x4a
kernel: [<ffffffff812568c2>] ? _spin_unlock+0x9/0xb
kernel: [<ffffffff811da2e1>] ? __alloc_skb+0x3c/0x15b
kernel: [<ffffffffa0356644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore]
kernel: [<ffffffff8107913d>] __get_free_pages+0x12/0x41
kernel: [<ffffffff810982b1>] __kmalloc_track_caller+0x3b/0xec
kernel: [<ffffffff811da30b>] __alloc_skb+0x66/0x15b
kernel: [<ffffffffa0356644>] iwl_rx_allocate+0xac/0x208 [iwlcore]
kernel: [<ffffffffa03567b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
kernel: [<ffffffffa037d8e3>] iwl_rx_handle+0x356/0x39a [iwlagn]
kernel: [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod]
kernel: [<ffffffffa037de27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn]
kernel: [<ffffffff8103dff0>] tasklet_action+0x71/0xbc
kernel: [<ffffffff8103e877>] __do_softirq+0x9b/0x12c
kernel: [<ffffffff8100cb7c>] call_softirq+0x1c/0x28
kernel: [<ffffffff8100e694>] do_softirq+0x34/0x72
kernel: [<ffffffff8103e601>] irq_exit+0x3f/0x79
kernel: [<ffffffff8100dd95>] do_IRQ+0xa3/0xba
kernel: [<ffffffff8100c413>] ret_from_intr+0x0/0xa
kernel: <EOI> [<ffffffffa0262720>] ? acpi_idle_enter_simple+0x101/0x12f [processor]
kernel: [<ffffffffa0262716>] ? acpi_idle_enter_simple+0xf7/0x12f [processor]
kernel: [<ffffffff811cd6d8>] ? cpuidle_idle_call+0x8c/0xc4
kernel: [<ffffffff8100ae0f>] ? cpu_idle+0x52/0x93
kernel: [<ffffffff81245f4d>] ? rest_init+0x61/0x63
kernel: [<ffffffff81411c3f>] ? start_kernel+0x348/0x353
kernel: [<ffffffff8141129a>] ? x86_64_start_reservations+0xaa/0xae
kernel: [<ffffffff8141137f>] ? x86_64_start_kernel+0xe1/0xe8
kernel: Mem-Info:
kernel: DMA per-cpu:
kernel: CPU 0: hi: 0, btch: 1 usd: 0
kernel: CPU 1: hi: 0, btch: 1 usd: 0
kernel: DMA32 per-cpu:
kernel: CPU 0: hi: 186, btch: 31 usd: 172
kernel: CPU 1: hi: 186, btch: 31 usd: 86
kernel: Active_anon:314043 active_file:2401 inactive_anon:105396
kernel: inactive_file:2026 unevictable:407 dirty:0 writeback:3949 unstable:0
kernel: free:10313 slab:10486 mapped:2860 pagetables:4100 bounce:0
kernel: DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2828kB inactive_anon:3296kB
active_file:736kB inactive_file:664kB unevictable:0kB present:15336kB pages_scanned:0
all_unreclaimable? no
kernel: lowmem_reserve[]: 0 1976 1976 1976
kernel: DMA32 free:33328kB min:5664kB low:7080kB high:8496kB active_anon:1253344kB inactive_anon:418288kB
active_file:8868kB inactive_file:7440kB unevictable:1628kB present:2023748kB pages_scanned:0
all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: DMA: 913*4kB 36*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 7924kB
kernel: DMA32: 7198*4kB 501*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 33328kB
kernel: 63958 total pagecache pages
kernel: 59163 pages in swap cache
kernel: Swap cache stats: add 310806, delete 251643, find 16810381/16825997
kernel: Free swap = 1534944kB
kernel: Total swap = 2097144kB
kernel: 518064 pages RAM
kernel: 10324 pages reserved
kernel: 78783 pages shared
kernel: 442988 pages non-shared
kernel: iwlagn 0000:10:00.0: Can not allocate SKB buffers
kernel: swapper: page allocation failure. order:2, mode:0x4020
kernel: Pid: 0, comm: swapper Not tainted 2.6.31-rc7 #15
kernel: Call Trace:
kernel: <IRQ> [<ffffffff8107909a>] __alloc_pages_nodemask+0x542/0x58a
kernel: [<ffffffff812545d1>] ? printk+0x67/0x6e
kernel: [<ffffffffa0356644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore]
kernel: [<ffffffff8107913d>] __get_free_pages+0x12/0x41
kernel: [<ffffffff810982b1>] __kmalloc_track_caller+0x3b/0xec
kernel: [<ffffffff811da30b>] __alloc_skb+0x66/0x15b
kernel: [<ffffffffa0356644>] iwl_rx_allocate+0xac/0x208 [iwlcore]
kernel: [<ffffffffa03567b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
kernel: [<ffffffffa037d90e>] iwl_rx_handle+0x381/0x39a [iwlagn]
kernel: [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod]
kernel: [<ffffffffa037de27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn]
kernel: [<ffffffff8103dff0>] tasklet_action+0x71/0xbc
kernel: [<ffffffff8103e877>] __do_softirq+0x9b/0x12c
kernel: [<ffffffff8100cb7c>] call_softirq+0x1c/0x28
kernel: [<ffffffff8100e694>] do_softirq+0x34/0x72
kernel: [<ffffffff8103e601>] irq_exit+0x3f/0x79
kernel: [<ffffffff8100dd95>] do_IRQ+0xa3/0xba
kernel: [<ffffffff8100c413>] ret_from_intr+0x0/0xa
kernel: <EOI> [<ffffffffa0262720>] ? acpi_idle_enter_simple+0x101/0x12f [processor]
kernel: [<ffffffffa0262716>] ? acpi_idle_enter_simple+0xf7/0x12f [processor]
kernel: [<ffffffff811cd6d8>] ? cpuidle_idle_call+0x8c/0xc4
kernel: [<ffffffff8100ae0f>] ? cpu_idle+0x52/0x93
kernel: [<ffffffff81245f4d>] ? rest_init+0x61/0x63
kernel: [<ffffffff81411c3f>] ? start_kernel+0x348/0x353
kernel: [<ffffffff8141129a>] ? x86_64_start_reservations+0xaa/0xae
kernel: [<ffffffff8141137f>] ? x86_64_start_kernel+0xe1/0xe8
kernel: Mem-Info:
kernel: DMA per-cpu:
kernel: CPU 0: hi: 0, btch: 1 usd: 0
kernel: CPU 1: hi: 0, btch: 1 usd: 0
kernel: DMA32 per-cpu:
kernel: CPU 0: hi: 186, btch: 31 usd: 172
kernel: CPU 1: hi: 186, btch: 31 usd: 86
kernel: Active_anon:314043 active_file:2401 inactive_anon:105396
kernel: inactive_file:2026 unevictable:407 dirty:0 writeback:3949 unstable:0
kernel: free:10313 slab:10486 mapped:2860 pagetables:4100 bounce:0
kernel: DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2828kB inactive_anon:3296kB
active_file:736kB inactive_file:664kB unevictable:0kB present:15336kB pages_scanned:0
all_unreclaimable? no
kernel: lowmem_reserve[]: 0 1976 1976 1976
kernel: DMA32 free:33328kB min:5664kB low:7080kB high:8496kB active_anon:1253344kB inactive_anon:418288kB
active_file:8868kB inactive_file:7440kB unevictable:1628kB present:2023748kB pages_scanned:0
all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: DMA: 913*4kB 36*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 7924kB
kernel: DMA32: 7198*4kB 501*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 33328kB
kernel: 63958 total pagecache pages
kernel: 59163 pages in swap cache
kernel: Swap cache stats: add 310806, delete 251643, find 16810381/16825997
kernel: Free swap = 1534944kB
kernel: Total swap = 2097144kB
kernel: 518064 pages RAM
kernel: 10324 pages reserved
kernel: 78783 pages shared
kernel: 442988 pages non-shared
kernel: iwlagn 0000:10:00.0: Can not allocate SKB buffers
^ 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