On 15 June 2015 at 21:03, Alex Zuepke <alexander.zue...@hs-rm.de> wrote: > Am 15.06.2015 um 20:58 schrieb Peter Maydell: >> I'm beginning to suspect that your guest code has a race >> condition in it, such that if the other CPU runs at a >> point you weren't expecting it to then you end up >> deadlocking or otherwise running into a bug in your guest. >> >> In particular, I see the emulation getting stuck even without >> this patch to arm_cpu_set_irq().
> Yes, it's a bug, sorry for that. I removed too much code to get a simple > testcase. It's stuck in the first spinlock where CPU#1 is waiting for CPU#0 > to initialize the rest of the system, and I need to WFE or YIELD here as > well. > > But this is showing the original problem again: the emulation get's stuck > spinning on CPU #1 forever, because the main loop doesn't switch to CPU #0 > voluntarily. Just press a key on the console/emulated serial line to trigger > an event to QEMU's main loop, and the testcase should continue. Pressing a key does not unwedge the test case for me. -- PMM