From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BYB6L-0004T7-6a for qemu-devel@nongnu.org; Wed, 09 Jun 2004 17:59:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BYB6J-0004SW-KX for qemu-devel@nongnu.org; Wed, 09 Jun 2004 17:59:16 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BYB6J-0004ST-IK for qemu-devel@nongnu.org; Wed, 09 Jun 2004 17:59:15 -0400 Received: from [81.228.11.115] (helo=av9-1-sn1.fre.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BYB57-0001GL-6F for qemu-devel@nongnu.org; Wed, 09 Jun 2004 17:58:01 -0400 Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id 9432237E98 for ; Wed, 9 Jun 2004 23:57:58 +0200 (CEST) Received: from putte2k (h151n2fls306o994.telia.com [81.225.243.151]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 7F90E37E42 for ; Wed, 9 Jun 2004 23:57:58 +0200 (CEST) Message-ID: <000b01c44e6c$dcdef410$0401a8c0@putte2k> From: "Mike Nordell" Date: Wed, 9 Jun 2004 23:58:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: NE2000 problem found Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Fabrice Bellard wrote: > Can you tell me exactly in which case you have problems with NE2000 ? Always? :-) On Windows 2000, running Windows 2000 sp4, -pci -cirrusvga. It's also the thing that it seems only about every second time networking "works", to the extent the guest actually gets a DHCP address. It seems the slirp code is indeed getting the request, and is offering an addr, but the response is not reaching the guest OS' IP-stack. Whether this is due to the guests driver not even getting the interrupt from the virtual NIC, the response frame is malformed or I haven't yet been able to determine. I'm still in the process of adding better tracing, to be able to see what happens when. After adding the asic writeb I have observed it being written with 0x43 (just a few times) and 0xff (more times), and only directly after "read addr=0x7 val=40". I haven't yet added tracing output of rcnt for writeb, and I don't know the significance of this, but I suspect it means something. /Mike