Re: High CPU temp, suspend problem - xen 4.1.5-pre, linux 3.7.x

[Marek Marczykowski <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2821 bytes --]

On 25.03.2013 15:17, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 25, 2013 at 12:36:31PM +0100, Marek Marczykowski wrote:
>> On 22.03.2013 17:56, Konrad Rzeszutek Wilk wrote:
>>> This reminds me of something. I recall a long long time ago seeing something like this....
>>> Completly forgot about this until now. The difference was whether the Xen's cpu_idle 
>>> as running a) the acpi_idle (so using the different C-states), or b) the default one
>>> (so just using HLT).
>>>
>>> With the b), during resume it would get half-way through
>>> (http://darnok.org/xen/devel.acpi-s3.v1.serial.log) while with a) it would actually
>>> continue on - http://darnok.org/xen/devel.acpi-s3.v0.serial.log
>>>
>>> This was on some MSI MS-7680/H61M-P23 (MS-7680) motherboard.
>>>
>>> Oh look: http://lists.xen.org/archives/html/xen-devel/2011-06/msg02059.html
>>>
>>> And it looks Kevin's recommendation was use the a) case with max_cstates=1
>>> to narrow it down.
>>
>> When default_idle used, resume doesn't work at all (even the first one). Details:
>> (1) With max_cstates=1, without xen-acpi-processor module: default_idle used.
>> Suspend succeed, but always hang at resume.
> 
> AHA! So the bug persist.
>>
>> (2) With max_cstate=1, with xen-acpi-processor module loaded: acpi_idle used.
>> Suspend succeed, resume also, but after resume above problem exists (high
>> temperature, C2-C3 states only present on CPU0, subsequent suspends always
>> ends up with reboot).
>>
>> (3) Without max_cstate=1, with xen-acpi-processor module loaded: same as (2).
>>
>> (4) Without max_cstate=1, without xen-acpi-processor module loaded: same as (1).
>>
>> One more observation: when xen compiled with debug=y, (2) and (4) cases
>> behaves the same as (1).
> 
> Oh, that is something new.

I've tried also some (automated :) ) bisection on xen from 4.1.2 to 4.1.4, but
unfortunately results wasn't deterministic... My script don't distinguish
different symptoms (reboot at suspend, hang at resume, incomplete C-states
after resume, etc), so this can be reason for such non-deterministic results...

One time I've got this commit as first bad:
commit 329d4280255ff44300913f24119f52d3459c1ed0
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Apr 17 08:33:33 2012 +0100

    XENPF_set_processor_pminfo XEN_PM_CX overflows states array

Maybe related?

>>
>> Hopefully I will have real serial console somehow in this week and will be
>> able to get more details from hang and reboot cases.
>>
>> BTW Any chances for Xen ACPI S3 patches in upstream kernel?
> 
> <sigh> Now that the regression storm of v3.9 has subsided I should have
> some breathing room to address that. 

I keep fingers crossed.

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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