|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0 (was: Re: git-bisect results |
Date: | Fri, 16 Dec 2011 19:44:10 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 |
On 12/16/2011 06:53 PM, Max Filippov wrote:
git bisect says this. I didn't believe it first time, so I ran it twice with a few modifications, and it pointed to the same commit both times ...Richard, could you please elaborate on your testcase and configuration (host/target architecture, command lines, etc).Ok, I've found most of details, what's not clear to me is how you decide whether the build is good or bad. I mean, you need to rebuild qemu on every bisection step, but neither this commit nor the previous or the next one change anything that would compile for x86 targets.
Fairly certain this bisect is a red herring.tglx reported this the other day in IRC. He narrowed it down to virtio-serial. He was able to reproduce it both with kvm tools and QEMU.
Regards, Anthony Liguori
67882fd177389527510eb36b3f7712011a835545 is the first bad commit commit 67882fd177389527510eb36b3f7712011a835545 Author: Max Filippov<address@hidden> Date: Tue Sep 6 03:55:28 2011 +0400 target-xtensa: implement narrow instructions Instructions with op0>= 8 are 2 bytes long, others are 3 bytes long. Signed-off-by: Max Filippov<address@hidden> Signed-off-by: Blue Swirl<address@hidden> Rich.
[Prev in Thread] | Current Thread | [Next in Thread] |