I send this again because my first mail accidently had html code in it and might have been filtered by some people. On Saturday 26 May 2007, Michael Buesch wrote: > On Saturday 26 May 2007 02:24:31 Stephen Hemminger wrote: > > Something is broken with the b44 driver in 2.6.22-rc1 or later. Now > > bisecting. The performance (with iperf) for receiving is normally 94Mbits > > or more. But something happened that dropped performance to less than > > 1Mbit, probably corrupted packets. > > > > There is nothing obvious in the commit log for drivers/net/b44.c, so it > > probably is something more general. > > > > > > Looking at the code in b44_rx(), I see a couple unrelated of bugs: > > 1. In the small packet case it recycles the skb before copying data > > out... Not good if new data arrives overwriting existing data. > > > > 2. Macros like RX_PKT_BUF_SZ that depend on local variables are evil!! > > Very interesting! > 2.6.22 doesn't include ssb, does it? > > Adding CCs to make reporters of another bugreport aware of this. I did some more tests with my BCM4401 and different kernels, here are the results: 2.6.21.1: iperf: [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001 [ 5] 0.0-60.6 sec 1.13 MBytes 157 Kbits/sec [ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 57837 [ 4] 0.0-63.1 sec 2.82 MBytes 375 Kbits/sec koala:~# ping -c10 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_seq=1 ttl=64 time=0.241 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.215 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.230 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.238 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.229 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.228 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.231 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.229 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.228 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.237 ms --- 192.168.1.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8998ms rtt min/avg/max/mdev = 0.215/0.230/0.241/0.018 ms The system was unusable while i ran the iperf test, when I moved the mouse it was only jumping around and doing anything like starting programs or switching the desktop first happend after iperf had finished it's test. I did a http downlaod with wget and got 11.23M/s. 2.6.22-rc3: [ 5] local 192.168.1.2 port 46557 connected with 192.168.1.1 port 5001 [ 5] 0.0-60.4 sec 58.9 MBytes 8.18 Mbits/sec [ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 51633 [ 4] 0.0-63.1 sec 7.27 MBytes 967 Kbits/sec koala:~# ping -c10 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_seq=1 ttl=64 time=0.243 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.234 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.238 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.235 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.230 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.317 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.232 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.232 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.228 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.238 ms --- 192.168.1.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8997ms rtt min/avg/max/mdev = 0.228/0.242/0.317/0.031 ms System responsiveness was the same as with 2.6.21.1. wget got 11.23M/s, again same as 2.6.21.1. 2.6.22-rc2-mm1: [ 5] local 192.168.1.2 port 42198 connected with 192.168.1.1 port 5001 [ 5] 0.0-60.1 sec 402 MBytes 56.1 Mbits/sec [ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 48598 [ 4] 0.0-63.0 sec 177 MBytes 23.6 Mbits/sec koala:~# ping -c10 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_seq=1 ttl=64 time=39.8 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=52.7 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=86.7 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=8.22 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=32.1 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=56.0 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=80.0 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.52 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=25.4 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=49.3 ms --- 192.168.1.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9000ms rtt min/avg/max/mdev = 1.526/43.207/86.700/26.369 ms Here system responsiveness was ok whil I ran iperf, I didn't notic anything anomalous. When I tried the wget http download the tranfer did stall and from this point on I couldn't send or receive anything on my BCM4401 anymore. Taken the interface down and up again didn't help anything. I wonder if this is Uwe's problem on all the kernels there apperaded nothing special in dmesg. for the iperf test I connect my BCM4401 directly with an e100. The system with the e100 was iperf server and ran fine all over the test. Maxi
Attachment:
signature.asc
Description: This is a digitally signed message part.
