Rob,
On 7 Feb 2014, at 18:15, Rob Herring wrote:
I've bisected a problem with system emulation and SMP kernels using
per cpu timers to this commit. I can reproduce this problem on ARM
emulation with both ARM generic timers (only in 1.7.0) and ARM MPCore
timers. Using a single broadcast timer in the guest kernel works fine.
My host is ubuntu 13.10.
I don't know the ARM emulation well, but from the description this looks
like a problem where timers are firing too often. The timer changes have
tended to uncover bugs elsewhere in the QEMU, for instance setting timer
expiry times to something very near zero. So far (touch wood) the timer
changes themselves have been relatively clean.
What I'd suggest you do is run qemu within gdb, and when you have
seen the sluggish behaviour, set a breakpoint in timerlist_run_timers
just before the line saying cb(opaque). If I'm right your breakpoint
should immediately hit. Step in to the callback and note which it is.
It should always (or nearly always) be the same timer (note the process
of debugging will cause other timers to expire).
You then want to find where that timer is set and see if the expiry
value looks silly. Normally the issue is that timer_mod takes an
argument (i) which is absolute time, not an interval, and (ii) is
measured in nanoseconds unless the timer's scale has been
set otherwise (quite often I've seen it read the current time
in nanoseconds then add an offset in milliseconds).
If you find which timer it is but can't work out why it's doing it,
I can take another look.