add new results

19 files changed, 1263 insertions, 0 deletions

diff --git a/results/classifier/111/other/1207896 b/results/classifier/111/other/1207896
new file mode 100644
index 00000000..f4e12917
--- /dev/null
+++ b/results/classifier/111/other/1207896
@@ -0,0 +1,38 @@
+other: 0.336
+semantic: 0.170
+graphic: 0.106
+device: 0.057
+files: 0.053
+vnc: 0.047
+debug: 0.045
+permissions: 0.030
+performance: 0.030
+boot: 0.029
+network: 0.029
+socket: 0.027
+PID: 0.022
+KVM: 0.019
+other: 0.217
+debug: 0.132
+files: 0.118
+semantic: 0.106
+network: 0.081
+PID: 0.072
+device: 0.056
+performance: 0.056
+boot: 0.044
+permissions: 0.033
+socket: 0.029
+graphic: 0.028
+vnc: 0.018
+KVM: 0.010
+
+binfmt wrapper for argv[0] handling
+
+Please, add patch https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html to upstream. 2 years have passed and this patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu with this patch. It is 100% needed.
+
+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 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.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1296882 b/results/classifier/111/other/1296882
new file mode 100644
index 00000000..c041d24d
--- /dev/null
+++ b/results/classifier/111/other/1296882
@@ -0,0 +1,40 @@
+other: 0.195
+device: 0.176
+semantic: 0.143
+files: 0.115
+graphic: 0.073
+vnc: 0.048
+PID: 0.036
+network: 0.036
+debug: 0.034
+performance: 0.032
+boot: 0.030
+permissions: 0.029
+socket: 0.027
+KVM: 0.025
+other: 0.181
+debug: 0.138
+files: 0.134
+semantic: 0.131
+device: 0.129
+performance: 0.050
+boot: 0.048
+network: 0.043
+PID: 0.043
+permissions: 0.034
+socket: 0.029
+graphic: 0.017
+vnc: 0.017
+KVM: 0.007
+
+add next free device option to qemu-img
+
+I'd like to propose an option to be added to qemu-img which returns the next free NBD (the device file) very similar to losetup -f. It would make life a lot easier.
+
+Followers of this enhancement request might be interested in the following workaround: http://stackoverflow.com/questions/22535222/next-free-device-option-for-qemu-nbd/
+
+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 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.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1452742 b/results/classifier/111/other/1452742
new file mode 100644
index 00000000..becc6fdc
--- /dev/null
+++ b/results/classifier/111/other/1452742
@@ -0,0 +1,64 @@
+other: 0.194
+semantic: 0.162
+device: 0.101
+PID: 0.067
+graphic: 0.063
+vnc: 0.062
+socket: 0.062
+network: 0.058
+files: 0.047
+debug: 0.041
+permissions: 0.038
+performance: 0.038
+boot: 0.037
+KVM: 0.030
+other: 0.204
+debug: 0.155
+files: 0.096
+network: 0.090
+semantic: 0.072
+device: 0.062
+performance: 0.054
+PID: 0.053
+socket: 0.048
+boot: 0.040
+graphic: 0.040
+permissions: 0.038
+vnc: 0.031
+KVM: 0.017
+
+the option for vdagent communication needed for qxl scren resizing is not documented
+
+Hello,
+
+I tried running a guest with vdagent which is supposed to resize the guest screen to match client window size.
+
+However, a special serial port needs to be created for the vdagent to communicate with the client.
+
+This patch adds a short note to the vga qxl option.
+
+
+
+To be able to include your patch, you've got to send it to the qemu-devel mailing list, with a proper Signed-off-by line. Please see http://qemu-project.org/Contribute/SubmitAPatch#Submitting_your_Patches for details.
+
+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/424
+
+
diff --git a/results/classifier/111/other/1553760 b/results/classifier/111/other/1553760
new file mode 100644
index 00000000..4498fcae
--- /dev/null
+++ b/results/classifier/111/other/1553760
@@ -0,0 +1,37 @@
+other: 0.211
+semantic: 0.159
+device: 0.146
+files: 0.068
+network: 0.059
+vnc: 0.054
+graphic: 0.053
+permissions: 0.050
+PID: 0.046
+socket: 0.046
+boot: 0.034
+debug: 0.030
+performance: 0.026
+KVM: 0.019
+other: 0.244
+network: 0.142
+debug: 0.108
+files: 0.098
+performance: 0.065
+semantic: 0.063
+device: 0.062
+PID: 0.053
+boot: 0.047
+socket: 0.043
+vnc: 0.023
+graphic: 0.022
+permissions: 0.018
+KVM: 0.013
+
+NUMA node binding are not supported by this QEMU
+
+I read https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1417937/, but I don't understand why it was only fixed on Ubunto.
+I'm running on Debian 8, openstack kilo, and trying to launch a VM with numa pinning.
+Is it not possible to build qemu with CONFIG_NUMA enabled for Debian where libnuma is present?
+
+it did turn out that my qemu had CONFIG_NUMA disabled. ended up upgrading it which solved it.
+
diff --git a/results/classifier/111/other/1556372 b/results/classifier/111/other/1556372
new file mode 100644
index 00000000..25f4a910
--- /dev/null
+++ b/results/classifier/111/other/1556372
@@ -0,0 +1,55 @@
+other: 0.332
+semantic: 0.163
+graphic: 0.103
+device: 0.075
+vnc: 0.055
+PID: 0.052
+files: 0.039
+debug: 0.030
+permissions: 0.030
+performance: 0.028
+socket: 0.027
+boot: 0.023
+KVM: 0.022
+network: 0.022
+other: 0.172
+semantic: 0.147
+debug: 0.127
+files: 0.126
+network: 0.095
+performance: 0.078
+device: 0.066
+PID: 0.045
+permissions: 0.038
+socket: 0.027
+boot: 0.027
+graphic: 0.023
+vnc: 0.021
+KVM: 0.007
+
+Superfluous popup on Cocoa to verify quit, cannot be disabled.
+
+This patch severely reduces the quality of life for developers using QEMU in a rapid Edit-Compile-Test cycle.
+Any method of quitting QEMU via the UI triggers this dialogue, whose default option is "cancel" -- necessitating the use of the mouse to click "Confirm".
+
+This dialogue cannot be disabled by any flag, and is highly annoying. Recommend a flag to disable this confirmation, or in fact disable it by default and enable it with a flag.
+
+Patch in question:
+
+https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05031.html
+
+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.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1563931 b/results/classifier/111/other/1563931
new file mode 100644
index 00000000..4c981b6d
--- /dev/null
+++ b/results/classifier/111/other/1563931
@@ -0,0 +1,51 @@
+other: 0.181
+semantic: 0.140
+device: 0.107
+graphic: 0.079
+socket: 0.065
+vnc: 0.059
+permissions: 0.056
+files: 0.053
+PID: 0.053
+debug: 0.050
+network: 0.046
+boot: 0.044
+performance: 0.042
+KVM: 0.026
+other: 0.211
+debug: 0.152
+files: 0.114
+device: 0.111
+semantic: 0.079
+PID: 0.064
+network: 0.046
+boot: 0.045
+socket: 0.041
+performance: 0.036
+graphic: 0.036
+permissions: 0.026
+vnc: 0.024
+KVM: 0.016
+
+qemu-img should allow resizing image with snapshots
+
+Currently it's not possible to resize a disk image with qemu-img if image in question has snapshots associated. I'm not entirely sure this is technically possible but if it is, it would be really nice to support that.
+
+$ qemu-img --version
+qemu-img version 2.4.1 (qemu-2.4.1-8.fc23), Copyright (c) 2004-2008 Fabrice Bellard
+
+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.
+
+
+Implemented in 7fa140abf69675b7b83af32de.  Note that every internal snapshot has a disk size associated with it, though, so applying a snapshot from when the image had a different size means the image size will be reverted to what it was as the time of the snapshot.
+
diff --git a/results/classifier/111/other/1583775 b/results/classifier/111/other/1583775
new file mode 100644
index 00000000..20c59fba
--- /dev/null
+++ b/results/classifier/111/other/1583775
@@ -0,0 +1,68 @@
+other: 0.206
+semantic: 0.125
+KVM: 0.102
+PID: 0.088
+graphic: 0.074
+device: 0.069
+socket: 0.054
+network: 0.052
+files: 0.049
+vnc: 0.045
+boot: 0.041
+debug: 0.037
+permissions: 0.036
+performance: 0.023
+other: 0.236
+network: 0.110
+files: 0.104
+semantic: 0.089
+PID: 0.072
+debug: 0.069
+device: 0.059
+permissions: 0.055
+KVM: 0.046
+boot: 0.046
+performance: 0.034
+socket: 0.034
+graphic: 0.027
+vnc: 0.019
+
+Feature Request: qemu 2.6.0
+
+Qemu 2.6.0 just got released, and according to changelogs it has quite some enhancements...
+
+would it be possible to have someone who has a qemu ppa on launchpad to migrate this into his ppa?
+
+thanks in advance
+
+I'm testing a merge of it right now.
+
+On Thu, May 19, 2016 at 9:13 PM, Launchpad Bug Tracker
+<email address hidden> wrote:
+> You have been subscribed to a public bug:
+>
+> Qemu 2.6.0 just got released, and according to changelogs it has quite
+> some enhancements...
+>
+> would it be possible to have someone who has a qemu ppa on launchpad to
+> migrate this into his ppa?
+>
+> thanks in advance
+>
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+>
+>
+> ** Tags: kvm qemu spice vfio virtio
+> --
+> Feature Request: qemu 2.6.0
+> https://bugs.launchpad.net/bugs/1583775
+> You received this bug notification because you are subscribed to QEMU.
+
+
+thank you very much serge=)
+
+Hi; I'm going to close this because it isn't a bug in upstream QEMU (which only does source releases).
+
+
diff --git a/results/classifier/111/other/1656711 b/results/classifier/111/other/1656711
new file mode 100644
index 00000000..63f84d83
--- /dev/null
+++ b/results/classifier/111/other/1656711
@@ -0,0 +1,52 @@
+other: 0.234
+semantic: 0.140
+graphic: 0.114
+device: 0.111
+performance: 0.061
+PID: 0.052
+boot: 0.040
+vnc: 0.039
+socket: 0.038
+debug: 0.037
+KVM: 0.034
+permissions: 0.034
+files: 0.034
+network: 0.030
+other: 0.202
+debug: 0.149
+files: 0.101
+semantic: 0.094
+graphic: 0.091
+device: 0.076
+performance: 0.061
+network: 0.056
+boot: 0.042
+PID: 0.037
+socket: 0.036
+permissions: 0.028
+vnc: 0.016
+KVM: 0.011
+
+GTK3 interface doesn't zoom-to-fit by default
+
+The SDL interface automatically scales the video output to
+match the window size.  The GTK3 interface has an off-by-default option
+"Zoom To Fit" for that.  As far as I can tell, no command-line option
+exists to turn that option on.  That makes it harder to quickly zoom a
+freshly launched VM; instead of just hitting a maximize-window hotkey, I
+also have to navigate through the menu to select "Zoom To Fit".
+
+Given that VMs typically start out running in a much lower-resolution
+video mode than the host (and VMs not running a full graphical
+environment often stay that way), this seriously impacts the usability
+of qemu-system.
+
+(Observed in QEMU 2.8)
+
+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 all 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". Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1739378 b/results/classifier/111/other/1739378
new file mode 100644
index 00000000..bd0a39c3
--- /dev/null
+++ b/results/classifier/111/other/1739378
@@ -0,0 +1,111 @@
+other: 0.110
+debug: 0.101
+device: 0.092
+semantic: 0.092
+PID: 0.082
+boot: 0.080
+graphic: 0.072
+performance: 0.069
+files: 0.059
+permissions: 0.054
+vnc: 0.051
+socket: 0.049
+KVM: 0.045
+network: 0.044
+other: 0.147
+files: 0.144
+debug: 0.116
+device: 0.093
+PID: 0.081
+boot: 0.077
+semantic: 0.062
+performance: 0.047
+socket: 0.047
+vnc: 0.043
+graphic: 0.038
+permissions: 0.037
+network: 0.036
+KVM: 0.031
+
+migration state save/load of sdcard device is broken
+
+I'm having different issues trying to have QEMU snapshots working using qemu-system-arm with vexpress-a15 board.
+
+In this opportunity, I'm trying the git master head version:
+# git rev-parse HEAD
+af352675efb7e92a1f5f6461a042a12015ab3d12
+
+$ /usr/local/bin/qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 2048 -append 'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb device-tree/vexpress-v2p-ca15-tc1.dtb  
+audio: Could not init `oss' audio driver
+
+Later on, when the machine finishes booting I savevm ss and quit. However, when I try to restore it, I have that Missing section footer error:
+
+$ /usr/local/bin/qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 2048 -append 'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb device-tree/vexpress-v2p-ca15-tc1.dtb  -loadvm ss
+audio: Could not init `oss' audio driver
+qemu-system-arm: Missing section footer for sd-card
+qemu-system-arm: Error -22 while loading VM state
+
+
+OS: Ubuntu 16.04.3 LTS (xenial)
+
+$ gcc --version
+gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
+
+I've also tried a different ./configure line, explicitly enabling some of the features, i.e. smartcard, with the same results:
+
+./configure '--disable-user' '--enable-system' '--enable-linux-user' '--enable-modules' '--enable-linux-aio' '--audio-drv-list=pa' '--enable-attr' '--enable-brlapi' '--enable-virtfs' '--enable-cap-ng' '--enable-curl' '--enable-fdt' '--enable-gnutls' '--disable-gtk' '--disable-vte' '--enable-libiscsi' '--enable-curses' '--enable-smartcard' '--enable-rbd' '--enable-vnc-sasl' '--enable-seccomp' '--enable-spice' '--enable-libusb' '--enable-usb-redir' '--enable-xfsctl' '--enable-vnc' '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-kvm' '--enable-vhost-net'
+
+How have I built it?
+# git clone git://git.qemu.org/qemu.git
+# cd qemu
+# git submodule update --init --checkout
+# make clean && ./configure --target-list=arm-softmmu && make -j8
+# sudo make install
+
+As a reference, and just in case these may be in some way related, I've just submitted another ticket for a different issue with snapshots using Ubuntu Qemu version (https://bugs.launchpad.net/qemu/+bug/1739371)
+
+Cheers,
+Gus
+
+
+
+From a quick look my guess would be the wpgrps_size in sd_vmstate is different on the source and destination for some reason - it's the only thing that seems to be variable.
+(It could also be whether the subsection is transmitted or not, but that's supposed to sort itself out automatically).
+
+So, it should be only related to SD? Which virtual device/storage backend do you recommend for snapshots?
+
+
+On 20 December 2017 at 18:44, Dr. David Alan Gilbert
+<email address hidden> wrote:
+> From a quick look my guess would be the wpgrps_size in sd_vmstate is
+> different on the source and destination for some reason
+
+Good guess: I added a pre_save hook to sdcard.c's vmstate,
+which reports wpgrps_size as 201, but in the pre_load hook
+it is reported as 0.
+
+This seems to be because nothing ever calls the sd_reset()
+function. I suspect this is down to the "legacy" handling
+of sd card setup in sd_init(), or possibly the generic handling
+of reset for devices that connect to SD buses.
+
+(sd_reset() eventually gets called when the guest OS
+probes the SD controller and issues a card reset command,
+which is why it's correctly set by the time we do a vmsave.)
+
+thanks
+-- PMM
+
+
+I think the sd card migration issue should be fixed by http://patchwork.ozlabs.org/patch/857554/
+
+NB that you'll also need to use "-machine secure=off" on the command line, as there's a second bug where we don't successfully migrate with trustzone emulation enabled (which is the default now).
+
+
+Finally I could test it. Yeah man, awesome, that did the trick. It is working like a charm.
+You can close the ticket.
+Thanks
+
+The patch has been merged here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0cb57cc701839e7358918
+
diff --git a/results/classifier/111/other/1748756 b/results/classifier/111/other/1748756
new file mode 100644
index 00000000..6af80f29
--- /dev/null
+++ b/results/classifier/111/other/1748756
@@ -0,0 +1,41 @@
+other: 0.230
+semantic: 0.223
+graphic: 0.104
+device: 0.088
+files: 0.051
+vnc: 0.050
+PID: 0.046
+permissions: 0.044
+debug: 0.039
+boot: 0.030
+socket: 0.029
+performance: 0.027
+network: 0.025
+KVM: 0.014
+other: 0.228
+device: 0.132
+semantic: 0.119
+network: 0.098
+files: 0.092
+PID: 0.085
+boot: 0.047
+permissions: 0.041
+socket: 0.037
+debug: 0.037
+graphic: 0.028
+vnc: 0.023
+performance: 0.023
+KVM: 0.009
+
+[Feature request] Support of TI AM1808 for Lego EV3
+
+It would be great if emulating TI AM1808 would be possible. It will be a big step towards Lego Mindstorms EV3 emulation.
+
+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 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.
+
+The QEMU project doesn't implement new target architectures or board models on demand based on wishlist requests; they're a lot of work to do. Instead we simply code-review and incorporate board models and architectures as and when people decide to write them and submit the patches. So there's really no point in having a 'wishlist' bug in the bug tracker saying "support for board X would be nice", because it will never happen, unless by the coincidence that somebody happened to implement and submit it to us anyway.
+
+So I'm going to close this bug as "Won't Fix"; if anybody happens to want to work with upstream on implementing this board model they are welcome to do so -- the mechanism for that is to email qemu-devel (with plans, requests for advice or patches).
+
+
diff --git a/results/classifier/111/other/1779649 b/results/classifier/111/other/1779649
new file mode 100644
index 00000000..6d5f7d66
--- /dev/null
+++ b/results/classifier/111/other/1779649
@@ -0,0 +1,42 @@
+other: 0.211
+graphic: 0.157
+semantic: 0.149
+device: 0.132
+PID: 0.057
+socket: 0.051
+vnc: 0.045
+performance: 0.036
+files: 0.033
+network: 0.032
+debug: 0.030
+boot: 0.028
+permissions: 0.025
+KVM: 0.014
+other: 0.160
+debug: 0.144
+semantic: 0.136
+files: 0.126
+PID: 0.087
+performance: 0.085
+device: 0.061
+network: 0.049
+boot: 0.037
+permissions: 0.029
+graphic: 0.028
+vnc: 0.024
+socket: 0.023
+KVM: 0.010
+
+Suspending a domain works with a 3.16 gues kernel but not with a 4.16 one
+
+Suspending a domain with `systemctl suspend` works with a guest 3.16 kernel (jessie), the domain goes into `pmsuspend` in libvirt but doesn't work anymore with a 4.16 one (sid) where:
+ - With a QXL card: the spice display just goes black and the domain stays `running` in libvirt but is "dead"
+ - With a VGA card: the screen goes black and comes back immediately, the domain stays fine
+
+Qemu: Master, 281bd281222776229d5dbf84d1a5c6d8d9d2a34b
+
+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 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.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1780815 b/results/classifier/111/other/1780815
new file mode 100644
index 00000000..966c712f
--- /dev/null
+++ b/results/classifier/111/other/1780815
@@ -0,0 +1,42 @@
+other: 0.168
+semantic: 0.159
+device: 0.139
+PID: 0.072
+graphic: 0.063
+vnc: 0.061
+performance: 0.057
+files: 0.057
+socket: 0.048
+network: 0.042
+debug: 0.040
+boot: 0.035
+permissions: 0.031
+KVM: 0.027
+other: 0.175
+debug: 0.157
+semantic: 0.135
+files: 0.115
+performance: 0.064
+network: 0.064
+graphic: 0.064
+device: 0.062
+PID: 0.054
+boot: 0.033
+socket: 0.033
+permissions: 0.024
+vnc: 0.014
+KVM: 0.008
+
+SDL Doesn't Rescale Image on Resolution Change
+
+Whilst in fullscreen mode, if the guest changes resolution for whatever reason, the screen doesn't update the scaling so you end up looking at only part of the screen, e.g. if the guest changes from 640x480 to 1024x768, the image will still be fullscreen, but what you're actually looking at will be the top-left most 640x480 segment of the screen stretched out.
+
+Manually going out of fullscreen mode and then back in fixes the scaling, but you have to do that every time the guest changes resolution.
+
+QEmu 2.12.0 using qemu-system-x86_64 with Arch Linux host.
+
+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 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.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1842916 b/results/classifier/111/other/1842916
new file mode 100644
index 00000000..1e244c39
--- /dev/null
+++ b/results/classifier/111/other/1842916
@@ -0,0 +1,82 @@
+other: 0.234
+PID: 0.120
+device: 0.091
+semantic: 0.082
+files: 0.082
+socket: 0.054
+graphic: 0.054
+debug: 0.049
+network: 0.047
+vnc: 0.042
+permissions: 0.039
+boot: 0.038
+performance: 0.037
+KVM: 0.033
+other: 0.171
+files: 0.134
+semantic: 0.124
+PID: 0.113
+boot: 0.068
+socket: 0.068
+device: 0.059
+network: 0.055
+debug: 0.047
+graphic: 0.037
+permissions: 0.034
+vnc: 0.034
+performance: 0.031
+KVM: 0.026
+
+[18.04 FEAT] Enhanced Hardware Support - Finalize Naming
+
+This feature request will provide the final naming of the next machine
+
+A similar ticket for Eoan/19.10 was created, too:
+https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842774
+
+Disco also needs to be addressed, but let's track that here, too.
+
+------- Comment From <email address hidden> 2019-09-18 08:43 EDT-------
+See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0e2251132995b962281aa80ab54a9288f9e0b6b
+
+commit a0e2251132995b962281aa80ab54a9288f9e0b6b
+Author: Martin Schwidefsky <email address hidden>
+Date:   Wed Feb 6 08:22:11 2019 +0100
+
+s390: add support for IBM z15 machines
+
+Add detection for machine types 0x8562 and 8x8561 and set the ELF platform
+name to z15. Add the miscellaneous-instruction-extension 3 facility to
+the list of facilities for z15.
+
+And allow to generate code that only runs on a z15 machine.
+
+Reviewed-by: Christian Borntraeger <email address hidden>
+Signed-off-by: Martin Schwidefsky <email address hidden>
+Signed-off-by: Heiko Carstens <email address hidden>
+
+for the kernel upstream commit. Applies cleanly to git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic
+
+Marking this as duplicate of LP 1842774, since both LPs deal with the same patch, just for different Ubuntu releases.
+But the affected Ubuntu releases are now all listed in LP 1842774, which makes the requested kernel SRU simpler.
+
+------- Comment From <email address hidden> 2019-10-04 03:42 EDT-------
+For reference the QEMU part, which is already done in eoan via
+> qemu (1:4.0+dfsg-0ubuntu9) eoan; urgency=medium
+>
+> * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch:
+> update the z15 model name (LP: #1842774)
+>
+> -- Christian Ehrhardt <email address hidden>  Tue, 24 Sep 2019
+
+is upstream commit 7505deca0bfa859136ec6419dbafc504f22fcac2
+s390x/cpumodel: Add the z15 name to the description of gen15a
+
+------- Comment From <email address hidden> 2019-11-04 11:27 EDT-------
+*** This bug has been marked as a duplicate of bug 181268 ***
+
+------- Comment From <email address hidden> 2019-11-04 11:28 EDT-------
+IBM Bugzilla status -> closed,
+
+Will be tracked with LP: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842774
+
diff --git a/results/classifier/111/other/1851972 b/results/classifier/111/other/1851972
new file mode 100644
index 00000000..8dd52081
--- /dev/null
+++ b/results/classifier/111/other/1851972
@@ -0,0 +1,151 @@
+other: 0.103
+permissions: 0.092
+KVM: 0.092
+vnc: 0.077
+boot: 0.072
+performance: 0.072
+network: 0.072
+device: 0.070
+socket: 0.066
+files: 0.064
+debug: 0.059
+PID: 0.058
+semantic: 0.051
+graphic: 0.051
+other: 0.258
+debug: 0.125
+KVM: 0.117
+device: 0.078
+semantic: 0.064
+PID: 0.063
+files: 0.061
+boot: 0.047
+socket: 0.041
+network: 0.037
+performance: 0.031
+graphic: 0.030
+permissions: 0.025
+vnc: 0.022
+
+pc-q35-4.1 and AMD Navi 5700/XT incompatible
+
+Hello,
+
+I am not sure if this qualifies as a "bug"; it is be more of an unknown issue with default settings. However, since the default value of q35 default_kernel_irqchip_split was changed seemingly due to similar user feedback, I thought this was important to share..
+
+AMD Navi 5700/XT vfio-pci passthrough seems incompatible with one/multiple settings in pc-q35-3.1 and higher. The workaround for me is that pc-q35-3.0 still works fine passing through the GPU and official drivers can load/install fine.
+
+The default/generic GPU drivers in a Fedora 30 or Windows 1903 guest do work; the monitor displays the desktop in a 800x600 resolution and things are rendered fine.. so the basic functionality of the card seems fine with pc-q35-4.1.
+
+But attempting to use the official open source AMD driver with the card resulted in a hung kernel for the Fedora 30 guest.. and a BSOD on the Windows 1903 guest immediately during driver install.
+
+I do not see any errors in Qemu command output.. did not investigate other logs or KVM etc, because I am not sure what to look for or how to go about it. Also not sure which combination of the latest q35 default settings are valid combinations to try either, because it seems that multiple things have changed related to pcie-root-port defaults and other machine options. I am happy to run tests and provide feedback if that helps identify the issue.
+
+I am using "Linux arch 5.4.0-rc6-mainline" kernel on ArchLinux host with AMD Navi reset pci quirk patch applied.
+
+My working Qemu command line is this:
+
+QEMU_AUDIO_DRV=pa \
+QEMU_PA_SERVER=/run/user/1000/pulse/native \
+/usr/bin/qemu-system-x86_64 \
+-name windows \
+-m 16g \
+-accel kvm \
+-machine pc-q35-3.0,accel=kvm,pflash0=ovmf0,pflash1=ovmf1 \
+-blockdev node-name=ovmf0,driver=file,filename=/virt/qemu/roms/OVMF_CODE.fd,read-only=on \
+-blockdev node-name=ovmf1,driver=file,filename=/virt/qemu/machines/windows/OVMF_VARS.fd \
+-boot menu=on \
+-global kvm-pit.lost_tick_policy=discard \
+-no-hpet \
+-rtc base=utc,clock=host,driftfix=slew \
+-cpu host,kvm=off,hv_vendor_id=RedHatRedHat,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer \
+-smp sockets=1,cores=4,threads=1 \
+-nodefaults \
+-netdev bridge,br=br0,id=net0 \
+-device virtio-net-pci,netdev=net0,addr=19.0,mac=52:54:00:12:34:77 \
+-device virtio-scsi-pci \
+-blockdev raw,node-name=disk0,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/os.raw \
+-device scsi-hd,drive=disk0,rotation_rate=1 \
+-blockdev raw,node-name=disk1,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/data.raw \
+-device scsi-hd,drive=disk1,rotation_rate=1 \
+-drive index=0,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/Win10_1903_V2_English_x64.iso \
+-drive index=1,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/virtio-win-0.1.173.iso \
+-device ich9-intel-hda,addr=1b.0 \
+-device hda-output \
+-monitor stdio \
+-display none \
+-vga none \
+-device pcie-root-port,id=pcierp0,chassis=1,slot=1,addr=1c.0,disable-acs=on,multifunction=on \
+-device pcie-root-port,id=pcierp1,chassis=2,slot=2,addr=1c.1,disable-acs=on \
+-device x3130-upstream,bus=pcierp0,id=pcieu0 \
+-device xio3130-downstream,bus=pcieu0,id=pcied0,chassis=11,slot=11 \
+-device vfio-pci,host=03:00.0,bus=pcied0,addr=00.0,multifunction=on \
+-device vfio-pci,host=03:00.1,bus=pcied0,addr=00.1 \
+-device qemu-xhci,addr=1d.0 \
+-device usb-host,vendorid=0x258a,productid=0x0001 \
+-device usb-host,vendorid=0x1bcf,productid=0x0005 ;
+
+Thank you!
+
+Paolo Bonzini commented on IRC: AMD avic requires kernel_irqchip=split.
+
+Can you try using it? (released QEMU uses -machine ...,kernel_irqchip=split, git QEMU expects -accel kernel_irqchip=split).
+
+Hi Philippe, thanks for replying.
+
+The 'kernel_irqchip' parameter is a bit confusing to me. It looks like the documentation was updated from it defaulted to 'off' as a -machine parameter, to now it will default to 'on' as an -accel parameter.
+
+This bug described how the value for 'default_kernel_irqchip_split' parameter had been changed to 'true' in Q35 version 4.0, but then set back to 'false' after discovering that it caused issues for Nvidia gpu passthrough and other things: https://bugs.launchpad.net/qemu/+bug/1826422
+
+However, my problems with the AMD gpu passthrough are present when switching between Q35 3.0 (which does work) and 3.1 (which does not work), both of which would still have 'default_kernel_irqchip_split' set to false.. so it does not seem to me to be related to 'kernel_irqchip'.
+
+Q35 version 3.1 did introduce many other changes:
+
+static void pc_q35_3_1_machine_options(MachineClass *m)
+{
+..
+    pcmc->do_not_add_smb_acpi = true;
+    m->smbus_no_migration_support = true;
+    m->alias = NULL;
+    pcmc->pvh_enabled = false;
+..
+
+GlobalProperty hw_compat_3_1[] = {
+    { "pcie-root-port", "x-speed", "2_5" },
+    { "pcie-root-port", "x-width", "1" },
+..
+
+I thought maybe those could cause the AMD Navi gpu problems, but I am not that knowledgeable about these settings.
+
+Also I do not have the AMD Navi gpu conveniently available anymore to test.
+
+Commit 11bc4a13 (Nov 13, 2019, merged after v4.2.0-rc5) moved the kernel-irqchip parameter to -accel, but I think the default was inadvertently changed to off.  The documentation was changed to say the default is on, but the code change seems to have done the opposite.
+
+I found this when I tested my Windows Server 2016 VMs with the last qemu from git.  Windows boots and runs very slowly unless I add either <ioapic driver='kvm'/> (kernel_irqchip=on) or <timer name="hypervclock" present="yes"/> to the libvirt config.  Using the qemu installed with Ubuntu 19.10 (version 4.0.0), I can reproduce the slowness by explicitly adding kernel_irqchip=off.
+
+Details:
+- Host CPU: Ryzen 3950X (16 core, 32 thread)
+- Host RAM: 64 GiB
+- Host OS: Ubuntu 19.10 64-bit, kernel version 5.5.0-rc4 (commit 738d2902773e + ACS override patch)
+- Guest CPU: host-passthrough, 16 vcpus (8 cores, 2 threads, topoext).
+- Guest RAM: 12 GiB
+- Guest machine type: pc-i440fx-4.0 (BIOS boot)
+- Guest OS: Windows Server 2016, build 1607
+
+Commit d1972be13f ("accel/kvm: Make "kernel_irqchip" default on") fixes the default mixup I described above.  This isn't related to Marshall's issue as it involves qemu 3.0 vs 3.1, but at least it cleans up some confusion.
+
+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.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1860914 b/results/classifier/111/other/1860914
new file mode 100644
index 00000000..32f617a0
--- /dev/null
+++ b/results/classifier/111/other/1860914
@@ -0,0 +1,83 @@
+other: 0.159
+semantic: 0.144
+device: 0.098
+boot: 0.090
+PID: 0.070
+vnc: 0.054
+files: 0.054
+permissions: 0.054
+network: 0.050
+graphic: 0.050
+debug: 0.048
+performance: 0.048
+KVM: 0.043
+socket: 0.039
+other: 0.143
+semantic: 0.139
+debug: 0.120
+files: 0.109
+boot: 0.098
+network: 0.070
+PID: 0.069
+device: 0.060
+socket: 0.045
+vnc: 0.040
+performance: 0.038
+permissions: 0.034
+graphic: 0.021
+KVM: 0.013
+
+QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification
+
+When QEMU is launched with the -kernel option to boot a Multiboot image, the command line passed in the -append option is additionally prefixed the pathname of the kernel image and a space. Likewise, module command lines passed in the -initrd option are passed with the module pathname and a space prepended. At the very least the former is contary to what is prescribed in the Multiboot specification, version 0.6.96[0], which says in §3.3:
+
+> General-purpose boot loaders should allow user a complete control on command line independently of other factors like image name.
+
+With respect to module command lines, the spec is less clear, but GNU GRUB2 (the de facto reference implementation) does not prepend pathnames to command lines of either. I haven't tested GRUB legacy, but I assume it exhibits the same behaviour. It would be strange if passing pathnames was in fact intended; bootloader pathnames are useless to the loaded kernel, which may potentially have a completely different view of the file system from the bootloader.
+
+Also, given that a kernel pathname may contain spaces, skipping it in the command line cannot be done reliably, while loading a Multiboot module from a pathname that contains spaces is outright impossible.
+
+Found in 4.2.0, but latest git master apparently behaves the same.
+
+[0]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
+
+
+
+The QEMU project is currently moving 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 the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+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/425
+
+
diff --git a/results/classifier/111/other/1881729 b/results/classifier/111/other/1881729
new file mode 100644
index 00000000..98f91334
--- /dev/null
+++ b/results/classifier/111/other/1881729
@@ -0,0 +1,64 @@
+other: 0.276
+semantic: 0.146
+graphic: 0.075
+PID: 0.072
+device: 0.064
+files: 0.055
+permissions: 0.051
+debug: 0.045
+network: 0.043
+performance: 0.043
+vnc: 0.038
+socket: 0.035
+KVM: 0.030
+boot: 0.027
+other: 0.190
+debug: 0.185
+files: 0.118
+semantic: 0.105
+performance: 0.077
+network: 0.066
+PID: 0.065
+device: 0.054
+boot: 0.034
+graphic: 0.032
+permissions: 0.027
+vnc: 0.021
+socket: 0.019
+KVM: 0.007
+
+target_read_memory in disas.c ignores possible errors
+
+`target_read_memory` in `disas.c` ignores (possible) errors. This leads to disassembler possibly disassembling garbage.
+
+The QEMU project is currently moving 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 the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" within the next 60 days (otherwise it will get
+closed as "Expired"). We will then eventually migrate the ticket auto-
+matically to the new system (but you won't be the reporter of the bug
+in the new system and thus won't get notified on changes anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1893634 b/results/classifier/111/other/1893634
new file mode 100644
index 00000000..d585c48b
--- /dev/null
+++ b/results/classifier/111/other/1893634
@@ -0,0 +1,72 @@
+other: 0.190
+device: 0.137
+semantic: 0.105
+graphic: 0.070
+files: 0.065
+network: 0.065
+PID: 0.062
+debug: 0.055
+performance: 0.055
+permissions: 0.050
+socket: 0.043
+KVM: 0.034
+vnc: 0.034
+boot: 0.033
+other: 0.162
+files: 0.159
+debug: 0.151
+semantic: 0.086
+PID: 0.085
+device: 0.079
+boot: 0.060
+network: 0.044
+performance: 0.039
+permissions: 0.032
+vnc: 0.031
+socket: 0.029
+graphic: 0.027
+KVM: 0.016
+
+blk_get_max_transfer() works only with sg
+
+blk_get_max_transfer() is supposed to be able to get the max_sectors queue limit of the scsi device on the host side and is used in both scsi-generic.c (for scsi-generic and scsi-block) and scsi-disk.c (for scsi-hd) to set/change the max_xfer_len (and opt_xfer_len in the case of scsi-generic).
+
+However, it only works with the sg driver in doing so. It cannot get the queue limit with the sd driver and simply returns MAX_INT.
+
+qemu version 5.1.0
+kernel version 5.8.5
+
+Btw, is there a particular reason that it doesn't MIN_NON_ZERO against the original max_xfer_len: https://github.com/qemu/qemu/blob/v5.1.0/hw/scsi/scsi-generic.c#L172?
+
+The QEMU project is currently moving 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 the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/other/1907909 b/results/classifier/111/other/1907909
new file mode 100644
index 00000000..73dcc082
--- /dev/null
+++ b/results/classifier/111/other/1907909
@@ -0,0 +1,93 @@
+other: 0.108
+device: 0.081
+PID: 0.076
+permissions: 0.075
+semantic: 0.073
+KVM: 0.072
+performance: 0.072
+files: 0.071
+graphic: 0.069
+debug: 0.064
+vnc: 0.062
+boot: 0.062
+network: 0.058
+socket: 0.056
+other: 0.162
+PID: 0.152
+files: 0.101
+performance: 0.098
+semantic: 0.082
+debug: 0.078
+device: 0.062
+boot: 0.051
+network: 0.044
+KVM: 0.039
+graphic: 0.038
+permissions: 0.035
+socket: 0.030
+vnc: 0.028
+
+assertion failure in am53c974
+
+Hello,
+
+Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator.
+
+A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service.
+
+This was found in version 5.2.0 (master)
+
+
+qemu-system-i386: ../hw/scsi/esp.c:402: void esp_do_dma(ESPState *): Assertion `s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen' failed.
+
+#0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
+51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
+[Current thread is 1 (Thread 0x7fdd25dc4700 (LWP 28983))]
+gdb-peda$ bt
+#0  0x00007fdd3f8b5f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
+#1  0x00007fdd3f8b78b1 in __GI_abort () at abort.c:79
+#2  0x00007fdd3f8a742a in __assert_fail_base (fmt=0x7fdd3fa2ea38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=file@entry=0x55b3e11a4f73 "../hw/scsi/esp.c", line=line@entry=0x192, function=function@entry=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:92
+#3  0x00007fdd3f8a74a2 in __GI___assert_fail (assertion=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=0x55b3e11a4f73 "../hw/scsi/esp.c", line=0x192, function=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:101
+#4  0x000055b3e0941441 in esp_do_dma (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:401
+#5  0x000055b3e0944261 in handle_ti (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:549
+#6  0x000055b3e093fdf9 in esp_dma_enable (s=0x55b3e49d1c88, irq=<optimized out>, level=<optimized out>)
+    at ../hw/scsi/esp.c:79
+#7  0x000055b3e0897930 in esp_pci_dma_write (pci=<optimized out>, saddr=<optimized out>, val=<optimized
+out>) at ../hw/scsi/esp-pci.c:83
+#8  0x000055b3e0897930 in esp_pci_io_write (opaque=<optimized out>, addr=<optimized out>, val=0xcf, size=0x4) at ../hw/scsi/esp-pci.c:209
+#9  0x000055b3e0e8f798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...)
+    at ../softmmu/memory.c:491
+#10 0x000055b3e0e8f58e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552
+#11 0x000055b3e0e8f58e in memory_region_dispatch_write (mr=0x55b3e49d1b70, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501
+#12 0x000055b3e0e21541 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=0xffffffcf, attrs=..., result=0x0) at ../memory_ldst.c.inc:382
+#13 0x00007fdcd84a4a7f in code_gen_buffer ()
+#14 0x000055b3e0e57da0 in cpu_tb_exec (cpu=0x55b3e3c33650, itb=<optimized out>)
+    at ../accel/tcg/cpu-exec.c:178
+#15 0x000055b3e0e589eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized
+out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658
+#16 0x000055b3e0e589eb in cpu_exec (cpu=0x55b3e3c33650) at ../accel/tcg/cpu-exec.c:771
+#17 0x000055b3e0e87b9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243
+#18 0x000055b3e0e87b9f in tcg_cpu_thread_fn (arg=0x55b3e3c33650) at ../accel/tcg/tcg-cpus.c:427
+#19 0x000055b3e115f775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521
+#20 0x00007fdd3fc6f6db in start_thread (arg=0x7fdd25dc4700) at pthread_create.c:463
+#21 0x00007fdd3f998a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+
+To reproduce the assertion failure, please run the QEMU with the following command line.
+
+
+$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img
+
+Please let me know if I can provide any further info.
+
+Thank you.
+
+- Cheolwoo, Myung (Seoul National University)
+
+
+
+It looks like this reproducer  triggers the same bug as #1919036, as of 3f8d1885e
+
+Can you still reproduce the issue with QEMU v6.0? For me, the attached reproducer does not cause a crash anymore...
+
+As Alexander already wrote, this triggered the same bug as #1919036 which got fixed by commit 0ebb5fd80589835153a0c2baa1b8cc7a04e67a93. Since this is not reproducible anymore, I'm closing this bug now. If you still can reproduce it somehow, please open a new ticket in the new gitlab issue tracker.
+
diff --git a/results/classifier/111/other/1917184 b/results/classifier/111/other/1917184
new file mode 100644
index 00000000..0bf0e203
--- /dev/null
+++ b/results/classifier/111/other/1917184
@@ -0,0 +1,77 @@
+other: 0.158
+semantic: 0.138
+PID: 0.087
+performance: 0.076
+device: 0.071
+network: 0.071
+graphic: 0.057
+debug: 0.057
+files: 0.055
+socket: 0.053
+permissions: 0.052
+KVM: 0.050
+vnc: 0.041
+boot: 0.033
+other: 0.163
+files: 0.102
+debug: 0.097
+semantic: 0.090
+PID: 0.079
+network: 0.068
+performance: 0.065
+device: 0.063
+boot: 0.061
+vnc: 0.051
+graphic: 0.050
+permissions: 0.046
+socket: 0.042
+KVM: 0.022
+
+qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip
+
+When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault.
+
+qemu version 5.2.0, x86-64 host.
+
+
+
+The QEMU project is currently moving 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 the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+Bug still present in latest master
+
+
+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/314
+
+