[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] [PATCH] Turn off pending guest timer printk


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Mon, 27 Mar 2006 10:59:42 +0800
  • Delivery-date: Mon, 27 Mar 2006 03:01:08 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcZL8mHgbaeJrjSiR2WOtJj8SFYa2wAY04TQATyFo7A=
  • Thread-topic: [Xen-ia64-devel] [PATCH] Turn off pending guest timer printk

>From: Magenheimer, Dan (HP Labs Fort Collins)
>Sent: 2006年3月21日 3:38
>
>> I have run Xen with 2 domains doing kernel compilation and I got no
>> Oops for timer.
>> Is this bug platform-dependant ?
>> Dan, are you able to reproduce this bug on a Tiger4 ?
>> Does this bug also appear on other platforms ?
>
>I rebuilt with tip and I'm no longer seeing the
>timer oops.  If I see it again, I will let you know.
>
>Dan
>

Cset 9084 fixes this weird timer oops, and yes it's done by Tristan. :-)
# HG changeset patch
# User awilliam@xxxxxxxxxxx
# Node ID ede16886f979dde3991f2a13c7eef71820a60cca
# Parent  c668c6abb5f0dc4d8cc81dbbcd4e96bb786b0f12
[IA64] #if 0'd useless code in timer handled.

Signed-off-by: Tristan Gingold <tristan.gingold@xxxxxxxx>

Previous our fix for this oops issue is to add guard at end of 
vcpu_check_pending_interrupts, to handle case where guest timer 
handler may set itm several times within one loop with interrupt disabled. 
That works for UP case, but not for SMP.

See following #if 0'd code:
        if (domain0_ready && current->domain != dom0) {
                if(vcpu_timer_expired(dom0->vcpu[0])) {
                        vcpu_pend_timer(dom0->vcpu[0]);
                        //vcpu_set_next_timer(dom0->vcpu[0]);
                        vcpu_wake(dom0->vcpu[0]);
                }
        }

When host SMP is enabled, and above code runs on another LP (not the 
one for dom0), virtual timer interrupt may be pended to dom0 at any given 
time. However read_ivr hyperprivop executed in asm code has no check, 
and thus may see that spurious timer interrupt sometimes.

So #if 0 solves it. :-)

Thanks,
Kevin

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.