qemu-i386-user on ARM host: wine hangs/spins when trying to run anything

Bug #902413 reported by Pierre-Loup A. Griffais on 2011-12-10
This bug affects 9 people
Affects Status Importance Assigned to Milestone
wine (Gentoo Linux)

Bug Description

With qemu built from git from 217bfb445b54db618a30f3a39170bebd9fd9dbf2 and configured with './configure --target-list=i386-linux-user --static --interp-prefix=/home/pgriffais/natty-i386/', trying to run wine 1.3.15 from an Ubuntu 11.04 chroot results in hangs. If I run an i386 emulated wineserver, wineserver hangs in:

0x600c7f8c in read () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
 in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0 0x600c7f8c in read () at ../sysdeps/unix/syscall-template.S:82
#1 0x6004a316 in read (cpu_env=0x622c3ee8, num=3, arg1=6, arg2=1121255519,
    arg3=1, arg4=134875664, arg5=1, arg6=1121255528, arg7=0, arg8=0)
    at /usr/include/bits/unistd.h:45
#2 do_syscall (cpu_env=0x622c3ee8, num=3, arg1=6, arg2=1121255519, arg3=1,
    arg4=134875664, arg5=1, arg6=1121255528, arg7=0, arg8=0)
    at /home/ubuntu/src/qemu/linux-user/syscall.c:4691
#3 0x600262f0 in cpu_loop (env=0x622c3ee8)
    at /home/ubuntu/src/qemu/linux-user/main.c:321
#4 0x60026bbc in main (argc=<value optimized out>,
    argv=<value optimized out>, envp=<value optimized out>)
    at /home/ubuntu/src/qemu/linux-user/main.c:3817

While wine hangs in:

0x600c84ac in recvmsg () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
 in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0 0x600c84ac in recvmsg () at ../sysdeps/unix/syscall-template.S:82
#1 0x60041c4e in do_sendrecvmsg (fd=4, target_msg=<value optimized out>,
    flags=1073741824, send=0)
    at /home/ubuntu/src/qemu/linux-user/syscall.c:1834
#2 0x600497ec in do_socketcall (cpu_env=<value optimized out>, num=102,
    arg1=17, arg2=1122504544, arg3=2076831732, arg4=1122504568,
    arg5=2076942688, arg6=1122504888, arg7=0, arg8=0)
    at /home/ubuntu/src/qemu/linux-user/syscall.c:2235
#3 do_syscall (cpu_env=<value optimized out>, num=102, arg1=17,
    arg2=1122504544, arg3=2076831732, arg4=1122504568, arg5=2076942688,
    arg6=1122504888, arg7=0, arg8=0)
    at /home/ubuntu/src/qemu/linux-user/syscall.c:6085
#4 0x600262f0 in cpu_loop (env=0x622c3f08)
    at /home/ubuntu/src/qemu/linux-user/main.c:321
#5 0x60026bbc in main (argc=<value optimized out>,
    argv=<value optimized out>, envp=<value optimized out>)
    at /home/ubuntu/src/qemu/linux-user/main.c:3817

However if I build wineserver 1.3.15 natively for ARM and run it on the host while wine is emulated, I get the following:

root@tiberiusstation:/home/ubuntu# ./natty-i386/usr/bin/wine notepad
Unsupported ancillary data: 1/2
Unsupported ancillary data: 1/2
Unsupported ancillary data: 1/2
err:process:__wine_kernel_init boot event wait timed out

I assume the last one is due to wineboot.exe hanging. The main wine process hangs in there:

cg_temp_new_internal_i32 (temp_local=<value optimized out>)
    at /home/ubuntu/src/qemu/tcg/tcg.c:483
483 }
(gdb) bt
#0 tcg_temp_new_internal_i32 (temp_local=<value optimized out>)
    at /home/ubuntu/src/qemu/tcg/tcg.c:483
#1 0x60052ac6 in tcg_temp_new_i32 (val=6)
    at /home/ubuntu/src/qemu/tcg/tcg.h:442
#2 tcg_const_i32 (val=6) at /home/ubuntu/src/qemu/tcg/tcg.c:530
#3 0x6005ef0c in tcg_gen_shri_i32 (ot=2, op1=2, op2=7, is_right=1,
    is_arith=0, s=<value optimized out>)
    at /home/ubuntu/src/qemu/tcg/tcg-op.h:605
#4 gen_shift_rm_im (ot=2, op1=2, op2=7, is_right=1, is_arith=0,
    s=<value optimized out>)
    at /home/ubuntu/src/qemu/target-i386/translate.c:1514
#5 0x6006df90 in gen_shifti (s=0xbefea970, pc_start=<value optimized out>)
    at /home/ubuntu/src/qemu/target-i386/translate.c:1946
#6 disas_insn (s=0xbefea970, pc_start=<value optimized out>)
    at /home/ubuntu/src/qemu/target-i386/translate.c:5397
#7 0x60091758 in gen_intermediate_code_internal (env=0x625656f8,
    tb=0x402cdf48) at /home/ubuntu/src/qemu/target-i386/translate.c:7825
#8 gen_intermediate_code_pc (env=0x625656f8, tb=0x402cdf48)
    at /home/ubuntu/src/qemu/target-i386/translate.c:7896
#9 0x60054bf2 in cpu_restore_state (tb=0x402cdf48, env=0x62565690,
    searched_pc=1617393812) at /home/ubuntu/src/qemu/translate-all.c:126
#10 0x60091d9e in handle_cpu_signal (host_signum=<value optimized out>,
    pinfo=<value optimized out>, puc=0xbefeab70)
    at /home/ubuntu/src/qemu/user-exec.c:117
#11 cpu_x86_signal_handler (host_signum=<value optimized out>,
    pinfo=<value optimized out>, puc=0xbefeab70)
    at /home/ubuntu/src/qemu/user-exec.c:458
#12 0x6003c764 in host_signal_handler (host_signum=11, info=0xbefeaaf0,
    puc=<value optimized out>)
    at /home/ubuntu/src/qemu/linux-user/signal.c:492
#13 <signal handler called>
#14 0x60677894 in static_code_gen_buffer ()
#15 0x6000a260 in cpu_x86_exec (env=0x0)
    at /home/ubuntu/src/qemu/cpu-exec.c:566
#16 0x68953200 in ?? ()
#17 0x68953200 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?

Running the same version of wine through qemu-user-i386 running on an i386 host works fine with both wineserver and wine being emulated; that's the result I'm trying to achieve.

Forgot to mention I had applied this patch also. Without this, emulated bash can't even start anything.

Peter Maydell (pmaydell) wrote :

Multithreaded programs don't work (reliably) in x86 user emulation mode. This is a known (longstanding) bug.
ARM hosts are also currently known to have problems (as stated in the qemu 1.0 release notes).

Thanks for your quick reply, Peter.

Are there more specific bug entries tracking both the general problems you're talking about that I could monitor for progress, or any pointers on the direction to go to improve the situation?

Peter Maydell (pmaydell) wrote :

For ARM hosts (mostly being worked on):

For x86 multithreaded (mostly *not* being worked on):

At the moment the target-i386 front end is in status "Odd Fixes", which means it may get easy bug fixes but is unlikely to get enough attention to fix trickier problems like threading support.

Understood, thanks a lot for the pointers. From a quick skim it doesn't look like I'm directly running into any of these ARM host issues (yet). I'm hopeful that the i386 target will get increasing attention in the future as ARM devices get more widespread after x86 was the standard for so long. Out of curiosity, is the amd64 target in any better shape?

Peter Maydell (pmaydell) wrote :

QEMU has no separate amd64 target; it is all handled by target-i386.

leeseungman (forsucess1) on 2012-12-28
Changed in qemu:
assignee: nobody → leeseungman (forsucess1)

with QEMU expected to turn ver 2.0 in april I wonder this bug is still forgotten.
Bugs list on Peter Maydell's post and Dan Kegel's have fixes commited, and I see there are alternative patches from http://patchwork.ozlabs.org/patch/45206/ and http://repo.or.cz/w/qemu/agraf.git linked from http://wiki.winehq.org/ARM

Marina Kovalevna (ciiiiipa) wrote :

Good question, any news please?

Nathan Shearer (6-mail-f) wrote :

I just tried running x86 windows program, on x86 wine, on qemu-i386, all on an arm host. I am also experiencing a hung wine and wineserver. Was this bug ever fixed?

Peter Maydell (pmaydell) wrote :

We're actively working on improving QEMU's support for multithreaded guest programs in linux-user, but those changes are not yet complete.

Henry Wertz (hwertz10) wrote :

I'm running qemu-2.5.0 on ARM, and wine (wine-1.7, 1.8, wine-staging) all seem to behave similarly; rename the winepreloader and you'll be able to run winecfg, notepad run, a few installers do run and the software runs. But Windows software LOVES using threads so you rapidly end up with some other installer firing off at least 6 or 8 threads and things break down. qemu-2.6.0, wine doesn't start.

This is a tricky problem; current qemu has I/O threads, main thread (which is not fully thread-safe, this is what's being worked on...) and user threads; things work as long as some non-thread-safe part is not exercised too hard.

I was beginning to despair, but there actually appears to be intense development activity on qemu branches on 3 fronts --

1) general qemu-multithreading (to make kvm qemu more scalable, let qemu-system-xxx actually use more than one CPU core, instead of simulating x CPU cores on one physical core as it does now). But this also involves fixing thread-safety problems in qemu that affect qemu-user-xxxx.

2) Specifically getting qemu-i386-static threading work on ARM (a few ARM vendors.)

3) Get qemu-arm-static threading working on x86.

It looks like this should get into qemu in due time, maybe it'd be appropriate to call it qemu-3.0 at that point.

Riku Voipio (riku-voipio) wrote :

You might want to retry wine with qemu-i386-static again now with qemu 2.7, which has a major thread/signal rework done.

Nathan Shearer (6-mail-f) wrote :

Running SkiFree (1.04 x32) on wine (1.8.3 x32) installed in a gentoo i686 chroot, all running via qemu-user-i386-static 1.7.0 on a raspberry pi 2 armv7 host works. It was almost playable at 1920x1080 too!

winecfg worked, notepad.exe worked, and SkiFree worked too.

Thomas Huth (th-huth) wrote :

So can we close this bug now, or is there still something left to do here?

Changed in qemu:
status: New → Incomplete

A year has passed since last update by Nathan Shearer, but status is labeled 'incomplete'. Please check if it's solved with wine 3.0

Thomas Huth (th-huth) wrote :

There hasn't been an update within a year, so let's assume this bug has been fixed.

Changed in qemu:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers