Re: [Xen-devel] Only CPU0 active after ACPI S3, xen 4.1.3

[Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On 12.01.2013 08:05, Marek Marczykowski wrote:
> On 03.01.2013 09:52, Jan Beulich wrote:
>>>>> On 21.12.12 at 14:33, Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
>> wrote:
>>> On 21.12.2012 09:55, Jan Beulich wrote:
>>>>>>> On 21.12.12 at 05:52, Marek Marczykowski 
>>>>>>> <marmarek@xxxxxxxxxxxxxxxxxxxxxx> 
>>> wrote:
>>>>> On 21.12.2012 00:17, Marek Marczykowski wrote:
>>>>>> With this patch applied (on 4.1.4 and 4.3-unstable), I've got original 
>>>>> symptom
>>>>>> - only CPU0 active after ACPI S3. Didn't get reboot after few tries.
>>>>>> "xl debug-key r" output attached.
>>>>>> Anyway it looks like bug was introduced somehow between 4.1.2 and 4.1.3 
>>>>>> - on
>>>>>> 4.1.2 none of above problems happened.
>>>>>
>>>>> I've done bisect on xen 4.1 and found problematic commit:
>>>>> http://xenbits.xen.org/hg/xen-4.1-testing.hg/rev/1f95b55ef427 
>>>>
>>>> In that case, using "sched_ratelimit_us=0" should make the
>>>> problem go away again - did you try that?
>>>
>>> This option does not help when trying 4.1.4, but does when trying xen 
>>> compiled from above c/s.
>>
>> Are you saying that on 4.1.4 this doesn't take effect? Are there
>> any log messages indicating so? The above being the top most
>> change to sched_credit.c, this difference in behavior pretty odd.
> 
> I can no longer reproduce this bug on 4.1.3-rc1-pre (above sched_credit c/s)
> with or without sched_ratelimit_us=0. So it must be some mistake during
> previous testing.
> Also the problem from email subject is rather rare and not observed after ~20
> suspend-resume cycles...
> 
> Just to summary:
> 4.1.3-rc1-pre (above sched_credit c/s) - works ok
> 4.1.4 regardless of sched_ratelimit_us=0 reboots at resume
> 4.1.5-pre reboots at resume regardless of sched_ratelimit_us option
> 4.1.5-pre with "Introduce system_state variable" reverted works fine -
> regardless of sched_ratelimit_us option
> 
> "4.1.5-pre" was c/s 23436:2ae6267371d8, but still the same effects on
> 23441:2a91623a5807.

Just after sending this email I've suspended laptop (running 4.1.5-pre with
above commit reverted, but without sched_ratelimit_us=0 option). After few
hours it hanged at resume (don't know at which state, but somehow early -
before reinitialize of console). The same xen version suspended for shorter
time period (2-5min) resumed without problem. I've retried suspend for 4-5h
and got reboot.
The same version (still with "system_state" commit reverted), but _with_
sched_ratelimit_us=0 resumes well even after many hours.

So sched_ratelimit_us option makes some difference even on most recent 4.1
xen, but it needs patience to spot it...
Maybe above "works ok" for 4.1.3-rc1-pre isn't really true because I've tested
short suspend periods.

-- 
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel