From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HsGxJ-0006Af-TR for qemu-devel@nongnu.org; Sun, 27 May 2007 07:30:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HsGxJ-0006AJ-Bl for qemu-devel@nongnu.org; Sun, 27 May 2007 07:30:37 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HsGxJ-0006AG-2P for qemu-devel@nongnu.org; Sun, 27 May 2007 07:30:37 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HsGxI-0002mH-FS for qemu-devel@nongnu.org; Sun, 27 May 2007 07:30:36 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l4RBUV4H020292 for ; Sun, 27 May 2007 04:30:31 -0700 (PDT) Message-ID: <46596BEC.1090006@windriver.com> Date: Sun, 27 May 2007 06:30:52 -0500 From: Jason Wessel MIME-Version: 1.0 Subject: Re: [Qemu-devel] MIPS64 problem with ethernet References: <4651B40F.3000704@windriver.com> <4651BD4D.9020008@aurel32.net> <4651BF78.3000000@windriver.com> <20070526211844.GB18476@amd64.aurel32.net> In-Reply-To: <20070526211844.GB18476@amd64.aurel32.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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 Aurelien Jarno wrote: > As discussed on IRC, the problem is only present on 32-bit hosts. It is > due to the do_ddivu which is falsely implemented using lldiv and then by > casting the result. The patch below uses / and % as on the 64-bit host > code. It is maybe slower than lldiv, but at least it gives the correct > result. This probably involves some libgcc code, so it is better to keep > it in op_helper.c for 32-bit hosts. > > With your change the ethernet does come up but it seems there is a further problem, perhaps with ddivu. My host is a 32bit host, and this does seem to work on a 64bit host or the real hardware. Doing something like an ls /proc does not work in the emulated target. The reason is that the compatibility syscalls are 32bit and there is some sign extension problem somewhere. I put the following code in kernel/main/init.c as an illustration of the problem. { unsigned long v1 = 0xffffffff80731111; unsigned int v2 = v1 + 1; printk("v1 %lx v2 %08x\n", v1, v2); } On the real hw it prints correctly as: v1 ffffffff80731111 v2 80731112 On the emulated 64 bit + 64bit kernel on a 32 bit host it prints as: v1 ffffffff80731111 v2 ffffffff80731112 This might be due to the ddivu in printk, but it could be elsewhere... Jason.