> That's a pretty big change, and I'm not sure how it's related to > completed requests hanging in the thread pool instead of reentering the > file-posix coroutine. But I also tested it enough that I'm confident > it's really the first bad commit. > > Maybe you want to try if your problem starts at the same commit?
Stefan already found that by bisecting last week: See: https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg07629.html But, IMHO the commit is not the reason for (my) bug - It just makes it easier to trigger... I can see (my) bug sometimes with 4.1.1, although I have no easy way to reproduce it reliable. Also, Stefan sent some patches to the list to fix some of the problems. https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg00022.html Does that fix your problem? I will run further tests with your script, thanks. > Kevin > > > #!/bin/bash > > qmp() { > cat <<EOF > {'execute':'qmp_capabilities'} > EOF > > while true; do > cat <<EOF > { "execute": "drive-backup", "arguments": { > "job-id":"drive_image1","device": "drive_image1", "sync": "full", "target": > "/tmp/backup.raw" } } > EOF > sleep 1 > cat <<EOF > { "execute": "block-job-cancel", "arguments": { "device": "drive_image1"} } > EOF > sleep 2 > done > } > > ./qemu-img create -f qcow2 /tmp/test.qcow2 4G > for i in $(seq 0 1); do echo "write ${i}G 1G"; done | ./qemu-io > /tmp/test.qcow2 > > qmp | x86_64-softmmu/qemu-system-x86_64 \ > -enable-kvm \ > -machine pc \ > -m 1G \ > -object 'iothread,id=iothread-virtioscsi0' \ > -device 'virtio-scsi-pci,id=virtioscsi0,iothread=iothread-virtioscsi0' \ > -blockdev node-name=my_drive,driver=file,filename=/tmp/test.qcow2 \ > -blockdev driver=qcow2,node-name=drive_image1,file=my_drive \ > -device scsi-hd,drive=drive_image1,id=image1 \ > -cdrom ~/images/iso/RHEL-8.0-20190116.1-x86_64-dvd1.iso \ > -boot d \ > -qmp stdio -monitor vc