Public bug reported:
Information:
OS: Slackware64-Current
Compiled with: gcc version 5.3.0 (GCC) / glibc 2.23
Compiled using:
CFLAGS="-O2 -fPIC" \
CXXFLAGS="-O2 -fPIC" \
LDFLAGS="-L/usr/lib64" \
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--libdir=/usr/lib6
Sure, I did the same test and still got a SIGABRT, but the debug looks a
little different:
Backtrace:
#0 0x7f8f0d46a3f8 in raise () at /lib64/libc.so.6
#1 0x7f8f0d46bffa in abort () at /lib64/libc.so.6
#2 0x7f8f0d462c17 in __assert_fail_base () at /lib64/libc.so.6
#3 0x7f8f0d4
It still fails with ext4:
#0 0x7fbaa12b33f8 in raise () at /lib64/libc.so.6
#1 0x7fbaa12b4ffa in abort () at /lib64/libc.so.6
#2 0x7fbaa12abc17 in __assert_fail_base () at /lib64/libc.so.6
#3 0x7fbaa12abcc2 in () at /lib64/libc.so.6
#4 0x5646b990f926 in mirror_run (s=0x56
I just tested master, and it does the same as 2.6.0-rc
The 2.6.0 branch crashes much faster than 2.5.x
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1570134
Title:
While committing snapshot qe
Thank you for working on this. Super helpful to have someone looking at
this issue!
With those two patches applied to 2.6.0-rc2 I still get the following:
qemu-system-x86_64: block/mirror.c:342: mirror_iteration: Assertion
`hbitmap_next == next_sector' failed.
The line number confirms that qemu
Max,
Qemu still crashes for me, but the debug is again very different. When
I attach to the qemu process from gdb, it is unable to provide a
backtrace when it crashes. The log file is different too. Any ideas?
qemu-system-x86_64: block.c:2307: bdrv_replace_in_backing_chain:
Assertion `!bdrv_re
Running master as of this morning 4/22 and I'm not getting any more
crashes, and I'm flat beating on it. RC3 still crashes on me, so
whatever the fix is, came after rc3.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.la
Am 28.09.2017 um 19:01 hat Dr. David Alan Gilbert geschrieben:
> Hi,
> This is a 'fun' bug; I had a good chat to kwolf about it earlier.
> A proper fix really needs to be done together with libvirt so that we
> can sequence:
>a) The stopping of the CPU on the source
>b) The termination o
Public bug reported:
Source server: linux 4.19.5 qemu-3.0.0 from source, libvirt 4.9
Dest server: linux 4.18.19 qemu-3.0.0 from source, libvirt 4.9
When this VM is running on source server:
/usr/bin/qemu-system-x86_64 -name guest=testvm,debug-threads=on -S
-object
secret,id=masterKey0,format=raw
If I remote iothreads and writeback caching, it seems more reliable, but
I can still get it to hang.
This time the source server shows the VM as running, backtrace looks
like:
(gdb) bt full
#0 0x7f27eab0028c in __lll_lock_wait () at /lib64/libpthread.so.0
#1 0x7f27eaaf9d35 in pthread_mu
Public bug reported:
Qemu version on both sides: 2.12.1
Host A Linux: 4.9.76
Host B Linux: 4.14.67
While calling from Host A:
virsh migrate virtualmachine qemu+ssh://hostB/system --live --undefinesource
--persistent --verbose --copy-storage-all
I get a qemu crash with:
2018-09-21 16:12:23.073+
Tested with Qemu 3.0.0 and this still happens.
Also tested with kernel 4.9.128 on one side and 4.9.76 on the other
thinking it might be a kernel 4.14 issue.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/b
Hi Eric,
Thanks for looking at this.
I looked at the nbd/server.c code and couldn't see how it could send a
NBD_REPLY_TYPE_NONE packet without setting the NBD_REPLY_FLAG_DONE bit.
The only place NBD_REPLY_TYPE_NONE is set is on line 1603:
set_be_chunk(&chunk, NBD_REPLY_FLAG_DONE, NBD_REPLY_T
I'm back to trying to figure this out. I can't use migrate and copy
storage until this bug is fixed, so I'm pretty motivated. Today I
configured libvirt/qemu to dump the core, and I compiled qemu with
debugging symbols. Here is the backtrace. I'm not sure it says
anything we don't already know.
>From the core:
structured = {magic = 1732535960, flags = 0, type = 0, handle =
94174913593865, length = 0}
You would think that would pass:
chunk = &reply->structured;
if (chunk->type == NBD_REPLY_TYPE_NONE) {
/* NBD_REPLY_FLAG_DONE is already checked in nbd_co_receive_one_chun
Okay, this is probably a race condition bug. If remove:
1
and
iothread='1' from the disk which causes the command to change from:
-device virtio-blk-
pci,iothread=iothread1,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-
disk0,id=virtio-disk0,bootindex=2,write-cache=on
to
-device virtio-blk-p
I see the same thing:
2017-12-28 21:36:26.837+: initiating migration
qemu-system-x86_64: block/io.c:1537: bdrv_co_pwritev: Assertion
`!(bs->open_flags & BDRV_O_INACTIVE)' failed.
2017-12-28 21:36:40.516+: shutting down, reason=crashed
~
Running:
QEMU emulator version 2.10.1
libvirtd (lib
17 matches
Mail list logo
