Description of problem: I upgrade kernel from Koji to 3.4.1-1, and my wireless interface drop too many packages. I test cca. 1000 ping packet, and ~10-20 % packet loss. If I downgrade kernel-3.3.7-3, wireless interface work correctly, my ping statistic: 1900 packets transmitted, 1897 received, 0% packet loss, time 1901206ms rtt min/avg/max/mdev = 1.055/3.804/229.989/18.668 ms I ping my SOHO router. My interface: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n lsmod | grep htc ath9k_htc 65606 0 ath9k_common 13602 1 ath9k_htc ath9k_hw 408220 2 ath9k_common,ath9k_htc ath 23103 3 ath9k_hw,ath9k_common,ath9k_htc mac80211 492420 1 ath9k_htc cfg80211 195764 3 mac80211,ath,ath9k_htc Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Very high packet loss rate Expected results: Low packet loss rate Additional info:
Can we see the output of 'dmesg' from after a period of high packet loss?
Created attachment 589680 [details] dmesg after packet loss
64 bytes from router (10.0.0.128): icmp_req=394 ttl=255 time=1.26 ms 64 bytes from router (10.0.0.128): icmp_req=395 ttl=255 time=1.34 ms 64 bytes from router (10.0.0.128): icmp_req=396 ttl=255 time=1.34 ms 64 bytes from router (10.0.0.128): icmp_req=397 ttl=255 time=1.22 ms 64 bytes from router (10.0.0.128): icmp_req=398 ttl=255 time=1.34 ms 64 bytes from router (10.0.0.128): icmp_req=399 ttl=255 time=1.35 ms 64 bytes from router (10.0.0.128): icmp_req=400 ttl=255 time=1.36 ms 64 bytes from router (10.0.0.128): icmp_req=401 ttl=255 time=1.45 ms <--- 64 bytes from router (10.0.0.128): icmp_req=443 ttl=255 time=16.1 ms <--- 64 bytes from router (10.0.0.128): icmp_req=444 ttl=255 time=1.32 ms 64 bytes from router (10.0.0.128): icmp_req=445 ttl=255 time=1.25 ms 64 bytes from router (10.0.0.128): icmp_req=446 ttl=255 time=1.31 ms 64 bytes from router (10.0.0.128): icmp_req=447 ttl=255 time=1.19 ms 64 bytes from router (10.0.0.128): icmp_req=448 ttl=255 time=1.40 ms 64 bytes from router (10.0.0.128): icmp_req=449 ttl=255 time=1.32 ms 64 bytes from router (10.0.0.128): icmp_req=450 ttl=255 time=1.34 ms 64 bytes from router (10.0.0.128): icmp_req=451 ttl=255 time=1.36 ms 64 bytes from router (10.0.0.128): icmp_req=452 ttl=255 time=1.45 ms 64 bytes from router (10.0.0.128): icmp_req=453 ttl=255 time=1.33 ms ^C --- router ping statistics --- 453 packets transmitted, 385 received, 15% packet loss, time 452536ms rtt min/avg/max/mdev = 1.164/3.874/179.627/17.868 ms
Created attachment 589681 [details] messages
3.3.7-1 OK 3.3.7-3 OK 3.4.0-1 FAIL 3.4.1-1 FAIL
iwconfig wlan0 | sed 's/ESSID:.*$//' wlan0 IEEE 802.11bgn Mode:Managed Frequency:2.417 GHz Access Point: 00:04:E2:FC:35:D6 Bit Rate=54 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=43/70 Signal level=-67 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:1 Missed beacon:0 ifconfig wlan0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.0.2 netmask 255.255.255.0 broadcast 10.0.0.255 inet6 fe80::76ea:3aff:fe87:6d52 prefixlen 64 scopeid 0x20<link> ether 74:ea:3a:87:6d:52 txqueuelen 1000 (Ethernet) RX packets 4523 bytes 3094351 (2.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 4453 bytes 781271 (762.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
3.4.2-1.fc17.x86_64: 1424 packets transmitted, 1215 received, 14% packet loss, time 1424755ms rtt min/avg/max/mdev = 1.173/3.110/144.748/13.936 ms :( Latest good kernel: kernel-3.3.7-3.fc17.x86_64.
This regression likely driver related problem, not an 802.11. I tested other wireless interface: ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter lsmod | grep 8187 rtl8187 56911 0 eeprom_93cx6 13088 1 rtl8187 mac80211 497449 1 rtl8187 cfg80211 187660 2 mac80211,rtl8187 uname -r 3.4.2-1.fc17.x86_64 --- router ping statistics --- 1000 packets transmitted, 1000 received, 0% packet loss, time 1000298ms rtt min/avg/max/mdev = 0.951/3.482/248.647/18.092 ms My wireless router and wlan0 interface physical distance ~8 m. If I use my TP-LINK TL-WN722N interface, my ping statistic: --- router ping statistics --- 1000 packets transmitted, 863 received, 13% packet loss, time 1000170ms rtt min/avg/max/mdev = 1.118/3.080/143.325/13.424 ms But this interface work correctly, if I boot 3.3.7-3 kernel.
hardly any changes are going into ath9k_htc recently. please check you have the latest firmware http://linuxwireless.org/download/htc_fw/1.3/ could be a bug in h/w code which ath9k_htc and ath9k have in common.
I downloaded latest firmware from http://linuxwireless.org/download/htc_fw/1.3/, and compare: pwd /home/csaba cmp htc_9271.fw /lib/firmware/htc_9271.fw; echo $? 0 cmp htc_7010.fw /lib/firmware/htc_7010.fw; echo $? 0 I use latest firmware.
If I use kernel 3.4.2 or 3.3.7, same firmware loading into wireless device, independently from kernel release. (Sorry my very bad english.)
should be fixed by http://permalink.gmane.org/gmane.linux.kernel.wireless.general/93099 commit 931cb03afed7b541392295f3afc4638da32f08a0 Author: Rajkumar Manoharan <rmanohar.com> Date: Wed Jun 20 16:29:20 2012 +0530 ath9k_htc: configure bssid on ASSOC/IBSS change After the change "mac80211: remove spurious BSSID change flag", BSS_CHANGED_BSSID will not be passed on association or IBSS status changes. So it could be better to program bssid on ASSOC or IBSS change notification. Not doing so, is affecting the packet transmission. Cc: stable.org [3.4+] Reported-by: Michael Leun <lkml20120218.net> Signed-off-by: Rajkumar Manoharan <rmanohar.com> Signed-off-by: John W. Linville <linville>
Test kernels w/ the patch above are building here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4194787 When the finish building, please give them a try and post the results here...thanks!
Very thanks, you solved this problem! :) --- router ping statistics --- 1300 packets transmitted, 1300 received, 0% packet loss, time 1300782ms rtt min/avg/max/mdev = 1.077/3.459/229.913/14.332 ms lsmod | grep htc ath9k_htc 65679 0 ath9k_common 13602 1 ath9k_htc ath9k_hw 389899 2 ath9k_common,ath9k_htc ath 23103 3 ath9k_common,ath9k_htc,ath9k_hw mac80211 497449 1 ath9k_htc cfg80211 187660 3 ath,mac80211,ath9k_htc uname -r 3.4.4-1.bz828731.1.fc17.x86_64 My usb wireless interface (TP-LINK TL-WN722N): Bus 001 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Patch applied to f17 kernels, should be picked-up in next build.
kernel-3.4.4-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/kernel-3.4.4-3.fc17
kernel-3.4.4-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kernel-3.4.4-3.fc16
Package kernel-3.4.4-3.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.4.4-3.fc17' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9988/kernel-3.4.4-3.fc17 then log in and leave karma (feedback).
Perhaps it isn't the same bug, but I experienced similar symptoms with the iwlwifi driver on an Intel Corporation Centrino Ultimate-N 6300 (rev 3e). kernel-3.3.7-1.fc16.x86_64 works. kernel-3.4.2-1.fc16.x86_64 has the problem. kernel-3.4.4-3.fc16.x86_64 is fixed. Thanks, all.
kernel-3.4.4-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 834850 has been marked as a duplicate of this bug. ***
kernel-3.4.4-4.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kernel-3.4.4-4.fc16
kernel-3.4.4-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.