Messages in this thread |  | | From | Maximilian Engelhardt <> | Subject | Re: b44: regression in 2.6.22 (resend) | Date | Sun, 27 May 2007 21:25:17 +0200 |
| |
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 [unhandled content-type:application/pgp-signature] |  |