From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kaq13-00045M-Mq for qemu-devel@nongnu.org; Wed, 03 Sep 2008 06:55:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kaq11-00044L-6P for qemu-devel@nongnu.org; Wed, 03 Sep 2008 06:55:11 -0400 Received: from [199.232.76.173] (port=33257 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kaq0z-000442-UM for qemu-devel@nongnu.org; Wed, 03 Sep 2008 06:55:10 -0400 Received: from relay01.mx.bawue.net ([193.7.176.67]:40470) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kaq0z-0002fW-Q6 for qemu-devel@nongnu.org; Wed, 03 Sep 2008 06:55:10 -0400 Date: Wed, 3 Sep 2008 12:54:47 +0200 From: Thiemo Seufer Subject: Re: [Qemu-devel] MIPS kernel hanging when loaded through U-Boot in qemu Message-ID: <20080903105447.GA17474@networkno.de> References: <20080828110042.1d27e8bb@surf> <20080903092511.4918f2d6@surf> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20080903092511.4918f2d6@surf> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Petazzoni Cc: qemu-devel@nongnu.org Thomas Petazzoni wrote: > Le Thu, 28 Aug 2008 11:00:42 +0200, > Thomas Petazzoni a =E9crit : >=20 > > It always hangs around the same place, but not exactly. Sometimes > > after "PID hash table entries", sometimes after "Console: colour dummy > > devices", sometimes one or two messages later, or before. >=20 > It seems to hang when the first interrupt occurs, which might explain > why it hangs at a random place, but always around the same point. >=20 > I've added a small debug message in target-mips/helper.c:do_interrupt() > to see what's happening: > http://toulibre.org/~thomas/qemu/qemu-interrupt-log-patch >=20 > With just the kernel (booted with -kernel), everything is fine, we see > a couple of interrupt of type "interrupt", and the boot proceeds: > http://toulibre.org/~thomas/qemu/qemu-interrupt-log-kernel-only 'Interrupt' at this point should be the normal timer interrupt, "syscall" are the execve() calls which start kernel threads. On classic mips, both types of exceptions use the general exception vector at 0x80000180. > But with U-Boot, once the first interrupt of type "interrupt" is fired, > it is followed by an interrupt of type "syscall", and then of type > "interrupt" again, and so on and so on, indefinitely: > http://toulibre.org/~thomas/qemu/qemu-interrupt-log-with-u-boot >=20 > As I'm not a MIPS expert, I don't know what's happening here. Is it a > bug in U-Boot that leaves an incorrect CPU state ? Is it a Qemu > emulation problem ? The difference here is that the timer interrupt goes to 0x80000200, this is controlled by the IV bit in the Cause register. This feature isn't available on all CPUs. In the kernel the relevant check to test for it is cpu_has_divec. I figure U-Boot and the Kernel disagree on the setting. Qemu always allows to set this Cause bit, independent of the CPU type. So I figure we have two bugs: - The kernel should try to clear the IV bit if it doesn't intend to use it - Qemu should ignore attempts to set the IV bit when emulating CPUs without divec. Thiemo