+++ This bug was initially created as a clone of Bug #713063 +++
Description of problem:
When I run multiple netperf clients on host, they connect with the
netperf-server in guest.
clients fail to execute cmds and output "interrupted system call"
Only happened with multi nics.
Version-Release number of selected component (if applicable):
Also can hit this problem in
so, not a regression.
Steps to Reproduce:
1. boot up a guest with multi nics (e1000)
2. setup and launch netperf server in guest
3. setup and launch multiple netperf client in host.
host)# while true;do ./netperf -t TCP_STREAM -H $guest_ip ;echo Tcp:$?;done &
host)# while true;do ./netperf -t UDP_STREAM -H $guest_ip;echo Udp:$?;done &
host)# while true;do ./netperf -H $guest_ip -- -m 200; echo $? Other:$?;done &
netperf clients outputted:
interrupted system call
netperf remote error 4
netperf commands completed.
--- Additional comment from email@example.com on 2011-06-21 13:37:31 EDT ---
is it related to https://bugzilla.redhat.com/show_bug.cgi?id=704097?
--- Additional comment from firstname.lastname@example.org on 2011-06-21 22:44:04 EDT ---
(In reply to comment #1)
> is it related to https://bugzilla.redhat.com/show_bug.cgi?id=704097?
Yes, looks related. 8193 also lacks the check of buffer availability before receiving packets. I can try this.
--- Additional comment from email@example.com on 2011-06-24 02:11:12 EDT ---
In step 1, I start guest with 4 nics.
In step 3, launch 4 netperf client in host. one netperf client per guest nic.
Just a comment about (ab)use of the UDP_STREAM test. There is no flow-control in UDP and a netperf UDP_STREAM test does not add any of its own, so those UDP_STREAM tests will no doubt be flooding the interconnect(s) with traffic.
This may very well blow the timing so out of the water that netperf will not be able to cope.
Looking at the code in src/nettest_bsd.c the "netperf remote error" is printing the value of response->serv_errno. There is no explicit setting of that to a value of four, which then implies that is an actual errno number from the system running netserver. In this case, where netperf and netserver systems are probably running the same/similar OS, that netperf attempts to do a perror() with that value is probably ok, but may not be the most "robust" thing to do, so in general, it is best to lookup the errno in the context of the system on which netserver was running. (I can never recall how standardized errno values are).
Also, I take it that is a "by hand" reciting of what netperf emitted rather than a direct cut-and-paste as there is a colon after netperf in the fprintf() calls in the source code :)