From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Re: DomU lockups after resume from S3 on Core i5 processors Date: Tue, 06 Jul 2010 09:41:34 +0100 Message-ID: <4C33085E0200007800009AE1@vpn.id2.novell.com> References: <4C31B629.7070601@invisiblethingslab.com> <4C324E8C.4030305@invisiblethingslab.com> <4C3257B2.1040002@invisiblethingslab.com> <4C32602A.8070305@goop.org> <4C326241.2030503@invisiblethingslab.com> <4C3267FB.3070202@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4C3267FB.3070202@goop.org> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge , Joanna Rutkowska Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> On 06.07.10 at 01:17, Jeremy Fitzhardinge wrote: > On 07/05/2010 03:52 PM, Joanna Rutkowska wrote: >> On 07/06/10 00:43, Jeremy Fitzhardinge wrote: >>> Do you know what's going on it in that it might be waiting >>> for? >>> =20 >> No idea. I might be guessing that it would be different kernel >> subsystems each time -- e.g. when I'm lucky and when the apps got only >> "partially" locked up, I can e.g. open new tabs in Google Chrome, I can >> see some thumbnails of my popular websites, but without their contents. >> This would suggest the networking subsystem is dead, but at the same >> time Chrome is apparently communicating fine with the X server in the >> DomU (and which in turn talks fine with Dom0 over Xen shared >> memory/evtchanl). >> >> I experienced the above behavior also when had only one VCPU er DomU. >> =20 >=20 > I've seen similar things with just normal domain save/restore, where the > timer interrupt seems to be failing. Can you ssh into the domain? I > found that I couldn't do an interactive ssh (hung at the prompt), but a > non-interactive command would work, so I could cat /proc/interrupts. Did either of you try disabling the setting of sched_clock_stable in arch/x86/kernel/cpu/intel.c:early_init_intel()? I found this to be a requirement in our pv kernels (though in connection with the use of C-states, not with S3). Jan