Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1058979 - [ath9k_htc] TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n overheats [NEEDINFO]
Summary: [ath9k_htc] TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n overheats
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: fedora-kernel-wireless-ath
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-28 22:19 UTC by Alberto Ruiz
Modified: 2014-03-17 18:44 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-17 18:44:50 UTC
jforbes: needinfo?


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Linux Kernel 61111 None None None Never

Description Alberto Ruiz 2014-01-28 22:19:59 UTC
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]

Comment 1 Josh Boyer 2014-01-29 12:00:59 UTC
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.

Comment 2 Alberto Ruiz 2014-01-29 13:16:15 UTC
Sounds good. For now I've fixed the issue with an /etc/NetworkManager/dispatcher.d script.

Comment 3 John Greene 2014-01-29 20:59:31 UTC
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.

Comment 4 Alberto Ruiz 2014-01-30 13:54:17 UTC
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

Comment 5 John Greene 2014-01-30 19:01:55 UTC
(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?

Comment 6 Alberto Ruiz 2014-01-31 11:20:33 UTC
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.

Comment 7 Justin M. Forbes 2014-02-24 13:55:33 UTC
*********** 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.

Comment 8 Justin M. Forbes 2014-03-17 18:44:50 UTC
*********** 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.


Note You need to log in before you can comment on or make changes to this bug.