Hello, A) Included below is I think a sure-way to reproduce the bug. (I wasn't sure if you had done reproduction yet, and were looking only at provided kernel traces) B) Is there a specific kernel-bug ## I can cite and watch for progress/fix ? I ran into the same while doing similar rsync tests related to qemu bug https://gitlab.com/qemu-project/qemu/-/issues/727 1) create empty qcow2 file [root@sirius gana]# qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904 2) create another qcow2/vhdx containing sgdata, Ensure that data is good/not be corrupt. (I prepare my vhdx on windows) That issue filing mentioned earlier has scriptlets for "synthetic generated data" (sgdata) https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 3) download a fedora rawhide iso https://archive.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/ 4) [root@sirius gana]# qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot "d" -cdrom "/vol/15KJ_Images/transcend/Fedora-Workstation-Live-x86_64-Rawhide-20211230.n.0.iso" -hda "/mnt/a16/gkpics01.qcow2" -hdb "/vol/15KJ_Images/test/sgdata.vhdx" -device "virtio-vga-gl" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" Inside VM, open a terminal tab 1) use gdisk make type-0700 partition /dev/sda1 2) format /dev/sda1 as ntfs mkfs -t ntfs -Q -L fs_gkpics01 /dev/sda1 3) mount /dev/sda and /dev/sdb mount /dev/sda1 /mnt/a mount /dev/sdb2 /mnt/b 4) ( sdate=`date`; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rsynclog.txt ; echo $sdate ; date ) monitor dmesg -w in a second tab Basically, in the above test, I am trying to copy about 85GiB of data from /dev/sdb2 to /dev/sda1 The kernel trace happens within less than a couple of Gb of transfer, after which rsync bails out. -Gana
