From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Kernel crash with acpi_processor, cpu_idle and intel_idle =y Date: Tue, 31 Jul 2012 09:42:24 -0400 Message-ID: <20120731134224.GE4789@phenom.dumpdata.com> 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> <20120731135848.7298a046@internecto.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20120731135848.7298a046@internecto.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mark van Dijk Cc: Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, Jul 31, 2012 at 01:58:48PM +0200, Mark van Dijk wrote: > 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. Sure, but it should be smart enought not to crash. Can you please try the patch I sent in the other email. > > 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. You seem to be using MWAIT states, which is what the C4-C7 are. > > 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. I am not sure what those do. What did the manual say that they are doing? BTW, C4-C7 are basically C3 states with MWAIT - and from your pastebins you seem to have those enabled. > > 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