> > > As mentioned earlier, even a totally simple/normal backup job fails when
> > > using io-threads and the VM is under load. It results in a total
> > > VM freeze!
> > >
> >
> > This is definitely a different issue. I'll take a look at it today.
>
> Thanks. Stefan found a way to avoid that
> > > > So the solution is to disable backups when using io-threads?
> > > >
> > >
> > > I meant forbidding transactions with completion-mode == grouped. It
> > > would be still possible running transactions (and thus, backups) with
> > > completion-mode == individual, which is the default.
> >
On Wed, Mar 25, 2020 at 04:40:48PM +0100, Dietmar Maurer wrote:
> > On March 25, 2020 1:39 PM Sergio Lopez wrote:
> >
> >
> > On Wed, Mar 25, 2020 at 01:29:48PM +0100, Dietmar Maurer wrote:
> > > > As expected, if both BDS are running on the same IOThread (and thus,
> > > > the same
> On March 25, 2020 1:39 PM Sergio Lopez wrote:
>
>
> On Wed, Mar 25, 2020 at 01:29:48PM +0100, Dietmar Maurer wrote:
> > > As expected, if both BDS are running on the same IOThread (and thus,
> > > the same AioContext), the problem is not reproducible.
> > >
> > > In a general sense, we could
On Wed, Mar 25, 2020 at 01:29:48PM +0100, Dietmar Maurer wrote:
> > As expected, if both BDS are running on the same IOThread (and thus,
> > the same AioContext), the problem is not reproducible.
> >
> > In a general sense, we could say that completion modes other than
> > "individual" are not
> As expected, if both BDS are running on the same IOThread (and thus,
> the same AioContext), the problem is not reproducible.
>
> In a general sense, we could say that completion modes other than
> "individual" are not supported for a transaction that may access
> different AioContexts. I don't
25.03.2020 14:40, Stefan Reiter wrote:
On 24/03/2020 17:49, Dietmar Maurer wrote:
A more serious issue is that I also get a hang inside the poll loop
when the VM is under load. For example, running "stress -d 5" inside
the VM (Debian Buster).
Then running a simply drive-backup like:
{
On Wed, Mar 25, 2020 at 09:13:12AM +0100, Sergio Lopez wrote:
> On Tue, Mar 24, 2020 at 02:47:43PM +0100, Max Reitz wrote:
> > Hi Dietmar,
> >
> > I assume this is with master and has popped up only recently?
> >
> > Maybe it has something to do with the recent mutex patches by Stefan, so
> > I’m
On 24/03/2020 17:49, Dietmar Maurer wrote:
A more serious issue is that I also get a hang inside the poll loop
when the VM is under load. For example, running "stress -d 5" inside
the VM (Debian Buster).
Then running a simply drive-backup like:
{ "execute": "drive-backup", "arguments": {
On Tue, Mar 24, 2020 at 02:47:43PM +0100, Max Reitz wrote:
> Hi Dietmar,
>
> I assume this is with master and has popped up only recently?
>
> Maybe it has something to do with the recent mutex patches by Stefan, so
> I’m Cc-ing him.
>
Hi,
I was able to reproduce the issue with a build after the
A more serious issue is that I also get a hang inside the poll loop
when the VM is under load. For example, running "stress -d 5" inside
the VM (Debian Buster).
Then running a simply drive-backup like:
{ "execute": "drive-backup", "arguments": { "device": "drive-scsi0", "sync":
"full",
> I assume this is with master and has popped up only recently?
sure
> Maybe it has something to do with the recent mutex patches by Stefan, so
> I’m Cc-ing him.
Thanks.
> What version of QEMU are you running? Sergio contributed a lot of AIO
> context (and iothread) fixes this release; this looks (at a glance) to
> be similar and related.
I test with latest code from git
commit 09a98dd988c715157c0b80af16fa5baa80101eed
Merge: f1e748d279 1583794b9b
Author:
Hi Dietmar,
I assume this is with master and has popped up only recently?
Maybe it has something to do with the recent mutex patches by Stefan, so
I’m Cc-ing him.
Max
On 24.03.20 14:33, Dietmar Maurer wrote:
> spoke too soon - the error is still there, sigh
>
>> This is fixed with this
Well, that was a rollercoaster of emotions as I read your mails.
On 3/24/20 9:33 AM, Dietmar Maurer wrote:
> spoke too soon - the error is still there, sigh
>
>> This is fixed with this patch:
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg07249.html
>>
>> thanks!
>>
>>> On
spoke too soon - the error is still there, sigh
> This is fixed with this patch:
>
> https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg07249.html
>
> thanks!
>
> > On March 24, 2020 12:13 PM Dietmar Maurer wrote:
> >
> >
> > I get a core dump with backup transactions when using
This is fixed with this patch:
https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg07249.html
thanks!
> On March 24, 2020 12:13 PM Dietmar Maurer wrote:
>
>
> I get a core dump with backup transactions when using io-threads.
>
> To reproduce, create and start a VM with:
>
> #
I get a core dump with backup transactions when using io-threads.
To reproduce, create and start a VM with:
# qemu-img create disk1.raw 100M
# qemu-img create disk2.raw 100M
#./x86_64-softmmu/qemu-system-x86_64 -chardev
'socket,id=qmp,path=/var/run/qemu-test.qmp,server,nowait' -mon
18 matches
Mail list logo
