summary refs log tree commit diff stats
path: root/results/classifier/108/other/90
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/9016
-rw-r--r--results/classifier/108/other/90016
-rw-r--r--results/classifier/108/other/902413181
-rw-r--r--results/classifier/108/other/903370
-rw-r--r--results/classifier/108/other/90336525
-rw-r--r--results/classifier/108/other/90431
-rw-r--r--results/classifier/108/other/90516
-rw-r--r--results/classifier/108/other/905095393
-rw-r--r--results/classifier/108/other/90616
-rw-r--r--results/classifier/108/other/90680462
-rw-r--r--results/classifier/108/other/90686435
-rw-r--r--results/classifier/108/other/90722
-rw-r--r--results/classifier/108/other/90706374
-rw-r--r--results/classifier/108/other/90926
14 files changed, 1283 insertions, 0 deletions
diff --git a/results/classifier/108/other/90 b/results/classifier/108/other/90
new file mode 100644
index 000000000..513ea2a35
--- /dev/null
+++ b/results/classifier/108/other/90
@@ -0,0 +1,16 @@
+device: 0.801
+performance: 0.626
+semantic: 0.606
+files: 0.522
+other: 0.522
+graphic: 0.476
+permissions: 0.244
+boot: 0.217
+socket: 0.179
+network: 0.165
+debug: 0.147
+PID: 0.119
+vnc: 0.054
+KVM: 0.018
+
+vga/std lacks few wide screen modes.
diff --git a/results/classifier/108/other/900 b/results/classifier/108/other/900
new file mode 100644
index 000000000..c8534ca85
--- /dev/null
+++ b/results/classifier/108/other/900
@@ -0,0 +1,16 @@
+device: 0.691
+other: 0.601
+network: 0.464
+performance: 0.416
+semantic: 0.343
+graphic: 0.305
+debug: 0.217
+permissions: 0.168
+PID: 0.160
+boot: 0.138
+files: 0.127
+vnc: 0.024
+socket: 0.020
+KVM: 0.007
+
+how to install gemu guest agent without configure script ?
diff --git a/results/classifier/108/other/902413 b/results/classifier/108/other/902413
new file mode 100644
index 000000000..380354bf5
--- /dev/null
+++ b/results/classifier/108/other/902413
@@ -0,0 +1,181 @@
+graphic: 0.803
+other: 0.769
+performance: 0.668
+KVM: 0.668
+permissions: 0.651
+debug: 0.627
+device: 0.620
+semantic: 0.598
+vnc: 0.525
+socket: 0.493
+network: 0.467
+boot: 0.454
+PID: 0.449
+files: 0.411
+
+qemu-i386-user on ARM host: wine hangs/spins when trying to run anything
+
+With qemu built from git from 217bfb445b54db618a30f3a39170bebd9fd9dbf2 and configured with './configure --target-list=i386-linux-user --static --interp-prefix=/home/pgriffais/natty-i386/', trying to run wine 1.3.15 from an Ubuntu 11.04 chroot results in hangs. If I run an i386 emulated wineserver, wineserver hangs in:
+
+0x600c7f8c in read () at ../sysdeps/unix/syscall-template.S:82
+82	../sysdeps/unix/syscall-template.S: No such file or directory.
+	in ../sysdeps/unix/syscall-template.S
+(gdb) bt
+#0  0x600c7f8c in read () at ../sysdeps/unix/syscall-template.S:82
+#1  0x6004a316 in read (cpu_env=0x622c3ee8, num=3, arg1=6, arg2=1121255519, 
+    arg3=1, arg4=134875664, arg5=1, arg6=1121255528, arg7=0, arg8=0)
+    at /usr/include/bits/unistd.h:45
+#2  do_syscall (cpu_env=0x622c3ee8, num=3, arg1=6, arg2=1121255519, arg3=1, 
+    arg4=134875664, arg5=1, arg6=1121255528, arg7=0, arg8=0)
+    at /home/ubuntu/src/qemu/linux-user/syscall.c:4691
+#3  0x600262f0 in cpu_loop (env=0x622c3ee8)
+    at /home/ubuntu/src/qemu/linux-user/main.c:321
+#4  0x60026bbc in main (argc=<value optimized out>, 
+    argv=<value optimized out>, envp=<value optimized out>)
+    at /home/ubuntu/src/qemu/linux-user/main.c:3817
+
+While wine hangs in:
+
+0x600c84ac in recvmsg () at ../sysdeps/unix/syscall-template.S:82
+82	../sysdeps/unix/syscall-template.S: No such file or directory.
+	in ../sysdeps/unix/syscall-template.S
+(gdb) bt
+#0  0x600c84ac in recvmsg () at ../sysdeps/unix/syscall-template.S:82
+#1  0x60041c4e in do_sendrecvmsg (fd=4, target_msg=<value optimized out>, 
+    flags=1073741824, send=0)
+    at /home/ubuntu/src/qemu/linux-user/syscall.c:1834
+#2  0x600497ec in do_socketcall (cpu_env=<value optimized out>, num=102, 
+    arg1=17, arg2=1122504544, arg3=2076831732, arg4=1122504568, 
+    arg5=2076942688, arg6=1122504888, arg7=0, arg8=0)
+    at /home/ubuntu/src/qemu/linux-user/syscall.c:2235
+#3  do_syscall (cpu_env=<value optimized out>, num=102, arg1=17, 
+    arg2=1122504544, arg3=2076831732, arg4=1122504568, arg5=2076942688, 
+    arg6=1122504888, arg7=0, arg8=0)
+    at /home/ubuntu/src/qemu/linux-user/syscall.c:6085
+#4  0x600262f0 in cpu_loop (env=0x622c3f08)
+    at /home/ubuntu/src/qemu/linux-user/main.c:321
+#5  0x60026bbc in main (argc=<value optimized out>, 
+    argv=<value optimized out>, envp=<value optimized out>)
+    at /home/ubuntu/src/qemu/linux-user/main.c:3817
+
+However if I build wineserver 1.3.15 natively for ARM and run it on the host while wine is emulated, I get the following:
+
+root@tiberiusstation:/home/ubuntu# ./natty-i386/usr/bin/wine notepad
+Unsupported ancillary data: 1/2
+Unsupported ancillary data: 1/2
+Unsupported ancillary data: 1/2
+err:process:__wine_kernel_init boot event wait timed out
+
+I assume the last one is due to wineboot.exe hanging. The main wine process hangs in there:
+
+cg_temp_new_internal_i32 (temp_local=<value optimized out>)
+    at /home/ubuntu/src/qemu/tcg/tcg.c:483
+483	}
+(gdb) bt
+#0  tcg_temp_new_internal_i32 (temp_local=<value optimized out>)
+    at /home/ubuntu/src/qemu/tcg/tcg.c:483
+#1  0x60052ac6 in tcg_temp_new_i32 (val=6)
+    at /home/ubuntu/src/qemu/tcg/tcg.h:442
+#2  tcg_const_i32 (val=6) at /home/ubuntu/src/qemu/tcg/tcg.c:530
+#3  0x6005ef0c in tcg_gen_shri_i32 (ot=2, op1=2, op2=7, is_right=1, 
+    is_arith=0, s=<value optimized out>)
+    at /home/ubuntu/src/qemu/tcg/tcg-op.h:605
+#4  gen_shift_rm_im (ot=2, op1=2, op2=7, is_right=1, is_arith=0, 
+    s=<value optimized out>)
+    at /home/ubuntu/src/qemu/target-i386/translate.c:1514
+#5  0x6006df90 in gen_shifti (s=0xbefea970, pc_start=<value optimized out>)
+    at /home/ubuntu/src/qemu/target-i386/translate.c:1946
+#6  disas_insn (s=0xbefea970, pc_start=<value optimized out>)
+    at /home/ubuntu/src/qemu/target-i386/translate.c:5397
+#7  0x60091758 in gen_intermediate_code_internal (env=0x625656f8, 
+    tb=0x402cdf48) at /home/ubuntu/src/qemu/target-i386/translate.c:7825
+#8  gen_intermediate_code_pc (env=0x625656f8, tb=0x402cdf48)
+    at /home/ubuntu/src/qemu/target-i386/translate.c:7896
+#9  0x60054bf2 in cpu_restore_state (tb=0x402cdf48, env=0x62565690, 
+    searched_pc=1617393812) at /home/ubuntu/src/qemu/translate-all.c:126
+#10 0x60091d9e in handle_cpu_signal (host_signum=<value optimized out>, 
+    pinfo=<value optimized out>, puc=0xbefeab70)
+    at /home/ubuntu/src/qemu/user-exec.c:117
+#11 cpu_x86_signal_handler (host_signum=<value optimized out>, 
+    pinfo=<value optimized out>, puc=0xbefeab70)
+    at /home/ubuntu/src/qemu/user-exec.c:458
+#12 0x6003c764 in host_signal_handler (host_signum=11, info=0xbefeaaf0, 
+    puc=<value optimized out>)
+    at /home/ubuntu/src/qemu/linux-user/signal.c:492
+#13 <signal handler called>
+#14 0x60677894 in static_code_gen_buffer ()
+#15 0x6000a260 in cpu_x86_exec (env=0x0)
+    at /home/ubuntu/src/qemu/cpu-exec.c:566
+#16 0x68953200 in ?? ()
+#17 0x68953200 in ?? ()
+Backtrace stopped: previous frame identical to this frame (corrupt stack?
+
+Running the same version of wine through qemu-user-i386 running on an i386 host works fine with both wineserver and wine being emulated; that's the result I'm trying to achieve.
+
+Forgot to mention I had applied this patch also. Without this, emulated bash can't even start anything.
+
+Multithreaded programs don't work (reliably) in x86 user emulation mode. This is a known (longstanding) bug.
+ARM hosts are also currently known to have problems (as stated in the qemu 1.0 release notes).
+
+
+Thanks for your quick reply, Peter.
+
+Are there more specific bug entries tracking both the general problems you're talking about that I could monitor for progress, or any pointers on the direction to go to improve the situation?
+
+For ARM hosts (mostly being worked on):
+https://bugs.launchpad.net/qemu/+bug/893208
+https://bugs.launchpad.net/qemu/+bug/883136
+https://bugs.launchpad.net/qemu/+bug/883133
+https://bugs.launchpad.net/qemu/+bug/870990
+
+For x86 multithreaded (mostly *not* being worked on):
+https://bugs.launchpad.net/qemu/+bug/668799
+https://bugs.launchpad.net/qemu/+bug/739785
+
+At the moment the target-i386 front end is in status "Odd Fixes", which means it may get easy bug fixes but is unlikely to get enough attention to fix trickier problems like threading support.
+
+
+Understood, thanks a lot for the pointers. From a quick skim it doesn't look like I'm directly running into any of these ARM host issues (yet). I'm hopeful that the i386 target will get increasing attention in the future as ARM devices get more widespread after x86 was the standard for so long. Out of curiosity, is the amd64 target in any better shape?
+
+QEMU has no separate amd64 target; it is all handled by target-i386.
+
+
+See also
+https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/758424
+
+with QEMU expected to turn ver 2.0 in april I wonder this bug is still forgotten. 
+Bugs list on Peter Maydell's post and Dan Kegel's have fixes commited, and I see there are alternative patches from http://patchwork.ozlabs.org/patch/45206/ and http://repo.or.cz/w/qemu/agraf.git linked from http://wiki.winehq.org/ARM
+
+Good question, any news please?
+
+I just tried running x86 windows program, on x86 wine, on qemu-i386, all on an arm host. I am also experiencing a hung wine and wineserver. Was this bug ever fixed?
+
+We're actively working on improving QEMU's support for multithreaded guest programs in linux-user, but those changes are not yet complete.
+
+
+I'm running qemu-2.5.0 on ARM, and wine (wine-1.7, 1.8, wine-staging) all seem to behave similarly; rename the winepreloader and you'll be able to run winecfg, notepad run, a few installers do run and the software runs.  But Windows software LOVES using threads so you rapidly end up with some other installer firing off at least 6 or 8 threads and things break down.  qemu-2.6.0, wine doesn't start.
+
+This is a tricky problem; current qemu has I/O threads, main thread (which is not fully thread-safe, this is what's being worked on...) and user threads; things work as long as some non-thread-safe part is not exercised too hard.  
+
+I was beginning to despair, but there actually appears to be intense development activity on qemu branches on 3 fronts -- 
+
+1) general qemu-multithreading (to make kvm qemu more scalable, let qemu-system-xxx actually use more than one CPU core, instead of simulating x CPU cores on one physical core as it does now). But this also involves fixing thread-safety problems in qemu that affect qemu-user-xxxx.  
+
+2) Specifically getting qemu-i386-static threading work on ARM (a few ARM vendors.)
+
+3) Get qemu-arm-static threading working on x86.
+
+It looks like this should get into qemu in due time, maybe it'd be appropriate to call it qemu-3.0 at that point.
+
+You might want to retry wine with qemu-i386-static again now with qemu 2.7, which has a major thread/signal rework done.
+
+Running SkiFree (1.04 x32) on wine (1.8.3 x32) installed in a gentoo i686 chroot, all running via qemu-user-i386-static 1.7.0 on a raspberry pi 2 armv7 host works. It was almost playable at 1920x1080 too!
+
+winecfg worked, notepad.exe worked, and SkiFree worked too.
+
+So can we close this bug now, or is there still something left to do here?
+
+A year has passed since last update by Nathan Shearer, but status is labeled 'incomplete'. Please check if it's solved with wine 3.0
+
+There hasn't been an update within a year, so let's assume this bug has been fixed.
+
diff --git a/results/classifier/108/other/903 b/results/classifier/108/other/903
new file mode 100644
index 000000000..41e0fa7b2
--- /dev/null
+++ b/results/classifier/108/other/903
@@ -0,0 +1,370 @@
+KVM: 0.691
+other: 0.633
+graphic: 0.476
+debug: 0.453
+device: 0.450
+semantic: 0.438
+permissions: 0.430
+PID: 0.407
+vnc: 0.403
+boot: 0.367
+performance: 0.353
+socket: 0.331
+files: 0.310
+network: 0.244
+
+m1 MacOS panic testing lima with qemu HEAD/7.0.0
+Description of problem:
+I'm trying to help the `lima` project test the latest version of lima on m1 with the latest qemu https://github.com/lima-vm/lima/issues/713 and I got a panic and was told to report back in the qemu issue tracker.
+
+I created a VM with 8GiB memory, and got a panic.
+
+
+lima version:
+```
+⎈ |rancher-desktop:default) ~ ❯❯❯ limactl --version                                                                                                                                                                                                                                                                                            ✘ 1 
+limactl version HEAD-1164273
+```
+
+qemu version:
+```
+(⎈ |rancher-desktop:default) ~ ❯❯❯ qemu-system-aarch64 --version
+QEMU emulator version 6.2.50 (v6.2.0-2380-g1416688c53)
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+```
+
+MacOS panic:
+
+```
+panic(cpu 3 caller 0xfffffe001db6ea58): vm_fault() KERN_FAILURE from guest fault on state 0xfffffe6032c98000 @sleh.c:3091
+Debugger message: panic
+Memory ID: 0x6
+OS release type: User
+OS version: 21A559
+Kernel version: Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
+Fileset Kernelcache UUID: 3B2CA3833A09A383D66FB36667ED9CBF
+Kernel UUID: 67BCB41B-BAA4-3634-8E51-B0210457E324
+iBoot version: iBoot-7429.41.5
+secure boot?: YES
+Paniclog version: 13
+KernelCache slide: 0x00000000160d8000
+KernelCache base:  0xfffffe001d0dc000
+Kernel slide:      0x0000000016900000
+Kernel text base:  0xfffffe001d904000
+Kernel text exec slide: 0x00000000169e8000
+Kernel text exec base:  0xfffffe001d9ec000
+mach_absolute_time: 0x1661a3f15fc
+Epoch Time:        sec       usec
+  Boot    : 0x622a7219 0x00029f9b
+  Sleep   : 0x622ba92c 0x00061dca
+  Wake    : 0x622ba9d3 0x000ae46d
+  Calendar: 0x622bc0fb 0x000caf67
+
+Zone info:
+Foreign   : 0xfffffe0025c14000 - 0xfffffe0025c28000
+Native    : 0xfffffe10003bc000 - 0xfffffe30003bc000
+Readonly  : 0 - 0
+Metadata  : 0xfffffe64105d0000 - 0xfffffe641c53c000
+Bitmaps   : 0xfffffe641c53c000 - 0xfffffe6433f6c000
+CORE 0 PVH locks held: None
+CORE 1 PVH locks held: None
+CORE 2 PVH locks held: None
+CORE 3 PVH locks held: None
+CORE 4 PVH locks held: None
+CORE 5 PVH locks held: None
+CORE 6 PVH locks held: None
+CORE 7 PVH locks held: None
+CORE 8 PVH locks held: None
+CORE 9 PVH locks held: None
+CORE 0: PC=0xfffffe001da72c6c, LR=0xfffffe001da72c6c, FP=0xfffffe6110abbef0
+CORE 1: PC=0xfffffe001f2cdbe0, LR=0xfffffe001f2ceb54, FP=0xfffffe611027b600
+CORE 2: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe603778bef0
+CORE 3 is the one that panicked. Check the full backtrace for details.
+CORE 4: PC=0xfffffe001da72c6c, LR=0xfffffe001da72c6c, FP=0xfffffe61166fbef0
+CORE 5: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6110a6bef0
+CORE 6: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe61121cbef0
+CORE 7: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe60b4be3ef0
+CORE 8: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6032af3ef0
+CORE 9: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6090a4bef0
+Panicked task 0xfffffe150e4ccd50: 17757 pages, 10 threads: pid 21141: qemu-system-aarc
+Panicked thread: 0xfffffe1515ae87d8, backtrace: 0xfffffe60d51e3300, tid: 979402
+		  lr: 0xfffffe001da3e488  fp: 0xfffffe60d51e3370
+		  lr: 0xfffffe001da3e158  fp: 0xfffffe60d51e33e0
+		  lr: 0xfffffe001db7a558  fp: 0xfffffe60d51e3400
+		  lr: 0xfffffe001db6d2d4  fp: 0xfffffe60d51e3480
+		  lr: 0xfffffe001db6ac9c  fp: 0xfffffe60d51e3540
+		  lr: 0xfffffe001d9f37f8  fp: 0xfffffe60d51e3550
+		  lr: 0xfffffe001da3ddcc  fp: 0xfffffe60d51e38f0
+		  lr: 0xfffffe001da3ddcc  fp: 0xfffffe60d51e3960
+		  lr: 0xfffffe001e23c748  fp: 0xfffffe60d51e3980
+		  lr: 0xfffffe001db6ea58  fp: 0xfffffe60d51e39e0
+		  lr: 0xfffffe001db6e5dc  fp: 0xfffffe60d51e3a50
+		  lr: 0xfffffe001d9fe828  fp: 0xfffffe60d51e3a60
+		  lr: 0xfffffe001db823f4  fp: 0xfffffe60d51e3e50
+		  lr: 0xfffffe001db6b140  fp: 0xfffffe60d51e3f10
+		  lr: 0xfffffe001d9f37f8  fp: 0xfffffe60d51e3f20
+
+last started kext at 1368960011: com.apple.filesystems.smbfs	4.0 (addr 0xfffffe001d8ea490, size 64483)
+loaded kexts:
+com.apple.filesystems.smbfs	4.0
+com.apple.filesystems.autofs	3.0
+com.apple.fileutil	20.036.15
+com.apple.UVCService	1
+com.apple.driver.AppleUSBTopCaseDriver	5010.1
+com.apple.iokit.SCSITaskUserClient	452.30.4
+com.apple.driver.AppleIntelI210Ethernet	2.3.1
+com.apple.driver.AppleBiometricServices	1
+com.apple.driver.CoreKDL	1
+com.apple.driver.AppleTopCaseHIDEventDriver	5010.1
+com.apple.driver.SEPHibernation	1
+com.apple.driver.BCMWLANFirmware4387.Hashstore	1
+com.apple.driver.DiskImages.ReadWriteDiskImage	493.0.0
+com.apple.driver.DiskImages.UDIFDiskImage	493.0.0
+com.apple.driver.DiskImages.RAMBackingStore	493.0.0
+com.apple.driver.DiskImages.FileBackingStore	493.0.0
+com.apple.filesystems.apfs	1933.41.2
+com.apple.driver.AppleUSBDeviceNCM	5.0.0
+com.apple.driver.AppleThunderboltIP	4.0.3
+com.apple.driver.AppleFileSystemDriver	3.0.1
+com.apple.nke.l2tp	1.9
+com.apple.filesystems.tmpfs	1
+com.apple.filesystems.lifs	1
+com.apple.IOTextEncryptionFamily	1.0.0
+com.apple.filesystems.hfs.kext	582.40.4
+com.apple.security.BootPolicy	1
+com.apple.BootCache	40
+com.apple.AppleFSCompression.AppleFSCompressionTypeZlib	1.0.0
+com.apple.AppleFSCompression.AppleFSCompressionTypeDataless	1.0.0d1
+com.apple.driver.AppleCS42L84Audio	502.6
+com.apple.driver.ApplePMP	1
+com.apple.driver.AppleSmartIO2	1
+com.apple.driver.AppleSN012776Amp	502.6
+com.apple.AppleEmbeddedSimpleSPINORFlasher	1
+com.apple.driver.AppleT6000SOCTuner	1
+com.apple.driver.AppleT6000CLPCv3	1
+com.apple.driver.AppleSmartBatteryManager	161.0.0
+com.apple.driver.AppleALSColorSensor	1.0.0d1
+com.apple.driver.AppleAOPVoiceTrigger	100.1
+com.apple.driver.ApplePMPFirmware	1
+com.apple.driver.AppleMCDP29XXUpdateSupport	1
+com.apple.driver.AppleM68Buttons	1.0.0d1
+com.apple.driver.AppleSamsungSerial	1.0.0d1
+com.apple.driver.AppleSerialShim	1
+com.apple.driver.usb.AppleSynopsysUSB40XHCI	1
+com.apple.driver.AppleSDXC	3.1.1
+com.apple.driver.AppleSPMIPMU	1.0.1
+com.apple.AGXG13X	187.57
+com.apple.driver.AppleAVD	415
+com.apple.driver.AppleAVE2	501.6.9
+com.apple.driver.AppleJPEGDriver	4.7.8
+com.apple.driver.AppleProResHW	126.2.0
+com.apple.driver.AppleMobileDispT600X-DCP	140.0
+com.apple.driver.AppleDPDisplayTCON	1
+com.apple.driver.AppleEventLogHandler	1
+com.apple.driver.AppleS5L8960XNCO	1
+com.apple.driver.AppleT6001PMGR	1
+com.apple.driver.AppleS8000AES	1
+com.apple.driver.AppleS8000DWI	1.0.0d1
+com.apple.driver.AppleInterruptControllerV2	1.0.0d1
+com.apple.driver.AppleT8110DART	1
+com.apple.driver.AppleBluetoothModule	1
+com.apple.driver.AppleBCMWLANBusInterfacePCIe	1
+com.apple.driver.AppleS5L8920XPWM	1.0.0d1
+com.apple.driver.AudioDMAController-T600x	100.51
+com.apple.driver.AppleT6000DART	1
+com.apple.driver.AppleSPIMC	1
+com.apple.driver.AppleS5L8940XI2C	1.0.0d2
+com.apple.driver.AppleT6000	1
+com.apple.iokit.IOUserEthernet	1.0.1
+com.apple.driver.usb.AppleUSBUserHCI	1
+com.apple.iokit.IOKitRegistryCompatibility	1
+com.apple.iokit.EndpointSecurity	1
+com.apple.driver.AppleDiskImages2	126.40.1
+com.apple.AppleSystemPolicy	2.0.0
+com.apple.nke.applicationfirewall	402
+com.apple.kec.InvalidateHmac	1
+com.apple.kec.AppleEncryptedArchive	1
+com.apple.driver.driverkit.serial	6.0.0
+com.apple.kext.triggers	1.0
+com.apple.driver.AppleUSBMergeNub	900.4.2
+com.apple.driver.usb.cdc.ecm	5.0.0
+com.apple.driver.usb.cdc.acm	5.0.0
+com.apple.driver.usb.serial	6.0.0
+com.apple.driver.usb.cdc.ncm	5.0.0
+com.apple.iokit.IOAVBFamily	1010.2
+com.apple.plugin.IOgPTPPlugin	1000.11
+com.apple.driver.usb.IOUSBHostHIDDevice	1.2
+com.apple.driver.usb.cdc	5.0.0
+com.apple.driver.AppleUSBAudio	412.8
+com.apple.iokit.IOAudioFamily	300.10
+com.apple.vecLib.kext	1.2.0
+com.apple.iokit.IOEthernetAVBController	1.1.0
+com.apple.driver.usb.AppleUSBXHCIPCI	1.2
+com.apple.driver.AppleMesaSEPDriver	100.99
+com.apple.iokit.IOBiometricFamily	1
+com.apple.driver.AppleHIDKeyboard	228
+com.apple.driver.AppleHSBluetoothDriver	5010.1
+com.apple.driver.IOBluetoothHIDDriver	9.0.0
+com.apple.driver.AppleActuatorDriver	5400.25
+com.apple.driver.AppleMultitouchDriver	5400.25
+com.apple.driver.AppleThunderboltPCIUpAdapter	4.1.1
+com.apple.driver.AppleThunderboltDPOutAdapter	8.5.0
+com.apple.driver.AppleSEPHDCPManager	1.0.1
+com.apple.driver.AppleTrustedAccessory	1
+com.apple.iokit.AppleSEPGenericTransfer	1
+com.apple.driver.DiskImages.KernelBacked	493.0.0
+com.apple.driver.AppleXsanScheme	3
+com.apple.driver.usb.networking	5.0.0
+com.apple.driver.AppleThunderboltUSBDownAdapter	1.0.4
+com.apple.driver.AppleThunderboltPCIDownAdapter	4.1.1
+com.apple.driver.AppleThunderboltDPInAdapter	8.5.0
+com.apple.driver.AppleThunderboltDPAdapterFamily	8.5.0
+com.apple.nke.ppp	1.9
+com.apple.driver.AppleHIDTransportSPI	5400.30
+com.apple.driver.AppleHIDTransport	5400.30
+com.apple.driver.AppleInputDeviceSupport	5400.30
+com.apple.driver.AppleBSDKextStarter	3
+com.apple.filesystems.hfs.encodings.kext	1
+com.apple.driver.AppleConvergedIPCOLYBTControl	1
+com.apple.driver.AppleConvergedPCI	1
+com.apple.driver.AppleBluetoothDebug	1
+com.apple.driver.AppleBTM	1.0.1
+com.apple.driver.AppleDiagnosticDataAccessReadOnly	1.0.0
+com.apple.driver.AppleCSEmbeddedAudio	502.6
+com.apple.driver.AppleDCPDPTXProxy	1.0.0
+com.apple.driver.DCPDPFamilyProxy	1
+com.apple.driver.ApplePassthroughPPM	3.0
+com.apple.driver.AppleAOPAudio	102.2
+com.apple.driver.AppleEmbeddedAudio	502.6
+com.apple.iokit.AppleARMIISAudio	100.1
+com.apple.driver.AppleSPU	1
+com.apple.iokit.IONVMeFamily	2.1.0
+com.apple.driver.AppleNANDConfigAccess	1.0.0
+com.apple.AGXFirmwareKextG13XRTBuddy	187.57
+com.apple.AGXFirmwareKextRTBuddy64	187.57
+com.apple.driver.AppleHPM	3.4.4
+com.apple.driver.DCPAVFamilyProxy	1
+com.apple.driver.AppleStockholmControl	1.0.0
+com.apple.driver.AppleT6000TypeCPhy	1
+com.apple.driver.AppleT8103TypeCPhy	1
+com.apple.driver.AppleUSBXDCIARM	1.0
+com.apple.driver.AppleUSBXDCI	1.0
+com.apple.iokit.IOUSBDeviceFamily	2.0.0
+com.apple.driver.usb.AppleSynopsysUSBXHCI	1
+com.apple.driver.usb.AppleUSBXHCI	1.2
+com.apple.driver.AppleEmbeddedUSBHost	1
+com.apple.driver.usb.AppleUSBHub	1.2
+com.apple.driver.usb.AppleUSBHostCompositeDevice	1.2
+com.apple.driver.AppleDialogPMU	1.0.1
+com.apple.driver.AppleSPMI	1.0.1
+com.apple.driver.usb.AppleUSBHostPacketFilter	1.0
+com.apple.iokit.IOGPUFamily	35.11
+com.apple.iokit.IOMobileGraphicsFamily-DCP	343.0.0
+com.apple.driver.AppleDCP	1
+com.apple.driver.AppleFirmwareKit	1
+com.apple.iokit.IOMobileGraphicsFamily	343.0.0
+com.apple.driver.AppleSART	1
+com.apple.driver.ApplePMGR	1
+com.apple.driver.AppleARMWatchdogTimer	1
+com.apple.driver.AppleDisplayCrossbar	1.0.0
+com.apple.iokit.IODisplayPortFamily	1.0.0
+com.apple.driver.AppleTypeCPhy	1
+com.apple.driver.AppleThunderboltNHI	7.2.8
+com.apple.driver.AppleT6000PCIeC	1
+com.apple.iokit.IOThunderboltFamily	9.3.2
+com.apple.driver.ApplePIODMA	1
+com.apple.driver.AppleT600xPCIe	1
+com.apple.driver.AppleMultiFunctionManager	1
+com.apple.driver.AppleBluetoothDebugService	1
+com.apple.driver.AppleBCMWLANCore	1.0.0
+com.apple.iokit.IO80211Family	1200.12.2b1
+com.apple.driver.IOImageLoader	1.0.0
+com.apple.driver.AppleOLYHAL	1
+com.apple.driver.corecapture	1.0.4
+com.apple.driver.AppleEmbeddedPCIE	1
+com.apple.driver.AppleMCA2-T600x	600.95
+com.apple.driver.AppleEmbeddedAudioLibs	100.9.1
+com.apple.driver.AppleFirmwareUpdateKext	1
+com.apple.driver.AppleH13CameraInterface	4.79.0
+com.apple.driver.AppleH10PearlCameraInterface	17.0.3
+com.apple.driver.AppleGPIOICController	1.0.2
+com.apple.driver.AppleFireStormErrorHandler	1
+com.apple.driver.AppleMobileApNonce	1
+com.apple.iokit.IOTimeSyncFamily	1000.11
+com.apple.driver.DiskImages	493.0.0
+com.apple.iokit.IOGraphicsFamily	593
+com.apple.iokit.IOBluetoothSerialManager	9.0.0
+com.apple.iokit.IOBluetoothHostControllerUSBTransport	9.0.0
+com.apple.iokit.IOBluetoothHostControllerUARTTransport	9.0.0
+com.apple.iokit.IOBluetoothHostControllerTransport	9.0.0
+com.apple.driver.IOBluetoothHostControllerPCIeTransport	9.0.0
+com.apple.iokit.IOBluetoothFamily	9.0.0
+com.apple.driver.FairPlayIOKit	68.13.0
+com.apple.iokit.CoreAnalyticsFamily	1
+com.apple.iokit.CSRBluetoothHostControllerUSBTransport	9.0.0
+com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport	9.0.0
+com.apple.driver.AppleSSE	1.0
+com.apple.driver.AppleSEPKeyStore	2
+com.apple.driver.AppleUSBTDM	532.40.7
+com.apple.iokit.IOUSBMassStorageDriver	209.40.6
+com.apple.iokit.IOPCIFamily	2.9
+com.apple.iokit.IOSCSIBlockCommandsDevice	452.30.4
+com.apple.iokit.IOSCSIArchitectureModelFamily	452.30.4
+com.apple.driver.AppleIPAppender	1.0
+com.apple.driver.AppleFDEKeyStore	28.30
+com.apple.driver.AppleEffaceableStorage	1.0
+com.apple.driver.AppleCredentialManager	1.0
+com.apple.driver.KernelRelayHost	1
+com.apple.iokit.IOUSBHostFamily	1.2
+com.apple.driver.AppleUSBHostMergeProperties	1.2
+com.apple.driver.usb.AppleUSBCommon	1.0
+com.apple.driver.AppleSMC	3.1.9
+com.apple.driver.RTBuddy	1.0.0
+com.apple.driver.AppleEmbeddedTempSensor	1.0.0
+com.apple.driver.AppleARMPMU	1.0
+com.apple.iokit.IOAccessoryManager	1.0.0
+com.apple.driver.AppleOnboardSerial	1.0
+com.apple.iokit.IOSkywalkFamily	1.0
+com.apple.driver.mDNSOffloadUserClient	1.0.1b8
+com.apple.iokit.IONetworkingFamily	3.4
+com.apple.iokit.IOSerialFamily	11
+com.apple.driver.AppleSEPManager	1.0.1
+com.apple.driver.AppleA7IOP	1.0.2
+com.apple.driver.IOSlaveProcessor	1
+com.apple.driver.AppleBiometricSensor	2
+com.apple.iokit.IOHIDFamily	2.0.0
+com.apple.driver.AppleANELoadBalancer	5.33.2
+com.apple.driver.AppleH11ANEInterface	5.33.0
+com.apple.AUC	1.0
+com.apple.iokit.IOAVFamily	1.0.0
+com.apple.iokit.IOHDCPFamily	1.0.0
+com.apple.iokit.IOCECFamily	1
+com.apple.iokit.IOAudio2Family	1.0
+com.apple.driver.AppleIISController	100.1
+com.apple.driver.AppleAudioClockLibs	100.9.1
+com.apple.driver.AppleM2ScalerCSCDriver	265.0.0
+com.apple.iokit.IOSurface	302.9
+com.apple.driver.IODARTFamily	1
+com.apple.security.quarantine	4
+com.apple.security.sandbox	300.0
+com.apple.kext.AppleMatch	1.0.0d1
+com.apple.driver.AppleMobileFileIntegrity	1.0.5
+com.apple.security.AppleImage4	4.1.0
+com.apple.kext.CoreTrust	1
+com.apple.iokit.IOCryptoAcceleratorFamily	1.0.1
+com.apple.driver.AppleARMPlatform	1.0.2
+com.apple.iokit.IOStorageFamily	2.1
+com.apple.iokit.IOSlowAdaptiveClockingFamily	1.0.0
+com.apple.iokit.IOReportFamily	47
+com.apple.kec.pthread	1
+com.apple.kec.Libm	1
+com.apple.kec.corecrypto	12.0
+
+
+
+** Stackshot Succeeded ** Bytes Traced 478480 (Uncompressed 1208976) **
+```
+Steps to reproduce:
+1. See https://github.com/lima-vm/lima/issues/713
+Additional information:
+
diff --git a/results/classifier/108/other/903365 b/results/classifier/108/other/903365
new file mode 100644
index 000000000..bfd5a6423
--- /dev/null
+++ b/results/classifier/108/other/903365
@@ -0,0 +1,25 @@
+network: 0.813
+other: 0.744
+graphic: 0.585
+device: 0.509
+semantic: 0.500
+performance: 0.482
+socket: 0.475
+vnc: 0.337
+permissions: 0.336
+files: 0.269
+debug: 0.252
+boot: 0.208
+PID: 0.186
+KVM: 0.157
+
+[feature request] bind nat (-net user) to other interface (like eth0:2)
+
+-net user mode is very nice because it does not require any changes in host system. However if host system has muplitple IPs You cant use it, or even switch to another. Qemu should be able to "bind" to eth0:1 eth0:2 so that outgoing traffic uses this interface and thus other IP.
+
+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/904 b/results/classifier/108/other/904
new file mode 100644
index 000000000..24713791c
--- /dev/null
+++ b/results/classifier/108/other/904
@@ -0,0 +1,31 @@
+permissions: 0.887
+graphic: 0.875
+device: 0.846
+performance: 0.730
+semantic: 0.662
+debug: 0.641
+network: 0.599
+vnc: 0.485
+PID: 0.479
+boot: 0.425
+socket: 0.381
+files: 0.356
+KVM: 0.219
+other: 0.191
+
+RISC-V: Cannot set SEIP bit of mip csr register in M mode
+Description of problem:
+
+Steps to reproduce:
+1.   run assembly instructions **in M mode**: 
+```
+not t0, x0    // set t0 to 0b11..11
+csrs mip, t0  // write mip with t0, mip registers are WARL(Write Any Values, Reads Legal Values)
+csrr t1, mip  // read value from mip to t1
+```
+2.   GDB enters the command `display/z $t1` to see that the content of the t1 register is 0x466, which means that the SEIP bit of mip is not set.
+3.   According to page 47 of [riscv-privileged-20211203](https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf), `SEIP is writable in mip`.
+4.   According to page 81 of the same manual,`If implemented, SEIP is read-only in sip`.
+5.   However, the above code and results show that the SEIP bit of mip cannot be set by software **in M mode**.
+Additional information:
+
diff --git a/results/classifier/108/other/905 b/results/classifier/108/other/905
new file mode 100644
index 000000000..f8676e25f
--- /dev/null
+++ b/results/classifier/108/other/905
@@ -0,0 +1,16 @@
+graphic: 0.661
+performance: 0.656
+debug: 0.560
+device: 0.245
+semantic: 0.222
+boot: 0.079
+network: 0.069
+other: 0.037
+socket: 0.033
+vnc: 0.021
+KVM: 0.017
+PID: 0.011
+permissions: 0.006
+files: 0.003
+
+Null-ptr dereference in blk_bs
diff --git a/results/classifier/108/other/905095 b/results/classifier/108/other/905095
new file mode 100644
index 000000000..0af9e4dbd
--- /dev/null
+++ b/results/classifier/108/other/905095
@@ -0,0 +1,393 @@
+permissions: 0.783
+KVM: 0.766
+graphic: 0.712
+device: 0.709
+PID: 0.688
+semantic: 0.683
+debug: 0.677
+performance: 0.676
+boot: 0.675
+network: 0.669
+socket: 0.659
+other: 0.658
+vnc: 0.644
+files: 0.583
+
+qemu-img can't convert vmdk file: Operation not permitted
+
+There is no reason why the vdmk image can't be converted. Even running it as root does not help.
+
+$ ls -lh
+insgesamt 60G
+-rw-rw-rw- 1 root   root   479M 2011-09-10 17:47 freetz-linux-1.2.1-disk1.vmdk
+
+$ sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw
+qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted
+qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk'
+
+I get a similar Error when I try to rum vmdk images directly. After adding a new machine and adding vmdk disks with virt-manager, it tells me when I start the virtual machine:
+Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1
+kvm: -drive file=/var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk,if=none,id=drive-virtio-disk0,boot=on,format=qcow2: could not open disk image /var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk: Invalid argument
+
+Runnung raw images works perfectly for me.
+
+Hint: i have a symlink set:
+/var/lib/libvirt$ ls -lh
+insgesamt 12K
+drwxr-xr-x 2 root         root 4,0K 2011-07-26 14:30 boot
+lrwxrwxrwx 1 root         root    9 2011-08-19 10:47 images -> /home/vms
+drwxr-xr-x 2 root         root 4,0K 2011-08-19 09:38 network
+drwxr-xr-x 5 libvirt-qemu kvm  4,0K 2011-12-16 04:34 qemu
+
+but this should not be the reason hopefully
+
+ProblemType: Bug
+DistroRelease: Ubuntu 11.04
+Package: qemu-kvm 0.14.0+noroms-0ubuntu4.4
+ProcVersionSignature: Ubuntu 2.6.38-13.52-generic 2.6.38.8
+Uname: Linux 2.6.38-13-generic x86_64
+Architecture: amd64
+CheckboxSubmission: 8f12e98536291f59719792d89958b124
+CheckboxSystem: d00f84de8a555815fa1c4660280da308
+Date: Fri Dec 16 04:24:10 2011
+InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
+KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
+MachineType: Dell Inc. Latitude E5510
+ProcEnviron:
+ LANGUAGE=de_DE:en
+ PATH=(custom, user)
+ LANG=de_DE.UTF-8
+ SHELL=/bin/bash
+ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-13-generic root=UUID=503213e4-5136-4e60-8a02-7cbd0123dca8 ro quiet splash vt.handoff=7
+SourcePackage: qemu-kvm
+UpgradeStatus: Upgraded to natty on 2011-08-18 (119 days ago)
+dmi.bios.date: 09/08/2011
+dmi.bios.vendor: Dell Inc.
+dmi.bios.version: A11
+dmi.board.name: 023HKR
+dmi.board.vendor: Dell Inc.
+dmi.board.version: A00
+dmi.chassis.type: 9
+dmi.chassis.vendor: Dell Inc.
+dmi.modalias: dmi:bvnDellInc.:bvrA11:bd09/08/2011:svnDellInc.:pnLatitudeE5510:pvr0001:rvnDellInc.:rn023HKR:rvrA00:cvnDellInc.:ct9:cvr:
+dmi.product.name: Latitude E5510
+dmi.product.version: 0001
+dmi.sys.vendor: Dell Inc.
+
+
+
+I just saw that the image format in my last comment was not set right. After changing it from qcow2 to vmdk I get this error when starting the machine:
+
+Error starting domain: operation failed: failed to retrieve chardev info in qemu with 'info chardev'
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/engine.py", line 956, in asyncfunc
+    vm.startup()
+  File "/usr/share/virt-manager/virtManager/domain.py", line 1048, in startup
+    self._backend.create()
+  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 330, in create
+    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
+libvirtError: operation failed: failed to retrieve chardev info in qemu with 'info chardev'
+
+To reproduce the problem feel free to download this image:
+http://sourceforge.net/projects/freetz-linux/
+
+here's the xml file of the virtual machine
+
+same on a fresh installed up to date ubuntu 11.10:
+sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw
+qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted
+qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk'
+
+up-to-date debian 6.0 says:
+# qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img
+qemu-img: error while reading
+
+debian testing says:
+qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img
+qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted
+qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk'
+
+debian sid says:
+qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img
+*** glibc detected *** qemu-img: double free or corruption (top): 0x000000000755cd60 ***
+======= Backtrace: =========
+/lib/x86_64-linux-gnu/libc.so.6(+0x72656)[0x2b78929df656]
+/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x2b78929e438c]
+qemu-img[0x41c4a2]
+qemu-img[0x41d1e6]
+qemu-img[0x40e6d9]
+qemu-img[0x40f247]
+qemu-img[0x4055f1]
+qemu-img[0x4068ad]
+/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x2b789298bead]
+qemu-img[0x404efd]
+======= Memory map: ========
+00400000-0045a000 r-xp 00000000 91:e6 114343429                          /usr/bin/qemu-img
+0065a000-0065f000 rw-p 0005a000 91:e6 114343429                          /usr/bin/qemu-img
+0065f000-00a60000 rw-p 0065f000 00:00 0 
+0755a000-0757b000 rw-p 0755a000 00:00 0                                  [heap]
+2b7891471000-2b7891490000 r-xp 00000000 91:e6 254542713                  /lib/x86_64-linux-gnu/ld-2.13.so
+2b7891490000-2b7891492000 rw-p 2b7891490000 00:00 0 
+2b7891690000-2b7891691000 r--p 0001f000 91:e6 254542713                  /lib/x86_64-linux-gnu/ld-2.13.so
+2b7891691000-2b7891692000 rw-p 00020000 91:e6 254542713                  /lib/x86_64-linux-gnu/ld-2.13.so
+2b7891692000-2b7891693000 rw-p 2b7891692000 00:00 0 
+2b7891693000-2b789169a000 r-xp 00000000 91:e6 254542726                  /lib/x86_64-linux-gnu/librt-2.13.so
+2b789169a000-2b7891899000 ---p 00007000 91:e6 254542726                  /lib/x86_64-linux-gnu/librt-2.13.so
+2b7891899000-2b789189a000 r--p 00006000 91:e6 254542726                  /lib/x86_64-linux-gnu/librt-2.13.so
+2b789189a000-2b789189b000 rw-p 00007000 91:e6 254542726                  /lib/x86_64-linux-gnu/librt-2.13.so
+2b789189b000-2b78918b2000 r-xp 00000000 91:e6 89718972                   /usr/lib/libz.so.1.2.3.4
+2b78918b2000-2b7891ab1000 ---p 00017000 91:e6 89718972                   /usr/lib/libz.so.1.2.3.4
+2b7891ab1000-2b7891ab2000 rw-p 00016000 91:e6 89718972                   /usr/lib/libz.so.1.2.3.4
+2b7891ab2000-2b7891ab3000 rw-p 2b7891ab2000 00:00 0 
+2b7891ab3000-2b7891ace000 r-xp 00000000 91:e6 115417965                  /usr/lib/librbd.so.1.0.0
+2b7891ace000-2b7891ccd000 ---p 0001b000 91:e6 115417965                  /usr/lib/librbd.so.1.0.0
+2b7891ccd000-2b7891cce000 rw-p 0001a000 91:e6 115417965                  /usr/lib/librbd.so.1.0.0
+2b7891cce000-2b7891eca000 r-xp 00000000 91:e6 115417963                  /usr/lib/librados.so.2.0.0
+2b7891eca000-2b78920ca000 ---p 001fc000 91:e6 115417963                  /usr/lib/librados.so.2.0.0
+2b78920ca000-2b78920d9000 rw-p 001fc000 91:e6 115417963                  /usr/lib/librados.so.2.0.0
+2b78920d9000-2b78920ed000 rw-p 2b78920d9000 00:00 0 
+2b78920ed000-2b7892147000 r-xp 00000000 91:e6 254542231                  /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0
+2b7892147000-2b7892347000 ---p 0005a000 91:e6 254542231                  /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0
+2b7892347000-2b7892349000 r--p 0005a000 91:e6 254542231                  /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0
+2b7892349000-2b789234a000 rw-p 0005c000 91:e6 254542231                  /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0
+2b789234a000-2b789234b000 rw-p 2b789234a000 00:00 0 
+2b789234b000-2b789234f000 r-xp 00000000 91:e6 152502901                  /lib/libuuid.so.1.3.0
+2b789234f000-2b789254e000 ---p 00004000 91:e6 152502901                  /lib/libuuid.so.1.3.0
+2b789254e000-2b789254f000 rw-p 00003000 91:e6 152502901                  /lib/libuuid.so.1.3.0
+2b789254f000-2b7892550000 r-xp 00000000 91:e6 254542270                  /lib/x86_64-linux-gnu/libaio.so.1.0.1
+2b7892550000-2b789274f000 ---p 00001000 91:e6 254542270                  /lib/x86_64-linux-gnu/libaio.so.1.0.1
+2b789274f000-2b7892750000 rw-p 00000000 91:e6 254542270                  /lib/x86_64-linux-gnu/libaio.so.1.0.1
+2b7892750000-2b7892767000 r-xp 00000000 91:e6 254542714                  /lib/x86_64-linux-gnu/libpthread-2.13.so
+2b7892767000-2b7892966000 ---p 00017000 91:e6 254542714                  /lib/x86_64-linux-gnu/libpthread-2.13.so
+2b7892966000-2b7892967000 r--p 00016000 91:e6 254542714                  /lib/x86_64-linux-gnu/libpthread-2.13.so
+2b7892967000-2b7892968000 rw-p 00017000 91:e6 254542714                  /lib/x86_64-linux-gnu/libpthread-2.13.so
+2b7892968000-2b789296d000 rw-p 2b7892968000 00:00 0 
+2b789296d000-2b7892ae7000 r-xp 00000000 91:e6 254542727                  /lib/x86_64-linux-gnu/libc-2.13.so
+2b7892ae7000-2b7892ce7000 ---p 0017a000 91:e6 254542727                  /lib/x86_64-linux-gnu/libc-2.13.so
+2b7892ceAborted
+
+
+seems to be an older problem:
+https://bugzilla.redhat.com/show_bug.cgi?id=548723
+
+still getting the error while trying to convert a vmdk
+
+how to proceed?
+
+I just generated OVA from vsphere client, then I untarred it and I got a ovf and a vmdk file, how do I convert the vmdk to a readable format by kvm?
+
+Angelo, a workaround for me was to run the freetz image (which in fact is an ubuntu image) with VirtalBox. Then I booted the Machine with a systemrescuecd CD.
+
+In systemrescuecd I extracted the disk image using the dd command (disk druid). You can netcat the raw image via network to your KVM machine. The raw image booted without any problems in KVM.
+
+Hope this works for you.
+
+Confirmed on ubuntu 11.10:
+>> qemu-img convert ZendTo-Ubuntu-x64-disk1.vmdk -O raw zend.img
+qemu-img: Could not open 'ZendTo-Ubuntu-x64-disk1.vmdk': Operation not permitted
+qemu-img: Could not open 'ZendTo-Ubuntu-x64-disk1.vmdk'
+
+
+Hello,
+Could someone please comment on this? There are blogs and such all over the internet talking about how easy it is to use qemu-img convert to convert VMware vmdk's to KVM qcow2's (or other formats). However, every time I do this, no matter what version of Linux or qemu-img I am using, it either a) produces an image but that is only a few MBs and thus obviously unbootable; or b) has the error in comment #9 (Operation not permitted). I see thomas303's workaround but that obviously sounds pretty harsh to be doing on a regular basis as we are looking to support our product on both VMware and KVM. Will this inability to convert vmdk to qcow2 be addressed in qemu soon?
+
+@Neil,
+
+it looks like the 2011 google summer of code project did not succeed.  I don't know of anyone else working on this problem right now.
+
+Actually support upstream has improved a lot in recent qemu (thanks to IBM), and Red Hat are planning on doing further work in this area.
+
+Right now / with old qemu, the best thing is to convert your proprietary vmdk files to a portable format, ie. raw or qcow2, and use that instead.
+
+I retried with ubuntu 16.04, qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.4).
+
+While the original file (freetz vmdk) is not available (they use .ova now), I got another .vmdk file from
+http://www.osboxes.org/debian/#debian-8-5-vmware
+
+qemu-img convert Debian\ 8.5\ \(64bit\).vmdk -O raw test.raw
+qemu-img convert Debian\ 8.5\ \(64bit\).vmdk -O qcow2 test.qcow2
+
+Both worked, and I could boot the system I converted from .vmdk using qemu-kvm.
+
+Looks as if this issue got fixed, finally.
+
+
+I did the same task on totally different images recently and it worked fine.
+Thanks for bumping that old bug so we can close it.
+
+That "Debian 8.5 (64bit).vmdk" also works fine with the qemu-img from upstream master branch ==> I'm closing this ticket now for upstream, too.
+
+Description of problem:
+
+qemu-img convert cannot convert a VMDK4 format file to (eg) raw (or
+anything else).  It silently produces a large file that mostly
+contains zero bytes, and is completely unusable.
+
+Version-Release number of selected component (if applicable):
+
+Tested with qemu-img 0.10.5, 0.11.0, and
+git d9a50a366f2178 (2009-12-11).
+
+How reproducible:
+
+Always.
+
+Steps to Reproduce:
+1. Export to OVF from VMWare vSphere / ESX 4.0.0.
+2. Copy the resultant disk image to a Fedora machine.
+3. Check the SHA1 sums (from *.mf file) to make sure image was not
+   corrupted during the copy.
+4. Run:
+     qemu-img convert -O raw TestLinux-disk1.vmdk TestLinux-disk1.raw
+5. Try to mount / use the resulting raw file, eg. using guestfish.
+  
+Actual results:
+
+The raw file contains mostly zeroes, see below.  It contains zeroes
+where there should be partition tables, superblocks etc. and so is
+totally unusable.
+
+Expected results:
+
+A usable disk image.
+
+Additional info:
+
+Compare the entropy of the VMDK file with the resulting raw disk.
+I would expect the entropy to be about the same, but you can see the
+raw disk is mostly compressible (zeroes).
+
+  $ ls -l TestLinux-disk1.vmdk
+  -rw-rw-r--  1 rjones rjones  887312896 2009-12-18 10:35 TestLinux-disk1.vmdk
+  $ gzip -c TestLinux-disk1.vmdk | wc -c
+  860846320
+  $ gzip -c TestLinux-disk1.raw | wc -c
+  8744715
+
+VMWare's OVF metadata says the following about the disk format:
+
+  <References>
+    <File ovf:href="TestLinux-disk1.vmdk"
+          ovf:id="file1" ovf:size="887312896" />
+  </References>
+  <DiskSection>
+    <Info>Virtual disk information</Info>
+    <Disk ovf:capacity="8"
+          ovf:capacityAllocationUnits="byte * 2^30"
+          ovf:diskId="vmdisk1" ovf:fileRef="file1"
+          ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" />
+  </DiskSection>
+
+qemu-img 0.10.5 fails in a different way.  It gives the error
+message:
+
+  qemu-img: error while reading
+
+qemu-img >= 0.11.0 fail silently, no error message or error code.
+
+I've tried this with several disk images exported from vSphere 4
+and they have all failed to convert in the same way.
+
+Test files (at time of writing these are STILL UPLOADING, with ETA
+of 2009-12-19).
+
+http://homes.merjis.com/~rich/TestLinux-disk1.vmdk
+  SHA1: 2C81BAE89210B075ACC51DA9D025935470149D55
+http://homes.merjis.com/~rich/TestLinux.ovf
+  SHA1: 30831689B8C6F1B1A1FCBB728769B5F71056A580
+
+This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
+
+This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
+
+You don't happen to know if this reproduces with qemu-img > 0.12.x or have a test image I can convert to reproduce handy?
+
+Nothing much has changed in the qemu vmdk block
+driver since I looked at it before (I just checked upstream
+git), so it's very likely to be still broken.
+
+I have some VMDK images, but I warn you that they
+are very large!  If you have somewhere I can upload
+them to, I can send some your way ...
+
+
+This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
+Changing version to '13'.
+
+More information and reason for this action is here:
+http://fedoraproject.org/wiki/BugZappers/HouseKeeping
+
+I just checked upstream git for the driver again,
+and apart from code cleanups the code is still the
+same as ever.  Therefore moving the bug -> Rawhide.
+
+Updated links:
+http://oirase.annexia.org/tmp/TestLinux-disk1.vmdk                              
+  SHA1: 2c81bae89210b075acc51da9d025935470149d55                                
+http://oirase.annexia.org/tmp/TestLinux.ovf                                     
+  SHA1: 30831689b8c6f1b1a1fcbb728769b5f71056a580
+
+Latest qemu-img no longer silently converts to zeroes.  Instead
+it gives a strange error:
+
+$ qemu-img convert -f vmdk -O raw TestLinux-disk1.vmdk TestLinux-disk1.raw
+qemu-img: Could not open 'TestLinux-disk1.vmdk': Operation not permitted
+qemu-img: Could not open 'TestLinux-disk1.vmdk'
+
+> qemu-img: Could not open 'TestLinux-disk1.vmdk': Operation not permitted
+
+This is probably because qemu-img.c code expects  brdv_open() to return an errno value
+
+    ret = bdrv_open(bs, filename, flags, drv);
+    if (ret < 0) {
+        error_report("Could not open '%s': %s", filename, strerror(-ret));
+        goto fail;
+    }
+
+while the vmdk_open function just returns -1 for everything:
+
+   ...
+    return 0;
+ fail:
+    qemu_free(s->l1_backup_table);
+    qemu_free(s->l1_table);
+    qemu_free(s->l2_cache);
+    return -1;
+}
+
+and by coincidence, '1 == EPERM'.  There are ~4 codepaths in vmdk_open that could fail, the VMDK magic check and then a couple of reads of metadata
+
+There is hope:
+http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg03130.html
+http://lists.gnu.org/archive/html/qemu-devel/2011-06/threads.html#00033
+
+The vmdk from "Export as OVF..." doesn't work.
+# qemu-img convert -O raw esx4.1-rhel5.7-i386-disk1.vmdk test-vmdk.raw
+qemu-img: Could not open 'esx4.1-rhel5.7-i386-disk1.vmdk'
+qemu-img: Could not open 'esx4.1-rhel5.7-i386-disk1.vmdk'
+
+I copied a vmdk file from ESX storage directly,and then use qemu-img to convert it to raw,it works.
+# qemu-img convert -O raw esx4.1-rhel5.7-i386-flat.vmdk test-vmdk.raw
+# ll test-vmdk.raw 
+-rw-r--r--. 1 root root 8589934592 Feb 17 16:58 test-vmdk.raw
+
+(In reply to comment #11)
+> I copied a vmdk file from ESX storage directly,and then use qemu-img to convert
+> it to raw,it works.
+> # qemu-img convert -O raw esx4.1-rhel5.7-i386-flat.vmdk test-vmdk.raw
+> # ll test-vmdk.raw 
+> -rw-r--r--. 1 root root 8589934592 Feb 17 16:58 test-vmdk.raw
+
+*-flat.vmdk files are not VMDK.  They are just raw files
+which happen to have a .vmdk extension.  So this doesn't
+really prove anything.
+
+This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
+
+This bug has lingered for forever, so I don't think tracking this in Fedora is going to solve much.
+
+Rich, if you can still reproduce this with qemu.git, I'd recommend filing an upstream bug and publishing a reproducer image like you did before.
+
diff --git a/results/classifier/108/other/906 b/results/classifier/108/other/906
new file mode 100644
index 000000000..ef957d24e
--- /dev/null
+++ b/results/classifier/108/other/906
@@ -0,0 +1,16 @@
+other: 0.675
+performance: 0.540
+device: 0.511
+graphic: 0.483
+permissions: 0.476
+semantic: 0.382
+network: 0.258
+debug: 0.235
+vnc: 0.140
+socket: 0.125
+boot: 0.090
+PID: 0.069
+KVM: 0.041
+files: 0.038
+
+Cannot IPL this ISO image
diff --git a/results/classifier/108/other/906804 b/results/classifier/108/other/906804
new file mode 100644
index 000000000..15f7a20db
--- /dev/null
+++ b/results/classifier/108/other/906804
@@ -0,0 +1,62 @@
+other: 0.757
+KVM: 0.586
+graphic: 0.522
+debug: 0.504
+vnc: 0.491
+performance: 0.487
+permissions: 0.465
+semantic: 0.460
+device: 0.455
+files: 0.430
+PID: 0.415
+socket: 0.399
+boot: 0.376
+network: 0.326
+
+SIGSEGV using sheepdog
+
+While doing a mkfs on a Sheepdog volume attached inside a VM, qemu-kvm segfaults:
+
+
+Program received signal SIGSEGV, Segmentation fault.
+aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784
+784	/build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c: No such file or directory.
+	in /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c
+(gdb) bt
+#0  aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784
+#1  0x00007effed02b7bb in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/coroutine-ucontext.c:125
+#2  0x00007effe89e4d60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
+#3  0x00007fff90ed7fd0 in ?? ()
+#4  0x0000000000000000 in ?? ()
+(gdb) bt full
+#0  aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784
+        rsp = {proto_ver = 8 '\b', opcode = 8 '\b', flags = 61231, epoch = 32511, id = 4023393600, data_length = 32511, result = 4022027568, copies = 32511, pad = {3902624371, 32511, 4022027680, 32511, 4022027680, 32511}}
+        s = <optimized out>
+        fd = <optimized out>
+        aio_req = <optimized out>
+        acb = <optimized out>
+        idx = 139637703787936
+#1  0x00007effed02b7bb in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/coroutine-ucontext.c:125
+        self = 0x7effefbb45a0
+        co = 0x7effefbb45a0
+#2  0x00007effe89e4d60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
+No symbol table info available.
+#3  0x00007fff90ed7fd0 in ?? ()
+No symbol table info available.
+#4  0x0000000000000000 in ?? ()
+No symbol table info available.
+(gdb)  info threads
+  Id   Target Id         Frame 
+  12   Thread 0x7eff4d3ea700 (LWP 10461) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
+  11   Thread 0x7eff4c3e8700 (LWP 10460) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
+  9    Thread 0x7eff49be3700 (LWP 10442) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
+  8    Thread 0x7eff4a3e4700 (LWP 10441) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
+  7    Thread 0x7eff493e2700 (LWP 10440) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
+  6    Thread 0x7effd2741700 (LWP 10270) "kvm" 0x00007effe8a71407 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
+* 1    Thread 0x7effecf39900 (LWP 10267) "kvm" aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784
+
+I think this is fixed with http://patchwork.ozlabs.org/patch/138719/
+
+
+The fix mentioned in comment #1 has been included long ago (commit ID 6d1acda8f16d1f2d0b05cf), so marking this ticket as "Fix released" now.
+
diff --git a/results/classifier/108/other/906864 b/results/classifier/108/other/906864
new file mode 100644
index 000000000..fa38efd09
--- /dev/null
+++ b/results/classifier/108/other/906864
@@ -0,0 +1,35 @@
+device: 0.732
+performance: 0.665
+graphic: 0.645
+semantic: 0.418
+other: 0.294
+PID: 0.172
+permissions: 0.153
+boot: 0.140
+debug: 0.132
+KVM: 0.128
+socket: 0.106
+network: 0.092
+files: 0.031
+vnc: 0.029
+
+Always mouse grabbing with -usbdevice tablet
+
+version: QEMU emulator version 1.0 (qemu-kvm 1.0)
+             QEMU emulator version 1.0 (qemu 1.0)
+             (source builds)
+os: archlinux x86-64
+last working version: qemu-kvm 0.15.1
+
+commandline: each with "-usb -usbdevice tablet" and sdl output 
+
+expected behavior:  mouse gets grabbed only by forcing it (pressing release/grab-combination (CTRL-ALT))
+
+actual behavior:
+When moving the mouse over the window it gets instantly grabbed, so i cannot use window-manager-specific hotkeys anymore.  After pressing the release combination every mouse movement over or within the window will grab the mouse again. 
+I have tried this with several vga types and window managers: no difference
+
+Seems to work for me with the latest version of QEMU. Can you still reproduce it with the latest version?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/907 b/results/classifier/108/other/907
new file mode 100644
index 000000000..e991c5e78
--- /dev/null
+++ b/results/classifier/108/other/907
@@ -0,0 +1,22 @@
+boot: 0.881
+graphic: 0.767
+device: 0.736
+files: 0.722
+other: 0.674
+network: 0.556
+PID: 0.491
+debug: 0.489
+socket: 0.419
+semantic: 0.407
+performance: 0.388
+permissions: 0.228
+vnc: 0.207
+KVM: 0.136
+
+qemu-system-x86_64 -blockdev fails with "CURL: Error opening file" when supplied url of ISO file
+Steps to reproduce:
+1. Run: qemu-system-x86_64 -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true
+
+The command returns error: qemu-system-x86_64: -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true,discard=unmap: CURL: Error opening file:
+Additional information:
+This bug is not present in qemu 6.1.0, it surfaced with an update to 6.2.0
diff --git a/results/classifier/108/other/907063 b/results/classifier/108/other/907063
new file mode 100644
index 000000000..442ed0e3a
--- /dev/null
+++ b/results/classifier/108/other/907063
@@ -0,0 +1,74 @@
+permissions: 0.818
+other: 0.769
+semantic: 0.687
+graphic: 0.623
+debug: 0.567
+device: 0.565
+network: 0.489
+PID: 0.470
+performance: 0.459
+vnc: 0.438
+boot: 0.402
+KVM: 0.401
+socket: 0.378
+files: 0.338
+
+Error reading VMDK4 with footer instead of header
+
+VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END
+"). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file.
+
+I have regression-tested this with various OVAs exported from VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were unable to import any compressed VMDKs with a footer. It now works on all the ones I have. 
+
+bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ *before* rgd_offset. I was only able to get VMDK conversion to work by switching the order back to that specified by VMWare and previously used by QEMU. I don't know what VMDK this commit is referring to, so I can't test to see if I've broken it. :(
+
+I will submit this patch to the mailing list if I get a chance, but I'm also uploading it here so I don't lose it.
+
+
+
+On Tue, Dec 20, 2011 at 8:53 PM, bbgordonn <email address hidden> wrote:
+> Public bug reported:
+>
+> VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END
+> "). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file.
+>
+> I have regression-tested this with various OVAs exported from
+> VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were
+> unable to import any compressed VMDKs with a footer. It now works on all
+> the ones I have.
+>
+> bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset
+> and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec
+> from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_
+> *before* rgd_offset. I was only able to get VMDK conversion to work by
+> switching the order back to that specified by VMWare and previously used
+> by QEMU. I don't know what VMDK this commit is referring to, so I can't
+> test to see if I've broken it. :(
+>
+> I will submit this patch to the mailing list if I get a chance, but I'm
+> also uploading it here so I don't lose it.
+>
+> ** Affects: qemu
+>     Importance: Undecided
+>         Status: New
+>
+> --
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/907063
+
+Thanks for reporting this.  I have CCed Fam who worked on VMDK this summer.
+
+Please submit patches to the mailing list according to the guidelines here:
+
+http://wiki.qemu.org/Contribute/SubmitAPatch
+
+Stefan
+
+
+Looks like something similar has been commited here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=65bd155c7356d448ffee7
+So is this problem fixed nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/909 b/results/classifier/108/other/909
new file mode 100644
index 000000000..7c0a472c5
--- /dev/null
+++ b/results/classifier/108/other/909
@@ -0,0 +1,26 @@
+graphic: 0.825
+device: 0.761
+other: 0.564
+files: 0.401
+socket: 0.377
+semantic: 0.323
+network: 0.283
+vnc: 0.262
+permissions: 0.238
+performance: 0.236
+boot: 0.233
+PID: 0.222
+debug: 0.150
+KVM: 0.006
+
+qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries
+Description of problem:
+**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.**
+
+Trying to chroot into a mips n32 installation fails with 
+```
+/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data
+```
+however, bash, libc.so.6, and qemu all exist and have the proper abi
+
+The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware.