[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] High CPU temp, suspend problem - xen 4.1.5-pre, linux 3.7.x
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@xxxxxxxx> 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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |