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

>>> 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