qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] MIPS kernel hanging when loaded through U-Boot in qemu


From: Thiemo Seufer
Subject: Re: [Qemu-devel] MIPS kernel hanging when loaded through U-Boot in qemu
Date: Wed, 3 Sep 2008 12:54:47 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Thomas Petazzoni wrote:
> Le Thu, 28 Aug 2008 11:00:42 +0200,
> Thomas Petazzoni <address@hidden> a écrit :
> 
> > 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.
> 
> 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.
> 
> 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
> 
> 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
> 
> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]