On 22 Feb 2014, at 00:57, Matt Lupfer wrote:
I did some more debugging and found the problem was elsewhere. This
different timer behavior is exposing a bug in the HPET implementation.
It's possible for the QEMU timer underlying the HPET to call the hpet_timer()
callback between when the
Il 22/02/2014 01:57, Matt Lupfer ha scritto:
Thanks for the response. The hpet_timer() callback calls timer_mod()
every 1 ms. That timerlist has no notify callback so it in turn calls
qemu_notify_event().
The guest kernel is only enabling the HPET timer and looking for
timer interrupts.
On 21 Feb 2014, at 04:34, Matt Lupfer wrote:
A git bisect points to this commit as the culprit:
b1bbfe7 aio / timers: On timer modification, qemu_notify or aio_notify
which was part of the Aug 2013 timer rewrite. Reverting this hunk in
particular makes the issue go away:
@@ -522,9
On 02/21/2014 06:27 AM, Alex Bligh wrote:
On 21 Feb 2014, at 04:34, Matt Lupfer wrote:
This doesn't appear to be a solution, because with the timer rewrite, QEMU
moves its periodic (1 ms) qemu_notify_event() call to break out of
the main event loop from a SIGALRM handler to the rearm of a
Hello,
After upgrading to QEMU 1.7.0, CentOS 5.x guests often fail to boot
with the following kernel apic=debug output:
ACPI: Core revision 20060707
enabled ExtINT on CPU#0
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to
Il 21/02/2014 05:34, Matt Lupfer ha scritto:
This doesn't appear to be a solution, because with the timer rewrite, QEMU
moves its periodic (1 ms) qemu_notify_event() call to break out of
the main event loop from a SIGALRM handler to the rearm of a QEMU timer.
Presumably QEMU is counting on
