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
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
I am pretty sure Charle's patch will fix this problem
ron
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
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
On Sat, Sep 11, 2010 at 10:18 AM, Lucio De Re lu...@proxima.alt.za 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
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
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 lu...@proxima.alt.za:
On
2010/9/11 Lucio De Re lu...@proxima.alt.za:
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
Hello,
this starts to be daunting...
When I use troff with the R font, troff uses metrics from /sys/lib/troff/font/R.
Then something, when dpost -f is running, must take the real glyphs
and put them into the final ps.
I guess that something must read /sys/lib/postscript/troff/R to find
out that
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 void
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*
2010/9/11 Paul Lalonde paul.a.lalo...@gmail.com:
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
this doesn't work for me either on p9p, but it does work under
plan 9. it's a font problem.
do you have the fonts?
they do not come with plan9port, because the
postscript fonts cannot be redistributed except
with plan 9 itself.
i believe that if you copy /sys/lib/postscript/font/*
to
On Thu, Sep 9, 2010 at 4:13 PM, erik quanstrom quans...@quanstro.net wrote:
lately, i've been seeing email with gigantic headers.
120 header lines are not that uncommon. unfortunately
upas has sometimes inserts a blank line about
(but not exactly) 4k into the file. a bit of digging,
That sounds about right, unfortunately.
You might be better off just using TeX.
It's better at math, it runs on Plan 9,
and your colleagues who don't use
Plan 9 will still be able to collaborate
on documents with you.
Russ
OK, just checked, and my vx32 repo at bitbucket.org has the cld
patch. I guess yiyus committed it?
ron
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
On Sat, 11 Sep 2010 16:07:54 -0700
ron minnich rminn...@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
On Sat, Sep 11, 2010 at 4:35 PM, Robert Ransom rransom.8...@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
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
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);
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
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 @@
#defineVMAPSIZE(0x1000-VPTSIZE-KMAPSIZE)
#defineUZERO 0 /* base of user
OK, the bigger user stack is committed to my vx32 at bitbucket.
ron
25 matches
Mail list logo
