From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: High CPU temp, suspend problem - xen 4.1.5-pre, linux 3.7.x Date: Mon, 25 Mar 2013 10:17:01 -0400 Message-ID: <20130325141701.GI11546@phenom.dumpdata.com> References: <5140E69F.9090803@invisiblethingslab.com> <20130315130240.GA8582@phenom.dumpdata.com> <514C79F3.5050504@invisiblethingslab.com> <20130322165651.GA4827@phenom.dumpdata.com> <515036BF.10105@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <515036BF.10105@invisiblethingslab.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Marek Marczykowski Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Mon, Mar 25, 2013 at 12:36:31PM +0100, Marek Marczykowski wrote: > On 22.03.2013 17:56, Konrad Rzeszutek Wilk wrote: > > On Fri, Mar 22, 2013 at 04:34:11PM +0100, Marek Marczykowski wrote: > >> I've switched to 3.8.4, on which problem is much easier to reproduce (almost > >> every startup). > >> > >> On bad bootup, xen-acpi-processor didn't found any C-state: for each CPU > >> _pr.flags.power and _pr->power.count was 0 (but flags.power_setup_done=1). In > >> this case suspend (or shutdown) always ends up with reset. > > > > This is you booting the machine from a cold-state or a warm one? > > Doesn't matter - in both cases the same result. > > > There are some BIOSes out there that I know that use the scratchpad registers in > > IOH (so depending on the platform that can be 0:0e.1 , Reg 0x84). If Xen or Linux > > touch it then the P-states and C-states that the BIOS generates are buggy. > > > > But that is not the case here - you are saying that the DSDT after disassembling > > (so cat /sys/firmware/acpi/tables/DSDT, or SSDT* and the iasl -d on them), the > > _PSD, _PSS, and _PCT look the same? > > Binary versions are the same so assume disassembled also. I've copied full > /sys/firmware/acpi/tables at some startups and in all cases (both cold and > warm startups) all were the same. > In case of any noticed difference will check disassembled versions. Was hoping it was something as simple as that :-) .. snip.. > > 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. > > 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? Now that the regression storm of v3.9 has subsided I should have some breathing room to address that. > > -- > Best Regards / Pozdrawiam, > Marek Marczykowski > Invisible Things Lab >