From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: random crash in post_kvm_run() Date: Thu, 01 Jul 2010 14:44:29 +0300 Message-ID: <4C2C7F9D.3010002@redhat.com> References: <4C29E435.1040201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: BuraphaLinux Server Return-path: Received: from mx1.redhat.com ([209.132.183.28]:40538 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755130Ab0GALoc (ORCPT ); Thu, 1 Jul 2010 07:44:32 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 06/30/2010 09:25 PM, BuraphaLinux Server wrote: >> >> Can you downgrade the kernel to a known good one to see which component >> causes the failure? >> >> > Thank you for your suggestion. Changing only the kernel back to > 2.6.32.14 and changing nothing else, the qemu/kvm works well. > However, I want to run the newer kernel to get all the fixes in newer > kernels. But for the short term, at least I can run my KVMs. > Sure. This looks like a regression, and we want to fix it. > Since I want to move to the newer kernel, I would like to keep working > to resolve my problem. Should I send the two kernel configs, or > bootup logs, or put them somewhere for download, or... ? > The surest way to find out the cause is to bisect. To do that, install git, and clone the Linux repository: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git $ cd linux-2.6 Start by verifying that 2.6.32 (not 2.6.32.14) still works: $ git checkout v2.6.32 # prune unnecessary modules $ make localmodconfig $ make && sudo make install # do your normal tests If that fails, it means the fix is somewhere in v2.6.32.y, which should be easy to find. If it works, start your bisect $ git bisect start v.2.6.34 v2.6.32 virt/kvm arch/x86/kvm Git will choose a commit, build it and test it. If it works, do a $ git bisect good otherwise, $ git bisect bad Git will then choose another test point; build, test, and repeat. Eventually it will spit out the commit which caused the problem. The process is time consuming, but has a high probability of pinpointing the cause of the bug accurately. -- error compiling committee.c: too many arguments to function