This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] Instability with Xen, interrupt routing frozen, HPET bro

To: "'gang.wei@xxxxxxxxx'" <gang.wei@xxxxxxxxx>
Subject: RE: [Xen-devel] Instability with Xen, interrupt routing frozen, HPET broadcast
From: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
Date: Wed, 4 May 2011 17:31:44 -0500
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "'xiantao.zhang@xxxxxxxxx'" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Wed, 04 May 2011 15:32:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwKqwvW3Ga87kRkRM2m+5EkjC6gqQ==
Thread-topic: RE: [Xen-devel] Instability with Xen, interrupt routing frozen, HPET broadcast
On Thu, 30 Sep 2010 14:02:34 +0800, gang.wei@xxxxxxxxx wrote:
> I am the original developer of HPET broadcast code. 
> First of all, to disable HPET broadcast, no additional patch is required. 
> Please simply add option "cpuidle=off" or "max_cstate=1" at xen cmdline in 
> /boot/grub/grub.conf. 
> Second, I noticed that the issue just occur on pre-nehalem server processors. 
> I 
> will check whether I can reproduce it. 

> On , xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote:
> > Maybe you can disable pirq_set_affinity to have a try with the
> > following patch. It may trigger IRQ migration in hypervisor,
> > and the IRQ migration logic about(especailly
> > shared)level-triggered ioapic IRQ is not well tested because
> > of no users before.  After intoducing the pirq_set_affinity in
> > #Cset21625, the logic is used frequently when vcpu migration
> > occurs, so I doubt it maybe expose the issue you met.
> > Besides, there is a bug in event driver which is fixed in
> > latest pv_ops dom0, seems the dom0 you are using doesn't
> > include the fix.  This bug may result in lost event in dom0
> > and invoke dom0 hang eventually. To workaround this bug,  you
> > can disable irqbalance in dom0. Good luck!

Andreas Kinzler reported seeing soft-locks and hard-locks on Xen
back in September 2010, associated with HPET broadcast.

I'm seeing similar issues.  If I disable C-states as Jimmy suggests
above, the problem goes away.  If I set the clocksource to pit, the
problem goes away.  It may go away also if I set the clocksource to
pmtimer/acpi, or if I remove HPET from the list of available platform

Did this issue ever get resolved?  Is there a better solution that
using pit as a clocksource?  I'd really prefer to not disable 
C-states, as the hardware I'm using gets significant performance
and performance/watt benefits from being able to enter C2.

--Mark Langsdorf
Operating System Research Center

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>