Netperf tests cause i82551 network down

Bug #808588 reported by Amos Jianjun Kong
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Stefan Weil

Bug Description

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

Revision history for this message
Amos Jianjun Kong (amoskong) wrote :
Revision history for this message
Amos Jianjun Kong (amoskong) wrote :

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

Revision history for this message
Amos Jianjun Kong (amoskong) wrote :
Changed in qemu:
assignee: nobody → Stefan Weil (ubuntu-weilnetz)
Revision history for this message
Amos Jianjun Kong (amoskong) wrote :

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

Revision history for this message
Thomas Huth (th-huth) wrote :

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?

Changed in qemu:
status: New → Incomplete
Revision history for this message
Thomas Huth (th-huth) wrote :

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...

Changed in qemu:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.