All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cleber Rosa <crosa@redhat.com>
To: qemu-devel <qemu-devel@nongnu.org>,
	David Hildenbrand <dhildenb@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	 John G Johnson <john.g.johnson@oracle.com>,
	Jagannathan Raman <jag.raman@oracle.com>,
	 Willian Rampazzo <willianr@redhat.com>
Subject: tests/acceptance/multiprocess.py test failure
Date: Wed, 14 Jul 2021 21:59:13 -0400	[thread overview]
Message-ID: <CA+bd_6+2zk0N=s-D2OG4FUZ-HirJ+8HkMUktF=Jqyf9_HhyH1w@mail.gmail.com> (raw)

Hi everyone,

The tests/acceptance/multiprocess.py:Multiprocess.test_multiprocess_x86_64
is currently failing (as of a9649a719a44894b81f38dc1c5c1888ee684acef).
Unfortunately CI was unable to catch this issue earlier, because tests
that require KVM are not yet running (but this should change soon).
The relevant part of the test logs is:

VM launch command: './qemu-system-x86_64 -display none -vga none
-chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_5g22rvrp/qemu-427815-monitor.sock
-mon chardev=mon,mode=control -chardev
socket,id=console,path=/var/tmp/avo_qemu_sock_5g22rvrp/qemu-427815-console.sock,server=on,wait=off
-serial chardev:console -machine pc -accel kvm -cpu host -object
memory-backend-memfd,id=sysmem-file,size=2G --numa
node,memdev=sysmem-file -m 2048 -kernel
/home/cleber/avocado/data/cache/by_location/b4c64f15a75b083966d39d9246dd8db177736bb4/vmlinuz
-initrd /home/cleber/avocado/data/cache/by_location/b4c64f15a75b083966d39d9246dd8db177736bb4/initrd.img
-append printk.time=0 console=ttyS0 rdinit=/bin/bash -device
x-pci-proxy-dev,id=lsi1,fd=16'
>>> {'execute': 'qmp_capabilities'}

The test remains stuck here for as long as the test is allowed to run.
Because there's currently no timeout in the test, it can remain stuck
forever.  But, with a timeout, we end up getting:

Error launching VM
Command: './qemu-system-x86_64 -display none -vga none -chardev
socket,id=mon,path=/var/tmp/avo_qemu_sock_5g22rvrp/qemu-427815-monitor.sock
-mon chardev=mon,mode=control -chardev
socket,id=console,path=/var/tmp/avo_qemu_sock_5g22rvrp/qemu-427815-console.sock,server=on,wait=off
-serial chardev:console -machine pc -accel kvm -cpu host -object
memory-backend-memfd,id=sysmem-file,size=2G --numa
node,memdev=sysmem-file -m 2048 -kernel
/home/cleber/avocado/data/cache/by_location/b4c64f15a75b083966d39d9246dd8db177736bb4/vmlinuz
-initrd /home/cleber/avocado/data/cache/by_location/b4c64f15a75b083966d39d9246dd8db177736bb4/initrd.img
-append printk.time=0 console=ttyS0 rdinit=/bin/bash -device
x-pci-proxy-dev,id=lsi1,fd=16'
Output: "qemu-system-x86_64: ../../src/qemu/softmmu/physmem.c:2055:
qemu_ram_alloc_from_fd: Assertion `(ram_flags & ~(RAM_SHARED |
RAM_PMEM | RAM_NORESERVE)) == 0' failed.\n"

I've bisected it to:

---

d5015b80134047013eeec10000df5ce2014ee114 is the first bad commit
commit d5015b80134047013eeec10000df5ce2014ee114
Author: David Hildenbrand <david@redhat.com>
Date:   Mon May 10 13:43:17 2021 +0200

    softmmu/memory: Pass ram_flags to qemu_ram_alloc_from_fd()

    Let's pass in ram flags just like we do with qemu_ram_alloc_from_file(),
    to clean up and prepare for more flags.

    Simplify the documentation of passed ram flags: Looking at our
    documentation of RAM_SHARED and RAM_PMEM is sufficient, no need to be
    repetitive.

    Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Acked-by: Eduardo Habkost <ehabkost@redhat.com> for memory backend
and machine core
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Message-Id: <20210510114328.21835-5-david@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 backends/hostmem-memfd.c | 7 ++++---
 hw/misc/ivshmem.c        | 5 ++---
 include/exec/memory.h    | 9 +++------
 include/exec/ram_addr.h  | 6 +-----
 softmmu/memory.c         | 7 +++----
 5 files changed, 13 insertions(+), 21 deletions(-)

---

To reproduce it:

1. configure --target-list=x86_64-softmmu
2. meson compile
3. make check-venv
4. ./tests/venv/bin/avocado --show=test run --job-timeout=20s
tests/acceptance/multiprocess.py:Multiprocess.test_multiprocess_x86_64

It'd be helpful to know if anyone else is experiencing the same failure.

Thanks,
- Cleber.



             reply	other threads:[~2021-07-15  2:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15  1:59 Cleber Rosa [this message]
2021-07-15  8:16 ` tests/acceptance/multiprocess.py test failure David Hildenbrand
2021-07-15 13:16   ` Cleber Rosa
2021-07-15 14:51     ` Jag Raman
2021-07-20 18:39       ` Cleber Rosa
2021-07-20 20:13         ` Jag Raman
2021-07-20 20:20           ` Peter Maydell

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='CA+bd_6+2zk0N=s-D2OG4FUZ-HirJ+8HkMUktF=Jqyf9_HhyH1w@mail.gmail.com' \
    --to=crosa@redhat.com \
    --cc=dhildenb@redhat.com \
    --cc=elena.ufimtseva@oracle.com \
    --cc=jag.raman@oracle.com \
    --cc=john.g.johnson@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=willianr@redhat.com \
    /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.