From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Resume not working on 2nd gen Core i5 Date: Fri, 24 Feb 2012 00:54:18 -0500 Message-ID: <20120224055418.GA11780@phenom.dumpdata.com> References: <4F460354.7080907@invisiblethingslab.com> <20120223141827.GC23963@phenom.dumpdata.com> <20120223173146.GA22922@phenom.dumpdata.com> <4F4679D1.3000806@invisiblethingslab.com> <20120223180313.GC22574@phenom.dumpdata.com> <4F46E174.6040009@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: <4F46E174.6040009@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.xensource.com" , Joanna Rutkowska List-Id: xen-devel@lists.xenproject.org > >>>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises how > >>>>> to approach debugging it? > >>>>> .. snip.. > (the same hardware) > On 2.6.38.3 xenlinux kernel after resume there is screen content from before > suspend, power led light constantly (as it should), but system is > irresponsible (no capslock led, no reaction to sysrq, network etc). > On 3.x with your patches system goes into S3, but on resume is even worse - no > screen content at all (and no backlight) and also irresponsible, power led > still blinking. As 3.x tried: > - your devel/acpi-s3.v7 branch directly > - 3.2.7 merged with devel/acpi-s3.v7 > - 3.3-rc4 with devel/acpi-s3.v7 OK. That is weird - it worked for me last time. One thing at at time then - try doing this from text-mode, so no graphic mode involved. For that you might need to disable your i915 driver altogether. Then just run 'pm-suspend' and see where it stops. The next part is... Wait a minute, this reminds me of something I encountered with a SandyBrige i2100 - the suspend would work, but resume would get stuck. The issue was with the hypervisor and if I had the acpi-cpufreq drivers loaded it resumed just fine. If I didn't - so hypervisor had no idea about C states or P states, it would be stuck in the default_idle and never come back. So you might want for fun try also using the stable/processor-passthru.v5 and build it with CONFIG_XEN_PROCESSOR_PASSTHRU=y. But the other issue could be with your ExpressCard. I don't know if you are using the serial console output on it, but there might be a bug in the hypervisor where it ends up looping forver if you are using a serial console). So try _not_ using it and seeing what happens. > - your devel/acpi-s3.v8 branch directly > The same result on all above. > > How can I debug this issue? Try those things. Then start ramping up the debug options to get an idea of what is not working. Also, flash your BIOS just in case. > > -- > Best Regards / Pozdrawiam, > Marek Marczykowski > Invisible Things Lab >