[9fans] 9vx mk install chokes on gs

[9fans] 9vx mk install chokes on gs

[ron minnich]

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

Re: [9fans] 9vx mk install chokes on gs

[andrey mirtchovski]

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

Re: [9fans] 9vx mk install chokes on gs

[Robert Ransom]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

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

Re: [9fans] 9vx mk install chokes on gs

[erik quanstrom]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

OK, the bigger user stack is committed to my vx32 at bitbucket.

ron

Re: [9fans] 9vx mk install chokes on gs

[erik quanstrom]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

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

Re: [9fans] 9vx mk install chokes on gs

[Russ Cox]

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

Re: [9fans] 9vx mk install chokes on gs

[erik quanstrom]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

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

Re: [9fans] 9vx mk install chokes on gs

[Russ Cox]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

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

Re: [9fans] 9vx mk install chokes on gs

[ron minnich]

Ah. It was 256 MB but Yiyus changed it 8 weeks ago to 64MB. Why?

ron

Re: [9fans] 9vx mk install chokes on gs

[yy]

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

Re: [9fans] 9vx mk install chokes on gs

[yy]

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