* rt2x00/rt73usb random memory corruption
From: Richard Zidlicky @ 2009-06-25 20:33 UTC (permalink / raw)
To: linux-wireless
Hi,
tried to pin down the occassional mysterious crashes. The crashes occur in several
different places, but almost allways the culprit is a "CR2: 00000000000d5a0b" which
in my configuration causes an illegal access.
As the kernel mostly survives the boot this gave me the opportunity to look at the
live kernel - interestingly a quick grep of /proc/kcore allways shows exactly one
instance of 000d5a0b. In all cases it looks it did overwrite something else that was
supposed to be at that place and just these 4 bytes were modified.
Looking at the addreses that were modified did not yield any interesting patterns
(like page/struct offsets) that would give me any hint. Seems like in the case I looked
at some module ELF information was overwritten, this was during boot so the address
to this location was quite likely found somewhere on the stack?
So far no luck to provoke a crash at the place where the memory corruption happens.
Any ideas? Given that the destination location is probably picked from the stack
- has anyone experience with trying various stack alignments in kernel code?
Here is 2 examples of memory blocks that get overwritten..
Case 1:
*
6621354520 6978652e 65742e74 00007478 00000000
6621354540 696e692e 65742e74 00007478 00000000
6621354560 646f722e 2e617461 31727473 0000312e
6621354600 736b5f5f 61746d79 70675f62 0000006c
6621354620 636b5f5f 61746372 70675f62 0000006c
6621354640 74636573 736e6f69 00000000 00000000
6621354660 f645bef0 f8178020 00000000 00000000
6621354700 f645b7c0 f8235020 00000000 00000000
6621354720 6978652e 65742e74 00007478 00000000
6621354740 f645bf40 f8178020 00000000 00000000
6621354760 f645bff0 f8178020 00000000 00000000
6621355000 f645b740 f8178020 00000000 00000000
6621355020 00000000 00002c0c 00000786 0006b651
6621355040 ** 000d5a0b ** 61726665 70695f67 00003476 ******
***6621355040 \v Z \r \0 e f r a g _ i p v 4 \0 \0 *******
6621355060 646f722e 2e617461 31727473 0000312e
6621355100 75625f5f 61745f67 00656c62 00000000
6621355120 74636573 736e6f69 00000000 00000000
6621355140 6978652e 65742e74 33007478 00627375
6621355160 696e692e 65742e74 00007478 00000000
6621355200 645f666e 61726665 70695f67 00003476
6621355220 61726170 6574656d 00007372 00000000
6621355240 f645bbd0 f645b180 f8db9bc8 00000000
same with od -c
6621354520 . e x i t . t e x t \0 \0 \0 \0 \0 \0
6621354540 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621354560 . r o d a t a . s t r 1 . 1 \0 \0
6621354600 _ _ k s y m t a b _ g p l \0 \0 \0
6621354620 _ _ k c r c t a b _ g p l \0 \0 \0
6621354640 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
6621354660 360 276 E 366 200 027 370 \0 \0 \0 \0 \0 \0 \0 \0
6621354700 300 267 E 366 P # 370 \0 \0 \0 \0 \0 \0 \0 \0
6621354720 . e x i t . t e x t \0 \0 \0 \0 \0 \0
6621354740 @ 277 E 366 200 027 370 \0 \0 \0 \0 \0 \0 \0 \0
6621354760 360 277 E 366 200 027 370 \0 \0 \0 \0 \0 \0 \0 \0
6621355000 @ 267 E 366 200 027 370 \0 \0 \0 \0 \0 \0 \0 \0
6621355020 \0 \0 \0 \0 \f , \0 \0 206 \a \0 \0 Q 266 006 \0
6621355040 \v Z \r \0 e f r a g _ i p v 4 \0 \0 *******
6621355060 . r o d a t a . s t r 1 . 1 \0 \0
6621355100 _ _ b u g _ t a b l e \0 \0 \0 \0 \0
6621355120 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
6621355140 . e x i t . t e x t \0 3 u s b \0
6621355160 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621355200 n f _ d e f r a g _ i p v 4 \0 \0
6621355220 p a r a m e t e r s \0 \0 \0 \0 \0 \0
6621355240 320 273 E 366 200 261 E 366 310 233 333 370 \0 \0 \0 \0
6621355260 270 207 327 370 270 207 327 370 310 233 333 370 \0 \0 \0 \0
Case 2:
6621133760 f64495f0 f6b08b00 f8f6fbc8 00000000
6621134000 f8ee67b8 f8ee67b8 f8f6fbc8 00000000
6621134020 f8b4d964 f6b08b20 f8f6fbc8 00000000
6621134040 61726170 6574656d 00007372 00000000
6621134060 6978652e 65742e74 33007478 00627375
6621134100 696e692e 65742e74 00007478 00000000
6621134120 646f722e 2e617461 31727473 0000312e
6621134140 f8fe672c f8fe672c f9070740 00000000
6621134160 74636573 736e6f69 00000000 00000000
6621134200 00000000 00002c0c 00000786 0006b651
6621134220 *** 000d5a0b 636f6c6c 78616d5f 00000000 ****
6621134240 f64497c0 f8fc7cb4 f9070740 00000000
6621134260 75625f5f 61745f67 00656c62 00000000
6621134300 6e757278 6265645f 00006775 00000000
6621134320 61657270 636f6c6c 00000000 00000000
6621134340 645f666e 61726665 70695f67 00003476
same with od -c
6621133760 360 225 D 366 \0 213 260 366 310 373 366 370 \0 \0 \0 \0
6621134000 270 g 356 370 270 g 356 370 310 373 366 370 \0 \0 \0 \0
6621134020 d 331 264 370 213 260 366 310 373 366 370 \0 \0 \0 \0
6621134040 p a r a m e t e r s \0 \0 \0 \0 \0 \0
6621134060 . e x i t . t e x t \0 3 u s b \0
6621134100 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621134120 . r o d a t a . s t r 1 . 1 \0 \0
6621134140 , g 376 370 , g 376 370 @ \a \a 371 \0 \0 \0 \0
6621134160 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
6621134200 \0 \0 \0 \0 \f , \0 \0 206 \a \0 \0 Q 266 006 \0
6621134220 \v Z \r \0 l l o c _ m a x \0 \0 \0 \0 ********
6621134240 300 227 D 366 264 | 374 370 @ \a \a 371 \0 \0 \0 \0
6621134260 _ _ b u g _ t a b l e \0 \0 \0 \0 \0
6621134300 x r u n _ d e b u g \0 \0 \0 \0 \0 \0
6621134320 p r e a l l o c \0 \0 \0 \0 \0 \0 \0 \0
6621134340 n f _ d e f r a g _ i p v 4 \0 \0
6621134360 270 322 304 302 354 322 304 302 340 304 302 T 340 304 302
6621134400 . e x i t . t e x t \0 \0 \0 \0 \0 \0
6621134420 p a r a m e t e r s \0 \0 \0 \0 \0 \0
6621134440 . e x i t . t e x t \0 \0 \0 \0 \0 \0
6621134460 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621134500 . s m p _ l o c k s \0 \0 \0 \0 \0 \0
6621134520 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
6621134540 _ _ k s y m t a b _ g p l \0 \0 \0
6621134560 s n d _ h d a _ i n t e l \0 \0 \0
6621134600 _ _ k c r c t a b _ g p l \0 \0 \0
6621134620 n f _ d e f r a g _ i p v 4 \0 \0
6621134640 _ _ k c r c t a b _ g p l \0 \0 \0
6621134660 _ _ k s y m t a b _ g p l \0 \0 \0
*
6621134720 \0 220 D 366 320 224 D 366 t 034 373 370 \0 \0 \0 \0
6621134740 310 O 021 370 310 O 021 370 020 O 264 370 \0 \0 \0 \0
6621134760 r t 2 x 0 0 l i b \0 \0 \0 \0 \0 \0 \0
6621135000 317 \t 367 354 322 005 370 020 O 264 370 \0 \0 \0 \0
6621135020 s n d _ h d a _ i n t e l \0 \0 \0
6621135040 030 367 200 370 020 226 D 366 020 O 264 370 \0 \0 \0 \0
6621135060 r t 2 x 0 0 l i b \0 \0 \0 \0 \0 \0 \0
6621135100 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621135120 . r o d a t a . s t r 1 . 1 \0 \0
6621135140 s n d _ h d a _ i n t e l \0 \0 \0
6621135160 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621135200 r t 2 x 0 0 l i b \0 \0 \0 \0 \0 \0 \0
*
6621135240 s n d _ h d a _ i n t e l \0 \0 \0
6621135260 T 240 375 370 220 224 D 366 t 034 373 370 \0 \0 \0 \0
6621135300 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
Richard
^ permalink raw reply
* Re: [RFC 00/11] cfg80211 connect API + wireless extension move
From: Dave @ 2009-06-25 20:37 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <43e72e890906241324n341f4988wc6e7325ee389e71e@mail.gmail.com>
Luis R. Rodriguez wrote:
> On Wed, Jun 24, 2009 at 5:07 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
>
>> Maybe we even decide to
>> not internalise it this way because orinoco wants to keep
>> some ioctls that we'll not offer in cfg80211, not sure yet.
Do we need to maintain these interfaces? I think allowing the same
functionality via other means should be acceptable (since any software
using these interfaces clearly doesn't work with any other hardware).
> Hm, which ones?
orinoco has the following private wext handlers:
reset firmware
reset card
get/set adhoc port
get/set short preamble
get/set ibss port
get rid
I've only ever had occasion to use the reset ioctls recently, when my
card started seriously misbehaving (I suspect it's about to fail).
debugfs or something?
The get/set things could be done as module parameters. Preferred values
will be model/fw specific - though I expect we have reasonable defaults
picked during initialisation.
Get RID reads settings off the card. Useful for debugging or reverse
engineering, but I hope no-one uses it for anything else. Remove completely?
Regarding patch 11 (the internalise one), would it be better to:
* continue to export cfg80211_wext_* for now
* set mac80211s dev->wireless_handler to &cfg80211_wext_handler in
iface.c (via a #define that's NULL if !CONFIG_WEXT)
* specify a release when we expect all drivers, or at least those
anyone cares about, to have converted?
That removes the WE dependency from mac80211 but allows drivers to
gradually implement cfg80211 support. I originally attempted doing it in
one hit - that sucked, but may have been due to not having a clear idea
of how cfg80211 is supposed to work.
It also means orinoco can keep its wext private functions for a bit longer.
Thanks,
Dave.
^ permalink raw reply
* [PATCH] mac80211: fix allocation in mesh_queue_preq
From: Andrey Yurovsky @ 2009-06-25 23:07 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Andrey Yurovsky
We allocate a PREQ queue node in mesh_queue_preq, however the allocation
may cause us to sleep. Use GFP_ATOMIC to prevent this.
[ 1869.126498] BUG: scheduling while atomic: ping/1859/0x10000100
[ 1869.127164] Modules linked in: ath5k mac80211 ath
[ 1869.128310] Pid: 1859, comm: ping Not tainted 2.6.30-wl #1
[ 1869.128754] Call Trace:
[ 1869.129293] [<c1023a2b>] __schedule_bug+0x48/0x4d
[ 1869.129866] [<c13b5533>] __schedule+0x77/0x67a
[ 1869.130544] [<c1026f2e>] ? release_console_sem+0x17d/0x185
[ 1869.131568] [<c807cf47>] ? mesh_queue_preq+0x2b/0x165 [mac80211]
[ 1869.132318] [<c13b5b3e>] schedule+0x8/0x1f
[ 1869.132807] [<c1023c12>] __cond_resched+0x16/0x2f
[ 1869.133478] [<c13b5bf0>] _cond_resched+0x27/0x32
[ 1869.134191] [<c108a370>] kmem_cache_alloc+0x1c/0xcf
[ 1869.134714] [<c10273ae>] ? printk+0x15/0x17
[ 1869.135670] [<c807cf47>] mesh_queue_preq+0x2b/0x165 [mac80211]
[ 1869.136731] [<c807d1f8>] mesh_nexthop_lookup+0xee/0x12d [mac80211]
[ 1869.138130] [<c807417e>] ieee80211_xmit+0xe6/0x2b2 [mac80211]
[ 1869.138935] [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k]
[ 1869.139831] [<c80c97bc>] ? ath5k_tasklet_rx+0xba/0x506 [ath5k]
[ 1869.140863] [<c8075191>] ieee80211_subif_start_xmit+0x6c9/0x6e4
[mac80211]
[ 1869.141665] [<c105cf1c>] ? handle_level_irq+0x78/0x9d
[ 1869.142390] [<c12e3f93>] dev_hard_start_xmit+0x168/0x1c7
[ 1869.143092] [<c12f1f17>] __qdisc_run+0xe1/0x1b7
[ 1869.143612] [<c12e25ff>] qdisc_run+0x18/0x1a
[ 1869.144248] [<c12e62f4>] dev_queue_xmit+0x16a/0x25a
[ 1869.144785] [<c13b6dcc>] ? _read_unlock_bh+0xe/0x10
[ 1869.145465] [<c12eacdb>] neigh_resolve_output+0x19c/0x1c7
[ 1869.146182] [<c130e2da>] ? ip_finish_output+0x0/0x51
[ 1869.146697] [<c130e2a0>] ip_finish_output2+0x182/0x1bc
[ 1869.147358] [<c130e327>] ip_finish_output+0x4d/0x51
[ 1869.147863] [<c130e9d5>] ip_output+0x80/0x85
[ 1869.148515] [<c130cc49>] dst_output+0x9/0xb
[ 1869.149141] [<c130dec6>] ip_local_out+0x17/0x1a
[ 1869.149632] [<c130e0bc>] ip_push_pending_frames+0x1f3/0x255
[ 1869.150343] [<c13247ff>] raw_sendmsg+0x5e6/0x667
[ 1869.150883] [<c1033c55>] ? insert_work+0x6a/0x73
[ 1869.151834] [<c8071e00>] ?
ieee80211_invoke_rx_handlers+0x17da/0x1ae8 [mac80211]
[ 1869.152630] [<c132bd68>] inet_sendmsg+0x3b/0x48
[ 1869.153232] [<c12d7deb>] __sock_sendmsg+0x45/0x4e
[ 1869.153740] [<c12d8537>] sock_sendmsg+0xb8/0xce
[ 1869.154519] [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k]
[ 1869.155289] [<c1036b25>] ? autoremove_wake_function+0x0/0x30
[ 1869.155859] [<c115992b>] ? __copy_from_user_ll+0x11/0xce
[ 1869.156573] [<c1159d99>] ? copy_from_user+0x31/0x54
[ 1869.157235] [<c12df646>] ? verify_iovec+0x40/0x6e
[ 1869.157778] [<c12d869a>] sys_sendmsg+0x14d/0x1a5
[ 1869.158714] [<c8072c40>] ? __ieee80211_rx+0x49e/0x4ee [mac80211]
[ 1869.159641] [<c80c83fe>] ? ath5k_rxbuf_setup+0x6d/0x8d [ath5k]
[ 1869.160543] [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k]
[ 1869.161434] [<c80beba4>] ? ath5k_hw_get_rxdp+0xe/0x10 [ath5k]
[ 1869.162319] [<c80c97bc>] ? ath5k_tasklet_rx+0xba/0x506 [ath5k]
[ 1869.163063] [<c1005627>] ? enable_8259A_irq+0x40/0x43
[ 1869.163594] [<c101edb8>] ? __dequeue_entity+0x23/0x27
[ 1869.164793] [<c100187a>] ? __switch_to+0x2b/0x105
[ 1869.165442] [<c1021d5f>] ? finish_task_switch+0x5b/0x74
[ 1869.166129] [<c12d963a>] sys_socketcall+0x14b/0x17b
[ 1869.166612] [<c1002b95>] syscall_call+0x7/0xb
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
---
net/mac80211/mesh_hwmp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 003cb47..f49ef28 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -637,7 +637,7 @@ static void mesh_queue_preq(struct mesh_path *mpath, u8 flags)
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
struct mesh_preq_queue *preq_node;
- preq_node = kmalloc(sizeof(struct mesh_preq_queue), GFP_KERNEL);
+ preq_node = kmalloc(sizeof(struct mesh_preq_queue), GFP_ATOMIC);
if (!preq_node) {
printk(KERN_DEBUG "Mesh HWMP: could not allocate PREQ node\n");
return;
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 0/3] wireless extensions improvements
From: David Miller @ 2009-06-25 23:18 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20090624113447.441667549@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 24 Jun 2009 13:34:47 +0200
> This series contains three improvements to wireless
> extensions:
> 1) make them network namespace aware, as discussed
> previously
> 2) optimise the event sending code and fix a small
> heap information leak
> 3) do some generic work and make it possible to send
> compat netlink events, and make wext do this
>
> Because the third patch depends on the first two (it
> could be made not to, if you wish) but touches generic
> networking stuff, I'd like to have all of these included
> in net-next instead of John's wireless tree, all the
> other wireless work can be done independently of these.
These changes look fine to me, so I'll likely put them into
net-next-2.6 as soon as I open that up.
FWIW, I bet we could make read() easily work properly to for the
compat stuff, and it would be nice to shore up that one minor hole.
^ permalink raw reply
* [PATCH] zd1211rw: adding SONY IFU-WLM2 (054c:0257) as a zd1211b device
From: Hin-Tak Leung @ 2009-06-26 4:28 UTC (permalink / raw)
To: linux-wireless, linville; +Cc: Hin-Tak Leung, Hin-Tak Leung
Yevgen Kotikov reported success on the sourceforge zd1211-devs list
with the following details:
Brand/retail: SONY IFU-WLM2
USB-IDs: Vendor: 0x054C Device: 0x0257
chip ID: zd1211b chip 054c:0257 v4802 high 00-0b-6b AL2230_RF pa0 -----
FCC ID: unknown
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Tested-by: Yevgen Kotikov <yevgen.kotikov@gmail.com>
---
drivers/net/wireless/zd1211rw/zd_usb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index 2c24dd9..722b20c 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -66,6 +66,7 @@ static struct usb_device_id usb_ids[] = {
{ USB_DEVICE(0x0471, 0x1236), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0471, 0x1237), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x050d, 0x705c), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x054c, 0x0257), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0586, 0x340a), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0586, 0x340f), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0586, 0x3410), .driver_info = DEVICE_ZD1211B },
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 0/3] wireless extensions improvements
From: John W. Linville @ 2009-06-26 5:46 UTC (permalink / raw)
To: David Miller; +Cc: johannes, netdev, linux-wireless
In-Reply-To: <20090625.161817.112930127.davem@davemloft.net>
On Thu, Jun 25, 2009 at 04:18:17PM -0700, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Wed, 24 Jun 2009 13:34:47 +0200
>
> > This series contains three improvements to wireless
> > extensions:
> > 1) make them network namespace aware, as discussed
> > previously
> > 2) optimise the event sending code and fix a small
> > heap information leak
> > 3) do some generic work and make it possible to send
> > compat netlink events, and make wext do this
> >
> > Because the third patch depends on the first two (it
> > could be made not to, if you wish) but touches generic
> > networking stuff, I'd like to have all of these included
> > in net-next instead of John's wireless tree, all the
> > other wireless work can be done independently of these.
>
> These changes look fine to me, so I'll likely put them into
> net-next-2.6 as soon as I open that up.
ACK
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [2.6.31-rc1] iwlagn (4965): no wireless due to RFKILL problem
From: Frans Pop @ 2009-06-26 11:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Netdev, linux-kernel
I've tried .31-rc1 on my HP 2510p notebook and the only problem I found
was that wireless no longer works. The cause looks to be related to
RFKILL.
Initially when I booted all I got in dmesg was:
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: EU
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5490000 KHz - 5710000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: EU
iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27kd
iwlagn: Copyright(c) 2003-2009 Intel Corporation
iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:10:00.0: setting latency timer to 64
iwlagn 0000:10:00.0: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
iwlagn 0000:10:00.0: Tunable channels: 11 802.11bg, 13 802.11a channels
iwlagn 0000:10:00.0: irq 27 for MSI/MSI-X
phy0: Selected rate control algorithm 'iwl-agn-rs'
Normally I'd expect to see the following after that (from .30):
iwlagn 0000:10:00.0: firmware: requesting iwlwifi-4965-2.ucode
iwlagn 0000:10:00.0: loaded firmware version 228.57.2.23
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
wlan0: authenticate with AP 00:14:c1:38:e5:15
wlan0: authenticated
wlan0: associate with AP 00:14:c1:38:e5:15
wlan0: RX AssocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=1)
wlan0: associated
So it did not even try to load the firmware...
After the boot completed I tried unloading and reloading iwlagn, and then
I suddenly got:
iwlagn 0000:10:00.0: PCI INT A disabled
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: EU
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5490000 KHz - 5710000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: EU
iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27kd
iwlagn: Copyright(c) 2003-2009 Intel Corporation
iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:10:00.0: setting latency timer to 64
iwlagn 0000:10:00.0: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
iwlagn 0000:10:00.0: Tunable channels: 11 802.11bg, 13 802.11a channels
iwlagn 0000:10:00.0: irq 27 for MSI/MSI-X
phy0: Selected rate control algorithm 'iwl-agn-rs'
iwlagn 0000:10:00.0: firmware: requesting iwlwifi-4965-2.ucode
iwlagn 0000:10:00.0: loaded firmware version 228.57.2.23
iwlagn 0000:10:00.0: Radio disabled by HW RF Kill switch
I then noticed that the wireless led on the notbook was indeed off, but it
was totally unresponsive to any attempts to turn it on.
I also compared loaded modules; for .30:
cfg80211 65944 3 iwlagn,iwlcore,mac80211
iwlagn 113236 0
iwlcore 159172 1 iwlagn
led_class 5080 3 iwlcore,hp_accel,sdhci
lib80211 7520 1 iwlcore
mac80211 164744 2 iwlagn,iwlcore
rfkill 12276 5 hp_wmi,iwlcore
and for .31-rc1:
cfg80211 90808 3 iwlagn,iwlcore,mac80211
iwlagn 107856 0
iwlcore 167908 1 iwlagn
led_class 5064 3 iwlcore,hp_accel,sdhci
mac80211 167024 2 iwlagn,iwlcore
rfkill 20640 2 hp_wmi,cfg80211
Note that lib80211 no longer gets loaded.
After rebooting into .30 wireless worked again.
Cheers,
FJP
Relevant part of config (diff between .30 and .31-rc1):
CONFIG_WIRELESS=y
CONFIG_CFG80211=m
# CONFIG_CFG80211_REG_DEBUG is not set
+# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
+# CONFIG_MAC80211_DEFAULT_PS is not set
+CONFIG_MAC80211_DEFAULT_PS_VALUE=1
#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=m
-CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=y
+CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set
[...]
CONFIG_IWLWIFI=m
CONFIG_IWLWIFI_LEDS=y
-CONFIG_IWLWIFI_RFKILL=y
# CONFIG_IWLWIFI_SPECTRUM_MEASUREMENT is not set
CONFIG_IWLWIFI_DEBUG=y
CONFIG_IWLAGN=m
CONFIG_IWL4965=y
# CONFIG_IWL5000 is not set
# CONFIG_IWL3945 is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set
# CONFIG_HERMES is not set
+# CONFIG_IWM is not set
^ permalink raw reply
* Re: [2.6.31-rc1] iwlagn (4965): no wireless due to RFKILL problem
From: Maciej Rutecki @ 2009-06-26 11:59 UTC (permalink / raw)
To: Frans Pop; +Cc: linux-wireless, Netdev, linux-kernel
In-Reply-To: <200906261336.29318.elendil@planet.nl>
2009/6/26 Frans Pop <elendil@planet.nl>:
> I've tried .31-rc1 on my HP 2510p notebook and the only problem I found
> was that wireless no longer works. The cause looks to be related to
> RFKILL.
>
Same on HP/Compaq nx6310, caused by hp-wmi module. It's disable
bluetooth and wireless. I must turn it on in Windows XP (in HP tools).
Workaround: don't load hp-wmi. Already I try find how enable it via
/sys like in Windows.
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* Re: [2.6.31-rc1] iwlagn (4965): no wireless due to RFKILL problem
From: Frans Pop @ 2009-06-26 12:10 UTC (permalink / raw)
To: Maciej Rutecki
Cc: linux-wireless, Netdev, linux-kernel, Alan Jenkins, Johannes Berg
In-Reply-To: <8db1092f0906260459n308311faweb6d9733cdd1eb13@mail.gmail.com>
On Friday 26 June 2009, Maciej Rutecki wrote:
> 2009/6/26 Frans Pop <elendil@planet.nl>:
> > I've tried .31-rc1 on my HP 2510p notebook and the only problem I
> > found was that wireless no longer works. The cause looks to be
> > related to RFKILL.
>
> Same on HP/Compaq nx6310, caused by hp-wmi module. It's disable
> bluetooth and wireless. I must turn it on in Windows XP (in HP tools).
> Workaround: don't load hp-wmi. Already I try find how enable it via
> /sys like in Windows.
Thanks for narrowing it down.
Well, with 2.6.30 hp-wmi worked together with rfkill without problems.
Looking at the commit logs, it looks like the rfkill rewrite by Johannes
and Alan is the cause here. CCs added.
^ permalink raw reply
* [PATCH 3/3] iwlwifi: always print buffer when error condition occurs
From: Reinette Chatre @ 2009-06-26 18:00 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In-Reply-To: <1246039255-2195-3-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
We want to see the buffer contents when the error occurs without
needing to set any debug flags.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-tx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 85ae7a6..5d1d6c3 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -1108,7 +1108,7 @@ void iwl_tx_cmd_complete(struct iwl_priv *priv, struct iwl_rx_mem_buffer *rxb)
txq_id, sequence,
priv->txq[IWL_CMD_QUEUE_NUM].q.read_ptr,
priv->txq[IWL_CMD_QUEUE_NUM].q.write_ptr)) {
- iwl_print_hex_dump(priv, IWL_DL_INFO , rxb, 32);
+ iwl_print_hex_error(priv, rxb, 32);
return;
}
--
1.5.6.3
^ permalink raw reply related
* [PATCH 0/3] iwlwifi driver updates 06/26/2009
From: Reinette Chatre @ 2009-06-26 18:00 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
We re-enable indication that iwlwifi supports PS. The rest is just
debugging help.
[PATCH 1/3] iwlagn: re-enable PS support for iwlagn
[PATCH 2/3] iwlwifi: add utility to print buffer when error occurs
[PATCH 3/3] iwlwifi: always print buffer when error condition occurs
Reinette
^ permalink raw reply
* [PATCH 2/3] iwlwifi: add utility to print buffer when error occurs
From: Reinette Chatre @ 2009-06-26 18:00 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In-Reply-To: <1246039255-2195-2-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-debug.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-debug.h b/drivers/net/wireless/iwlwifi/iwl-debug.h
index 2cf014f..65bbce0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-debug.h
+++ b/drivers/net/wireless/iwlwifi/iwl-debug.h
@@ -36,6 +36,12 @@ struct iwl_priv;
#define IWL_INFO(p, f, a...) dev_info(&((p)->pci_dev->dev), f, ## a)
#define IWL_CRIT(p, f, a...) dev_crit(&((p)->pci_dev->dev), f, ## a)
+#define iwl_print_hex_error(priv, p, len) \
+do { \
+ print_hex_dump(KERN_ERR, "iwl data: ", \
+ DUMP_PREFIX_OFFSET, 16, 1, p, len, 1); \
+} while (0)
+
#ifdef CONFIG_IWLWIFI_DEBUG
#define IWL_DEBUG(__priv, level, fmt, args...) \
do { \
--
1.5.6.3
^ permalink raw reply related
* [PATCH 1/3] iwlagn: re-enable PS support for iwlagn
From: Reinette Chatre @ 2009-06-26 18:00 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In-Reply-To: <1246039255-2195-1-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
The register locking rework addressed the problem where nic
access was obtained incorrectly when PS is enabled.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-core.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 6ab0716..88135f3 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1325,7 +1325,8 @@ int iwl_setup_mac(struct iwl_priv *priv)
hw->flags = IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_NOISE_DBM |
IEEE80211_HW_AMPDU_AGGREGATION |
- IEEE80211_HW_SPECTRUM_MGMT;
+ IEEE80211_HW_SPECTRUM_MGMT |
+ IEEE80211_HW_SUPPORTS_PS;
hw->wiphy->interface_modes =
BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_ADHOC);
--
1.5.6.3
^ permalink raw reply related
* Re: [RFC 00/11] cfg80211 connect API + wireless extension move
From: Johannes Berg @ 2009-06-26 20:18 UTC (permalink / raw)
To: Dave; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <4A43E002.2060309@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]
On Thu, 2009-06-25 at 21:37 +0100, Dave wrote:
> Do we need to maintain these interfaces? I think allowing the same
> functionality via other means should be acceptable (since any software
> using these interfaces clearly doesn't work with any other hardware).
True.
> > Hm, which ones?
>
> orinoco has the following private wext handlers:
>
> reset firmware
> reset card
> get/set adhoc port
> get/set short preamble
> get/set ibss port
> get rid
>
> I've only ever had occasion to use the reset ioctls recently, when my
> card started seriously misbehaving (I suspect it's about to fail).
> debugfs or something?
Sounds appropriate.
> The get/set things could be done as module parameters. Preferred values
> will be model/fw specific - though I expect we have reasonable defaults
> picked during initialisation.
That too.
> Get RID reads settings off the card. Useful for debugging or reverse
> engineering, but I hope no-one uses it for anything else. Remove completely?
I suspect you can get rid of it, yes.
> Regarding patch 11 (the internalise one), would it be better to:
> * continue to export cfg80211_wext_* for now
> * set mac80211s dev->wireless_handler to &cfg80211_wext_handler in
> iface.c (via a #define that's NULL if !CONFIG_WEXT)
> * specify a release when we expect all drivers, or at least those
> anyone cares about, to have converted?
Sure. I don't think we need to specify a release since there's only
three drivers so far -- orinoco, rndis and iwm. The latter is taken care
of, and the two others shouldn't be much of a problem either.
> That removes the WE dependency from mac80211 but allows drivers to
> gradually implement cfg80211 support. I originally attempted doing it in
> one hit - that sucked, but may have been due to not having a clear idea
> of how cfg80211 is supposed to work.
Yeah, I agree, doing it in one go will probably overwork anyone who
attempts it, otoh once we actually convert everything in the tree all
the remaining drivers will have to be done in one go. So I think we
should just wait until all drivers are converted and then simply swap. I
can help with rndis/orinoco too.
> It also means orinoco can keep its wext private functions for a bit longer.
Yes. Mind you, I was not only talking about iwpriv, but also about
things like orinoco's spy support or get/set sensitivity. The latter we
don't quite understand -- can you tell us what it actually does? Spy
support should just be removed, I think.
Additionally, at the wireless summit today (yesterday by the time you
read this) we decided to allow cfg80211 drivers to continue exporting
iwpriv handlers, so that existing factory calibration interfaces or
similar can be maintained going forward even with future drivers.
However, this is understood to be purely for backward compatibility with
existing calibration or similar tools.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC 00/11] cfg80211 connect API + wireless extension move
From: Johannes Berg @ 2009-06-26 21:01 UTC (permalink / raw)
To: Dave; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <4A43E002.2060309@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]
On Thu, 2009-06-25 at 21:37 +0100, Dave wrote:
> Regarding patch 11 (the internalise one), would it be better to:
> * continue to export cfg80211_wext_* for now
> * set mac80211s dev->wireless_handler to &cfg80211_wext_handler in
> iface.c (via a #define that's NULL if !CONFIG_WEXT)
> * specify a release when we expect all drivers, or at least those
> anyone cares about, to have converted?
>
> That removes the WE dependency from mac80211 but allows drivers to
> gradually implement cfg80211 support. I originally attempted doing it in
> one hit - that sucked, but may have been due to not having a clear idea
> of how cfg80211 is supposed to work.
Another idea I just had is that we could do everything like my
internalise patch, but have an if (!netdev->wireless_handlers) before
the assignment. That way, people could still have their own wireless
handlers. Additionally, subject to a Kconfig symbol, we could still
export the handlers, something like this:
config NEED_CFG80211_WEXT_HANDLERS
bool
#ifdef CONFIG_NEED_...
#define EXPORT_WEXT(sym) EXPORT_SYMBOL_GPL(sym)
#define __wext_static
static inline void cfg80211_assign_wext_handlers(netdev, handlers)
{
if (!dev->wireless_handlers)
dev->wireless_handlers = h;
}
#else
#warn "Having custom wireless handlers is deprecated!!"
#define EXPORT_WEXT(sym)
#define __wext_static static
static inline void cfg80211_assign_wext_handlers(netdev, handlers)
{
dev->wireless_handlers = h;
}
#endif
or something like that. Then drivers that are in transition could select
NEED_... and transition call by call even in the future after we switch
to the central model. Is it worth it? I don't know.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* USB level power management for wireless dongles
From: Oliver Neukum @ 2009-06-27 8:55 UTC (permalink / raw)
To: linux-wireless, linux-usb
Hi,
this very experimental patch adds USB autosuspend support
to a wireless driver. Please test this to verify to concept works.
Regards
Oliver
--
commit d0806743041f9d2e3e215877b869b85ab4287574
Author: Oliver Neukum <oneukum@linux-d698.(none)>
Date: Sat Jun 27 10:40:54 2009 +0200
support for simple USB autosuspend for rt2x00
USB autosuspend is hooked into STATE_RADIO_ON/OFF
This allows USB autosuspend if the network interface is down
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 66daf68..1507dcf 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1126,14 +1126,21 @@ static int rt2500usb_set_state(struct rt2x00_dev *rt2x00dev,
static int rt2500usb_set_device_state(struct rt2x00_dev *rt2x00dev,
enum dev_state state)
{
+ struct usb_interface *usb_intf;
int retval = 0;
switch (state) {
case STATE_RADIO_ON:
+ usb_intf = to_usb_interface(&rt2x00dev->dev);
+ retval = usb_autopm_get_interface(usb_intf);
+ if (retval < 0)
+ break;
retval = rt2500usb_enable_radio(rt2x00dev);
break;
case STATE_RADIO_OFF:
+ usb_intf = to_usb_interface(&rt2x00dev->dev);
rt2500usb_disable_radio(rt2x00dev);
+ usb_autopm_put_interface(usb_intf);
break;
case STATE_RADIO_RX_ON:
case STATE_RADIO_RX_ON_LINK:
@@ -2053,6 +2060,7 @@ static struct usb_driver rt2500usb_driver = {
.disconnect = rt2x00usb_disconnect,
.suspend = rt2x00usb_suspend,
.resume = rt2x00usb_resume,
+ .supports_autosuspend = 1,
};
static int __init rt2500usb_init(void)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 3756166..4d20e58 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1907,6 +1907,7 @@ static int rt2800usb_set_state(struct rt2x00_dev *rt2x00dev,
static int rt2800usb_set_device_state(struct rt2x00_dev *rt2x00dev,
enum dev_state state)
{
+ struct usb_interface *usb_intf;
int retval = 0;
switch (state) {
@@ -1916,17 +1917,24 @@ static int rt2800usb_set_device_state(struct rt2x00_dev *rt2x00dev,
* to be woken up. After that it needs a bit of time
* to be fully awake and the radio can be enabled.
*/
+ usb_intf = to_usb_interface(&rt2x00dev->dev);
+ retval = usb_autopm_get_interface(usb_intf);
+ if (retval < 0)
+ break;
+ msleep(1); /* Paranoia */
rt2800usb_set_state(rt2x00dev, STATE_AWAKE);
msleep(1);
retval = rt2800usb_enable_radio(rt2x00dev);
break;
case STATE_RADIO_OFF:
+ usb_intf = to_usb_interface(&rt2x00dev->dev);
/*
* After the radio has been disablee, the device should
* be put to sleep for powersaving.
*/
rt2800usb_disable_radio(rt2x00dev);
rt2800usb_set_state(rt2x00dev, STATE_SLEEP);
+ usb_autopm_put_interface(usb_intf);
break;
case STATE_RADIO_RX_ON:
case STATE_RADIO_RX_ON_LINK:
@@ -3062,6 +3070,7 @@ static struct usb_driver rt2800usb_driver = {
.disconnect = rt2x00usb_disconnect,
.suspend = rt2x00usb_suspend,
.resume = rt2x00usb_resume,
+ .supports_autosuspend = 1,
};
static int __init rt2800usb_init(void)
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index c188488..18c2fbe 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -1403,14 +1403,21 @@ static int rt73usb_set_state(struct rt2x00_dev *rt2x00dev, enum dev_state state)
static int rt73usb_set_device_state(struct rt2x00_dev *rt2x00dev,
enum dev_state state)
{
+ struct usb_interface *usb_intf;
int retval = 0;
switch (state) {
case STATE_RADIO_ON:
+ usb_intf = to_usb_interface(&rt2x00dev->dev);
+ retval = usb_autopm_get_interface(usb_intf);
+ if (retval < 0)
+ break;
retval = rt73usb_enable_radio(rt2x00dev);
break;
case STATE_RADIO_OFF:
+ usb_intf = to_usb_interface(&rt2x00dev->dev);
rt73usb_disable_radio(rt2x00dev);
+ usb_autopm_put_interface(usb_intf);
break;
case STATE_RADIO_RX_ON:
case STATE_RADIO_RX_ON_LINK:
@@ -2442,6 +2449,7 @@ static struct usb_driver rt73usb_driver = {
.disconnect = rt2x00usb_disconnect,
.suspend = rt2x00usb_suspend,
.resume = rt2x00usb_resume,
+ .supports_autosuspend = 1,
};
static int __init rt73usb_init(void)
^ permalink raw reply related
* Re: [2.6.31-rc1] iwlagn (4965): no wireless due to RFKILL problem
From: Frans Pop @ 2009-06-27 9:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Maciej Rutecki, linux-wireless, Netdev, linux-kernel,
Alan Jenkins
In-Reply-To: <1246048132.21314.75.camel@johannes.local>
On Friday 26 June 2009, Johannes Berg wrote:
> On Fri, 2009-06-26 at 14:10 +0200, Frans Pop wrote:
> > Well, with 2.6.30 hp-wmi worked together with rfkill without
> > problems. Looking at the commit logs, it looks like the rfkill
> > rewrite by Johannes and Alan is the cause here. CCs added.
>
> Hmm, looks like there might be another polarity error, try this:
> - int query = BIT(b + 8) | ((!!blocked) << b);
> + int query = BIT(b + 8) | ((!blocked) << b);
Thanks Johannes, that makes wireless work again.
However, I just saw another possible issue.
When I disable wireless using the hardware switch and the enable it again
almost immediately after on 2.6.30, I get:
[disable]
iwlagn 0000:10:00.0: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.
usb 3-1: USB disconnect, address 2
[enable]
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
usb 3-1: new full speed USB device using uhci_hcd and address 3
usb 3-1: configuration #1 chosen from 1 choice
wlan0: no probe response from AP 00:14:c1:38:e5:15 - disassociating
iwlagn 0000:10:00.0: index 0 not used in uCode key table.
wlan0: authenticate with AP 00:14:c1:38:e5:15
wlan0: authenticate with AP 00:14:c1:38:e5:15
wlan0: authenticated
wlan0: associate with AP 00:14:c1:38:e5:15
wlan0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=1)
wlan0: associated
And without any other action networking is up again.
With 2.6.31 I get this:
[disable]
wlan0: deauthenticating by local choice (reason=3)
iwlagn 0000:10:00.0: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5
mac80211-phy0: failed to remove key (0, 00:14:c1:38:e5:15) from hardware (-5)
iwlagn 0000:10:00.0: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5
mac80211-phy0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-5)
usb 3-1: USB disconnect, address 2
[enable]
usb 3-1: new full speed USB device using uhci_hcd and address 3
usb 3-1: configuration #1 chosen from 1 choice
A lot uglier with those errors. And after that I have to run ifdown/ifup
before networking is up again (ifup only does not work as it will complain
"interface already configured"):
[ifdown wlan0]
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ifup wlan 0]
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: authenticate with AP 00:14:c1:38:e5:15
wlan0: authenticated
wlan0: associate with AP 00:14:c1:38:e5:15
wlan0: RX AssocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
BTW, would it make sense to bring back the first two lines shown with .30
(or at least the first one):
iwlagn 0000:10:00.0: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.
IMHO it's good to register the reason for the disconnect.
Cheers,
FJP
^ permalink raw reply
* Re: [2.6.31-rc1] iwlagn (4965): no wireless due to RFKILL problem
From: Maciej Rutecki @ 2009-06-27 9:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Frans Pop, linux-wireless, Netdev, linux-kernel, Alan Jenkins
In-Reply-To: <1246048132.21314.75.camel@johannes.local>
2009/6/26 Johannes Berg <johannes@sipsolutions.net>:
> Hmm, looks like there might be another polarity error, try this:
> - int query = BIT(b + 8) | ((!!blocked) << b);
> + int query = BIT(b + 8) | ((!blocked) << b);
>
This helps. hp-wmi works without any problems.
Tested-by Maciej Rutecki <maciej.rutecki@gmail.com>
Thanks
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* [PATCH] p54: re-enable power save feature
From: Christian Lamparter @ 2009-06-28 0:32 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Johannes Berg
This patch re-enables p54's power save features and adds a workaround
which temporarily alters the device's power state in order to allow
ps-polls to be sent and buffered data to be retrieved during psm.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
Johannes,
can you please give this patch a go with your cisco ap?
Regards,
Chr
---
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 178efbc..9bff43d 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -584,7 +584,8 @@ int p54_set_ps(struct p54_common *priv)
unsigned int i;
u16 mode;
- if (priv->hw->conf.flags & IEEE80211_CONF_PS)
+ if (priv->hw->conf.flags & IEEE80211_CONF_PS &&
+ !priv->powersave_override)
mode = P54_PSM | P54_PSM_BEACON_TIMEOUT | P54_PSM_DTIM |
P54_PSM_CHECKSUM | P54_PSM_MCBC;
else
@@ -606,8 +607,8 @@ int p54_set_ps(struct p54_common *priv)
psm->beacon_rssi_skip_max = 200;
psm->rssi_delta_threshold = 0;
- psm->nr = 10;
- psm->exclude[0] = 0;
+ psm->nr = 1;
+ psm->exclude[0] = WLAN_EID_TIM;
p54_tx(priv, skb);
return 0;
diff --git a/drivers/net/wireless/p54/lmac.h b/drivers/net/wireless/p54/lmac.h
index 0496cff..af35cfc 100644
--- a/drivers/net/wireless/p54/lmac.h
+++ b/drivers/net/wireless/p54/lmac.h
@@ -548,4 +548,7 @@ int p54_upload_key(struct p54_common *priv, u8 algo, int slot,
int p54_download_eeprom(struct p54_common *priv, void *buf,
u16 offset, u16 len);
+/* utility */
+u8 *p54_find_ie(struct sk_buff *skb, u8 ie);
+
#endif /* LMAC_H */
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index f9b4f6a..42abf34 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -65,51 +65,64 @@ static int p54_set_tim(struct ieee80211_hw *dev, struct ieee80211_sta *sta,
return p54_update_beacon_tim(priv, sta->aid, set);
}
-static int p54_beacon_format_ie_tim(struct sk_buff *skb)
+u8 *p54_find_ie(struct sk_buff *skb, u8 ie)
{
- /*
- * the good excuse for this mess is ... the firmware.
- * The dummy TIM MUST be at the end of the beacon frame,
- * because it'll be overwritten!
- */
-
struct ieee80211_mgmt *mgmt = (void *)skb->data;
u8 *pos, *end;
if (skb->len <= sizeof(mgmt))
- return -EINVAL;
+ return NULL;
pos = (u8 *)mgmt->u.beacon.variable;
end = skb->data + skb->len;
while (pos < end) {
if (pos + 2 + pos[1] > end)
- return -EINVAL;
+ return NULL;
- if (pos[0] == WLAN_EID_TIM) {
- u8 dtim_len = pos[1];
- u8 dtim_period = pos[3];
- u8 *next = pos + 2 + dtim_len;
+ if (pos[0] == ie)
+ return pos;
- if (dtim_len < 3)
- return -EINVAL;
+ pos += 2 + pos[1];
+ }
+ return NULL;
+}
- memmove(pos, next, end - next);
+static int p54_beacon_format_ie_tim(struct sk_buff *skb)
+{
+ /*
+ * the good excuse for this mess is ... the firmware.
+ * The dummy TIM MUST be at the end of the beacon frame,
+ * because it'll be overwritten!
+ */
+ u8 *tim;
+ u8 dtim_len;
+ u8 dtim_period;
+ u8 *next;
- if (dtim_len > 3)
- skb_trim(skb, skb->len - (dtim_len - 3));
+ tim = p54_find_ie(skb, WLAN_EID_TIM);
+ if (!tim)
+ return 0;
- pos = end - (dtim_len + 2);
+ dtim_len = tim[1];
+ dtim_period = tim[3];
+ next = tim + 2 + dtim_len;
- /* add the dummy at the end */
- pos[0] = WLAN_EID_TIM;
- pos[1] = 3;
- pos[2] = 0;
- pos[3] = dtim_period;
- pos[4] = 0;
- return 0;
- }
- pos += 2 + pos[1];
- }
+ if (dtim_len < 3)
+ return -EINVAL;
+
+ memmove(tim, next, skb_tail_pointer(skb) - next);
+
+ if (dtim_len > 3)
+ skb_trim(skb, skb->len - (dtim_len - 3));
+
+ tim = skb_tail_pointer(skb) - (dtim_len + 2);
+
+ /* add the dummy at the end */
+ tim[0] = WLAN_EID_TIM;
+ tim[1] = 3;
+ tim[2] = 0;
+ tim[3] = dtim_period;
+ tim[4] = 0;
return 0;
}
@@ -384,6 +397,9 @@ static void p54_bss_info_changed(struct ieee80211_hw *dev,
priv->wakeup_timer = info->beacon_int *
info->dtim_period * 5;
p54_setup_mac(priv);
+ } else {
+ priv->wakeup_timer = 500;
+ priv->aid = 0;
}
}
@@ -517,6 +533,9 @@ struct ieee80211_hw *p54_init_common(size_t priv_data_len)
skb_queue_head_init(&priv->tx_pending);
dev->flags = IEEE80211_HW_RX_INCLUDES_FCS |
IEEE80211_HW_SIGNAL_DBM |
+ IEEE80211_HW_SUPPORTS_PS |
+ IEEE80211_HW_PS_NULLFUNC_STACK |
+ IEEE80211_HW_BEACON_FILTER |
IEEE80211_HW_NOISE_DBM;
dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
index 19d085c..6772ed5 100644
--- a/drivers/net/wireless/p54/p54.h
+++ b/drivers/net/wireless/p54/p54.h
@@ -208,6 +208,7 @@ struct p54_common {
u32 tsf_low32, tsf_high32;
u32 basic_rate_mask;
u16 aid;
+ bool powersave_override;
__le32 beacon_req_id;
/* cryptographic engine information */
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index 31fda17..ea074a6 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -285,6 +285,45 @@ static int p54_rssi_to_dbm(struct p54_common *priv, int rssi)
priv->rssical_db[band].add) / 4;
}
+/*
+ * Even if the firmware is capable of dealing with incoming traffic,
+ * while dozing, we have to prepared in case mac80211 uses PS-POLL
+ * to retrieve outstanding frames from our AP.
+ * (see comment in net/mac80211/mlme.c @ line 1993)
+ */
+static void p54_pspoll_workaround(struct p54_common *priv, struct sk_buff *skb)
+{
+ struct ieee80211_hdr *hdr = (void *) skb->data;
+ struct ieee80211_tim_ie *tim_ie;
+ u8 *tim;
+ u8 tim_len;
+ bool new_psm;
+
+ /* only beacons have a TIM IE */
+ if (!ieee80211_is_beacon(hdr->frame_control))
+ return;
+
+ if (!priv->aid)
+ return;
+
+ /* only consider beacons from the associated BSSID */
+ if (compare_ether_addr(hdr->addr3, priv->bssid))
+ return;
+
+ tim = p54_find_ie(skb, WLAN_EID_TIM);
+ if (!tim)
+ return;
+
+ tim_len = tim[1];
+ tim_ie = (struct ieee80211_tim_ie *) &tim[2];
+
+ new_psm = ieee80211_check_tim(tim_ie, tim_len, priv->aid);
+ if (new_psm != priv->powersave_override) {
+ priv->powersave_override = new_psm;
+ p54_set_ps(priv);
+ }
+}
+
static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
{
struct p54_rx_data *hdr = (struct p54_rx_data *) skb->data;
@@ -337,6 +376,9 @@ static int p54_rx_data(struct p54_common *priv, struct sk_buff *skb)
skb_pull(skb, header_len);
skb_trim(skb, le16_to_cpu(hdr->len));
+ if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS))
+ p54_pspoll_workaround(priv, skb);
+
ieee80211_rx_irqsafe(priv->hw, skb);
queue_delayed_work(priv->hw->workqueue, &priv->work,
^ permalink raw reply related
* Re: [RFC 00/11] cfg80211 connect API + wireless extension move
From: Dave @ 2009-06-28 8:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1246050118.21314.82.camel@johannes.local>
Johannes Berg wrote:
> On Thu, 2009-06-25 at 21:37 +0100, Dave wrote:
>
>> That removes the WE dependency from mac80211 but allows drivers to
>> gradually implement cfg80211 support. I originally attempted doing it in
>> one hit - that sucked, but may have been due to not having a clear idea
>> of how cfg80211 is supposed to work.
>
> Another idea I just had is that we could do everything like my
> internalise patch, but have an if (!netdev->wireless_handlers) before
> the assignment. That way, people could still have their own wireless
> handlers.
I had that same thought...
> Additionally, subject to a Kconfig symbol, we could still
> export the handlers, something like this:
<snip>
> or something like that. Then drivers that are in transition could select
> NEED_... and transition call by call even in the future after we switch
> to the central model. Is it worth it? I don't know.
Neat. I tend to prefer avoiding these indirections and keeping things
clean. I'd vote (if I had one) to take the NEED_ behaviour now, and
transition at some point.
Thanks,
Dave.
^ permalink raw reply
* Re: [RFC 00/11] cfg80211 connect API + wireless extension move
From: Dave @ 2009-06-28 9:26 UTC (permalink / raw)
To: Johannes Berg; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1246047520.21314.67.camel@johannes.local>
Johannes Berg wrote:
> Yes. Mind you, I was not only talking about iwpriv, but also about
> things like orinoco's spy support or get/set sensitivity. The latter we
> don't quite understand -- can you tell us what it actually does? Spy
> support should just be removed, I think.
I've had a closer look at this.
The sensitivity basically controls the roaming threshold when handled by
firmware. It is a firmware setting, though the Agere driver also
validates the multicast rates based on it. The drivers/firmware use
terms like system scale, AP density, distance between APs.
There are 3 valid values:
3 - high density of APs. Maintain 11Mbps by roaming.
2 - medium density of APs. Maintain 2Mbps.
1 - low density. Maintain 1Mbps.
Although the values are defined in terms of the usable bitrate, the
(Intersil) documentation states that the implementation is based on SNR.
Dave.
^ permalink raw reply
* Re: [PATCH] wireless: Compare ethernet addresses by unaligned safe way
From: Ivan Kuten @ 2009-06-28 12:18 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Yauhen Kharuzhy
In-Reply-To: <1245150895.8623.3.camel@johannes.local>
Hello,
In net/wireless/scan.c : cfg80211_wext_siwscan there seems also unaligned allocations
for creq->ssids and creq->channels. Should it be something like that?
Modified: trunk/uClinux-dist-2008R1-RC8/compat-wireless-2009-06-11/net/wireless/scan.c
==============================================================================
--- trunk/uClinux-dist-2008R1-RC8/compat-wireless-2009-06-11/net/wireless/scan.c (original)
+++ trunk/uClinux-dist-2008R1-RC8/compat-wireless-2009-06-11/net/wireless/scan.c Fri Jun 26 14:00:52 2009
@@ -619,7 +619,7 @@
if (wiphy->bands[band])
n_channels += wiphy->bands[band]->n_channels;
- creq = kzalloc(sizeof(*creq) + sizeof(struct cfg80211_ssid) +
+ creq = kzalloc(roundup(sizeof(*creq), 4) + roundup(sizeof(struct cfg80211_ssid), 4) +
n_channels * sizeof(void *),
GFP_ATOMIC);
if (!creq) {
@@ -629,8 +629,8 @@
creq->wiphy = wiphy;
creq->ifidx = dev->ifindex;
- creq->ssids = (void *)(creq + 1);
- creq->channels = (void *)(creq->ssids + 1);
+ creq->ssids = (void *)creq + roundup(sizeof(*creq), 4);
+ creq->channels = (void *)creq->ssids + roundup(sizeof(*creq->ssids), 4);
creq->n_channels = n_channels;
creq->n_ssids = 1;
Regards,
Ivan
> On Tue, 2009-06-16 at 13:54 +0300, Yauhen Kharuzhy wrote:
>> When we try to run RTL8187 driver on AD BlackFin platform, we got
>> messages from kernel about unaligned memory access at
>> compare_ether_addr() calls.
>>
>> Replacing of compare_ether_addr() by memcmp() fixes this problem.
>
> This shouldn't be necessary. Which operand is unaligned?
>
>> --- a/net/mac80211/ibss.c
>> +++ b/net/mac80211/ibss.c
>> @@ -395,7 +395,7 @@ struct sta_info *ieee80211_ibss_add_sta(struct ieee80211_sub_if_data *sdata,
>> return NULL;
>> }
>>
>> - if (compare_ether_addr(bssid, sdata->u.ibss.bssid))
>> + if (memcmp(bssid, sdata->u.ibss.bssid, ETH_ALEN))
>> return NULL;
>
> So in this case it seems that it is possible that u.ibss.bssid is not
> aligned, consider fixing by doing
>
> --- ieee80211_i.h
> +++ ieee80211_i.h
> - u8 bssid[ETH_ALEN];
> + u8 bssid[ETH_ALEN] __align(2);
>
> or so instead.
>
>> --- a/net/wireless/scan.c
>> +++ b/net/wireless/scan.c
>> @@ -134,7 +134,7 @@ static bool is_bss(struct cfg80211_bss *a,
>> {
>> const u8 *ssidie;
>>
>> - if (bssid && compare_ether_addr(a->bssid, bssid))
>> + if (bssid && memcmp(a->bssid, bssid, ETH_ALEN))
>
> Since a->bssid is after a pointer I can't see how it would be unaligned,
> and bssid should be unaligned only if the call trace shows it's coming
> from the above u.ibss.bssid.
>
> johannes
^ permalink raw reply
* Re: Proposal enquiry for Wireless Roaming feature enhancement
From: Dave @ 2009-06-28 14:07 UTC (permalink / raw)
To: Holger Schurig
Cc: linux-wireless, Kalle Valo, Dan Williams, Johannes Berg,
Balaji Ravindran, Mircea Gherzan
In-Reply-To: <200906231001.29728.hs4233@mail.mn-solutions.de>
Holger Schurig wrote:
>> Can you tell anything about the configuration parameters
>> available? For example, can the driver configure an rssi
>> threshold for enabling background scanning[1]?
>
> Orinoco and WLAGS Hermes1 and Hermes2 has some "sensitivy"
> setting, from 1..3:
>
> $ iwconfig eth1 sens 3
>
> What exactly this does is a bit opaque and handled by the
> firmware.
I wasn't paying too much attention to this thread. However as part of a
separate thread* I had a look into orinoco's sensitivity setting.
Anyway, see my e-mail earlier today for a description of what the values
do. The description should be valid for Intersil and Agere firmware
(including most if not all old versions), and applies to orinoco and
WL_LKM drivers.
Regards,
Dave.
* the thread is titled "[RFC 00/11] cfg80211: connect API + wireless
extension move"
^ permalink raw reply
* [PATCH 27/62] drivers/net/wireless/ath/ath9k: Remove unnecessary semicolons
From: Joe Perches @ 2009-06-28 16:26 UTC (permalink / raw)
To: linux-kernel
Cc: trivial, Andrew Morton, Senthil Balasubramanian,
Vasanthakumar Thiagarajan, Sujith Manoharan, Jouni Malinen,
Luis R. Rodriguez, ath9k-devel, linux-wireless, netdev
In-Reply-To: <cover.1246173664.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/ath/ath9k/eeprom.c | 2 --
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c b/drivers/net/wireless/ath/ath9k/eeprom.c
index a2fda70..d82a0f9 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -2516,10 +2516,8 @@ static void ath9k_hw_set_def_power_per_rate_table(struct ath_hw *ah,
targetPowerCck.tPow2x[1];
ratesArray[rate5_5s] = ratesArray[rate5_5l] =
targetPowerCck.tPow2x[2];
- ;
ratesArray[rate11s] = ratesArray[rate11l] =
targetPowerCck.tPow2x[3];
- ;
}
if (IS_CHAN_HT40(chan)) {
for (i = 0; i < ARRAY_SIZE(targetPowerHt40.tPow2x); i++) {
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 34935a8..cffb078 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2345,7 +2345,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
ath9k_hw_init_bb(ah, chan);
if (!ath9k_hw_init_cal(ah, chan))
- return -EIO;;
+ return -EIO;
rx_chainmask = ah->rxchainmask;
if ((rx_chainmask == 0x5) || (rx_chainmask == 0x3)) {
--
1.6.3.1.10.g659a0.dirty
^ permalink raw reply related
* Re: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc)
From: Sitsofe Wheeler @ 2009-06-28 20:23 UTC (permalink / raw)
To: Bob Copeland
Cc: Jiri Slaby, Nick Kossifidis, Frederic Weisbecker, linux-kernel,
linux-wireless, ath5k-devel, Luis R. Rodriguez
In-Reply-To: <20090526211029.GA2011@sucs.org>
On Tue, May 26, 2009 at 10:10:30PM +0100, Sitsofe Wheeler wrote:
> On Fri, May 22, 2009 at 10:39:31AM +0100, Sitsofe Wheeler wrote:
> > On Mon, May 18, 2009 at 11:05:40AM +0100, Sitsofe Wheeler wrote:
> > > On Fri, May 15, 2009 at 12:09:04AM -0400, Bob Copeland wrote:
> > > >
> > > > This is too ugly to live, but I'd like to know if you can reproduce
> > > > with this patch. If it still happens, then I guess it's back to
> >
> > The poison message has not reappeared but this morning there was a
>
> Yet again, I spoke too soon. This evening the following was in dmesg:
>
> I'm pretty certain this kernel had your previous patch (although the
> directory that held the kernel has since been cleaned away on the server
> on which it was compiled).
OK I'm still trying to follow this. I forwarded your patch to 2.6.31-rc1
but this time I have kmemleak enabled. I left it streaming radio for the
past few hours and the following appeared in the logs:
Jun 28 17:01:34 eeepc kernel: [ 744.083787] kmemleak: unreferenced object 0xf5845770 (size 64):
Jun 28 17:01:34 eeepc kernel: [ 744.083795] kmemleak: comm "swapper", pid 1, jiffies 4294673468
Jun 28 17:01:34 eeepc kernel: [ 744.083799] kmemleak: backtrace:
Jun 28 17:01:34 eeepc kernel: [ 744.083811] kmemleak: [<c01a749d>] kmemleak_alloc+0x11d/0x2a0
Jun 28 17:01:34 eeepc kernel: [ 744.083818] kmemleak: [<c01a4376>] __kmalloc+0x136/0x210
Jun 28 17:01:34 eeepc kernel: [ 744.083828] kmemleak: [<c043f923>] ieee80211_register_hw+0x83/0x4b0
Jun 28 17:01:34 eeepc kernel: [ 744.083837] kmemleak: [<c04630d5>] ath5k_pci_probe+0xee5/0x1100
Jun 28 17:01:34 eeepc kernel: [ 744.083849] kmemleak: [<c0279ab3>] local_pci_probe+0x13/0x20
Jun 28 17:01:34 eeepc kernel: [ 744.083856] kmemleak: [<c027a608>] pci_device_probe+0x68/0x90
Jun 28 17:01:34 eeepc kernel: [ 744.083864] kmemleak: [<c0312670>] driver_probe_device+0x70/0x140
Jun 28 17:01:34 eeepc kernel: [ 744.083872] kmemleak: [<c031293a>] __driver_attach+0x7a/0x80
Jun 28 17:01:34 eeepc kernel: [ 744.083881] kmemleak: [<c0311af9>] bus_for_each_dev+0x49/0x70
Jun 28 17:01:34 eeepc kernel: [ 744.083888] kmemleak: [<c031250e>] driver_attach+0x1e/0x20
Jun 28 17:01:34 eeepc kernel: [ 744.083896] kmemleak: [<c0312188>] bus_add_driver+0xd8/0x290
Jun 28 17:01:34 eeepc kernel: [ 744.083904] kmemleak: [<c0312a6f>] driver_register+0x5f/0x120
Jun 28 17:01:34 eeepc kernel: [ 744.083911] kmemleak: [<c027a443>] __pci_register_driver+0x53/0xc0
Jun 28 17:01:34 eeepc kernel: [ 744.083922] kmemleak: [<c061d82d>] init_ath5k_pci+0x1d/0x40
Jun 28 17:01:34 eeepc kernel: [ 744.083929] kmemleak: [<c0101122>] do_one_initcall+0x32/0x1d0
Jun 28 17:01:34 eeepc kernel: [ 744.083939] kmemleak: [<c05fe8aa>] kernel_init+0xba/0x110
Jun 28 17:01:34 eeepc kernel: [ 744.084074] kmemleak: unreferenced object 0xf5845b60 (size 64):
Jun 28 17:01:34 eeepc kernel: [ 744.084080] kmemleak: comm "swapper", pid 1, jiffies 4294683694
Jun 28 17:01:34 eeepc kernel: [ 744.084085] kmemleak: backtrace:
Jun 28 17:01:34 eeepc kernel: [ 744.084093] kmemleak: [<c01a749d>] kmemleak_alloc+0x11d/0x2a0
Jun 28 17:01:34 eeepc kernel: [ 744.084100] kmemleak: [<c01a4376>] __kmalloc+0x136/0x210
Jun 28 17:01:34 eeepc kernel: [ 744.084111] kmemleak: [<c0239880>] __crypto_alloc_tfm+0x40/0x170
Jun 28 17:01:34 eeepc kernel: [ 744.084120] kmemleak: [<c0239cbc>] crypto_alloc_base+0x3c/0x80
Jun 28 17:01:34 eeepc kernel: [ 744.084128] kmemleak: [<c04420ff>] ieee80211_wep_init+0x2f/0x80
Jun 28 17:01:34 eeepc kernel: [ 744.084136] kmemleak: [<c043fa9d>] ieee80211_register_hw+0x1fd/0x4b0
Jun 28 17:01:34 eeepc kernel: [ 744.084144] kmemleak: [<c04630d5>] ath5k_pci_probe+0xee5/0x1100
Jun 28 17:01:34 eeepc kernel: [ 744.084153] kmemleak: [<c0279ab3>] local_pci_probe+0x13/0x20
Jun 28 17:01:34 eeepc kernel: [ 744.084160] kmemleak: [<c027a608>] pci_device_probe+0x68/0x90
Jun 28 17:01:34 eeepc kernel: [ 744.084168] kmemleak: [<c0312670>] driver_probe_device+0x70/0x140
Jun 28 17:01:34 eeepc kernel: [ 744.084175] kmemleak: [<c031293a>] __driver_attach+0x7a/0x80
Jun 28 17:01:34 eeepc kernel: [ 744.084184] kmemleak: [<c0311af9>] bus_for_each_dev+0x49/0x70
Jun 28 17:01:34 eeepc kernel: [ 744.084191] kmemleak: [<c031250e>] driver_attach+0x1e/0x20
Jun 28 17:01:34 eeepc kernel: [ 744.084199] kmemleak: [<c0312188>] bus_add_driver+0xd8/0x290
Jun 28 17:01:34 eeepc kernel: [ 744.084207] kmemleak: [<c0312a6f>] driver_register+0x5f/0x120
Jun 28 17:01:34 eeepc kernel: [ 744.084214] kmemleak: [<c027a443>] __pci_register_driver+0x53/0xc0
There were quite a few leaks before this. I dunno if kmemleak is
spurious or not. As always, any ideas?
--
Sitsofe | http://sucs.org/~sits/
^ 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