* [9fans] 9vx mk install chokes on gs
@ 2010-09-11 23:07 ron minnich
2010-09-11 23:15 ` andrey mirtchovski
2010-09-11 23:35 ` Robert Ransom
0 siblings, 2 replies; 19+ messages in thread
From: ron minnich @ 2010-09-11 23:07 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
any good ideas here? I'm running with 9vx -m 1024. Kind of hard to
believe I'm out.
mk gs
pcc -o 8.out obj/gs.8 obj/adler32.8 obj/compress.8 obj/crc32.8
obj/deflate.8 obj/dscparse.8 obj/gconfig.8 obj/gdevabuf.8
obj/gdevbbox.8 obj/gdevbj10.8 obj/gdevcd8.8 obj/gdevcdj.8
obj/gdevdbit.8 obj/gdevddrw.8 obj/gdevdfax.8 obj/gdevdflt.8
obj/gdevdgbr.8 obj/gdevdjet.8 obj/gdevdljm.8 obj/gdevdsha.8
obj/gdevfax.8 obj/gdevhit.8 obj/gdevifno.8 obj/gdevjpeg.8 obj/gdevm1.8
obj/gdevm16.8 obj/gdevm2.8 obj/gdevm24.8 obj/gdevm32.8 obj/gdevm4.8
obj/gdevm40.8 obj/gdevm48.8 obj/gdevm56.8 obj/gdevm64.8 obj/gdevm8.8
obj/gdevmem.8 obj/gdevmpla.8 obj/gdevnfwd.8 obj/gdevp14.8
obj/gdevpbm.8 obj/gdevpcl.8 obj/gdevpdf.8 obj/gdevpdfb.8
obj/gdevpdfc.8 obj/gdevpdfd.8 obj/gdevpdfg.8 obj/gdevpdfi.8
obj/gdevpdfj.8 obj/gdevpdfk.8 obj/gdevpdfm.8 obj/gdevpdfo.8
obj/gdevpdfp.8 obj/gdevpdfr.8 obj/gdevpdft.8 obj/gdevpdfu.8
obj/gdevpdfv.8 obj/gdevpdt.8 obj/gdevpdtb.8 obj/gdevpdtc.8
obj/gdevpdtd.8 obj/gdevpdte.8 obj/gdevpdtf.8 obj/gdevpdti.8
obj/gdevpdts.8 obj/gdevpdtt.8 obj/gdevpdtv.8 obj/gdevpdtw.8
obj/gdevpipe.8 obj/gdevplan9.8 obj/gdevplnx.8 obj/gdevppla.8
obj/gdevprn.8 obj/gdevps.8 obj/gdevpsdi.8 obj/gdevpsdp.8
obj/gdevpsds.8 obj/gdevpsdu.8 obj/gdevpsf1.8 obj/gdevpsf2.8
obj/gdevpsfm.8 obj/gdevpsft.8 obj/gdevpsfu.8 obj/gdevpsfx.8
obj/gdevpsu.8 obj/gdevstc.8 obj/gdevstc1.8 obj/gdevstc2.8
obj/gdevstc3.8 obj/gdevstc4.8 obj/gdevtfax.8 obj/gdevtifs.8
obj/gdevvec.8 obj/gp_getnv.8 obj/gp_nsync.8 obj/gp_stdia.8
obj/gp_strdl.8 obj/gp_unifn.8 obj/gp_unifs.8 obj/gp_unix.8
obj/gp_unix_cache.8 obj/gpmisc.8 obj/gsalloc.8 obj/gsalpha.8
obj/gsalphac.8 obj/gsargs.8 obj/gsbitcom.8 obj/gsbitops.8
obj/gsbittab.8 obj/gscdefs.8 obj/gscdevn.8 obj/gscedata.8
obj/gscencs.8 obj/gschar.8 obj/gschar0.8 obj/gscie.8 obj/gsciemap.8
obj/gsclipsr.8 obj/gscolor.8 obj/gscolor1.8 obj/gscolor2.8
obj/gscolor3.8 obj/gscoord.8 obj/gscparam.8 obj/gscpixel.8 obj/gscrd.8
obj/gscrdp.8 obj/gscrypt1.8 obj/gscscie.8 obj/gscsepr.8 obj/gscspace.8
obj/gsdevice.8 obj/gsdevmem.8 obj/gsdfilt.8 obj/gsdparam.8 obj/gsdps.8
obj/gsdps1.8 obj/gsdsrc.8 obj/gsfcid.8 obj/gsfcid2.8 obj/gsfcmap.8
obj/gsfcmap1.8 obj/gsflip.8 obj/gsfname.8 obj/gsfont.8 obj/gsfont0.8
obj/gsfont0c.8 obj/gsfunc.8 obj/gsfunc0.8 obj/gsfunc3.8 obj/gsfunc4.8
obj/gsgcache.8 obj/gsgdata.8 obj/gsht.8 obj/gsht1.8 obj/gshtscr.8
obj/gsicc.8 obj/gsimage.8 obj/gsimpath.8 obj/gsinit.8 obj/gsiodev.8
obj/gsistate.8 obj/gslibctx.8 obj/gsline.8 obj/gsmalloc.8
obj/gsmatrix.8 obj/gsmemlok.8 obj/gsmemory.8 obj/gsmemret.8
obj/gsmisc.8 obj/gsnorop.8 obj/gsnotify.8 obj/gsovrc.8 obj/gspaint.8
obj/gsparam.8 obj/gsparams.8 obj/gsparamx.8 obj/gspath.8 obj/gspath1.8
obj/gspcolor.8 obj/gsptype1.8 obj/gsptype2.8 obj/gsroptab.8
obj/gsserial.8 obj/gsshade.8 obj/gsstate.8 obj/gstext.8 obj/gstrans.8
obj/gstype1.8 obj/gstype2.8 obj/gstype42.8 obj/gsutil.8 obj/gswts.8
obj/gxacpath.8 obj/gxbcache.8 obj/gxblend.8 obj/gxccache.8
obj/gxccman.8 obj/gxchar.8 obj/gxchrout.8 obj/gxcht.8 obj/gxclbits.8
obj/gxclfile.8 obj/gxclimag.8 obj/gxclip.8 obj/gxclip2.8 obj/gxclipm.8
obj/gxclist.8 obj/gxclpage.8 obj/gxclpath.8 obj/gxclrast.8
obj/gxclread.8 obj/gxclrect.8 obj/gxclutil.8 obj/gxcmap.8
obj/gxcpath.8 obj/gxctable.8 obj/gxdcconv.8 obj/gxdcolor.8
obj/gxdevndi.8 obj/gxdhtserial.8 obj/gxfcopy.8 obj/gxfdrop.8
obj/gxfill.8 obj/gxhintn.8 obj/gxhldevc.8 obj/gxht.8 obj/gxhtbit.8
obj/gxi12bit.8 obj/gxi16bit.8 obj/gxicolor.8 obj/gxidata.8
obj/gxifast.8 obj/gximag3x.8 obj/gximage.8 obj/gximage1.8
obj/gximage2.8 obj/gximage3.8 obj/gximage4.8 obj/gximono.8
obj/gxipixel.8 obj/gxiscale.8 obj/gxmclip.8 obj/gxoprect.8
obj/gxp1fill.8 obj/gxpaint.8 obj/gxpath.8 obj/gxpath2.8 obj/gxpcmap.8
obj/gxpcopy.8 obj/gxpdash.8 obj/gxpflat.8 obj/gxsample.8 obj/gxshade.8
obj/gxshade1.8 obj/gxshade4.8 obj/gxshade6.8 obj/gxstroke.8
obj/gxsync.8 obj/gxttfb.8 obj/gxtype1.8 obj/gxwts.8 obj/gzspotan.8
obj/ialloc.8 obj/iapi.8 obj/ibnum.8 obj/icc.8 obj/iccinit0.8
obj/iconfig.8 obj/icontext.8 obj/idebug.8 obj/idict.8 obj/idisp.8
obj/idparam.8 obj/idstack.8 obj/igc.8 obj/igcref.8 obj/igcstr.8
obj/iinit.8 obj/ilocate.8 obj/imain.8 obj/imainarg.8 obj/iname.8
obj/inffast.8 obj/inflate.8 obj/inftrees.8 obj/interp.8 obj/ipar
??none??: out of memory
pcc: 8l: 8l 2731: error
mk: pcc -o ... : exit status=rc 2728: pcc 2730: 8l: 8l 2731: error
mk: for(i in 1a ... : exit status=rc 1720: rc 2717: mk 2719: error
mk: test -e 8._cp ... : exit status=rc 1321: mk 1708: error
mk: date for (i ... : exit status=rc 83: rc 1308: mk 1309: error
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-11 23:07 [9fans] 9vx mk install chokes on gs ron minnich
@ 2010-09-11 23:15 ` andrey mirtchovski
2010-09-11 23:35 ` Robert Ransom
1 sibling, 0 replies; 19+ messages in thread
From: andrey mirtchovski @ 2010-09-11 23:15 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
get some more memory? :)
On Sat, Sep 11, 2010 at 5:07 PM, ron minnich <rminnich@gmail.com> wrote:
> any good ideas here? I'm running with 9vx -m 1024. Kind of hard to
> believe I'm out.
>
>
> mk gs
> pcc -o 8.out obj/gs.8 obj/adler32.8 obj/compress.8 obj/crc32.8
> obj/deflate.8 obj/dscparse.8 obj/gconfig.8 obj/gdevabuf.8
> obj/gdevbbox.8 obj/gdevbj10.8 obj/gdevcd8.8 obj/gdevcdj.8
> obj/gdevdbit.8 obj/gdevddrw.8 obj/gdevdfax.8 obj/gdevdflt.8
> obj/gdevdgbr.8 obj/gdevdjet.8 obj/gdevdljm.8 obj/gdevdsha.8
> obj/gdevfax.8 obj/gdevhit.8 obj/gdevifno.8 obj/gdevjpeg.8 obj/gdevm1.8
> obj/gdevm16.8 obj/gdevm2.8 obj/gdevm24.8 obj/gdevm32.8 obj/gdevm4.8
> obj/gdevm40.8 obj/gdevm48.8 obj/gdevm56.8 obj/gdevm64.8 obj/gdevm8.8
> obj/gdevmem.8 obj/gdevmpla.8 obj/gdevnfwd.8 obj/gdevp14.8
> obj/gdevpbm.8 obj/gdevpcl.8 obj/gdevpdf.8 obj/gdevpdfb.8
> obj/gdevpdfc.8 obj/gdevpdfd.8 obj/gdevpdfg.8 obj/gdevpdfi.8
> obj/gdevpdfj.8 obj/gdevpdfk.8 obj/gdevpdfm.8 obj/gdevpdfo.8
> obj/gdevpdfp.8 obj/gdevpdfr.8 obj/gdevpdft.8 obj/gdevpdfu.8
> obj/gdevpdfv.8 obj/gdevpdt.8 obj/gdevpdtb.8 obj/gdevpdtc.8
> obj/gdevpdtd.8 obj/gdevpdte.8 obj/gdevpdtf.8 obj/gdevpdti.8
> obj/gdevpdts.8 obj/gdevpdtt.8 obj/gdevpdtv.8 obj/gdevpdtw.8
> obj/gdevpipe.8 obj/gdevplan9.8 obj/gdevplnx.8 obj/gdevppla.8
> obj/gdevprn.8 obj/gdevps.8 obj/gdevpsdi.8 obj/gdevpsdp.8
> obj/gdevpsds.8 obj/gdevpsdu.8 obj/gdevpsf1.8 obj/gdevpsf2.8
> obj/gdevpsfm.8 obj/gdevpsft.8 obj/gdevpsfu.8 obj/gdevpsfx.8
> obj/gdevpsu.8 obj/gdevstc.8 obj/gdevstc1.8 obj/gdevstc2.8
> obj/gdevstc3.8 obj/gdevstc4.8 obj/gdevtfax.8 obj/gdevtifs.8
> obj/gdevvec.8 obj/gp_getnv.8 obj/gp_nsync.8 obj/gp_stdia.8
> obj/gp_strdl.8 obj/gp_unifn.8 obj/gp_unifs.8 obj/gp_unix.8
> obj/gp_unix_cache.8 obj/gpmisc.8 obj/gsalloc.8 obj/gsalpha.8
> obj/gsalphac.8 obj/gsargs.8 obj/gsbitcom.8 obj/gsbitops.8
> obj/gsbittab.8 obj/gscdefs.8 obj/gscdevn.8 obj/gscedata.8
> obj/gscencs.8 obj/gschar.8 obj/gschar0.8 obj/gscie.8 obj/gsciemap.8
> obj/gsclipsr.8 obj/gscolor.8 obj/gscolor1.8 obj/gscolor2.8
> obj/gscolor3.8 obj/gscoord.8 obj/gscparam.8 obj/gscpixel.8 obj/gscrd.8
> obj/gscrdp.8 obj/gscrypt1.8 obj/gscscie.8 obj/gscsepr.8 obj/gscspace.8
> obj/gsdevice.8 obj/gsdevmem.8 obj/gsdfilt.8 obj/gsdparam.8 obj/gsdps.8
> obj/gsdps1.8 obj/gsdsrc.8 obj/gsfcid.8 obj/gsfcid2.8 obj/gsfcmap.8
> obj/gsfcmap1.8 obj/gsflip.8 obj/gsfname.8 obj/gsfont.8 obj/gsfont0.8
> obj/gsfont0c.8 obj/gsfunc.8 obj/gsfunc0.8 obj/gsfunc3.8 obj/gsfunc4.8
> obj/gsgcache.8 obj/gsgdata.8 obj/gsht.8 obj/gsht1.8 obj/gshtscr.8
> obj/gsicc.8 obj/gsimage.8 obj/gsimpath.8 obj/gsinit.8 obj/gsiodev.8
> obj/gsistate.8 obj/gslibctx.8 obj/gsline.8 obj/gsmalloc.8
> obj/gsmatrix.8 obj/gsmemlok.8 obj/gsmemory.8 obj/gsmemret.8
> obj/gsmisc.8 obj/gsnorop.8 obj/gsnotify.8 obj/gsovrc.8 obj/gspaint.8
> obj/gsparam.8 obj/gsparams.8 obj/gsparamx.8 obj/gspath.8 obj/gspath1.8
> obj/gspcolor.8 obj/gsptype1.8 obj/gsptype2.8 obj/gsroptab.8
> obj/gsserial.8 obj/gsshade.8 obj/gsstate.8 obj/gstext.8 obj/gstrans.8
> obj/gstype1.8 obj/gstype2.8 obj/gstype42.8 obj/gsutil.8 obj/gswts.8
> obj/gxacpath.8 obj/gxbcache.8 obj/gxblend.8 obj/gxccache.8
> obj/gxccman.8 obj/gxchar.8 obj/gxchrout.8 obj/gxcht.8 obj/gxclbits.8
> obj/gxclfile.8 obj/gxclimag.8 obj/gxclip.8 obj/gxclip2.8 obj/gxclipm.8
> obj/gxclist.8 obj/gxclpage.8 obj/gxclpath.8 obj/gxclrast.8
> obj/gxclread.8 obj/gxclrect.8 obj/gxclutil.8 obj/gxcmap.8
> obj/gxcpath.8 obj/gxctable.8 obj/gxdcconv.8 obj/gxdcolor.8
> obj/gxdevndi.8 obj/gxdhtserial.8 obj/gxfcopy.8 obj/gxfdrop.8
> obj/gxfill.8 obj/gxhintn.8 obj/gxhldevc.8 obj/gxht.8 obj/gxhtbit.8
> obj/gxi12bit.8 obj/gxi16bit.8 obj/gxicolor.8 obj/gxidata.8
> obj/gxifast.8 obj/gximag3x.8 obj/gximage.8 obj/gximage1.8
> obj/gximage2.8 obj/gximage3.8 obj/gximage4.8 obj/gximono.8
> obj/gxipixel.8 obj/gxiscale.8 obj/gxmclip.8 obj/gxoprect.8
> obj/gxp1fill.8 obj/gxpaint.8 obj/gxpath.8 obj/gxpath2.8 obj/gxpcmap.8
> obj/gxpcopy.8 obj/gxpdash.8 obj/gxpflat.8 obj/gxsample.8 obj/gxshade.8
> obj/gxshade1.8 obj/gxshade4.8 obj/gxshade6.8 obj/gxstroke.8
> obj/gxsync.8 obj/gxttfb.8 obj/gxtype1.8 obj/gxwts.8 obj/gzspotan.8
> obj/ialloc.8 obj/iapi.8 obj/ibnum.8 obj/icc.8 obj/iccinit0.8
> obj/iconfig.8 obj/icontext.8 obj/idebug.8 obj/idict.8 obj/idisp.8
> obj/idparam.8 obj/idstack.8 obj/igc.8 obj/igcref.8 obj/igcstr.8
> obj/iinit.8 obj/ilocate.8 obj/imain.8 obj/imainarg.8 obj/iname.8
> obj/inffast.8 obj/inflate.8 obj/inftrees.8 obj/interp.8 obj/ipar
> ??none??: out of memory
> pcc: 8l: 8l 2731: error
> mk: pcc -o ... : exit status=rc 2728: pcc 2730: 8l: 8l 2731: error
> mk: for(i in 1a ... : exit status=rc 1720: rc 2717: mk 2719: error
> mk: test -e 8._cp ... : exit status=rc 1321: mk 1708: error
> mk: date for (i ... : exit status=rc 83: rc 1308: mk 1309: error
>
> ron
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-11 23:07 [9fans] 9vx mk install chokes on gs ron minnich
2010-09-11 23:15 ` andrey mirtchovski
@ 2010-09-11 23:35 ` Robert Ransom
2010-09-12 0:39 ` ron minnich
1 sibling, 1 reply; 19+ messages in thread
From: Robert Ransom @ 2010-09-11 23:35 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Sat, 11 Sep 2010 16:07:54 -0700
ron minnich <rminnich@gmail.com> wrote:
> any good ideas here? I'm running with 9vx -m 1024. Kind of hard to
> believe I'm out.
> mk gs
> pcc -o 8.out obj/gs.8 obj/adler32.8 obj/compress.8 obj/crc32.8
> obj/deflate.8 obj/dscparse.8 obj/gconfig.8 obj/gdevabuf.8
> obj/iinit.8 obj/ilocate.8 obj/imain.8 obj/imainarg.8 obj/iname.8
> obj/inffast.8 obj/inflate.8 obj/inftrees.8 obj/interp.8 obj/ipar
> ??none??: out of memory
> pcc: 8l: 8l 2731: error
% man 2 exec |vgrep
...
BUGS
There is a large but finite limit on the size of an argment
list, typically around 409,600 bytes. The kernel constant
TSTKSIZ controls this.
...
Robert Ransom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [9fans] 9vx mk install chokes on gs
2010-09-11 23:35 ` Robert Ransom
@ 2010-09-12 0:39 ` ron minnich
2010-09-12 0:49 ` ron minnich
0 siblings, 1 reply; 19+ messages in thread
From: ron minnich @ 2010-09-12 0:39 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Sat, Sep 11, 2010 at 4:35 PM, Robert Ransom <rransom.8774@gmail.com> wrote:
> BUGS
> There is a large but finite limit on the size of an argment
> list, typically around 409,600 bytes. The kernel constant
> TSTKSIZ controls this.
> ...
>
>
> Robert Ransom
>
no, I'm running under ratrace and 8l is run and I get to this:
4684 8l Brk 0xdeba 032379d8 00015298 00000000 = -1 "segments overlap"
0x11d294485d874150 0x11d294485d87c620
Oh well :-(
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 0:39 ` ron minnich
@ 2010-09-12 0:49 ` ron minnich
2010-09-12 1:02 ` erik quanstrom
0 siblings, 1 reply; 19+ messages in thread
From: ron minnich @ 2010-09-12 0:49 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
This operating system is so much fun it's unfair at times.
term% grep Brk /dev/text | grep 8l
4684 8l Brk 0xdeba 0003ea58 00000000 00000000 = 0 ""
0x11d2943ddb0c6c28 0x11d2943ddb0ccdd0
4684 8l Brk 0xdeba 000570f8 00017494 00001fa8 = 0 ""
0x11d2943ded6477a8 0x11d2943ded64cd98
4684 8l Brk 0xdeba 0006f798 00017492 00001faa = 0 ""
0x11d2943df0d4fdb8 0x11d2943df0d553a8
4684 8l Brk 0xdeba 00087e38 0001749e 00005966 = 0 ""
0x11d2943df747e2a0 0x11d2943df74834a8
4684 8l Brk 0xdeba 000a04d8 00017493 00005966 = 0 ""
0x11d2943dfa538490 0x11d2943dfa53da80
4684 8l Brk 0xdeba 0011a5f8 00017498 00005966 = 0 ""
0x11d2943e01998c40 0x11d2943e0199ede8
4684 8l Brk 0xdeba 00194718 0001749c 000058ef = 0 ""
0x11d2943e0e012178 0x11d2943e0e017f38
4684 8l Brk 0xdeba 0020e838 00015298 00000000 = 0 ""
0x11d2943e2852e0c0 0x11d2943e285336b0
4684 8l Brk 0xdeba 00288958 0001528d 00000000 = 0 ""
0x11d2943e3fb530d8 0x11d2943e3fb582e0
4684 8l Brk 0xdeba 004eaef8 00000000 000058ef = 0 ""
0x11d2943e4efa5ed8 0x11d2943e4efac468
4684 8l Brk 0xdeba 0074d498 0001528d 00000000 = 0 ""
0x11d2943ebc6be720 0x11d2943ebc6c4cb0
4684 8l Brk 0xdeba 009afa38 00015298 00000000 = 0 ""
0x11d2943f468a9f28 0x11d2943f468af518
4684 8l Brk 0xdeba 00c11fd8 00017494 000058ef = 0 ""
0x11d2943fb61756b0 0x11d2943fb617b858
4684 8l Brk 0xdeba 00e74578 0001749b 000058ef = 0 ""
0x11d294402504f7a8 0x11d2944025053a10
4684 8l Brk 0xdeba 010d6b18 0001749f 000058ef = 0 ""
0x11d294409abb0fc8 0x11d294409abb5a00
4684 8l Brk 0xdeba 013390b8 0001749d 000058ef = 0 ""
0x11d2944108610208 0x11d2944108616b80
4684 8l Brk 0xdeba 0159b658 00000000 000058ef = 0 ""
0x11d29441807b3178 0x11d29441807b9ed8
4684 8l Brk 0xdeba 017fdbf8 00017497 000058ef = 0 ""
0x11d294420ad4e328 0x11d294420ad54ca0
4684 8l Brk 0xdeba 01a60198 00015298 00000000 = 0 ""
0x11d29442921f5908 0x11d29442921fb6c8
4684 8l Brk 0xdeba 01cc2738 00017495 00005966 = 0 ""
0x11d2944340477448 0x11d294434047ddc0
4684 8l Brk 0xdeba 01f24cd8 0001528d 00000000 = 0 ""
0x11d29443d7559310 0x11d29443d7561fb0
4684 8l Brk 0xdeba 02187278 00000000 01cc2738 = 0 ""
0x11d294448ff77190 0x11d294448ff80600
4684 8l Brk 0xdeba 023e9818 0001528d 00000000 = 0 ""
0x11d294452b014350 0x11d294452b01a8e0
4684 8l Brk 0xdeba 0264bdb8 00015298 00000000 = 0 ""
0x11d29445da7c2138 0x11d29445da7c8ab0
4684 8l Brk 0xdeba 028ae358 00000000 000058ef = 0 ""
0x11d2944662799f20 0x11d29446627a00c8
4684 8l Brk 0xdeba 02b108f8 00000000 000058ef = 0 ""
0x11d29446e574eec0 0x11d29446e57563f0
4684 8l Brk 0xdeba 02d72e98 0001528d 00000000 = 0 ""
0x11d294476893e360 0x11d2944768944120
4684 8l Brk 0xdeba 02fd5438 0001749b 000058ef = 0 ""
0x11d29447ed62c638 0x11d29447ed633398
4684 8l Brk 0xdeba 032379d8 00015298 00000000 = -1 "segments overlap"
0x11d294485d874150 0x11d294485d87c620
now how easy was that :-) (although nothing is fixed yet ...)
Note that it grabs about 1M on each sbrk ... or a little more. It got
to 52M or so and then it was all over.
ron
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 0:49 ` ron minnich
@ 2010-09-12 1:02 ` erik quanstrom
2010-09-12 2:25 ` ron minnich
0 siblings, 1 reply; 19+ messages in thread
From: erik quanstrom @ 2010-09-12 1:02 UTC (permalink / raw)
To: 9fans
the problematic code is at /sys/src/9/port/segment.c:483,491
for(i = 0; i < NSEG; i++) {
ns = up->seg[i];
if(ns == 0 || ns == s)
continue;
if(newtop >= ns->base && newtop < ns->top) {
qunlock(&s->lk);
error(Esoverlap);
}
}
so either gcc is causing the math here to go funky, or
9vx really does have a odd segment layout.
what does /proc/$pid/segment say?
- erik
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 1:02 ` erik quanstrom
@ 2010-09-12 2:25 ` ron minnich
2010-09-12 2:32 ` ron minnich
0 siblings, 1 reply; 19+ messages in thread
From: ron minnich @ 2010-09-12 2:25 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Actually it's really simple. Stack in 9vx begins at 48 MB. A bit small
for compiling gs I suppose :-)
I'll see how to grow it.
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 2:25 ` ron minnich
@ 2010-09-12 2:32 ` ron minnich
2010-09-12 3:44 ` ron minnich
2010-09-12 4:59 ` erik quanstrom
0 siblings, 2 replies; 19+ messages in thread
From: ron minnich @ 2010-09-12 2:32 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
diff -r 6ab31397d4b9 src/9vx/a/mem.h
--- a/src/9vx/a/mem.h Sat Sep 11 23:09:14 2010 +0200
+++ b/src/9vx/a/mem.h Sat Sep 11 19:31:19 2010 -0700
@@ -41,7 +41,7 @@
#define VMAPSIZE (0x10000000-VPTSIZE-KMAPSIZE)
#define UZERO 0 /* base of user address space */
#define UTZERO (UZERO+BY2PG) /* first address in user text */
-#define USTKTOP (0x4000000) /* byte just beyond user stack */
+#define USTKTOP (0x8000000) /* byte just beyond user stack */
#define USTKSIZE (16*1024*1024) /* size of user stack */
#define TSTKTOP (USTKTOP-USTKSIZE) /* end of new stack in sysexec */
#define TSTKSIZ 100 /* pages in new stack; limits exec args */
rminnich@xcpu2:~/src/plan9/vx32/src$
Fixed. gs builds. I'll do a full make to be sure there are no bad
repercussions.
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 2:32 ` ron minnich
@ 2010-09-12 3:44 ` ron minnich
2010-09-12 4:59 ` erik quanstrom
1 sibling, 0 replies; 19+ messages in thread
From: ron minnich @ 2010-09-12 3:44 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
OK, the bigger user stack is committed to my vx32 at bitbucket.
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 2:32 ` ron minnich
2010-09-12 3:44 ` ron minnich
@ 2010-09-12 4:59 ` erik quanstrom
2010-09-12 6:27 ` ron minnich
2010-09-12 15:44 ` Russ Cox
1 sibling, 2 replies; 19+ messages in thread
From: erik quanstrom @ 2010-09-12 4:59 UTC (permalink / raw)
To: rminnich, 9fans
> -#define USTKTOP (0x4000000) /* byte just beyond user stack */
> +#define USTKTOP (0x8000000) /* byte just beyond user stack */
shouldn't you add a 0 to that? what's wrong with giving a process 2gb
of address space? fundamental 9vx limits?
- erik
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 4:59 ` erik quanstrom
@ 2010-09-12 6:27 ` ron minnich
2010-09-12 15:44 ` Russ Cox
1 sibling, 0 replies; 19+ messages in thread
From: ron minnich @ 2010-09-12 6:27 UTC (permalink / raw)
To: erik quanstrom; +Cc: 9fans
On Sat, Sep 11, 2010 at 9:59 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> -#define USTKTOP (0x4000000) /* byte just beyond user stack */
>> +#define USTKTOP (0x8000000) /* byte just beyond user stack */
>
> shouldn't you add a 0 to that? what's wrong with giving a process 2gb
> of address space? fundamental 9vx limits?
I figure I'll take my time. I don't know the reason for the original
low limit, so I decided not to push it until I understand it better.
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 4:59 ` erik quanstrom
2010-09-12 6:27 ` ron minnich
@ 2010-09-12 15:44 ` Russ Cox
2010-09-12 16:48 ` erik quanstrom
2010-09-12 17:12 ` ron minnich
1 sibling, 2 replies; 19+ messages in thread
From: Russ Cox @ 2010-09-12 15:44 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs; +Cc: rminnich
On Sun, Sep 12, 2010 at 12:59 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> -#define USTKTOP (0x4000000) /* byte just beyond user stack */
>> +#define USTKTOP (0x8000000) /* byte just beyond user stack */
>
> shouldn't you add a 0 to that? what's wrong with giving a process 2gb
> of address space? fundamental 9vx limits?
there might not be 2gb of contiguous address space to have.
this is running inside a unix process.
another reason for the low size was so that it was easier
to keep multiple processes mapped at the same time,
to reduce context switch latency.
russ
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 15:44 ` Russ Cox
@ 2010-09-12 16:48 ` erik quanstrom
2010-09-12 18:19 ` Russ Cox
2010-09-12 17:12 ` ron minnich
1 sibling, 1 reply; 19+ messages in thread
From: erik quanstrom @ 2010-09-12 16:48 UTC (permalink / raw)
To: 9fans
On Sun Sep 12 11:45:31 EDT 2010, rsc@swtch.com wrote:
> On Sun, Sep 12, 2010 at 12:59 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> >> -#define USTKTOP (0x4000000) /* byte just beyond user stack */
> >> +#define USTKTOP (0x8000000) /* byte just beyond user stack */
> >
> > shouldn't you add a 0 to that? what's wrong with giving a process 2gb
> > of address space? fundamental 9vx limits?
>
> there might not be 2gb of contiguous address space to have.
> this is running inside a unix process.
>
> another reason for the low size was so that it was easier
> to keep multiple processes mapped at the same time,
> to reduce context switch latency.
that makes sense. unfortunately, this means that any
process that uses significant memory on plan 9 needs
to be re-checked for 9vx. even 100mb is tiny.
- erik
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 16:48 ` erik quanstrom
@ 2010-09-12 18:19 ` Russ Cox
2010-09-12 19:13 ` ron minnich
2010-09-12 19:33 ` ron minnich
0 siblings, 2 replies; 19+ messages in thread
From: Russ Cox @ 2010-09-12 18:19 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
>> another reason for the low size was so that it was easier
>> to keep multiple processes mapped at the same time,
>> to reduce context switch latency.
>
> that makes sense. unfortunately, this means that any
> process that uses significant memory on plan 9 needs
> to be re-checked for 9vx. even 100mb is tiny.
it's easy to recompile. the current limit seems to
work very well for people, as this is the first
complaint in two years. there are still people
running plan 9 on 64 MB or 128 MB machines.
(and actually i thought the 9vx limit was 256 MB;
maybe ron cranked it down.)
russ
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 18:19 ` Russ Cox
@ 2010-09-12 19:13 ` ron minnich
2010-09-12 19:33 ` ron minnich
1 sibling, 0 replies; 19+ messages in thread
From: ron minnich @ 2010-09-12 19:13 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Sun, Sep 12, 2010 at 11:19 AM, Russ Cox <rsc@swtch.com> wrote:
> (and actually i thought the 9vx limit was 256 MB;
> maybe ron cranked it down.)
I don't think so but I'll dig around.
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 18:19 ` Russ Cox
2010-09-12 19:13 ` ron minnich
@ 2010-09-12 19:33 ` ron minnich
2010-09-12 20:09 ` yy
1 sibling, 1 reply; 19+ messages in thread
From: ron minnich @ 2010-09-12 19:33 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Ah. It was 256 MB but Yiyus changed it 8 weeks ago to 64MB. Why?
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 19:33 ` ron minnich
@ 2010-09-12 20:09 ` yy
2010-09-14 20:38 ` yy
0 siblings, 1 reply; 19+ messages in thread
From: yy @ 2010-09-12 20:09 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
2010/9/12 ron minnich <rminnich@gmail.com>:
> Ah. It was 256 MB but Yiyus changed it 8 weeks ago to 64MB. Why?
Sorry about that. It was after updating all the a/ files from the .ed
scripts. It looks like I did not pay enough attention to mem.ed. There
were other changes that could be causing problems too. I'm currently
having another look at all the stuff in a/. It could take some time,
but I will fix it. In the meantime, the old mem.h will probably work
just fine.
--
- yiyus || JGL . 4l77.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 20:09 ` yy
@ 2010-09-14 20:38 ` yy
0 siblings, 0 replies; 19+ messages in thread
From: yy @ 2010-09-14 20:38 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
2010/9/12 yy <yiyu.jgl@gmail.com>:
> 2010/9/12 ron minnich <rminnich@gmail.com>:
>> Ah. It was 256 MB but Yiyus changed it 8 weeks ago to 64MB. Why?
>
> Sorry about that. It was after updating all the a/ files from the .ed
> scripts. It looks like I did not pay enough attention to mem.ed. There
> were other changes that could be causing problems too. I'm currently
> having another look at all the stuff in a/. It could take some time,
> but I will fix it. In the meantime, the old mem.h will probably work
> just fine.
The problem was in mem.ed. I have changed it and think it should work
well now, but the problem was in the original russ' file and all this
stuff is a bit over me. When you have some time, could you please have
a look at it and/or do some testing? For the moment I modified mem.ed
but not mem.h (just in case). To regenerate mem.h, run something like
this from src/9vx/a:
./AUTOGEN -r ~/sysfromiso/ /sys/src/9/pc/mem.h
Thanks
In other new: kfs support is in bootboot now, I'm currently running
9vx from a kfs file. It feels good.
--
- yiyus || JGL . 4l77.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] 9vx mk install chokes on gs
2010-09-12 15:44 ` Russ Cox
2010-09-12 16:48 ` erik quanstrom
@ 2010-09-12 17:12 ` ron minnich
1 sibling, 0 replies; 19+ messages in thread
From: ron minnich @ 2010-09-12 17:12 UTC (permalink / raw)
To: Russ Cox; +Cc: Fans of the OS Plan 9 from Bell Labs
On Sun, Sep 12, 2010 at 8:44 AM, Russ Cox <rsc@swtch.com> wrote:
> there might not be 2gb of contiguous address space to have.
> this is running inside a unix process.
Good reason :-)
What's interesting is I ran 9vx for quite some time and never hit an
issue until 8l had to load gs.
ron
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-09-14 20:38 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-11 23:07 [9fans] 9vx mk install chokes on gs ron minnich
2010-09-11 23:15 ` andrey mirtchovski
2010-09-11 23:35 ` Robert Ransom
2010-09-12 0:39 ` ron minnich
2010-09-12 0:49 ` ron minnich
2010-09-12 1:02 ` erik quanstrom
2010-09-12 2:25 ` ron minnich
2010-09-12 2:32 ` ron minnich
2010-09-12 3:44 ` ron minnich
2010-09-12 4:59 ` erik quanstrom
2010-09-12 6:27 ` ron minnich
2010-09-12 15:44 ` Russ Cox
2010-09-12 16:48 ` erik quanstrom
2010-09-12 18:19 ` Russ Cox
2010-09-12 19:13 ` ron minnich
2010-09-12 19:33 ` ron minnich
2010-09-12 20:09 ` yy
2010-09-14 20:38 ` yy
2010-09-12 17:12 ` ron minnich
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).