Arch Linux

I have a update about the bug i think.
iwconfig wlan0 on kernel 2.6.28.8:

wlan0 IEEE 802.11bg ESSID:"linksys"
Mode:Managed Frequency:2.437 GHz Access Point: 00:18:F8:42:56:0F
Bit Rate=11 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Power Management:off
Link Quality=16/100 Signal level:65/65
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

iwconfig wlan0 on kernel 2.6.29.1-3:

wlan0 IEEE 802.11bg ESSID:"linksys"
Mode:Managed Frequency:2.437 GHz Access Point: 00:18:F8:42:56:0F
Bit Rate=11 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Power Management:off
Link Quality=31/100 Signal level:-69 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

I hope this helps.

Please report upstream.

I may have made a break in this bug. We change the 'Rate control algorithm' to mistrel. In the older kernel it was pid.

I will recompile the kernel with pid 'Rate control algorithm' to see if it fixes the problem.

To my knowledge, only minstrel is supported upstream these days.

I found that out too. Sorry. Thought/hoped it was a simple fix in the config.

I think i may have found something. It maybe a a usb bug.

in kernel 2.6.28:
Mar 25 12:37:33 arch-live kernel: usbcore: deregistering interface driver rtl8187
Mar 25 12:37:33 arch-live kernel: r8169: eth0: link down
Mar 25 12:37:33 arch-live kernel: phy1: Selected rate control algorithm 'pid'
Mar 25 12:37:33 arch-live kernel: phy1: hwaddr 00:18:4d:5f:d8:7f, RTL8187vB (default) V1 + rtl8225z2
Mar 25 12:37:33 arch-live kernel: usbcore: registered new interface driver rtl8187

in kernel 2.6.29:
Apr 22 01:14:34 arch-live kernel: usbcore: deregistering interface driver rtl8187
Apr 22 01:14:34 arch-live kernel: r8169: eth0: link down
Apr 22 01:14:34 arch-live kernel: usb 1-6: reset high speed USB device using ehci_hcd and address 3
Apr 22 01:14:35 arch-live kernel: wmaster0 (rtl8187): not using net_device_ops yet
Apr 22 01:14:35 arch-live kernel: phy1: Selected rate control algorithm 'minstrel'
Apr 22 01:14:35 arch-live kernel: wlan0 (rtl8187): not using net_device_ops yet
Apr 22 01:14:35 arch-live kernel: phy1: hwaddr 00:18:4d:5f:d8:7f, RTL8187vB (default) V1 + rtl8225z2
Apr 22 01:14:35 arch-live kernel: usbcore: registered new interface driver rtl8187

You will notice that its when reset high speed usb device that the net_device_ops happen. This doesn't happen in kernel 2.6.28.

PS. I forgot to tell you guys that i'm using netgear wg111v2 USB. Its build with a rtl8187 chip in it.

I think I had the net_device_ops message too in 2.6.29 with iwl3945 (it's gone in .30)

2.6.30-rc3 doesn't fix my upload bug. :(

Good news everyone!!!

I found a fix. I have reversed 8 patches for rtl8187 and got it my upload back to where it should be.

I going to try to narrow it down since the first for 4 patches i try didn't do anything to fix it i think.

there is are the last 4 by name in http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=summary
rtl8187: fix retry count passed in rtl8187_tx
rtl8187: Fix transmission count sent to mac80211
rtl8187: implement conf_tx callback to configure tx queues
rtl8187: fix 8187B throughput regression

I don't think i have to add all 8 back just these 4. Building another kernel with these 4 patchs reversed to see if upload works fine.

The last 4 patches i wrote about still fix the problem. So thats narrows it down to just 4 patches from 8. :)

I couldn't fix the bug with reversing some patches. But i think the main problem is very high packet drops.

on kernel 2.6.28 with 'ping -c 40 google.com':
0% packets drop

on kenrel 2.6.29 with 'ping -c 40 google.com':
75% of the packets are dropped.

This may explain why there is a slow upload with rtl8187. With that high of a packet drop it will not be uploading very fast at all.

If you have such drops, it could be that you have to change the send/receive power.
I don't know if the module supports such a parameter, but that would be an idea.

I got some good news. I got the packets to stop dropping. Its now 0%, Bad news is it didn't fix the upload problem to where is was before kernel 2.6.29.
code:
iwconfig wlan0 txpower off

I hope this helps.

I used tcpdump today to see how many packets are dropped when i upload files.
code:
tcpdump -C 4 -B 128 -i wlan0

in kernel 2.6.29
5001 packets captured
8458 packets received by filter
3457 packets dropped by kernel

I come back later to so what it is on kernel 2.6.28.

I just did it on kernel 2.6.28 now
code:
tcpdump -C 4 -B 128 -i wlan0

9933 packets captured
9933 packets received by filter
0 packets dropped by kernel

No packets are dropped on kernel 2.6.28. Don't know why this is happening but at least i know whats cause the upload speed drop now on kernel 2.6.29.

status with the 2.6.30?

The bug is still there.