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

[Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>]

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

j.

Attachment: signature.asc
Description: OpenPGP digital signature

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