[Xen-devel] RE: Query about cpuidle

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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