* broken timer
@ 2009-07-27 18:05 Glauber Costa
2009-07-28 6:33 ` Gleb Natapov
0 siblings, 1 reply; 3+ messages in thread
From: Glauber Costa @ 2009-07-27 18:05 UTC (permalink / raw)
To: kvm; +Cc: avi
Hello, goodfellas
I'm seeing a strange problem in our much loved qemu-kvm.git
It's been there before avi left for vacation, at least.
The worst part, is that it doesn't happen always, and I don't
even think it is deterministic in its nature, IOW, there was nothing
I could do to make it more or less likely to happen.
It's almost obviously interrupt related, but I can't determine more than that
As I haven't, and won't have the time to debug this in the near future, here's
the riddle for you all to appreciate:
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: QEMU Virtual CPU version 0.10.50 stepping 03
Using local APIC timer interrupts.
Detected 0.000 MHz APIC timer.
------------[ cut here ]------------
WARNING: at kernel/time/clockevents.c:46 clockevent_delta2ns+0x37/0x72() (Not tainted)
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.27.5-117.fc10.x86_64 #1
Call Trace:
[<ffffffff810418f2>] warn_on_slowpath+0x60/0x90
[<ffffffff81331c7e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[<ffffffff8159d140>] ? early_idt_handler+0x0/0x72
[<ffffffff8132faf6>] ? printk+0x3c/0x3e
[<ffffffff8105cb9a>] clockevent_delta2ns+0x37/0x72
[<ffffffff815ad263>] setup_boot_APIC_clock+0x1c2/0x24b
[<ffffffff8132faf6>] ? printk+0x3c/0x3e
[<ffffffff815ab8a6>] native_smp_prepare_cpus+0x29e/0x2cf
[<ffffffff8159d5a8>] kernel_init+0x59/0x214
[<ffffffff81331c7e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[<ffffffff810116e9>] child_rip+0xa/0x11
[<ffffffff81010a07>] ? restore_args+0x0/0x30
[<ffffffff8159d54f>] ? kernel_init+0x0/0x214
[<ffffffff810116df>] ? child_rip+0x0/0x11
---[ end trace 4eaa2a86a8e2da22 ]---
APIC frequency too slow, disabling apic timer
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: broken timer
2009-07-27 18:05 broken timer Glauber Costa
@ 2009-07-28 6:33 ` Gleb Natapov
2009-07-28 13:35 ` Glauber Costa
0 siblings, 1 reply; 3+ messages in thread
From: Gleb Natapov @ 2009-07-28 6:33 UTC (permalink / raw)
To: Glauber Costa; +Cc: kvm, avi
On Mon, Jul 27, 2009 at 03:05:40PM -0300, Glauber Costa wrote:
> Hello, goodfellas
>
> I'm seeing a strange problem in our much loved qemu-kvm.git
This bug shouldn't depend on qemu-kvm.git at all unless you are running
with no-kvm-irqchip. The only things that involved in APIC timer
calibration are tsc and APIC. (If you don't use apicpmtimer kernel
parameter. Don't you?)
What is you host HW? Which version of kernel modules are you using?
Is your host overcommitted when this happens? Try to load the host with
work (while(1)) and run the guest. Is it easier to reproduce problem
this way?
> It's been there before avi left for vacation, at least.
>
> The worst part, is that it doesn't happen always, and I don't
> even think it is deterministic in its nature, IOW, there was nothing
> I could do to make it more or less likely to happen.
>
> It's almost obviously interrupt related, but I can't determine more than that
> As I haven't, and won't have the time to debug this in the near future, here's
> the riddle for you all to appreciate:
>
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> CPU0: QEMU Virtual CPU version 0.10.50 stepping 03
> Using local APIC timer interrupts.
> Detected 0.000 MHz APIC timer.
> ------------[ cut here ]------------
> WARNING: at kernel/time/clockevents.c:46 clockevent_delta2ns+0x37/0x72() (Not tainted)
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.27.5-117.fc10.x86_64 #1
>
> Call Trace:
> [<ffffffff810418f2>] warn_on_slowpath+0x60/0x90
> [<ffffffff81331c7e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
> [<ffffffff8159d140>] ? early_idt_handler+0x0/0x72
> [<ffffffff8132faf6>] ? printk+0x3c/0x3e
> [<ffffffff8105cb9a>] clockevent_delta2ns+0x37/0x72
> [<ffffffff815ad263>] setup_boot_APIC_clock+0x1c2/0x24b
> [<ffffffff8132faf6>] ? printk+0x3c/0x3e
> [<ffffffff815ab8a6>] native_smp_prepare_cpus+0x29e/0x2cf
> [<ffffffff8159d5a8>] kernel_init+0x59/0x214
> [<ffffffff81331c7e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
> [<ffffffff810116e9>] child_rip+0xa/0x11
> [<ffffffff81010a07>] ? restore_args+0x0/0x30
> [<ffffffff8159d54f>] ? kernel_init+0x0/0x214
> [<ffffffff810116df>] ? child_rip+0x0/0x11
>
> ---[ end trace 4eaa2a86a8e2da22 ]---
> APIC frequency too slow, disabling apic timer
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: broken timer
2009-07-28 6:33 ` Gleb Natapov
@ 2009-07-28 13:35 ` Glauber Costa
0 siblings, 0 replies; 3+ messages in thread
From: Glauber Costa @ 2009-07-28 13:35 UTC (permalink / raw)
To: Gleb Natapov; +Cc: kvm, avi
On Tue, Jul 28, 2009 at 09:33:05AM +0300, Gleb Natapov wrote:
> On Mon, Jul 27, 2009 at 03:05:40PM -0300, Glauber Costa wrote:
> > Hello, goodfellas
> >
> > I'm seeing a strange problem in our much loved qemu-kvm.git
> This bug shouldn't depend on qemu-kvm.git at all unless you are running
> with no-kvm-irqchip. The only things that involved in APIC timer
> calibration are tsc and APIC. (If you don't use apicpmtimer kernel
> parameter. Don't you?)
>
> What is you host HW? Which version of kernel modules are you using?
> Is your host overcommitted when this happens? Try to load the host with
> work (while(1)) and run the guest. Is it easier to reproduce problem
> this way?
NM.
I did a git pull in kvm.git, and reboot my kernel. Not a single problem since then.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-07-28 13:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-27 18:05 broken timer Glauber Costa
2009-07-28 6:33 ` Gleb Natapov
2009-07-28 13:35 ` Glauber Costa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).