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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
