From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Query about cpuidle Date: Fri, 9 Sep 2011 13:18:06 +0100 Message-ID: <4E6A03FE.8090202@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: kevin.tian@intel.com Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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. I applied your patch, changeset 23662:2faba14bac13, about initializing default C state information, and this appears to have fixed 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. Thanks in advance, -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com