[9fans] Plan 9 Go 386

Discussion:

(too old to reply)

Christopher Nielsen

2013-05-23 22:14:59 UTC

I am trying to get the Plan 9/386 port of go stable enough to run a
builder on one of my machines, but I've run into a few snags and could
use some guidance.

Here's the relevant setup:
VMware Workstation instance running as CPU/FS/Auth server
Thinkpad T21 running as a CPU server

The Plan 9 install is up to date against sources, and the go tree is tip.

Compiling the go tool chain with sse2 under VMware yields broken
tools, and building with GO386=387, consistently breaks the tests. On
bare metal, all tests except net/http pass most of the time. When a
test fails I get the following errors:

From the test:
<test> <pid>: suicide: sys: trap: fault write addr=0xfffffffc pc=0x0001e6ea
panic: runtime error: index out of range

<followed by a goroutine stack trace>

On the console of the cpu server:
<pid> <test>: checked <n> page table entries

It doesn't matter what the test is, when it fails, it follows this pattern

An unrelated problem is in net/http, I am seeing any of the timeout
tests, e.g., TestServerTimeouts, TestTLSHandshakeTimeout, exceed the
test timeout. I am not sure what's going on there, but they all get
stuck in a call to Pread.

If anyone has any insight into what might be happening, your help
would be greatly appreciated.

--
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety." --Benjamin Franklin
"The tree of liberty must be refreshed from time to time with the
blood of patriots & tyrants." --Thomas Jefferson

Steve Simon

2013-05-23 23:25:21 UTC

Permalink

At one time the SSE support in the labs kernel was incomplete,
it contained just enough that people actually needed so its possible
that the full state of sse is not being saved/restored.

I haven't experimented with recent kernels, things may wll have changed,
but it might be somthing to check.

-Steve

erik quanstrom

2013-05-24 13:50:40 UTC

Permalink

Post by Christopher Nielsen
Compiling the go tool chain with sse2 under VMware yields broken
tools, and building with GO386=387, consistently breaks the tests. On
bare metal, all tests except net/http pass most of the time. When a

which tests does it break? ?c compile -0. as 0 (which is incorrect),
and print(2)'s %g and %f print -0. as 0. could this or other bits of
non-ieee conformance in the system be the real issue?

Post by Christopher Nielsen
<test> <pid>: suicide: sys: trap: fault write addr=0xfffffffc pc=0x0001e6ea
panic: runtime error: index out of range

i can't imagine how bad sse would lead to accessing address -4.

this looks like the problem rob fixed the other week.

- erik

l***@proxima.alt.za

2013-05-24 14:29:19 UTC

Permalink

Post by erik quanstrom
which tests does it break? ?c compile -0. as 0 (which is incorrect),
and print(2)'s %g and %f print -0. as 0. could this or other bits of
non-ieee conformance in the system be the real issue?

They could be significant, but only where floating point is involved,
the failures I noted do not have an obvious floating point component -
except when SSE2 is required and not available.

So let's start with a show of hands. Who can consistently run the Go
build tests (run.rc --no-rebuild in $GOROOT/src after a successful
make.rc) without failure and what is the Plan 9 (i386) environment
applicable?

Factors I believe are relevant are CPU type, including SSE2
capabilities, which fork of Plan 9 (current Bell Labs
distribution/prior to the 21-bit Rune update (maybe), nix, 9atom,
9front, are there others? I know 9vx is broken, sadly.), local
updates may be pertinent too. Also, I'm assuming, with Christopher,
that we're dealing with Go "tip", if it's an older version, that may
point us in some useful direction.

Also, for the more adventurous, CL 7987044 (from memory - prompt me if
it's wrong) adds ARM capabilities, modulo some changes from Gorka I
have yet to identify. I will be going off topic for a while, I need
to rebuild the local ESXi instance and that will probably take longer
than the weekend, so I can't promise much help until I'm done. But I
will be interested in the outcome of this poll.

If you can, pass the request on, there may be people this message
can't reach.

Lucio.

Jeremy Jackins

2013-05-25 01:11:01 UTC

Permalink

I consistently fail at html/template. At one point I was hanging
indefinitely on some other tests (net/http I think) due to goroutines
never giving up control, setting GOMAXPROCS=2 fixed it. I'm not sure
if that's still an issue though.

I have a 386 which is capable of SSE2, and I'm up to date with sources.

Post by l***@proxima.alt.za

They could be significant, but only where floating point is involved,
the failures I noted do not have an obvious floating point component -
except when SSE2 is required and not available.
So let's start with a show of hands. Who can consistently run the Go
build tests (run.rc --no-rebuild in $GOROOT/src after a successful
make.rc) without failure and what is the Plan 9 (i386) environment
applicable?
Factors I believe are relevant are CPU type, including SSE2
capabilities, which fork of Plan 9 (current Bell Labs
distribution/prior to the 21-bit Rune update (maybe), nix, 9atom,
9front, are there others? I know 9vx is broken, sadly.), local
updates may be pertinent too. Also, I'm assuming, with Christopher,
that we're dealing with Go "tip", if it's an older version, that may
point us in some useful direction.
Also, for the more adventurous, CL 7987044 (from memory - prompt me if
it's wrong) adds ARM capabilities, modulo some changes from Gorka I
have yet to identify. I will be going off topic for a while, I need
to rebuild the local ESXi instance and that will probably take longer
than the weekend, so I can't promise much help until I'm done. But I
will be interested in the outcome of this poll.
If you can, pass the request on, there may be people this message
can't reach.
Lucio.

Skip Tavakkolian

2013-05-25 02:00:15 UTC

Permalink

I sent a message on a thread earlier about broken procs when running 'go test std' -- test of template/html is one of those that broken -- that seems to indicate resource limit problems because running each test individually passes without a problem. Does the test fail if you 'go test' in the pkg/template/html directory?

Post by Jeremy Jackins
I consistently fail at html/template. At one point I was hanging
indefinitely on some other tests (net/http I think) due to goroutines
never giving up control, setting GOMAXPROCS=2 fixed it. I'm not sure
if that's still an issue though.
I have a 386 which is capable of SSE2, and I'm up to date with sources.

Post by l***@proxima.alt.za

They could be significant, but only where floating point is involved,
the failures I noted do not have an obvious floating point component -
except when SSE2 is required and not available.
So let's start with a show of hands. Who can consistently run the Go
build tests (run.rc --no-rebuild in $GOROOT/src after a successful
make.rc) without failure and what is the Plan 9 (i386) environment
applicable?
Factors I believe are relevant are CPU type, including SSE2
capabilities, which fork of Plan 9 (current Bell Labs
distribution/prior to the 21-bit Rune update (maybe), nix, 9atom,
9front, are there others? I know 9vx is broken, sadly.), local
updates may be pertinent too. Also, I'm assuming, with Christopher,
that we're dealing with Go "tip", if it's an older version, that may
point us in some useful direction.
Also, for the more adventurous, CL 7987044 (from memory - prompt me if
it's wrong) adds ARM capabilities, modulo some changes from Gorka I
have yet to identify. I will be going off topic for a while, I need
to rebuild the local ESXi instance and that will probably take longer
than the weekend, so I can't promise much help until I'm done. But I
will be interested in the outcome of this poll.
If you can, pass the request on, there may be people this message
can't reach.
Lucio.

Jeremy Jackins

2013-05-25 02:36:08 UTC

Permalink

On Fri, May 24, 2013 at 8:00 PM, Skip Tavakkolian

Post by Skip Tavakkolian
I sent a message on a thread earlier about broken procs when running 'go test std' -- test of template/html is one of those that broken -- that seems to indicate resource limit problems because running each test individually passes without a problem. Does the test fail if you 'go test' in the pkg/template/html directory?

Yes:

% go test -v
=== RUN TestAddParseTree-2
--- PASS: TestAddParseTree-2 (0.01 seconds)
=== RUN TestClone-2
--- PASS: TestClone-2 (0.00 seconds)
=== RUN TestTemplates-2
--- PASS: TestTemplates-2 (0.00 seconds)
=== RUN TestCloneCrash-2
--- PASS: TestCloneCrash-2 (0.00 seconds)
=== RUN TestTypedContent-2
--- PASS: TestTypedContent-2 (0.00 seconds)
=== RUN TestStringer-2
--- PASS: TestStringer-2 (0.00 seconds)
=== RUN TestEndsWithCSSKeyword-2
--- PASS: TestEndsWithCSSKeyword-2 (0.00 seconds)
=== RUN TestIsCSSNmchar-2
--- PASS: TestIsCSSNmchar-2 (0.00 seconds)
=== RUN TestDecodeCSS-2
--- PASS: TestDecodeCSS-2 (0.00 seconds)
=== RUN TestHexDecode-2
--- PASS: TestHexDecode-2 (0.04 seconds)
=== RUN TestSkipCSSSpace-2
--- PASS: TestSkipCSSSpace-2 (0.00 seconds)
=== RUN TestCSSEscaper-2
--- PASS: TestCSSEscaper-2 (0.00 seconds)
=== RUN TestCSSValueFilter-2
--- PASS: TestCSSValueFilter-2 (0.00 seconds)
=== RUN TestEscape-2
--- PASS: TestEscape-2 (0.03 seconds)
=== RUN TestEscapeSet-2
--- PASS: TestEscapeSet-2 (0.00 seconds)
=== RUN TestErrors-2
template.test 289408: suicide: sys: floating point in note handler pc=0x0001e9c7
exit status: 'template.test 289408: sys: floating point in note
handler pc=0x0001e9c7'
FAIL html/template 0.213s

Jeremy Jackins

2013-05-25 03:06:00 UTC

Permalink

Post by Jeremy Jackins
=== RUN TestErrors-2
template.test 289408: suicide: sys: floating point in note handler pc=0x0001e9c7
exit status: 'template.test 289408: sys: floating point in note
handler pc=0x0001e9c7'
FAIL html/template 0.213s

acid: stk()
runtime.memmove(to=0x106dd000,fr=0x30887660,n=0x2c)+0x107
/usr/glenda/src/go/src/pkg/runtime/memmove_386.s:145
runtime.sighandler(s=0x30887660,v=0x308876e4,gp=0x106d31b0)+0x126
/usr/glenda/src/go/src/pkg/runtime/os_plan9_386.c:67
runtime.sigtramp(ureg=0x30887660,note=0x106d31b0)+0x44
/usr/glenda/src/go/src/pkg/runtime/sys_plan9_386.s:161
0x308876e4 ?file?:0
acid:

l***@proxima.alt.za

2013-05-25 05:50:00 UTC

Permalink

I've seen this before, although by now I've seen so many errors crop
up that I can't recall them all.

Post by Jeremy Jackins

I am surprised, but also relieved that we have a resproducible mistake
outside the run.rc scope. We can focus on that.

I'm hoping cinap, with his in-depth knowledge of the kernel, can shed
some light here. It does look as if we have some error in the
handling of syscalls or notes, although I already mentioned I expected
a note to a process that had received a floating point exception
rather than a floating point exception in a note handler.

In my most recent copy of src/go/src/pkg/runtime/sys_plan9_386.s line
161 is a get_tls(BX), on return from sighandler(). Get_tls on the 386
resolves to

MOVL _tos(SB),r // zasm_plan9_386.h:8

so unless SB is way off, it does not seem to be a problem. I'd lay my
bets on sighandler() (so_plan9_386.c:28), but I am not comfortable
digging in there.

++L

erik quanstrom

2013-05-25 12:53:35 UTC

Permalink

Post by l***@proxima.alt.za
I've seen this before, although by now I've seen so many errors crop
up that I can't recall them all.

Post by Jeremy Jackins

I am surprised, but also relieved that we have a resproducible mistake
outside the run.rc scope. We can focus on that.

this is not surprising. the backtrace and error seem to tell us everything
we need to know. go appears doing floating point in a note handler,
which is not legal in plan 9.

checking the code quickly from here
http://code.google.com/p/go/source/browse/src/pkg/runtime/memmove_386.s
we have

144 move_33through64:
145 MOVOU (SI), X0

which is indeed floating point in memmove. a quick fix would be to
comment out line 47 and make line 48 an unconditional jump.

47 // TESTL $0x4000000, runtime·cpuid_edx(SB) // check for sse2
48 JMP nosse2 // JEQ nosse2

- erik

Jeremy Jackins

2013-05-25 18:25:31 UTC

Permalink

Yes, thank you Erik. With this html/template passes.

Post by erik quanstrom

Post by l***@proxima.alt.za
I've seen this before, although by now I've seen so many errors crop
up that I can't recall them all.

Post by Jeremy Jackins

I am surprised, but also relieved that we have a resproducible mistake
outside the run.rc scope. We can focus on that.

this is not surprising. the backtrace and error seem to tell us everything
we need to know. go appears doing floating point in a note handler,
which is not legal in plan 9.
checking the code quickly from here
http://code.google.com/p/go/source/browse/src/pkg/runtime/memmove_386.s
we have
145 MOVOU (SI), X0
which is indeed floating point in memmove. a quick fix would be to
comment out line 47 and make line 48 an unconditional jump.
47 // TESTL $0x4000000, runtime·cpuid_edx(SB) // check for sse2
48 JMP nosse2 // JEQ nosse2
- erik

l***@proxima.alt.za

2013-05-25 05:17:56 UTC

Permalink

Post by Jeremy Jackins
I have a 386 which is capable of SSE2, and I'm up to date with sources.

Thank you. Could you please try testing html/template alone (I think
you'll get better advice from Skip on how to do it - I would "cd
src/pkg/html/template; go test", i suppose that will do)? Maybe a
couple of times for luck?

++L