* [9fans] Plan 9 Go 386
@ 2013-05-23 22:14 Christopher Nielsen
2013-05-23 23:25 ` Steve Simon
2013-05-24 13:50 ` erik quanstrom
0 siblings, 2 replies; 12+ messages in thread
From: Christopher Nielsen @ 2013-05-23 22:14 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-23 22:14 [9fans] Plan 9 Go 386 Christopher Nielsen @ 2013-05-23 23:25 ` Steve Simon 2013-05-24 13:50 ` erik quanstrom 1 sibling, 0 replies; 12+ messages in thread From: Steve Simon @ 2013-05-23 23:25 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-23 22:14 [9fans] Plan 9 Go 386 Christopher Nielsen 2013-05-23 23:25 ` Steve Simon @ 2013-05-24 13:50 ` erik quanstrom 2013-05-24 14:29 ` lucio 1 sibling, 1 reply; 12+ messages in thread From: erik quanstrom @ 2013-05-24 13:50 UTC (permalink / raw) To: 9fans > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-24 13:50 ` erik quanstrom @ 2013-05-24 14:29 ` lucio 2013-05-25 1:11 ` Jeremy Jackins 0 siblings, 1 reply; 12+ messages in thread From: lucio @ 2013-05-24 14:29 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-24 14:29 ` lucio @ 2013-05-25 1:11 ` Jeremy Jackins 2013-05-25 2:00 ` Skip Tavakkolian 2013-05-25 5:17 ` lucio 0 siblings, 2 replies; 12+ messages in thread From: Jeremy Jackins @ 2013-05-25 1:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-25 1:11 ` Jeremy Jackins @ 2013-05-25 2:00 ` Skip Tavakkolian 2013-05-25 2:36 ` Jeremy Jackins 2013-05-25 5:17 ` lucio 1 sibling, 1 reply; 12+ messages in thread From: Skip Tavakkolian @ 2013-05-25 2:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-25 2:00 ` Skip Tavakkolian @ 2013-05-25 2:36 ` Jeremy Jackins 2013-05-25 3:06 ` Jeremy Jackins 0 siblings, 1 reply; 12+ messages in thread From: Jeremy Jackins @ 2013-05-25 2:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-25 2:36 ` Jeremy Jackins @ 2013-05-25 3:06 ` Jeremy Jackins 2013-05-25 5:50 ` lucio 0 siblings, 1 reply; 12+ messages in thread From: Jeremy Jackins @ 2013-05-25 3:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > === 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: ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-25 3:06 ` Jeremy Jackins @ 2013-05-25 5:50 ` lucio 2013-05-25 12:53 ` erik quanstrom 0 siblings, 1 reply; 12+ messages in thread From: lucio @ 2013-05-25 5:50 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-25 5:50 ` lucio @ 2013-05-25 12:53 ` erik quanstrom 2013-05-25 18:25 ` Jeremy Jackins 0 siblings, 1 reply; 12+ messages in thread From: erik quanstrom @ 2013-05-25 12:53 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-25 12:53 ` erik quanstrom @ 2013-05-25 18:25 ` Jeremy Jackins 0 siblings, 0 replies; 12+ messages in thread From: Jeremy Jackins @ 2013-05-25 18:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] Plan 9 Go 386 2013-05-25 1:11 ` Jeremy Jackins 2013-05-25 2:00 ` Skip Tavakkolian @ 2013-05-25 5:17 ` lucio 1 sibling, 0 replies; 12+ messages in thread From: lucio @ 2013-05-25 5:17 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-05-25 18:25 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-23 22:14 [9fans] Plan 9 Go 386 Christopher Nielsen 2013-05-23 23:25 ` Steve Simon 2013-05-24 13:50 ` erik quanstrom 2013-05-24 14:29 ` lucio 2013-05-25 1:11 ` Jeremy Jackins 2013-05-25 2:00 ` Skip Tavakkolian 2013-05-25 2:36 ` Jeremy Jackins 2013-05-25 3:06 ` Jeremy Jackins 2013-05-25 5:50 ` lucio 2013-05-25 12:53 ` erik quanstrom 2013-05-25 18:25 ` Jeremy Jackins 2013-05-25 5:17 ` lucio
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).