All of lore.kernel.org
 help / color / mirror / Atom feed
From: tg@gmplib.org (Torbjörn Granlund)
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el
Date: Sat, 02 Aug 2014 22:49:22 +0200	[thread overview]
Message-ID: <86egwyfwh9.fsf@shell.gmplib.org> (raw)

Qemu versions 1.7.0, 1.7.1, 2.0.0, 2.1.0 do not run Debian mips64 BE or
LE stably.  While install in 32-bit mode typically works, running the
64-bit kernel causes qemu to segfault or abort after a while.

How to reproduce:

Grab installation kernel and initrd:

ftp://ftp.debian.org/debian/dists/wheezy/main/installer-mips/current/images/malta/netboot/vmlinux-3.2.0-4-4kc-malta
ftp://ftp.debian.org/debian/dists/wheezy/main/installer-mips/current/images/malta/netboot/initrd.gz

Start qemu-system-mips64 and perform an installation.  Choose defaults,
i.e., "Standard system utilities" and "SSH server".

  qemu-system-mips64 -M malta -m 256 -nographic \
    -drive file=disk.img,if=virtio,index=0 \
    -net nic,macaddr=52:54:00:13:06:64 -net user,hostfwd=tcp::20008-:22 \
    -kernel vmlinux-3.2.0-4-4kc-malta \
    -initrd initrd.gz \
    -append "console=ttyS0"

Copy out /boot somehow.  I usually do "Execute a shell" just before the
installation is about to finish, and there do

  mount /dev/vda2 /target
  mount /dev/vda1 /target/boot
  mount -t proc proc /target/proc
  mount --rbind /sys /target/sys
  mount --rbind /dev /target/dev
  chroot /target bash
  /etc/init.d/ssh start

(assuming "put all files in one partition" was chosen; mount commands
might need adjustment for other partitioning schemes).

Then from the host system I do

  scp -pr -P 20008 localhost:/boot .

and then quit the shell and finish up the installation.  (Alternatively
use qemu-nbd or guestfish.)

Then boot the installed system:

  qemu-system-mips64 -M malta -cpu 5Kc -m 256 \
    -drive file=disk.img,if=virtio,index=0 \
    -net nic,macaddr=52:54:00:13:06:64 -net user,hostfwd=tcp::20008-:22 \
    -kernel boot/vmlinux-3.2.0-4-5kc-malta \
    -initrd boot/initrd.img-3.2.0-4-5kc-malta \
    -append "root=/dev/vda1 console=ttyS0" \
    -nographic -serial null -monitor null

Then, log in to the system ("ssh -p 20008 root@localhost) and try the
system.  It will crash within hours, but usually within minutes.

Safe crash strategy:

  package_list="gcc g++ gdb make emacs23-nox postfix sharutils zsh rsync ntp"
  apt-get -y install $package_list gcc-multilib g++-multilib

Not crashed yet?  Let's provoke it somewhat more:

  wget https://ftp.gnu.org/gnu/gmp/gmp-6.0.0a.tar.bz2
  tar xf gmp-6.0.0a.tar.bz2
  cd gmp-6.0.0
  (configure && make && while true; do make check; done) >&/dev/null

Note that I have reproduced this problem on several host machines.  Host
system stability is not the root cause.  The host system has been either
GNU/Linux or FreeBSD.  I have not found a stable setup since before qemu
1.7.0.  I know it was stable around 1.5.x or 1.6.x.  (Even older qemus
executed a few instructions incorrectly, making them inadequate for my
use.)

Other notes:

1. Replacing virtio with ide for the disk spec does not improve things.

2. Both qemu-system-mips64 and qemu-system-mips64el exhibit the same
   instability patterns.

3. At least qemu-system-mips64el 2.1.0 sometimes hangs also during
   initial install, i.e., while running in 32-bit mode.  (I only
   observed this with virtio disk.)

Torbjörn
Please encrypt, key id 0xC8601622

             reply	other threads:[~2014-08-02 20:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-02 20:49 Torbjörn Granlund [this message]
2014-08-03  0:11 ` [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el Torbjörn Granlund
2014-10-17  7:32   ` Aurelien Jarno
2014-10-17  7:28 ` Aurelien Jarno
2014-10-17 13:53   ` Torbjörn Granlund
2014-10-17 18:23     ` Aurelien Jarno
2014-10-17 18:57       ` Torbjörn Granlund
2014-10-17 19:09         ` Aurelien Jarno
2014-10-22 20:31           ` Torbjörn Granlund
2014-10-22 22:07             ` Aurelien Jarno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86egwyfwh9.fsf@shell.gmplib.org \
    --to=tg@gmplib.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.