Aurelien Jarno wrote:
> 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
> cnt = read_c0_count();
> cnt += delta;
> 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.