Re: [Qemu-devel] [Bug 1158912] Re: QEMU Version 1.4.0 - SLIRP hangs VM

[Stefan Hajnoczi <stefanha@gmail.com>]

On Mon, Mar 25, 2013 at 08:57:46PM -0000, Kenneth Salerno wrote:
> Result of git bisect:
> 
> commit 837d1f978224f7e7b020c71ffb10b291952cc596
> Merge: a6fc23e 2b35e93
> Author: Blue Swirl <blauwirbel@gmail.com>
> Date:   Sat Jan 12 12:46:57 2013 +0000
> 
>     Merge branch 's390-reorg' of git://repo.or.cz/qemu/rth
>     
>     * 's390-reorg' of git://repo.or.cz/qemu/rth: (149 commits)
>       target-s390: Claim maintainership
>       target-s390: Use noreturn for exception and load_psw
>       target-s390: Use TCG_CALL_NO_WG for misc helpers
>       target-s390: Use TCG_CALL_NO_WG for integer helpers
>       target-s390: Use TCG_CALL_NO_WG for floating-point helpers
>       target-s390: Use TCG_CALL_NO_WG for memory helpers
>       target-s390: Perform COMPARE AND SWAP inline
>       target-s390: Optimize get_address
>       target-s390: Optimize ADDC/SUBB
>       target-s390: Optimize ADDU/SUBU CC testing
>       target-s390: Tidy comparisons
>       target-s390: Optmize emitting discards
>       target-s390: Optimize XC
>       target-s390: Fix cpu_clone_regs
>       target-s390: Implement LOAD/SET FP AND SIGNAL
>       target-s390: Implement SET ROUNDING MODE
>       target-s390: Use uint64_to_float128
>       target-s390: Implement LCDFR
>       target-s390: Check insn operand specifications
>       target-s390: Implement CPSDR
>       ...
> 
> 
> There are 1,484 files affected by this commit - Is there a way I can narrow this down even further within this commit?

Looks like git-bisect(1) got stuck on a merge - maybe it followed the
wrong parent commit.

Please manually check whether a6fc23e hangs:

  $ cd qemu
  $ git checkout a6fc23e
  $ ...build and test hang...

If a6fc23e is indeed broken then you can start a new git bisect between
v1.3.0 (good) and a6fc23e (bad).

If a6fc23e is not broken then that really suggestes the 's390-reorg'
merge broke SLIRP, which is unlikely.

Hope this helps.

Regarding the QEMU backtrace, it shows SLIRP is waiting in a blocking
accept() call:

Thread 1 (Thread 416.0x228):
#0  0x7c90e514 in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c90df5a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x71a5402b in ?? () from /cygdrive/c/WINDOWS/system32/mswsock.dll
#3  0x71a6b858 in StartWsdpService ()
   from /cygdrive/c/WINDOWS/system32/mswsock.dll
#4  0x71ac0e46 in WSAAccept () from /cygdrive/c/WINDOWS/system32/WS2_32.dll
#5  0x71ac1057 in accept () from /cygdrive/c/WINDOWS/system32/WS2_32.dll
#6  0x0057caff in tcp_connect (inso=0x1c07c68) at slirp/tcp_subr.c:423
#7  0x005763d0 in slirp_select_poll (readfds=0xa19a40 <rfds>, 
    writefds=0xa19b60 <wfds>, xfds=0xa19c80 <xfds>, select_error=0)
    at slirp/slirp.c:485
#8  0x0053688b in main_loop_wait (nonblocking=0) at main-loop.c:419
#9  0x005a8333 in main_loop () at vl.c:2001
#10 0x005af134 in qemu_main (argc=34, argv=0x1c08048, envp=0x0) at vl.c:4326
#11 0x005a4d84 in SDL_main (argc=34, argv=0x1c08048) at vl.c:102
#12 0x0073a951 in console_main ()
#13 0x00000022 in ?? ()
#14 0x01c08048 in ?? ()

Since the main loop holds the global mutex the guest is unable to make
progress and appears to hang.

Stefan