1 files changed, 118 insertions, 0 deletions
diff --git a/results/classifier/118/all/1253777 b/results/classifier/118/all/1253777
new file mode 100644
index 000000000..d8766813a
--- /dev/null
+++ b/results/classifier/118/all/1253777
@@ -0,0 +1,118 @@
+permissions: 0.948
+peripherals: 0.939
+semantic: 0.936
+register: 0.929
+user-level: 0.928
+KVM: 0.922
+debug: 0.921
+hypervisor: 0.917
+mistranslation: 0.913
+assembly: 0.909
+arm: 0.908
+architecture: 0.907
+device: 0.905
+TCG: 0.904
+PID: 0.903
+vnc: 0.900
+graphic: 0.897
+performance: 0.896
+virtual: 0.892
+files: 0.891
+risc-v: 0.890
+network: 0.887
+VMM: 0.882
+socket: 0.874
+ppc: 0.862
+boot: 0.839
+kernel: 0.801
+x86: 0.768
+i386: 0.728
+
+OpenBSD VM running on OpenBSD host has sleep calls taking twice as long as they should
+
+Running a script like
+
+while [ 1 ]
+do
+  date
+  sleep 1
+done
+
+on the VM will result in the (correct) date being displayed, but it is displayed only every two (!) seconds.  We have also noticed that if we connect to the VM's console using VNC, and move the mouse pointer constantly in the VNC window, the script runs normally with updates every second!  Note that the script doesn't have to be running on the VM's console - it's also possible to (say) ssh to the VM from a separate machine and run the script and it will display the '2 second' issue, but as soon as you move the mouse pointer constantly in the VNC console window the script starts behaving normally with updates every second.
+
+I have only seen this bug when running an OpenBSD VM on an OpenBSD host.  Running an OpenBSD VM on a Linux host does not exhibit the problem for me.  I also belive (am told) that a Linux VM running on an OpenBSD host does not exhibit the problem.
+
+I have been using the OpenBSD 5.4 64 bit distro which comes with qemu 1.5.1 in a package, however I tried compiling qemu 1.6.1 and that has the same bug.  In fact older OpenBSD distros have the same issue - going back to OpenBSD distros from two years ago still have the problem.  This is not a 'new' bug recently introduced.
+
+Initially I wondered if it could be traced to an incorrectly set command line option, but I've since gone through many of the options in the man page simply trying different values (eg. different CPU types ( -cpu) , different emulated PC (-M)) but so far the problem remains.
+
+I'm quite happy to run tests in order to track this bug down better.  We use qemu running on OpenBSD extensively and find it very useful!
+
+Hi, please test qemu 1.7.0-rc.  There were several changes to the timer machinery that can help this bug.
+
+I'll have a look at it now.
+
+Regards,
+
+-Martin
+
+
+On 28/11/13 01:58, Paolo Bonzini wrote:
+> Hi, please test qemu 1.7.0-rc.  There were several changes to the timer
+> machinery that can help this bug.
+>
+
+
+-- 
+R A Ward Ltd. | We take the privacy of our customers seriously.
+Christchurch  | All sensitive E-Mail attachments MUST be encrypted.
+New Zealand
+
+
+
+I downloaded 1.7.0-rc2 and compiled it.  Running it, I see the version 
+number reported as 1.6.92!?
+
+In any case, I don't see any improvement, ie. the bug is still there.
+
+Regards,
+
+-Martin
+
+
+On 28/11/13 01:58, Paolo Bonzini wrote:
+> Hi, please test qemu 1.7.0-rc.  There were several changes to the timer
+> machinery that can help this bug.
+>
+
+
+
+Hadn't heard any news on this bug so decided to check the latest source.  1.7.0 now available so downloaded it and compiled it.  No mean feat in itself for OpenBSD.  FWIW it seemed a lot more difficult than for earlier (1.6.x) versions.  1.7.0 now reports its version as 1.7.0 - a good start.  Alas the "2 second" bug still appears to be there.
+
+This issue was fixed in the openstack/python-tripleoclient 0.0.10 release.
+
+What does comment #5 mean? Is this issue now fixed with the latest version of QEMU?
+
+I hadn't seen comment #5.  Not sure how that affects qemu.  
+Unfortunately I'm not in a position to set up a system any time soon 
+with the latest versions of everything to see if the bug is still present.
+
+
+On 24/01/17 08:32, Thomas Huth wrote:
+> What does comment #5 mean? Is this issue now fixed with the latest
+> version of QEMU?
+>
+> ** Changed in: qemu
+>         Status: New => Incomplete
+>
+
+
+-- 
+R A Ward Ltd. | We take the privacy of our customers seriously.
+Christchurch  | All sensitive E-Mail attachments MUST be encrypted.
+New Zealand
+
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+