[Top][All Lists]
[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
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel,
J. Mayer <=
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel, Thiemo Seufer, 2007/10/15