Anyone fancy trying to reproduce a qemu-system-ppc64 bug?

Richard W.M. Jones rjones at redhat.com
Mon Jun 11 17:43:28 UTC 2012


I'm trying to track down a bug either in our Fedora kernel or in
(upstream) qemu-system-ppc64.  Occasionally when accessing disk, the
VM hangs.  qemu sits doing nothing -- it appears to be a case of a
lost interrupt or event.

Before I try to report this upstream, it'd be helpful if anyone on
this list could try to reproduce the problem.  It is fairly simple,
but the test may take hours to run.

Note this can be tested on either x86-64 or ppc64 host!  For me, both
types of host show the bug.

(1) Compile qemu-system-ppc64 from upstream git:

  cd /tmp
  sudo yum install libfdt-devel SDL-devel bluez-libs-devel brlapi-devel \
    ceph-devel check-devel cyrus-sasl-devel gnutls-devel libaio-devel \
    libattr-devel libcurl-devel libjpeg-devel libpng-devel libuuid-devel \
    ncurses-devel nss-devel pciutils-devel pulseaudio-libs-devel \
    rsync spice-protocol texi2html usbredir-devel which xfsprogs-devel \
    zlib-devel
  git clone git://git.qemu.org/qemu.git
  cd qemu
  ./configure
  make -k
  make -C ppc64-softmmu qemu-system-ppc64
  # if ppc64-softmmu/qemu-system-ppc64 has been created then you're
  # good, even if the make command failed

(2) Download my test virtual machine.  Note this requires ~400 MB on /tmp.

  cd /tmp
  wget http://oirase.annexia.org/tmp/ppc64/appliance-1.19.4.tar.xz
  xzcat appliance-1.19.4.tar.xz | tar xvf -

(3) Create a temporary disk.

  rm /tmp/test.img
  truncate -s 1G /tmp/test.img

(4) Run VM under qemu-system-ppc64:

  /tmp/qemu/ppc64-softmmu/qemu-system-ppc64 \
    -global virtio-blk-pci.scsi=off \
    -nodefconfig -nodefaults -nographic \
    -drive file=/tmp/test.img,cache=off,format=raw,if=virtio \
    -M pseries -m 500 \
    -no-reboot -serial stdio \
    -kernel appliance/kernel -initrd appliance/initrd \
    -append 'panic=1 console=ttyS0 udevtimeout=300 no_timer_check acpi=off printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=screen' \
    -drive file=appliance/root,snapshot=on,if=virtio,cache=unsafe

After the VM boots, you should see it in an endless loop creating a
filesystem and mounting it (inside the VM).

Eventually (maybe after several *hours*) it may hang
  ==> well done you have reproduced the bug!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora


More information about the ppc mailing list