On 16 June 2015 at 11:33, Peter Maydell <peter.mayd...@linaro.org> wrote: > Pressing a key does not unwedge the test case for me.
Looking at the logs, this seems to be expected given what the guest code does with CPU #1: (the below is edited logs, created with a hacky patch I have that annotates the debug logs with CPU numbers): CPU #1: Trace 0x7f2d67afa000 [80000100] _start # we start CPU #1: Trace 0x7f2d67afc060 [8000041c] main_cpu1 # we correctly figured out we're CPU 1 CPU #1: Trace 0x7f2d67afc220 [80000448] main_cpu1 # we took the branch to 80000448 CPU #1: Trace 0x7f2d67afc220 [80000448] main_cpu1 # 8000448 is a branch-to-self, so here we stay CPU #1 never bothered to enable its GICC cpu interface, so it will never receive interrupts and will never get out of this tight loop. We get here because CPU #1 has got through main_cpu1 to the point of testing your 'release' variable before CPU #0 has got through main_cpu0 far enough to set it to 1, so it still has the zero in it that it has on system startup. If scheduling happened to mean that CPU #0 ran further through main_cpu0 before CPU #1 ran, we wouldn't end up in this situation -- you have a race condition, as I suggested. The log shows we're sat with CPU#0 fruitlessly looping on a variable in memory, and CPU#1 in this endless loop. PS: QEMU doesn't care, but your binary seems to be entirely devoid of barrier instructions, which is likely to cause you problems on real hardware. thanks -- PMM
