From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Marczykowski Subject: Re: High CPU temp, suspend problem - xen 4.1.5-pre, linux 3.7.x Date: Mon, 25 Mar 2013 12:36:31 +0100 Message-ID: <515036BF.10105@invisiblethingslab.com> References: <5140E69F.9090803@invisiblethingslab.com> <20130315130240.GA8582@phenom.dumpdata.com> <514C79F3.5050504@invisiblethingslab.com> <20130322165651.GA4827@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2258617105890356567==" Return-path: In-Reply-To: <20130322165651.GA4827@phenom.dumpdata.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: Konrad Rzeszutek Wilk Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2258617105890356567== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F82590E11D1986C3F3A1892" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F82590E11D1986C3F3A1892 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 C= PU >> _pr.flags.power and _pr->power.count was 0 (but flags.power_setup_done= =3D1). In >> this case suspend (or shutdown) always ends up with reset. >=20 > 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 reg= isters in > IOH (so depending on the platform that can be 0:0e.1 , Reg 0x84). If Xe= n or Linux > touch it then the P-states and C-states that the BIOS generates are bug= gy. >=20 > But that is not the case here - you are saying that the DSDT after disa= ssembling > (so cat /sys/firmware/acpi/tables/DSDT, or SSDT* and the iasl -d on the= m), the > _PSD, _PSS, and _PCT look the same? Binary versions are the same so assume disassembled also. I've copied ful= l /sys/firmware/acpi/tables at some startups and in all cases (both cold an= d warm startups) all were the same. In case of any noticed difference will check disassembled versions. > You could also look at the FACP table and see if they are different. >> >> On good one xen-acpi-processor got C1-C3 states for each CPU, then sus= pend >> succeeded, but after resume CPU0 had C1-C3, but others only C1. Reload= ing >> xen-acpi-processor (rmmod -f...) fixes this (according to xl debug-key= c), but >> still temperature keep high. Regardless of xen-acpi-processor reloadin= g, next >> suspend always fails. >=20 > If you reload, and look at the runqeueus, are all of them using the ACP= I > idler or the default one? The ACPI one (before reload and after). >> Not sure how C-states can be related to S3 suspend, but perhaps someth= ing more >> general with ACPI is wrong? >=20 > This reminds me of something. I recall a long long time ago seeing some= thing like this.... > Completly forgot about this until now. The difference was whether the X= en's cpu_idle=20 > as running a) the acpi_idle (so using the different C-states), or b) th= e default one > (so just using HLT). >=20 > 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 wo= uld actually > continue on - http://darnok.org/xen/devel.acpi-s3.v0.serial.log >=20 > This was on some MSI MS-7680/H61M-P23 (MS-7680) motherboard. >=20 > Oh look: http://lists.xen.org/archives/html/xen-devel/2011-06/msg02059.= html >=20 > And it looks Kevin's recommendation was use the a) case with max_cstate= s=3D1 > to narrow it down. When default_idle used, resume doesn't work at all (even the first one). = Details: (1) With max_cstates=3D1, without xen-acpi-processor module: default_idle= used. Suspend succeed, but always hang at resume. (2) With max_cstate=3D1, 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 alway= s ends up with reboot). (3) Without max_cstate=3D1, with xen-acpi-processor module loaded: same a= s (2). (4) Without max_cstate=3D1, without xen-acpi-processor module loaded: sam= e as (1). One more observation: when xen compiled with debug=3Dy, (2) and (4) cases= behaves the same as (1). Hopefully I will have real serial console somehow in this week and will b= e able to get more details from hang and reboot cases. BTW Any chances for Xen ACPI S3 patches in upstream kernel? --=20 Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab --------------enig0F82590E11D1986C3F3A1892 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRUDa/AAoJENuP0xzK19cs/kkH+QFabmB23/umTQfpgAqQ4Vg1 meAPMvyPSoCdfxdGWCn/haN3MScn7OX/gtpTGyO7QbAA5xRcs8cTBOW1FyN6Apzx Nm1xC5XSDp3NFgU+qUoJqtpY93SucSmWXobO5zfavMJHzRa5eQ2H6PXkNJ7CsWip XoIFhg+BXxhAlGgkA/dakfnA5M7thgd0GvygS5c7nDl9bkkm2F1ggzisce3yedrk UE7YXkIdGbyQqueVsivT7Ak9xNg12pZKrdxAdbZRAVhpQ1yp9tuIFXOYhFXNdusC iL2WK1ZxYcM+6THofi0Tvr63Zlk+R1HkNjbIxiUCUlpupbJJ3RF1FGgXFNyzI3Y= =Zvxl -----END PGP SIGNATURE----- --------------enig0F82590E11D1986C3F3A1892-- --===============2258617105890356567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2258617105890356567==--