From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HUSrC-0000K4-AS for qemu-devel@nongnu.org; Thu, 22 Mar 2007 15:21:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HUSrA-0000BK-Gw for qemu-devel@nongnu.org; Thu, 22 Mar 2007 15:21:53 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUSrA-0000AV-92 for qemu-devel@nongnu.org; Thu, 22 Mar 2007 14:21:52 -0500 Received: from bangui.magic.fr ([195.154.194.245]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HUSpK-0001xp-NR for qemu-devel@nongnu.org; Thu, 22 Mar 2007 15:19:59 -0400 Received: from [192.168.0.2] (ppp-36.net-723.magic.fr [80.118.184.36]) by bangui.magic.fr (8.13.1/8.13.1) with ESMTP id l2MJJpGT003558 for ; Thu, 22 Mar 2007 20:19:51 +0100 Subject: Re: [Qemu-devel] Re: Qemu PPC ethernet checksum bug [PATCH] From: "J. Mayer" In-Reply-To: <4602BF6F.7050608@windriver.com> References: <7ED098B05D69FE41B380586BF1474DBA1CBA85@ala-mail08.corp.ad.wrs.com> <1174206229.7316.195.camel@rapid> <4602BF6F.7050608@windriver.com> Content-Type: text/plain Date: Thu, 22 Mar 2007 20:19:54 +0100 Message-Id: <1174591194.31773.5.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 On Thu, 2007-03-22 at 12:39 -0500, Jason Wessel wrote: > Attached is a patch as well as an example program, where I took the code > from the from the linux kernel and made a call in with a dummy packet. > > It appears the problem is the addic translation does not correctly > set/reset the carry bit, and this is a regression vs the source base on > 3/7/2007. With the change here, I can boot the ppc-prep machine again > and use ethernet. OK, thanks for this detailed report, I can now see what the bug is: the carry should be reset when immediate value is zero. Your patch is not great because it disables useful optimization, but I will test another one and commit it soon. > J. Mayer wrote: > > Hi, > > > > My concern is I cannot reproduce your problem for the following reasons: > > - the PREP machine (and the heathrow too...) is broken and cannot even > > boot. PCI and/or IRQ are broken, so the Linux kernel hangs. > > - when using the "known to work" Linux distributions on the mac99 > > machine (please take a look at the STATUS file), I am able to download a > > kernel from www.kernel.org, which makes me think TCP packets are sent > > and received correctly, with valid checksums. > > > > Then, it would be a great thing if you could isolate the failing routine > > and, for example, make a test case usable with linux-user emulation. > > This would be a great help to solve this issue. > > > > Thanks by advance. > > -- J. Mayer Never organized