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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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.

<sigh> 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?

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



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