[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1320030] Re: Qemu 2.0.0 with display=gtk hangs
From: |
tadawson |
Subject: |
[Qemu-devel] [Bug 1320030] Re: Qemu 2.0.0 with display=gtk hangs |
Date: |
Wed, 21 May 2014 07:12:34 -0000 |
Testing on other systems reveals that this is solid on Slackware14.1,
with it's associated libraries. Interestingly, the more heavily the
machine is loaded, the further the emulator runs prior to hanging . . .
The 1.7.1 code, compiled on an older Slackware (loosely based on 12, but
has evolved, but generally older libs) appears to work. I have changed
out most libs that seem apparent - gtk+, vte, and a few others, as well
as compiling with slirp and aio disabled, as well as not using gthreads,
to no avail. This appears to be a race between the gtk window thread,
and qemu, but the qemu source is so large, that I have not yet been able
to find that area of the code to be able to debug deeper.
Help!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1320030
Title:
Qemu 2.0.0 with display=gtk hangs
Status in QEMU:
New
Bug description:
When qemu 2.0.0 is started, compiled with gtk, communications between
the emulator process and the gtk "wrapper" window hang, and the
emulator hangs typically before the bios finishes initializing, and if
boot menu=on is selected, even if it gets to this point, keyboard
input is not accepted to the emulator process. Switching to the
session console in the window header yeilds a fully functional console
with zero input issues, indicating that the overall process is getting
keyboard data, just not cleanly passing it to the emulator. A
"system_reset" in the console will typically result in a bit more
execution of the emulator, and then a subsequent hang at a later
point. When the hang occurs, CPU useage pegs at 100%, and when I
strace the process, I get typically 20,000 lines in the trace in about
2 seconds, 90% of which is repetitive:
read(5, 0x7fff965c4df0, 16) = -1 EAGAIN (Resource temporarily
unavai
lable)
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
read(9, "\1\0\0\0\0\0\0\0", 512) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
un
available)
ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11,
eve
nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17,
events=POLL
IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}], 8, {0, 0}, NULL, 8) = 2
([{f
d=5, revents=POLLIN}, {fd=4, revents=POLLIN}], left {0, 0})
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
read(4, "\1\0\0\0\0\0\0\0", 512) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
un
available)
futex(0x7f562ce32e40, FUTEX_WAKE_PRIVATE, 1) = 1
ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11,
eve
nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17,
events=POLL
IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}, {fd=14, events=POLLIN},
{fd=1
6, events=POLLIN}, {fd=12, events=POLLIN}], 11, {0, 20060537}, NULL, 8) = 1
([{f
d=5, revents=POLLIN}], left {0, 20056426})
read(5, "\10\0\0\0\0\0\0\0", 16) = 8
recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
un
available)
futex(0x7f562ce32e40, FUTEX_WAKE_PRIVATE, 1) = 1
ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11,
eve
nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17,
events=POLL
IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}, {fd=14, events=POLLIN},
{fd=1
6, events=POLLIN}, {fd=12, events=POLLIN}], 11, {0, 19878122}, NULL, 8) = 1
([{f
d=9, revents=POLLIN}], left {0, 19672563})
futex(0x7f562ce32e40, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
tempora
rily unavailable)
read(5, 0x7fff965c4df0, 16) = -1 EAGAIN (Resource temporarily
unavai
lable)
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
read(9, "\1\0\0\0\0\0\0\0", 512) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
un
available)
ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11,
eve
nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17,
events=POLL
IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}], 8, {0, 0}, NULL, 8) = 2
([{f
d=5, revents=POLLIN}, {fd=4, revents=POLLIN}], left {0, 0})
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
read(4, "\1\0\0\0\0\0\0\0", 512) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
un
available)
futex(0x7f562ce32e40, FUTEX_WAKE_PRIVATE, 1) = 1
ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11,
eve
nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17,
events=POLL
IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}, {fd=14, events=POLLIN},
{fd=1
6, events=POLLIN}, {fd=12, events=POLLIN}], 11, {0, 18960120}, NULL, 8) = 1
([{f
d=5, revents=POLLIN}], left {0, 18956018})
read(5, "\10\0\0\0\0\0\0\0", 16) = 8
recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
un
available)
futex(0x7f562ce32e40, FUTEX_WAKE_PRIVATE, 1) = 1
ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11,
eve
nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17,
events=POLL
IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}, {fd=14, events=POLLIN},
{fd=1
6, events=POLLIN}, {fd=12, events=POLLIN}], 11, {0, 18778228}, NULL, 8) = 1
([{f
d=9, revents=POLLIN}], left {0, 18580700})
The host system has an average load as of this test of .38, and is 8 2.33GHz
Xeon cores, and 8GB RAM with a 3.10.17 kernel, and nowhere near swapping . . .
(Distro is slackware 14.1, FWIW)
The above was generated with the command:
strace qemu-system-x86_64 linux-0.2.img -cpu Westmere -k en-us
-machine accel=kvm
This occurs with any cpu, with or without the "-k" (I had seen some
reports that some probs in the GTK build were resolved by this option
- no joy here) and with and without the "accell=kvm" (again tried
based on other found bugs/solutions.).
Thus:
strace qemu-system-x86_64 linux0.2.img
Behaves identically, and disabling serial and parallel also has zero
impact. If I run with "-display=sdl" then the image boots perfects,
as is also the case if I build qemu with --disable-gtk.
This situation is identical on a remote display, and also in 1.7.1.
No variation in current git build, uploaded 05/15/2014, 18:58 CST . .
.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1320030/+subscriptions
- [Qemu-devel] [PATCH 0/9] POWER8 patches, Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 1/9] target-ppc: Rename MMCR0/1 contants, Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 4/9] target-ppc: Refactor init_proc_POWER8, Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 5/9] target-ppc: Add POWER8 SPRs, Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 8/9] spapr_hcall: Split h_set_mode(), Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 2/9] target-ppc: Refactor init_proc_POWER7, Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 9/9] spapr_hcall: Add address-translation-mode-on-interrupt resource in H_SET_MODE, Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 6/9] target-ppc: Enable PPR and VRSAVE SPRs migration, Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 7/9] KVM: target-ppc: Enable transactional state migration, Alexey Kardashevskiy, 2014/05/21
- [Qemu-devel] [PATCH 3/9] target-ppc: Add POWER7 SPRs, Alexey Kardashevskiy, 2014/05/21