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 related to user-mode or system-mode. Let's break down the information given.
The user is using a specific git commit of QEMU, version v2.7.0-rc4, with certain configuration options. Notably, they have `--enable-linux-user` and disabled several other features like system mode, tools, guest agent, etc. So from the start, it seems they're running in user-mode because they've enabled it and disabled system.
The command line shows they're using `/usr/bin/qemu-arm`, which I know is typically used for running user-mode applications under emulation. The arguments passed suggest compiling something inside a chroot environment, which makes sense in user-mode where you emulate an ARM environment on their x86 host.
Looking at the backtrace from GDB, it shows that QEMU is hanging in `pselect` syscall. The stack trace goes through functions like `safe_pselect6`, `do_select`, and `do_syscall`. These are all part of handling system calls within user-mode emulation. So the issue seems to be happening when QEMU is emulating a select/poll system call for the guest program.
The strace logs also show that the process 1823 (which is likely the QEMU instance) is stuck in `pselect6` with no activity, indicating it's waiting on some file descriptors but isn't getting any events. This suggests that within the emulated environment, a system call isn't completing as expected.
Considering reproducibility is low—only one occurrence out of many trials—it might be related to timing or resource contention specific to user-mode emulation. Since they're compiling different sources each time in a chroot, it's possible that certain conditions trigger this hang when running specific tasks within the emulated environment.
Putting it all together: The issue occurs during user-mode emulation, specifically while handling system calls like `pselect`. There's no mention of hardware or device emulation, which are more system-mode concerns. Therefore, this bug is likely related to user-mode.
</think>
user
|