summary refs log tree commit diff stats
path: root/results/scraper/launchpad/808588
blob: c35c3770e6b7211824a1b749e1645d2bb0035372 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
Netperf tests cause i82551 network down

1. boot up a guest with 82551 nic
# qemu-kvm -net nic,model=i82551 ...
2. launch netperf server in the guest
3.on the host 
for b in 32 64 128 256 512 1024 1460 2048 4096 8192  9000 16384 32768  65495 65507
do ./netperf -t TCP_STREAM -f m -H <guest ip> -P 0 -l 10 -- -m $b
done

for b in 32 64 128 256 512 1024 1460 2048 4096 8192  9000 16384 32768  65495 65507
do ./netperf -t UDP_STREAM -f m -H <guest ip> -P 0 -l 10 -- -m $b
done


Result:
Guest network becomes down


netperf client output:
./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 32
 87380  16384     32    10.97      19.61
./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 64
 87380  16384     64    11.55      79.68
./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 128
 87380  16384    128    10.16      14.20
./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 256
 87380  16384    256    11.17      12.85
./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 512
 87380  16384    512    10.01      16.38
./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1024
Interrupted system call
netperf: remote error 4./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1460
establish control: are you sure there is a netserver listening on 10.66.9.39 at port 12865?
establish_control could not establish the control connection from 0.0.0.0 port 0 address family AF_UNSPEC to 10.66.9.39 port 12865 address family AF_UNSPEC
./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 2048


qemu debug message:
....
EE100   nic_receive             command 0x0000, link 0x3d3e6822, addr 0xffffffff, size 1518
EE100   nic_can_receive         0x29a0180
EE100   nic_receive             0x29a0180 received broadcast, len=60
EE100   nic_receive             Receive buffer (0 bytes) too small for data (60 bytes); data truncated
EE100   nic_receive             command 0x8000, link 0x37b32022, addr 0xffffffff, size 0
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EE100   nic_receive             receive: Running out of frames
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
EE100   eepro100_write1         addr=Command/Status+1 val=0x20



kvm version:
qemu-kvm:  commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021
Date:   Mon Jul 4 13:36:06 2011 +0300

related fix in driver:
http://marc.info/?l=linux-netdev&m=118859393206222&w=3


1. When bug reproduces, we can only capture arp request in the tap device.   

# tcpdump -i tap0
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:14:11.741203 ARP, Request who-has 10.66.8.167 tell 10.66.8.252, length 28
16:14:12.741186 ARP, Request who-has 10.66.8.167 tell 10.66.8.252, length 28
16:14:13.741183 ARP, Request who-has 10.66.8.167 tell 10.66.8.252, length 28

2. Execute 'system_reset' in qemu monitor,  guest could not get ip address.

# tcpdump -i tap0
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:16:21.508588 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
16:16:21.682585 IP6 :: > ff02::1:ff12:3456: ICMP6, neighbor solicitation, who has fe80::5054:ff:fe12:3456, length 24
16:16:22.682616 IP6 fe80::5054:ff:fe12:3456 > ff02::2: ICMP6, router solicitation, length 16
16:16:23.105303 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:56 (oui Unknown), length 300
16:16:25.837597 IP6 fe80::5054:ff:fe12:3456 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
16:16:26.682594 IP6 fe80::5054:ff:fe12:3456 > ff02::2: ICMP6, router solicitation, length 16
16:16:30.111097 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:56 (oui Unknown), length 300
16:16:30.682598 IP6 fe80::5054:ff:fe12:3456 > ff02::2: ICMP6, router solicitation, length 16
16:16:39.112289 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:56 (oui Unknown), length 300
16:16:43.107232 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:56 (oui Unknown), length 300


The patch mentioned in comment #3 had been included in the kernel here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7734f6e6bcd7ba78b00e93e74a4ddafd9886cdea
So I guess we can close this bug nowadays? Or can you still reproduce this issue with the current kernel and current version of QEMU?

There hasn't been a reply to my question in the last comment within
months, so I assume nobody cares about this anymore. So I'm closing this
ticket now...