I recently did a pacman -Syu
update on my Arch laptop, and this came with the new 2.6.38 kernel (wonder patch, yay!
). However, since then, I've been having sporadic problems with my wireless connectivity, i.e. I get tons of dropped packets, and iwconfig reports a bunch of Tx excessive retries and "Invalid misc" counts.
Now, I can still navigate the web okay, but because of this problem, it's often much
slower than usual loading up a page, and doing other network-intensive things, such as doing a system update/sync are slowed to a crawl as well.
From the iwconfig man page:
Tx excessive retries
Number of packets that the hardware failed to deliver. Most MAC
protocols will retry the packet a number of times before giving
Other packets lost in relation with specific wireless opera‐
The description is vague, but my guess would be that the driver's at fault here. It didn't used to do this with kernel 2.6.37 and below; it would
drop packets on rare
occasion, but it was nowhere near as bad as this. Here's the iwconfig wlan0
output from having just reconnected:
wlan0 IEEE 802.11bgn ESSID:"XXXXXXXXXXXXX"
Mode:Managed Frequency:2.412 GHz Access Point: 00:24:B2:03:E1:EE
Bit Rate=150 Mb/s Tx-Power=17 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Link Quality=42/70 Signal level=-68 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:1 Invalid misc:23 Missed beacon:0
As you can see, there are several "Invalid misc"s, and this only recently started happening with the new kernel. The number has gone up since making this post on both that and the Tx excessive retries.
output to (hopefully) give a better idea of how bad this is:
[mrcode@lappy486 ~]$ ping -c 15 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=5.97 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=4.82 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=2.75 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=4.62 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=9.18 ms
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=2.57 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=8.75 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=6.08 ms
64 bytes from 192.168.1.1: icmp_req=12 ttl=64 time=5.15 ms
64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=5.87 ms
64 bytes from 192.168.1.1: icmp_req=14 ttl=64 time=6.19 ms
64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=2.58 ms
--- 192.168.1.1 ping statistics ---
15 packets transmitted, 12 received, 20% packet loss, time 14033ms
rtt min/avg/max/mdev = 2.579/5.381/9.186/2.065 ms
^ This is not
good. Is there anything I can do about this? Is it the driver's fault? Will I have to roll back my kernel?
My laptop's WNIC is an Atheros AR9285 PCI-e, confirmed to be using the ath9k driver:
lspci | grep "Net"
description: Wireless interface
product: AR9285 Wireless Network Adapter (PCI-Express)
vendor: Atheros Communications Inc.
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlan0
width: 64 bits
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=ath9k driverversion=2.6.38-ARCH firmware=N/A ip=192.168.1.4 latency=0 link=yes multicast=yes wireless=IEEE 802.11bgn
resources: irq:16 memory:f0700000-f070ffff
03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
EDIT: Update: There is a bug on the kernel tracker about this problem here
, and I've tried passing nohwcrypt=1 to ath9k when modprobing it, but while it seems to work for a short while, it then completely locks up the system (kernel panic?), i.e. no mouse/keyboard, X frozen, no SSH access, can't even ping the machine.
Also, if I try to roll back my kernel, I end up in dep hell: downgrading kernel26 requires downgrading nvidia, virtualbox, virtualbox-guest-additions, and virtualbox-guest-modules, but when trying to downgrade virualbox-guest-modules, it complains of nvidia requiring kernel26<2.6.38, when I've already rolled it back to 2.6.37!