[Qemu-devel] rtc: lost some interrupts at 1024Hz.

[Qemu-devel] rtc: lost some interrupts at 1024Hz.

[Brad Campbell]

G'day all,

Just wonder if anyone else is seeing this. I've not had a chance to track it down or try to debug it 
yet.

I'm running latest QEMU CVS with kqemu and the -no-tsc patch on a vanilla 2.6.17.3 kernel with suspend2.

The VM behaves perfectly until I do a suspend/resume of the host. When the machine comes back, most 
of the time (not all the time however) it ends up flooding my logs with this message.

Jul  8 17:26:03 localhost kernel: [43299223.910000] rtc: lost some interrupts at 1024Hz.
Jul  8 17:26:03 localhost kernel: [43299223.930000] rtc: lost some interrupts at 1024Hz.
Jul  8 17:26:03 localhost kernel: [43299223.950000] rtc: lost some interrupts at 1024Hz.
Jul  8 17:26:03 localhost kernel: [43299223.970000] rtc: lost some interrupts at 1024Hz.

Of course if I shutdown/reboot the VM the problem goes away. I've seen this before but it's been a 
while from memory.
I'm running a vanilla 2.6.17.3 kernel in the guest booted with GRUB and both host and guest are 
configured with HZ=100.

I seem to recall mplayer does the same thing if I leave something playing over a suspend/resume, but 
I've not had a chance to look at it further. It's pretty reproducible here with qemu anyway.

This is about the only remaining thing that is preventing me leaving VM's up over suspend/resume 
now. Other than that, it's all good.

I'll probably get to looking at it in the next couple of weeks if nobody has any pointers.
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] rtc: lost some interrupts at 1024Hz.

[Fabrice Bellard]

It seems to be a host kernel problem.

Regards,

Fabrice.

Brad Campbell wrote:
> G'day all,
> 
> Just wonder if anyone else is seeing this. I've not had a chance to 
> track it down or try to debug it yet.
> 
> I'm running latest QEMU CVS with kqemu and the -no-tsc patch on a 
> vanilla 2.6.17.3 kernel with suspend2.
> 
> The VM behaves perfectly until I do a suspend/resume of the host. When 
> the machine comes back, most of the time (not all the time however) it 
> ends up flooding my logs with this message.
> 
> Jul  8 17:26:03 localhost kernel: [43299223.910000] rtc: lost some 
> interrupts at 1024Hz.
> Jul  8 17:26:03 localhost kernel: [43299223.930000] rtc: lost some 
> interrupts at 1024Hz.
> Jul  8 17:26:03 localhost kernel: [43299223.950000] rtc: lost some 
> interrupts at 1024Hz.
> Jul  8 17:26:03 localhost kernel: [43299223.970000] rtc: lost some 
> interrupts at 1024Hz.
> 
> Of course if I shutdown/reboot the VM the problem goes away. I've seen 
> this before but it's been a while from memory.
> I'm running a vanilla 2.6.17.3 kernel in the guest booted with GRUB and 
> both host and guest are configured with HZ=100.
> 
> I seem to recall mplayer does the same thing if I leave something 
> playing over a suspend/resume, but I've not had a chance to look at it 
> further. It's pretty reproducible here with qemu anyway.
> 
> This is about the only remaining thing that is preventing me leaving 
> VM's up over suspend/resume now. Other than that, it's all good.
> 
> I'll probably get to looking at it in the next couple of weeks if nobody 
> has any pointers.
> Brad

Re: [Qemu-devel] rtc: lost some interrupts at 1024Hz.

[Brad Campbell]

Fabrice Bellard wrote:
> It seems to be a host kernel problem.
> 

It is a host kernel problem. The kernel does not save/restore the config of the periodic interrupt 
timer over a suspend/resume cycle. I'm having a cursory look into it.

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

RE: [Qemu-devel] rtc: lost some interrupts at 1024Hz.

[Armistead, Jason]

Brad Campbell wrote:

>The VM behaves perfectly until I do a suspend/resume of the host. When the
machine comes back, most 
>of the time (not all the time however) it ends up flooding my logs with
this message.
>
>Jul  8 17:26:03 localhost kernel: [43299223.910000] rtc: lost some
interrupts at 1024Hz.
>Jul  8 17:26:03 localhost kernel: [43299223.930000] rtc: lost some
interrupts at 1024Hz.
>Jul  8 17:26:03 localhost kernel: [43299223.950000] rtc: lost some
interrupts at 1024Hz.
>Jul  8 17:26:03 localhost kernel: [43299223.970000] rtc: lost some
interrupts at 1024Hz.

Some clues from Google's search results, searching for "rtc: lost some
interrupts at 1024Hz":

http://lkml.org/lkml/2006/4/25/107

Also look at Google's groups.  Lots of discussion about these error messages
there

I suspect (without diving into source code) that Linux tracks timer
interrupts (in old PC DOS days, 18 ticks per second from a programmable
interval timer) versus the hardware RTC timer ticks, and when there are less
interrupts occurring than expected, it thinks the hardware is on the blink
or else there is some higher priority interrupt handler that is running for
longer than 2 RTC interrupts.

I get the impression that Linux media player style applications which need
critical timer resources actually increase the interrupt rate from 18 per
second to something a lot higher, in your case 1024 Hz.  The kernel may be
trying to ensure that the interrupts are being handled in a timely fashion,
and to know that, all it can do is compare against the RTC chip.  If you
expect 1024 interrupts per second, but in a two second period (from the HW
RTC clock) there have only been say 1500 processed instead of 1024 i.e. 1500
times the interrupt handler has run, then clearly, around 548 interrupts
went missing, blocked by some higher interrupt priority source.

I found some sources for the RTC driver at

http://www.kernel.org/pub/scm/linux/kernel/bkcvs/linux-2.5/drivers/char/rtc.
c,v

and this seems to confirm what I expected.  Look in function rtc_dropped_irq
and the comments preceding it.

Cheers

Jason