1 files changed, 119 insertions, 0 deletions
diff --git a/results/classifier/118/review/1923648 b/results/classifier/118/review/1923648
new file mode 100644
index 000000000..85c0e282e
--- /dev/null
+++ b/results/classifier/118/review/1923648
@@ -0,0 +1,119 @@
+x86: 0.918
+performance: 0.910
+vnc: 0.884
+files: 0.876
+device: 0.870
+VMM: 0.864
+architecture: 0.858
+permissions: 0.852
+network: 0.849
+ppc: 0.831
+graphic: 0.808
+risc-v: 0.802
+user-level: 0.798
+socket: 0.794
+peripherals: 0.758
+kernel: 0.750
+register: 0.749
+debug: 0.744
+assembly: 0.744
+hypervisor: 0.734
+arm: 0.729
+mistranslation: 0.712
+KVM: 0.679
+PID: 0.659
+virtual: 0.655
+semantic: 0.650
+TCG: 0.640
+i386: 0.637
+boot: 0.628
+--------------------
+virtual: 0.908
+performance: 0.886
+hypervisor: 0.365
+debug: 0.330
+x86: 0.213
+TCG: 0.060
+PID: 0.048
+boot: 0.037
+files: 0.031
+socket: 0.031
+risc-v: 0.027
+device: 0.023
+semantic: 0.020
+register: 0.020
+vnc: 0.016
+network: 0.014
+VMM: 0.012
+user-level: 0.010
+kernel: 0.009
+assembly: 0.006
+permissions: 0.006
+architecture: 0.004
+peripherals: 0.003
+ppc: 0.003
+graphic: 0.001
+KVM: 0.001
+mistranslation: 0.000
+arm: 0.000
+i386: 0.000
+
+macOS App Nap feature gradually freezes QEMU process
+
+macOS version: 10.15.2
+QEMU versions: 5.2.0 (from MacPorts)
+               5.2.92 (v6.0.0-rc2-23-g9692c7b037)
+
+If the QEMU window is not visible (hidden, minimized or another application is in full screen mode), the QEMU process gradually freezes: it still runs, but the VM does not respond to external requests such as Telnet or SSH until the QEMU window is visible on the desktop.
+
+This behavior is due to the work of the macOS App Nap function:
+https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/AppNap.html#//apple_ref/doc/uid/TP40013929-CH2-SW1
+
+It doesn't matter how the process is started -- as a background job or as a foreground shell process in case QEMU has a desktop window.
+
+My VM does not have a display output, only a serial line, most likely if the VM was using OpenGL, or playing sound (or any other App Nap triggers), then the problem would never have been detected.
+
+In my case only one starting way without this problem:
+sudo qemu-system-x86_64 -nodefaults \
+-cpu host -accel hvf -smp 1 -m 384 \
+-device virtio-blk-pci,drive=flash0 \
+-drive file=/vios-adventerprisek9-m.vmdk.SPA.156-1.T.vmdk,if=none,format=vmdk,id=flash0 \
+-device e1000,netdev=local -netdev tap,id=local,ifname=tap0,script=no,downscript=no \
+-serial stdio -display none
+
+The typical way from the internet to disable App Nap doesn't work:
+defaults write NSGlobalDomain NSAppSleepDisabled -bool YES
+
+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.
+
+
+Moved here:
+https://gitlab.com/qemu-project/qemu/-/issues/334
+