On Fri, Jul 2, 2010 at 9:07 AM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > On Fri, Jul 2, 2010 at 4:31 AM, ewheeler <kvm@xxxxxxxxxxxxxxx> wrote: >> Hello all, >> >> I'm booting a CentOS kernel under today's KVM git and it hangs after >> initializing the serial port when the drive if=virtio, but not when >> drive if=ide. Look close---this is not a "forgot to add virtio_blk" >> problem. If I use 0.12.3 from Ubuntu 10.04 it works properly. >> >> Reproduction: >> >> Using kvm 0.12.3 on ubuntu 10.04 (1:84+dfsg-0ubuntu16+0.12.3+noroms >> +0ubuntu9) it will work properly: >> >> qemu-system-x86_64 -drive file=dummy-disk-image,if=virtio \ >> -kernel vmlinuz-2.6.18-194.3.1.el5.centos.plus >> >> As expected, the kernel panics unable to mount root (good-boot.png). >> This makes sense, as "dummy-disk-image" is 1MB of 0x00 bytes. >> >> ---However---if I use today's git (2010-07-01) of kvm: >> >> /usr/local/kvm-git/bin/qemu-system-x86_64 -drive file=dummy-disk-image,if=virtio \ >> -kernel vmlinuz-2.6.18-194.3.1.el5.centos.plus >> >> This hangs just after initializing the Serial device (obtained by adding >> -serial stdio -append console=ttyS0): >> >> Note that this only happens with the disk interface set to virtio >> (if=virtio). It works fine for ide (if=ide). >> >> >> Am I doing something wrong here? >> Is anyone else having this problem? > > I have seen this issue with a RHEL 5.5 guest running under > qemu-kvm.git. It boots a new guest fine but hangs as you described > with the RHEL 5.5 kernel. I have not investigated. This issue is affected by extboot, a feature that enables booting from virtio-blk devices. I have just sent a patch to the KVM mailing list to restore extboot functionality which has been broken in qemu-kvm.git. That patch can be used to work around this issue by using "-drive ...,boot=on" but it doesn't explain why the RHEL 5.5 kernel hangs during serial initialization when extboot is not present. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html