qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thiemo Seufer <ths@networkno.de>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: linux-mips@linux-mips.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Date: Mon, 15 Oct 2007 16:05:14 +0100	[thread overview]
Message-ID: <20071015150514.GV3379@networkno.de> (raw)
In-Reply-To: <20071002200644.GA19140@hall.aurel32.net>

Aurelien Jarno wrote:
> Hi,
> 
> As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a
> try on QEMU/MIPS, and unfortunately it doesn't work correctly.
> 
> In some cases the kernel schedules an event very near in the future, 
> which means the timer is scheduled a few cycles only from its current
> value. Unfortunately under QEMU, the timer runs too fast compared to the
> speed at which instructions are execution. This causes a lockup of the
> kernel. This can be triggered by running hwclock --hctosys in the guest
> (which is run at boot time by most distributions). Until now, I haven't 
> found any other way to trigger the bug.

I found Qemu/MIPS locks up in the emulated kernel's calibrate_delay
function. Switching the kernel option off works around the problem.

> The problematic code in the kernel from arch/mips/kernel/time.c is the
> following:
> 
>         cnt = read_c0_count();
>         cnt += delta;
>         write_c0_compare(cnt);
>         res = ((long)(read_c0_count() - cnt ) > 0) ? -ETIME : 0;
> 
> Note that there is a minimum value for delta (currently set to 48) to 
> avoid lockup.
> 
> In QEMU, the emulated kernel runs at 100 MHz, ie very fast, which means
> that more than 48 timer cycles happen between the two calls of
> read_c0_count(). The code returns -ETIME, and the routine is called
> again with 48 and so on.
> 
> I have tried to reduce the speed of the timer, the problem disappears
> when running at 1MHz (on my machine).
> 
> Here are a few proposed ways to fix the problem (they are not exclusive):
> 
> 1) Improve the emulation speed for timer instructions. This is what I
> did with the attached patch. I see no obvious reason of stopping the
> translation after a write to CP0_Compare, so I removed that part.

The write could trigger an exception.


Thiemo

  parent reply	other threads:[~2007-10-15 15:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-02 20:06 [Qemu-devel] QEMU/MIPS & dyntick kernel Aurelien Jarno
2007-10-02 20:27 ` Avi Kivity
2007-10-02 20:37   ` Aurelien Jarno
2007-10-02 20:48     ` Alan Cox
2007-10-02 20:57       ` Aurelien Jarno
2007-10-02 22:35         ` Ralf Baechle
2007-10-04  1:59 ` J. Mayer
2007-10-04 16:19   ` Daniel Jacobowitz
2007-10-15  1:23   ` Paul Brook
2007-10-15  8:15     ` Dor Laor
2007-10-15 15:05 ` Thiemo Seufer [this message]
2007-10-15 15:58   ` Ralf Baechle
2007-10-15 16:20     ` Thiemo Seufer

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=20071015150514.GV3379@networkno.de \
    --to=ths@networkno.de \
    --cc=aurelien@aurel32.net \
    --cc=linux-mips@linux-mips.org \
    --cc=qemu-devel@nongnu.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).