add 18th iteration of classifier

1 files changed, 180 insertions, 0 deletions

diff --git a/results/classifier/118/all/1498144 b/results/classifier/118/all/1498144
new file mode 100644
index 00000000..ecabdd7c
--- /dev/null
+++ b/results/classifier/118/all/1498144
@@ -0,0 +1,180 @@
+graphic: 0.948
+register: 0.946
+permissions: 0.945
+semantic: 0.934
+debug: 0.933
+architecture: 0.932
+boot: 0.929
+peripherals: 0.926
+arm: 0.926
+performance: 0.925
+device: 0.925
+assembly: 0.922
+files: 0.904
+socket: 0.900
+PID: 0.900
+kernel: 0.897
+network: 0.881
+virtual: 0.880
+hypervisor: 0.876
+vnc: 0.869
+i386: 0.868
+TCG: 0.864
+risc-v: 0.862
+KVM: 0.855
+VMM: 0.846
+user-level: 0.841
+x86: 0.841
+ppc: 0.825
+mistranslation: 0.809
+
+ Failure booting hurd with qemu-system-i386 on ARM
+
+Trying to boot debian-hurd-20150320.img ends with:
+
+qemu-system-i386: qemu-coroutine-lock.c:91: qemu_co_queue_restart_all: Assertion `qemu_in_coroutine()' failed.
+
+Program received signal SIGABRT, Aborted.
+__libc_do_syscall ()
+    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
+44      ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
+(gdb) bt
+#0  __libc_do_syscall ()
+    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
+#1  0xb6ef8f0e in __GI_raise (sig=sig@entry=6)
+    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
+#2  0xb6efb766 in __GI_abort () at abort.c:89
+#3  0xb6ef4150 in __assert_fail_base (
+    fmt=0x1 <error: Cannot access memory at address 0x1>, 
+    assertion=0x7f89a234 "qemu_in_coroutine()", assertion@entry=0x0, 
+    file=0x7f89da58 "qemu-coroutine-lock.c", file@entry=0xb5660000 "\001", 
+    line=91, line@entry=3069931692, 
+    function=function@entry=0x7f89ab78 "qemu_co_queue_restart_all")
+    at assert.c:92
+#4  0xb6ef41e6 in __GI___assert_fail (assertion=0x0, file=0xb5660000 "\001", 
+    line=3069931692, function=0x7f89ab78 "qemu_co_queue_restart_all")
+    at assert.c:101
+#5  0x7f59a6b4 in ?? ()
+
+I was using the same setup as in Bug 893208 (i.e git checkout from 2015-09-15)
+
+On 09/21/15 21:04, PeteVine wrote:
+> Public bug reported:
+> 
+> Trying to boot debian-hurd-20150320.img ends with:
+> 
+> qemu-system-i386: qemu-coroutine-lock.c:91: qemu_co_queue_restart_all:
+> Assertion `qemu_in_coroutine()' failed.
+> 
+> Program received signal SIGABRT, Aborted.
+> __libc_do_syscall ()
+>     at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
+> 44      ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
+> (gdb) bt
+> #0  __libc_do_syscall ()
+>     at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
+> #1  0xb6ef8f0e in __GI_raise (sig=sig@entry=6)
+>     at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
+> #2  0xb6efb766 in __GI_abort () at abort.c:89
+> #3  0xb6ef4150 in __assert_fail_base (
+>     fmt=0x1 <error: Cannot access memory at address 0x1>, 
+>     assertion=0x7f89a234 "qemu_in_coroutine()", assertion@entry=0x0, 
+>     file=0x7f89da58 "qemu-coroutine-lock.c", file@entry=0xb5660000 "\001", 
+>     line=91, line@entry=3069931692, 
+>     function=function@entry=0x7f89ab78 "qemu_co_queue_restart_all")
+>     at assert.c:92
+> #4  0xb6ef41e6 in __GI___assert_fail (assertion=0x0, file=0xb5660000 "\001", 
+>     line=3069931692, function=0x7f89ab78 "qemu_co_queue_restart_all")
+>     at assert.c:101
+> #5  0x7f59a6b4 in ?? ()
+> 
+> I was using the same setup as in Bug 893208 (i.e git checkout from
+> 2015-09-15)
+> 
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+> 
+
+This backtrace is next to useless I believe, but it's not your fault. I
+think "scripts/qemu-gdb.py" might be helpful (it has a little bit of
+documentation too). See also commit 9eddd6a4.
+
+Thanks
+Laszlo
+
+
+All right, I'll rebuild and try qemu-gdb.py if still necessary.
+Do any fancy CFLAGS make a difference in performance or should they be avoided altogether on ARM?
+
+I can't get any more useful info - either the script is expecting some outdated version of python or there's simply nothing else to see cause qemu failed to start.
+
+For example:
+
+(gdb) source qemu-gdb.py
+(gdb) run
+Starting program: /usr/bin/qemu-system-i386 -m 512 -hda /media/odroid/debian-hurd-20150320.img
+
+and so on
+
+(gdb) qemu mtree
+Python Exception <class 'gdb.error'> No symbol "address_space_memory" in current context.: 
+Error occurred in Python command: No symbol "address_space_memory" in current context.
+
+As for using:
+
+qemu coroutine, I'm not sure where the pointer value should come from but feeding it a bogus one ends exactly as above.
+
+Any suggestions?
+
+On 09/23/15 17:13, PeteVine wrote:
+> I can't get any more useful info - either the script is expecting some
+> outdated version of python or there's simply nothing else to see cause
+> qemu failed to start.
+> 
+> For example:
+> 
+> (gdb) source qemu-gdb.py
+> (gdb) run
+> Starting program: /usr/bin/qemu-system-i386 -m 512 -hda /media/odroid/debian-hurd-20150320.img
+> 
+> and so on
+> 
+> (gdb) qemu mtree
+> Python Exception <class 'gdb.error'> No symbol "address_space_memory" in current context.: 
+> Error occurred in Python command: No symbol "address_space_memory" in current context.
+> 
+> As for using:
+> 
+> qemu coroutine, I'm not sure where the pointer value should come from
+> but feeding it a bogus one ends exactly as above.
+> 
+> Any suggestions?
+> 
+
+Sorry, no idea.
+
+
+I've just tried again with the latest commits - hurd boots,  hooray!
+
+Even though not related to the original issue (was also happening on i386 a few days ago), after getting to the login prompt inside hurd the keyboard doesn't work and the only clue from the kernel at boot time might be this:
+
+'Unexpected ACK from keyboard'
+
+or this:
+
+'/bin/console: could not receive return value from the daemon process: Connection timed out' 
+
+I haven't got any more info so I'm not going to open a new bug myself. Thx.
+
+Lastly, the machine 'power down' button doesn't work and a new message appeared inside hurd:
+
+'kdb: queue full'
+
+In case anyone's interested I've just discovered booting in recovery mode (root already logged in) doesn't exhibit the problem with non-working keyboard.
+
+Looking through 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.]
+