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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
