From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: 2.6.32 guest with paravirt clock enabled hangs on 2.6.37.6 host (w qemu-kvm-0.13.0) Date: Mon, 09 May 2011 11:30:13 -0700 Message-ID: <4DC832B5.6000205@redhat.com> References: <20110508183303.GA7918@nik-comp.lan> <4DC6E6C4.4030103@msgid.tls.msk.ru> <20110508190637.GB7918@nik-comp.lan> <4DC8252A.9050405@redhat.com> <20110509182525.GA2202@nik-comp.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , kvm@vger.kernel.org To: Nikola Ciprich Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57867 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751911Ab1EISak (ORCPT ); Mon, 9 May 2011 14:30:40 -0400 In-Reply-To: <20110509182525.GA2202@nik-comp.lan> Sender: kvm-owner@vger.kernel.org List-ID: On 05/09/2011 11:25 AM, Nikola Ciprich wrote: > The guest, because latest kernels do not suffer this problem, so I'd like to > find fix so it can be pushed to -stable (we're using 2.6.32.x) > host is currently 2.6.37 (and i'm currently testing 2.6.38 as well) > n. That's a pretty wide range to be bisecting, and I think we know for a fact there were some kvmclock related bugs in that range. If you are looking for something causing problems with tcpdump, I'd suggest getting rid of kvmclock in your testing and using TSC instead; if you're looking to verify that kvmclock related changed have been backported to -stable, rather than bisect and run into bugs, it would probably be faster to check the commit logs for arch/x86/kvm/x86.c and make sure you're not missing anything from me or Glauber that has been applied to the most recent branch. Zach