1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c
Description of problem:
On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c
- qemu windows crashes during data copy
```D:\tmpq\qemu\8.0.0-rc4\qemu\qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios D:\vstorage\win_m01_edk2-x8_64.fd -boot c -drive "index=0,if=virtio,media=disk,format=raw,file=D:\vstorage\m01_bootnoefi.raw.img" -drive "index=1,if=virtio,media=disk,format=raw,file=F:\m01_lnx.raw.img.vtoy" -drive "index=2,if=virtio,media=disk,format=vhdx,file=F:\gkpics01.vhdx" -drive "index=3,if=virtio,media=disk,format=vhdx,file=D:\test\sgdata.vhdx" -display sdl -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -chardev qemu-vdagent,id=ch1,name=vdagent,clipboard=on -device virtio-serial -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -qmp "tcp:127.0.0.1:5955,server,nowait"```
``` ```
```Windows Hypervisor Platform accelerator is operational```
```Unexpected error in bdrv_check_qiov_request() at ../../../block/io.c:815:```
```D:\tmpq\qemu\8.0.0-rc4\qemu\qemu-system-x86_64.exe: offset is negative: -28983296```
.
- The **LINE NUMBER** : https://gitlab.com/qemu-project/qemu/-/blob/master/block/io.c#L815
- qemu setup is ```qemu-w64-setup-20230414.exe ```
Steps to reproduce:
1. have fresh vhdx ready create a vhdx in ```diskmgmt``` (also attached to [comment](https://gitlab.com/qemu-project/qemu/-/issues/727#note_1346341805))
2. have vhdx with synthetic generated data ready (see process to generate sgdata in [comment](https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694) )
3. start qemu, login, open terminal
4. Inside VM, start a terminal window, sudo root,
5. open```gdisk /dev/vdc``` create a ntfs partition
6. format as ntfs: ```mkfs.ntfs -Q -L fs_gkpics01 /dev/vdc1```
7. mount the partition ```mount -t ntfs3 /dev/vdc1 /mnt/a -o uid=1000,gid=1000,defaults,umask=0002```
8. mount the partition ```mount -t ntfs3 /dev/vdd2 /mnt/b -o uid=1000,gid=1000,defaults,umask=0002```
9. In a user login, do rsync data-copy step
```( fl="photos001" ; src="/mnt/b/sgdata" ; dst="/mnt/a" ; sdate=`date` ; echo "$sdate" ; cd "$src" ; rsync -avH "$fl" "$dst" ; echo "$sdate" ; date ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "rsync $src/$fl" )```
The bug is easily reproducible.
The moment of the crash may seems spurious, but is almost certainly bound to happen.
When it happens, it can be seen to be the same error message.
Sometimes the crash happens in ```gdisk``` step, sometimes during ```mkfs.ntfs``` sometimes partway through the ```rsync```-copy, not very long into it.
Additional information:
- This has been happening for some time. I haven't used/tested vhdx much in windows much since 7.0.0 on account of other corruption bugs/lack of dependability.
- This does not happen in Linux, as tested in #727
- The fix of #727 is unrelated to this. It doesn't have the same feel/reproduction intuitive-signature.
- Happens before (on doing the same test)
- on 8.0.0-rc1 (line number of io.c there is L811)
- on 7.2.0 (line no of io.c there is [L971](https://gitlab.com/qemu-project/qemu/-/blob/ace5a161ea1c09d8eaa8b2a717528457dc924e83/block/io.c#L971))
- It may be caused by other changes going into block code since 7.0 .
|