[Top] [All Lists]

Re: [Qemu-devel] QEMU/MIPS & dyntick kernel

To: Aurelien Jarno <>
Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
From: Thiemo Seufer <>
Date: Mon, 15 Oct 2007 16:05:14 +0100
In-reply-to: <>
Original-recipient: rfc822;
References: <>
User-agent: Mutt/1.5.16 (2007-06-11)
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.


<Prev in Thread] Current Thread [Next in Thread>