Re: [ath9k-devel] [PATCH RFC] Re: skb_under_panic in ath9k
On 05/26/2013 10:02 AM, Oleksij Rempel wrote: Am 26.05.2013 08:20, schrieb Oleksij Rempel: Am 24.05.2013 10:47, schrieb Marc Kleine-Budde: added ath9k-devel to Cc On 05/23/2013 12:02 AM, Marc Kleine-Budde wrote: Hello, I'm on a kirkwood based armv5 system with an USB attached TP-Link TL-WN821N - Atheros AR7010+AR9287, [1]. the wlan is running in AP mode with hostapd-1.0. The kernel is v3.8.12 from debian (3.8-1-kirkwood #1 Debian 3.8.12-1). The system crashes repeatedly after about one week with the following oops: [633625.401875] skbuff: skb_under_panic: text:bf501028 len:128 put:8 head:d2788800 data:d27887fe tail:0xd278887e end:0xd2788f40 dev:wlan1 [633625.414180] [ cut here ] [633625.418909] kernel BUG at /build/buildd-linux_3.8.12-1-armel-7F6kBx/linux-3.8.12/net/core/skbuff.c:145! [633625.428430] Internal error: Oops - BUG: 0 [#1] ARM [633625.433322] Modules linked in: [...] [633625.583170] CPU: 0Not tainted (3.8-1-kirkwood #1 Debian 3.8.12-1) [633625.589821] PC is at skb_push+0x6c/0x84 [633625.593763] LR is at skb_push+0x6c/0x84 [633625.597707] pc : [c0282990]lr : [c0282990]psr: 2013 [633625.597707] sp : c04c1d50 ip : 08f8 fp : df04ea54 [633625.609404] r10: 0002 r9 : 0008 r8 : df00dca8 [633625.614734] r7 : 0006 r6 : c04410a0 r5 : d278887e r4 : d2788800 [633625.621378] r3 : c04d328c r2 : 2093 r1 : 0001 r0 : 0079 [633625.628015] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [633625.635443] Control: 0005317f Table: 1f224000 DAC: 0017 [633625.641295] Process swapper (pid: 0, stack limit = 0xc04c01b8) [633625.647241] Stack: (0xc04c1d50 to 0xc04c2000) [633625.657414] 1d40: 0008 d2788800 d27887fe d278887e [633625.666101] 1d60: d2788f40 df04e000 df00dc00 df2e0c00 0078 bf501028 df2e0c00 dfba3120 [633625.675025] 1d80: d278882a df04e9a0 bf504110 dfb3ce20 0201 00084502 [633625.683954] 1da0: 0001 df2e0c00 dfba3120 0008 0002 c04c1df4 0001 [633625.693553] 1dc0: 006a bf5058b0 c04c1df4 c04c1e30 dfba2300 c151ff18 df04e9a0 [633625.702041] 1de0: c04c1e30 bf37560c 000c 4288 c04c1e2c c151ff18 006a df2e0c00 [633625.710540] 1e00: dfba2300 006a df04e462 0001 6013 bf375760 [633625.718904] 1e20: 0001 c14c19a0 c14c0460 c04c1e30 c04c1e30 dfba2300 [633625.727374] 1e40: df04e460 c151fc00 de5af200 0002 0002 dfba2300 dfba2308 dfba28a8 [633625.787263] 1e60: c04c1e7c dfba28ac df2e0c00 bf376d58 c0508ae0 012c 0080 [633625.798914] 1e80: 03c66eab c0508ae8 c04d4c68 c04d3494 0006 0100 [633625.810249] 1ea0: c052b3a0 0009 c052b3c0 c0026e2c 0001 0018 c04c c0026644 [633625.818620] 1ec0: c04d8f74 c1484260 1144b25a c04d8f74 0020 c04c1f4c 0013 [633625.831230] 1ee0: fed20200 c04c1f4c 56251311 c04d0420 c0026a2c [633625.842695] 1f00: 2000 c000f28c c004e27c c0271318 2013 c000df94 c04c1f60 6013 [633625.853824] 1f20: 000e32dc 0002404f b5def004 0002404f c04d0698 56251311 [633625.864745] 1f40: c04d0420 0003 c04c1f60 c004e27c c0271318 2013 [633625.875714] 1f60: b5ed22e0 0002404f 0084d405 c04d0698 c04d0698 [633625.886646] 1f80: c04d0420 004b8074 c0270e88 c04d0698 c050918c c0271014 [633625.898317] 1fa0: c04c c0509b28 c04cc1cc c096f0e0 4000 c000f484 c04c8c20 [633625.909787] 1fc0: c04b9650 c0498764 c0498284 c04b9650 [633625.918159] 1fe0: 00053175 c04c8048 c04b964c c04cc1c4 8040 [633625.926557] [c0282990] (skb_push+0x6c/0x84) from [bf501028] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) [633625.937158] [bf501028] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) from [bf504110] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) [633625.949877] [bf504110] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) from [bf5058b0] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) [633625.961458] [bf5058b0] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) from [bf37560c] (__ieee80211_tx+0x210/0x2a8 [mac80211]) [633625.972695] [bf37560c] (__ieee80211_tx+0x210/0x2a8 [mac80211]) from [bf375760] (ieee80211_tx+0xbc/0xc4 [mac80211]) [633625.983816] [bf375760] (ieee80211_tx+0xbc/0xc4 [mac80211]) from [bf376d58] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) [633625.995326] [bf376d58] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) from [c0026e2c] (tasklet_action+0x84/0xcc) [633626.005905] [c0026e2c] (tasklet_action+0x84/0xcc) from [c0026644] (__do_softirq+0xdc/0x204) [633626.014750] [c0026644] (__do_softirq+0xdc/0x204) from [c0026a2c] (irq_exit+0x40/0x8c) [633626.023103] [c0026a2c] (irq_exit+0x40/0x8c) from [c000f28c] (handle_IRQ+0x64/0x84)
Re: [ath9k-devel] skb_under_panic in ath9k
On 05/23/2013 12:02 AM, Marc Kleine-Budde wrote: The system crashes repeatedly after about one week with the following oops: [633625.401875] skbuff: skb_under_panic: text:bf501028 len:128 put:8 head:d2788800 data:d27887fe tail:0xd278887e end:0xd2788f40 dev:wlan1 [633625.414180] [ cut here ] [633625.418909] kernel BUG at /build/buildd-linux_3.8.12-1-armel-7F6kBx/linux-3.8.12/net/core/skbuff.c:145! [633625.428430] Internal error: Oops - BUG: 0 [#1] ARM [633625.433322] Modules linked in: [...] [633625.583170] CPU: 0Not tainted (3.8-1-kirkwood #1 Debian 3.8.12-1) [633625.589821] PC is at skb_push+0x6c/0x84 [633625.593763] LR is at skb_push+0x6c/0x84 [633625.597707] pc : [c0282990]lr : [c0282990]psr: 2013 [633625.597707] sp : c04c1d50 ip : 08f8 fp : df04ea54 [633625.609404] r10: 0002 r9 : 0008 r8 : df00dca8 [633625.614734] r7 : 0006 r6 : c04410a0 r5 : d278887e r4 : d2788800 [633625.621378] r3 : c04d328c r2 : 2093 r1 : 0001 r0 : 0079 [633625.628015] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [633625.635443] Control: 0005317f Table: 1f224000 DAC: 0017 [633625.641295] Process swapper (pid: 0, stack limit = 0xc04c01b8) [633625.647241] Stack: (0xc04c1d50 to 0xc04c2000) [633625.657414] 1d40: 0008 d2788800 d27887fe d278887e [633625.666101] 1d60: d2788f40 df04e000 df00dc00 df2e0c00 0078 bf501028 df2e0c00 dfba3120 [633625.675025] 1d80: d278882a df04e9a0 bf504110 dfb3ce20 0201 00084502 [633625.683954] 1da0: 0001 df2e0c00 dfba3120 0008 0002 c04c1df4 0001 [633625.693553] 1dc0: 006a bf5058b0 c04c1df4 c04c1e30 dfba2300 c151ff18 df04e9a0 [633625.702041] 1de0: c04c1e30 bf37560c 000c 4288 c04c1e2c c151ff18 006a df2e0c00 [633625.710540] 1e00: dfba2300 006a df04e462 0001 6013 bf375760 [633625.718904] 1e20: 0001 c14c19a0 c14c0460 c04c1e30 c04c1e30 dfba2300 [633625.727374] 1e40: df04e460 c151fc00 de5af200 0002 0002 dfba2300 dfba2308 dfba28a8 [633625.787263] 1e60: c04c1e7c dfba28ac df2e0c00 bf376d58 c0508ae0 012c 0080 [633625.798914] 1e80: 03c66eab c0508ae8 c04d4c68 c04d3494 0006 0100 [633625.810249] 1ea0: c052b3a0 0009 c052b3c0 c0026e2c 0001 0018 c04c c0026644 [633625.818620] 1ec0: c04d8f74 c1484260 1144b25a c04d8f74 0020 c04c1f4c 0013 [633625.831230] 1ee0: fed20200 c04c1f4c 56251311 c04d0420 c0026a2c [633625.842695] 1f00: 2000 c000f28c c004e27c c0271318 2013 c000df94 c04c1f60 6013 [633625.853824] 1f20: 000e32dc 0002404f b5def004 0002404f c04d0698 56251311 [633625.864745] 1f40: c04d0420 0003 c04c1f60 c004e27c c0271318 2013 [633625.875714] 1f60: b5ed22e0 0002404f 0084d405 c04d0698 c04d0698 [633625.886646] 1f80: c04d0420 004b8074 c0270e88 c04d0698 c050918c c0271014 [633625.898317] 1fa0: c04c c0509b28 c04cc1cc c096f0e0 4000 c000f484 c04c8c20 [633625.909787] 1fc0: c04b9650 c0498764 c0498284 c04b9650 [633625.918159] 1fe0: 00053175 c04c8048 c04b964c c04cc1c4 8040 [633625.926557] [c0282990] (skb_push+0x6c/0x84) from [bf501028] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) [633625.937158] [bf501028] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) from [bf504110] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) [633625.949877] [bf504110] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) from [bf5058b0] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) [633625.961458] [bf5058b0] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) from [bf37560c] (__ieee80211_tx+0x210/0x2a8 [mac80211]) [633625.972695] [bf37560c] (__ieee80211_tx+0x210/0x2a8 [mac80211]) from [bf375760] (ieee80211_tx+0xbc/0xc4 [mac80211]) [633625.983816] [bf375760] (ieee80211_tx+0xbc/0xc4 [mac80211]) from [bf376d58] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) [633625.995326] [bf376d58] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) from [c0026e2c] (tasklet_action+0x84/0xcc) [633626.005905] [c0026e2c] (tasklet_action+0x84/0xcc) from [c0026644] (__do_softirq+0xdc/0x204) [633626.014750] [c0026644] (__do_softirq+0xdc/0x204) from [c0026a2c] (irq_exit+0x40/0x8c) [633626.023103] [c0026a2c] (irq_exit+0x40/0x8c) from [c000f28c] (handle_IRQ+0x64/0x84) [633626.031193] [c000f28c] (handle_IRQ+0x64/0x84) from [c000df94] (__irq_svc+0x34/0x78) [633626.039412] [c000df94] (__irq_svc+0x34/0x78) from [c0271318] (cpuidle_wrap_enter+0x54/0x9c) [633626.048331] [c0271318] (cpuidle_wrap_enter+0x54/0x9c) from [c0270e88] (cpuidle_enter_state+0x14/0x68) [633626.058162] [c0270e88] (cpuidle_enter_state+0x14/0x68) from [c0271014]
Re: [ath9k-devel] AR9287; WiFi AP Mode - Increase interbeacon duration of 100ms
Thanks Ben for this information. Can you please let me know where I can change the beacon time from 100ms to 250ms? Thanks regards Sandeep. From: Ben Greear gree...@candelatech.com To: sandeep suresh sandeep.sur...@yahoo.co.in Cc: Adrian Chadd adr...@freebsd.org; ath9k-devel ath9k-de...@venema.h4ckr.net; linux-wirel...@vger.kernel.org linux-wirel...@vger.kernel.org Sent: Monday, 3 June 2013 9:46 PM Subject: Re: [ath9k-devel] AR9287; WiFi AP Mode - Increase interbeacon duration of 100ms On 06/03/2013 03:15 AM, sandeep suresh wrote: Hello All, Gentle reminder; really will be greatful, if you can give me some directions on this, Please. Regards Sandeep *From:* sandeep suresh sandeep.sur...@yahoo.co.in *To:* Adrian Chadd adr...@freebsd.org; ath9k-devel ath9k-devel@lists.ath9k.org *Cc:* linux-wirel...@vger.kernel.org linux-wirel...@vger.kernel.org *Sent:* Monday, 27 May 2013 1:40 PM *Subject:* AR9287; WiFi AP Mode - Increase interbeacon duration of 100ms Hello All, This is regarding the inter beacon timing for AR9287 WiFi module when configured in WiFi Access Point mode. In this mode, the beacons are generated every 100ms by the WiFi AP. I have the following questions: 1. As per documentation available on the internet, the minimum inter beacon timing is 100ms. But can we increase the the inter beacon timing above this value? say 250ms, 500ms etc 2. As per standard, does increase in inter beacon time 100ms, have any impact on the WiFi Clients connected to AR9287 WiFi AP? Even though I might test with some WiFi clients without any side effects but there may be some WiFi clients (which I might be unaware of )that might not work. 3. Has anyone attempted to do this? Please let me know if you have any observations on this? We have been using a default of 250ms beacon timer for years in our ath9k APs. Seems to work just fine, but we mostly use them for internal testing with other ath9k systems acting as the stations. Thanks, Ben Thanks regards Sandeep ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com/___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k_htc: fix skb_under_panic error
This error seems to be really rare, and we do not know real couse of it.
But, in any case, we should check size of head before reducing it.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
Reported-by: Marc Kleine-Budde m...@blackshift.org
---
drivers/net/wireless/ath/ath9k/htc_hst.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.c
b/drivers/net/wireless/ath/ath9k/htc_hst.c
index aac4a40..2901351 100644
--- a/drivers/net/wireless/ath/ath9k/htc_hst.c
+++ b/drivers/net/wireless/ath/ath9k/htc_hst.c
@@ -26,6 +26,12 @@ static int htc_issue_send(struct htc_target *target, struct
sk_buff* skb,
struct htc_endpoint *endpoint = target-endpoint[epid];
int status;
+ if (skb_headroom(skb) len
+ pskb_expand_head(skb, len, 0, GFP_ATOMIC)) {
+ dev_err(target-dev, Unable to expand headrom to %d\n, len);
+ return -ENOMEM;
+ }
+
hdr = (struct htc_frame_hdr *)
skb_push(skb, sizeof(struct htc_frame_hdr));
hdr-endpoint_id = epid;
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] 4.9GHz and 5.8GHz regulatory entries?
Hi all, I'm hacking at the support needed for 4.9 and 5.8GHz NICs in FreeBSD. Well, there's support for them (and they work!) but I'm doing up some regulatory entries for them. So, has anyone looked at adding 4.9 and 5.8GHz regulatory domain entries to db.txt in Linux, for regulatory domains that allow them to be used unlicenced? Thanks, Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] 4.9GHz and 5.8GHz regulatory entries?
Hi Adrian, I've done a modification for 5.8 ghz and some outdoor tests usin ubnt-hardware. Joe Am Mittwoch, 5. Juni 2013 schrieb Adrian Chadd : Hi all, I'm hacking at the support needed for 4.9 and 5.8GHz NICs in FreeBSD. Well, there's support for them (and they work!) but I'm doing up some regulatory entries for them. So, has anyone looked at adding 4.9 and 5.8GHz regulatory domain entries to db.txt in Linux, for regulatory domains that allow them to be used unlicenced? Thanks, Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org javascript:; https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
