[9fans] Plan 9 Go 386

[9fans] Plan 9 Go 386

[Christopher Nielsen]

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

Re: [9fans] Plan 9 Go 386

[Steve Simon]

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

Re: [9fans] Plan 9 Go 386

[erik quanstrom]

>
> 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:

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?

>  From the test:
> <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

Re: [9fans] Plan 9 Go 386

[lucio]

> 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.

Re: [9fans] Plan 9 Go 386

[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.

On Fri, May 24, 2013 at 8:29 AM,  <lucio@proxima.alt.za> wrote:
>> 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.
>
>

Re: [9fans] Plan 9 Go 386

[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?

On May 24, 2013, at 6:11 PM, Jeremy Jackins <jeremyjackins@gmail.com> wrote:

> 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.
> 
> On Fri, May 24, 2013 at 8:29 AM,  <lucio@proxima.alt.za> wrote:
>>> 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.
> 

Re: [9fans] Plan 9 Go 386

[Jeremy Jackins]

On Fri, May 24, 2013 at 8:00 PM, Skip Tavakkolian
<skip.tavakkolian@gmail.com> wrote:
> 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

Re: [9fans] Plan 9 Go 386

[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:

Re: [9fans] Plan 9 Go 386

[lucio]

> 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

Re: [9fans] Plan 9 Go 386

[lucio]

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

>> === 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:

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

Re: [9fans] Plan 9 Go 386

[erik quanstrom]

On Sat May 25 01:50:51 EDT 2013, lucio@proxima.alt.za wrote:
> I've seen this before, although by now I've seen so many errors crop
> up that I can't recall them all.
> 
> >> === 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:
> 
> 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

Re: [9fans] Plan 9 Go 386

[Jeremy Jackins]

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

On Sat, May 25, 2013 at 6:53 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Sat May 25 01:50:51 EDT 2013, lucio@proxima.alt.za wrote:
>> I've seen this before, although by now I've seen so many errors crop
>> up that I can't recall them all.
>>
>> >> === 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:
>>
>> 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
>