summary refs log tree commit diff stats
path: root/results/classifier/108/other/121
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/12116
-rw-r--r--results/classifier/108/other/121023
-rw-r--r--results/classifier/108/other/121021242
-rw-r--r--results/classifier/108/other/121122
-rw-r--r--results/classifier/108/other/121191028
-rw-r--r--results/classifier/108/other/121194323
-rw-r--r--results/classifier/108/other/121358
-rw-r--r--results/classifier/108/other/121319639
-rw-r--r--results/classifier/108/other/121488430
-rw-r--r--results/classifier/108/other/121587
-rw-r--r--results/classifier/108/other/121636854
-rw-r--r--results/classifier/108/other/1216845105
-rw-r--r--results/classifier/108/other/1217145
-rw-r--r--results/classifier/108/other/121835
-rw-r--r--results/classifier/108/other/1218098137
-rw-r--r--results/classifier/108/other/121920777
-rw-r--r--results/classifier/108/other/121923438
17 files changed, 959 insertions, 0 deletions
diff --git a/results/classifier/108/other/121 b/results/classifier/108/other/121
new file mode 100644
index 000000000..1da9c8e94
--- /dev/null
+++ b/results/classifier/108/other/121
@@ -0,0 +1,16 @@
+device: 0.779
+performance: 0.728
+debug: 0.662
+network: 0.621
+other: 0.591
+graphic: 0.417
+permissions: 0.414
+boot: 0.341
+socket: 0.285
+vnc: 0.217
+semantic: 0.201
+PID: 0.194
+files: 0.152
+KVM: 0.024
+
+multiprocess program gets incorrect results with qemu arm-linux-user
diff --git a/results/classifier/108/other/1210 b/results/classifier/108/other/1210
new file mode 100644
index 000000000..c2fe9a6eb
--- /dev/null
+++ b/results/classifier/108/other/1210
@@ -0,0 +1,23 @@
+device: 0.859
+graphic: 0.816
+performance: 0.667
+files: 0.644
+semantic: 0.605
+network: 0.536
+debug: 0.464
+permissions: 0.316
+boot: 0.311
+PID: 0.176
+other: 0.158
+vnc: 0.097
+socket: 0.059
+KVM: 0.034
+
+qemu segfaults on PNG screendump
+Description of problem:
+Attempting to produce a screendump via the monitor in the PNG format leads to a segmentation fault (but the screen dump is produced correctly).
+Steps to reproduce:
+1. Launch QEMU
+2. Go to the monitoring screen ()
+3. execute the command: `screendump /tmp/dump.png -f png`
+4. observe the crash (segfault)
diff --git a/results/classifier/108/other/1210212 b/results/classifier/108/other/1210212
new file mode 100644
index 000000000..84bb2eaac
--- /dev/null
+++ b/results/classifier/108/other/1210212
@@ -0,0 +1,42 @@
+device: 0.716
+debug: 0.666
+graphic: 0.665
+semantic: 0.553
+socket: 0.530
+network: 0.499
+vnc: 0.499
+permissions: 0.441
+boot: 0.428
+PID: 0.394
+performance: 0.394
+other: 0.256
+KVM: 0.232
+files: 0.212
+
+qemu core dumps with -serial mon:vc
+
+qemu 1.5.2-1 dumps core when asked to put the monitor on a virtual console.  For example, suppose you want to monitor the second serial port, you might try something like:
+
+qemu-system-x86_64 -serial null -serial mon:vc
+
+But that creates a core dump.  In fact, even re-creating what should be the default dumps core:
+
+$ qemu-system-x86_64 -serial mon:vc:80Cx25C
+Segmentation fault (core dumped)
+
+I'm not including a backtrace because the bug is so easy to reproduce, but I can provide more info if necessary.
+
+Hi,
+
+This problem has been solved by
+
+commit 7b7ab18d0b9769b5f39e663fa55caed461b1202e:
+Author: Michael Roth <email address hidden>
+Date:   Tue Jul 30 13:04:22 2013 -0500
+
+chardev: fix CHR_EVENT_OPENED events for mux chardevs
+
+Patch link:
+http://patchwork.ozlabs.org/patch/263458/
+
+
diff --git a/results/classifier/108/other/1211 b/results/classifier/108/other/1211
new file mode 100644
index 000000000..260f5e2a3
--- /dev/null
+++ b/results/classifier/108/other/1211
@@ -0,0 +1,22 @@
+device: 0.854
+graphic: 0.562
+debug: 0.375
+boot: 0.229
+semantic: 0.184
+PID: 0.109
+files: 0.089
+other: 0.077
+vnc: 0.038
+network: 0.029
+performance: 0.022
+socket: 0.018
+permissions: 0.012
+KVM: 0.010
+
+Bad fonts in "cirrus" VGA card.
+Description of problem:
+Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file.
+Steps to reproduce:
+Similar to #988.
+Additional information:
+
diff --git a/results/classifier/108/other/1211910 b/results/classifier/108/other/1211910
new file mode 100644
index 000000000..93f1e470b
--- /dev/null
+++ b/results/classifier/108/other/1211910
@@ -0,0 +1,28 @@
+graphic: 0.888
+performance: 0.828
+device: 0.775
+semantic: 0.642
+other: 0.624
+permissions: 0.542
+network: 0.533
+vnc: 0.528
+socket: 0.489
+debug: 0.405
+PID: 0.379
+boot: 0.349
+files: 0.340
+KVM: 0.035
+
+Logical to linear address translation is wrong for 32-bit guests on a 64-bit hypervisor
+
+I run a 64-bit hypervisor in qemu-system-x86_64 (without KVM) and on top of that I have a 32-bit guest. The guest configures the code-segment to have a base of 0x4000_0000 and a limit of 0xFFFF_FFFF with paging disabled. Thus, if a logical address of e.g. 0xC000_0000 is used, it should be translated to 0x0000_0000 (linear and physical), because of the overflow that happens.
+But this does not happen with the described setup. Instead, qemu seems to calculate the logical to linear translation with 64-bit addresses so that no overflow happens. Consequently, the resulting address is 0x1_0000_0000 and this gets written to exitinfo2 in the VMCB structure. This causes trouble for hypervisors that expect the upper 32 bits of exitinfo2 to be 0 for 32-bit guests.
+
+Note also that the exact same setup runs fine on real AMD machines with SVM. That is, the upper 32 bits in exitinfo2 are always 0 because of the overflow.
+
+I've tested that with the latest development version of QEMU (commit 328465fd9f3a628ab320b5959d68d3d49df58fa6).
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1211943 b/results/classifier/108/other/1211943
new file mode 100644
index 000000000..9ccf4cd5b
--- /dev/null
+++ b/results/classifier/108/other/1211943
@@ -0,0 +1,23 @@
+device: 0.751
+performance: 0.569
+network: 0.548
+graphic: 0.544
+socket: 0.489
+PID: 0.347
+boot: 0.311
+debug: 0.308
+semantic: 0.300
+vnc: 0.292
+KVM: 0.278
+other: 0.199
+files: 0.186
+permissions: 0.137
+
+#GP and aligned move instruction
+
+When the operand of movaps, movapd or movdqa instruction isn't aligned, general-protection exception should be generated.
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1213 b/results/classifier/108/other/1213
new file mode 100644
index 000000000..95aa5960a
--- /dev/null
+++ b/results/classifier/108/other/1213
@@ -0,0 +1,58 @@
+device: 0.694
+socket: 0.603
+network: 0.571
+PID: 0.533
+vnc: 0.515
+semantic: 0.508
+files: 0.506
+boot: 0.410
+performance: 0.340
+permissions: 0.335
+other: 0.330
+debug: 0.270
+KVM: 0.260
+graphic: 0.113
+
+7.1.0 - NSIS Installer file issues
+Description of problem:
+![image](/uploads/9d359265667c9640d184805ca09ab15c/image.png)
+
+Please check the screenshot relative to Window program list
+
+**Problem n. 1 (standard icon)**
+
+The icon rlative to QEMU is not graphic icon but starndrd udenfiend icon
+
+**Problem n. 2 (author missing)**
+
+Author info is missing
+
+**Problem n. 3 (installer date is not updated)**
+
+When you upgrade QEM the installation date not reflect last update but first installation (ex. version 7.1.0 with date of 2021).
+
+Note: all issues are relative to NSIS installer script.
+
+**Uninstaller icon**
+
+It seems that
+
+**!define MUI_UNICON "${SRCDIR}\pc-bios\qemu-nsis.ico"**__
+
+didn't work.
+
+Please check here
+
+https://nsis.sourceforge.io/Add_uninstall_information_to_Add/Remove_Programs
+
+Please try to add in uninsaller section
+
+    WriteRegStr HKLM "${UNINST_KEY}" "DisplayIcon" "${SRCDIR}\pc-bios\qemu-nsis.ico"
+
+**Missing author info in uninstall view**
+
+    ; Write the uninstall keys for Windows
+    WriteRegStr HKLM "${UNINST_KEY}" "DisplayName" "QEMU"
+    WriteRegStr HKLM "${UNINST_KEY}" "Publisher" "QEMU crew"
+
+Replace "QEMU crew" with text that you like.
diff --git a/results/classifier/108/other/1213196 b/results/classifier/108/other/1213196
new file mode 100644
index 000000000..624298f8e
--- /dev/null
+++ b/results/classifier/108/other/1213196
@@ -0,0 +1,39 @@
+socket: 0.799
+semantic: 0.557
+device: 0.523
+network: 0.502
+graphic: 0.422
+other: 0.410
+performance: 0.408
+PID: 0.337
+files: 0.328
+vnc: 0.323
+boot: 0.251
+permissions: 0.218
+KVM: 0.146
+debug: 0.145
+
+-serial tcp should hang up when DTR goes low
+
+In keeping with the spirit of serial modem control signals, de-asserting DTR should cause the TCP connection to break; asserting DTR should cause QEMU to initiate a new connection or for it to accept another (in server mode; this may involve waiting for one to arrive, too).
+
+In addition to allowing low DTR to drop the socket connection, and allowing low DTR to reject a socket connection, the DCD modem bit also be implemented - DCD should follow the state of the TCP socket: a connected socket should pull DCD high, and a disconnected socket should pull DCD low. From what Ive seen in the source, it looks like a serial IOCTL functioned needs to be added to chardev/char-socket.c to allow the MSR bits to be tracked against the state of the socket.  DCD should be very easy to implement this way, but I hadn't thought about DTR.
+
+Sent in a patch for this.
+
+https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04658.html
+
+DTR controls the socket.
+
+DCD reflects the state of the socket.
+
+
+
+
+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/97
+
+
diff --git a/results/classifier/108/other/1214884 b/results/classifier/108/other/1214884
new file mode 100644
index 000000000..0bf93ee76
--- /dev/null
+++ b/results/classifier/108/other/1214884
@@ -0,0 +1,30 @@
+device: 0.791
+graphic: 0.785
+other: 0.706
+semantic: 0.692
+vnc: 0.646
+performance: 0.568
+permissions: 0.556
+PID: 0.555
+socket: 0.544
+files: 0.524
+network: 0.499
+debug: 0.443
+boot: 0.397
+KVM: 0.378
+
+Support VDI (Virtualbox) snapshots
+
+Please support Snapshots in VDI images.
+
+It seems that VirtualBox uses a snapshot for any changes to the main system disc. Even when the user does not create a snapshot. 
+
+So if I want to mount a VDI disc with the recent system changes, I have to mount the Snapshot.
+
+Thanks
+
+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/108/other/1215 b/results/classifier/108/other/1215
new file mode 100644
index 000000000..d4b5edcfd
--- /dev/null
+++ b/results/classifier/108/other/1215
@@ -0,0 +1,87 @@
+KVM: 0.626
+other: 0.615
+device: 0.614
+debug: 0.614
+permissions: 0.611
+graphic: 0.593
+vnc: 0.589
+semantic: 0.587
+PID: 0.566
+socket: 0.565
+performance: 0.554
+files: 0.552
+boot: 0.545
+network: 0.540
+
+block-stream qmp command regression in 7.1.0
+Description of problem:
+After `block-stream` qmp commands, guest was hanged when using `iothread` option.  
+According to b1e1af3, there are some change at drain blockdev subtree and strong reference to base node.  
+We couldn't produce this issue when we reverted the commit.  
+It seems to be raised by racing acquiring aio_lock between iothread and main thread.
+Steps to reproduce:
+1. Start Guest with upper command.
+2. After started, operate `block-stream` command to qmp socket
+```
+echo '{"execute":"qmp_capabilities"}{
+   "execute":"block-stream",
+   "arguments":{
+      "job-id":"hangTest", 
+      "device":"vdaFile"    
+   }
+}' | sudo nc -U /var/run/monitor_a9b43742-9117-4aae-8887-24bdb017ec20 -N
+```
+Additional information:
+- gdb debug stack
+```
+Thread 1 (Thread 0x7fcfaed84600 (LWP 162409) "qemu-system-x86"):
+#0  0x00007fcfaf108e7e in __ppoll (fds=0x5634a9b6b240, nfds=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42
+#1  0x00005634a7be22dd in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64
+#2  0x00005634a7bc02c9 in fdmon_poll_wait (ctx=0x5634a990eec0, ready_list=0x7ffcb2ce4fb8, timeout=-1) at ../util/fdmon-poll.c:80
+#3  0x00005634a7bbf9c9 in aio_poll (ctx=ctx@entry=0x5634a990eec0, blocking=blocking@entry=true) at ../util/aio-posix.c:660
+#4  0x00005634a7ac849d in bdrv_parent_drained_end_single (c=c@entry=0x5634a9b4bb30) at ../block/io.c:76
+#5  0x00005634a7a98240 in bdrv_replace_child_noperm (childp=0x5634a9b61240, new_bs=0x0, free_empty_child=<optimized out>) at ../block.c:2910
+#6  0x00005634a7a987fe in bdrv_replace_child_tran (childp=<optimized out>, new_bs=<optimized out>, tran=<optimized out>, free_empty_child=<optimized out>) at ../block.c:2444
+#7  0x00005634a7a988bc in bdrv_remove_file_or_backing_child (bs=bs@entry=0x5634a9b5d1f0, child=child@entry=0x5634a9b4bb30, tran=tran@entry=0x5634aa415fc0) at ../block.c:5155
+#8  0x00005634a7a9fac6 in bdrv_remove_file_or_backing_child (tran=0x5634aa415fc0, child=0x5634a9b4bb30, bs=0x5634a9b5d1f0) at ../block.c:5133
+#9  bdrv_set_file_or_backing_noperm (parent_bs=parent_bs@entry=0x5634a9b5d1f0, child_bs=child_bs@entry=0x0, is_backing=is_backing@entry=true, tran=tran@entry=0x5634aa415fc0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3412
+#10 0x00005634a7a9fd04 in bdrv_set_backing_noperm (errp=0x7ffcb2ce5150, tran=0x5634aa415fc0, backing_hd=0x0, bs=0x5634a9b5d1f0) at ../block.c:3449
+#11 bdrv_set_backing_hd (bs=bs@entry=0x5634a9b5d1f0, backing_hd=backing_hd@entry=0x0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3461
+#12 0x00005634a7b25e19 in stream_prepare (job=0x5634a9e83da0) at ../block/stream.c:85
+#13 0x00005634a7aa922e in job_prepare (job=0x5634a9e83da0) at ../job.c:837
+#14 job_txn_apply (fn=<optimized out>, job=0x5634a9e83da0) at ../job.c:158
+#15 job_do_finalize (job=0x5634a9e83da0) at ../job.c:854
+#16 0x00005634a7aa9726 in job_exit (opaque=0x5634a9e83da0) at ../job.c:941
+#17 0x00005634a7bd26b4 in aio_bh_call (bh=0x7fcfa0824010) at ../util/async.c:150
+#18 aio_bh_poll (ctx=ctx@entry=0x5634a990eec0) at ../util/async.c:178
+#19 0x00005634a7bbf602 in aio_dispatch (ctx=0x5634a990eec0) at ../util/aio-posix.c:421
+#20 0x00005634a7bd22f2 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:320
+#21 0x00007fcfaf3c0d1b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
+#22 0x00005634a7bde7c0 in glib_pollfds_poll () at ../util/main-loop.c:297
+#23 os_host_main_loop_wait (timeout=114194793) at ../util/main-loop.c:320
+#24 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:596
+#25 0x00005634a784fdc3 in qemu_main_loop () at ../softmmu/runstate.c:734
+#26 0x00005634a769f9e0 in qemu_main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:38
+--Type <RET> for more, q to quit, c to continue without paging--
+#27 0x00007fcfaf019d90 in __libc_start_call_main (main=main@entry=0x5634a769b0c0 <main>, argc=argc@entry=56, argv=argv@entry=0x7ffcb2ce54c8) at ../sysdeps/nptl/libc_start_call_main.h:58
+#28 0x00007fcfaf019e40 in __libc_start_main_impl (main=0x5634a769b0c0 <main>, argc=56, argv=0x7ffcb2ce54c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb2ce54b8) at ../csu/libc-start.c:392
+#29 0x00005634a769f905 in _start ()
+```
+- iothread gdb stack
+```
+Thread 3 (Thread 0x7fcfae47e640 (LWP 162411) "IO iothread1"):
+#0  futex_wait (private=0, expected=2, futex_word=0x5634a9b49620) at ../sysdeps/nptl/futex-internal.h:146
+#1  __GI___lll_lock_wait (futex=futex@entry=0x5634a9b49620, private=0) at ./nptl/lowlevellock.c:49
+#2  0x00007fcfaf0880dd in lll_mutex_lock_optimized (mutex=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:48
+#3  ___pthread_mutex_lock (mutex=mutex@entry=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:128
+#4  0x00005634a7bc25b8 in qemu_mutex_lock_impl (mutex=0x5634a9b49620, file=0x5634a7da2997 "../util/async.c", line=682) at ../util/qemu-thread-posix.c:88
+#5  0x00005634a7bd24a5 in aio_context_acquire (ctx=0x5634a9b495c0) at ../util/async.c:682
+#6  co_schedule_bh_cb (opaque=0x5634a9b495c0) at ../util/async.c:520
+#7  0x00005634a7bd26b4 in aio_bh_call (bh=0x5634a9b494a0) at ../util/async.c:150
+#8  aio_bh_poll (ctx=ctx@entry=0x5634a9b495c0) at ../util/async.c:178
+#9  0x00005634a7bbf754 in aio_poll (ctx=0x5634a9b495c0, blocking=blocking@entry=true) at ../util/aio-posix.c:712
+#10 0x00005634a7a9392a in iothread_run (opaque=opaque@entry=0x5634a9998700) at ../iothread.c:67
+#11 0x00005634a7bc21d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504
+#12 0x00007fcfaf084b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+#13 0x00007fcfaf116a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
diff --git a/results/classifier/108/other/1216368 b/results/classifier/108/other/1216368
new file mode 100644
index 000000000..75f8fb275
--- /dev/null
+++ b/results/classifier/108/other/1216368
@@ -0,0 +1,54 @@
+semantic: 0.815
+graphic: 0.705
+device: 0.702
+other: 0.691
+socket: 0.666
+debug: 0.601
+files: 0.554
+performance: 0.550
+PID: 0.515
+vnc: 0.487
+boot: 0.449
+network: 0.391
+permissions: 0.365
+KVM: 0.293
+
+unsupported screen resolution crashes sdl-qemu
+
+if the (windows) guest sets a screen resolution that the SDL backend does not support,
+qemu does an exit(1).
+with this fix, the the resolution is still wrong (only part of the desktop is displayed),
+but qemu keeps running and the guest can auto-revert the video mode:
+
+ui/sdl.c:do_sdl_resize()
+    SDL_Surface * tmp_screen;
+    tmp_screen = SDL_SetVideoMode(width, height, bpp, flags);
+    if (!tmp_screen) {
+//      fprintf(stderr, "Could not open SDL display (%dx%dx%d): %s\n", width, 
+//              height, bpp, SDL_GetError());
+//      exit(1);
+    } else {
+        real_screen = tmp_screen;
+    }
+
+Sorry, a little confusion what's the problem you want to solve?
+
+its in the first sentence. let me rephrase: the (windows) guest can select some screen resolution which SDL cannot
+provide. what happens is that qemu quits without giving the quest a chance to shut down. thats like having a monitor
+that crashes windows when it doesnt support the video mode.
+
+Yes, it is a bug. It should go back to the previous setting if the new screen resolution falied.
+I will send a patch later. 
+
+Thanks.
+
+Patch posted:
+
+http://patchwork.ozlabs.org/patch/270084/
+
+this patch does solve the problem
+
+Patch has been included here a while ago already:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=898ae2846de4dcb1
+... so this ticket could now be marked as fixed.
+
diff --git a/results/classifier/108/other/1216845 b/results/classifier/108/other/1216845
new file mode 100644
index 000000000..d7518aaba
--- /dev/null
+++ b/results/classifier/108/other/1216845
@@ -0,0 +1,105 @@
+permissions: 0.851
+other: 0.760
+semantic: 0.753
+graphic: 0.750
+device: 0.736
+performance: 0.734
+PID: 0.700
+vnc: 0.699
+debug: 0.682
+KVM: 0.650
+files: 0.628
+network: 0.627
+socket: 0.622
+boot: 0.549
+
+qemu-system-arm semihosting always calls exit(0)
+
+In my embedded ARM project I have a bunch of unit tests that I run in a POSIX synthetic environment, and, as usual for POSIX processes, these tests return 0 for success and !=0 for error.
+
+Now I expanded the testing environment to run some of these tests compiled for ARM, under QEMU, with the tracing messages forwarded via the semihosting API.
+
+Up to now everything is fine with the emulation. 
+
+However I have a problem with passing the failure code back to the operating system, to drive the continuous integration framework.
+
+I checked the arm-semi.c code and for SYS_EXIT and I discovered that the parameter passed is ignored and it always calls exit(0):
+
+    case SYS_EXIT:
+        gdb_exit(env, 0);
+        exit(0);
+
+To solve my problem I temporarily made a patch, and for cases that should return non zero codes, I call an unsupported BKPT instruction, which makes QEMU abort, and pass an non zero code (1) back to the operating system.
+
+    qemu: Unsupported SemiHosting SWI 0xf1
+
+This kludge is more or less functional, but is quite inconvenient.
+
+After checking the ARM manuals, I discovered that SYS_EXIT is not standard, and the 0x18 code used for it originally was used for angel_SWIreason_ReportException, which has a slightly different purpose.
+
+Now the question:
+
+Would it be possible to no longer ignore the code passed to 0x18, and if it is non zero, to call exit() with a different value?
+
+The suggested rule would be:
+
+if (code ==0 || code == 0x20026)
+  exit(0);
+elif (code < 256)
+  exit(code);
+else
+  exit(1);
+
+The value 0x20026 means ADP_Stopped_ApplicationExit, and, if I understood it right, it means that the program terminated successfully. If this is not true, it can be removed from the first conditional statement.
+
+What do you think? Can this be added to arm-semi.c?
+
+
+Regards,
+
+Liviu
+
+Had a similar problem with my emulation environment.  However, I did some inspection of the assembly code generated by newlib for ARM semi-hosting.  While it initially appears that exit() and _exit() discard the status code, upon careful inspection one finds that it is pushed on the stack, with the SP pointing right to it at the point at which the SWI is executed.
+
+Thus, if the code passed to 0x18 is 0x20026, you can fetch the status code passed to exit() from the stack.
+
+thank you for your suggestion.
+
+as semihosting servers I use the j-link gdb server, openocd and qemu. if I got it right, you suggest to modify all these servers to retrieve the exit code from a specific location. as long as this is not documented in the ARM manuals, I cannot recommend such a solution.
+
+in the GNU ARM Eclipse project templates I  fixed the problem by using my own semihosting routines, where exit returns different values for 0 and non zero, so I no longer depend on the newlib support for semihosting.
+
+
+
+On 4 February 2015 at 15:56, Karl Zimmerman
+<email address hidden> wrote:
+> Had a similar problem with my emulation environment.  However, I did
+> some inspection of the assembly code generated by newlib for ARM semi-
+> hosting.  While it initially appears that exit() and _exit() discard the
+> status code, upon careful inspection one finds that it is pushed on the
+> stack, with the SP pointing right to it at the point at which the SWI is
+> executed.
+>
+> Thus, if the code passed to 0x18 is 0x20026, you can fetch the status
+> code passed to exit() from the stack.
+
+Yes, but this is an internal implementation detail of newlib,
+not a part of the semihosting ABI. It might well change
+in different versions of newlib and we can't rely on it.
+
+-- PMM
+
+
+With the new 2.0 ARM semihosting ABI, there is an optional extension SYS_EXIT_EXTENDED which can be used to implement returning a non-zero exit code for 32-bit ARM programs:
+
+https://developer.arm.com/docs/100863/latest/semihosting-operations/sys_exit_extended-0x20#sh-ext-exit-extended
+
+QEMU should implement this.
+
+
+https://<email address hidden>/ is a patchset which adds semihosting v2 support to QEMU. With those patches and a guest binary which understands semihosting v2 and knows how to probe for the existence of the EXIT_EXTENDED extension, arm guest binaries will be able to pass a non-zero exit status.
+
+
+The semihosting v2 support went into QEMU in the 4.2 release, but I forgot to close this bug...
+
+
diff --git a/results/classifier/108/other/1217 b/results/classifier/108/other/1217
new file mode 100644
index 000000000..6c9b1a787
--- /dev/null
+++ b/results/classifier/108/other/1217
@@ -0,0 +1,145 @@
+performance: 0.767
+permissions: 0.765
+other: 0.755
+graphic: 0.743
+KVM: 0.726
+vnc: 0.726
+device: 0.708
+debug: 0.700
+semantic: 0.699
+PID: 0.693
+files: 0.687
+socket: 0.683
+boot: 0.660
+network: 0.651
+
+QEMU  6.2.0: Random segfaults when access register eax using qemu-system-x86_64
+Description of problem:
+coredump info:
+```
+(gdb) bt
+#0  0x0000152016187387 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
+#1  0x0000152016188a78 in __GI_abort () at abort.c:90
+#2  0x00001520159f2439 in os::abort (dump_core=<optimized out>)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1572
+#3  0x0000152015c0e64a in VMError::report_and_die (this=this@entry=0x151fe009c4d0)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1112
+#4  0x00001520159fc5e5 in JVM_handle_linux_signal (sig=11, info=0x151fe009c770, ucVoid=0x151fe009c640,
+    abort_if_unrecognized=<optimized out>)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:541
+#5  0x00001520159ef5f8 in signalHandler (sig=11, info=0x151fe009c770, uc=0x151fe009c640)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4591
+#6  <signal handler called>
+#7  do_clone (pd=pd@entry=0x151fc7cfe700, attr=attr@entry=0x151fe009d410, stackaddr=<optimized out>,
+    stopped=<optimized out>, fct=0x152016b4fde0 <start_thread>, clone_flags=4001536)
+    at ../nptl/sysdeps/pthread/createthread.c:77
+#8  0x0000152016b5056a in create_thread (stackaddr=<optimized out>, attr=0x151fe009d410, pd=0x151fc7cfe700)
+    at ../nptl/sysdeps/pthread/createthread.c:244
+#9  __pthread_create_2_1 (newthread=<optimized out>, attr=<optimized out>, start_routine=<optimized out>,
+    arg=<optimized out>) at pthread_create.c:553
+#10 0x00001520159fb9b8 in os::create_thread (thread=0x561592f7f000, thr_type=<optimized out>,
+---Type <return> to continue, or q <return> to quit---f 7
+    stack_size=<optimized out>)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:921
+#11 0x00001520157eea78 in JVM_StartThread (env=<optimized out>, jthread=0x151fe009d4d0)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/share/vm/prims/jvm.cpp:3128
+#12 0x0000152001ef0c26 in ?? ()
+#13 0x00000006e100f538 in ?? ()
+#14 0x00000000de00bfff in ?? ()
+#15 0x0000151fe009d530 in ?? ()
+#16 0x0000152001915328 in ?? ()
+#17 0x00000006e100f538 in ?? ()
+#18 0x0000152010062550 in ?? ()
+#19 0x00000006f1450200 in ?? ()
+#20 0x00001520de280104 in ?? ()
+#21 0x0000000000000000 in ?? ()
+(gdb) f 7
+#7  do_clone (pd=pd@entry=0x151fc7cfe700, attr=attr@entry=0x151fe009d410, stackaddr=<optimized out>,
+    stopped=<optimized out>, fct=0x152016b4fde0 <start_thread>, clone_flags=4001536)
+    at ../nptl/sysdeps/pthread/createthread.c:77
+77        if (__builtin_expect (rc == -1, 0))
+(gdb) disas
+Dump of assembler code for function do_clone:
+   0x0000152016b4f010 <+0>:     push   %r12
+   0x0000152016b4f012 <+2>:     xor    %r12d,%r12d
+   0x0000152016b4f015 <+5>:     mov    %rdx,%r10
+   0x0000152016b4f018 <+8>:     push   %rbp
+   0x0000152016b4f019 <+9>:     mov    %rsi,%rbp
+   0x0000152016b4f01c <+12>:    push   %rbx
+   0x0000152016b4f01d <+13>:    mov    %rdi,%rbx
+   0x0000152016b4f020 <+16>:    sub    $0x10,%rsp
+   0x0000152016b4f024 <+20>:    test   %ecx,%ecx
+   0x0000152016b4f026 <+22>:    setne  %r12b
+   0x0000152016b4f02a <+26>:    jne    0x152016b4f07f <do_clone+111>
+   0x0000152016b4f02c <+28>:    lock incl 0x21022d(%rip)        # 0x152016d5f260 <__nptl_nthreads>
+   0x0000152016b4f033 <+35>:    lea    0x2d0(%rbx),%r8
+   0x0000152016b4f03a <+42>:    lea    0xd9f(%rip),%rdi        # 0x152016b4fde0 <start_thread>
+   0x0000152016b4f041 <+49>:    xor    %eax,%eax
+   0x0000152016b4f043 <+51>:    mov    %rbx,%r9
+   0x0000152016b4f046 <+54>:    mov    %rbx,%rcx
+   0x0000152016b4f049 <+57>:    mov    $0x3d0f00,%edx
+   0x0000152016b4f04e <+62>:    mov    %r8,(%rsp)
+   0x0000152016b4f052 <+66>:    mov    %r10,%rsi
+   0x0000152016b4f055 <+69>:    callq  0x152016b4d470 <__clone@plt>
+=> 0x0000152016b4f05a <+74>:    cmp    $0xffffffff,%eax
+   0x0000152016b4f05d <+77>:    je     0x152016b4f118 <do_clone+264>
+---Type <return> to continue, or q <return> to quit---q
+Quit
+(gdb) p rc
+$1 = 223935
+(gdb) i r rax
+rax            0x36abf  223935
+(gdb) i r eax
+eax            0x0      0
+(gdb) l
+72        atomic_increment (&__nptl_nthreads);
+73
+74        int rc = ARCH_CLONE (fct, STACK_VARIABLES_ARGS, clone_flags,
+75                             pd, &pd->tid, TLS_VALUE, &pd->tid);
+76
+77        if (__builtin_expect (rc == -1, 0))
+78          {
+79            atomic_decrement (&__nptl_nthreads); /* Oops, we lied for a second.  */
+80
+81            /* Perhaps a thread wants to change the IDs and if waiting
+(gdb)
+```
+Additional information:
+```
+# cat test.c
+#include <stdlib.h>
+
+int main() {
+   int rc = test1();
+   if(__builtin_expect (rc == -1, 0)) {
+        return rc;
+   }
+
+  return 0;
+}
+# cat test_asm.s
+global test1
+section .text
+test1:
+      mov rax, 223935
+      ret
+
+(gdb) disas main
+Dump of assembler code for function main:
+   0x00000000004004f6 <+0>:     sub    $0x8,%rsp
+   0x00000000004004fa <+4>:     mov    $0x0,%eax
+   0x00000000004004ff <+9>:     callq  0x4004f0 <test1>
+   0x0000000000400504 <+14>:    cmp    $0xffffffff,%eax
+   0x0000000000400507 <+17>:    sete   %al
+   0x000000000040050a <+20>:    movzbl %al,%eax
+   0x000000000040050d <+23>:    neg    %eax
+   0x000000000040050f <+25>:    add    $0x8,%rsp
+   0x0000000000400513 <+29>:    retq
+End of assembler dump.
+...
+# set breakpoint at 0x0000000000400504 
+(gdb) i r eax
+eax            0x36abf  223935
+(gdb) i r rax
+rax            0x36abf  223935
+```
diff --git a/results/classifier/108/other/1218 b/results/classifier/108/other/1218
new file mode 100644
index 000000000..4d8f32586
--- /dev/null
+++ b/results/classifier/108/other/1218
@@ -0,0 +1,35 @@
+other: 0.867
+permissions: 0.847
+files: 0.840
+device: 0.831
+boot: 0.831
+network: 0.823
+debug: 0.818
+socket: 0.814
+performance: 0.814
+graphic: 0.812
+PID: 0.800
+KVM: 0.792
+semantic: 0.767
+vnc: 0.746
+
+bitmap lost when create snapshot using blockdev-snapshot-sync function
+Description of problem:
+bitmap will be lost when using the blockdev-snapshot-sync qmp command to create external snapshot.
+if we create snapshot with the bitmap ,we have to start our incremental backup chain from a new full-backup.
+Steps to reproduce:
+1. start the qemu :
+qemu-system-x86_64 -name guest=i-00001C,debug-threads=on  -machine pc,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1   -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga  -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8 -device ich9-usb-ehci1,id=usb1,bus=pci.0,addr=0x9 -device piix4-usb-uhci,id=usb2,bus=pci.0,addr=0xb -device qemu-xhci,id=usb3,bus=pci.0,addr=0xc -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on  -drive file=/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1     -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait
+
+2. {"execute":"block-dirty-bitmap-add","arguments":{"node":"drive-virtio-disk0", "name":"bitmap-2022-09-19-16-10-23"}}
+
+3. {"execute":"query-block"} and the result:
+ {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block173", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "**dirty-bitmaps**": [{"name": "bitmap-2022-09-19-16-10-23", "recording": true, "persistent": false, "busy": false, "granularity": 65536, "count": 0}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]}
+
+4. {"execute":"blockdev-snapshot-sync","arguments":{"device": "drive-virtio-disk0", "snapshot-file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "format": "qcow2"}}
+5. {"execute":"query-block"} and the result:
+ {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "backing-filename-format": "qcow2", "virtual-size": 21474836480, "filename": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "full-backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block618", "backing_file_depth": 1, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "backing_file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]}
+
+we lost the bitmap bitmap-2022-09-19-16-10-23
+Additional information:
+the bitmap attach the active bs, when changing the active bs ,the bitmap will be lost...
diff --git a/results/classifier/108/other/1218098 b/results/classifier/108/other/1218098
new file mode 100644
index 000000000..fcf44f406
--- /dev/null
+++ b/results/classifier/108/other/1218098
@@ -0,0 +1,137 @@
+other: 0.762
+performance: 0.636
+graphic: 0.620
+debug: 0.556
+KVM: 0.526
+permissions: 0.499
+boot: 0.494
+network: 0.494
+device: 0.481
+PID: 0.474
+semantic: 0.473
+files: 0.460
+socket: 0.443
+vnc: 0.440
+
+qemu-system-ppc64 segfaults in helper_ldl_mmu
+
+Download a Fedora 19 ISO from:
+http://mirrors.kernel.org/fedora-secondary/releases/19/Fedora/ppc64/iso/
+
+Compile qemu from git (I'm using 401c227b0a1134245ec61c6c5a9997cfc963c8e4
+from today).
+
+Run qemu-system-ppc64 like this:
+
+ppc64-softmmu/qemu-system-ppc64 -M pseries -m 4096 -hda /dev/fedora/f20ppc64 -cdrom /tmp/Fedora-19-ppc64-DVD.iso -netdev user,id=usernet,net=169.254.0.0/16 -device virtio-net-pci,netdev=usernet
+
+Guest gets to yaboot.  If you hit return, qemu segfaults:
+
+Program received signal SIGABRT, Aborted.
+0x00007ffff041fa19 in __GI_raise (sig=sig@entry=6)
+    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
+56	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
+(gdb) t a a bt
+
+Thread 4 (Thread 0x7fff6eef7700 (LWP 7553)):
+#0  sem_timedwait ()
+    at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_timedwait.S:101
+#1  0x00005555559a5897 in qemu_sem_timedwait (sem=sem@entry=0x55555631e788, 
+    ms=ms@entry=10000) at util/qemu-thread-posix.c:238
+#2  0x000055555577e54c in worker_thread (opaque=0x55555631e6f0)
+    at thread-pool.c:97
+#3  0x00007ffff625ec53 in start_thread (arg=0x7fff6eef7700)
+    at pthread_create.c:308
+#4  0x00007ffff04df13d in clone ()
+    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
+
+Thread 3 (Thread 0x7fff6e605700 (LWP 7547)):
+#0  0x00007ffff041fa19 in __GI_raise (sig=sig@entry=6)
+    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
+#1  0x00007ffff0421128 in __GI_abort () at abort.c:90
+#2  0x000055555583ea33 in helper_ldl_mmu (env=0x7ffff7fd7140, addr=1572864, 
+    mmu_idx=1) at /home/rjones/d/qemu/include/exec/softmmu_template.h:153
+#3  0x00007fffab0819d8 in code_gen_buffer ()
+#4  0x00005555557aa7ae in cpu_tb_exec (tb_ptr=<optimized out>, 
+    cpu=0x7ffff7fd7010) at /home/rjones/d/qemu/cpu-exec.c:56
+#5  cpu_ppc_exec (env=env@entry=0x7ffff7fd7140)
+    at /home/rjones/d/qemu/cpu-exec.c:631
+#6  0x00005555557abc35 in tcg_cpu_exec (env=0x7ffff7fd7140)
+    at /home/rjones/d/qemu/cpus.c:1193
+#7  tcg_exec_all () at /home/rjones/d/qemu/cpus.c:1226
+#8  qemu_tcg_cpu_thread_fn (arg=<optimized out>)
+    at /home/rjones/d/qemu/cpus.c:885
+#9  0x00007ffff625ec53 in start_thread (arg=0x7fff6e605700)
+    at pthread_create.c:308
+#10 0x00007ffff04df13d in clone ()
+    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
+
+Thread 1 (Thread 0x7ffff7fa9a40 (LWP 7542)):
+#0  0x00007ffff04d4c2f in __GI_ppoll (fds=0x555556483210, nfds=4, 
+    timeout=<optimized out>, timeout@entry=0x7fffffffd940, 
+    sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56
+#1  0x0000555555762db9 in ppoll (__ss=0x0, __timeout=0x7fffffffd940, 
+    __nfds=<optimized out>, __fds=<optimized out>)
+    at /usr/include/bits/poll2.h:77
+#2  qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, 
+    timeout=timeout@entry=951497) at qemu-timer.c:276
+#3  0x000055555572b58c in os_host_main_loop_wait (timeout=951497)
+    at main-loop.c:228
+#4  main_loop_wait (nonblocking=<optimized out>) at main-loop.c:484
+#5  0x00005555555ef9d8 in main_loop () at vl.c:2090
+#6  main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
+    at vl.c:4435
+
+NB: This does NOT happen if you specify -cpu POWER7 on the command line.
+
+git bisect points the finger at:
+
+401c227b0a1134245ec61c6c5a9997cfc963c8e4 is the first bad commit
+commit 401c227b0a1134245ec61c6c5a9997cfc963c8e4
+Author: Richard Henderson <email address hidden>
+Date:   Thu Jul 25 07:16:52 2013 -1000
+
+    tcg-i386: Use new return-argument ld/st helpers
+    
+    Discontinue the jump-around-jump-to-jump scheme, trading it for a single
+    immediate move instruction.  The two extra jumps always consume 7 bytes,
+    whereas the immediate move is either 5 or 7 bytes depending on where the
+    code_gen_buffer gets located.
+    
+    Signed-off-by: Richard Henderson <email address hidden>
+
+:040000 040000 dfd9a66c85713cd1886a3342de1e9ac95d7ea43f df8673dea69bc89cc2cc979aa24415e3fea4ed53 M	include
+:040000 040000 1f7cd5291f2c69b4126c63bd567c6b106eb332c9 87e7ece766168dda860b513dc97fe5af28ec2c4b M	tcg
+
+
+I just bisected the same thing down to this commit. It only breaks on one of my x86 machines though. Namely one with
+
+  gcc (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012]
+
+The abort comes from stack protect code:
+
+(gdb) bt
+#0  0x00007f4cdf7ff3d5 in raise () from /lib64/libc.so.6
+#1  0x00007f4cdf800858 in abort () from /lib64/libc.so.6
+#2  0x00007f4ce18f15b9 in helper_ldl_mmu (env=0x7f4cce74f140, addr=2143803008,
+    mmu_idx=1) at /tmp/qemu_src/include/exec/softmmu_template.h:153
+#3  0x00007f4cd71eb335 in ?? ()
+#4  0x0000000000000000 in ?? ()
+(gdb) up
+#1  0x00007f4cdf800858 in abort () from /lib64/libc.so.6
+(gdb)
+#2  0x00007f4ce18f15b9 in helper_ldl_mmu (env=0x7f4cce74f140, addr=2143803008,
+    mmu_idx=1) at /tmp/qemu_src/include/exec/softmmu_template.h:153
+warning: Source file is more recent than executable.
+153	                                                        GETPC_EXT());
+(gdb) p /x addr
+$1 = 0x7fc7d680
+(gdb) x /i $pc
+=> 0x7f4ce18f15b9 <helper_ldl_mmu+121>:
+    callq  0x7f4ce16d3550 <__stack_chk_fail@plt>
+
+Fix posted: http://patchwork.ozlabs.org/patch/270872/
+
+
+Commit 584950fd4e4d6ca580800e46f1b41cf1b0b4236c
+
diff --git a/results/classifier/108/other/1219207 b/results/classifier/108/other/1219207
new file mode 100644
index 000000000..7ebadf5a3
--- /dev/null
+++ b/results/classifier/108/other/1219207
@@ -0,0 +1,77 @@
+other: 0.857
+permissions: 0.836
+vnc: 0.829
+KVM: 0.822
+debug: 0.813
+graphic: 0.773
+device: 0.762
+performance: 0.756
+semantic: 0.736
+files: 0.697
+socket: 0.696
+network: 0.681
+boot: 0.660
+PID: 0.647
+
+QMP (32 bit only) segfaults in query-tpm-types when compiled with --enable-tpm
+
+NB: This bug ONLY happens on i686.  When qemu is compiled for x86-64, the bug does NOT happen.
+
+$ ./configure --enable-tpm
+$ make
+$ (sleep 5; printf '{"execute":"qmp_capabilities"}\n{"execute":"query-tpm-types"}\n') | ./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 6, "major": 1}, "package": ""}, "capabilities": []}}
+{"return": {}}
+Segmentation fault (core dumped)
+
+The stack trace is:
+
+#0  output_type_enum (v=0xb9938228, obj=0x5, 
+    strings=0xb77f0320 <TpmType_lookup>, kind=0xb767f1d4 "TpmType", name=0x0, 
+    errp=0xbfec4628) at qapi/qapi-visit-core.c:306
+#1  0xb762b3b5 in visit_type_enum (v=v@entry=0xb9938228, obj=0x5, 
+    strings=0xb77f0320 <TpmType_lookup>, kind=kind@entry=0xb767f1d4 "TpmType", 
+    name=name@entry=0x0, errp=errp@entry=0xbfec4628)
+    at qapi/qapi-visit-core.c:114
+#2  0xb74a9ef4 in visit_type_TpmType (errp=0xbfec4628, name=0x0, 
+    obj=<optimized out>, m=0xb9938228) at qapi-visit.c:5220
+#3  visit_type_TpmTypeList (m=0xb9938228, obj=obj@entry=0xbfec4678, 
+    name=name@entry=0xb76545a6 "unused", errp=errp@entry=0xbfec4674)
+    at qapi-visit.c:5206
+#4  0xb74c403e in qmp_marshal_output_query_tpm_types (errp=0xbfec4674, 
+    ret_out=0xbfec46d8, ret_in=0xb993f490) at qmp-marshal.c:3795
+#5  qmp_marshal_input_query_tpm_types (mon=0xb9937098, qdict=0xb99379a0, 
+    ret=0xbfec46d8) at qmp-marshal.c:3817
+#6  0xb7581d7a in qmp_call_cmd (cmd=<optimized out>, params=0xb99379a0, 
+    mon=0xb9937098) at /home/rjones/d/qemu/monitor.c:4644
+#7  handle_qmp_command (parser=0xb99370ec, tokens=0xb9941438)
+    at /home/rjones/d/qemu/monitor.c:4710
+#8  0xb7631d8f in json_message_process_token (lexer=0xb99370f0, 
+    token=0xb993f3a8, type=JSON_OPERATOR, x=29, y=1)
+    at qobject/json-streamer.c:87
+#9  0xb764579b in json_lexer_feed_char (lexer=lexer@entry=0xb99370f0, 
+    ch=<optimized out>, flush=flush@entry=false) at qobject/json-lexer.c:303
+#10 0xb76458c8 in json_lexer_feed (lexer=lexer@entry=0xb99370f0, 
+    buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1)
+    at qobject/json-lexer.c:356
+#11 0xb7631fab in json_message_parser_feed (parser=0xb99370ec, 
+    buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1)
+    at qobject/json-streamer.c:110
+#12 0xb75803eb in monitor_control_read (opaque=0xb9937098, 
+    buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=1) at /home/rjones/d/qemu/monitor.c:4731
+#13 0xb74b191e in qemu_chr_be_write (len=<optimized out>, 
+    buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", s=0xb9935800) at qemu-char.c:165
+#14 fd_chr_read (chan=0xb9935870, cond=(G_IO_IN | G_IO_HUP), opaque=0xb9935800)
+    at qemu-char.c:841
+#15 0xb71f6876 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0
+#16 0xb71b0286 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
+#17 0xb747a13e in glib_pollfds_poll () at main-loop.c:189
+#18 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:234
+#19 main_loop_wait (nonblocking=1) at main-loop.c:484
+#20 0xb7309f11 in main_loop () at vl.c:2090
+#21 main (argc=8, argv=0xbfec5c14, envp=0xbfec5c38) at vl.c:4435
+
+Looks like the fix has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=02dc4bf5684d3fb46786
+... so closing this ticket now.
+
diff --git a/results/classifier/108/other/1219234 b/results/classifier/108/other/1219234
new file mode 100644
index 000000000..8b373fc11
--- /dev/null
+++ b/results/classifier/108/other/1219234
@@ -0,0 +1,38 @@
+other: 0.876
+device: 0.855
+semantic: 0.828
+debug: 0.809
+files: 0.728
+graphic: 0.727
+performance: 0.699
+PID: 0.660
+socket: 0.555
+permissions: 0.522
+boot: 0.482
+network: 0.419
+vnc: 0.399
+KVM: 0.102
+
+-device ide-hd will assign bus with with no free units
+
+Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1000118
+
+./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device ide-hd,drive=aa -device ide-hd,drive=bb
+qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus supports only 1 units
+qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed.
+qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be initialized
+
+If a bus isn't specified for -device ide-hd, it just uses the first bus it finds, not taking into account if that bus was already assigned for another device. So users are forced to do -device ide-hd,bus=ide.0 -device ide-hd,bus=ide.1, etc. 
+
+This isn't specific to -device ahci, but it's worse there since there isn't any -drive if=IDE or -hda convenience option, which both seem to get the logic correct.
+
+I know -device is the 'build it yourself' approach so I understand if this is WONTFIX.
+
+Is somebody still planning to fix this, or should this be closed as WONTFIX?
+
+I'll re-investigate. I definitely fixed some of this (there is if=IDE for AHCI now), but I recall Markus mentioning recently that there are a lot of weird things quite broken with AHCI and bus assignment.
+
+I'm working on several other IDE fixes for the next release, so we can add this one to the pile. I will leave it as "incomplete" for now since I need to re-assess.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+