From owner-freebsd-bugs Fri Mar 7 10: 0:26 2003 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A76CB37B407 for ; Fri, 7 Mar 2003 10:00:24 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D85543F75 for ; Fri, 7 Mar 2003 10:00:24 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h27I0NNS095771 for ; Fri, 7 Mar 2003 10:00:23 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h27I0Ngi095765; Fri, 7 Mar 2003 10:00:23 -0800 (PST) Date: Fri, 7 Mar 2003 10:00:23 -0800 (PST) Message-Id: <200303071800.h27I0Ngi095765@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Gustav Wibling Subject: Re: kern/44126: lnc network hungup at large traffics on VMware (R esend) Reply-To: Gustav Wibling Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/44126; it has been noted by GNATS. From: Gustav Wibling To: "'freebsd-gnats-submit@FreeBSD.org'" , "'tam@math.kobe-u.ac.jp'" Cc: Subject: Re: kern/44126: lnc network hungup at large traffics on VMware (R esend) Date: Fri, 7 Mar 2003 09:52:21 -0800 The reason this happens on VMware is due to a race in the driver. This race is exposed by virtual hardware because things happens more in clusters. The problem was caused by the line outw(sc->rdp, RINT | INEA) at the end of the lnc_rint function. What happens is that from the end of the while loop to the outw writes/acks the RINT in the LANCE status register the receive ring fills up with new data and the RINT written in the status register due to this will be acked without the driver handling the new packets. No new RINT interrupts will be generated because the hardware is unable to get a valid receive dsc. (The ring is full). The guest won't handle the packets because it received no interrupt from the hardware. By removing this line the caller of lnc_rint will do a read and an ack and then handle what it read, instead of just unconditionally acking. This seems like the correct thing to do. This is very unlikely to happen on real hardware because it normally takes time to receive, in this case, 8 packets. On virtual hardware this can be done very fast because it is mainly a memcpy. The next release of VMware Workstation will have a workaround for this. Thanks, Gustav Wibling Member of Tech. Staff VMware, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message