WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: Query about cpuidle

To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Subject: [Xen-devel] RE: Query about cpuidle
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 13 Sep 2011 11:19:11 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 12 Sep 2011 20:21:40 -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>
References: <4E6A03FE.8090202@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acxu6opoEyAJzQDxSH+ExUnzCqsGFgC1q5TQAACqAaA=
Thread-topic: Query about cpuidle
forgot to CC the list

> -----Original Message-----
> From: Tian, Kevin
> Sent: Tuesday, September 13, 2011 11:07 AM
> To: 'Andrew Cooper'
> Subject: RE: Query about cpuidle
> 
> > From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> > Sent: Friday, September 09, 2011 8:18 PM
> >
> > Hello,
> >
> > We have recently had a support escalation about Xen-4.1.1 being unable
> > to boot on HP BL460c G7 blades.  The problem turned out to be a null
> > function pointer deference (ns_to_tick in cpu_idle.c) during early boot
> > of dom0, in the set_cx_pminfo function.
> 
> one possible reason is related to the order of how ACPI processor objects
> are found. CPU0 may not be always the 1st item there, and thus the
> ns_to_tick is not initialized accordingly.
> 
> you can easily verify this by adding printk in set_cx_pminfo.
> 
> >
> > I applied your patch, changeset 23662:2faba14bac13, about initializing
> > default C state information, and this appears to have fixed the problem.
> 
> with this patch function pointers are initialized when Xen is bringing up
> CPUs, which happens before dom0 and thus should avoid the problem
> 
> >
> > However, I see in the patch that setting up the function pointers
> > (ns_to_tick, tick_to_ns etc) is predicated on the hypercall coming in on
> > CPU0.  What guarantees are in place to ensure that these function
> > pointers get set up?  I cant see anything obvious from the code, but
> > have to admit that the null pointer deference appears to have gone away.
> 
> this is due to the cpu notifier coming in the latter part of the patch.
> 
> having said that, original logic looks error-prone, since there's no
> guarantee that cpu0 will be always firstly registered. We should just
> look at whether ns_to_tick is NULL, and if yes then do appropriate
> initialization at the 1st place, if you don't want to pull the whole 23662
> into your version.
> 
> Thanks
> Kevin
> 

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

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