qemu-devel
[Top][All Lists]
Advanced

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

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


From: J. Mayer
Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Date: Thu, 04 Oct 2007 03:59:42 +0200

On Tue, 2007-10-02 at 22:06 +0200, Aurelien Jarno wrote:
> Hi,

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.

[....]

There seem to have specific problems when using dynticks in Qemu. What I
can see is that it makes the PowerPC emulation quite unusable, at least
on my PC, which is an amd64 (with a fix CPU frequency), no matter if I
run 32 or 64 bits mode.
What I can see is that the emulated timer frequency seem to be
completely random: the system time, as seen from the target CPU, is
running from half of the real time to twice of the real time speed,
randomly; launching Qemu twice in the same conditions, on the same
machine, will give different speed for the emulated system timer. I also
experiment a lot of Qemu freezes: I cannot run the emulated target more
than a few minutes before it freezes; sometimes it runs less than 1
second, even not get out of the firmware. It's not the same issue than
yours, as the firmware uses no timer and as it's a complete Qemu freeze:
even the monitor is frozen.

I tried to disactivate dynticks, just commenting the entry in
alarm_timers structure. Since then, I can notice that the emulated
system clock seems always to be running at the same speed as the host
one (not a single second of difference after 2 hours of compilation in
the target system...) and that I never had any Qemu freeze anymore since
then. Which convinces me that dynticks is the source of the problems...

Then, I feel like dynticks in Qemu is an experimental feature that
should not be activated as default, as it seems not to be really usable
as it is now. I got no idea of what's going wrong in that code, I saw
nothing awfull at first sight (I only gave a quick look...) but it makes
Qemu unreliable and quite unusable, as far as I can see.

[...]

-- 
J. Mayer <address@hidden>
Never organized





reply via email to

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