06.07.2013 09:31, Oleksij Rempel wrote: > Hi Michael, Hello! > there is no way to avoid latest wireless-testing kernel. I had similar problems for some kernel version. But now it seems to work more or less ok. For example it will nuke complete system only by triggering some bug in xhcd driver :) Hmm. Are you saying that no one cares about -stable, and bugs are only fixed in latest prereleases? If that's true, it is very unfortunate situation for the wireless subsystem... Thanks, /mjt > Am 05.07.2013 11:01, schrieb Michael Tokarev: >> Hello. >> >> Recently I bought a TP-Link TL-WN821N v3 802.11n USB adaptor, >> and tried to use it as an access point for a small Wireless LAN. >> >> It works fine so far, except of one issue. >> >> Quite often to be really annoying, it stops working with the >> following message in kernel log: >> >> Jul 5 09:51:26 gnome vmunix: [133814.449408] ath: Unable to remove station entry for: 38:aa:3c:02:07:f1 >> >> after this, the interface is stuck, it can't be seen over WIFI, >> and any attempt to do anything with it inside the host results >> in more processes entering D state (initially right when this >> happens, there's a kworker process in D state). >> >> For example, `rmmod ath9k_htc' - which appears to be a topmost >> module on the stack - results in rmmod entering D state, with >> the following stack: >> >> rmmod D 000000010266c10c 0 10684 10643 0x00000000 >> ffffffff8148b020 0000000000000082 0000000000012400 ffff88012ae9d7d0 >> ffff880114843fd8 ffff880114843fd8 ffff880114843fd8 ffff88012ae9d7d0 >> 0000000125aa5040 ffffffff8148b020 0000000000012400 ffff8801298cb500 >> Call Trace: >> [<ffffffff81367a59>] ? __schedule+0x3a9/0x960 >> [<ffffffff810558f0>] ? usleep_range+0x40/0x40 >> [<ffffffff81368e38>] ? __mutex_lock_slowpath+0xc8/0x140 >> [<ffffffff813689ba>] ? mutex_lock+0x1a/0x40 >> [<ffffffffa025bc66>] ? ath9k_wmi_cmd+0xc6/0x200 [ath9k_htc] >> [<ffffffffa02614d8>] ? ath9k_regread+0x38/0x50 [ath9k_htc] >> [<ffffffffa0076849>] ? ath_hw_keyreset+0x59/0x220 [ath] >> [<ffffffffa0076a2d>] ? ath_key_delete+0x1d/0xdc [ath] >> [<ffffffffa025edc5>] ? ath9k_htc_set_key+0x85/0x130 [ath9k_htc] >> [<ffffffffa0230d19>] ? ieee80211_key_disable_hw_accel+0x89/0x130 [mac80211] >> [<ffffffffa0230ddc>] ? __ieee80211_key_destroy+0x1c/0x80 [mac80211] >> [<ffffffffa0231505>] ? ieee80211_free_keys+0x45/0x80 [mac80211] >> [<ffffffffa02233a7>] ? ieee80211_do_stop+0x1f7/0x5c0 [mac80211] >> [<ffffffff812d9f40>] ? dev_deactivate_many+0x1f0/0x240 >> [<ffffffffa0223785>] ? ieee80211_stop+0x15/0x20 [mac80211] >> [<ffffffff812bc505>] ? __dev_close_many+0x85/0xd0 >> [<ffffffff812bc638>] ? dev_close_many+0x98/0x110 >> [<ffffffff812bc788>] ? rollback_registered_many+0xd8/0x250 >> [<ffffffff812bc90e>] ? unregister_netdevice_many+0xe/0x60 >> [<ffffffffa0222f00>] ? ieee80211_remove_interfaces+0xc0/0x100 [mac80211] >> [<ffffffffa0211096>] ? ieee80211_unregister_hw+0x46/0x110 [mac80211] >> [<ffffffffa02624c4>] ? ath9k_htc_disconnect_device+0x54/0xd0 [ath9k_htc] >> [<ffffffffa025b3a2>] ? ath9k_hif_usb_disconnect+0x52/0x150 [ath9k_htc] >> [<ffffffffa005dd52>] ? usb_unbind_interface+0x42/0x150 [usbcore] >> [<ffffffff81274546>] ? __device_release_driver+0x76/0xe0 >> [<ffffffff81274bf0>] ? driver_detach+0xa0/0xb0 >> [<ffffffff812743d0>] ? bus_remove_driver+0x70/0xc0 >> [<ffffffffa005d7a6>] ? usb_deregister+0xa6/0xc0 [usbcore] >> [<ffffffffa0262d36>] ? ath9k_htc_exit+0x6/0x16 [ath9k_htc] >> [<ffffffff81080ee2>] ? sys_delete_module+0x132/0x260 >> [<ffffffff8136a245>] ? page_fault+0x25/0x30 >> [<ffffffff81371552>] ? system_call_fastpath+0x16/0x1b >> >> followed by: >> >> Jul 5 10:02:27 gnome vmunix: [134474.473451] ath: Unable to remove interface at idx: 0 >> >> (rmmod is stuck forever). >> >> Now, in order to make the interface to work again, the only way I >> found so far is to _reboot_ the machine. For example, re-plugging >> the USB cord does not help, because, as far as I can see, the driver >> is in some weird state and can't initialize the new interface. >> >> This is a 3.2.0-stable kernel (right now 3.2.46), x86-64 (amd64), >> self-compiled, without additional patches. >> >> >> There are a few references to this message on the 'net, including >> one mentioning this very card (in russian) -- >> >> http://forums.opensuse.org/p-russian/dhydhdhdhdhundhdhdh/1046-1077-1083-1077-1079-1086/469022-wifi-usb-tp-link-tl-wn821n.html >> >> they claim the problem has been fixed for _some_ by upgrading the >> BIOS on the motherboard. Maybe this is actually related, because >> as far as I can tell, this started happening _after_ I upgraded >> BIOS on my motherboard, so it may be related to the bios changes. >> I don't recall whenever I noticed this erratic behavour before I >> upgraded BIOS. Looking at the BIOS history, I don't see anything >> interesting about USB in the changelog, except this: >> >> * Fixed issue with Fast Boot so USB devices still work under DOS >> if USB Optimization is enabled. >> >> This is an intel atom-based D2500CC board, with the latest BIOS. >> I had to update bios because of another issue which is now fixed, >> but I can't go back to the old bios because the old one was too >> old and current motherboard refuses to flash it. >> >> >> What can be done to diagnose the problem? I can give a more recent >> kernel a try, but I'd love to see it fixed for a -stable kernel which >> is used by several major distributions. Also, the problem is not >> easy to trigger, the system may work for a few days without issues >> or may stop working in a few hours, irrespective of the load (f.e. >> the above example at 09:51 was me awakening my android phone just >> to see what time it is now, and it trying to connect/disconnect >> to/from the default wifi network -- there were no other devices >> using wifi at that time). >> >> Thanks, >> >> /mjt >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel@xxxxxxxxxxxxxxx >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
