From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark van Dijk Subject: Re: Kernel crash with acpi_processor, cpu_idle and intel_idle =y Date: Tue, 31 Jul 2012 13:58:48 +0200 Message-ID: <20120731135848.7298a046@internecto.net> References: <20120722181611.7ae03506@internecto.net> <20120723142025.GB793@phenom.dumpdata.com> <20120726022527.4d3f6e4a@internecto.net> <20120726140552.GD28024@phenom.dumpdata.com> <501176DD0200007800090A32@nat28.tlf.novell.com> <20120726145535.GA5743@phenom.dumpdata.com> <20120728145515.50bf4d45@internecto.net> <501657C70200007800091357@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <501657C70200007800091357@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org Message 501657C70200007800091357@nat28.tlf.novell.com contained: >The first thing intel_idle_init() does is check >boot_option_idle_override, and I thought this got forced to >something other than IDLE_NO_OVERRIDE by the Xen code. >But at least in the current kernel that doesn't seem to be >the case anymore, and thus I suppose that it's dying on the >subsequent > > retval = cpuidle_register_driver(&intel_idle_driver); > if (retval) { > printk(KERN_DEBUG PREFIX "intel_idle yielding to %s", > cpuidle_get_driver()->name); > return retval; > } > >since cpuidle_get_driver() is presumably returning NULL (after >all xen_arch_setup() does call disable_cpuidle()). This is way beyond my knowledge. I'm no programmer so unfortunately I can't say anything about it. Not using INTEL_IDLE is no problem, in fact, I now understand that INTEL_IDLE is not (should not) even used with Xen. But I have to ask whether we can look at the other issue a bit more, regarding CPU states and how I can get states C4-C7 to work. Perhaps you can tell me whether the BIOS options "ACPI T-state", "C3 Auto Demotion" and "C1 Auto Demotion" should be disabled. I think they should be, as I read it this sets respectively C4-C7 to C3, and C3-C2 to C1 right? I have (and had) those disabled, when I enabled them the output from xenpm did not differ. Much obliged, Mark. -- Stay in touch, Mark van Dijk. ,-------------------------------- ---------------------------' Tue Jul 31 11:28 UTC 2012 Today is Boomtime, the 66th day of Confusion in the YOLD 3178