I am cloning the bug because I still see it on Fedora 17.

+++ This bug was initially created as a clone of Bug #815377 +++

Description of problem:

The wireless card can't connect to the AP anymore after failing to reset the channel with the error:
   ath: Unable to reset channel, reset status -22

Version-Release number of selected component (if applicable):
$> uname -a
Linux ... 3.3.2-1.fc16.x86_64 #1 SMP Sat Apr 14 00:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


How reproducible:
Connect to wireless lan and accesspoint switches the channel used.


Actual results:
The wireless connection is lost and the driver cannot connect to wireless anymore until system restart.


Additional info:
/var/log/messages

Apr 23 12:55:51 nruivo kernel: [ 9939.381835] ath: Failed to wakeup in 500us
Apr 23 12:55:51 nruivo kernel: [ 9939.444918] ath: Failed to stop TX DMA, queues=0x10f!
Apr 23 12:55:51 nruivo kernel: [ 9939.456306] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
Apr 23 12:55:51 nruivo kernel: [ 9939.456340] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Apr 23 12:55:51 nruivo kernel: [ 9939.570249] ath: Chip reset failed
Apr 23 12:55:51 nruivo kernel: [ 9939.570254] ath: Unable to reset channel, reset status -22
Apr 23 12:55:52 nruivo kernel: [ 9940.502994] ath: Failed to wakeup in 500us
Apr 23 12:55:53 nruivo kernel: [ 9941.068048] ath: Failed to stop TX DMA, queues=0x10f!
Apr 23 12:55:53 nruivo kernel: [ 9941.079394] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
Apr 23 12:55:53 nruivo kernel: [ 9941.079402] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Apr 23 12:55:53 nruivo kernel: [ 9941.193327] ath: Chip reset failed
Apr 23 12:55:53 nruivo kernel: [ 9941.193334] ath: Unable to reset channel, reset status -22
Apr 23 12:55:53 nruivo kernel: [ 9941.193368] ath: Unable to set channel
Apr 23 12:55:53 nruivo kernel: [ 9941.206681] cfg80211: Calling CRDA to update world regulatory domain
Apr 23 12:55:53 nruivo NetworkManager[1087]: <info> (wlan0): supplicant interface state: completed -> disconnected
Apr 23 12:55:53 nruivo kernel: [ 9941.226841] cfg80211: World regulatory domain updated:
Apr 23 12:55:53 nruivo kernel: [ 9941.226848] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Apr 23 12:55:53 nruivo kernel: [ 9941.226856] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 23 12:55:53 nruivo kernel: [ 9941.226862] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Apr 23 12:55:53 nruivo kernel: [ 9941.226868] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Apr 23 12:55:53 nruivo kernel: [ 9941.226874] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 23 12:55:53 nruivo kernel: [ 9941.226879] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 23 12:55:53 nruivo kernel: [ 9941.226903] cfg80211: Calling CRDA for country: PT
Apr 23 12:55:53 nruivo kernel: [ 9941.235080] cfg80211: Regulatory domain changed to country: PT
Apr 23 12:55:53 nruivo kernel: [ 9941.235088] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Apr 23 12:55:53 nruivo kernel: [ 9941.235095] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Apr 23 12:55:53 nruivo kernel: [ 9941.235101] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Apr 23 12:55:53 nruivo kernel: [ 9941.235106] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Apr 23 12:55:53 nruivo kernel: [ 9941.235111] cfg80211:   (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
Apr 23 12:55:53 nruivo NetworkManager[1087]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Apr 23 12:55:53 nruivo kernel: [ 9941.357349] ath: Failed to stop TX DMA, queues=0x10f!
Apr 23 12:55:53 nruivo kernel: [ 9941.368724] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
Apr 23 12:55:53 nruivo kernel: [ 9941.368732] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Apr 23 12:55:53 nruivo kernel: [ 9941.482656] ath: Chip reset failed
Apr 23 12:55:53 nruivo kernel: [ 9941.482661] ath: Unable to reset channel, reset status -22
Apr 23 12:55:53 nruivo kernel: [ 9941.482680] ath: Unable to set channel



$> lspci 
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b5)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5)
00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 VGA compatible controller: ATI Technologies Inc NI Seymour [AMD Radeon HD 6470M]
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
0d:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)
13:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5209 (rev 01)
13:00.1 SD Host controller: Realtek Semiconductor Co., Ltd. Device 5209 (rev 01)


Kernel modules:
ath9k                 134768  0 
mac80211              496450  1 ath9k
ath9k_common           13600  1 ath9k
ath9k_hw              408211  2 ath9k,ath9k_common
ath                    23089  3 ath9k,ath9k_common,ath9k_hw
cfg80211              195558  3 ath9k,mac80211,ath


#> ath_info -v wlan0
#DBG main: sleep_ctl reg 7b0eb7d6   reset_ctl reg 00000000
MAC revision 0xdf9f is not supported!

--- Additional comment from John W. Linville on 2012-04-27 13:34:01 EDT ---

Is there any specific action that leads to this failure?

What was the last kernel that worked properly?

--- Additional comment from Mohammed Shafi on 2012-04-30 09:19:12 EDT ---

in addition to John's query please see if disabling power save helps
iwconfig wlanX power off
iw dev wlanX set power_save off
these failure stuffs are corner cases and not so easy to debug!

--- Additional comment from Nelson Ruivo on 2012-04-30 10:26:30 EDT ---

Thanks, I'm still trying to find a way to reproduce the failure conditions, but this depends on the router decision to change the channel.

However I made the recommended change:

$> iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:"XXXX"
          ....
          Power Management:off
          ....


I had this problem ever since I'm using Fedora 16 on this laptop (HP DV-6C50EP), the first OS I've been using on it.

--- Additional comment from Nelson Ruivo on 2012-06-28 13:39:49 EDT ---

After some months with power management off the error doesn't happen anymore.
Recently I've installed ath9k from linuxwireless, and the error didn't happen with power management on, so the error might be in the kernel include driver, the linuxwireless ath9k module seems to be more stable.

--- Additional comment from Sergio Durigan Junior on 2012-07-28 01:57:42 EDT ---

I can confirm this bug on a Dell Inspiron 15R Special Edition (7250), with the same card.

sergio@afrodite ~ $ uname -a
Linux afrodite 3.4.5-2.fc17.x86_64 #1 SMP Mon Jul 16 20:52:08 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
sergio@afrodite ~ $ lspci
00:00.0 Host bridge: Intel Corporation Ivy Bridge DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Ivy Bridge PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Device 0166 (rev 09)
00:14.0 USB Controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation Panther Point MEI Controller #1 (rev 04)
00:1a.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 2 (rev c4)
00:1d.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation Panther Point 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04)
01:00.0 VGA compatible controller: ATI Technologies Inc Device 682f (rev ff)
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 07)
08:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)

When the issue happened, the power management was 'on'.  I set it to 'off' now (according to the comments above), so let's see if it happens again.

My router does not change its channel automatically, so I do not think this is the issue.

Let me know if I can provide more details.

--- Additional comment from Sergio Durigan Junior on 2012-08-04 00:14:09 EDT ---

After some days using the notebook with power management disabled for the wifi card, I can confirm the bug does not manifest anymore.  However, it would be good to have it fixed because (a) the solution is not trivial to find for a regular Fedora user and (b) one has to remember to disable power management every time the system boots (I automatized this, but it is not trivial also).

--- Additional comment from Dave Jones on 2012-10-23 11:36:22 EDT ---

# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).

--- Additional comment from Vladimir Rusinov on 2012-10-26 18:20:00 EDT ---

I'm still seeing this problem with latest kernel.

Turning off power management helps a bit: instead of blowing in 1 minute it lasts for about 15.

Any known workaround?

--- Additional comment from Nelson Ruivo on 2012-11-28 06:41:43 EST ---

I confirm this still happens on Kernel 3.6.6:

$> uname -a
Linux nruivo.besttables.com 3.6.6-1.fc16.x86_64 #1 SMP Mon Nov 5 16:56:43 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

After about 24 hours connected through wi-fi with power management on, the error happened again, follows a partial trace from /var/log/messases:

Nov 28 11:32:27 nruivo kernel: [80504.206710] ath: phy0: Could not stop RX, we could be confusing the DMA engine when we start RX up
Nov 28 11:32:27 nruivo kernel: [80504.268827] ath: phy0: Failed to stop TX DMA, queues=0x10f!
Nov 28 11:32:27 nruivo kernel: [80504.379997] ath: phy0: Chip reset failed
Nov 28 11:32:27 nruivo kernel: [80504.379999] ath: phy0: Unable to reset channel, reset status -22
Nov 28 11:32:27 nruivo kernel: [80504.380008] ath: phy0: Unable to set channel
Nov 28 11:32:27 nruivo kernel: [80504.491100] ath: phy0: RX failed to go idle in 10 ms RXSM=0xffffffff
Nov 28 11:32:27 nruivo kernel: [80504.502198] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
Nov 28 11:32:28 nruivo kernel: [80505.426493] ath: phy0: Failed to wakeup in 500us
Nov 28 11:32:28 nruivo kernel: [80505.540148] ath: phy0: RX failed to go idle in 10 ms RXSM=0xffffffff
Nov 28 11:32:28 nruivo kernel: [80505.551536] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff

--- Additional comment from Fedora End Of Life on 2013-01-16 09:07:29 EST ---

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from Fedora End Of Life on 2013-02-13 10:07:46 EST ---

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.