Comment 1 by m@capitanio.org:

I forgot to clean up the environment. It was run
with GOMAXPROCS=2.
With GOMAXPROCS=1 everything passes except the 3 epoll
cases
        netchan\
        rpc\
        websocket\
and the os test
5g -o _gotest_.5 dir_linux.go error.go env.go exec.go file.go getwd.go path.go proc.go
stat_linux.go time.go types.go  env_unix.go file_unix.go sys_linux.go exec_unix.go  
rm -f _test/os.a
gopack grc _test/os.a _gotest_.5 
--- FAIL: os_test.TestSeek (0.0 seconds)
    #6: Seek(8589934592, 0) = 0, <nil> want 8589934592, nil
    #7: Seek(8589934592, 2) = 13, <nil> want 8589934605, nil
FAIL

Comment 2 by m@capitanio.org:

I also forgot to unset DISABLE_NET_TESTS,
so all the non-working tests are (obviously):
        net\
        netchan\
        rpc\
        websocket\
        http\
        syslog\
        os\
----
Non-working benchmarks scripts:
cd pkg && make bench
...
...
cd ../../test/garbage && make bench
make[1]: Entering directory `/data4/soft/go/go/test/garbage'
5g parser.go stats.go
5l -o parser.out parser.5
./parser.out
./parser.out: 1: Syntax error: word unexpected (expecting ")")
make[1]: *** [parser.bench] Error 2
rm parser.5
make[1]: Leaving directory `/data4/soft/go/go/test/garbage'
make: *** [../../test/garbage.bench] Error 2
and
test/bench/timing.sh

Comment 3:

I run using the user-mode qemu all the time, but I use
the kernel binfmt misc support instead of setting $GORUN.
With DISABLE_NET_TESTS=1 all.bash runs to completion
on my linux/amd64 system.
The benchmark script looks like it just needs to use $GORUN.

Owner changed to r...@golang.org.

Status changed to HelpWanted.

Comment 4 by m@capitanio.org:

Thanks, indeed the binfmt misc support works much better. With GOMAXPROCS=1
and DISABLE_NET_TESTS=1 it passed all the tests.

Comment 5:

If you'd like to prepare a patch to insert $GORUN where it's needed, feel free.

Comment 6 by m@capitanio.org:

I apologize, I was wrong, in the comment #4 the tests wasn't enabled.
Actually I can't found any qemu user-mode version that supports
epoll_create. How did you setup the binfmt?

Comment 7 by m@capitanio.org:

http://code.google.com/p/go/source/detail?r=231c6b6747
almost fixes the GOMAXPROCS>1 random issues in comment #0
The success rate is much better, but not 100%.
The pkg/go/printer test breaks always:
throw: malloc/free - deadlock

Attachments:

1. go-qemu-arm-mp2.txt (16819 bytes)

Comment 8 by stephenm@golang.org:

Labels changed: added arch-arm.

Comment 9:

Labels changed: added priority-low, removed priority-medium.

Comment 10:

Labels changed: added priority-someday, removed priority-low.

Comment 11:

Issue #5384 has been merged into this issue.

Comment 12:

Labels changed: added repo-main.

Comment 13:

Labels changed: added release-none.

If we expect tests to pass in this configuration, then it should have a builder.
(See http://golang.org/wiki/PortingPolicy#requirements-for-a-new-port.)

If this configuration is sufficiently exotic that the tests don't pass, but nobody cares enough about it to set up (or run) a builder, then I don't think we should hold an issue open for it.

(CC @bradfitz @dmitshur @toothrot @cagedmantis)

I've historically ignored qemu-user because it doesn't quite test reality, but it might be worth trying to see what its state is, and it might be a good way to run a number of slower builders a bit faster. We've tried cross-compiling from fast GCE amd64 instances in the past and then just running tests sharded out over either physical non-x86 hardware or qemu system instances, but then we always hit the problem of how many tests of ours invoke go build themselves, and we end up compiling inside the slow environment instead.

Having qemu-user builders might mean we get a good compromise between fast host doing compilations and getting good enough arch emulation.

I think it's worth keeping this open for somebody to investigate.

Change https://golang.org/cl/206137 mentions this issue: cmd/go: delete flaky TestQEMUUserMode