WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] dom0 is stalled until a keypress

> From: Joanna Rutkowska [mailto:joanna@xxxxxxxxxxxxxxxxxxxxxx]
> Subject: Re: [Xen-devel] dom0 is stalled until a keypress
> 
> On 09/06/11 17:49, Dan Magenheimer wrote:
> >> From: Rafal Wojtczuk [mailto:rafal@xxxxxxxxxxxxxxxxxxxxxx]
> >> Sent: Monday, September 05, 2011 3:20 AM
> >> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: [Xen-devel] dom0 is stalled until a keypress
> >>
> >> Hello,
> >> The following bizarre behaviour was observed on xen4.1+suse dom0 2.6.38, on
> >> an old Core Duo laptop; maybe someone can hint what is wrong.
> >> Dom0 boot stalls after an init.d script prints "Starting udev". Then 
> >> nothing
> >> seems to happen. I need to press any key to observe progress - I need to do
> >> it tens of times for the boot to finish. After X starts fine, then there is
> >> no need for keypressing anymore.
> >> A particularly disturbing fact is that qrexec_daemon parent, that basically
> >> does
> >> for (;;) { sleep(1); fprintf(stderr, "."); }
> >> does not print dots, until a keypress arrives. So something is very wrong
> >> with timers.
> >> Somehow similarly, pm-suspend sometimes hangs at some stage - after 
> >> detaching
> >> power cord, machine enters S3 immediately.
> >> This is vaguely similar to the issue described in
> >>  https://lkml.org/lkml/2008/9/14/122
> >> but this time, "nohz=off" does not help.
> >>
> >> "cpufreq=dom0-kernel" cures the symptoms; but it is not a sideeffectless
> >> solution. Any idea what is going on or how to debug it ?
> >
> > ISTR seeing this on a Core(2?)Duo laptop and I think the
> > workaround was setting max_cstate=0 (as Xen boot parameter).
> >
> But what was the actual problem? Setting max_cstate is probably even
> worse for power management than setting cpufreq=dom-kernel, isn't it?

Sorry, dunno.  I recall looking into it a bit and finding that
the Core processor (and possibly specifically Merom, the laptop
version) had some special C-state (C3, C1E maybe?) and giving
up at that point.  Sorry I can't be more helpful.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel