2 files changed, 61 insertions, 0 deletions
diff --git a/results/classifier/108/other/1126 b/results/classifier/108/other/1126
new file mode 100644
index 000000000..7cd1758b7
--- /dev/null
+++ b/results/classifier/108/other/1126
@@ -0,0 +1,23 @@
+graphic: 0.885
+semantic: 0.629
+device: 0.620
+files: 0.591
+performance: 0.570
+other: 0.419
+PID: 0.389
+permissions: 0.348
+vnc: 0.266
+debug: 0.251
+network: 0.242
+socket: 0.170
+boot: 0.153
+KVM: 0.004
+
+qemu-system-mipsel freezes for nanoMIPS in the semihosting mode
+Description of problem:
+In the current git master branch (SHA: 7b17a1a8) there is a problem with qemu-system-mipsel when trying to execute a simple hello.elf program in the semihosting mode for the nanoMIPS architecture. I.e. after executing the following command the terminal freezes: 
+ ```
+   $ ./qemu-system-mipsel -cpu I7200 -semihosting -nographic -kernel hello.elf
+ ```
+hello.elf file is generated using the nanoMIPS GNU Toolchain (https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases).
+The program regularly terminates with QEMU emulator version 6.0.1.
diff --git a/results/classifier/108/other/1126369 b/results/classifier/108/other/1126369
new file mode 100644
index 000000000..10ab5001a
--- /dev/null
+++ b/results/classifier/108/other/1126369
@@ -0,0 +1,38 @@
+performance: 0.850
+graphic: 0.658
+device: 0.643
+semantic: 0.573
+boot: 0.419
+network: 0.411
+other: 0.396
+socket: 0.384
+vnc: 0.358
+PID: 0.332
+files: 0.326
+permissions: 0.325
+debug: 0.309
+KVM: 0.258
+
+qemu-img snapshot -c is unreasonably slow
+
+Something fishy is going on with qcow2 internal snapshot creation times.  I don't know if this is a regression because I haven't used internal snapshots in the past.
+
+QEMU 1.4-rc2:
+$ qemu-img create -f qcow2 test.qcow2 -o size=50G,preallocation=metadata
+$ time qemu-img snapshot -c new test.qcow2
+real	3m39.147s
+user	0m10.748s
+sys	0m26.165s
+
+(This is on an SSD)
+
+I expect snapshot creation to take under 1 second.
+
+Skipping the bdrv_flush() in update_cluster_refcount() gives a huge speed-up from over 3 minutes down to <1 second.  I think Kevin already discovered this in the past.
+
+Now we need to figure out how to safely perform the updates without flushing after each L2 table refcount increment.
+
+Looking through old bug tickets... have this issue been fixed, i.e. could we close this ticket nowadays? Or is there still something left to do?
+
+Code inspection shows that qcow2_update_cluster_refcount() no longer calls bdrv_flush().  This issue has been fixed.
+