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.
FWIW
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 t
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 r
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:
>
> > @@
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 these
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 connecte
