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: Fri, 22 Mar 2013 16:34:11 +0100 Message-ID: <514C79F3.5050504@invisiblethingslab.com> References: <5140E69F.9090803@invisiblethingslab.com> <20130315130240.GA8582@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4312191637978590407==" Return-path: In-Reply-To: <20130315130240.GA8582@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) --===============4312191637978590407== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44EDFAC788F07753FBE186C6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44EDFAC788F07753FBE186C6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15.03.2013 14:02, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 13, 2013 at 09:50:39PM +0100, Marek Marczykowski wrote: >> Hi, >> >> I've still have problems with ACPI(?) on Xen. After some system startu= p or >> resume CPU temperature goes high although all domUs (and dom0) are idl= e. On >> "good" system startup it is about 50-55C, on "bad" - above 67C (most t= ime >> above 70C). I've noticed difference in C-states repored by Xen (attach= ed >> files). On "bad" startups in addition suspend doesn't work - system re= starts >> during suspend (still didn't managed to get console messages - I don't= have >> serial port on this system). Note that sometimes system boots fine ("g= ood" >> state), but problem occurs after some suspend/resume cycles. Some time= ago >> I've got other symptoms: only CPU0 was used - for all VCPUs (according= to xl >> vcpu-list). Maybe it is related? >> >> Hardware: Dell Latitude E6420 >> CPU: Intel i5-2520M >> >> Software: >> xen stable-4.1 as of 15.02 (last commit: "xen: sched_creadit: improve = picking >> up the idle CPU for a VCPU"), with reverted commit "Introduce system_s= tate >> variable." >> But the same problem on vanilla xen 4.1.2. >> >> Linux 3.7.6 - happens almost every boot. On Linux 3.7.4 happens much r= arer >> (but still occurs). >> Kernel config: >> http://git.qubes-os.org/gitweb/?p=3Dmarmarek/kernel.git;a=3Dblob;f=3Dc= onfig-pvops;h=3Da6e953f71cdc84556571b592b8af87a5a4f9a8d0;hb=3DHEAD >> I've tried some bisect from 3.7.4 to 3.7.6, but without success becaus= e >> problem isn't 100% reproducible. >> >> Any ideas? >=20 > That C-states difference is important. The SYSIO part on your box means= that the > CPU ends up doing an MWAIT. An HALT on the other hand is not so power-s= aving > friendly. >=20 > Looking at this: >> (XEN) no cpu_id for acpi_id 5 >> (XEN) no cpu_id for acpi_id 6 >> (XEN) no cpu_id for acpi_id 7 >> (XEN) no cpu_id for acpi_id 8 >=20 > .. means that xen-acpi-processor was trying to probe for the ACPI IDs o= f the > the other CPUs that the machine theoritcally can support. That means it= got > the ACPI information for the first four CPUs (which is good). >=20 > You can as the first step in trying to figure this out, add #define DEB= UG 1 > in xen-acpi-processor.c right before any of the #includes. And also boo= t > Xen with 'cpufreq=3Dverbose'. That should tell you what kind of C-state= s the > xen-acpi-processor uploaded (And if it did it for all of the vCPUS). >=20 > If both bootups show that we do upload the C-states for all the CPUs bu= t they > vary that means digging a bit deeper in the ACPI code. Specifically in = > acpi_processor_get_power_info_cst and seeing if it hits any of the 'con= tinue'. >=20 > Then I would say take also the DSDT for both bootups and compare them. = It might > be that the BIOS is using a scratch register at reboot to construct the= C-states > and somehow it ends up being corrupted. Which means that on the next wa= rm reboot > the C-states has bogus data. This does show up in the field :-( Finally I've found some time for further debugging this. And it looks lik= e some deeper ACPI code problem... I've switched to 3.8.4, on which problem is much easier to reproduce (alm= ost 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=3D= 1). In this case suspend (or shutdown) always ends up with reset. On good one xen-acpi-processor got C1-C3 states for each CPU, then suspen= d succeeded, but after resume CPU0 had C1-C3, but others only C1. Reloading= xen-acpi-processor (rmmod -f...) fixes this (according to xl debug-key c)= , but still temperature keep high. Regardless of xen-acpi-processor reloading, = next suspend always fails. Not sure how C-states can be related to S3 suspend, but perhaps something= more general with ACPI is wrong? Each time DSDT (get from /sys/firmware/acpi/tables) is exactly the same. --=20 Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab --------------enig44EDFAC788F07753FBE186C6 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/ iQEcBAEBAgAGBQJRTHn0AAoJENuP0xzK19cs8CgH/Ru2cpSVpfntkmoAmXVYlsZv 1tp/vMoQqFNG35UQER+Q7xGV1nIkvTq61nd2j0RY59HoKShPtcstDbndD1SNasIE Sa1ztai5LZshqLgiSQQuKOeQCSuK8Eit36mfUJen6ys772PT+uYneaHcueWiEGUI E98BuDk7ba9Bfvbh4XH0YTikka1gHbaYA4CLJtGZGaNs99jHYAS8/QmlZKfCHlWR h5sYwQRmRwTSfs/N7fTe0GCHNRq/MQ54yMmE2Y5M1ZDzWo9pL5hKdEYEraZlYkzY guvxsG5gaClTAn7JICUQwXaPgr4wR1McFZ/0pEGfourw9VmjFpJyptUoU3z1Tvs= =unFL -----END PGP SIGNATURE----- --------------enig44EDFAC788F07753FBE186C6-- --===============4312191637978590407== 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 --===============4312191637978590407==--