From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXuGg-0002WJ-An for qemu-devel@nongnu.org; Tue, 06 Dec 2011 07:37:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXuGb-0006fh-T2 for qemu-devel@nongnu.org; Tue, 06 Dec 2011 07:37:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXuGb-0006fW-MJ for qemu-devel@nongnu.org; Tue, 06 Dec 2011 07:37:01 -0500 Message-ID: <4EDE0C67.7050003@redhat.com> Date: Tue, 06 Dec 2011 14:36:55 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20111204161619.13512.72277.malonedeb@soybean.canonical.com> <20111204174528.12025.9519.malone@wampee.canonical.com> In-Reply-To: <20111204174528.12025.9519.malone@wampee.canonical.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Bug 899961] Re: qemu/kvm locks up when run 32bit userspace with 64bit kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 899961 <899961@bugs.launchpad.net> Cc: qemu-devel@nongnu.org On 12/04/2011 07:45 PM, Michael Tokarev wrote: > Actually after trying to do lots of experiments and finally a git > bisection, it turned out that the issue only affects qemu-kvm, not > upstream qemu. Bisection between qemu-kvm 0.15.0 and 1.0 lead to this > commit: > > commit 145e11e840500e04a4d0a624918bb17596be19e9 > Merge: ce967f6 b195043 > Author: Avi Kivity > Date: Wed Aug 10 12:06:58 2011 +0300 > > Merge commit 'b195043003d90ea4027ea01cc7a6c974ac915108' into upstream-merge > > * commit 'b195043003d90ea4027ea01cc7a6c974ac915108': (130 commits) > ... > > After which I'm stuck... ;) > 32-on-64 doesn't build on Fedora due to glib2-devel.i686 conflicting with its x86_64 cousin, so I can't reproduce this. Can you try bisecting this further? $ git tag M b195043003d90ea4027ea01cc7a6c974ac915108 $ git bisect start M M^ ... $ git merge --no-commit M^ [build and test] $ git merge --abort (or git checkout -f) $ git bisect [good|bad] if it happens that M^2 was the bad commit, you'll get a merge conflict. In that case do $ git merge --abort $ git merge M (you'll just be testing M again, but it's good to verify) -- error compiling committee.c: too many arguments to function