Re: random crash in post_kvm_run()

[Avi Kivity <avi@redhat.com>]

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