From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rbw65-0006xh-Pz for qemu-devel@nongnu.org; Sat, 17 Dec 2011 10:22:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rbw64-0005Tw-BL for qemu-devel@nongnu.org; Sat, 17 Dec 2011 10:22:49 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:62622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rbw64-0005Ts-8g for qemu-devel@nongnu.org; Sat, 17 Dec 2011 10:22:48 -0500 Received: by yhgg71 with SMTP id g71so3989605yhg.4 for ; Sat, 17 Dec 2011 07:22:47 -0800 (PST) Message-ID: <4EECB3C5.6060608@codemonkey.ws> Date: Sat, 17 Dec 2011 09:22:45 -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> <4EECB1B0.7050404@codemonkey.ws> In-Reply-To: <4EECB1B0.7050404@codemonkey.ws> 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 09:13 AM, Anthony Liguori wrote: > 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? I've even further narrowed it down to the presents or lack of '-vga cirrus'. If you add '-vga cirrus' to the above command line, the guest will boot successfully. Regards, Anthony Liguori > > 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. >> >