From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbvxW-0004dv-HK for qemu-devel@nongnu.org; Sat, 17 Dec 2011 10:13:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbvxV-0004eR-I5 for qemu-devel@nongnu.org; Sat, 17 Dec 2011 10:13:58 -0500 Received: from mail-gy0-f173.google.com ([209.85.160.173]:47086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbvxV-0004eN-Cd for qemu-devel@nongnu.org; Sat, 17 Dec 2011 10:13:57 -0500 Received: by ghbg19 with SMTP id g19so3480930ghb.4 for ; Sat, 17 Dec 2011 07:13:56 -0800 (PST) Message-ID: <4EECB1B0.7050404@codemonkey.ws> Date: Sat, 17 Dec 2011 09:13:52 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20110930131148.GA4294@amd.home.annexia.org> <20110930165152.GB4294@amd.home.annexia.org> <20111216221956.GA23695@amd.home.annexia.org> <20111217000704.GB23695@amd.home.annexia.org> <4EEBF3EA.3040401@codemonkey.ws> <20111217082958.GJ2520@amd.home.annexia.org> In-Reply-To: <20111217082958.GJ2520@amd.home.annexia.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Amit Shah , Max Filippov , qemu-devel@nongnu.org, Gerd Hoffmann On 12/17/2011 02:33 AM, Richard W.M. Jones wrote: > On Fri, Dec 16, 2011 at 07:44:10PM -0600, Anthony Liguori wrote: >> 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. > > Yes, we do use virtio-serial. The command line is: > > /home/rjones/d/qemu/qemu.wrapper \ > -drive file=/tmp/libguestfs-test-tool-sda-b4hesH,cache=off,format=raw,if=virtio \ > -nodefconfig \ > -machine accel=kvm:tcg \ > -nodefaults \ > -nographic \ > -m 500 \ > -no-reboot \ > -no-hpet \ > -device virtio-serial \ > -serial stdio \ Okay, I can reproduce this now with a F15 guest. I've narrowed it down to '-nodefaults -serial stdio'. Can you confirm that if you remove those options it works for you? Regards, Anthony Liguori > -chardev socket,path=/tmp/libguestfsQQ187c/guestfsd.sock,id=channel0 \ > -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ > -kernel /var/tmp/.guestfs-500/kernel.24171 \ > -initrd /var/tmp/.guestfs-500/initrd.24171 \ > -append 'panic=1 console=ttyS0 udevtimeout=300 no_timer_check acpi=off printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=xterm ' \ > -drive file=/var/tmp/.guestfs-500/root.24171,snapshot=on,if=virtio,cache=unsafe > > which comes from this libguestfs test case: > > LIBGUESTFS_QEMU=~/d/qemu/qemu.wrapper libguestfs-test-tool -t 60 > > where qemu.wrapper is: > > #!/bin/sh - > qemudir=/home/rjones/d/qemu > exec $qemudir/x86_64-softmmu/qemu-system-x86_64 -L $qemudir/pc-bios "$@" > > I'll try it with/without virtio-serial. > > git bisect red herring is pretty strange? > > Rich. >