debug: 0.827
other: 0.789
socket: 0.784
performance: 0.783
device: 0.776
network: 0.775
graphic: 0.773
semantic: 0.762
permissions: 0.762
PID: 0.747
boot: 0.706
vnc: 0.668
files: 0.662
KVM: 0.568

netlink broken on big-endian mips

Debian QEMU version 2.7.0, but the bug also appears in current git master (commit c36ed06e9159)

As the summary says, netlink is completely broken on big-endian mips running qemu-user.

Running 'ip route' from within a Debian chroot with QEMU simply hangs. Running amd64 strace on qemu-mips-static shows that it's waiting for a netlink response from the kernel which never comes.

[...]
[pid 11249] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3
[pid 11249] setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
[pid 11249] setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
[pid 11249] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
[pid 11249] getsockname(3, {sa_family=AF_NETLINK, nl_pid=11249, nl_groups=00000000}, [12]) = 0
[pid 11249] time([1479745823])          = 1479745823
[pid 11249] sendto(3, {{len=671088640, type=0x1a00 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_MULTI|0x100, seq=539046744, pid=0}, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\0\0\1"}, 40, 0, NULL, 0) = 40
[pid 11249] recvmsg(3,

Notice the len in the buffer passed to the kernel is 0x28000000 which looks byteswapped.

Removing the call to fd_trans_unregister in the NR_socket syscall in do_syscall fixes this for me, but I don't understand why the fd translation was immediately unregistered after being registered just before in do_socket - presumably it was added for a reason.

--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -9331,7 +9331,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 #ifdef TARGET_NR_socket
     case TARGET_NR_socket:
         ret = do_socket(arg1, arg2, arg3);
-        fd_trans_unregister(ret);
         break;
 #endif
 #ifdef TARGET_NR_socketpair

I also notice fd_trans_unregister does not appear in the socketcall implementation which seems like an oversight.

Same here. While running qemu-debootstrap using Debian qemu 2.7, debootstrap hangs on groupadd calls. Reproduction on amd64 host, running jessie, on a failed qemu-debootstrap but sufficiently working jessie mips chroot. See attached strace of groupadd. Problem reproduces with compiled qemu from git master, commit 00227fefd2059464cd2f59aed29944874c630e2f.

...
[pid 31008] socket(PF_NETLINK, SOCK_RAW, NETLINK_AUDIT) = 3
[pid 31008] fcntl(3, F_SETFD, FD_CLOEXEC) = 0
...
[pid 31008] sendto(3, "\0\0\0x\4\\\0\5\0\0\0\1\0\0\0\0op=adding group "..., 120, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 120
[pid 31008] ppoll([{fd=3, events=POLLIN}], 1, {0, 500000000}, NULL, 0) = 0 (Timeout)
[pid 31008] recvfrom(3, 0x7facef9e1504, 8988, 66, 0x7fff0138c9b0, 0x7fff0138c9f4) = -1 EAGAIN (Resource temporarily unavailable)
[pid 31008] ppoll([{fd=3, events=POLLIN}], 1, {0, 500000000}, NULL, 0) = 0 (Timeout)
[pid 31008] recvfrom(3, 0x7facef9e1504, 8988, 66, 0x7fff0138c9b0, 0x7fff0138c9f4) = -1 EAGAIN (Resource temporarily unavailable)
...etc ... etc...

Strace jessie mips groupadd.

Patch applied by James works for me as well. Dropping a qemu-user static binary from Debian qemu 2.1 into the mips chroot can also be used as workaround.

This has been fixed by 40493c5f2b0f124c9b2581e539bba14522e51269, which is exactly the same diff as given here.