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

Re: [Xen-devel] Re: [Xen-users] dom0 hangs in xen 4.0.1-rc3-pre


  • To: Andreas Kinzler <ml-xen-devel@xxxxxx>
  • From: Bruce Edge <bruce.edge@xxxxxxxxx>
  • Date: Tue, 28 Sep 2010 09:04:10 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 28 Sep 2010 09:05:39 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PkdQG5bw6+tM1+LpG/Xd6Wmm9KbwHvIIBj6WbZBwD32R7bcNbqv4EMDYMCrvUUXMJw NsSFlFe25AswBl8rR8bDpBzR8prHKpnVkEnPgD21wc7IGulEjXawd0rOzKJYG8GELOT9 Vpp9CK56DRomzb9bo8iirnD6UjKeWLUIiXA/k=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

On Mon, Sep 27, 2010 at 7:50 AM, Andreas Kinzler <ml-xen-devel@xxxxxx> wrote:
> On 27.09.2010 16:32, Bruce Edge wrote:
>>>>
>>>> Does this affect all Nehalem chips or only the Lynnfields? The .21
>>>> kernel
>>>> is  causing grief for us too.  I was wondering if this was related.
>>>
>>> I am still researching this. For testing I bought a test system with
>>> Westmere-EP (Xeon E5620) which has ARAT. This system worked stable while
>>> Intel still lists it as having the C6 errata. This leads me to the
>>> conclusion that the HPET timer migration code (called HPET broadcast)
>>> from
>>> Xen is the root cause. This affects all CPUs that use it - but mainly
>>> Nehalem because of turbo mode.
>>
>> Thanks for the info. I'll try disabling turbo mode in the BIOS and see if
>> that helps.
>> Let me know if there's anything I can run/do/test/etc.
>
> If you want to check the issue I am referring to then you need to apply my
> patch from:
> http://lists.xensource.com/archives/html/xen-devel/2010-09/msg00556.html
>
> Do not modify the BIOS settings in any way.
>
> Regards Andreas
>

Andreas,
With this patch the dom0 hangs when I start the vm in pv mode. The hvm
ISO based install was OK, but the pv mode runtime hung the dom0
shortly after the boot entry was selected from the VM's grub menu.
There was no output on the VM console.
The dom0 console is printiing these:
[38927.441493] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
[38992.941432] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
[39058.441434] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
[39123.931432] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]

The Xen console is still responsive.
I've attached the '*' output.

And lastly, just for confirmation, this it the patch I applied:

diff -urN xx/xen/arch/x86/hpet.c xen-4.0.1/xen/arch/x86/hpet.c
--- xx/xen/arch/x86/hpet.c      2010-08-25 12:22:11.000000000 +0200
+++ xen-4.0.1/xen/arch/x86/hpet.c       2010-08-30 18:13:34.000000000 +0200
@@ -405,7 +405,7 @@
         /* Only consider HPET timer with MSI support */
         if ( !(cfg & HPET_TN_FSB_CAP) )
             continue;
-
+if (1) continue;
         ch->flags = 0;
         ch->idx = i;

@@ -703,8 +703,9 @@

 int hpet_broadcast_is_available(void)
 {
-    return (legacy_hpet_event.event_handler == handle_hpet_broadcast
-            || num_hpets_used > 0);
+    /*return (legacy_hpet_event.event_handler == handle_hpet_broadcast
+            || num_hpets_used > 0);*/
+    return 0;
 }

 int hpet_legacy_irq_tick(void)


-Bruce

Attachment: screenlog.30
Description: Binary data

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

 


Rackspace

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