168c:002a ath: Failed to stop TX DMA in 100 msec after killing last frame

[Cristian Aravena Romero]

Message in dmesg:

[ 22.308381] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 22.308447] ath: Failed to stop TX DMA!
---
ApportVersion: 2.12-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: caravena 1670 F.... pulseaudio
 /dev/snd/controlC1: caravena 1670 F.... pulseaudio
 /dev/snd/pcmC1D0p: caravena 1670 F...m pulseaudio
CRDA:
 country CL:
  (2402 - 2482 @ 40), (N/A, 20)
  (5170 - 5250 @ 40), (N/A, 20)
  (5250 - 5330 @ 40), (N/A, 20), DFS
  (5735 - 5835 @ 40), (N/A, 20)
DistroRelease: Ubuntu 13.10
HibernationDevice: RESUME=UUID=360bd2d2-4f44-4311-86d6-4781ac81ee87
InstallationDate: Installed on 2013-07-31 (17 days ago)
InstallationMedia: Ubuntu-GNOME 13.10 "Saucy Salamander" - Alpha amd64 (20130724)
MachineType: SAMSUNG ELECTRONICS CO., LTD. 530U3C/530U4C
MarkForUpload: True
Package: linux (not installed)
ProcFB:
 0 inteldrmfb
 1 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-3.11.0-2-generic root=UUID=0c67119c-ddae-476a-b510-142ec598f691 ro rootflags=subvol=@ quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.11.0-2.5-generic 3.11.0-rc5
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-2-generic N/A
 linux-backports-modules-3.11.0-2-generic N/A
 linux-firmware 1.113
Tags: saucy
Uname: Linux 3.11.0-2-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 04/15/2013
dmi.bios.vendor: Phoenix Technologies Ltd.
dmi.bios.version: P14AAJ
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: SAMSUNG_NP1234567890
dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.board.version: FAB1
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvrP14AAJ:bd04/15/2013:svnSAMSUNGELECTRONICSCO.,LTD.:pn530U3C/530U4C:pvr0.1:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSAMSUNG_NP1234567890:rvrFAB1:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvr0.1:
dmi.product.name: 530U3C/530U4C
dmi.product.version: 0.1
dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.

[vadik56 (vadik56-gmail)]

I also see same messages in dmesg. Currently using Ubuntu natty beta 2.6.38-8-generic. Wireless speed is very slow. About 30% of packets are lost using ping:
 --- 192.168.1.1 ping statistics ---
45 packets transmitted, 31 received, 31% packet loss, time 44086ms
rtt min/avg/max/mdev = 1.163/2.363/16.377/2.694 ms

lspci -vvv
09:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
 Subsystem: D-Link System Inc Device 3a69
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 168, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at fbce0000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [40] #80 [0000]
 Kernel driver in use: ath9k
 Kernel modules: ath9k

[theanswriz42 (theanswriz42)]

This is what I'm seeing:

steve@triton:~$ dmesg | grep -i ath
[ 3.307689] device-mapper: multipath: version 1.2.0 loaded
[ 3.307692] device-mapper: multipath round-robin: version 1.0.0 loaded
[ 10.487950] ath9k 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 10.487974] ath9k 0000:02:00.0: setting latency timer to 64
[ 10.581769] ath: EEPROM regdomain: 0x65
[ 10.581771] ath: EEPROM indicates we should expect a direct regpair map
[ 10.581773] ath: Country alpha2 being used: 00
[ 10.581774] ath: Regpair used: 0x65
[ 11.020072] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control'
[ 11.020587] Registered led device: ath9k-phy0::radio
[ 11.020635] Registered led device: ath9k-phy0::assoc
[ 11.020660] Registered led device: ath9k-phy0::tx
[ 11.020683] Registered led device: ath9k-phy0::rx
[ 11.020690] ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xffffc900057c0000, irq=16
[ 110.607163] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 110.615611] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 110.615641] ath: Failed to stop TX DMA!
[ 111.014587] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 111.014620] ath: Failed to stop TX DMA!

steve@triton:~$ lspci | grep -i wireless
02:00.0 Network controller: Atheros Communications Inc. AR9287 Wireless Network Adapter (PCI-Express) (rev 01)

[Lukasz Olszewski (olszewskil)]

This bug also affects me making network operations practically impossible. lscpi for net below:

Network controller: Atheros Communications Inc. AR9287 Wireless Network Adapter (PCI-Express) (rev 01)
 Subsystem: Foxconn International, Inc. Device e030
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at e8e00000 (64-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: ath9k
 Kernel modules: ath9k

and the syslog:

 kernel: [ 5012.743836] ath: Failed to stop TX DMA!
 kernel: [ 5012.755839] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
 kernel: [ 5012.755845] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
 kernel: [ 5012.767458] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
 kernel: [ 5019.780925] ath: Failed to stop TX DMA in 100 msec after killing last frame
 kernel: [ 5019.780955] ath: Failed to stop TX DMA!
 kernel: [ 5059.803900] ath: Failed to stop TX DMA in 100 msec after killing last frame

[Ben Kero (ben-kero)]

This definitely affects me on maverick and natty, having this hardware:

bkero@Prosper:~$ uname -a
Linux Prosper 2.6.38-02063802-generic #201103281246 SMP Mon Mar 28 12:50:24 UTC 2011 x86_64 GNU/Linux

bkero@Prosper:~$ dmesg|tail -10
[31775.258391] ath: Failed to stop TX DMA in 100 msec after killing last frame
[31775.258428] ath: Failed to stop TX DMA!
[31777.268397] ath: Failed to stop TX DMA in 100 msec after killing last frame
[31777.268434] ath: Failed to stop TX DMA!
[31814.278388] ath: Failed to stop TX DMA in 100 msec after killing last frame
[31814.278426] ath: Failed to stop TX DMA!
[31819.288366] ath: Failed to stop TX DMA in 100 msec after killing last frame
[31819.288404] ath: Failed to stop TX DMA!
[31822.298415] ath: Failed to stop TX DMA in 100 msec after killing last frame
[31822.298453] ath: Failed to stop TX DMA!

bkero@Prosper:~$ lspci|grep Atheros
r01:08.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)

It seems that there was a fix in 2.6.39-rc1 as evidenced in commit d78f4b3e2c4dfb9487624f7157af04ab4260e189

Here's a link to the changelog: http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.39-rc1

Additionally, the fix was ported to compat-wireless, so hopefully we can get a fix backported to 2.6.38 for natty.

[Lee (lee-sodnpoo)]

FWIW - removing and inserting the ath9k module brings it back for me (on natty).

[Ben Kero (ben-kero)]

Just tried the 2.6.39-rc4 kernel from the kernel PPA, and I can confirm that I no longer receive these errors.

[vadik56 (vadik56-gmail)]

This bug should be listed in "Known Issues" section of release notes since wireless is almost unusable with ath9k module. https://wiki.ubuntu.com/NattyNarwhal/ReleaseNotes

[Lukasz Olszewski (olszewskil)]

Yes, it should be listed in "known issues". As a matter of fact it should even be a "show stopper" for this kernel in natty. I made my wifi usable by forcing "g only" mode. The connection still resets every few minutes but it's much better than in "n mode". So I guess there might be much more people out there who are not really aware of this problem as long as they don't use their wifi cards in "n mode"...

[Lukasz Olszewski (olszewskil)]

I am happy to report that this bug is FIXED by the latest kernel update (to version 2.6.38-9).

[Sebastian Breier (tomcat42)]

Related: Bug 761134
Fix is indeed in 2.6.38-9 and in natty-propsed since 2011-05-02.

[pasqoo (pasqoo)]

I got Ubuntu Natty 64bit installed on my laptop with kernel 2.6.38-9-general on (from proposed repository)... but the bug is still present; I keep receiving those errors.

When my interface gets deactivated, I have to click on my connection name (so it disconnects and reconnects to it) to make it work again, even if my network-applet says my connection is correctly established.

My router is set in "g only" mode, sometimes I change channel just to test various frequencies, but it doesn't help me.
WPA2-PSK AES protection is on too.

[Lukasz Olszewski (olszewskil)]

Well I've just noticed this bug isn't entirely fixed after all. I thought it was but these errors still appear they are just much less frequent and don't influence my connection stability as much as they used to with 2.6.38-8. I am even able to use wifi card in 'n mode' which wasn't possible before. Sadly, today I've noticed some heavy packet loss and after checking the logs it turned out it's the same error. It just appears less often.

[Lukas Winter (webmaster-geloescht)]

I get these errors as soon as I connect my TV screen over HDMI. My wireless connection is absolutely unusable until I disconnect it again. This is just one regression out of many that I experience since I upgraded to natty. I'd be very happy to see at least one of them fixed before I downgrade again or switch distributions.

[David Turner (dkturner)]

This continues to affect me on 2.6.38-9-generic-pae from -proposed. Wireless becomes unusable after a few hours.

uname -a:
Linux ceres 2.6.38-9-generic-pae #43-Ubuntu SMP Thu Apr 28 17:12:11 UTC 2011 i686 i686 i386 GNU/Linux

excerpted lspci:
04:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)

From dmesg:
[58864.888234] ath: Failed to stop TX DMA in 100 msec after killing last frame
[58864.888260] ath: Failed to stop TX DMA!

(repeated every few seconds)

Will provide more data on request. Have also tried latest stable compat-wireless but not yet bleeding edge.

[Sami Nieminen (sami-nieminen)]

I have the same problem and the same messages in dmesg output when the wireless connection stalls on heavy file transfer. It resumes after some time automatically. I still am running kernel 2.6.38-8-generic.

[Jacob Burkamper (jacob-burkamper)]

I have the same issue. dmesg reports the same problem, uname -r returns 2.6.38-8-generteic. I have ubuntu 11.04 64bit.

I would also like to add that ping times from wireless card to router are ridiculously high, even at idle. Using the wireless card at all is practically impossible, but only on a "g" router.

What I mean is that on my router at home, which is brand new 802.11n router (2x2), pings are flawless. The connection will only crash during heavy file transfers for half an hour or more. However, at work we have only 802.11 g, and in one place 802.11b routers. The wireless to these routers is almost unusable. pings are at >50ms at idle, and loading even a webpage will push pings up into the >500ms range. Any sort of file transfer returns the "failed to stop tx dma" message. This is a showstopping bug as I can not use my linux partition for work as I intended.

It is worth noting that the same laptop has no problems when loaded into my windows partition, so this is defintitely a linux-driver issue.

hardware is an atheros AR9287.

[SmokyMcPot (karl-trampe)]

I confirm that bug. My hardware is
05:01.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
I am running Kubuntu 11.04 64 Bit (linux 2.6.38-8-generic)

This bug makes my wireless networking useless. Please fix as fast as possible.

[Markus Schulewski (earlski-k)]

I confirm the bug!

System Information:
Ubuntu 11.04 (up to date: kernel 2.6.38-8)
additional information will follow...

Wifi Connection is established, but so slow that the network in unusable!
Changing back to Kernel 2.6.35-28-generic fixes the Problem.

Please change "importance" to high

[Markus Schulewski (earlski-k)]

lspci -vv

[Markus Schulewski (earlski-k)]

lspci -vvn

[Markus Schulewski (earlski-k)]

lspci -vvnn

[Markus Schulewski (earlski-k)]

Version:
Ubuntu 2.6.38-8.42-generic 2.6.38.2

uname -a:
Linux mpc 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

[Seth Forshee (sforshee)]

There's a report on the upstream bug report that this worked fine in 2.6.37, in which case we can do a bisection to determine which commit introduced the problem. First, can someone install the kernel at the following link and verify that the problem is not present? Thanks!

  http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-natty/

[Christoph Korn (c-korn)]

The error message does not appear with this kernel.
But the connection still disconnects.
Do I have to uninstall the old kernel first?

I better try a maverick or lucid live cd for testing.

[Seth Forshee (sforshee)]

@Christoph: Thanks for testing. You don't have to uninstall the old kernel. I just checked, and in the 2.6.37 build you will never get the messages, period, even if the condition that generates the messages exists. So whether or not you get the messages in earlier builds is no indication of whether or not the issue is happening.

There may be more than one problem here. Does 2.6.37 (or any other previous version) work for anyone? I'd especially like to hear back from the original reporter of the bug.

[Bart Rose (jbrose3)]

Also getting this error w/ AR5008 chipset. Able to detect networks, but unable to connect. Up to date Natty installation, with proposed ppa enabled.

[Lukasz Olszewski (olszewskil)]

Seth: I had no problems with my wireless on previous versions of Ubuntu. So if I remember correctly 2.6.36 was the last kernel working for me.

[Lukasz Olszewski (olszewskil)]

I've just tried kernel 3.0 from Oneiric and I don't see any errors in the syslog but the connection is still crippled :(

[Lukasz Olszewski (olszewskil)]

I've just upgraded to 11.10 alpha 2 and get the same problem with the same error message just much rarely than in 11.04.

[Andy (smiffy75)]

This bug affects me

[John Pugh (jpugh)]

Apparently Chromium OS has fixed these by patching comptat-wireless. These fixes apparently are in the 2.6.39 kernel tree?

Reference: http://code.google.com/p/chromium-os/issues/detail?id=13275

[Jg-jguk (jg-jguk)]

Is anyone working on this? I'll add a bug bounty £100 for a fix. Email me if interested with your proposal: jg at jguk.org

[Igor Cota (igor-cota)]

I've just tried Oneiric and this unfortunate bug is still here.
But here's something that might be useful: I have Natty downgraded to 2.6.36 (just to evade this bug) on another partition and when I did a warm reboot from Oneiric the bug was still there. I was quite surprised because I never had those issues before on .36 kernel. What also struck me was a Bluetooth indicator that was also never there before. The Bluetooth applet seemed functional but after a shutdown WiFi was back to normal and Bluetooth reports "no adapters".

Considering this all happened after a warm reboot maybe it's possible that powering up Bluetooth somehow messes with 802.11? Or it could be a faulty firmware uploaded?

[Jg-jguk (jg-jguk)]

ath9k on Ubuntu 11.10 with 3.0.0-12-generic-pae is 20x more reliable for me over the last 7 days since upgrade. I have Acer Aspire Timeline X 3820T laptop.

[Oguz Yarimtepe (oguzy)]

This problem still holds for Kubuntu 11.10, i am attaching the log files related with the issue. I can see that the ath9k driver is installed but the error messages continue at the boot up.

Removing the driver, reinstalling it or reinstalling it with the nohwcrypt=1 didn't solve the problem.

[Oguz Yarimtepe (oguzy)]

Here are some lines from syslog after disabling and enabling wireless

Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.871606] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.881187] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.895845] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x000062c0
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.895856] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.917358] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00008040
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.917363] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.985486] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.999785] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00008040
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.999791] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.069590] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.084040] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00008040
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.084045] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.153546] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.167925] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006040
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.167934] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.237487] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.251828] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006040
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.251839] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.321552] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.335944] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00008040
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.335954] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.405471] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.419871] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00008040
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5744.419881] ath: Could not stop RX, we could be confus...

[Spatialist (fsluiter)]

And I also confirm the bug, exact eroro messages as oguzy
On 11.10 with kernel 3.0.0-14-generic-pae
System: Acer aspire 5750g and atheros AR9287 wireless network adapter

It seems that the 3.0 kernel reintroduced the bug.
The wireless works ok for awhile, sometimes minutes, sometimes an hour and then stops suddenly.

It takes a powerdown/reboot to work again.

Can somebody check if the patch was applied in the 3.0 kernel? It does not seem to ban encryption problem, but more a race condition where the driver messes up the card.

[Lukasz Olszewski (olszewskil)]

Spatialist, do you get TX DMA error in your syslog? If not please check if you experience similar symptomps as described in bug #814035.

[Spatialist (fsluiter)]

Hi Lukasz,

I get exactly the same errors in dmesg as oguzy (I copy his, as my laptop has no network):
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.881187] ath: Failed to stop TX DMA!
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.895845] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x000062c0
Dec 30 14:57:03 gulsah-SATELLITE-PRO-C660 kernel: [ 5743.895856] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up

I did try the nohwcrypt=1, but that did not work at all (the error was actually getting worse, i.e. almost immediately after having connected to the router).

What might be significant is that some of the errors mention 100ms and oguzy and mine mention 10ms. Also when my wireless does work, the speed (8mb/s down) and ping (2ms to router) is normal and the indicator lighton the laptop is on. This changes to off, the errors appear in the logs and the network manager tries to reconnect, claiming that the connection needs a password, which it does already have.
With a powerdown and start, the connection comes back up, a simple restart is not enough. After a simple restart, the kernel does not recognize the network card anymore, lspci does not show it to be present on bus 3:0.0 where it previously was. With a simple restart to Windows it does not recognize the card sometimes also. I read somewhere that this type of card needs/gets a firmware reinitialisation every time a reboot occurs, so that might be important.

The all or nothing behaviour of the bug I see seems to me more consistent with a race condition than an encryption problem. Maybe this race condition changes when encryption is on/off.
I think the above patchby Christian Aravena, which (I think) adds a call to a semaphore in the ath9 driver, is not present in the 3.0 kernel driver and therefore the bug was reintroduced. Is there someone who can verify it not being present in this kernel? That would explain a lot.

[Александр (clif05)]

Hello. Any news? I have the same bug with my pci wi-fi card(dlink dwa 547) on atheros ar9223 chipset...

[Spatialist (fsluiter)]

No, no news at all.

I tried the developers list of the driver, but no response either.
It looks like it is a reintroduced bug. I do not have the time to test
compiling the driver and applying patches, in fact the laptop is now a
Microsoft system and I gave it to my mother in law ;-)

Good luck,

Floris

2012/2/11 Александр <email address hidden>:
> Hello. Any news? I have the same bug with my pci wi-fi card(dlink dwa
> 547) on atheros ar9223 chipset...
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/736171
>
> Title:
>  ath: Failed to stop TX DMA in 100 msec after killing last frame
>
> Status in The Linux Kernel:
>  Incomplete
> Status in “linux” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Message in dmesg:
>
>  [   22.308381] ath: Failed to stop TX DMA in 100 msec after killing last frame
>  [   22.308447] ath: Failed to stop TX DMA!
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/736171/+subscriptions

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "ath9k-Fix-race-in-starting-stopping-DMA" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[penalvch (penalvch)]

Chistian Aravena, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Cristian Aravena Romero (caravena)]

apport information

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[penalvch (penalvch)]

Cristian Aravena Romero, in order to allow additional upstream developers to examine the issue, at your earliest convenience, could you please test the latest upstream kernel available from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Please keep in mind the following:
1) The one to test is at the very top line at the top of the page (not the daily folder).
2) The release names are irrelevant.
3) The folder time stamps aren't indicative of when the kernel actually was released upstream.
4) Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds .

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Also, you don't need to apport-collect further unless specifically requested to do so.

It is most helpful that after testing of the latest upstream kernel is complete, you mark this report Status Confirmed.

Lastly, to keep this issue relevant to upstream, please continue to test the latest mainline kernel as it becomes available.

Thank you for your help.