diff options
Diffstat (limited to 'results/classifier/118/all/1498144')
| -rw-r--r-- | results/classifier/118/all/1498144 | 180 |
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.] + |