* Mike Snitzer <[email protected]> [2010-09-09 10:58]: > On Thu, Sep 09 2010 at 11:44am -0400, > Ryan Harper <[email protected]> wrote: > > > * Mike Snitzer <[email protected]> [2010-09-09 10:29]: > > > On Wed, Sep 01 2010 at 11:22pm -0400, > > > Mike Snitzer <[email protected]> wrote: > > > > > > > On Wed, Sep 01 2010 at 2:59pm -0400, > > > > Mike Snitzer <[email protected]> wrote: > > > > > > > > > My hope was that the request-based deadlock I'm seeing would disappear > > > > > if that relaxed ordering patch wasn't applied. Unfortunately, I still > > > > > see the hang. > > > > > > > > Turns out I can reproduce the hang on a stock 2.6.36-rc3 (without _any_ > > > > FLUSH+FUA patches)! > > > > > > > > I'll try to pin-point the root cause but I think my test is somehow > > > > exposing a bug in my virt setup. > > > > > > [my virt setup == single kvm guest (RHEL6) with F13 host] > > > > What's your kvm guest command line? > > I assume you mean qemu-kvm commandline: > > /usr/bin/qemu-kvm -S -M pc-0.11 -enable-kvm -m 2048 -smp > 1,sockets=1,cores=1,threads=1 -name rhel6.x86_64 -uuid > 9129e4e4-15d3-00e2-e9de-2c28a29feb52 -nodefaults -chardev > socket,id=monitor,path=/var/lib/libvirt/qemu/rhel6.x86_64.monitor,server,nowait > -mon chardev=monitor,mode=readline -rtc base=utc -boot cd -drive > file=/var/lib/libvirt/images/rhel6.x86_64.img,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none > -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 > -drive > file=/var/lib/libvirt/images/boot.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device > virtio-net-pci,vlan=0,id=net0,mac=54:52:00:70:e8:23,bus=pci.0,addr=0x6 -net > tap,fd=49,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device > isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 > -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 > > I'm using virtio-blk w/ cache=none for the root device. virtio-blk > isn't used for any other devices in the guest.
And you don't have any other disks in the guest (I see just the root and the cdrom), the lv stuff is happening against some sort of dummy target? > > Here is the guest's kernel commandline (not that it is interesting): > ro root=UUID=e0236db2-5a38-4d48-8bf5-55675671dee6 console=ttyS0 rhgb quiet > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=charge > crashkernel=auto > > > And the guest is using stock RHEL6 kernel? > > No, the guest is using the upstream kernel.org kernel. Hence my report > of an upstream regression. The guest is using RHEL6 userspace (udev in > all its glory, etc). > > > What KVM userspace are you using on the host? What comes with > > F13 or some updated version? > > Just what comes with F13. > > Mike -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx [email protected] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
