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.
commit b1bbfe72ec1ebf302d97f886cc646466c0abd679 Author: Alex Bligh <[email protected]> Date: Wed Aug 21 16:02:55 2013 +0100 aio / timers: On timer modification, qemu_notify or aio_notify On qemu_mod_timer_ns, ensure qemu_notify or aio_notify is called to end the appropriate poll(), irrespective of use_icount value. On qemu_clock_enable, ensure qemu_notify or aio_notify is called for all QEMUTimerLists attached to the QEMUClock. Signed-off-by: Alex Bligh <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]> This can be reproduced with a simple busybox initramfs and spawning several instances of a simple shell script to load the cores: while [ 1 ]; do echo rob > /dev/null; done & The symptom is user interaction become sluggish and jerky, and then kernel messages about soft lockup, rcu stalls and/or like this: hrtimer: interrupt took 3030033000 ns [sched_delayed] sched: RT throttling activated I also intermittently hang on boot hitting this warning: [ 0.640204] WARNING: CPU: 0 PID: 0 at /home/rob/proj/git/linux-2.6/kernel/time/clockevents.c:212 clockevents_program_event+0x50/0x138() which is from here: if (unlikely(expires.tv64 < 0)) { WARN_ON_ONCE(1); return -ETIME; } I'm not sure if this warning is caused by the same commit or not, but it seems like I'm getting wrong timer values from qemu. It appears to me that this bug report may also be related: https://bugs.launchpad.net/qemu/+bug/1222034 Rob
