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.