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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.09.11 at 11:03, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> 
>>> wrote:
> On 09/06/11 19:17, Dan Magenheimer wrote:
>>> 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.
> 
> But the same system worked fine without any tweaks (cpufreq, max_cstate)
> on Xen 3.4 and only started exhibiting this behavior after we switched
> to Xen 4.1...

4.1.0 or 4.1.1?

Jan


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