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
