I hit this warning in ath9k. Shortly after the machine blew up elsewhere,
but not sure if this is to blame or not.
Code is slightly modified 3.7.5 (just a few patches, not my normal mass of hackings!)
The warning that hit is the one below:
bf = ath9k_beacon_generate(sc->hw, vif);
WARN_ON(!bf);
Test case is dual-core Atom system with ath9k NIC, 10 or so virtual stations,
two virtual APs. Two stations send traffic to each other once everything associates, but
not sure it got that far when this crash happened.
[ 50.101409] device rddVR1 entered promiscuous mode
[ 52.898741] IPv6: ADDRCONF(NETDEV_CHANGE): vap1: link becomes ready
[ 54.119148] ------------[ cut here ]------------
[ 54.124563] WARNING: at /home/greearb/git/linux-3.7.dev.y/drivers/net/wireless/ath/ath9k/beacon.c:362 ath9k_beacon_tasklet+0xcc/0x5f0)
[ 54.138053] Hardware name: To Be Filled By O.E.M.
[ 54.143048] Modules linked in: bridge veth ip_gre gre 8021q garp stp llc fuse macvlan pktgen nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscao
[ 54.194049] Pid: 0, comm: swapper/0 Tainted: G C 3.7.5+ #39
[ 54.200819] Call Trace:
[ 54.203474] [<c04451bd>] warn_slowpath_common+0x6d/0xa0
[ 54.209086] [<f8b2e95c>] ? ath9k_beacon_tasklet+0xcc/0x5f0 [ath9k]
[ 54.215738] [<f8b2e95c>] ? ath9k_beacon_tasklet+0xcc/0x5f0 [ath9k]
[ 54.222398] [<c044520d>] warn_slowpath_null+0x1d/0x20
[ 54.227905] [<f8b2e95c>] ath9k_beacon_tasklet+0xcc/0x5f0 [ath9k]
[ 54.234236] [<c04cb37e>] ? check_for_new_grace_period+0x9e/0x120
[ 54.240655] [<c049d561>] ? trace_hardirqs_on_caller+0xa1/0x180
[ 54.246885] [<c044cf8c>] tasklet_action+0xbc/0xd0
[ 54.251960] [<c044d440>] __do_softirq+0xa0/0x170
[ 54.256959] [<c044d3a0>] ? irq_enter+0x70/0x70
[ 54.261772] <IRQ> [<c044d2fd>] ? irq_exit+0xbd/0xe0
[ 54.273227] [<c040d426>] ? do_IRQ+0x46/0xb0
[ 54.283802] [<c097a7f8>] ? common_interrupt+0x38/0x40
[ 54.295293] [<c049007b>] ? profile_setup+0x1fb/0x270
[ 54.306686] [<c06ac18b>] ? intel_idle+0xab/0x110
[ 54.317660] [<c0825746>] ? cpuidle_enter+0x16/0x30
[ 54.328715] [<c082576c>] ? cpuidle_enter_state+0xc/0x40
[ 54.340275] [<c0825cf9>] ? cpuidle_idle_call+0x79/0xb0
[ 54.351619] [<c041390f>] ? cpu_idle+0xaf/0xf0
[ 54.362096] [<c0957405>] ? rest_init+0xd5/0x140
[ 54.372738] [<c0957330>] ? __read_lock_failed+0x1c/0x1c
[ 54.384133] [<c0beeb82>] ? start_kernel+0x37c/0x382
[ 54.395109] [<c0bee677>] ? repair_env_string+0x5b/0x5b
[ 54.406368] [<c093ae29>] ? datagram_send_ctl+0x129/0x540
[ 54.417819] [<c0bee306>] ? i386_start_kernel+0xa9/0xb0
[ 54.429049] ---[ end trace fbfaaa6758c4d963 ]---
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Ben Greear wrote:
> I hit this warning in ath9k. Shortly after the machine blew up elsewhere,
> but not sure if this is to blame or not.
>
> Code is slightly modified 3.7.5 (just a few patches, not my normal mass of hackings!)
>
> The warning that hit is the one below:
>
> bf = ath9k_beacon_generate(sc->hw, vif);
> WARN_ON(!bf);
>
> Test case is dual-core Atom system with ath9k NIC, 10 or so virtual stations,
> two virtual APs. Two stations send traffic to each other once everything associates, but
> not sure it got that far when this crash happened.
>
Are these patches in your tree ?
commit 1381559ba48a04ca7c98f1b4c487bd44d0b75db5
Author: Felix Fietkau <[email protected]>
Date: Sun Jan 20 18:51:53 2013 +0100
ath9k: clean up processing of pending tx frames on reset
Dropping packets from aggregation sessions is usually not a good idea, as
it might upset the synchronization of the BlockAck receive window of the
remote node. The use of the retry_tx parameter to reset/tx-drain functions
also seemed a bit arbitrary.
This patch removes this parameter altogether and ensures that pending tx
frames are not dropped for no good reason.
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
commit 3adcf20afb585993ffee24de36d1975f6b26b120
Author: Felix Fietkau <[email protected]>
Date: Wed Jan 9 16:16:54 2013 +0100
ath9k: remove the WARN_ON that triggers if generating a beacon fails
During teardown, mac80211 will not return a new beacon. This is normal and
handled properly in the driver, so there's no need to spam the user with a kernel
warning here.
Cc: [email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Sujith
On 01/29/2013 09:29 PM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> I hit this warning in ath9k. Shortly after the machine blew up elsewhere,
>> but not sure if this is to blame or not.
>>
>> Code is slightly modified 3.7.5 (just a few patches, not my normal mass of hackings!)
>>
>> The warning that hit is the one below:
>>
>> bf = ath9k_beacon_generate(sc->hw, vif);
>> WARN_ON(!bf);
>>
>> Test case is dual-core Atom system with ath9k NIC, 10 or so virtual stations,
>> two virtual APs. Two stations send traffic to each other once everything associates, but
>> not sure it got that far when this crash happened.
>>
>
> Are these patches in your tree ?
They were not. I see the second was queued to stable, should the first one
be a stable candidate as well?
Thanks,
Ben
>
> commit 1381559ba48a04ca7c98f1b4c487bd44d0b75db5
> Author: Felix Fietkau <[email protected]>
> Date: Sun Jan 20 18:51:53 2013 +0100
>
> ath9k: clean up processing of pending tx frames on reset
>
> Dropping packets from aggregation sessions is usually not a good idea, as
> it might upset the synchronization of the BlockAck receive window of the
> remote node. The use of the retry_tx parameter to reset/tx-drain functions
> also seemed a bit arbitrary.
> This patch removes this parameter altogether and ensures that pending tx
> frames are not dropped for no good reason.
>
> Signed-off-by: Felix Fietkau <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
>
> commit 3adcf20afb585993ffee24de36d1975f6b26b120
> Author: Felix Fietkau <[email protected]>
> Date: Wed Jan 9 16:16:54 2013 +0100
>
> ath9k: remove the WARN_ON that triggers if generating a beacon fails
>
> During teardown, mac80211 will not return a new beacon. This is normal and
> handled properly in the driver, so there's no need to spam the user with a kernel
> warning here.
>
> Cc: [email protected]
> Signed-off-by: Felix Fietkau <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
>
>
> Sujith
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Ben Greear wrote:
> They were not. I see the second was queued to stable, should the first one
> be a stable candidate as well?
Sorry, I meant this one:
commit 1adb2e2b5f85023d17eb4f95386a57029df27c88
Author: Felix Fietkau <[email protected]>
Date: Wed Jan 9 16:16:53 2013 +0100
ath9k: fix double-free bug on beacon generate failure
When the next beacon is sent, the ath_buf from the previous run is reused.
If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet
the skb is freed, leading to a double-free on the next beacon tx attempt,
resulting in a system crash.
Cc: [email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Sujith
On 01/29/2013 10:09 PM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> They were not. I see the second was queued to stable, should the first one
>> be a stable candidate as well?
>
> Sorry, I meant this one:
>
> commit 1adb2e2b5f85023d17eb4f95386a57029df27c88
> Author: Felix Fietkau <[email protected]>
> Date: Wed Jan 9 16:16:53 2013 +0100
>
> ath9k: fix double-free bug on beacon generate failure
>
> When the next beacon is sent, the ath_buf from the previous run is reused.
> If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet
> the skb is freed, leading to a double-free on the next beacon tx attempt,
> resulting in a system crash.
>
> Cc: [email protected]
> Signed-off-by: Felix Fietkau <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
I did not have this one applied, and it would explain at least one
crash that I've seen.
I'll apply it (and the other you mentioned) now.
Thanks!
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com