summaryrefslogtreecommitdiffstats
path: root/net
diff options
context:
space:
mode:
authorStefan Hajnoczi <stefanha@linux.vnet.ibm.com>2012-08-24 13:50:30 +0100
committerStefan Hajnoczi <stefanha@gmail.com>2012-09-14 08:40:33 +0100
commit61518a74ca98870e8ff132f91dd5dda252e31f58 (patch)
tree72d897f85b440b0ba970c0ae4780598b73ec752c /net
parent190563f9a90c9df8ad32fc7f3e4b166deda949a6 (diff)
downloadhqemu-61518a74ca98870e8ff132f91dd5dda252e31f58.zip
hqemu-61518a74ca98870e8ff132f91dd5dda252e31f58.tar.gz
net: broadcast hub packets if at least one port can receive
In commit 60c07d933c66c4b30a83b7ccbc8a0cb3df1b2d0e ("net: fix qemu_can_send_packet logic") the "VLAN" broadcast behavior was changed to queue packets if any net client cannot receive. It turns out that this was not actually the right fix and just hides the real bug that hw/usb/dev-network.c:usbnet_receive() clobbers its receive buffer when called multiple times in a row. The commit also introduced a new bug that "VLAN" packets would not be sent if one of multiple net clients was down. The hw/usb/dev-network.c bug has since been fixed, so this patch reverts broadcast behavior to send packets as long as one net client can receive. Packets simply get queued for the net clients that are temporarily unable to receive. Reported-by: Roy.Li <rongqing.li@windriver.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Diffstat (limited to 'net')
-rw-r--r--net/hub.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/net/hub.c b/net/hub.c
index ac157e3..650a8b4 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -97,12 +97,12 @@ static int net_hub_port_can_receive(NetClientState *nc)
continue;
}
- if (!qemu_can_send_packet(&port->nc)) {
- return 0;
+ if (qemu_can_send_packet(&port->nc)) {
+ return 1;
}
}
- return 1;
+ return 0;
}
static ssize_t net_hub_port_receive(NetClientState *nc,
OpenPOWER on IntegriCloud