Problem description: Using kernel 2.6.27 or newer, I am unable do download something faster than about 40KB/s despite the fact that on the same machine and with the same internet connection and older kernel (2.6.26.2) I am getting 300-400KB/s (although iwconfig shows rate 11Mb/s, but it is different issue). No matter if I set the transfer rate to 1Mb/s or 11Mb/s (54Mb/s is not possible). I found that this regression was introduced between 2.6.26 and 2.6.27-rc2 (On 2.6.27-rc1 the internet doesn't work at all) and hasn't been fixed until 2.6.29. Compiling the driver as a module or statically have no effect. The same with other options. Regression appeared in: 2.6.27 Distribution: My own partially based on LFS Software environment: ppp 2.4.4b1 glibc 2.7 wireless-tools 29 inetutils 1.5 gcc 4.2.4 GNU make 3.81 binutils 2.18 util-linux-ng 2.14.1 module-init-tools 3.6 procps 3.2.7 kbd 1.14.1 udev 137 CPU: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) processor stepping : 2 cpu MHz : 1111.018 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow up bogomips : 2223.40 clflush size : 32 power management: ifconfig output: lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 txqueuelen:0 wlan0 Link encap:Ethernet HWaddr 00:80:C6:E8:5B:04 inet addr:192.168.0.8 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 txqueuelen:1000 iwconfig output: wlan0 IEEE 802.11b ESSID:"xxxxxxxx" Mode:Managed Frequency:2.412 GHz Access Point: 00:4F:62:17:88:99 Bit Rate=1 Mb/s Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Power Management:off Link Quality=60/100 Signal level:-100 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 version: Linux version 2.6.26 (system@kminix) (gcc version 4.2.4) #2 SMP Thu Apr 2 17:18:01 CEST 2009 and Linux version 2.6.27-rc2 (system@kminix) (gcc version 4.2.4) #1 SMP Sat Apr 4 13:29:55 CEST 2009 dmesg output and kernel config: in attachment Network card: Wireless PCI Adapter RT2400 / RT2460
Created attachment 20800 [details] dmesg output and kernel config (2.6.26 and 2.6.27-rc2)
Please enable debugfs support for rt2x00 and use the script: http://kernel.org/pub/linux/kernel/people/ivd/tools/rt2x00_regdump.sh on 2.6.26 and 2.6.27-rc2 to obtain register dumps from the 2 cases. Make sure that you make the dump when the interface is up and supposed to be working. Thanks
Created attachment 21462 [details] rt2400 register dumps in 2.6.26 and 2.6.27-rc2
Excuse me for not writing for so log, but I've been very busy. I've made 3 register dumps for each kernel: one before connecting to the network, one right after connecting and one during download. I've also included dmesg output. The registers after connecting to the network are indeed quite different, but I was suprised that there is one difference before connecting - csr, line 60th. It seems that sometimes (2.6.29) it is possible to download something with speed reaching 130-140kB/s and an average speed about 60kB/s, but it is still far less than it used to be (and less than transfer rate, which I couldn't change anyway).
Created attachment 21468 [details] Change basic_rate mask Could you try attached patch? Not sure if it will apply, but the change should be simple enough for a manual change as well. ;)
I've applied this patch to 2.6.29.1 (it was to difficult for me to apply it to kernel 2.6.27-rc2) and it helped a lot. Now it is possible to download at full speed. Thanks for help.
I've checked 2.6.30-rc8-git5 kernel and downloading is still very slow. Will this bug be fixed in final release or in future mainline kernels?
Getting very late for 2.6.30...Ivo, have you posted that one on linux-wireless?
(In reply to comment #8) > Getting very late for 2.6.30...Ivo, have you posted that one on > linux-wireless? No I haven't, but I won't either. The patch is very bad and I only attached it to see if this bug falls under the same category/cause as some other speed-related bugs. For example, this bug is exactly the same bug only on different hardware: [Bug 13362] rt2x00: slow wifi with correct basic rate bitmap http://bugzilla.kernel.org/show_bug.cgi?id=13362 The basic problem is that invalid data was written to the registers in 2.6.26 because of a bug in mac80211. This apparently triggered rt2x00 to transmit frames quite fast, but the specs indicate the value that was written was completely invalid and I actually expected that nothing would be transmitted or at least terribly slow with that invalid value.
So it is more complicated than I thought. Since the time needed to fix it might be quite long, wouldn't it be reasonable to apply some temporary hack to 2.6.30 (or 2.6.30.1) to allow faster downloads? The patch may be bad, but it works. Anyway, if you need any testing, I can help.
Well it even gets harder then that, I now that the patch fixes the problem for your hardware, but since it is an invalid value, I am not sure if it will negatively impact other devices. Problems with slow bitrates have been reported for all kernel versions so far, so what is a regression for some users was not nesceserrily a regression for another user... :(
Any news in this matter?
Created attachment 22990 [details] Fix ACK timeouts causing too many failures for TX frames. Please try this patch.
I've applied this patch but it didn't help at all. Still no more than 40-32 KB/s. On both 2.6.29 and 2.6.31. What is more, 2.6.31 may contain another bug as 'iwlist wlan0 scan' shows link quality 10/70 for all notworks. But it is a minor one.
Gertjan, Ivo, anything more to add here?
I'm declaring this one dead -- I don't forsee any further work to improve rt2400 performance...