On Mon, May 30, 2011 at 12:26 AM, Cedric Sodhi <man...@gmx.net> wrote: > Thank you for your replies. I did not reply to this thread so far > because the issue appears to have vanished. Which, by itsself, is > nothing interesting as it kept emerging sporadically and I could > sometimes go months without it. And since I do not recall having changed > anything I assume that this is the case right here. > > So I'll get back to you either when it comes up again or I can concluded > that it is gone for good.
sure thanks. > > Thanks. > > On Sat, May 28, 2011 at 07:00:02PM +0530, Mohammed Shafi wrote: >> On Fri, May 27, 2011 at 9:36 PM, Maciej Mrozowski <reave...@gmail.com> wrote: >> > On Wednesday 25 of May 2011 08:58:53 Cedric Sodhi wrote: >> >> Dear list, >> >> >> >> I use a Atheros HTC USB Wireless Device TL-WN721N with 9271. This is >> >> basically a very new devices which received a lot of positive reviews. >> >> And linux people keep insisting that Atheros are one of the better Wifi >> >> choices to make on linux. But I'm not getting anywhere this device! >> > >> > While it may be apples vs oranges comparison but I have identical - "No >> > probe >> > response" with my TL-WN821N V3 (AR9287+AR7010) USB device using recent >> > wireless testing (at 1e4541b73b33f9918255f36a60bdeacfae4fdb9d + htc_7010.fw >> > 1.3 firmware). >> > >> >> I did try to recreate the issue but nothing helped. may be I can >> increase the range or test it under more noisy environment >> >> >> > On disconnect - no attempt to recover (my net.wlan script needs to be >> > restarted manually, maybe I jsut takes some time?) : >> > wlan0: detected beacon loss from AP - sending probe request >> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after >> > 500ms, try 1/5 >> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after >> > 500ms, try 2/5 >> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after >> > 500ms, try 3/5 >> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after >> > 500ms, try 4/5 >> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after >> > 500ms, disconnecting. >> > Tx BA session stop requested for 68:7f:74:77:36:bc tid 0 >> > Rx BA session stop requested for 68:7f:74:77:36:bc tid 0 >> > Rx BA session stop requested for 68:7f:74:77:36:bc tid 7 >> > Tx BA session stop requested for 68:7f:74:77:36:bc tid 0 >> > ieee80211 phy0: Removed STA 68:7f:74:77:36:bc >> > ieee80211 phy0: Destroyed STA 68:7f:74:77:36:bc >> > ieee80211 phy0: device now idle >> > Stopping Tx BA session for 68:7f:74:77:36:bc tid 0 >> > Could not find station: 68:7f:74:77:36:bc >> > Stopping Tx BA session for 68:7f:74:77:36:bc tid 0 >> > Could not find station: 68:7f:74:77:36:bc >> > cfg80211: All devices are disconnected, going to restore regulatory >> > settings >> > cfg80211: Restoring regulatory settings >> > cfg80211: Adding request for country PL back into the queue >> > cfg80211: Kicking the queue >> > cfg80211: Calling CRDA for country: CN >> > ieee80211 phy0: device no longer idle - scanning >> > ieee80211 phy0: device now idle >> > >> > I do have a couple of related debug features in kernel (debugfs for >> > mac80211 >> > and ath9k_htc included) - what info exactly would you like me to provide? >> > Or >> > maybe some test scenario? >> >> anything... when the disconnection happen the prior mesgs will be useful >> >> > >> > Also some other strange issue I observed with ath9k_htc (just for record, >> > I'll >> > report details them when I run on them again): >> > - occasionally it happens I need to change USB port in order to get driver >> > re- >> > initialized (as it occasionally happens that device enters some locked >> > state - >> > 'net.wlan stop' hangs waiting for it and it needs to be removed from USB >> > port >> > to go further. Also after such operation sometimes this USB port appears >> > to be >> > useless and even rmmod && modprobe (also on mac80211 and cfg80211 just in >> > any >> > case) + reinserting USB stick doesn't help (error loading firmware), but >> > plugging to a different USB port works. >> > >> > A bit earlier (before a set of driver and firmware patches was applied by >> > Sujith last week) driver was "broken" to the point that it was actually >> > causing my WiFi router Cisco LinkSys WRT120N to freeze completely (router >> > cold >> > reset was required in order to restore router operability) - this one is >> > fixed >> > so don't bother - just for reference. >> > >> > -- >> > regards >> > MM >> > >> > _______________________________________________ >> > ath9k-devel mailing list >> > ath9k-devel@lists.ath9k.org >> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> > >> > >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel@lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
