Am 16.07.2020 um 14:40 hat Peter Maydell geschrieben: > On Thu, 9 Jul 2020 at 16:02, Kevin Wolf <kw...@redhat.com> wrote: > > > > We can "fix" it for probably all realistic cases by lowering the speed > > of the block job significantly. It's still not fully fixed for all > > theoretical cases, but the pattern of starting a block job that is > > throttled to a low speed so it will keep running for the next part of > > the test is very common. > > > > Kevin > > > > diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030 > > index 256b2bfbc6..31c028306b 100755 > > --- a/tests/qemu-iotests/030 > > +++ b/tests/qemu-iotests/030 > > @@ -243,7 +243,7 @@ class TestParallelOps(iotests.QMPTestCase): > > node_name = 'node%d' % i > > job_id = 'stream-%s' % node_name > > pending_jobs.append(job_id) > > - result = self.vm.qmp('block-stream', device=node_name, > > job_id=job_id, base=self.imgs[i-2], speed=512*1024) > > + result = self.vm.qmp('block-stream', device=node_name, > > job_id=job_id, base=self.imgs[i-2], speed=1024) > > self.assert_qmp(result, 'return', {}) > > > > for job in pending_jobs: > > Any chance we could get this fix into the tree? I've just > had an unrelated mergebuild test run hit this iotest 030 > failure again...
Sure. I sent a proper patch so I can include it in my next pull request (probably tomorrow). Kevin