ath9k_usb: TL-WN821N v3 (AR7010+9287) Connection drops

Bug #1049383 reported by Pin on 2012-09-11
40
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
High
linux (Fedora)
Expired
Undecided
linux (Ubuntu)
Medium
Unassigned

Bug Description

Hi. The connection with this device is fast and stable, but seems to drop after a certain amount of data has been transmitted. The easiest way to reproduce it is to download something large. I can always reproduce it by downloading a torrent. After about 300-400MB, it seems like the wireless dongle hangs and the connection doesn't work anymore.

At this point, network commands such as iwconfig freeze, and it's also impossible to reboot or turn off the computer. However, if the wireless dongle is unplugged and plugged again, everything's back to normal.

The module is set with nohwcrypt=1. If this option is not set, the connection drops much faster. Also, I've noticed that the latency is lower with nohwcrypt=1 (using speedtest.net, the latency without hardware encryption is consistently 3 times less).

Description: Ubuntu 12.04.1 LTS
Release: 12.04

linux-generic:
  Installed: 3.2.0.30.32
  Candidate: 3.2.0.30.32
  Version table:
 *** 3.2.0.30.32 0
        500 http://es.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.2.0.29.31 0
        500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
     3.2.0.23.25 0
        500 http://es.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

*******Results of lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 005 Device 002: ID 046d:c00e Logitech, Inc. M-BJ58/M-BJ69 Optical Wheel Mouse
Bus 002 Device 004: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]

******* Results for modinfo ath9k_usb:
filename: /lib/modules/3.2.0-30-generic/kernel/drivers/net/wireless/ath/ath9k/ath9k_htc.ko
firmware: htc_9271.fw
firmware: htc_7010.fw
description: Atheros driver 802.11n HTC based wireless devices
license: Dual BSD/GPL
author: Atheros Communications
srcversion: 9B885B82530A1FF8F15C062
alias: usb:v0CF3p20FFd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0411p017Fd*dc*dsc*dp*ic*isc*ip*
alias: usb:v083ApA704d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0846p9018d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0CF3p7010d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1668p1200d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0CF3p7015d*dc*dsc*dp*ic*isc*ip*
alias: usb:v057Cp8403d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0CF3pB003d*dc*dsc*dp*ic*isc*ip*
alias: usb:v040Dp3801d*dc*dsc*dp*ic*isc*ip*
alias: usb:v04CAp4605d*dc*dsc*dp*ic*isc*ip*
alias: usb:v13D3p3350d*dc*dsc*dp*ic*isc*ip*
alias: usb:v13D3p3349d*dc*dsc*dp*ic*isc*ip*
alias: usb:v13D3p3348d*dc*dsc*dp*ic*isc*ip*
alias: usb:v13D3p3346d*dc*dsc*dp*ic*isc*ip*
alias: usb:v13D3p3328d*dc*dsc*dp*ic*isc*ip*
alias: usb:v13D3p3327d*dc*dsc*dp*ic*isc*ip*
alias: usb:v07D1p3A10d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0846p9030d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0CF3p1006d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0CF3p9271d*dc*dsc*dp*ic*isc*ip*
depends: ath9k_hw,ath9k_common,mac80211,ath,cfg80211
intree: Y
vermagic: 3.2.0-30-generic SMP mod_unload modversions
parm: debug:Debugging mask (uint)
parm: nohwcrypt:Disable hardware encryption (int)

Pin (chessmani-gmail) wrote :
Brad Figg (brad-figg) on 2012-09-11
affects: linux-meta (Ubuntu) → linux (Ubuntu)
Logan Rosen (logan) wrote :

Looks like this is the same as https://bugzilla.kernel.org/show_bug.cgi?id=42661. I'll add an upstream bug watch.

Pin (chessmani-gmail) wrote :

I've just found a link(https://bbs.archlinux.org/viewtopic.php?id=136928) that hinted at the possibility of device overheating and suggested reducing the transmission power. I made a test after doing

iwconfig wlan0 txpower 10

with a 4GB torrent and managed to download 3GB before the connectivity dropped and I had to replug the device. Still, it's strange as in Windows there's no such issue.

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: kernel-bug-exists-upstream kernel-da-key precise
Changed in linux (Ubuntu):
status: New → Triaged
Changed in linux:
importance: Unknown → High
status: Unknown → Confirmed
sawbona (sawbona) wrote :
Download full text (3.3 KiB)

Hello:

I am running 12.10 LTS and have the same/similar problem.

Connects at boot, remaining strong and stable but after a while, the connection will drop and the system will try to connect again.

This does not happen and after a while, although configured to connect automatically, the pop-up asking to connect (fields are not blank) comes up but connection does not happen and the pop-up comes up once again after a while.

Unplugging and replugging the USB dongle has the effect of freezing the system which requires a hard reset as ctrl-alt-del will not do. Another symptom when system freezes is that kb leds flash on and off repeatedly.

***

-- lsusb (snip)
Bus 001 Device 002: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]

***

Curiously enough, the hardware data on the label is 'TL-WN822N V2', which apparently has a different chipset.
I have seen this reported elsewhere.

--

modinfo ath9k_usb
ERROR: modinfo: could not find module ath9k_usb

modinfo ath9k_ath
ERROR: modinfo: could not find module ath9k_ath

modinfo ath9k

filename: /lib/modules/3.2.0-53-generic/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko
license: Dual BSD/GPL
description: Support for Atheros 802.11n wireless LAN cards.
author: Atheros Communications
srcversion: 426E3BAA91A2633D95E6FD2
alias: platform:ar934x_wmac
alias: platform:ar933x_wmac
alias: platform:ath9k
alias: pci:v0000168Cd00000037sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000034sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000033sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000032sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000030sv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Esv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Dsv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Csv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Bsv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Asv*sd*bc*sc*i*
alias: pci:v0000168Cd00000029sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000027sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000024sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000023sv*sd*bc*sc*i*
depends: ath9k_hw,ath9k_common,mac80211,cfg80211,ath
intree: Y
vermagic: 3.2.0-53-generic SMP mod_unload modversions 686
parm: debug:Debugging mask (uint)
parm: nohwcrypt:Disable hardware encryption (int)
parm: blink:Enable LED blink on activity (int)
parm: btcoex_enable:Enable wifi-BT coexistence (int)

***

iwconfig

lo no wireless extensions.

wlan1 IEEE 802.11bgn ESSID:"XXXXXX"
          Mode:Managed Frequency:2.412 GHz Access Point: 1C:AF:F7:17:2A:4C
          Bit Rate=65 Mb/s Tx-Power=20 dBm
          Retry long limit:7 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=49/70 Signal level=-61 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
 - Tx excessive retries:0 Invalid misc:1 Missed beacon:0

eth0 no wireless extensions.20 days)

***

I see this bug was confirmed as being of high imprtance almost year ago (in ~20 days).

Ar...

Read more...

Oleksij Rempel (olerem) wrote :

Hello all,
can you please test it with latest kernel, 3.12 if possible. If you still can reproduce this issue, i will need more information about your wireless configuration and usb host controller you using.

Javier Sánchez (javiersm) wrote :

I can confirm this issue according to previous comments. I am using kernel 3.2 (3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux).

From my observations, the issue happens also when I am using a VPN trough OpenVPN.

Am 20.10.2013 18:16, schrieb Javi:
> I can confirm this issue according to previous comments. I am using
> kernel 3.2 (3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux).

3.2.0 is not interesting. It should not include other changes except
some security fixes.
Please use 3.12 from here:
http://kernel.ubuntu.com/~kernel-ppa/mainline/ or better test latest
ubuntu relase, since different software parts can couse issue.

Right now i tested my TL-WN822N v2 (AR7010+9287) on Ubuntu 13.10. It was
able to transfer 6GB without any problems or loosing connection.

>>From my observations, the issue happens also when I am using a VPN
> trough OpenVPN.

Can you please describe it more detailed.

Some users reported that Keep alive setting of the AccessPoint was
reason similar issue.

If Ubuntu 13.10 have same problem, i will need more data:
- dmesg
- iw dev wlan0 scan dump
- info about AccesPoint causing problems: name, version, firmware.
- lspci and "lsusb -t"

--
Regards,
Oleksij

jonathan Devereux (jon-dev87) wrote :

Hi,

I am also experiencing this problem on Ubuntu 13.10 with TL-WN821N. Some additional information:

- This happens with exsessive constant downloading, if I am gaming online in intermittent downloading it's fine and no issues.
- Downloading large files at constant high-speeds and it can cut out every hour to 2 hours.
- This happens to me on both Windows and Linux, but much more frequent on Ubuntu.
- On ubuntu the whole system with hang, on Windows connection to the router is lost until the device is unplugged and plugged back in.
- System will completely hang until the device is unplugged.
- The dongle gets quite hot.

Oleksij Rempel (olerem) wrote :

Am 21.10.2013 10:10, schrieb jonathan Devereux:
> Hi,
>
> I am also experiencing this problem on Ubuntu 13.10 with TL-WN821N.

Thank you. Which TL-WN821N version do you use?
And please attach information i requested in previous post.

--
Regards,
Oleksij

Oleksij Rempel (olerem) on 2013-10-21
tags: added: ath9k-htc

Pin, 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 kernel 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.12-rc6

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.

tags: added: needs-kernel-logs needs-upstream-testing
removed: ath9k-htc
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Oleksij Rempel (olerem) wrote :

I purchased this device for testing. And i still can't reproduce your problem. So, if you have this issue, please provide more information.

Javier Sánchez (javiersm) wrote :

I still reproducing the bug in Ubuntu 13.04 and current-release (release 16oct). In current-release 07-nov wpasupplicant chased so I could not reproduce the bug.

However I've tested it both in Debian 7 (with firmware-atheros package and 3.2.0-4-amd64) and Debian 7 Live and it worked perfectly.

Javier Sánchez (javiersm) wrote :

Sorry, I Debian Live 7 it fails again after transferring 2GB.

Javier Sánchez Monedero, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

No need exists to comment here at this time. After reading the above documentation in it's entirety, if you have further questions, you are welcome to redirect them to the appropriate mailing list or forum via http://www.ubuntu.com/support/community/mailinglists , or you may contact me directly.

Thank you for your understanding.

Oleksij Rempel (olerem) wrote :

@penalvch
are you working on ath9k-htc firmware?

This bug also affects my AR9271 internal USB wifi device.

I've tried kernel 3.12.0-031200-generic but this did not help using vanilla settings.

I ended up using:
$ cat /etc/modprobe.d/cfg80211.conf
options ath9k_htc nohwcrypt=1

and set txpower to 12 at runtime to circumvent this problem.

Sander Brandenburg, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Oleksij Rempel (olerem) wrote :

@Sander, thank you for your feed back.
will it to the trick only by setting txpower, without nohwcrypt?

@Oleksij, it appears tougher to locate than I thought.

I'm back to kernel 3.11.0-15-generic. I tried to overheat by stressing the CPU, GPU and wireless device for 15 minutes by running stress --cpu 4, glxgears fullscreen (vsync on however) and setting txpower to 20 and pingflooding my gateway (sudo ping -f -s 1476 ). It did not succeed.

Only after 6-9 hours of moderately (ping -Di 0.2 -s 65507 192.168.1.1, you'll be the judge) pingflooding my gateway I got into this state where I could not ping my gateway anymore. Stopping the ping flood, waiting a while and trying a normal ping again did not appear to work. Only after suspending, waiting a while and resuming I can get the wifi adapter to function again. Resuming 1-2 seconds after suspending did not work for me. However, after this suspend-resume trick I can trigger the nonfunctional state quite easily after 10-15 minutes.

So I am a bit confused about whether this is related to overheating, if it takes such a long while to trigger. Can I enable some kind of debugging to show this behaviour?

Description of problem:
I have a TP-Link TL-WN821N v3 USB dongle that overheats and shuts itself specially under heavy operations. Googling a bit I've managed to figure out that it is possible to fix this by executing:
# iwconfig wlp0s26f7u3 txpower 12

I wonder if this option can be set by default.

Version-Release number of selected component (if applicable):
$ uname -rsv
Linux 3.12.8-300.fc20.x86_64 #1 SMP Thu Jan 16 01:07:50 UTC 2014

How reproducible:
Most times, if using a heavy load on the device (try a couple of bittorrents for a couple of minutes)

Steps to Reproduce:
1. Put the network interface under heavy load.
2. Wait long enough

USB device info:
Bus 001 Device 007: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros AR7010+AR9287]

We'd likely need to change it upstream, and if it's commonly needed maybe that would work. However, I'll let the wireless people weigh in.

Sounds good. For now I've fixed the issue with an /etc/NetworkManager/dispatcher.d script.

Interesting and a bit amusing..but I digress.
Will take a look. Curious: have you tried this fix yourself? Does it fix your problem? I don't have one of these on hand.

It definitively fixes it for me, I'm not the only one affected by this[0], so fixing upstream would make a lot of people happy.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=61111

(In reply to Alberto Ruiz from comment #4)
> It definitively fixes it for me, I'm not the only one affected by this[0],
> so fixing upstream would make a lot of people happy.
>
> [0] https://bugzilla.kernel.org/show_bug.cgi?id=61111

As I read through this kernel bug and debug efforts, it occurs to me that the issue being debugged is a firmware crash, leaving the device in a high power state causing it to heat or perhaps heat causing firmware to crash first with the same result.

The patch in https://bugzilla.kernel.org/show_bug.cgi?id=61111#c22 is really a workaround that limits tx rates to avoid overheat at high rates, but is not going to be a solution for upstream for a number of reasons. It's intended for a workaround for the self built kernel (I can build this for you?) but expect
it's temporary in nature.

The last patch they have is trying to gather more information on why the firmware is crashing.. I'm curious if there is some problem in the firmware that should be monitoring the device temp and failing to take action on to avoid this issue they are trying to get a handle on. Saddly I don't have access to the firmware source to be able to do that.

I could also build a kernel for you that would include the firmware crash dump we could feed back to the kernel bug developer in hopes of helping them isolate the issue. I don't have your device to test with, are you willing to help debug the issue if you could get kernel builds?

I'll be more than happy to serve as a guinea gig, if you hand me the builds I can get the dongle to crash and give back any sort of trace.

Just point me to the build and let me know the instructions to gather those firmware traces.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.

Is the upstream bug # on this accurate? https://bugzilla.kernel.org/show_bug.cgi?id=61111 " [ath9k_htc] device overheating and failure on TP-Link TL-WN821N v3 (Atheros AR7010+AR9287)" would seem a better match

Changed in linux (Fedora):
importance: Unknown → Undecided
status: Unknown → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.