1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I'm trying to figure out whether this QEMU issue is user-mode or system-mode related. Let me start by understanding the problem.
The user is reporting that when they run qemu-system-arm on macOS, it hangs at startup. They've tried both a pre-built version and one compiled from source, but the same thing happens. However, using qemu-system-mipsel works fine, so it's specific to ARM. The host OS is Mac OS X 10.9.5, and they're using QEMU built with --enable-cocoa.
Looking at the run command, they're using different machines like vexpress-a9 and versatilepb, which are system emulations. They also mention that both user and kernel images cause the hang. The thread dump shows that the main thread is stuck in a mutex wait. The stack trace points to qemu_mutex_lock in the main loop.
In the thread list, several threads are involved, including one named 'com.apple.audio.IOThread.client', which might be related to audio processing but isn't the main issue here. The main problem seems to be with QEMU's own threading and mutex handling in the main loop.
QEMU's main loop is responsible for emulating the CPU and handling other devices. If it hangs there, it's likely due to an issue within QEMU's core, possibly related to how it handles ARM emulation or its threading model on macOS.
User-mode issues typically relate to applications running inside the emulator, while system-mode involves lower-level components like hardware emulation, devices, and OS interactions. Since this hang occurs at a low level during startup and is specific to the ARM target, it seems more systemic than application-related.
Additionally, the stack trace points to functions in cpus.c and main-loop.c, which are part of QEMU's core system-mode operations. So, this issue is likely related to how QEMU initializes or handles the ARM architecture on macOS at a lower level.
</think>
system
|