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:40:55 -0400 Message-ID: <20120731134054.GD4789@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline 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: Mark van Dijk , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Mon, Jul 30, 2012 at 08:45:43AM +0100, Jan Beulich wrote: > >>> On 28.07.12 at 14:55, Mark van Dijk wrote: > >> > > So.. in that case make sure you have XEN_ACPI_PROCESSOR=y and > >> > > "CONFIG_INTEL_IDLE is not set" and that should do it. > >> > > >> > Didn't he say that with INTEL_IDLE disabled things work (perhaps > >> > in a limited way, but at least don't crash)? My understanding is > >> > that things should work even with it enabled, and I was under the > >> > impression that you had already taken care of disabling cpuidle > >> > and cpufreq in the kernel when running on Xen... > >> > >> So did I - both of those (cpufreq and cpuidle) are disabled. > >> > >> Mark, any chance you can collect the serial output when it crashes > >> please? Actually, can you get the whole bootup log with 'loglevel=8 > >> debug' on the Linux command line? > >> > > > > The sad part is that I don't have physical access to the box, the good > > part is that I do have KVM and IPMI (SOL) access. > > > > This is what I could capture: > > > > http://i.imgur.com/t66FM.png > > 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. Yeah, by me thinking everything is peachy and that override is no longer needed :-( > 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()). Duh! That is easy enough to fix. Mark, can you please try testing with this patch (and obviously enable the CONFIG_INTEL_IDLE) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index d0f59c3..46a9884 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -557,7 +557,7 @@ static int __init intel_idle_init(void) retval = cpuidle_register_driver(&intel_idle_driver); if (retval) { printk(KERN_DEBUG PREFIX "intel_idle yielding to %s", - cpuidle_get_driver()->name); + cpuidle_get_driver() ? cpuidle_get_driver()->name : "none"); return retval; }