3 files changed, 244 insertions, 0 deletions
diff --git a/results/classifier/118/none/1855 b/results/classifier/118/none/1855
new file mode 100644
index 00000000..17592415
--- /dev/null
+++ b/results/classifier/118/none/1855
@@ -0,0 +1,89 @@
+permissions: 0.606
+register: 0.572
+virtual: 0.571
+device: 0.560
+graphic: 0.507
+assembly: 0.503
+semantic: 0.498
+user-level: 0.486
+files: 0.484
+debug: 0.483
+socket: 0.474
+architecture: 0.472
+arm: 0.468
+performance: 0.458
+PID: 0.453
+KVM: 0.449
+kernel: 0.443
+boot: 0.436
+network: 0.423
+hypervisor: 0.411
+peripherals: 0.408
+risc-v: 0.387
+vnc: 0.377
+ppc: 0.370
+x86: 0.357
+VMM: 0.354
+TCG: 0.341
+mistranslation: 0.338
+i386: 0.312
+
+io-qcow2-iothreads-commit-active test fails in a "minimal" build of QEMU
+Description of problem:
+The build fails because of the `io-qcow2-iothreads-commit-active` test failure:
+
+```
+343/412 qemu:block / io-qcow2-iothreads-commit-active                 ERROR           1.66s   exit status 1
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+--- /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/tests/iothreads-commit-active.out
++++ /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/iothreads-commit-active.out.bad
+@@ -11,13 +11,27 @@
+ 10 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+ Launching VM...
+-Creating some background I/O...
+-{"return": {}}
+-Starting active commit...
+-{"return": {}}
+-{"execute": "job-complete", "arguments": {"id": "job1"}}
+-{"return": {}}
+-{"data": {"device": "job1", "len": 131072, "offset": 131072, "speed": 0, "type": "commit"}, "event": "BLOCK_JOB_READY", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+-{"data": {"device": "job1", "len": 131072, "offset": 131072, "speed": 0, "type": "commit"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+-{"execute": "job-dismiss", "arguments": {"id": "job1"}}
+-{"return": {}}
++Traceback (most recent call last):
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 436, in launch
++    self._launch()
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 463, in _launch
++    self._pre_launch()
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/iotests.py", line 841, in _pre_launch
++    super()._pre_launch()
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/qtest.py", line 143, in _pre_launch
++    self._qtest = QEMUQtestProtocol(self._qtest_path, server=True)
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/qtest.py", line 54, in __init__
++    self._sock.bind(self._address)
++OSError: AF_UNIX path too long
++
++The above exception was the direct cause of the following exception:
++
++Traceback (most recent call last):
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/tests/iothreads-commit-active", line 65, in <module>
++    vm.launch()
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 449, in launch
++    raise VMLaunchFailure(
++qemu.machine.machine.VMLaunchFailure: OSError: AF_UNIX path too long
++       Command: /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/tests/qemu-iotests/../../qemu-system-x86_64 -display none -vga none -chardev socket,id=mon,fd=3 -mon chardev=mon,mode=control -qtest unix:path=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/tmptfjmlerc/qcow2-file-iothreads-commit-active/qemu-58979-qtest.sock -accel qtest -nodefaults -display none -accel qtest -object iothread,id=iothread0 -object throttle-group,x-bps-write=1048576,id=tg0 -blockdev file,node-name=disk0-file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-disk0.img -blockdev qcow2,node-name=disk0-fmt,file=disk0-file -drive if=none,id=drive0,file=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-disk0-snap.img,format=qcow2,cache=writeback,aio=threads,backing=disk0-fmt,node-name=disk0 -device virtio-scsi,iothread=iothread0 -device scsi-hd,drive=drive0 -blockdev file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-mirror-src.img,node-name=mirror-src-file -blockdev qcow2,file=mirror-src-file,node-name=mirror-src -blockdev file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-mirror-dst.img,node-name=mirror-dst-file -blockdev qcow2,file=mirror-dst-file,node-name=mirror-dst-fmt -blockdev throttle,throttle-group=tg0,file=mirror-dst-fmt,node-name=mirror-dst -device scsi-hd,drive=mirror-src
++       Output:
++
+
+(test program exited with status code 1)
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+```
+Steps to reproduce:
+1. Install GNU Guix on your GNU/Linux machine.
+2. `guix time-machine --url=https://gitlab.com/Apteryks/guix --branch=qemu-minimal-io-qcow2-iothreads-commit-active-test-failure -- build qemu-minimal --keep-failed`
+3. Observe the test failure.  The build artifacts are left under /tmp/guix-build-qemu-minimal-8.1.0.drv-0 to inspect.
+Additional information:
+Attached is the complete build log
+[8xr1k7v10jp2wgbimib6f0s51ilqgj3z-qemu-minimal-8.1.0.drv.gz](/uploads/59a0f88a05715c18a6bdb44845b83a18/8xr1k7v10jp2wgbimib6f0s51ilqgj3z-qemu-minimal-8.1.0.drv.gz)
diff --git a/results/classifier/118/none/1855002 b/results/classifier/118/none/1855002
new file mode 100644
index 00000000..1bc0badd
--- /dev/null
+++ b/results/classifier/118/none/1855002
@@ -0,0 +1,64 @@
+kernel: 0.612
+device: 0.578
+architecture: 0.527
+mistranslation: 0.509
+arm: 0.460
+graphic: 0.453
+x86: 0.446
+socket: 0.367
+performance: 0.365
+peripherals: 0.342
+user-level: 0.286
+VMM: 0.263
+assembly: 0.252
+vnc: 0.239
+boot: 0.239
+PID: 0.231
+permissions: 0.227
+register: 0.218
+virtual: 0.213
+network: 0.212
+debug: 0.212
+files: 0.151
+i386: 0.138
+semantic: 0.121
+risc-v: 0.100
+TCG: 0.080
+hypervisor: 0.053
+ppc: 0.032
+KVM: 0.028
+
+Cannot boot arm kernel images on s390x
+
+While running the acceptance tests on s390x, the arm tests under qemu/tests/acceptance/boot_linux_console.py will timeout, except the test using u-boot. All the arm tests run without problems on x86 and ppc.
+
+This test boots the kernel and wait for a kernel panic to make sure it can boot that kind of kernel on the host running the test. The URL for the kernels are available inside the python test code, but I'm listing them here:
+
+Fail: https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz
+Fail: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb
+Fail: https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb
+Pass: https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin
+
+I tried to manually investigate the problem with the first kernel of the list. The command I used to try to boot it was:
+
+/home/linux1/src/v4.2.0-rc3/bin/qemu-system-arm -serial stdio -machine virt -kernel /home/linux1/venv/python3/data/cache/by_location/1d5fdf8018e79b806aa982600c0866b199946efc/vmlinuz
+-append "printk.time=0 console=ttyAMA0"
+
+On an x86 machine, I can see it boots and ends with a kernel panic as expected. On s390x, it just hangs.
+
+I also tried to debug with gdb, redirecting the monitor and the serial console to other terminal sessions without success.
+
+QEMU version is the latest as of today,tag v4.2.0-rc4, commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e.
+
+s390x system is a Red Hat Enterprise Linux Server 7.7 running as a z/VM 6.4.0 guest at IBM LinuxONE Community Cloud.
+
+x86 system is a Fedora 31 running on Intel i7-8650U.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/187
+
+
diff --git a/results/classifier/118/none/1855617 b/results/classifier/118/none/1855617
new file mode 100644
index 00000000..fe73b88c
--- /dev/null
+++ b/results/classifier/118/none/1855617
@@ -0,0 +1,91 @@
+user-level: 0.583
+graphic: 0.526
+peripherals: 0.507
+PID: 0.500
+device: 0.495
+arm: 0.493
+permissions: 0.484
+network: 0.481
+virtual: 0.460
+mistranslation: 0.447
+performance: 0.442
+semantic: 0.442
+vnc: 0.442
+KVM: 0.435
+ppc: 0.433
+hypervisor: 0.429
+files: 0.418
+risc-v: 0.414
+kernel: 0.402
+architecture: 0.398
+VMM: 0.398
+x86: 0.383
+socket: 0.380
+register: 0.378
+boot: 0.366
+assembly: 0.353
+i386: 0.323
+debug: 0.318
+TCG: 0.307
+
+savevm with hax saves wrong register state
+
+I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different.
+When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot.
+
+cc'ing Colin and Yu for Hax info:
+
+* Alex (<email address hidden>) wrote:
+> Public bug reported:
+> 
+> I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different.
+> When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot.
+> 
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+> 
+> -- 
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/1855617
+> 
+> Title:
+>   savevm with hax saves wrong register state
+> 
+> Status in QEMU:
+>   New
+> 
+> Bug description:
+>   I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different.
+>   When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1855617/+subscriptions
+> 
+--
+Dr. David Alan Gilbert / <email address hidden> / Manchester, UK
+
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/188
+
+