* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers @ 2014-03-29 10:17 Harshal Vora 2014-03-30 7:31 ` Oleksij Rempel 0 siblings, 1 reply; 11+ messages in thread From: Harshal Vora @ 2014-03-29 10:17 UTC (permalink / raw) To: ath9k-devel Hi, We are running tp link wn721n usb wifi adapter with atheros 9271 chipset on raspberry pi using kernel version 3.6.11 We run the physical interface wlan0 in adhoc mode and also create a virtual interface wlan0-mon0 from wlan0 which runs in monitor mode. The USB chipset suddenly hangs or shuts down after running for sometime. Sometimes it runs for few minutes, sometimes for hours before this happens. Sometimes this happens when a new node enters the adhoc network. We are using babel on top of ad-hoc network to create a mesh like functionality. Below are the logs from one of the device. Also when I try to unload the driver using modprobe -r, it looks like panic mode. We are not using power save mode. Mar 28 15:45:45 localhost kernel: [18268.650000] ath: phy0: Unable to reset channel (2452 Mhz) reset status -22 Mar 28 15:45:45 localhost kernel: [18268.670000] ath: phy0: Unable to set channel Mar 28 15:45:46 localhost kernel: [18269.180000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:45:46 localhost kernel: [18269.180000] ath: phy0: Chip reset failed Mar 28 15:45:46 localhost kernel: [18269.190000] ath: phy0: Unable to reset channel (2457 Mhz) reset status -22 Mar 28 15:45:46 localhost kernel: [18269.210000] ath: phy0: Unable to set channel Mar 28 15:45:46 localhost kernel: [18269.720000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:45:46 localhost kernel: [18269.720000] ath: phy0: Chip reset failed Mar 28 15:45:46 localhost kernel: [18269.730000] ath: phy0: Unable to reset channel (2462 Mhz) reset status -22 Mar 28 15:45:46 localhost kernel: [18269.750000] ath: phy0: Unable to set channel Mar 28 15:45:47 localhost kernel: [18270.250000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:45:47 localhost kernel: [18270.260000] ath: phy0: Chip reset failed Mar 28 15:45:47 localhost kernel: [18270.270000] ath: phy0: Unable to reset channel (2467 Mhz) reset status -22 Mar 28 15:45:47 localhost kernel: [18270.280000] ath: phy0: Unable to set channel Mar 28 15:45:47 localhost kernel: [18270.790000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:45:47 localhost kernel: [18270.800000] ath: phy0: Chip reset failed Mar 28 15:45:48 localhost kernel: [18270.810000] ath: phy0: Unable to reset channel (2472 Mhz) reset status -22 Mar 28 15:45:48 localhost kernel: [18270.820000] ath: phy0: Unable to set channel Mar 28 15:45:48 localhost kernel: [18271.330000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:45:48 localhost kernel: [18271.340000] ath: phy0: Chip reset failed Mar 28 15:45:48 localhost kernel: [18271.350000] ath: phy0: Unable to reset channel (2484 Mhz) reset status -22 Mar 28 15:45:48 localhost kernel: [18271.360000] ath: phy0: Unable to set channel Mar 28 15:45:49 localhost kernel: [18271.870000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:45:49 localhost kernel: [18271.880000] ath: phy0: Chip reset failed Mar 28 15:45:49 localhost kernel: [18271.890000] ath: phy0: Unable to reset channel (2412 Mhz) reset status -22 Mar 28 15:45:49 localhost kernel: [18271.900000] ath: phy0: Unable to set channel Mar 28 15:45:49 localhost kernel: [18272.080000] wlan1: expiring inactive STA c0:4a:00:18:db:79 Mar 28 15:45:49 localhost kernel: [18272.080000] wlan1: moving STA c0:4a:00:18:db:79 to state 3 Mar 28 15:45:49 localhost kernel: [18272.090000] wlan1: moving STA c0:4a:00:18:db:79 to state 2 Mar 28 15:45:49 localhost kernel: [18272.090000] ath: phy0: Unable to remove station entry for: c0:4a:00:18:db:79 Mar 28 15:45:49 localhost kernel: [18272.110000] wlan1: moving STA c0:4a:00:18:db:79 to state 1 Mar 28 15:45:49 localhost kernel: [18272.110000] ieee80211 phy0: Removed STA c0:4a:00:18:db:79 Mar 28 15:45:49 localhost kernel: [18272.120000] ieee80211 phy0: Destroyed STA c0:4a:00:18:db:79 Mar 28 15:45:49 localhost kernel: [18272.120000] wlan1: expiring inactive STA 10:fe:ed:13:f2:10 Mar 28 15:45:49 localhost kernel: [18272.130000] wlan1: moving STA 10:fe:ed:13:f2:10 to state 3 Mar 28 15:45:49 localhost kernel: [18272.130000] wlan1: moving STA 10:fe:ed:13:f2:10 to state 2 Mar 28 15:45:49 localhost kernel: [18272.140000] ath: phy0: Unable to remove station entry for: 10:fe:ed:13:f2:10 Mar 28 15:45:49 localhost kernel: [18272.150000] wlan1: moving STA 10:fe:ed:13:f2:10 to state 1 Mar 28 15:45:49 localhost kernel: [18272.160000] ieee80211 phy0: Removed STA 10:fe:ed:13:f2:10 Mar 28 15:45:49 localhost kernel: [18272.160000] ieee80211 phy0: Destroyed STA 10:fe:ed:13:f2:10 Mar 28 15:45:49 localhost kernel: [18272.170000] wlan1: expiring inactive STA 64:66:b3:18:c9:79 Mar 28 15:45:49 localhost kernel: [18272.170000] wlan1: moving STA 64:66:b3:18:c9:79 to state 3 Mar 28 15:45:49 localhost kernel: [18272.180000] wlan1: moving STA 64:66:b3:18:c9:79 to state 2 Mar 28 15:45:49 localhost kernel: [18272.180000] ath: phy0: Unable to remove station entry for: 64:66:b3:18:c9:79 Mar 28 15:45:49 localhost kernel: [18272.200000] wlan1: moving STA 64:66:b3:18:c9:79 to state 1 Mar 28 15:45:49 localhost kernel: [18272.200000] ieee80211 phy0: Removed STA 64:66:b3:18:c9:79 Mar 28 15:45:49 localhost kernel: [18272.210000] ieee80211 phy0: Destroyed STA 64:66:b3:18:c9:79 Mar 28 15:45:49 localhost kernel: [18272.210000] wlan1: expiring inactive STA 00:1f:3c:0b:f0:5c Mar 28 15:45:49 localhost kernel: [18272.220000] wlan1: moving STA 00:1f:3c:0b:f0:5c to state 3 Mar 28 15:45:49 localhost kernel: [18272.220000] wlan1: moving STA 00:1f:3c:0b:f0:5c to state 2 Mar 28 15:45:49 localhost kernel: [18272.230000] ath: phy0: Unable to remove station entry for: 00:1f:3c:0b:f0:5c Mar 28 15:45:49 localhost kernel: [18272.240000] wlan1: moving STA 00:1f:3c:0b:f0:5c to state 1 Mar 28 15:45:49 localhost kernel: [18272.250000] ieee80211 phy0: Removed STA 00:1f:3c:0b:f0:5c Mar 28 15:45:49 localhost kernel: [18272.250000] ieee80211 phy0: Destroyed STA 00:1f:3c:0b:f0:5c Mar 28 15:45:49 localhost kernel: [18272.260000] wlan1: expiring inactive STA 10:fe:ed:14:d5:c4 Mar 28 15:45:49 localhost kernel: [18272.260000] wlan1: moving STA 10:fe:ed:14:d5:c4 to state 3 Mar 28 15:45:49 localhost kernel: [18272.270000] wlan1: moving STA 10:fe:ed:14:d5:c4 to state 2 Mar 28 15:45:49 localhost kernel: [18272.270000] ath: phy0: Unable to remove station entry for: 10:fe:ed:14:d5:c4 Mar 28 15:45:49 localhost kernel: [18272.280000] wlan1: moving STA 10:fe:ed:14:d5:c4 to state 1 Mar 28 15:45:49 localhost kernel: [18272.290000] ieee80211 phy0: Removed STA 10:fe:ed:14:d5:c4 Mar 28 15:45:49 localhost kernel: [18272.290000] ieee80211 phy0: Destroyed STA 10:fe:ed:14:d5:c4 Mar 28 15:46:19 localhost kernel: [18302.080000] wlan1: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge) Mar 28 15:46:19 localhost kernel: [18302.770000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:46:19 localhost kernel: [18302.780000] ath: phy0: Chip reset failed Mar 28 15:46:19 localhost kernel: [18302.780000] ath: phy0: Unable to reset channel (2412 Mhz) reset status -22 Mar 28 15:46:19 localhost kernel: [18302.800000] ath: phy0: Unable to set channel Mar 28 15:46:20 localhost kernel: [18303.310000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:46:20 localhost kernel: [18303.310000] ath: phy0: Chip reset failed Mar 28 15:46:20 localhost kernel: [18303.320000] ath: phy0: Unable to reset channel (2417 Mhz) reset status -22 Mar 28 15:46:20 localhost kernel: [18303.330000] ath: phy0: Unable to set channel Mar 28 15:46:20 localhost ntpdate[12205]: adjust time server 199.102.46.73 offset -0.001353 sec Mar 28 15:46:21 localhost kernel: [18303.850000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:46:21 localhost kernel: [18303.860000] ath: phy0: Chip reset failed Mar 28 15:46:21 localhost kernel: [18303.870000] ath: phy0: Unable to reset channel (2422 Mhz) reset status -22 Mar 28 15:46:21 localhost kernel: [18303.880000] ath: phy0: Unable to set channel Mar 28 15:46:21 localhost kernel: [18304.390000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 28 15:46:21 localhost kernel: [18304.400000] ath: phy0: Chip reset failed Logs after modprobe -r ath9k_htc Mar 29 07:05:21 localhost kernel: [73443.950000] ath: phy0: Failed to wakeup in 500us Mar 29 07:05:21 localhost kernel: [73443.960000] ------------[ cut here ]------------ Mar 29 07:05:21 localhost kernel: [73443.970000] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:2079 ath9k_hw_setpower+0x1fc/0x600 [ath9k_hw]() Mar 29 07:05:21 localhost kernel: [73443.980000] Modules linked in: nfnetlink_log nfnetlink xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables ath9k_htc(-) mac80211 led_class ath9k_common ath9k_hw ath 8192cu Mar 29 07:05:21 localhost kernel: [73444.000000] Backtrace: Mar 29 07:05:21 localhost kernel: [73444.000000] [<c0012a40>] (dump_backtrace+0x0/0x10c) from [<c053b610>] (dump_stack+0x18/0x1c) Mar 29 07:05:21 localhost kernel: [73444.010000] r6:bf0bad38 r5:00000009 r4:00000000 r3:c079a4e0 Mar 29 07:05:21 localhost kernel: [73444.010000] [<c053b5f8>] (dump_stack+0x0/0x1c) from [<c00307c0>] (warn_slowpath_common+0x54/0x6c) Mar 29 07:05:21 localhost kernel: [73444.020000] [<c003076c>] (warn_slowpath_common+0x0/0x6c) from [<c00307fc>] (warn_slowpath_null+0x24/0x2c) Mar 29 07:05:21 localhost kernel: [73444.030000] r8:0000704c r7:00020044 r6:00000000 r5:00000000 r4:bf10c339 Mar 29 07:05:21 localhost kernel: [73444.030000] r3:00000009 Mar 29 07:05:21 localhost kernel: [73444.040000] [<c00307d8>] (warn_slowpath_null+0x0/0x2c) from [<bf0bad38>] (ath9k_hw_setpower+0x1fc/0x600 [ath9k_hw]) Mar 29 07:05:21 localhost kernel: [73444.050000] [<bf0bab3c>] (ath9k_hw_setpower+0x0/0x600 [ath9k_hw]) from [<bf18cd6c>] (ath9k_htc_ps_wakeup+0x4c/0x50 [ath9k_htc]) Mar 29 07:05:21 localhost kernel: [73444.060000] [<bf18cd20>] (ath9k_htc_ps_wakeup+0x0/0x50 [ath9k_htc]) from [<bf18d4fc>] (ath9k_htc_configure_filter+0x78/0xd8 [ath9k_htc]) Mar 29 07:05:21 localhost kernel: [73444.070000] r5:ee7a18d8 r4:ee7a10a0 Mar 29 07:05:21 localhost kernel: [73444.070000] [<bf18d484>] (ath9k_htc_configure_filter+0x0/0xd8 [ath9k_htc]) from [<bf132048>] (ieee80211_configure_filter+0x158/0x1b8 [mac80211]) Mar 29 07:05:21 localhost kernel: [73444.090000] r6:ee7a0300 r5:00000000 r4:00000000 r3:bf18d484 Mar 29 07:05:21 localhost kernel: [73444.090000] [<bf131ef0>] (ieee80211_configure_filter+0x0/0x1b8 [mac80211]) from [<bf13e69c>] (ieee80211_do_stop+0x174/0x658 [mac80211]) Mar 29 07:05:21 localhost kernel: [73444.100000] r8:00000001 r7:ed64a000 r6:ee7a0300 r5:00000004 r4:000001d0 Mar 29 07:05:21 localhost kernel: [73444.110000] [<bf13e528>] (ieee80211_do_stop+0x0/0x658 [mac80211]) from [<bf13eb98>] (ieee80211_stop+0x18/0x20 [mac80211]) Mar 29 07:05:21 localhost kernel: [73444.120000] [<bf13eb80>] (ieee80211_stop+0x0/0x20 [mac80211]) from [<c03fd2a4>] (__dev_close_many+0x90/0xd4) Mar 29 07:05:21 localhost kernel: [73444.130000] [<c03fd214>] (__dev_close_many+0x0/0xd4) from [<c03fd3bc>] (dev_close_many+0x8c/0xf8) Mar 29 07:05:21 localhost kernel: [73444.140000] r5:ed64bdc0 r4:ed64bd24 Mar 29 07:05:21 localhost kernel: [73444.140000] [<c03fd330>] (dev_close_many+0x0/0xf8) from [<c03fd4ec>] (rollback_registered_many+0xc4/0x24c) Mar 29 07:05:21 localhost kernel: [73444.150000] r6:ed64bdc0 r5:ee88c000 r4:ed64bd24 Mar 29 07:05:21 localhost kernel: [73444.150000] [<c03fd428>] (rollback_registered_many+0x0/0x24c) from [<c03fd694>] (unregister_netdevice_many+0x20/0x68) Mar 29 07:05:21 localhost kernel: [73444.160000] [<c03fd674>] (unregister_netdevice_many+0x0/0x68) from [<bf13e24c>] (ieee80211_remove_interfaces+0x98/0xd8 [mac80211]) Mar 29 07:05:21 localhost kernel: [73444.170000] r4:ee7a0918 r3:00000001 Mar 29 07:05:21 localhost kernel: [73444.180000] [<bf13e1b4>] (ieee80211_remove_interfaces+0x0/0xd8 [mac80211]) from [<bf131118>] (ieee80211_unregister_hw+0x48/0xec [mac80211]) Mar 29 07:05:21 localhost kernel: [73444.190000] [<bf1310d0>] (ieee80211_unregister_hw+0x0/0xec [mac80211]) from [<bf191094>] (ath9k_htc_disconnect_device+0x58/0x98 [ath9k_htc]) Mar 29 07:05:21 localhost kernel: [73444.200000] r5:ee5fcc00 r4:ee7a10a0 Mar 29 07:05:21 localhost kernel: [73444.200000] [<bf19103c>] (ath9k_htc_disconnect_device+0x0/0x98 [ath9k_htc]) from [<bf1877d4>] (ath9k_htc_hw_deinit+0x18/0x1c [ath9k_htc]) Mar 29 07:05:21 localhost kernel: [73444.220000] r6:ef3ee468 r5:ef3e0220 r4:ee917540 r3:ee5c1080 Mar 29 07:05:21 localhost kernel: [73444.220000] [<bf1877bc>] (ath9k_htc_hw_deinit+0x0/0x1c [ath9k_htc]) from [<bf188de8>] (ath9k_hif_usb_disconnect+0x58/0x12c [ath9k_htc]) Mar 29 07:05:21 localhost kernel: [73444.230000] [<bf188d90>] (ath9k_hif_usb_disconnect+0x0/0x12c [ath9k_htc]) from [<c032f188>] (usb_unbind_interface+0x44/0x118) Mar 29 07:05:21 localhost kernel: [73444.240000] r8:c000f204 r7:ef3ee400 r6:ef3e0200 r5:bf198d3c r4:ef3e0220 Mar 29 07:05:21 localhost kernel: [73444.250000] [<c032f144>] (usb_unbind_interface+0x0/0x118) from [<c02c2864>] (__device_release_driver+0x78/0xc8) Mar 29 07:05:21 localhost kernel: [73444.260000] r7:bf198d3c r6:ef3e0254 r5:bf198d3c r4:ef3e0220 Mar 29 07:05:21 localhost kernel: [73444.260000] [<c02c27ec>] (__device_release_driver+0x0/0xc8) from [<c02c32ec>] (driver_detach+0xe4/0xf0) Mar 29 07:05:21 localhost kernel: [73444.270000] r5:ed64a000 r4:ef3e0220 Mar 29 07:05:21 localhost kernel: [73444.270000] [<c02c3208>] (driver_detach+0x0/0xf0) from [<c02c2628>] (bus_remove_driver+0x94/0xfc) Mar 29 07:05:21 localhost kernel: [73444.280000] r7:00000080 r6:c07b7abc r5:bf198d3c r4:00000000 Mar 29 07:05:21 localhost kernel: [73444.290000] [<c02c2594>] (bus_remove_driver+0x0/0xfc) from [<c02c3908>] (driver_unregister+0x58/0x78) Mar 29 07:05:21 localhost kernel: [73444.300000] r6:ed64a000 r5:bf198d3c r4:00000000 r3:00000008 Mar 29 07:05:21 localhost kernel: [73444.300000] [<c02c38b0>] (driver_unregister+0x0/0x78) from [<c032eba8>] (usb_deregister+0x64/0xf8) Mar 29 07:05:21 localhost kernel: [73444.310000] r5:bf198d0c r4:bf198d3c Mar 29 07:05:21 localhost kernel: [73444.310000] [<c032eb44>] (usb_deregister+0x0/0xf8) from [<bf18971c>] (ath9k_hif_usb_exit+0x14/0x1c [ath9k_htc]) Mar 29 07:05:21 localhost kernel: [73444.320000] r8:c000f204 r7:00000080 r6:ed64a000 r5:01ccc788 r4:bf199690 Mar 29 07:05:21 localhost kernel: [73444.330000] r3:bf1961c4 Mar 29 07:05:21 localhost kernel: [73444.330000] [<bf189708>] (ath9k_hif_usb_exit+0x0/0x1c [ath9k_htc]) from [<bf1961d4>] (ath9k_htc_exit+0x10/0x20 [ath9k_htc]) Mar 29 07:05:21 localhost kernel: [73444.340000] [<bf1961c4>] (ath9k_htc_exit+0x0/0x20 [ath9k_htc]) from [<c00698e0>] (sys_delete_module+0x1e4/0x2a0) Mar 29 07:05:21 localhost kernel: [73444.350000] [<c00696fc>] (sys_delete_module+0x0/0x2a0) from [<c000f080>] (ret_fast_syscall+0x0/0x30) Mar 29 07:05:21 localhost kernel: [73444.360000] r7:00000081 r6:00000001 r5:beda2a48 r4:01ccc538 Mar 29 07:05:21 localhost kernel: [73444.360000] ---[ end trace 6bff6510f53a402b ]--- Mar 29 07:05:21 localhost kernel: [73444.400000] ath: phy0: Failed to wakeup in 500us Mar 29 07:05:21 localhost kernel: [73444.410000] ath: phy0: Unable to remove interface at idx: 0 Mar 29 07:05:21 localhost kernel: [73444.460000] ath: phy0: Failed to wakeup in 500us Mar 29 07:05:21 localhost kernel: [73444.500000] ath: phy0: Failed to wakeup in 500us Mar 29 07:05:21 localhost kernel: [73444.540000] ath: phy0: Failed to wakeup in 500us Mar 29 07:05:22 localhost kernel: [73445.060000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 29 07:05:22 localhost kernel: [73445.570000] ath: phy0: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 Mar 29 07:05:22 localhost kernel: [73445.590000] device wlan1-mon0 left promiscuous mode ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-03-29 10:17 [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers Harshal Vora @ 2014-03-30 7:31 ` Oleksij Rempel 2014-03-31 5:41 ` Harshal Vora 0 siblings, 1 reply; 11+ messages in thread From: Oleksij Rempel @ 2014-03-30 7:31 UTC (permalink / raw) To: ath9k-devel Am 29.03.2014 11:17, schrieb Harshal Vora: > Hi, > > We are running tp link wn721n usb wifi adapter with atheros 9271 chipset > on raspberry pi using kernel version 3.6.11 > We run the physical interface wlan0 in adhoc mode and also create a > virtual interface wlan0-mon0 from wlan0 which runs in monitor mode. > The USB chipset suddenly hangs or shuts down after running for sometime. > Sometimes it runs for few minutes, sometimes for hours before this happens. > Sometimes this happens when a new node enters the adhoc network. > We are using babel on top of ad-hoc network to create a mesh like > functionality. > > Below are the logs from one of the device. Also when I try to unload the > driver using modprobe -r, it looks like panic mode. > We are not using power save mode. > > > Mar 28 15:45:45 localhost kernel: [18268.650000] ath: phy0: Unable to > reset channel (2452 Mhz) reset status -22 > Mar 28 15:45:45 localhost kernel: [18268.670000] ath: phy0: Unable to > set channel > Mar 28 15:45:46 localhost kernel: [18269.180000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:45:46 localhost kernel: [18269.180000] ath: phy0: Chip reset > failed > Mar 28 15:45:46 localhost kernel: [18269.190000] ath: phy0: Unable to > reset channel (2457 Mhz) reset status -22 > Mar 28 15:45:46 localhost kernel: [18269.210000] ath: phy0: Unable to > set channel > Mar 28 15:45:46 localhost kernel: [18269.720000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:45:46 localhost kernel: [18269.720000] ath: phy0: Chip reset > failed > Mar 28 15:45:46 localhost kernel: [18269.730000] ath: phy0: Unable to > reset channel (2462 Mhz) reset status -22 > Mar 28 15:45:46 localhost kernel: [18269.750000] ath: phy0: Unable to > set channel > Mar 28 15:45:47 localhost kernel: [18270.250000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:45:47 localhost kernel: [18270.260000] ath: phy0: Chip reset > failed > Mar 28 15:45:47 localhost kernel: [18270.270000] ath: phy0: Unable to > reset channel (2467 Mhz) reset status -22 > Mar 28 15:45:47 localhost kernel: [18270.280000] ath: phy0: Unable to > set channel > Mar 28 15:45:47 localhost kernel: [18270.790000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:45:47 localhost kernel: [18270.800000] ath: phy0: Chip reset > failed > Mar 28 15:45:48 localhost kernel: [18270.810000] ath: phy0: Unable to > reset channel (2472 Mhz) reset status -22 > Mar 28 15:45:48 localhost kernel: [18270.820000] ath: phy0: Unable to > set channel > Mar 28 15:45:48 localhost kernel: [18271.330000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:45:48 localhost kernel: [18271.340000] ath: phy0: Chip reset > failed > Mar 28 15:45:48 localhost kernel: [18271.350000] ath: phy0: Unable to > reset channel (2484 Mhz) reset status -22 > Mar 28 15:45:48 localhost kernel: [18271.360000] ath: phy0: Unable to > set channel > Mar 28 15:45:49 localhost kernel: [18271.870000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:45:49 localhost kernel: [18271.880000] ath: phy0: Chip reset > failed > Mar 28 15:45:49 localhost kernel: [18271.890000] ath: phy0: Unable to > reset channel (2412 Mhz) reset status -22 > Mar 28 15:45:49 localhost kernel: [18271.900000] ath: phy0: Unable to > set channel > Mar 28 15:45:49 localhost kernel: [18272.080000] wlan1: expiring > inactive STA c0:4a:00:18:db:79 > Mar 28 15:45:49 localhost kernel: [18272.080000] wlan1: moving STA > c0:4a:00:18:db:79 to state 3 > Mar 28 15:45:49 localhost kernel: [18272.090000] wlan1: moving STA > c0:4a:00:18:db:79 to state 2 > Mar 28 15:45:49 localhost kernel: [18272.090000] ath: phy0: Unable to > remove station entry for: c0:4a:00:18:db:79 > Mar 28 15:45:49 localhost kernel: [18272.110000] wlan1: moving STA > c0:4a:00:18:db:79 to state 1 > Mar 28 15:45:49 localhost kernel: [18272.110000] ieee80211 phy0: Removed > STA c0:4a:00:18:db:79 > Mar 28 15:45:49 localhost kernel: [18272.120000] ieee80211 phy0: > Destroyed STA c0:4a:00:18:db:79 > Mar 28 15:45:49 localhost kernel: [18272.120000] wlan1: expiring > inactive STA 10:fe:ed:13:f2:10 > Mar 28 15:45:49 localhost kernel: [18272.130000] wlan1: moving STA > 10:fe:ed:13:f2:10 to state 3 > Mar 28 15:45:49 localhost kernel: [18272.130000] wlan1: moving STA > 10:fe:ed:13:f2:10 to state 2 > Mar 28 15:45:49 localhost kernel: [18272.140000] ath: phy0: Unable to > remove station entry for: 10:fe:ed:13:f2:10 > Mar 28 15:45:49 localhost kernel: [18272.150000] wlan1: moving STA > 10:fe:ed:13:f2:10 to state 1 > Mar 28 15:45:49 localhost kernel: [18272.160000] ieee80211 phy0: Removed > STA 10:fe:ed:13:f2:10 > Mar 28 15:45:49 localhost kernel: [18272.160000] ieee80211 phy0: > Destroyed STA 10:fe:ed:13:f2:10 > Mar 28 15:45:49 localhost kernel: [18272.170000] wlan1: expiring > inactive STA 64:66:b3:18:c9:79 > Mar 28 15:45:49 localhost kernel: [18272.170000] wlan1: moving STA > 64:66:b3:18:c9:79 to state 3 > Mar 28 15:45:49 localhost kernel: [18272.180000] wlan1: moving STA > 64:66:b3:18:c9:79 to state 2 > Mar 28 15:45:49 localhost kernel: [18272.180000] ath: phy0: Unable to > remove station entry for: 64:66:b3:18:c9:79 > Mar 28 15:45:49 localhost kernel: [18272.200000] wlan1: moving STA > 64:66:b3:18:c9:79 to state 1 > Mar 28 15:45:49 localhost kernel: [18272.200000] ieee80211 phy0: Removed > STA 64:66:b3:18:c9:79 > Mar 28 15:45:49 localhost kernel: [18272.210000] ieee80211 phy0: > Destroyed STA 64:66:b3:18:c9:79 > Mar 28 15:45:49 localhost kernel: [18272.210000] wlan1: expiring > inactive STA 00:1f:3c:0b:f0:5c > Mar 28 15:45:49 localhost kernel: [18272.220000] wlan1: moving STA > 00:1f:3c:0b:f0:5c to state 3 > Mar 28 15:45:49 localhost kernel: [18272.220000] wlan1: moving STA > 00:1f:3c:0b:f0:5c to state 2 > Mar 28 15:45:49 localhost kernel: [18272.230000] ath: phy0: Unable to > remove station entry for: 00:1f:3c:0b:f0:5c > Mar 28 15:45:49 localhost kernel: [18272.240000] wlan1: moving STA > 00:1f:3c:0b:f0:5c to state 1 > Mar 28 15:45:49 localhost kernel: [18272.250000] ieee80211 phy0: Removed > STA 00:1f:3c:0b:f0:5c > Mar 28 15:45:49 localhost kernel: [18272.250000] ieee80211 phy0: > Destroyed STA 00:1f:3c:0b:f0:5c > Mar 28 15:45:49 localhost kernel: [18272.260000] wlan1: expiring > inactive STA 10:fe:ed:14:d5:c4 > Mar 28 15:45:49 localhost kernel: [18272.260000] wlan1: moving STA > 10:fe:ed:14:d5:c4 to state 3 > Mar 28 15:45:49 localhost kernel: [18272.270000] wlan1: moving STA > 10:fe:ed:14:d5:c4 to state 2 > Mar 28 15:45:49 localhost kernel: [18272.270000] ath: phy0: Unable to > remove station entry for: 10:fe:ed:14:d5:c4 > Mar 28 15:45:49 localhost kernel: [18272.280000] wlan1: moving STA > 10:fe:ed:14:d5:c4 to state 1 > Mar 28 15:45:49 localhost kernel: [18272.290000] ieee80211 phy0: Removed > STA 10:fe:ed:14:d5:c4 > Mar 28 15:45:49 localhost kernel: [18272.290000] ieee80211 phy0: > Destroyed STA 10:fe:ed:14:d5:c4 > > > Mar 28 15:46:19 localhost kernel: [18302.080000] wlan1: No active IBSS > STAs - trying to scan for other IBSS networks with same SSID (merge) > Mar 28 15:46:19 localhost kernel: [18302.770000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:46:19 localhost kernel: [18302.780000] ath: phy0: Chip reset > failed > Mar 28 15:46:19 localhost kernel: [18302.780000] ath: phy0: Unable to > reset channel (2412 Mhz) reset status -22 > Mar 28 15:46:19 localhost kernel: [18302.800000] ath: phy0: Unable to > set channel > Mar 28 15:46:20 localhost kernel: [18303.310000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:46:20 localhost kernel: [18303.310000] ath: phy0: Chip reset > failed > Mar 28 15:46:20 localhost kernel: [18303.320000] ath: phy0: Unable to > reset channel (2417 Mhz) reset status -22 > Mar 28 15:46:20 localhost kernel: [18303.330000] ath: phy0: Unable to > set channel > Mar 28 15:46:20 localhost ntpdate[12205]: adjust time server > 199.102.46.73 offset -0.001353 sec > Mar 28 15:46:21 localhost kernel: [18303.850000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:46:21 localhost kernel: [18303.860000] ath: phy0: Chip reset > failed > Mar 28 15:46:21 localhost kernel: [18303.870000] ath: phy0: Unable to > reset channel (2422 Mhz) reset status -22 > Mar 28 15:46:21 localhost kernel: [18303.880000] ath: phy0: Unable to > set channel > Mar 28 15:46:21 localhost kernel: [18304.390000] ath: phy0: timeout > (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 > Mar 28 15:46:21 localhost kernel: [18304.400000] ath: phy0: Chip reset > failed Hi Harshal, please, use latest wireless-testing.git and this firmware branch: https://github.com/olerem/open-ath9k-htc-firmware/tree/testing Latest kernel git has lots of changes in ath9k_htc code. And it is able to catch oops pattern from firmware. Latest firmware branch, is able to restart on some crashes. If you still have this issue, i'll suggest you to investigate it. You will need to attach UART to ar9271, to get more info. https://wikidevi.com/wiki/AR9271 -- Regards, Oleksij -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 278 bytes Desc: OpenPGP digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140330/5a580b82/attachment-0001.pgp ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-03-30 7:31 ` Oleksij Rempel @ 2014-03-31 5:41 ` Harshal Vora 2014-03-31 7:19 ` Oleksij Rempel 0 siblings, 1 reply; 11+ messages in thread From: Harshal Vora @ 2014-03-31 5:41 UTC (permalink / raw) To: ath9k-devel Hi Oleksij, Is there any constraint on the kernel version with the new firmware, as in a minimum kernel version for atheros drivers that are compatible with the latest firmware? Thanks, Regards, On 03/30/2014 01:01 PM, Oleksij Rempel wrote: > Am 29.03.2014 11:17, schrieb Harshal Vora: >> Hi, >> >> We are running tp link wn721n usb wifi adapter with atheros 9271 chipset >> on raspberry pi using kernel version 3.6.11 >> We run the physical interface wlan0 in adhoc mode and also create a >> virtual interface wlan0-mon0 from wlan0 which runs in monitor mode. >> The USB chipset suddenly hangs or shuts down after running for sometime. >> Sometimes it runs for few minutes, sometimes for hours before this happens. >> Sometimes this happens when a new node enters the adhoc network. >> We are using babel on top of ad-hoc network to create a mesh like >> functionality. >> >> Below are the logs from one of the device. Also when I try to unload the >> driver using modprobe -r, it looks like panic mode. >> We are not using power save mode. >> >> >> Mar 28 15:45:45 localhost kernel: [18268.650000] ath: phy0: Unable to >> reset channel (2452 Mhz) reset status -22 >> Mar 28 15:45:45 localhost kernel: [18268.670000] ath: phy0: Unable to >> set channel >> Mar 28 15:45:46 localhost kernel: [18269.180000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:45:46 localhost kernel: [18269.180000] ath: phy0: Chip reset >> failed >> Mar 28 15:45:46 localhost kernel: [18269.190000] ath: phy0: Unable to >> reset channel (2457 Mhz) reset status -22 >> Mar 28 15:45:46 localhost kernel: [18269.210000] ath: phy0: Unable to >> set channel >> Mar 28 15:45:46 localhost kernel: [18269.720000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:45:46 localhost kernel: [18269.720000] ath: phy0: Chip reset >> failed >> Mar 28 15:45:46 localhost kernel: [18269.730000] ath: phy0: Unable to >> reset channel (2462 Mhz) reset status -22 >> Mar 28 15:45:46 localhost kernel: [18269.750000] ath: phy0: Unable to >> set channel >> Mar 28 15:45:47 localhost kernel: [18270.250000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:45:47 localhost kernel: [18270.260000] ath: phy0: Chip reset >> failed >> Mar 28 15:45:47 localhost kernel: [18270.270000] ath: phy0: Unable to >> reset channel (2467 Mhz) reset status -22 >> Mar 28 15:45:47 localhost kernel: [18270.280000] ath: phy0: Unable to >> set channel >> Mar 28 15:45:47 localhost kernel: [18270.790000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:45:47 localhost kernel: [18270.800000] ath: phy0: Chip reset >> failed >> Mar 28 15:45:48 localhost kernel: [18270.810000] ath: phy0: Unable to >> reset channel (2472 Mhz) reset status -22 >> Mar 28 15:45:48 localhost kernel: [18270.820000] ath: phy0: Unable to >> set channel >> Mar 28 15:45:48 localhost kernel: [18271.330000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:45:48 localhost kernel: [18271.340000] ath: phy0: Chip reset >> failed >> Mar 28 15:45:48 localhost kernel: [18271.350000] ath: phy0: Unable to >> reset channel (2484 Mhz) reset status -22 >> Mar 28 15:45:48 localhost kernel: [18271.360000] ath: phy0: Unable to >> set channel >> Mar 28 15:45:49 localhost kernel: [18271.870000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:45:49 localhost kernel: [18271.880000] ath: phy0: Chip reset >> failed >> Mar 28 15:45:49 localhost kernel: [18271.890000] ath: phy0: Unable to >> reset channel (2412 Mhz) reset status -22 >> Mar 28 15:45:49 localhost kernel: [18271.900000] ath: phy0: Unable to >> set channel >> Mar 28 15:45:49 localhost kernel: [18272.080000] wlan1: expiring >> inactive STA c0:4a:00:18:db:79 >> Mar 28 15:45:49 localhost kernel: [18272.080000] wlan1: moving STA >> c0:4a:00:18:db:79 to state 3 >> Mar 28 15:45:49 localhost kernel: [18272.090000] wlan1: moving STA >> c0:4a:00:18:db:79 to state 2 >> Mar 28 15:45:49 localhost kernel: [18272.090000] ath: phy0: Unable to >> remove station entry for: c0:4a:00:18:db:79 >> Mar 28 15:45:49 localhost kernel: [18272.110000] wlan1: moving STA >> c0:4a:00:18:db:79 to state 1 >> Mar 28 15:45:49 localhost kernel: [18272.110000] ieee80211 phy0: Removed >> STA c0:4a:00:18:db:79 >> Mar 28 15:45:49 localhost kernel: [18272.120000] ieee80211 phy0: >> Destroyed STA c0:4a:00:18:db:79 >> Mar 28 15:45:49 localhost kernel: [18272.120000] wlan1: expiring >> inactive STA 10:fe:ed:13:f2:10 >> Mar 28 15:45:49 localhost kernel: [18272.130000] wlan1: moving STA >> 10:fe:ed:13:f2:10 to state 3 >> Mar 28 15:45:49 localhost kernel: [18272.130000] wlan1: moving STA >> 10:fe:ed:13:f2:10 to state 2 >> Mar 28 15:45:49 localhost kernel: [18272.140000] ath: phy0: Unable to >> remove station entry for: 10:fe:ed:13:f2:10 >> Mar 28 15:45:49 localhost kernel: [18272.150000] wlan1: moving STA >> 10:fe:ed:13:f2:10 to state 1 >> Mar 28 15:45:49 localhost kernel: [18272.160000] ieee80211 phy0: Removed >> STA 10:fe:ed:13:f2:10 >> Mar 28 15:45:49 localhost kernel: [18272.160000] ieee80211 phy0: >> Destroyed STA 10:fe:ed:13:f2:10 >> Mar 28 15:45:49 localhost kernel: [18272.170000] wlan1: expiring >> inactive STA 64:66:b3:18:c9:79 >> Mar 28 15:45:49 localhost kernel: [18272.170000] wlan1: moving STA >> 64:66:b3:18:c9:79 to state 3 >> Mar 28 15:45:49 localhost kernel: [18272.180000] wlan1: moving STA >> 64:66:b3:18:c9:79 to state 2 >> Mar 28 15:45:49 localhost kernel: [18272.180000] ath: phy0: Unable to >> remove station entry for: 64:66:b3:18:c9:79 >> Mar 28 15:45:49 localhost kernel: [18272.200000] wlan1: moving STA >> 64:66:b3:18:c9:79 to state 1 >> Mar 28 15:45:49 localhost kernel: [18272.200000] ieee80211 phy0: Removed >> STA 64:66:b3:18:c9:79 >> Mar 28 15:45:49 localhost kernel: [18272.210000] ieee80211 phy0: >> Destroyed STA 64:66:b3:18:c9:79 >> Mar 28 15:45:49 localhost kernel: [18272.210000] wlan1: expiring >> inactive STA 00:1f:3c:0b:f0:5c >> Mar 28 15:45:49 localhost kernel: [18272.220000] wlan1: moving STA >> 00:1f:3c:0b:f0:5c to state 3 >> Mar 28 15:45:49 localhost kernel: [18272.220000] wlan1: moving STA >> 00:1f:3c:0b:f0:5c to state 2 >> Mar 28 15:45:49 localhost kernel: [18272.230000] ath: phy0: Unable to >> remove station entry for: 00:1f:3c:0b:f0:5c >> Mar 28 15:45:49 localhost kernel: [18272.240000] wlan1: moving STA >> 00:1f:3c:0b:f0:5c to state 1 >> Mar 28 15:45:49 localhost kernel: [18272.250000] ieee80211 phy0: Removed >> STA 00:1f:3c:0b:f0:5c >> Mar 28 15:45:49 localhost kernel: [18272.250000] ieee80211 phy0: >> Destroyed STA 00:1f:3c:0b:f0:5c >> Mar 28 15:45:49 localhost kernel: [18272.260000] wlan1: expiring >> inactive STA 10:fe:ed:14:d5:c4 >> Mar 28 15:45:49 localhost kernel: [18272.260000] wlan1: moving STA >> 10:fe:ed:14:d5:c4 to state 3 >> Mar 28 15:45:49 localhost kernel: [18272.270000] wlan1: moving STA >> 10:fe:ed:14:d5:c4 to state 2 >> Mar 28 15:45:49 localhost kernel: [18272.270000] ath: phy0: Unable to >> remove station entry for: 10:fe:ed:14:d5:c4 >> Mar 28 15:45:49 localhost kernel: [18272.280000] wlan1: moving STA >> 10:fe:ed:14:d5:c4 to state 1 >> Mar 28 15:45:49 localhost kernel: [18272.290000] ieee80211 phy0: Removed >> STA 10:fe:ed:14:d5:c4 >> Mar 28 15:45:49 localhost kernel: [18272.290000] ieee80211 phy0: >> Destroyed STA 10:fe:ed:14:d5:c4 >> >> >> Mar 28 15:46:19 localhost kernel: [18302.080000] wlan1: No active IBSS >> STAs - trying to scan for other IBSS networks with same SSID (merge) >> Mar 28 15:46:19 localhost kernel: [18302.770000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:46:19 localhost kernel: [18302.780000] ath: phy0: Chip reset >> failed >> Mar 28 15:46:19 localhost kernel: [18302.780000] ath: phy0: Unable to >> reset channel (2412 Mhz) reset status -22 >> Mar 28 15:46:19 localhost kernel: [18302.800000] ath: phy0: Unable to >> set channel >> Mar 28 15:46:20 localhost kernel: [18303.310000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:46:20 localhost kernel: [18303.310000] ath: phy0: Chip reset >> failed >> Mar 28 15:46:20 localhost kernel: [18303.320000] ath: phy0: Unable to >> reset channel (2417 Mhz) reset status -22 >> Mar 28 15:46:20 localhost kernel: [18303.330000] ath: phy0: Unable to >> set channel >> Mar 28 15:46:20 localhost ntpdate[12205]: adjust time server >> 199.102.46.73 offset -0.001353 sec >> Mar 28 15:46:21 localhost kernel: [18303.850000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:46:21 localhost kernel: [18303.860000] ath: phy0: Chip reset >> failed >> Mar 28 15:46:21 localhost kernel: [18303.870000] ath: phy0: Unable to >> reset channel (2422 Mhz) reset status -22 >> Mar 28 15:46:21 localhost kernel: [18303.880000] ath: phy0: Unable to >> set channel >> Mar 28 15:46:21 localhost kernel: [18304.390000] ath: phy0: timeout >> (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000 >> Mar 28 15:46:21 localhost kernel: [18304.400000] ath: phy0: Chip reset >> failed > Hi Harshal, > > please, use latest wireless-testing.git and this firmware branch: > https://github.com/olerem/open-ath9k-htc-firmware/tree/testing > > Latest kernel git has lots of changes in ath9k_htc code. And it is able > to catch oops pattern from firmware. > Latest firmware branch, is able to restart on some crashes. > If you still have this issue, i'll suggest you to investigate it. You > will need to attach UART to ar9271, to get more info. > https://wikidevi.com/wiki/AR9271 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-03-31 5:41 ` Harshal Vora @ 2014-03-31 7:19 ` Oleksij Rempel 2014-03-31 8:06 ` Harshal Vora 0 siblings, 1 reply; 11+ messages in thread From: Oleksij Rempel @ 2014-03-31 7:19 UTC (permalink / raw) To: ath9k-devel Am 31.03.2014 07:41, schrieb Harshal Vora: > Hi Oleksij, > > Is there any constraint on the kernel version with the new firmware, as > in a minimum kernel version for atheros drivers that are compatible with > the latest firmware? FW API was not changed or changes should not brake anything. So theoretically new FW will work with old kernel. But, you, defiantly, won't use ath9_htc code older then 3.12. -- Regards, Oleksij -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 278 bytes Desc: OpenPGP digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140331/07e7e9f3/attachment.pgp ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-03-31 7:19 ` Oleksij Rempel @ 2014-03-31 8:06 ` Harshal Vora 2014-03-31 8:22 ` Oleksij Rempel 0 siblings, 1 reply; 11+ messages in thread From: Harshal Vora @ 2014-03-31 8:06 UTC (permalink / raw) To: ath9k-devel Hi Oleksij, We will test with kernel version 3.13.7 and also the latest firmware. Thanks, Regards, On 03/31/2014 12:49 PM, Oleksij Rempel wrote: > Am 31.03.2014 07:41, schrieb Harshal Vora: >> Hi Oleksij, >> >> Is there any constraint on the kernel version with the new firmware, as >> in a minimum kernel version for atheros drivers that are compatible with >> the latest firmware? > FW API was not changed or changes should not brake anything. So > theoretically new FW will work with old kernel. But, you, defiantly, > won't use ath9_htc code older then 3.12. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-03-31 8:06 ` Harshal Vora @ 2014-03-31 8:22 ` Oleksij Rempel 2014-03-31 9:10 ` Harshal Vora 0 siblings, 1 reply; 11+ messages in thread From: Oleksij Rempel @ 2014-03-31 8:22 UTC (permalink / raw) To: ath9k-devel Am 31.03.2014 10:06, schrieb Harshal Vora: > Hi Oleksij, > > We will test with kernel version 3.13.7 and also the latest firmware. I assume we misunderstand each other. FW will work with older kernel versions and some bugs are fixed in 3.13. But only wireless-testing.git can detect some FW oopses, and has changes which may affect AdHock mode. I recommend you to use wireless-testing.git or at least try to cherry-peak this changes. -- Regards, Oleksij -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 278 bytes Desc: OpenPGP digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140331/a3936116/attachment.pgp ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-03-31 8:22 ` Oleksij Rempel @ 2014-03-31 9:10 ` Harshal Vora 2014-04-04 12:37 ` Harshal Vora 0 siblings, 1 reply; 11+ messages in thread From: Harshal Vora @ 2014-03-31 9:10 UTC (permalink / raw) To: ath9k-devel Hi Oleksij, I compared the initial few commits from wireless-testing repo with 3.13.y branch of raspberry linux git repo. Seems like all of those have been merged. I also specifically checked commits only for /drivers/net/wireless/ath/ath9k folder and seems like they are also present in the raspberry linux repo. So I assume all the changes should be there. If issues persist, then I will test with the wireless-testing repo as well. Thanks, Regards, On 03/31/2014 01:52 PM, Oleksij Rempel wrote: > Am 31.03.2014 10:06, schrieb Harshal Vora: >> Hi Oleksij, >> >> We will test with kernel version 3.13.7 and also the latest firmware. > I assume we misunderstand each other. FW will work with older kernel > versions and some bugs are fixed in 3.13. But only wireless-testing.git > can detect some FW oopses, and has changes which may affect AdHock mode. > I recommend you to use wireless-testing.git or at least try to > cherry-peak this changes. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-03-31 9:10 ` Harshal Vora @ 2014-04-04 12:37 ` Harshal Vora 2014-04-04 12:59 ` Oleksij Rempel 0 siblings, 1 reply; 11+ messages in thread From: Harshal Vora @ 2014-04-04 12:37 UTC (permalink / raw) To: ath9k-devel Hi Oleksij, When the chipset goes into sleep mode and cannot come back due to errors like "Chip reset failed", we do not get any traffic inflow or outflow on that interface. Is it safe to assume that when no traffic is visible on that interface, we can restart that interface. Is there any way to check that the device is in that particular failed state? ip link, ip addr, ifconfig all show that the link is UP, but tcpdump does not show any traffic. Regards, On 03/31/2014 02:40 PM, Harshal Vora wrote: > Hi Oleksij, > > I compared the initial few commits from wireless-testing repo with > 3.13.y branch of raspberry linux git repo. Seems like all of those > have been merged. > > I also specifically checked commits only for > /drivers/net/wireless/ath/ath9k folder and seems like they are also > present in the raspberry linux repo. > > So I assume all the changes should be there. > > If issues persist, then I will test with the wireless-testing repo as > well. > > Thanks, > Regards, > > On 03/31/2014 01:52 PM, Oleksij Rempel wrote: >> Am 31.03.2014 10:06, schrieb Harshal Vora: >>> Hi Oleksij, >>> >>> We will test with kernel version 3.13.7 and also the latest firmware. >> I assume we misunderstand each other. FW will work with older kernel >> versions and some bugs are fixed in 3.13. But only wireless-testing.git >> can detect some FW oopses, and has changes which may affect AdHock >> mode. >> I recommend you to use wireless-testing.git or at least try to >> cherry-peak this changes. >> > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-04-04 12:37 ` Harshal Vora @ 2014-04-04 12:59 ` Oleksij Rempel 2014-04-19 11:49 ` Harshal Vora 0 siblings, 1 reply; 11+ messages in thread From: Oleksij Rempel @ 2014-04-04 12:59 UTC (permalink / raw) To: ath9k-devel Am 04.04.2014 14:37, schrieb Harshal Vora: > Hi Oleksij, > > When the chipset goes into sleep mode and cannot come back due to errors > like "Chip reset failed", > we do not get any traffic inflow or outflow on that interface. > > Is it safe to assume that when no traffic is visible on that interface, > we can restart that interface. > Is there any way to check that the device is in that particular failed > state? Only getting error log directly form FW will tell what exactly happens. You will need solder TX and GND on the chip. See https://wikidevi.com/wiki/AR9271 > ip link, ip addr, ifconfig all show that the link is UP, but tcpdump > does not show any traffic. > > Regards, > > On 03/31/2014 02:40 PM, Harshal Vora wrote: >> Hi Oleksij, >> >> I compared the initial few commits from wireless-testing repo with >> 3.13.y branch of raspberry linux git repo. Seems like all of those >> have been merged. >> >> I also specifically checked commits only for >> /drivers/net/wireless/ath/ath9k folder and seems like they are also >> present in the raspberry linux repo. >> >> So I assume all the changes should be there. >> >> If issues persist, then I will test with the wireless-testing repo as >> well. >> >> Thanks, >> Regards, >> >> On 03/31/2014 01:52 PM, Oleksij Rempel wrote: >>> Am 31.03.2014 10:06, schrieb Harshal Vora: >>>> Hi Oleksij, >>>> >>>> We will test with kernel version 3.13.7 and also the latest firmware. >>> I assume we misunderstand each other. FW will work with older kernel >>> versions and some bugs are fixed in 3.13. But only wireless-testing.git >>> can detect some FW oopses, and has changes which may affect AdHock >>> mode. >>> I recommend you to use wireless-testing.git or at least try to >>> cherry-peak this changes. >>> >> > -- Regards, Oleksij -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 278 bytes Desc: OpenPGP digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140404/22b9b05e/attachment.pgp ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-04-04 12:59 ` Oleksij Rempel @ 2014-04-19 11:49 ` Harshal Vora 2014-04-19 19:42 ` Oleksij Rempel 0 siblings, 1 reply; 11+ messages in thread From: Harshal Vora @ 2014-04-19 11:49 UTC (permalink / raw) To: ath9k-devel Hi Oleksij, We have upgraded to kernel 3.14.0 Looks like the kernel upgrade has solved the chip reset issue, but we are facing a new issue. We get a stack trace as shown below and after that the RAM in the raspberry pi goes down gradually from 300MB to 2-3MB At this stage the OOM killer kills a few processes to get some free RAM, but then again the memory keeps going down and eventually the machine crashes. If required we can show you a graph of free memory on how it keeps decreasing. We are noticing this same behaviour in different raspberry pi's (both model A and model B) and all running identical kernel and same processes. Apr 19 08:04:08 localhost kernel: [ 3720.478285] device wlan0-mon0 entered promiscuous mode Apr 19 08:04:15 localhost kernel: [ 3726.966336] net_ratelimit: 2 callbacks suppressed Apr 19 08:04:18 localhost ntpdate[4269]: adjust time server 120.88.47.10 offset 0.000133 sec Apr 19 08:04:25 localhost kernel: [ 3737.399383] wlan0: failed to move IBSS STA a0:f3:c1:2f:d4:34 to state 3 (-105) - keeping it anyway Apr 19 08:04:27 localhost kernel: [ 3738.510453] ------------[ cut here ]------------ Apr 19 08:04:27 localhost kernel: [ 3738.516737] WARNING: CPU: 0 PID: 2188 at kernel/workqueue.c:1393 __queue_work+0x21c/0x294() Apr 19 08:04:27 localhost kernel: [ 3738.528121] Modules linked in: nfnetlink_log nfnetlink ipv6 batman_adv arc4 ath9k_htc mac80211 ath9k_common ath9k_hw ath cfg80211 rfkill leds_gpio led_class spi_bcm2708 i2c_bcm2708 Apr 19 08:04:27 localhost kernel: [ 3738.549312] CPU: 0 PID: 2188 Comm: kworker/u2:0 Tainted: G W 3.14.0 #3 Apr 19 08:04:27 localhost kernel: [ 3738.560481] Workqueue: phy0 ieee80211_iface_work [mac80211] Apr 19 08:04:27 localhost kernel: [ 3738.567903] [<c0013f48>] (unwind_backtrace) from [<c001124c>] (show_stack+0x10/0x14) Apr 19 08:04:27 localhost kernel: [ 3738.579231] [<c001124c>] (show_stack) from [<c001f460>] (warn_slowpath_common+0x68/0x88) Apr 19 08:04:27 localhost kernel: [ 3738.590995] [<c001f460>] (warn_slowpath_common) from [<c001f49c>] (warn_slowpath_null+0x1c/0x24) Apr 19 08:04:27 localhost kernel: [ 3738.603597] [<c001f49c>] (warn_slowpath_null) from [<c0032e6c>] (__queue_work+0x21c/0x294) Apr 19 08:04:27 localhost kernel: [ 3738.615814] [<c0032e6c>] (__queue_work) from [<c0032f54>] (queue_work_on+0x5c/0x64) Apr 19 08:04:27 localhost kernel: [ 3738.627891] [<c0032f54>] (queue_work_on) from [<bf108660>] (ieee80211_rx_mgmt_probe_beacon+0x48c/0x648 [mac80211]) Apr 19 08:04:27 localhost kernel: [ 3738.643050] [<bf108660>] (ieee80211_rx_mgmt_probe_beacon [mac80211]) from [<bf108ca0>] (ieee80211_ibss_rx_queued_mgmt+0xf4/0x33c [mac80211]) Apr 19 08:04:27 localhost kernel: [ 3738.660660] [<bf108ca0>] (ieee80211_ibss_rx_queued_mgmt [mac80211]) from [<bf10a8c0>] (ieee80211_iface_work+0x1bc/0x2c4 [mac80211]) Apr 19 08:04:27 localhost kernel: [ 3738.677324] [<bf10a8c0>] (ieee80211_iface_work [mac80211]) from [<c00343c8>] (process_one_work+0x12c/0x36c) Apr 19 08:04:27 localhost kernel: [ 3738.691710] [<c00343c8>] (process_one_work) from [<c0034a50>] (worker_thread+0x118/0x3c4) Apr 19 08:04:27 localhost kernel: [ 3738.704512] [<c0034a50>] (worker_thread) from [<c003a248>] (kthread+0xbc/0xd8) Apr 19 08:04:27 localhost kernel: [ 3738.714114] [<c003a248>] (kthread) from [<c000e1f8>] (ret_from_fork+0x14/0x3c) Apr 19 08:04:27 localhost kernel: [ 3738.723646] ---[ end trace 73244bee8b3d23b5 ]--- Thanks, Regards, On 04/04/2014 06:29 PM, Oleksij Rempel wrote: > Am 04.04.2014 14:37, schrieb Harshal Vora: >> Hi Oleksij, >> >> When the chipset goes into sleep mode and cannot come back due to errors >> like "Chip reset failed", >> we do not get any traffic inflow or outflow on that interface. >> >> Is it safe to assume that when no traffic is visible on that interface, >> we can restart that interface. >> Is there any way to check that the device is in that particular failed >> state? > Only getting error log directly form FW will tell what exactly happens. > You will need solder TX and GND on the chip. > See https://wikidevi.com/wiki/AR9271 > >> ip link, ip addr, ifconfig all show that the link is UP, but tcpdump >> does not show any traffic. >> >> Regards, >> >> On 03/31/2014 02:40 PM, Harshal Vora wrote: >>> Hi Oleksij, >>> >>> I compared the initial few commits from wireless-testing repo with >>> 3.13.y branch of raspberry linux git repo. Seems like all of those >>> have been merged. >>> >>> I also specifically checked commits only for >>> /drivers/net/wireless/ath/ath9k folder and seems like they are also >>> present in the raspberry linux repo. >>> >>> So I assume all the changes should be there. >>> >>> If issues persist, then I will test with the wireless-testing repo as >>> well. >>> >>> Thanks, >>> Regards, >>> >>> On 03/31/2014 01:52 PM, Oleksij Rempel wrote: >>>> Am 31.03.2014 10:06, schrieb Harshal Vora: >>>>> Hi Oleksij, >>>>> >>>>> We will test with kernel version 3.13.7 and also the latest firmware. >>>> I assume we misunderstand each other. FW will work with older kernel >>>> versions and some bugs are fixed in 3.13. But only wireless-testing.git >>>> can detect some FW oopses, and has changes which may affect AdHock >>>> mode. >>>> I recommend you to use wireless-testing.git or at least try to >>>> cherry-peak this changes. >>>> > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers 2014-04-19 11:49 ` Harshal Vora @ 2014-04-19 19:42 ` Oleksij Rempel 0 siblings, 0 replies; 11+ messages in thread From: Oleksij Rempel @ 2014-04-19 19:42 UTC (permalink / raw) To: ath9k-devel Am 19.04.2014 13:49, schrieb Harshal Vora: > Hi Oleksij, > > We have upgraded to kernel 3.14.0 > Looks like the kernel upgrade has solved the chip reset issue, but we > are facing a new issue. > We get a stack trace as shown below and after that the RAM in the > raspberry pi goes down gradually from 300MB to 2-3MB > At this stage the OOM killer kills a few processes to get some free RAM, > but then again the memory keeps going down and eventually the machine > crashes. > If required we can show you a graph of free memory on how it keeps > decreasing. > We are noticing this same behaviour in different raspberry pi's (both > model A and model B) and all running identical kernel and same processes. Hi, suddenly i can't help you here. kmemleak is probably good start in this case. Are you sure it is not ARCH realted issue? > Apr 19 08:04:08 localhost kernel: [ 3720.478285] device wlan0-mon0 > entered promiscuous mode > Apr 19 08:04:15 localhost kernel: [ 3726.966336] net_ratelimit: 2 > callbacks suppressed > Apr 19 08:04:18 localhost ntpdate[4269]: adjust time server 120.88.47.10 > offset 0.000133 sec > Apr 19 08:04:25 localhost kernel: [ 3737.399383] wlan0: failed to move > IBSS STA a0:f3:c1:2f:d4:34 to state 3 (-105) - keeping it anyway > Apr 19 08:04:27 localhost kernel: [ 3738.510453] ------------[ cut here > ]------------ > Apr 19 08:04:27 localhost kernel: [ 3738.516737] WARNING: CPU: 0 PID: > 2188 at kernel/workqueue.c:1393 __queue_work+0x21c/0x294() > Apr 19 08:04:27 localhost kernel: [ 3738.528121] Modules linked in: > nfnetlink_log nfnetlink ipv6 batman_adv arc4 ath9k_htc mac80211 > ath9k_common ath9k_hw ath cfg80211 rfkill leds_gpio led_class > spi_bcm2708 i2c_bcm2708 > Apr 19 08:04:27 localhost kernel: [ 3738.549312] CPU: 0 PID: 2188 Comm: > kworker/u2:0 Tainted: G W 3.14.0 #3 > Apr 19 08:04:27 localhost kernel: [ 3738.560481] Workqueue: phy0 > ieee80211_iface_work [mac80211] > Apr 19 08:04:27 localhost kernel: [ 3738.567903] [<c0013f48>] > (unwind_backtrace) from [<c001124c>] (show_stack+0x10/0x14) > Apr 19 08:04:27 localhost kernel: [ 3738.579231] [<c001124c>] > (show_stack) from [<c001f460>] (warn_slowpath_common+0x68/0x88) > Apr 19 08:04:27 localhost kernel: [ 3738.590995] [<c001f460>] > (warn_slowpath_common) from [<c001f49c>] (warn_slowpath_null+0x1c/0x24) > Apr 19 08:04:27 localhost kernel: [ 3738.603597] [<c001f49c>] > (warn_slowpath_null) from [<c0032e6c>] (__queue_work+0x21c/0x294) > Apr 19 08:04:27 localhost kernel: [ 3738.615814] [<c0032e6c>] > (__queue_work) from [<c0032f54>] (queue_work_on+0x5c/0x64) > Apr 19 08:04:27 localhost kernel: [ 3738.627891] [<c0032f54>] > (queue_work_on) from [<bf108660>] > (ieee80211_rx_mgmt_probe_beacon+0x48c/0x648 [mac80211]) > Apr 19 08:04:27 localhost kernel: [ 3738.643050] [<bf108660>] > (ieee80211_rx_mgmt_probe_beacon [mac80211]) from [<bf108ca0>] > (ieee80211_ibss_rx_queued_mgmt+0xf4/0x33c [mac80211]) > Apr 19 08:04:27 localhost kernel: [ 3738.660660] [<bf108ca0>] > (ieee80211_ibss_rx_queued_mgmt [mac80211]) from [<bf10a8c0>] > (ieee80211_iface_work+0x1bc/0x2c4 [mac80211]) > Apr 19 08:04:27 localhost kernel: [ 3738.677324] [<bf10a8c0>] > (ieee80211_iface_work [mac80211]) from [<c00343c8>] > (process_one_work+0x12c/0x36c) > Apr 19 08:04:27 localhost kernel: [ 3738.691710] [<c00343c8>] > (process_one_work) from [<c0034a50>] (worker_thread+0x118/0x3c4) > Apr 19 08:04:27 localhost kernel: [ 3738.704512] [<c0034a50>] > (worker_thread) from [<c003a248>] (kthread+0xbc/0xd8) > Apr 19 08:04:27 localhost kernel: [ 3738.714114] [<c003a248>] (kthread) > from [<c000e1f8>] (ret_from_fork+0x14/0x3c) > Apr 19 08:04:27 localhost kernel: [ 3738.723646] ---[ end trace > 73244bee8b3d23b5 ]--- > > Thanks, > Regards, > > > On 04/04/2014 06:29 PM, Oleksij Rempel wrote: >> Am 04.04.2014 14:37, schrieb Harshal Vora: >>> Hi Oleksij, >>> >>> When the chipset goes into sleep mode and cannot come back due to errors >>> like "Chip reset failed", >>> we do not get any traffic inflow or outflow on that interface. >>> >>> Is it safe to assume that when no traffic is visible on that interface, >>> we can restart that interface. >>> Is there any way to check that the device is in that particular failed >>> state? >> Only getting error log directly form FW will tell what exactly happens. >> You will need solder TX and GND on the chip. >> See https://wikidevi.com/wiki/AR9271 >> >>> ip link, ip addr, ifconfig all show that the link is UP, but tcpdump >>> does not show any traffic. >>> >>> Regards, >>> >>> On 03/31/2014 02:40 PM, Harshal Vora wrote: >>>> Hi Oleksij, >>>> >>>> I compared the initial few commits from wireless-testing repo with >>>> 3.13.y branch of raspberry linux git repo. Seems like all of those >>>> have been merged. >>>> >>>> I also specifically checked commits only for >>>> /drivers/net/wireless/ath/ath9k folder and seems like they are also >>>> present in the raspberry linux repo. >>>> >>>> So I assume all the changes should be there. >>>> >>>> If issues persist, then I will test with the wireless-testing repo as >>>> well. >>>> >>>> Thanks, >>>> Regards, >>>> >>>> On 03/31/2014 01:52 PM, Oleksij Rempel wrote: >>>>> Am 31.03.2014 10:06, schrieb Harshal Vora: >>>>>> Hi Oleksij, >>>>>> >>>>>> We will test with kernel version 3.13.7 and also the latest firmware. >>>>> I assume we misunderstand each other. FW will work with older kernel >>>>> versions and some bugs are fixed in 3.13. But only >>>>> wireless-testing.git >>>>> can detect some FW oopses, and has changes which may affect AdHock >>>>> mode. >>>>> I recommend you to use wireless-testing.git or at least try to >>>>> cherry-peak this changes. >>>>> >> > -- Regards, Oleksij -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 278 bytes Desc: OpenPGP digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140419/a5a73135/attachment.pgp ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-04-19 19:42 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-03-29 10:17 [ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers Harshal Vora 2014-03-30 7:31 ` Oleksij Rempel 2014-03-31 5:41 ` Harshal Vora 2014-03-31 7:19 ` Oleksij Rempel 2014-03-31 8:06 ` Harshal Vora 2014-03-31 8:22 ` Oleksij Rempel 2014-03-31 9:10 ` Harshal Vora 2014-04-04 12:37 ` Harshal Vora 2014-04-04 12:59 ` Oleksij Rempel 2014-04-19 11:49 ` Harshal Vora 2014-04-19 19:42 ` Oleksij Rempel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.