Re: [9fans] 9vx mk install chokes on gs
This operating system is so much fun it's unfair at times. term% grep Brk /dev/text | grep 8l 4684 8l Brk 0xdeba 0003ea58 = 0 "" 0x11d2943ddb0c6c28 0x11d2943ddb0ccdd0 4684 8l Brk 0xdeba 000570f8 00017494 1fa8 = 0 "" 0x11d2943ded6477a8 0x11d2943ded64cd98 4684 8l Brk 0xdeba 0006f798 00017492 1faa = 0 "" 0x11d2943df0d4fdb8 0x11d2943df0d553a8 4684 8l Brk 0xdeba 00087e38 0001749e 5966 = 0 "" 0x11d2943df747e2a0 0x11d2943df74834a8 4684 8l Brk 0xdeba 000a04d8 00017493 5966 = 0 "" 0x11d2943dfa538490 0x11d2943dfa53da80 4684 8l Brk 0xdeba 0011a5f8 00017498 5966 = 0 "" 0x11d2943e01998c40 0x11d2943e0199ede8 4684 8l Brk 0xdeba 00194718 0001749c 58ef = 0 "" 0x11d2943e0e012178 0x11d2943e0e017f38 4684 8l Brk 0xdeba 0020e838 00015298 = 0 "" 0x11d2943e2852e0c0 0x11d2943e285336b0 4684 8l Brk 0xdeba 00288958 0001528d = 0 "" 0x11d2943e3fb530d8 0x11d2943e3fb582e0 4684 8l Brk 0xdeba 004eaef8 58ef = 0 "" 0x11d2943e4efa5ed8 0x11d2943e4efac468 4684 8l Brk 0xdeba 0074d498 0001528d = 0 "" 0x11d2943ebc6be720 0x11d2943ebc6c4cb0 4684 8l Brk 0xdeba 009afa38 00015298 = 0 "" 0x11d2943f468a9f28 0x11d2943f468af518 4684 8l Brk 0xdeba 00c11fd8 00017494 58ef = 0 "" 0x11d2943fb61756b0 0x11d2943fb617b858 4684 8l Brk 0xdeba 00e74578 0001749b 58ef = 0 "" 0x11d294402504f7a8 0x11d2944025053a10 4684 8l Brk 0xdeba 010d6b18 0001749f 58ef = 0 "" 0x11d294409abb0fc8 0x11d294409abb5a00 4684 8l Brk 0xdeba 013390b8 0001749d 58ef = 0 "" 0x11d2944108610208 0x11d2944108616b80 4684 8l Brk 0xdeba 0159b658 58ef = 0 "" 0x11d29441807b3178 0x11d29441807b9ed8 4684 8l Brk 0xdeba 017fdbf8 00017497 58ef = 0 "" 0x11d294420ad4e328 0x11d294420ad54ca0 4684 8l Brk 0xdeba 01a60198 00015298 = 0 "" 0x11d29442921f5908 0x11d29442921fb6c8 4684 8l Brk 0xdeba 01cc2738 00017495 5966 = 0 "" 0x11d2944340477448 0x11d294434047ddc0 4684 8l Brk 0xdeba 01f24cd8 0001528d = 0 "" 0x11d29443d7559310 0x11d29443d7561fb0 4684 8l Brk 0xdeba 02187278 01cc2738 = 0 "" 0x11d294448ff77190 0x11d294448ff80600 4684 8l Brk 0xdeba 023e9818 0001528d = 0 "" 0x11d294452b014350 0x11d294452b01a8e0 4684 8l Brk 0xdeba 0264bdb8 00015298 = 0 "" 0x11d29445da7c2138 0x11d29445da7c8ab0 4684 8l Brk 0xdeba 028ae358 58ef = 0 "" 0x11d2944662799f20 0x11d29446627a00c8 4684 8l Brk 0xdeba 02b108f8 58ef = 0 "" 0x11d29446e574eec0 0x11d29446e57563f0 4684 8l Brk 0xdeba 02d72e98 0001528d = 0 "" 0x11d294476893e360 0x11d2944768944120 4684 8l Brk 0xdeba 02fd5438 0001749b 58ef = 0 "" 0x11d29447ed62c638 0x11d29447ed633398 4684 8l Brk 0xdeba 032379d8 00015298 = -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
On Sat, Sep 11, 2010 at 4:35 PM, Robert Ransom 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 = -1 "segments overlap" 0x11d294485d874150 0x11d294485d87c620 Oh well :-( ron
Re: [9fans] 9vx mk install chokes on gs
On Sat, 11 Sep 2010 16:07:54 -0700 ron minnich 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 signature.asc Description: PGP signature
Re: [9fans] 9vx mk install chokes on gs
get some more memory? :) On Sat, Sep 11, 2010 at 5:07 PM, ron minnich 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 > >
[9fans] 9vx mk install chokes on gs
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 and replica/pull on OS X
OK, just checked, and my vx32 repo at bitbucket.org has the cld patch. I guess yiyus committed it? ron
Re: [9fans] 9vx and replica/pull on OS X
2010/9/11 Paul Lalonde : > I'm getting essentially every file tagged as "locally modified; will not > update". The option -s for replica could help you with that. I have used replica from 9vx and it works (yes, a lot of warnings, but it works). However, what I usually do is to keep a sysfromiso hg repository at the root of the plan9 tree I'm using with 9vx and bind /sysfromiso to / in my profile. If you really want to use replica, you better use 9vx with a plan9 filesystem. If you don't have a real fossil server you can run one with qemu (or download mycroftiv's gridtoolsplus from 9gridchan.org, which includes ready to use images) and then, with my 9vx version (I think this should work with ron's tree too), you can boot running: $ cat >/tmp/127.ini <
Re: [9fans] 9VX failure
hg diff
diff -r c7e9b5edb8d4 src/9vx/main.c
--- a/src/9vx/main.cSun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/main.cFri Sep 03 16:58:16 2010 +0100
@@ -55,6 +55,7 @@
static voidbootinit(void);
static voidsiginit(void);
+static void machkeyinit(void);
static char* getuser(void);
static char* findroot(void);
@@ -80,6 +81,9 @@
char buf[1024];
Here you go, thanks Charles!
ron
/* Minimal set up to make print work. */
+#ifndef TLS
+ machkeyinit();
+#endif
setmach(&mach0);
coherence = nop;
quotefmtinstall();
@@ -695,9 +699,6 @@
void
mach0init(void)
{
-#ifndef TLS
- machkeyinit();
-#endif
conf.nmach = 1;
machinit(); /* common per-processor init */
diff -r c7e9b5edb8d4 src/9vx/sched.c
--- a/src/9vx/sched.c Sun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/sched.c Fri Sep 03 16:58:16 2010 +0100
@@ -158,6 +158,8 @@
m->machno, p->pid, p->text, kprocq.n, nrunproc);
unlock(&kprocq.lk);
punlock(&run);
+ while(p->mach != nil)
+ sched_yield();
return p;
}
diff -r c7e9b5edb8d4 src/Makefrag
--- a/src/Makefrag Sun Dec 27 09:49:22 2009 -0800
+++ b/src/Makefrag Fri Sep 03 16:58:16 2010 +0100
@@ -1,7 +1,7 @@
# Main top-level makefile fragment for the vx32 virtual machine.
# Compiler flags common to both host and VX32 environment files.
-COMMON_CFLAGS = -g -O3 -MD -std=gnu99 -I. $(CFLAGS)
+COMMON_CFLAGS = -g -O2 -MD -std=gnu99 -I. -fno-stack-protector $(CFLAGS)
#COMMON_CFLAGS = -g -MD -std=gnu99 -I. $(CFLAGS)
COMMON_LDFLAGS = -g -L. $(LDFLAGS)
diff -r c7e9b5edb8d4 src/libvx32/run32.S
--- a/src/libvx32/run32.S Sun Dec 27 09:49:22 2009 -0800
+++ b/src/libvx32/run32.S Fri Sep 03 16:58:16 2010 +0100
@@ -111,6 +111,7 @@
popl%edi
popl%esi
popl%ebx
+ cld
ret
@@ -128,6 +129,8 @@
// (DS/ES/SS were already restored by vxrun_return.)
movwVXEMU_HOST_VS(%eax),VSEG
+ cld
+
ret
// Don't put anything here!
Re: [9fans] 9VX failure
Try 2. sorry.
Thanks again to charles for finding that CLD issue.
ron
hg diff
diff -r c7e9b5edb8d4 src/9vx/main.c
--- a/src/9vx/main.cSun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/main.cFri Sep 03 16:58:16 2010 +0100
@@ -55,6 +55,7 @@
static voidbootinit(void);
static voidsiginit(void);
+static void machkeyinit(void);
static char* getuser(void);
static char* findroot(void);
@@ -80,6 +81,9 @@
char buf[1024];
/* Minimal set up to make print work. */
+#ifndef TLS
+ machkeyinit();
+#endif
setmach(&mach0);
coherence = nop;
quotefmtinstall();
@@ -695,9 +699,6 @@
void
mach0init(void)
{
-#ifndef TLS
- machkeyinit();
-#endif
conf.nmach = 1;
machinit(); /* common per-processor init */
diff -r c7e9b5edb8d4 src/9vx/sched.c
--- a/src/9vx/sched.c Sun Dec 27 09:49:22 2009 -0800
+++ b/src/9vx/sched.c Fri Sep 03 16:58:16 2010 +0100
@@ -158,6 +158,8 @@
m->machno, p->pid, p->text, kprocq.n, nrunproc);
unlock(&kprocq.lk);
punlock(&run);
+ while(p->mach != nil)
+ sched_yield();
return p;
}
diff -r c7e9b5edb8d4 src/Makefrag
--- a/src/Makefrag Sun Dec 27 09:49:22 2009 -0800
+++ b/src/Makefrag Fri Sep 03 16:58:16 2010 +0100
@@ -1,7 +1,7 @@
# Main top-level makefile fragment for the vx32 virtual machine.
# Compiler flags common to both host and VX32 environment files.
-COMMON_CFLAGS = -g -O3 -MD -std=gnu99 -I. $(CFLAGS)
+COMMON_CFLAGS = -g -O2 -MD -std=gnu99 -I. -fno-stack-protector $(CFLAGS)
#COMMON_CFLAGS = -g -MD -std=gnu99 -I. $(CFLAGS)
COMMON_LDFLAGS = -g -L. $(LDFLAGS)
diff -r c7e9b5edb8d4 src/libvx32/run32.S
--- a/src/libvx32/run32.S Sun Dec 27 09:49:22 2009 -0800
+++ b/src/libvx32/run32.S Fri Sep 03 16:58:16 2010 +0100
@@ -111,6 +111,7 @@
popl%edi
popl%esi
popl%ebx
+ cld
ret
@@ -128,6 +129,8 @@
// (DS/ES/SS were already restored by vxrun_return.)
movwVXEMU_HOST_VS(%eax),VSEG
+ cld
+
ret
// Don't put anything here!
Re: [9fans] 9VX failure
2010/9/11 Lucio De Re : > That bit was easy, just move the leading # from nopcap to etherpcap: >From now on, this is the default in my 9vx version: http://bitbucket.org/yiyus/vx32/ If anybody thinks pcap should be compiled by default, please let me know. > Now, where do I find Charles' fix for the segmentation error? I'm trying to find that one too. -- - yiyus || JGL . 4l77.com
Re: [9fans] 9VX failure
On Sat, Sep 11, 2010 at 01:46:16PM -0400, Devon H. O'Dell wrote: > > pcap is for the virtual ethernet driver to use the native ip stack. > there's another one that uses TAP that yiyus finalized from someone > else's efforts (I'm not giving due credit here, sorry). If you don't > have pcap just don't build etherve.c. > That bit was easy, just move the leading # from nopcap to etherpcap: #PLAN9PCAP=etherpcap PLAN9PCAP=nopcap Now, where do I find Charles' fix for the segmentation error? ++L
Re: [9fans] 9VX failure
pcap is for the virtual ethernet driver to use the native ip stack. there's another one that uses TAP that yiyus finalized from someone else's efforts (I'm not giving due credit here, sorry). If you don't have pcap just don't build etherve.c. --dho 2010/9/11 Lucio De Re : > On Sat, Sep 11, 2010 at 10:24:05AM -0700, ron minnich wrote: >> >> >> > Is that included in rminnich/vx32, where default compilation fails with >> > a missing "pcap.h"? >> >> the pcap.h thing is unrelated and I think I'm going to change it so >> that it builds default with no pcap support, since I'm not the only >> person seeing this build error. >> >> no, I have to get his patch included. I had a question in to his >> customer support people about the patch first before i went with the >> patch :-) >> > That means that there are two patches required here: Charles' adjustment > (why have I not seen it, I wonder) and the pcap.h thing. Can you post > them here in the interim? I'm not sure I want to know why pcap.h is > being included and not found... > > ++L > >
Re: [9fans] 9VX failure
On Sat, Sep 11, 2010 at 10:24:05AM -0700, ron minnich wrote: > >> > > Is that included in rminnich/vx32, where default compilation fails with > > a missing "pcap.h"? > > the pcap.h thing is unrelated and I think I'm going to change it so > that it builds default with no pcap support, since I'm not the only > person seeing this build error. > > no, I have to get his patch included. I had a question in to his > customer support people about the patch first before i went with the > patch :-) > That means that there are two patches required here: Charles' adjustment (why have I not seen it, I wonder) and the pcap.h thing. Can you post them here in the interim? I'm not sure I want to know why pcap.h is being included and not found... ++L
Re: [9fans] 9VX failure
On Sat, Sep 11, 2010 at 10:18 AM, Lucio De Re wrote: > On Sat, Sep 11, 2010 at 09:34:20AM -0700, ron minnich wrote: >> >> I am pretty sure Charle's patch will fix this problem >> > Is that included in rminnich/vx32, where default compilation fails with > a missing "pcap.h"? the pcap.h thing is unrelated and I think I'm going to change it so that it builds default with no pcap support, since I'm not the only person seeing this build error. no, I have to get his patch included. I had a question in to his customer support people about the patch first before i went with the patch :-) ron
Re: [9fans] 9VX failure
On Sat, Sep 11, 2010 at 09:34:20AM -0700, ron minnich wrote: > > I am pretty sure Charle's patch will fix this problem > Is that included in rminnich/vx32, where default compilation fails with a missing "pcap.h"? What should I be looking for? ++L
Re: [9fans] 9vx and replica/pull on OS X
Hi, I just did a fresh pull for my sysfromiso tree from bitbucket, mk nuke etc. and it built fine. It's a lot of fun to look at, e.g., http://bitbucket.org/rminnich/sysfromiso/changeset/147b5c83d6f4 and see all the good stuff still being done on this kernel :-) ron
Re: [9fans] 9VX failure
I am pretty sure Charle's patch will fix this problem ron
Re: [9fans] 9vx and replica/pull on OS X
On Fri, Sep 10, 2010 at 10:32 PM, erik quanstrom wrote: >> > What am I doing wrong? >> >> I would argue that, while it is quite cool in principle, replica is >> the wrong way to solve the source distribution problem. I gave up on >> replica a year ago because I got tired of the kinds of problems you're >> having. > > while some much-needed patches have been slow in > being applied, i don't think bugs (or a broken 9vx #Z) > imply that replica is just wrong way to replicate changes > to sources. > While that may be true, my experiences with replica have been pretty dreadful. I'm just not smart enough to use it properly I guess. The other aspect with using it with 9vx is that it gives me easy rollbacks since my 9vx bits on my mac aren't currently protected by Venti. -eric
Re: [9fans] 9VX failure
On Sat, Sep 11, 2010 at 09:02:36AM +0200, Lucio De Re wrote: > > I was hoping to try 9vx.tgz from swtch.com which is not 9vx*.bz2, but > that does not behave any differently. > s/not 9/now 9/ ++L
[9fans] 9VX failure
Not much more than init: starting /bin/rc Segmentation fault from a freshly compiled 9vx or the 9vx.Linux contained in the HG repository on bitbucket.org. I was hoping to try 9vx.tgz from swtch.com which is not 9vx*.bz2, but that does not behave any differently. The platform Linux fangle 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:24:04 UTC 2010 i686 GNU/Linux Ubuntu Lucid Lynx on an HP Laptop. ++L
Re: [9fans] 9vx and replica/pull on OS X
> > What am I doing wrong? > > I would argue that, while it is quite cool in principle, replica is > the wrong way to solve the source distribution problem. I gave up on > replica a year ago because I got tired of the kinds of problems you're > having. while some much-needed patches have been slow in being applied, i don't think bugs (or a broken 9vx #Z) imply that replica is just wrong way to replicate changes to sources. i was able to migrate 8 years of dumps from old 32-bit filesytems with nothing (not a byte) lost in translation with replica. contrib quanstro/replica has the modest changes i made. i belive some of the change have been applied to sources. - erik
Re: [9fans] 9vx and replica/pull on OS X
On Fri, Sep 10, 2010 at 6:24 PM, Paul Lalonde wrote: > What am I doing wrong? I would argue that, while it is quite cool in principle, replica is the wrong way to solve the source distribution problem. I gave up on replica a year ago because I got tired of the kinds of problems you're having. sysfromiso is pretty up-to-date and it's pretty darn fast to pull down. I build arm kernels on it. http://bitbucket.org/rminnich/sysfromiso If you have questions let me know. ron
Re: [9fans] 9vx and replica/pull on OS X
FWIW, Ron's got a regularly updated snapshot of the source tree in mercurial -- he and I have been using that to keep our 9vx plan 9 directories up to date -- works faster, better, and is more reliable than replica. Using floren's python installation you can even use it under Plan 9. -eric On Fri, Sep 10, 2010 at 8:24 PM, Paul Lalonde wrote: > I want to build a kw kernel, which caused me to want to update my 9vx > installation. > Have my file system on a case-sensitive remote mounted drive. > I'm getting essentially every file tagged as "locally modified; will not > update". > When a file is good, I get a warning that I can't set the uid; I can > probably live with that. > So I grabbed a fresh plan9.tar.bz2 from Russ's site, and tried it. Same > thing. > What am I doing wrong? > > Paul > -- > I'm migrating my email. plalo...@telus.net will soon be disconnected. > Please use paul.a.lalo...@gmail.com from now on. > >
[9fans] 9vx and replica/pull on OS X
I want to build a kw kernel, which caused me to want to update my 9vx installation. Have my file system on a case-sensitive remote mounted drive. I'm getting essentially every file tagged as "locally modified; will not update". When a file is good, I get a warning that I can't set the uid; I can probably live with that. So I grabbed a fresh plan9.tar.bz2 from Russ's site, and tried it. Same thing. What am I doing wrong? Paul -- I'm migrating my email. plalo...@telus.net will soon be disconnected. Please use paul.a.lalo...@gmail.com from now on.
Re: [9fans] 9vx, kproc and *double sleep*
On Sun, Jun 13, 2010 at 11:03 AM, Philippe Anel wrote: > I tried with adding : > > while (p->mach) > sched_yield(); > > > at the end of sched.c:^runproc(), before the return. > > It seems to work well. > > What do you think ? Not sure I understand all the implications but I'll try anything at this point :-) I'm trying now with -O3 back on. The -O3 was a red herring. ron
Re: [9fans] 9vx, kproc and *double sleep*
If anyone can help me with some valgrind patches we can see if valgrind can be useful. Charles, I am really puzzled about your ubuntu experience. Oh, wait, can you set LANG=C and try again? Or is it? BTW when you get the immediate explosion does a window even ever come up or does it die before that? ron
Re: [9fans] 9vx, kproc and *double sleep*
Charles, Can you please give us stack information with gdb ? Phil; On Mon, 2010-06-14 at 20:15 +0100, Charles Forsyth wrote: > it's interesting that neither of philippe's changes, > however justified, make any visible difference > to 9vx on my ubuntu 10.04LTS system: 9vx still > fails almost immediately. that's consistent with > 9vx behaving itself as well as on any other platform > until i changed the linux and/or ubuntu version. > i'll see if i can brave gdb some more to find out. >
Re: [9fans] 9vx, kproc and *double sleep*
it's interesting that neither of philippe's changes, however justified, make any visible difference to 9vx on my ubuntu 10.04LTS system: 9vx still fails almost immediately. that's consistent with 9vx behaving itself as well as on any other platform until i changed the linux and/or ubuntu version. i'll see if i can brave gdb some more to find out.
Re: [9fans] 9vx, kproc and *double sleep*
i wasn't clear enough what i meant by `interrupt handler'. i didn't mean the device-specific function, but its caller. in pc/trap.c you see if(up && !clockintr) preempted(); and on other platforms (perhaps not enough) there are calls to preempted() in the interrupt handler(s) that despatch the device-specific ones. preempted calls sched, which can switch to another process before returning.--- Begin Message --- > that's only because the clock interrupt handler directly or indirectly (eg, > via sched) calls spllo, and other trap or interrupt handlers could do that. wouldn't that be fatal with shared 8259 interrupts? - erik--- End Message ---
Re: [9fans] 9vx, kproc and *double sleep*
I tried with adding : while (p->mach) sched_yield(); at the end of sched.c:^runproc(), before the return. It seems to work well. What do you think ? Phil;
Re: [9fans] 9vx, kproc and *double sleep*
Hi,
The solution is not that simple. I mean when kprocs go to sleep
through the call to psleep(), a pwakeup() is required. We cannot
simply change the following sched.c:^runproc() part :
while((p = kprocq.head) == nil){
by:
while(((p = kprocq.head) == nil) || p->mach){
The a/proc.c scheduler is different as it goes idle and can be
awakened by an interrupt (or a working kproc in 9vx).
Phil;
So is changing 9vx/sched.c to do these two steps the real fix?
ron
Re: [9fans] 9vx, kproc and *double sleep*
Should be, at least I think so. But I don't even know yet how we can do this. :) I think we can use the go trick and postpone the call to ready() while p->mach != 0. But I don't know where yet. Phil; ron minnich wrote: On Sun, Jun 13, 2010 at 7:26 AM, Philippe Anel wrote: In fact you're right, and this shows us this would only happens to 9vx. Indeed, the proc is a kproc and thus is not scheduled by the 9vx/a/proc.c scheduler, but by the one in 9vx/sched.c ... where dequeueproc() is not called and where p->mach is not checked. So is changing 9vx/sched.c to do these two steps the real fix? ron
Re: [9fans] 9vx, kproc and *double sleep*
On Sun, Jun 13, 2010 at 7:26 AM, Philippe Anel wrote: > In fact you're right, and this shows us this would only happens to 9vx. > Indeed, the proc is a kproc and thus is not scheduled by the 9vx/a/proc.c > scheduler, > but by the one in 9vx/sched.c ... where dequeueproc() is not called and > where p->mach > is not checked. So is changing 9vx/sched.c to do these two steps the real fix? ron
Re: [9fans] 9vx, kproc and *double sleep*
In fact you're right, and this shows us this would only happens to 9vx.
Indeed, the proc is a kproc and thus is not scheduled by the
9vx/a/proc.c scheduler,
but by the one in 9vx/sched.c ... where dequeueproc() is not called and
where p->mach
is not checked.
Thank you !
Phil;
Richard Miller wrote:
Philippe said:
Again, the change I proposed is not about sleep/wakeup/postnote, but
because wakeup() is ready()'ing the awakened process while the mach on
which sleep() runs is still holdind a pointer (up) to the awakened
process and can later (in schedinit()) assumes it is safe to access
(up)->state. Because of this, schedinit() can tries to call ready() on
(up), because because (up)->state may have been changed to Running by
a third mach entity.
and I tried to summarize:
It's a race between a process in sleep() returning to the scheduler on
cpu A, and the same process being readied and rescheduled on cpu B
after the wakeup.
But after further study of proc.c, I now believe we were both wrong.
A process on the ready queue can only be taken off the queue and
scheduled by calling dequeueproc(), which contains this:
/*
* p->mach==0 only when process state is saved
*/
if(p == 0 || p->mach){
unlock(runq);
return nil;
}
So the process p can only be scheduled (i.e. p->state set to Running)
if p->mach==nil.
The only place p->mach gets set to nil is in schedinit(), *after*
the test for p->state==Running.
This seems to mean there isn't a race after all, and Philippe's
thought experiment is impossible.
Am I missing something?
Re: [9fans] 9vx, kproc and *double sleep*
> that's only because the clock interrupt handler directly or indirectly (eg, > via sched) calls spllo, and other trap or interrupt handlers could do that. wouldn't that be fatal with shared 8259 interrupts? - erik
Re: [9fans] 9vx, kproc and *double sleep*
Philippe said:
> Again, the change I proposed is not about sleep/wakeup/postnote, but
> because wakeup() is ready()'ing the awakened process while the mach on
> which sleep() runs is still holdind a pointer (up) to the awakened
> process and can later (in schedinit()) assumes it is safe to access
> (up)->state. Because of this, schedinit() can tries to call ready() on
> (up), because because (up)->state may have been changed to Running by
> a third mach entity.
and I tried to summarize:
> It's a race between a process in sleep() returning to the scheduler on
> cpu A, and the same process being readied and rescheduled on cpu B
> after the wakeup.
But after further study of proc.c, I now believe we were both wrong.
A process on the ready queue can only be taken off the queue and
scheduled by calling dequeueproc(), which contains this:
/*
* p->mach==0 only when process state is saved
*/
if(p == 0 || p->mach){
unlock(runq);
return nil;
}
So the process p can only be scheduled (i.e. p->state set to Running)
if p->mach==nil.
The only place p->mach gets set to nil is in schedinit(), *after*
the test for p->state==Running.
This seems to mean there isn't a race after all, and Philippe's
thought experiment is impossible.
Am I missing something?
Re: [9fans] 9vx, kproc and *double sleep*
> - splhi -- it's not a true splhi in some sense; is it possible that > some code is sneaking in and running even when you splhi()? Could this > explain it? The error Philippe has found is only indirectly related to splhi(). It's a race between a process in sleep() returning to the scheduler on cpu A, and the same process being readied and rescheduled on cpu B after the wakeup. On native plan 9, A always wins the race because it runs splhi() and the code path from sleep to schedinit (where up->state==Running is checked) is shorter than the code path from runproc to the point in sched where up->state is set to Running. But the fact that this works is timing-dependent: if cpu A for some reason ran slower than cpu B, it could lose the race even without being interrupted. As Philippe explained, in 9vx the cpus are being simulated by threads. Because these threads are being scheduled by the host operating system, the virtual cpus can appear to be running at different speeds or to pause at awkward moments. Even without any "preemption" at the plan 9 level of abstraction, the timing assumption which prevents the sleep - reschedule race is no longer guaranteed.
Re: [9fans] 9vx, kproc and *double sleep*
> FYI, I've wondered if they had the same problem in go runtime because > I suspected the code to be quite similar. And I think go team fixed the > problem in ready() equivalent in go runtime, by adding a flag in Proc > equivalent so the proc (G in go) is put back to the run queue ... are you sure? that big scheduler lock looks like it's doing the job of splhi() to me. - erik
Re: [9fans] 9vx, kproc and *double sleep*
On Sat, Jun 12, 2010 at 3:15 PM, Charles Forsyth wrote: >>in Linux parlance, Plan 9 is a "preemptible" kernel. Interrupt handlers can >>be interrupted, so to speak. > > interrupt handlers are not normally interruptible during the interrupt > processing, but rather at the end (eg, when anyhigher, anyready or preempted > is called). Yes, I was not careful enough in how I said that. For those who wonder what I was trying to say, see trap(); note what happens after the isr() is called and look where preempted() is called. But, all this said, the problems we're seeing on 9vx are strangely similar to the ones I had on Xen when code that was not supposed to be interrupted got interrupted. There may be no real connection at all however. ron
Re: [9fans] 9vx, kproc and *double sleep*
>in Linux parlance, Plan 9 is a "preemptible" kernel. Interrupt handlers can be >interrupted, so to speak. interrupt handlers are not normally interruptible during the interrupt processing, but rather at the end (eg, when anyhigher, anyready or preempted is called). processes running at non-interrupt level in the kernel can be interrupted unless they are splhi or using ilock. >Except for the clock interrupt handler that's only because the clock interrupt handler directly or indirectly (eg, via sched) calls spllo, and other trap or interrupt handlers could do that.
Re: [9fans] 9vx, kproc and *double sleep*
There's kind of an interesting similarity here to what I had to deal with on the Xen port. So, a few random thoughts, probably useless, from early problems of this sort I've had. - in Linux parlance, Plan 9 is a "preemptible" kernel. Interrupt handlers can be interrupted, so to speak. Except for the clock interrupt handler: you have to check the interrupt number to make sure you are not pre-empting the clock interrupt handler. Sorry if I'm not saying this very well. On Xen and lguest I had to make sure of this (I mention this in the lguest port talk slides) - splhi -- it's not a true splhi in some sense; is it possible that some code is sneaking in and running even when you splhi()? Could this explain it? - What other aspect of the transition from hardware to software-in-sandbox might explain a non-premptible bit of code getting pre-empted? OK, back to fixing my 1990 civic :-) ron -
Re: [9fans] 9vx, kproc and *double sleep*
> - does richard miller's alternate implementation of wakeup > solve this problem. No, it doesn't.
Re: [9fans] 9vx, kproc and *double sleep*
9fans,
FYI, I've wondered if they had the same problem in go runtime because
I suspected the code to be quite similar. And I think go team fixed the
problem in ready() equivalent in go runtime, by adding a flag in Proc
equivalent so the proc (G in go) is put back to the run queue ...
Phil;
In go/src/pkg/runtime/proc.c:
>-<
// Mark g ready to run. Sched is already locked. G might be running
// already and about to stop. The sched lock protects g->status from
// changing underfoot.
static void
readylocked(G *g)
{
if(g->m){
// Running on another machine.
// Ready it when it stops.
g->readyonstop = 1;
return;
}
...
>-<
// Scheduler loop: find g to run, run it, repeat.
static void
scheduler(void)
{
lock(&sched);
...
if(gp->readyonstop){
gp->readyonstop = 0;
readylocked(gp);
}
...
Re: [9fans] 9vx, kproc and *double sleep*
Hi, I really think the spin model is good. And in fact, I really think current sleep/wakeup/postnote code is good. However, this model makes the assumption that plan9 processes are really Machs and not coroutines. I think we need a larger model, which includes the scheduler. I mean a model that describes a set of processes (in spin meaning), picking one kind of coroutine objects from a run queue (shared by all spin processes) and then calling sleep/wakeup/postnote a few times before putting the coroutine object back to the run queue. These spin processes would represent the cpus (or Machs) while coroutine objects would represent the plan9 processes. I even think we don't have to simulate the fact these processes can be interrupted. Again, the change I proposed is not about sleep/wakeup/postnote, but because wakeup() is ready()'ing the awakened process while the mach on which sleep() runs is still holdind a pointer (up) to the awakened process and can later (in schedinit()) assumes it is safe to access (up)->state. Because of this, schedinit() can tries to call ready() on (up), because because (up)->state may have been changed to Running by a third mach entity. This change only updates schedinit() (and tries) to make (up)->state access safe when it happens after a sleep() is awakened. Phil; in any event, given the long history with sleep/wakeup, changes should be justified with a promula model. the current model omits the spl* and the second lock. (http://swtch.com/spin/sleep_wakeup.txt). - erik
Re: [9fans] 9vx, kproc and *double sleep*
You can download my own (ugly) 9vx source code here : http://www.bouyapop.org/9vxigh.tar.bz2 In 9vx you'll find .gdbinit and crash.c. Just copy it to vx32 and replace 9vx folder, compile it and execute it under gdb with you own 9vx env. (gdb) r -F -r then compile and execute crash.c with 8c/8l. When it crashes, you can watch the latest logs with the gdb command k9logs 100 (it will show you 100 last ops). Phil; Bakul Shah wrote: On Fri, 11 Jun 2010 19:31:58 +0200 Philippe Anel wrote: I only did my tests on 9vx. I have a version that I instrumented with a circular log buffer, and I have some gdb macros which dumps the buffer. I can put the whole source somewhere and even a log with my comments of the bug if you want to see it. But please note that I made several Yes, please. Thanks! changes (because I had to understand how it works) and I would rather copy my changes to the latest 9vx source tree so that everyone can read it. What do you think ? Agreed. Best to check this in on a separate branch though. Branching/merging is cheap in hg. Please, I would like to insist on the fact I'm not saying the promela model is wrong. And I realize that the fix I propose might not be the good one. Maybe the problem is even elsewhere. All these is just feelings, logs and headache. I haven't used promela so can't say anything about it. sleep() is pretty complicated so figuring it out will take some time and effort but I first have to understand the cause and from past experience I know that code to check a cause hypothesis can be quite valuable (hence my earlier question). An unambiguous proof of what went wrong somehow frees my mind to better focus on the solution! Thanks for your thought experiements & code!
Re: [9fans] 9vx, kproc and *double sleep*
> I haven't used promela so can't say anything about it. http://spinroot.com/spin/Man/index.html - erik
Re: [9fans] 9vx, kproc and *double sleep*
On Fri, 11 Jun 2010 19:31:58 +0200 Philippe Anel wrote: > > I only did my tests on 9vx. I have a version that I instrumented with > a circular log buffer, and I have some gdb macros which dumps the > buffer. > > I can put the whole source somewhere and even a log with my comments > of the bug if you want to see it. But please note that I made several Yes, please. Thanks! > changes (because I had to understand how it works) and I would rather > copy my changes to the latest 9vx source tree so that everyone can > read it. What do you think ? Agreed. Best to check this in on a separate branch though. Branching/merging is cheap in hg. > Please, I would like to insist on the fact I'm not saying the promela > model is wrong. And I realize that the fix I propose might not be the > good one. Maybe the problem is even elsewhere. All these is just > feelings, logs and headache. I haven't used promela so can't say anything about it. sleep() is pretty complicated so figuring it out will take some time and effort but I first have to understand the cause and from past experience I know that code to check a cause hypothesis can be quite valuable (hence my earlier question). An unambiguous proof of what went wrong somehow frees my mind to better focus on the solution! Thanks for your thought experiements & code!
Re: [9fans] 9vx, kproc and *double sleep*
I only did my tests on 9vx. I have a version that I instrumented with
a circular log buffer, and I have some gdb macros which dumps the
buffer.
I can put the whole source somewhere and even a log with my comments
of the bug if you want to see it. But please note that I made several
changes (because I had to understand how it works) and I would rather
copy my changes to the latest 9vx source tree so that everyone can
read it. What do you think ?
At the end of this post I added some part of the instruments.
Please, I would like to insist on the fact I'm not saying the promela
model is wrong. And I realize that the fix I propose might not be the
good one. Maybe the problem is even elsewhere. All these is just
feelings, logs and headache.
Phil;
The logs look like this :
(gdb) k9log 10
- kernel history size: 524288
element size: 64
element count: 8192
History stack: 56300 elems:
dbeb: m= 3 pc=44e235 sp=51f02020 up=0 :0 xp=0 :0 r=
0 a= 0 # kproc: runproc: psleep
dbea: m= 3 pc=44e235 sp=51f02020 up=0 :0 xp=0 :0 r=
0 a= 0 # kproc: runproc: search
dbe9: m= 3 pc=44e235 sp=51f02020 up=0 :0 xp=0 :0 r=
0 a= 0 # kproc: runproc
dbe8: m= 3 pc=44dfb2 sp=51f02070 up=0 :0 xp=4 :8 r=
0 a= 0 # proc: sched: calling runproc
dbe7: m= 3 pc=44dfb2 sp=51f02070 up=0 :0 xp=4 :8 r=
0 a= 0 # proc: sched
dbe6: m= 3 pc=40e41b sp=51f020b0 up=4 :8 xp=0 :0 r=
0 a= 0 # proc: schedinit: disable up
dbe5: m= 3 pc=40e41b sp=51f020b0 up=4 :8 xp=0 :0 r=
983360 a= 0 # proc: sleep: unlock r
dbe4: m= 3 pc=40e41b sp=51f020b0 up=4 :8 xp=0 :0 r=
983360 a= 0 # proc: sleep: unlock up
dbe3: m= 3 pc=40e41b sp=51f020b0 up=4 :8 xp=0 :0 r=
0 a= 0 # proc: schedinit: up still active
dbe2: m= 3 pc=40e41b sp=51f020b0 up=4 :8 xp=0 :0 r=
0 a= 0 # proc: schedinit: start
where the first column is the serial of the logged operation, and 'a'
just a int.
-
void
sleep(Rendez *r, int (*ftest)(void*), void *arg)
{
int s;
void (*pt)(Proc*, int, vlong);
void * pc;
pc = getcallerpc(&r);
k9log("proc: sleep", pc, 0, r, 0);
s = splhi();
if (up == nil)
dbgbreak();
k9log("proc: sleep: lock r", pc, 0, r, 0);
lock(&r->xlk);
if(r->xp){
k9log("proc: sleep: ** double sleep **", pc, r->xp, r, 0);
panic("cpu%d: up=%d *double sleep* r=%p r->p=%d caller=%p\n",
m->machno, up ? up->pid : 0, r, r->xp ? r->xp->pid : 0, pc);
}
/*
* Wakeup only knows there may be something to do by testing
* r->p in order to get something to lock on.
* Flush that information out to memory in case the sleep is
* committed.
*/
r->xp = up;
r->xm = m;
r->xpc = pc;
k9log("proc: sleep: lock up", pc, 0, r, 0);
lock(&up->rlock);
//if (up->state != Running)
//dbgbreak();
k9log("proc: sleep: condition", pc, 0, r, up->nlocks.ref);
if ((*ftest)(arg)) {
k9log("proc: sleep: happened", pc, 0, r, 0);
done:
/*
* if condition happened or a note is pending
* never mind
*/
r->xp = nil;
k9log("proc: sleep: unlock up", pc, 0, r, 0);
unlock(&up->rlock);
k9log("proc: sleep: unlock r", pc, 0, r, 0);
unlock(&r->xlk);
}
else if (up->notepending) {
k9log("proc: sleep: note pending", pc, 0, r, 0);
goto done;
}
else {
/*
* now we are committed to
* change state and call scheduler
*/
pt = proctrace;
if(pt)
pt(up, SSleep, 0);
up->state = Wakeme;
up->rx = r;
/* statistics */
m->cs++;
k9log("proc: sleep: sleeping", pc, 0, r, 0);
procsave(up);
if(setlabel(&up->sched)) {
/*
* here when the process is awakened
*/
k9log("proc: sleep: awakened", pc, r->xp, r, 0);
procrestore(up);
spllo();
} else {
/*
* here to go to sleep (i.e. stop Running)
*/
//up->rmu = 1;
//k9log("proc: sleep: unlock up", pc, 0, r, 0);
//unlock(&up->rlock);
//k9log("proc: sleep: unlock r", pc, 0, r, 0);
//unlock(&r->xlk);
k9log("proc: sleep: going sched", pc, 0, r, 0);
gotolabel(&m->sched);
}
}
k9log("proc: sleep: done", pc, 0, r, 0);
if(up->notepending) {
k9log("proc: sleep: forward note", pc, 0, r, 0);
up->notepending = 0;
splx(s);
if(up->procctl == Proc_exitme && up->closingfgrp)
forceclosefgrp();
error(Eintr);
}
splx(s);
}
struct {
int32 count;
Re: [9fans] 9vx, kproc and *double sleep*
On Fri, 11 Jun 2010 16:59:42 +0200 Philippe Anel wrote: > Ooops I forgot to answer this : > > - does changing spl* to manipulation of a per-cpu lock solve the problem? > > sometimes preventing anything else from running on your mach is > > exactly what you want. > > > No ... I don't think so. I think the problem comes from the fact the > process is no longer exclusively tied to the current Mach when going > (back) to schedinit() ... hence the change I did. Were you able to verify your hypothesis by adding a bit of trapping code + assertion(s) in the original sources? At the point of double sleep one can check state to see if the expected preconditions are true. Alternatively one can check when the expected conditions become true, set a variable and test it where the double sleep print occurs. Then one can sort of walk back to the earliest point where things go wrong.
Re: [9fans] 9vx, kproc and *double sleep*
On Fri, Jun 11, 2010 at 8:04 AM, erik quanstrom wrote: > please wait. we still don't understand this problem > very well. (why does this work on real hardware?) all the 9vx failures I have seen are with the kexec threads. This is a major 0vx change from 9. I do think that there is something in what Phillipe is saying. ron
Re: [9fans] 9vx, kproc and *double sleep*
Oooops ... sorry for double copy :) The post was supposed to be : I never seen it on real hardware but I think it does not mean it cannot happen. The problem in 9vx comes from the fact 9vx Mach are simulated by pthreads which can be scheduled just before calling gotolabel in sleep(). This gives the time to another Mach (or pthread) to 'readies' the proc A. I think it does not happen on real hardware because the cpu just don't stop while calling gotolabel() and executes the scheduler. It does not happen because the cpu is not interupted (thanks to splhi). But still, I feel the problem is here, and we can imagine ... why not, the cpu running proc A blocking on a bus request or something else. I don't know if the model is good or not ... and as I wrote, this is only a thougth experiment ... with my poor brain :) Phil; Philippe Anel wrote: I never seen it on real hardware but I think it does not mean it cannot happen. The problem in 9vx comes from the fact 9vx Mach are simulated by pthreads which can be scheduled just before calling gotolabel in sleep(). This gives the time to another Mach (or pthread) to 'readies' the proc A. I never seen it on real hardware but I think it does not mean it cannot happen. The problem in 9vx comes from the fact 9vx Mach are simulated by pthreads which can be scheduled just before calling gotolabel in sleep(). This gives the time to another Mach (or pthread) to 'readies' the proc A. I think it does not happen on real hardware because the cpu just don't stop while calling gotolabel() and executes the scheduler. It does not happen because the cpu is not interupted (thanks to splhi). But still, I feel the problem is here, and we can imagine ... why not, the cpu running proc A blocking on a bus request or something else. I don't know if the model is good or not ... and I wrote this is only a thougth experiment ... with my poor brain :) I think it does not happen on real hardware because the cpu just don't stop while calling gotolabel() and executes the scheduler. It does not happen because the cpu is not interupted (thanks to splhi). But still, I feel the problem is here, and we can imagine ... why not, the cpu running proc A blocking on a bus request or something else. I don't know if the model is good or not ... and I wrote this is only a thougth experiment ... with my poor brain :) Phil; erik quanstrom wrote: On Fri Jun 11 10:54:40 EDT 2010, x...@bouyapop.org wrote: I don't think either splhi fixes the problem ... it only hides it for the 99.9% cases. on a casual reading, i agree. unfortunately, the current simplified promela model disagrees, and coraid has run millions of cpu-hrs on quad processor machines running near 100% load with up to 1500 procs, and never seen this. unless you have a good reason why we've never seen such a deadlock, i'm inclined to believe we're missing something. we need better reasons for sticking locks in than guesswork. multiple locks can easily lead to deadlock. have you tried your solution with a single Mach? No ... I don't think so. I think the problem comes from the fact the process is no longer exclusively tied to the current Mach when going (back) to schedinit() ... hence the change I did. have you tried? worst case is you'll have more information on the problem. - erik
Re: [9fans] 9vx, kproc and *double sleep*
I never seen it on real hardware but I think it does not mean it cannot happen. The problem in 9vx comes from the fact 9vx Mach are simulated by pthreads which can be scheduled just before calling gotolabel in sleep(). This gives the time to another Mach (or pthread) to 'readies' the proc A. I never seen it on real hardware but I think it does not mean it cannot happen. The problem in 9vx comes from the fact 9vx Mach are simulated by pthreads which can be scheduled just before calling gotolabel in sleep(). This gives the time to another Mach (or pthread) to 'readies' the proc A. I think it does not happen on real hardware because the cpu just don't stop while calling gotolabel() and executes the scheduler. It does not happen because the cpu is not interupted (thanks to splhi). But still, I feel the problem is here, and we can imagine ... why not, the cpu running proc A blocking on a bus request or something else. I don't know if the model is good or not ... and I wrote this is only a thougth experiment ... with my poor brain :) I think it does not happen on real hardware because the cpu just don't stop while calling gotolabel() and executes the scheduler. It does not happen because the cpu is not interupted (thanks to splhi). But still, I feel the problem is here, and we can imagine ... why not, the cpu running proc A blocking on a bus request or something else. I don't know if the model is good or not ... and I wrote this is only a thougth experiment ... with my poor brain :) Phil; erik quanstrom wrote: On Fri Jun 11 10:54:40 EDT 2010, x...@bouyapop.org wrote: I don't think either splhi fixes the problem ... it only hides it for the 99.9% cases. on a casual reading, i agree. unfortunately, the current simplified promela model disagrees, and coraid has run millions of cpu-hrs on quad processor machines running near 100% load with up to 1500 procs, and never seen this. unless you have a good reason why we've never seen such a deadlock, i'm inclined to believe we're missing something. we need better reasons for sticking locks in than guesswork. multiple locks can easily lead to deadlock. have you tried your solution with a single Mach? No ... I don't think so. I think the problem comes from the fact the process is no longer exclusively tied to the current Mach when going (back) to schedinit() ... hence the change I did. have you tried? worst case is you'll have more information on the problem. - erik
Re: [9fans] 9vx, kproc and *double sleep*
On Fri Jun 11 10:54:40 EDT 2010, x...@bouyapop.org wrote: > I don't think either splhi fixes the problem ... it only hides it for > the 99.9% cases. on a casual reading, i agree. unfortunately, the current simplified promela model disagrees, and coraid has run millions of cpu-hrs on quad processor machines running near 100% load with up to 1500 procs, and never seen this. unless you have a good reason why we've never seen such a deadlock, i'm inclined to believe we're missing something. we need better reasons for sticking locks in than guesswork. multiple locks can easily lead to deadlock. have you tried your solution with a single Mach? > No ... I don't think so. I think the problem comes from the fact the > process is no longer exclusively tied to the current Mach when going > (back) to schedinit() ... hence the change I did. have you tried? worst case is you'll have more information on the problem. - erik
Re: [9fans] 9vx, kproc and *double sleep*
On Fri Jun 11 11:03:32 EDT 2010, rminn...@gmail.com wrote: > I'm going to put this change into my hg repo for 9vx and do some > testing; others are welcome to as well. > > That's a pretty interesting catch. please wait. we still don't understand this problem very well. (why does this work on real hardware?) i'd hate to just swap buggy implementations of sleep/wakeup. - erik
Re: [9fans] 9vx, kproc and *double sleep*
I'm going to put this change into my hg repo for 9vx and do some testing; others are welcome to as well. That's a pretty interesting catch. ron
Re: [9fans] 9vx, kproc and *double sleep*
On Fri, Jun 11, 2010 at 2:49 PM, Philippe Anel wrote: > Schedinit() initialize the scheduler label ... on which sleep() goes when > calling gotolabel(&m->sched). > > Phil; yep. Toldja I was not awake yet. ron
Re: [9fans] 9vx, kproc and *double sleep*
Ooops I forgot to answer this : - does changing spl* to manipulation of a per-cpu lock solve the problem? sometimes preventing anything else from running on your mach is exactly what you want. No ... I don't think so. I think the problem comes from the fact the process is no longer exclusively tied to the current Mach when going (back) to schedinit() ... hence the change I did. Phil;
Re: [9fans] 9vx, kproc and *double sleep*
I don't think either splhi fixes the problem ... it only hides it for the 99.9% cases. Phil; erik quanstrom wrote: schedinit only runs once and sleep runs all the time. That's the part I don't get. gotolabel in sleep sends you back to the setlabel at the top of schedinit. But you might have found something, I sure wish I understood it all better :-) i'm not entirely convinced that the problem isn't the fact that splhi() doesn't do anything. here's what i wonder: - does richard miller's alternate implementation of wakeup solve this problem. - does changing spl* to manipulation of a per-cpu lock solve the problem? sometimes preventing anything else from running on your mach is exactly what you want. in any event, given the long history with sleep/wakeup, changes should be justified with a promula model. the current model omits the spl* and the second lock. (http://swtch.com/spin/sleep_wakeup.txt). - erik
Re: [9fans] 9vx, kproc and *double sleep*
> schedinit only runs once and sleep runs all the time. That's the part > I don't get. gotolabel in sleep sends you back to the setlabel at the top of schedinit. > But you might have found something, I sure wish I understood it all better :-) i'm not entirely convinced that the problem isn't the fact that splhi() doesn't do anything. here's what i wonder: - does richard miller's alternate implementation of wakeup solve this problem. - does changing spl* to manipulation of a per-cpu lock solve the problem? sometimes preventing anything else from running on your mach is exactly what you want. in any event, given the long history with sleep/wakeup, changes should be justified with a promula model. the current model omits the spl* and the second lock. (http://swtch.com/spin/sleep_wakeup.txt). - erik
Re: [9fans] 9vx, kproc and *double sleep*
Schedinit() initialize the scheduler label ... on which sleep() goes when calling gotolabel(&m->sched). Phil; ron minnich wrote: I'll look but one thing doesn't make sense to me: On Fri, Jun 11, 2010 at 2:06 PM, Philippe Anel wrote: // xigh: move unlocking to schedinit() schedinit only runs once and sleep runs all the time. That's the part I don't get. But you might have found something, I sure wish I understood it all better :-) ron
Re: [9fans] 9vx, kproc and *double sleep*
I'll look but one thing doesn't make sense to me: On Fri, Jun 11, 2010 at 2:06 PM, Philippe Anel wrote: > // xigh: move unlocking to schedinit() schedinit only runs once and sleep runs all the time. That's the part I don't get. But you might have found something, I sure wish I understood it all better :-) ron
[9fans] 9vx, kproc and *double sleep*
Dear 9fans,
I think I maybe have found the reason why some of us have a *double
sleep* error while running 9vx. I think this would even explain some
segmentation faults seen in kprocs.
Please forgive me for the length of this post. I'm trying to be as
explicit as possible.
I have no certainty about this, mostly because the part of the code I
think involved in the bug has been checked and read several times by
several programmers. But I instrumented my own version of 9vx with a
circular log buffer and have the same results each time I encounter
this bug.
While reading the a/proc.c source code, I wondered what would happen
if two cpus (Machs) try to call the function ready() on the same
process at almost the same time.
I know the function ready() queues a proc into run queue so the
scheduler (or schedulers as one is executed per Mach) can execute
it. Because of this, if a process can be readied twice, two Machs
would execute the same code with the same stack and hence the whole
kernel would crash.
Then I immediatly wondered if this could be the reason why we have the
function sleep called twice on the same Rendez address (typically a
"*double sleep*").
The function queueproc() called by the function ready() does not check
the if process about to be added to the run queue has already been
added. The reason is not only because it takes time, but most of all,
this case is not supposed to happen. If a process A in running (ie in
Running state), it is out of the run queue. Same if it is waiting (ie
in Wakeme state), in which case, only one other process is expected to
have a ref on A (through the Rendez.p member).
The thing is I think this last point is not totally true, because
process A also holds a ref to itself. Let's think about the following
thought experiment (here again I apologize because I suspect I could
have made this simpler), which would requires 3 cpus (or Machs):
Step 1, on Mach 0:
A proc X is asking for a worker process (kproc/kserver in 9vx) to
execute some task. In order to do so, it calls wakeup on a Rendez
pointer held by a proc A, typically sleeping on it (we will see how
a few lines below).
Step 2, on Mach 1:
Proc A is awakened. It serves the call (Kcall in 9vx) and then
signals the client (proc X) the work is done. In order to do so, it
calls wakeup on the Rendez pointer Proc.rsleep of X.
Then proc A waits for another request. It sleeps again on the
Rendez pointer assigned to the server.
Let see how it works. It first locks the Rendez, then locks
itself. After this it checks if the condition happened of if a note
is pending. Lets assume this did not happened. It thus change its
own state to Wakeme and initialize the schedule point which be
called by the scheduler when the Rendez will be awakened. Then,
before going to sleep (or giving control to scheduler), it unlocks
itself, then unlocks the Rendez.
Sleeping means giving control the scheduler so that another proc
(or coroutine in kernel) can execute. In order to do that, the
sleep() function just calls "gotolabel(&m->sched)".
At this moment, no one has a lock on either the Rendez or proc A.
Step 3, on Mach 0:
Proc X, which has been awakened by proc A, ask proc A for another
request. It calls wakeup on the Rendez on which A is trying to
sleep. I insist on the fact proc A is 'trying' because the
scheduler has still not switched Mach.up and thus Mach 1 has still
a ref on Proc A.
In the function wakeup(), proc X locks r (the Rendez), then locks
r->p which is pointer to proc A, and then call ready on it before
unlocking p and r.
At this point, we have proc A in the run queue, and still in the
scheduler of Mach 1. We then can imagine that a third cpu (Mach 2)
schedules this proc (ie dequeue it from run queue, change its state to
Running and calls gotolabel(&p->sched) ... executing proc A code on
proc A stack ...
This is the bug I think. Because in the meantime, Mach 1 can continue
its execution in schedinit() function, with proc A state set to
Running. And Mach 1 would thus calls ready() on proc A and even
schedules and executes it.
I know this is unlikely to happen because sleep() goes to the
scheduler with splhi and there is no reason why it could not process
schedinit() "if (up) {...}" statement before another cpu/Mach calls
the function wakeup which itself calls ready() on proc A. But the
problem is that 9vx splhi() is empty ... and cpu/Machs which are
really pthreads are scheduled by the operating system (Linux, BSD,
...). In fact, there is a 0.01% (I cannot calculate this to be
honnest) (non-)chance this can happen on real hardware.
I updated the functions sleep() and schedinit() so the function
schedinit() unlocks both p and p->r in "if (up) { ... }" statement.
Since this change, I no longer have the *double sleep* error, nor
segmentation fault.
What do you think ?
Phil;
/*
* sleep if a condition is not true. Another process will
* awaken us a
Re: [9fans] 9vx still crashing
> On Sun, Jun 6, 2010 at 3:16 AM, EBo wrote: > > > > I'm still having 9vx crash even after removing -O3 from the build flags. > > An odd error that pops up randomly in rio (not in the terminal window) is > > "double sleep called from...". Thought this tidbit might be useful to the > > discussion of what might be going on... > > I'm pretty sure it's memory corruption. i assume you mean 9vx is scribbling on memory it shouldn't, not that there is a hardware bug. when i've seen this in plan 9, i haven't ever found it to be a wild pointer. it's always been. - stack > 4k, - a missing waserror()/poperror() around a sleep, - locking bugs. while it certainly could be a wild poointer, it doesn't smell like that to me. where (file/line) is the double sleep occuring? that could be a clue. remember addresses from acid aren't much help unless one has the exact same binary. - erik
Re: [9fans] 9vx still crashing
On Sun, Jun 6, 2010 at 3:16 AM, EBo wrote: > > I'm still having 9vx crash even after removing -O3 from the build flags. > An odd error that pops up randomly in rio (not in the terminal window) is > "double sleep called from...". Thought this tidbit might be useful to the > discussion of what might be going on... I'm pretty sure it's memory corruption. ron
[9fans] 9vx still crashing
I'm still having 9vx crash even after removing -O3 from the build flags. An odd error that pops up randomly in rio (not in the terminal window) is "double sleep called from...". Thought this tidbit might be useful to the discussion of what might be going on... EBo --
Re: [9fans] 9vx and ubuntu 10.04LTS
On Tue, 4 May 2010 11:06:29 +0200 "Mathieu Lonjaret" wrote: > Not that I know of. it's a lucid lynx install I did when it was still > in beta and I haven't kept it up to date since then, so maybe that's > where the difference lies. > How do I check if that fix you're speaking of is installed or not? > > Cheers, > Mathieu > /sbin/sysctl vm.mmap_min_addr A setting of 0 indicates that the patch has been applied. Often, root doesn't need it, but sometimes does. And this is my last post until I find where my email header settings have been hidden, and exterminate them. Sorry. sixforty
Re: [9fans] 9vx and ubuntu 10.04LTS
Not that I know of. it's a lucid lynx install I did when it was still in beta and I haven't kept it up to date since then, so maybe that's where the difference lies. How do I check if that fix you're speaking of is installed or not? Cheers, Mathieu --- Begin Message --- The update to 10.04 has overloaded my email with messages from ubuntu's dosemu forum. Basically the same issue as with 9vx. A fix [sic] is suggested. So, question is: On Sat, 1 May 2010 23:36:08 +0200 "Mathieu Lonjaret" wrote: > Fwiw, 9vx does build and run fine on 10.04 here. > Lemme know if I can give you some relevant info which might help. > > Cheers, > Mathieu > Mathieu: have you perhaps applied the fix to run some emulator, and it's "fixing" 9vx? -- sixforty --- End Message ---
Re: [9fans] 9vx and ubuntu 10.04LTS
The update to 10.04 has overloaded my email with messages from ubuntu's dosemu forum. Basically the same issue as with 9vx. A fix [sic] is suggested. So, question is: On Sat, 1 May 2010 23:36:08 +0200 "Mathieu Lonjaret" wrote: > Fwiw, 9vx does build and run fine on 10.04 here. > Lemme know if I can give you some relevant info which might help. > > Cheers, > Mathieu > Mathieu: have you perhaps applied the fix to run some emulator, and it's "fixing" 9vx? -- sixforty
Re: [9fans] 9vx and ubuntu 10.04LTS
On Sat, May 1, 2010 at 10:48 PM, Vinu Rajashekhar wrote: > The address shown by ldd can even vary from run to run, for the same file - yeah it's a feechur. But still all my libs are living in high half of 32-bit space on a running instance. The two LOAD segments on my 9vx are : LOAD 0x00 0x08048000 0x08048000 0x6f2f4 0x6f2f4 R E 0x1000 LOAD 0x06fefc 0x080b8efc 0x080b8efc 0x77204 0x18b81c RW 0x1000 What are yours after building? This is my libc: /lib/libc.so.6 -> libc-2.9.so ron
Re: [9fans] 9vx and ubuntu 10.04LTS
The address shown by ldd can even vary from run to run, for the same file - http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-03/4363.html On Sun, May 2, 2010 at 3:27 AM, Charles Forsyth wrote: > >this version madness confuses me. i could not get it to run on 9.10. > > i had 9vx running fine in 9.10 on the same machine. > it was the upgrade to 10.04 LTS that messed it up today. > i wonder why the library allocation addresses are different. > >
Re: [9fans] 9vx and ubuntu 10.04LTS
>this version madness confuses me. i could not get it to run on 9.10. i had 9vx running fine in 9.10 on the same machine. it was the upgrade to 10.04 LTS that messed it up today. i wonder why the library allocation addresses are different.
Re: [9fans] 9vx and ubuntu 10.04LTS
On Sat, May 1, 2010 at 6:39 PM, Charles Forsyth wrote: >>can you run the current 9vx in 9.04? > > yes > > this version madness confuses me. i could not get it to run on 9.10. 9.04 was fine.
Re: [9fans] 9vx and ubuntu 10.04LTS
On Sat, May 1, 2010 at 6:33 PM, Charles Forsyth wrote: > % ldd 9vx.Linux # old > ... > % ldd 9vx # new > > note that `old' is run on an existing 9.04 (2.6.28-18-generic), which works, > and `new' is the 10.04 (2.6.32-21-generic), which doesn't. > can you run the current 9vx in 9.04?
Re: [9fans] 9vx and ubuntu 10.04LTS
Fwiw, 9vx does build and run fine on 10.04 here. Lemme know if I can give you some relevant info which might help. Cheers, Mathieu --- Begin Message --- % ldd 9vx.Linux # old ... % ldd 9vx # new note that `old' is run on an existing 9.04 (2.6.28-18-generic), which works, and `new' is the 10.04 (2.6.32-21-generic), which doesn't. --- End Message ---
Re: [9fans] 9vx and ubuntu 10.04LTS
>can you run the current 9vx in 9.04? yes
Re: [9fans] 9vx and ubuntu 10.04LTS
% ldd 9vx.Linux # old ... % ldd 9vx # new note that `old' is run on an existing 9.04 (2.6.28-18-generic), which works, and `new' is the 10.04 (2.6.32-21-generic), which doesn't.
Re: [9fans] 9vx and ubuntu 10.04LTS
On Sat, May 1, 2010 at 2:05 PM, Charles Forsyth wrote: > having upgraded a machine to ubunut 10.04LTS yesterday, > 9vx now crashes with a segmentation violation shortly after > saying it is starting /bin/rc. has anyone else a similar > problem on that or another linux system? 9vx itself was unchanged, > but i also tried recompiling it (in case a linux include file had > changed subtly) but it made no difference. > > i'm having problems with ubuntu 9.04 but i don't get any segment violation iirc. the precompiled binary works, compiling one myself does not. iru
Re: [9fans] 9vx and ubuntu 10.04LTS
% ldd 9vx.Linux # old linux-gate.so.1 => (0xb772) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7617000) ... % ldd 9vx # new linux-gate.so.1 => (0x00704000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00c35000) ... where an obvious difference is that what i take to be addresses have moved from high memory to low memory, which might have something to do with it. i don't know what the values mean, because ldd(1) doesn't bother to tell you.
Re: [9fans] 9vx and ubuntu 10.04LTS
On Sat, May 1, 2010 at 1:53 PM, Charles Forsyth wrote: > 2.6.32-21-generic according to uname -a > > hmm. I'm running 9vx just fine on 2.6.33 -- a non-ubongo version. I wonder if some ubuntu patch to the kernel has broken something? Blast. if you do an ldd on it what libc etc. is it depending on? Could this be another one of those weird libc problems that crops up with specialized 686 or tls-specific libcs? I'm running out again but we can compare the libcs we are depending on. I'm happier than ever that I've dumped ubuntu and replaced it with tinycore. I did a trial install of 9.10 this week on an x60. It loaded. It booted and demanded that it be allowed to upgrade 271 packages. it loaded them and installed them. It no longer booted. That did it for me ... tinycore is a bit of a caveman environment but I'm clearly not sophisticated enough for ubuntu ... I need an OS for "the rest of us knuckle-draggers". ron
Re: [9fans] 9vx and ubuntu 10.04LTS
>2.6.32-21-generic according to uname -a or is that a combination?
Re: [9fans] 9vx and ubuntu 10.04LTS
what kernel version is it nowadays? ron
Re: [9fans] 9vx and ubuntu 10.04LTS
2.6.32-21-generic according to uname -a
[9fans] 9vx and ubuntu 10.04LTS
having upgraded a machine to ubunut 10.04LTS yesterday, 9vx now crashes with a segmentation violation shortly after saying it is starting /bin/rc. has anyone else a similar problem on that or another linux system? 9vx itself was unchanged, but i also tried recompiling it (in case a linux include file had changed subtly) but it made no difference.
Re: [9fans] 9vx crashing
> sure. what specifically would you like to see? Well, of course, the bit about xz would not go amiss. I note that Ubuntu doesn't offer xz utilities, so as soon as I have copies for my installation (plan 9, ubuntu, netbsd 3.1) I'll let you know so you can put that on the wiki as well. I'll see later what else may be useful, haven't got very far yet :-) ++L
Re: [9fans] 9vx crashing
On 04/26/2010 09:52 AM, lu...@proxima.alt.za wrote: >> Try http://werc.homelinux.net/hacks/nano9/ >> >> Hope that helps, > > How does one install the stuff in that directory? Specifically, what > handles *.xz files? See http://tukaani.org/xz/ -- Balwinder S "bdheeman" DheemanRegistered Linux User: #229709 Anu'z li...@home (Unix Shoppe)Machines: #168573, 170593, 259192 Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP Home: http://werc.homelinux.net/ Visit: http://counter.li.org/
Re: [9fans] 9vx crashing
> > I forget what all else I did when trying nano. I ended up focusing back on > > 9atom, and Erik had just patched the source so that a "mk all" would compile > > everything. See ftp://ftp.quanstro.net/other/9atom.iso.bz2 if interested. > > That is one of the source trees I'm playing with for setting up 9vx on > > TinyCoreLinux and Gentoo. > > Sounds like something that ought to be on the wiki (where I seldom > look, I have to confess). Do you think you could add an entry when > you're done? And maybe let us or just me know? sure. what specifically would you like to see? This is some of the background work for my GSoC and thesis work, so if any of my proposals are accepted for GSoC then I'll be working on various aspects of this. If some reason that none of the proposals get excepted, then my thesis research will need this for rudimentary toolchain. EBo --
Re: [9fans] 9vx crashing
> I forget what all else I did when trying nano. I ended up focusing back on > 9atom, and Erik had just patched the source so that a "mk all" would compile > everything. See ftp://ftp.quanstro.net/other/9atom.iso.bz2 if interested. > That is one of the source trees I'm playing with for setting up 9vx on > TinyCoreLinux and Gentoo. > > hope that helps. Sounds like something that ought to be on the wiki (where I seldom look, I have to confess). Do you think you could add an entry when you're done? And maybe let us or just me know? ++L
Re: [9fans] 9vx crashing
lu...@proxima.alt.za said: > > Try http://werc.homelinux.net/hacks/nano9/ > > > > Hope that helps, > > How does one install the stuff in that directory? Specifically, what > handles *.xz files? I tripped over that one too... This might help with the *.xz files: http://en.wikipedia.org/wiki/Xz I forget what all else I did when trying nano. I ended up focusing back on 9atom, and Erik had just patched the source so that a "mk all" would compile everything. See ftp://ftp.quanstro.net/other/9atom.iso.bz2 if interested. That is one of the source trees I'm playing with for setting up 9vx on TinyCoreLinux and Gentoo. hope that helps. EBo --
Re: [9fans] 9vx crashing
> Try http://werc.homelinux.net/hacks/nano9/ > > Hope that helps, How does one install the stuff in that directory? Specifically, what handles *.xz files? ++L
Re: [9fans] 9vx crashing
> randomly changing build options is one approach to debugging but not > always effective :-) I also forgot to mention that the reason I tried that is that I noticed both of those switches were missing from one of the Makefrag files I was reading recently, so it was not completely random ;-)
Re: [9fans] 9vx crashing
ron minnich said: > randomly changing build options is one approach to debugging but not > always effective :-) true, true ;-) I'm still waking up! : Gentlemen, Start your tea-pot/coffee-makers!
Re: [9fans] 9vx crashing
randomly changing build options is one approach to debugging but not always effective :-) ron
Re: [9fans] 9vx crashing
> Sorry, forget to mention that I also spend a lot of time on figuring out > why newly build 9vx from hg was crashing both on FreeBSD and Linux, but > all in a vain (currently don't have access to an OS/X machine). > > I'm not sure, if it was a correct fix, but removing -melf_i386 option > did the trick; Without the -melf_i386 option I get the the following error: ld -o vxa/zlib/ezlib -Llibvxc -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/32/ -g -L. libvxc/vx32/crt0.o vxa/zlib/ezlib.vo vxa/zlib/compress.vo vxa/zlib/deflate.vo vxa/zlib/trees.vo vxa/zlib/adler32.vo vxa/zlib/crc32.vo vxa/zlib/zutil.vo -lc -lgcc ld: skipping incompatible libvxc/libc.a when searching for -lc ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in vxa/zlib/ezlib.vo Removing both the -melf_i386 and -mfp-ret-in-387 resulted in the same. I'm using GCC 4.3.4 and ld 2.18 on Gentoo updated/synchronized daily. I should also note that my hardware is an AMD x86_64 EBo --
Re: [9fans] 9vx crashing
On 04/21/2010 05:05 PM, erik quanstrom wrote: >>> While I could spend time trying to tracing through the code to figure out >>> what >>> is going on, I have opted for the moment to update the base root I am using >>> as >>> the old one is just shy of two years old, and the newer one seem to run >>> correctly so far. If this problem creeps up again I'll start debugging it >>> in >>> earnest. >> >> Try http://werc.homelinux.net/hacks/nano9/ > > what bug does this fix that you think you've > fixed that addresses this particular bug? Sorry, forget to mention that I also spend a lot of time on figuring out why newly build 9vx from hg was crashing both on FreeBSD and Linux, but all in a vain (currently don't have access to an OS/X machine). I'm not sure, if it was a correct fix, but removing -melf_i386 option did the trick; hence a patch: diff -r 8184025094f4 src/Makefrag --- a/src/Makefrag Mon Oct 05 02:53:41 2009 -0400 +++ b/src/Makefrag Fri Mar 12 22:16:57 2010 +0530 @@ -21,7 +21,7 @@ # VX32_AR := vx32-ar # VX32_OBJCOPY := vx32-objcopy VX32_CC:= gcc -m32 -VX32_LD:= ld -melf_i386 +VX32_LD:= ld VX32_AR:= ar VX32_OBJCOPY := objcopy I have GCC 4.4.3 and ld 2.20, both on FreeBSD 8.0-RELEASE and Debian 5.0.4 as well. -- Balwinder S "bdheeman" DheemanRegistered Linux User: #229709 Anu'z li...@home (Unix Shoppe)Machines: #168573, 170593, 259192 Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP Home: http://werc.homelinux.net/ Visit: http://counter.li.org/
Re: [9fans] 9vx crashing
> > While I could spend time trying to tracing through the code to figure out > > what > > is going on, I have opted for the moment to update the base root I am using > > as > > the old one is just shy of two years old, and the newer one seem to run > > correctly so far. If this problem creeps up again I'll start debugging it > > in > > earnest. > > Try http://werc.homelinux.net/hacks/nano9/ what bug does this fix that you think you've fixed that addresses this particular bug? - erik
Re: [9fans] 9vx crashing
On Wed, Apr 21, 2010 at 1:39 AM, Balwinder S Dheeman wrote: > Try http://werc.homelinux.net/hacks/nano9/ That's neat, I'm going to have to try it now :-) ron
Re: [9fans] 9vx crashing
On 04/20/2010 11:46 PM, EBo wrote: >> that pc is in the floating point code. clearly bogus. >> as find doesn't do any floating point. > > I have no idea why this is happening, only that it is and it is failing > consistently. > > While I could spend time trying to tracing through the code to figure out what > is going on, I have opted for the moment to update the base root I am using as > the old one is just shy of two years old, and the newer one seem to run > correctly so far. If this problem creeps up again I'll start debugging it in > earnest. Try http://werc.homelinux.net/hacks/nano9/ Hope that helps, -- Balwinder S "bdheeman" DheemanRegistered Linux User: #229709 Anu'z li...@home (Unix Shoppe)Machines: #168573, 170593, 259192 Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP Home: http://werc.homelinux.net/ Visit: http://counter.li.org/
Re: [9fans] 9vx crashing
> that pc is in the floating point code. clearly bogus. > as find doesn't do any floating point. I have no idea why this is happening, only that it is and it is failing consistently. While I could spend time trying to tracing through the code to figure out what is going on, I have opted for the moment to update the base root I am using as the old one is just shy of two years old, and the newer one seem to run correctly so far. If this problem creeps up again I'll start debugging it in earnest. EBo --
Re: [9fans] 9vx crashing
> 2) I installed Erik's find utility and running it gave the error:
>
> find 2062: suicide: sys: trap: invalid opcode pc=0x5001
>
>from inside 9vx, and:
>
> invalid opcode ff ff ba at eip 5001
>
>in the linux terminal that spawned it.
that pc is in the floating point code. clearly bogus.
as find doesn't do any floating point.
/sys/src/libc/port/strtod.c:139
134continue;
135}
136break;
137case 'e':
138case 'E':
>139if(state == S2 || state == S4) {
140state = S5;
141continue;
142}
143break;
144}
- erik
[9fans] 9vx crashing
Just an FYI. I've been working on getting 9vx running on a TinyCoreLinux USB stick, and I have been having 9vx crash in odd ways and wanted to post a note about it. For starters, I am building 9vx from hg source and using the root from 9vx's 2008/7/1 release 9vx-0.12. There are three points of possible interest: 1) the base root does not have libc.a which means that I can compile program, but not link them. 2) I installed Erik's find utility and running it gave the error: find 2062: suicide: sys: trap: invalid opcode pc=0x5001 from inside 9vx, and: invalid opcode ff ff ba at eip 5001 in the linux terminal that spawned it. 3) I was able to resolve both problems by replace the Plan 9 root with one copied from a recent 9atom.iso, however I am not finished testing that though. EBo --
