03:00.0 0280: 168c:002b (rev 01)
AR9285
3.2.something from a not-network-related repo. Everything network
related should be equivalent to mainline.
So far I could not obtain any details, because I've no idea how to make
ramoops succeed requesting memory and unfortunally my last attempt at
using vmcore failed because somehow I lost dbg symbols. The backtrace
that I get from the vmcore looks little promising though, even without
symbols:
(gdb) bt
#0 0xffffffff8119ff42 in ?? ()
#1 0x0000000000000000 in ?? ()
Even less promising looks the size of the vmcore, which I assume to be
the size of the actual RAM in use at the point of the panic:
-r-------- 1 root root 4014652552 Nov 21 20:19 vmcore
Compared to the output in normal operation, which is when the panics
occur. At the asbolute most, 2 Gigabytes including caches.
I'm afraid, that if my interpretion of the size of vmcore is correct,
ath eats up all RAM and thereby cause the panic, milliseconds before the
crash.
Why I think it's ath9k? This panic occurs, though not clearly
reproducibly, with moderate load on the wifi, that is listening to
online radio. And a few times I could witness a panic log on the console
(mostly everything freezes right in X) and ath was clearly involved.
As I said, I'm trying to obtain anything more definite, but it could be
hard, unless I get ramoops to work, which currently refuses to accept
any memory address to write the dump to.
Of course, I readily provide any info I can from the vmcore and will try
to get a bt with proper symbols asap.
Until then, this appears to be a regression somewhere since 3.1.1 (or
possibly 3.1.0). It's hard to tell though, since it's not readily
reproducible but I have never had the panic in neither of those
versions.
Cedric
On Tue, Nov 22, 2011 at 3:03 AM, Cedric Sodhi <[email protected]> wrote:
> 03:00.0 0280: 168c:002b (rev 01)
>
> AR9285
>
> 3.2.something from a not-network-related repo. Everything network
> related should be equivalent to mainline.
>
> So far I could not obtain any details, because I've no idea how to make
> ramoops succeed requesting memory and unfortunally my last attempt at
> using vmcore failed because somehow I lost dbg symbols. The backtrace
> that I get from the vmcore looks little promising though, even without
> symbols:
>
> (gdb) bt
> #0 ?0xffffffff8119ff42 in ?? ()
> #1 ?0x0000000000000000 in ?? ()
>
> Even less promising looks the size of the vmcore, which I assume to be
> the size of the actual RAM in use at the point of the panic:
>
> -r-------- ?1 root ? root ? 4014652552 Nov 21 20:19 vmcore
>
> Compared to the output in normal operation, which is when the panics
> occur. At the asbolute most, 2 Gigabytes including caches.
>
> I'm afraid, that if my interpretion of the size of vmcore is correct,
> ath eats up all RAM and thereby cause the panic, milliseconds before the
> crash.
>
> Why I think it's ath9k? This panic occurs, though not clearly
> reproducibly, with moderate load on the wifi, that is listening to
> online radio. And a few times I could witness a panic log on the console
> (mostly everything freezes right in X) and ath was clearly involved.
i am going to try this in my wireless-testing tree/ latest compat
wireless. please let me know if i had to do something specific(running
traffic in noisy environment, put the device in monitor mode) to
trigger the panic. any info to recreate will be helpful. i will also
try that online radio(i am not aware if it). i will be trying it in my
x86 platform.
>
> As I said, I'm trying to obtain anything more definite, but it could be
> hard, unless I get ramoops to work, which currently refuses to accept
> any memory address to write the dump to.
>
> Of course, I readily provide any info I can from the vmcore and will try
> to get a bt with proper symbols asap.
>
> Until then, this appears to be a regression somewhere since 3.1.1 (or
> possibly 3.1.0). It's hard to tell though, since it's not readily
> reproducible but I have never had the panic in neither of those
> versions.
>
> Cedric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
shafi