8 files changed, 525 insertions, 0 deletions
diff --git a/results/classifier/108/other/1873 b/results/classifier/108/other/1873
new file mode 100644
index 000000000..f60d871a3
--- /dev/null
+++ b/results/classifier/108/other/1873
@@ -0,0 +1,99 @@
+permissions: 0.885
+other: 0.857
+semantic: 0.828
+device: 0.755
+graphic: 0.742
+network: 0.741
+socket: 0.736
+debug: 0.732
+performance: 0.721
+KVM: 0.720
+PID: 0.691
+boot: 0.634
+vnc: 0.628
+files: 0.509
+
+igb driver failed to change MTU
+Description of problem:
+I am using the new IGB model to test sriov inside a virtual machine.
+
+and when the operator tries to configure MTU of 9000 on the VF I get a kernel crash and the node goes into reboot
+
+```
+virsh console virt-cluster-worker-0
+Connected to domain 'virt-cluster-worker-0'
+Escape character is ^] (Ctrl + ])
+[  486.776188] kernel BUG at include/linux/skbuff.h:2420!
+[  486.779661] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+[  486.781938] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.0-284.16.1.el9_2.x86_64 #1
+[  486.783847] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
+[  486.785681] RIP: 0010:eth_type_trans+0xd3/0x140
+[  486.787051] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48
+[  486.790542] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283
+[  486.791726] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028
+[  486.793086] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600
+[  486.794430] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980
+[  486.795779] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001
+[  486.797132] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000
+[  486.798499] FS:  0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000
+[  486.800325] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  486.801520] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0
+[  486.802856] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[  486.804171] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[  486.805459] PKRU: 55555554
+[  486.806291] Call Trace:
+[  486.807083]  <IRQ>
+[  486.807822]  igbvf_clean_rx_irq.constprop.0.isra.0+0x1b4/0x600 [igbvf]
+[  486.809027]  igbvf_poll+0x3d/0x210 [igbvf]
+[  486.809981]  __napi_poll+0x27/0x170
+[  486.810886]  net_rx_action+0x233/0x2f0
+[  486.811777]  __do_softirq+0xc7/0x2ac
+[  486.812644]  __irq_exit_rcu+0xb5/0xe0
+[  486.813515]  common_interrupt+0x80/0xa0
+[  486.814404]  </IRQ>
+[  486.815113]  <TASK>
+[  486.815800]  asm_common_interrupt+0x22/0x40
+[  486.816710] RIP: 0010:default_idle+0x10/0x20
+[  486.817631] Code: cc 0f ae f0 0f ae 38 0f ae f0 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 66 90 0f 00 2d 7e 3e 4d 00 fb f4 <c3> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 65
+[  486.820523] RSP: 0018:ffffaef2000afed0 EFLAGS: 00000246
+[  486.821705] RAX: ffffffff99f36ea0 RBX: ffff90bb4032a300 RCX: ffff90bd581f2430
+[  486.822936] RDX: 000000000013bd13 RSI: 0000000000000001 RDI: 000000000013bd14
+[  486.824165] RBP: 0000000000000000 R08: 0000007155e9e493 R09: ffff90bb437f4800
+[  486.825374] R10: 0000000000000232 R11: 0000000000000000 R12: 0000000000000000
+[  486.826581] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
+[  486.827777]  ? mwait_idle+0x80/0x80
+[  486.828593]  default_idle_call+0x33/0xe0
+[  486.829479]  cpuidle_idle_call+0x15d/0x1c0
+[  486.830381]  ? kvm_sched_clock_read+0x14/0x40
+[  486.831289]  do_idle+0x7b/0xe0
+[  486.832035]  cpu_startup_entry+0x19/0x20
+[  486.833076]  start_secondary+0x116/0x140
+[  486.834527]  secondary_startup_64_no_verify+0xe5/0xeb
+[  486.835953]  </TASK>
+[  486.836991] Modules linked in: igbvf veth ipt_REJECT nf_reject_ipv4 xt_nat xt_CT vhost_net vhost vhost_iotlb tap tun nf_conntrack_netlink tls xt_MASQUERADE nft_chain_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables rfkill geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 overlay ext4 mbcache jbd2 intel_rapl_msr intel_rapl_common isst_if_common nfit libnvdimm kvm_intel kvm irqbypass rapl iTCO_wdt iTCO_vendor_support cirrus drm_shmem_helper drm_kms_helper pcspkr i2c_i801 syscopyarea sysfillrect i2c_smbus sysimgblt virtio_balloon lpc_ich fb_sys_fops joydev ip_tables drm xfs libcrc32c dm_multipath sr_mod cdrom sg igb nvme_tcp ahci nvme_fabrics nvme libahci nvme_core virtio_net crct10dif_pclmul libata i2c_algo_bit crc32_pclmul dca virtio_console net_failover nvme_common virtio_blk t10_pi crc32c_intel failover ghash_clmulni_intel serio_raw dm_mirror dm_region_hash dm_log dm_mod fuse
+[  486.852907] ---[ end trace d1f9cdb1a6c92411 ]---
+[  486.854263] RIP: 0010:eth_type_trans+0xd3/0x140
+[  486.855234] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48
+[  486.858732] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283
+[  486.859777] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028
+[  486.861020] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600
+[  486.862238] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980
+[  486.863478] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001
+[  486.864718] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000
+[  486.865969] FS:  0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000
+[  486.867317] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  486.868458] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0
+[  486.869705] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[  486.870959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[  486.872212] PKRU: 55555554
+[  486.873040] Kernel panic - not syncing: Fatal exception in interrupt
+[  486.875441] Kernel Offset: 0x18400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
+[  486.877044] Rebooting in 10 seconds..
+```
+Steps to reproduce:
+1. create a vm using igb driver for the network interface
+2. change the MTU of the PF to 9000
+3. allocate virtual functions
+4. change the MTU on the virtual function (vm crash)
+Additional information:
+
diff --git a/results/classifier/108/other/1873032 b/results/classifier/108/other/1873032
new file mode 100644
index 000000000..af81c5140
--- /dev/null
+++ b/results/classifier/108/other/1873032
@@ -0,0 +1,47 @@
+graphic: 0.813
+performance: 0.619
+device: 0.600
+network: 0.533
+boot: 0.483
+files: 0.481
+socket: 0.455
+PID: 0.435
+semantic: 0.431
+vnc: 0.423
+debug: 0.413
+other: 0.408
+permissions: 0.388
+KVM: 0.307
+
+After upgrade qemu to 5.0.0-0.3.rc2.fc33 the virtual machine with Windows 10 after a while starts to work very slowly
+
+Description of problem:
+
+After upgrade qemu to 5.0.0-0.3.rc2.fc33 the virtual machine with Windows 10 after a while starts to work very slowly
+
+I created the virtual machine with Windows 10 with the following config:
+- 1 CPU
+- 2GB RAM
+- With network access
+
+I launch there a web browser there with flash content. 
+And usually, the system (Windows 10) does not work there for more than an hour.
+When the system starts to work very slowly it doesn't respond to "Reboot" and "Shut Down" commands. Only works "Force Reset" and "Force Off". But when I reboot the system with "Force Reset" it usually stuck at boot at the Windows splash screen. https://imgur.com/yGyacDG
+
+The last version of qemu which not contain this issue is 5.0.0-0.2.rc0.fc33
+
+
+
+When VM starts work very slowly System interrupts in Windows Task Manager eats up 99% of all CPU resources.
+
+
+Please try this patch series: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg02728.html
+
+Unofficial x86_64 build of v5.0.0 with those 2 patches for Arch is here: [1].
+
+[1] https://download.opensuse.org/repositories/home:/post-factum/Arch/x86_64/
+
+I confirm that with patches https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg02728.html Win 10 in QEMU working already more than 24 hours without issue.
+
+The patches mentioned in the previous comments have been released with QEMU v5.1, so I'm marking this bug as fixed now. If you still have problems, please open a new ticket.
+
diff --git a/results/classifier/108/other/1873335 b/results/classifier/108/other/1873335
new file mode 100644
index 000000000..b73a2c4a3
--- /dev/null
+++ b/results/classifier/108/other/1873335
@@ -0,0 +1,113 @@
+device: 0.723
+PID: 0.677
+other: 0.655
+graphic: 0.651
+performance: 0.633
+permissions: 0.597
+KVM: 0.588
+socket: 0.587
+debug: 0.576
+boot: 0.574
+vnc: 0.564
+semantic: 0.555
+network: 0.552
+files: 0.439
+
+Dos Keypad is not working for numbers - numlock is not working
+
+Hello,
+i tried to use Qemu 4.2 for Dos, but there is problem what in Dos is not possible turn on Numlock for input numbers, so games need it.. Numlock only working as arrow keys.
+  I tested bough Windows and Linux builds.
+
+I made the following experiments
+
+openSuse 15.2
+kde environment
+qemu 4.2.1 and 5.2.0
+
+VM: android-x86-7.1-r5 (www.android-x86.org)
+
+1.
+
+i add a standard 102 keys PC keyboard with "-device usb-kbd"
+
+for host numlock is "on"
+i launch the VM
+for host numlock is on. We can use the numeric keypad.
+for guest numlock is off! We can't use the numeric keypad.
+
+Now to add the keyboard instead of "-device usb-kbd" I use "-device usb-host, vendorid=<hex number>,productid= <hex number>
+
+for host numlock is "on"
+I launch the VM
+for host numlock is on. We can use the numeric keypad.
+for guest numlock is on. We can use the numeric keypad.
+
+2.
+
+I add a standard 102 keys PC keyboard with "-device usb-kbd"
+
+for the host the keyboard is in state "numlock on"
+launch the VM
+wait for launching is finished
+
+for the host the keyboard is in state "numlock on". We see that the numlock ligh is on. We can use the numeric keypad.
+but for the guest the keyboard is in state "numlock off" ! We can't use the numeric keypad.
+
+type the key "numlock". the numlock light is switched off.
+
+for the host the keyboard is in the state "numlock off". We can't use the numeric keypad to write 0...9, "."
+for the guest the keyboard is in the state "numlock on" ! We can use the numeric keypad to write 0...9, "."
+
+retype the key "numlock"
+
+this time the numeric keypad is in state "numlock on" for the host and the guest. We can use the numeric keypad for the host and for the guest !
+
+
+
+I use this qemu invocation
+
+[CODE]
+#!/bin/bash
+
+qemu-kvm \
+-enable-kvm \
+-k fr \
+-m 2048 \
+-smp 2 \
+-cpu host \
+-vga qxl \
+-device usb-ehci \
+-device usb-mouse \
+-device usb-kbd \
+-device usb-tablet \
+-device ich9-intel-hda \
+-device hda-duplex,audiodev=snd0 \
+-audiodev pa,id=snd0 \
+-device usb-host,vendorid=0x046d,productid=0x08e5 \
+-boot menu=on \
+-nic bridge \
+~/QEMU_VM/android_x86_7.1-r5.img \
+
+[/CODE]
+
+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 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/204
+
+
diff --git a/results/classifier/108/other/1873337 b/results/classifier/108/other/1873337
new file mode 100644
index 000000000..a755c5e01
--- /dev/null
+++ b/results/classifier/108/other/1873337
@@ -0,0 +1,47 @@
+graphic: 0.772
+device: 0.528
+semantic: 0.475
+other: 0.444
+files: 0.415
+permissions: 0.334
+socket: 0.315
+PID: 0.312
+performance: 0.304
+network: 0.304
+vnc: 0.279
+debug: 0.214
+boot: 0.161
+KVM: 0.093
+
+Arrow keys press is double in some programs in Dos
+
+Hello,
+im trying to use Qemu for Dos machines.
+
+ But there is problem with some programs that arrow key press is double in some problems. As advanced Filemanagers - Dos Navigator or File Wizard, same Scandisk.
+
+There is gif:
+https://www.vogons.org/download/file.php?id=77141&mode=view
+
+ Its blocking to use such problem, unless you use Numlock key for it, but im used 25+ years to arrow keys and its bug.. I guess that it would mess with some games too.
+
+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 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/205
+
+
diff --git a/results/classifier/108/other/1873338 b/results/classifier/108/other/1873338
new file mode 100644
index 000000000..2fe85b9c4
--- /dev/null
+++ b/results/classifier/108/other/1873338
@@ -0,0 +1,86 @@
+boot: 0.908
+debug: 0.904
+semantic: 0.902
+graphic: 0.899
+performance: 0.892
+other: 0.890
+device: 0.887
+permissions: 0.882
+vnc: 0.873
+PID: 0.858
+files: 0.853
+socket: 0.832
+network: 0.784
+KVM: 0.742
+
+Dos on the fly CD image replacement is not Working with DOS
+
+Im not able to exchange CD image on the fly (needed for some games). I messed with command like - in console(ATL+CRTL+2) eject ide1-cd0 and change ide-cd0 D:/Games/!Emulators/Dos-QEMU/ISOs/TestChangeISO.iso , but system so never able to find new CD data.. simply drive so empty.. but when i reboot virtual machine, new change image is now working.
+
+  Qemu 4.2.
+
+Does this work with other guests, like Windows 95/98 as far as you can tell? Is it only a problem in DOS? What exact version of DOS are you seeing the problem with?
+
+I tried Win98 virtual machine here its working fine, without reboot.
+
+ Im using MS-DOS 7.1 - integrated within and Win9x and classic MSDEX or SHSUCDX drivers for CD-ROM, but o dpmt thing that it matters.
+
+I think I need a bit more detail, I'm sorry. Can you explain to me the full environment you are seeing the problem in?
+
+Host: Windows? Linux? what version? If Linux, what kernel version?
+Guest: what's the version of the guest you are running? Windows98, or a version of DOS directly?
+Command-line: What's the QEMU command line you used? An exact command line helps.
+
+If it works OK in Windows98 but you are using a version of DOS embedded in Windows98, can you describe exactly the circumstance in which you are seeing stale CDROM data, with steps on how to reproduce?
+
+When it "doesn't work", can you explain the exact behavior you are seeing, in which application(s)?
+
+
+
+Host: I tried both Windows (10 64bit 19.09) and Linux host (Mint 19.3 64bit, kernel 5.40) system it really doesnt matters.
+
+Guest: Windows 98 - has integrated MS-DOS 7.1 you can boot into it through boot menu, which could be set by meditation of MSDOS.SYS, but you can install MS-DOS 7.1 Standalone too, without Windows, its the same.
+ https://winworldpc.com/product/ms-dos/7x
+ What DOS is after set up through Autoexec.bat and config.sys files. 
+ Using DOS 7.1 make sense, because its most modern and supporting FAT32 file system.
+
+ There is Qemu starting line i doubt that it will help, you can simulate problem with any DOS machine.
+qemu-system-i386.exe ^
+-m 64 ^
+-hda HDDs\MS-DOS-Systen-5G.vmdk ^
+-hdb HDDs\DosData20G.vmdk ^
+-vga cirrus ^ 
+-soundhw sb16,adlib,pcspk ^
+-net nic,model=rtl8139 ^
+-net tap,ifname=TAP ^
+-cdrom Isos\dos71cd.iso ^
+-k en-us
+
+ With Windows 98 - i run just commands in monitor.. open my computer and open cd drive - content of cd is changed.. its the same as in all later OSes XP- to Win10. Its working as expected.
+
+ DOS - i boot into dos with cd drive driver enabled (lest say MSCDEX).. i run monitor, change cd image.. a trying to access it lets say that is drive E.. So i write "E:" <ENTER> to command line. I get error that drive is not accessible.. (command line should be switched to E:\ and here i should be able use "dir" to get list of files) but when i reboot machine, i see new exchange cd content.. so its at least somehow working.
+  Problem is that some games and programs require change cd on the fly, so reboot is not solution.
+  
+   You can simulate right behavior with Vmware or Virtualbox machine.
+
+   Is you are not familar with MS-DOS, here are command to autoexec and config for enable use of cd-rom drive:
+https://superuser.com/questions/778716/install-a-cd-rom-driver-on-ms-dos
+
+  Problem is probably that present version of cd exchange simulation code is not good enough / compatible for MSCDEX or SHSUCDX DOS CD-ROM drivers.. to make same action as is exchange cd on physical computer.
+
+  Windows 98 and later are using other drivers for it of course..
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+Its not incomplete. i gave lots of info.
+
+You need to reset the state from Incomplete to New after you've provided the information.
+
+
+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/206
+
+
diff --git a/results/classifier/108/other/1873339 b/results/classifier/108/other/1873339
new file mode 100644
index 000000000..bb4d3fd4e
--- /dev/null
+++ b/results/classifier/108/other/1873339
@@ -0,0 +1,60 @@
+graphic: 0.631
+device: 0.561
+other: 0.507
+performance: 0.480
+semantic: 0.446
+permissions: 0.406
+PID: 0.399
+network: 0.345
+socket: 0.311
+files: 0.305
+vnc: 0.297
+debug: 0.261
+KVM: 0.259
+boot: 0.217
+
+Qemu DOS Quake - 640x480 and above resolutions - Unable to load VESA palette in dos prompt and game crashing are not working 
+
+I have problem make Quake Demo working with 640x480+, with 320x200 working fine.
+I tried 3 virtual videocards settings: -vga cirrus 640x480 is not available, probably emulated GPU has not enough VRAM or some Vesa2 utility is needed. For -vga std and -vga vmware // 640x480 is available in game menu, but when i tried to set it, im getting: Unable to load VESA palette in dos prompt and game crashing.
+With vmware svgaII other Q2DOS 640x480 and 1024x768 its working fine, so it not working only with some games.
+
+  Qemu 4.2, its same on Linux and Windows.
+
+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" 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.
+
+
+
+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/251
+
+
diff --git a/results/classifier/108/other/1873344 b/results/classifier/108/other/1873344
new file mode 100644
index 000000000..74e1382bd
--- /dev/null
+++ b/results/classifier/108/other/1873344
@@ -0,0 +1,36 @@
+KVM: 0.898
+device: 0.715
+vnc: 0.537
+performance: 0.464
+socket: 0.422
+boot: 0.417
+other: 0.407
+semantic: 0.392
+graphic: 0.373
+files: 0.323
+permissions: 0.296
+network: 0.235
+PID: 0.231
+debug: 0.197
+
+KVM Windows 98 sound card passthrough is not working for DOS programs..
+
+Hello,
+im trying to passthrough PCI soundcards into Qemu Windows 98 machine - i tried Yamaha 724/744 and Aunreal Vortex 1, for Windows 98 its working fine, but for Windows 98 dosbox mode its at the best half - working - FM (music) only or nothing with detected by games sound setups.
+  All there cards are using SB emulation devices. 
+
+  When i try to boot to pure DOS, without Windows 98, even music is not working with pass through, only sound which i was able to heard its form Yamaha Setup utility test - Native 16bit sound, aby other test, games setup etc.. are able to dettect sound cards at all. 
+  Im pretty sure that drivers are setup correctly, because im using same setup on other physical machine, when its working. My suspect is missing or broken Qemu MB DMA channels emulation.. Because its is need to make DOS sound working.
+
+  Im using pass through because, SB16 emulation in Qemu is incomplete and for Windows 98 dos box, problem is same as with physical cards. Same with AC97 emulation and its Win95 drivers, which have SB emulation device fallback..
+
+Qemu 2.11 + 4.2 Linux Mint 19.3. MB Gigabyte Z170.
+
+
+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/73
+
+
diff --git a/results/classifier/108/other/1873542 b/results/classifier/108/other/1873542
new file mode 100644
index 000000000..f3e572e1b
--- /dev/null
+++ b/results/classifier/108/other/1873542
@@ -0,0 +1,37 @@
+graphic: 0.761
+device: 0.626
+boot: 0.369
+other: 0.349
+performance: 0.337
+semantic: 0.322
+vnc: 0.319
+socket: 0.309
+KVM: 0.243
+permissions: 0.161
+PID: 0.154
+files: 0.153
+debug: 0.110
+network: 0.069
+
+Windows 98 videocard passthrough - unable to load higher resolution -Desktop, after some games crashes, without whole physical machine reset..
+
+When you are using games which are using fullscreen switching resolutions (some old games are 640x480 or 800x600 max), videocard is often stuck after crash and whole Linux machine has to be rebooted, to fix it.. VM reboot is not enough. 
+
+  That stuck is strange one, after restart of machine, text mode is working fine, but graphical mode should be set to higher resolution (Load Windows 98 desktop) there is only black screen and screen input blinking.
+
+  I simulated it with multiple videocards, graphical drivers, its quite often, full Linux reboot is always safe it. Im using right roms for my cards, because otherwise i get often even boot machine twice in one Linux boot session.
+
+  Some there is need for some better card reset.
+
+  Also some videocard reset on Linux level workaround would be nice. 
+
+  Simulated on Qemu 2.11 and 4.2 and Linux Mint 19.3, but my guess its whole KVM videocard passthrough problem.
+
+
+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/254
+
+