From: Thiemo Seufer <ths@networkno.de>
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] MIPS kernel hanging when loaded through U-Boot in qemu
Date: Wed, 3 Sep 2008 12:54:47 +0200 [thread overview]
Message-ID: <20080903105447.GA17474@networkno.de> (raw)
In-Reply-To: <20080903092511.4918f2d6@surf>
Thomas Petazzoni wrote:
> Le Thu, 28 Aug 2008 11:00:42 +0200,
> Thomas Petazzoni <thomas.petazzoni@enix.org> 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
next prev parent reply other threads:[~2008-09-03 10:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-28 9:00 [Qemu-devel] MIPS kernel hanging when loaded through U-Boot in qemu Thomas Petazzoni
2008-08-28 15:14 ` Thiemo Seufer
2008-09-03 7:25 ` Thomas Petazzoni
2008-09-03 10:54 ` Thiemo Seufer [this message]
2008-09-03 12:03 ` Thomas Petazzoni
2008-09-03 12:20 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080903105447.GA17474@networkno.de \
--to=ths@networkno.de \
--cc=qemu-devel@nongnu.org \
--cc=thomas.petazzoni@enix.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).