1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
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.]
|