I have been struggling with very frequent wifi drops. In my regular quest for a solution I stumbled upon this post.
My kernel version is 4.2.0-16-generic Linux 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 Most recent kern.log entries indicate Nov 7 05:37:28 watsonit-150411 kernel: [419299.308586] ath: phy41: Chip reset failed Nov 7 05:37:28 watsonit-150411 kernel: [419299.308590] ath: phy41: Unable to reset channel (2457 Mhz) reset status -22 Nov 7 05:37:28 watsonit-150411 kernel: [419299.308592] ath: phy41: Unable to set channel Nov 7 05:37:28 watsonit-150411 kernel: [419299.408415] ath: phy41: RX failed to go idle in 10 ms RXSM=0x0 Nov 7 05:37:28 watsonit-150411 kernel: [419299.418500] ath: phy41: Failed to wakeup in 500us Nov 7 05:37:28 watsonit-150411 kernel: [419299.428492] ath: phy41: Failed to wakeup in 500us Nov 7 05:37:28 watsonit-150411 kernel: [419299.727544] ath: phy41: RX failed to go idle in 10 ms RXSM=0x306e82a7 Based on the above I came across a post @ http://ubuntuforums.org/showthread.php?2239557 and implemented the proposed script in /etc/pm/sleep.d/ case "{$1}" in hibernate|suspend) # disable wlan0 ifdown wlan0 --force ;; resume|thaw) # enable wlan0 ## service networking restart ifup wlan0 ;; esac The belief is that for some reason wpa_supplicant does not stop before going to sleep, but then tries to start again upon resume in order to negotiate keys. Let's see if stopping wpa_supplicate before sleep (assuming this code achieves that and that the system really is suspending) solves this issue. Worth noting here that I am not using network-manager since the problem was even greater with that additional service running. It is yet to be determined whether or not this resolves, or improves things. What I have noticed since making this last change this morning is that the workstation eventually became unreachable from other LAN locations; however, upon returning to the workstation and unlocking the screen ifconfig and ping proved that connectivity was good.... perhaps the suspend/resume script did help. Ultimately, I still need to avoid having the connection drop at all -- no suspend, no bringing the interface down. Hopefully some of this information sounds familiar to others and helps. If anyone has further suggestions on permanently resolving this issue, would love to hear them. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1361646 Title: Atheros wireless AR9285 keeps disconnecting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361646/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
