qemu-system-arm hangs at start on OS X
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Both from release 2.1.2 and built from a recent source, qemu-system-arm seems to hang immediately after starting up, never getting to the point of actually booting.
I've tried qemu-system-mipsel with another image and it worked fine, so this seems to be specific to the ARM runtime. I've tried two different ARM kernels, and I also ran into this with QEMU 2.1.2 release, installed from a bottle using homebrew.
Host: Mac OS X 10.9.5 (Darwin Kernel Version 13.4.0)
QEMU version: built from HEAD@ab0302ee76
Build command: ./configure --enable-cocoa --target-
Run command:
qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 256 -sd disk.img -net nic,macaddr=
I also tried this, with a different kernel & root:
qemu-system-arm -kernel zImage -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -hda rootfs-
Thread dump:
(lldb) thread list
Process 34364 stopped
* thread #1: tid = 0x135966, 0x00007fff89f4a746 libsystem_
thread #2: tid = 0x13598b, 0x00007fff89f4ae6a libsystem_
thread #3: tid = 0x13598c, 0x00007fff89f4b662 libsystem_
thread #7: tid = 0x1359b2, 0x00007fff89f4acc2 libsystem_
thread #9: tid = 0x1359c1, 0x00000001091bc5d9
thread #11: tid = 0x1359cc, 0x00007fff89f4a716 libsystem_
thread #12: tid = 0x1359da, 0x00007fff89f46a1a libsystem_
-------
* thread #1: tid = 0x135966, 0x00007fff89f4a746 libsystem_
* frame #0: 0x00007fff89f4a746 libsystem_
frame #1: 0x00007fff8e05f779 libsystem_
frame #2: 0x000000010033e8e9 qemu-system-
frame #3: 0x000000010002d742 qemu-system-
frame #4: 0x00000001002c84b5 qemu-system-
frame #5: 0x00000001002c83f6 qemu-system-
frame #6: 0x000000010014961a qemu-system-
frame #7: 0x00000001001495d1 qemu-system-
frame #8: 0x000000010029b45e qemu-system-
Do these guest images and command lines work on Linux QEMU? (The most common cause of "nothing happens" is "wrong kernel for this board" or similar misconfiguration, where QEMU is correctly emulating a crashed guest that never made any output...)