Re: [9fans] sad commentary
On Wed, Jul 2, 2008 at 8:35 PM, erik quanstrom [EMAIL PROTECTED] wrote: Also, public 9grids. Though judging by gdiaz's experiences with sirviente, there's a bit of work to be done in that area - I get the impression things are fairly unstable once the machine gets under memory pressure. -sqweek i think this is an artifact of setting up heavily-used systems combining venti, fossil, auth and cpu server. ... sure crashing is antisocial. the alternative is to add very large amounts of code to the kernel. Back when this was first posted I wanted to protest the point that a large kernel modification is necessary, since I figured you can do a good enough job with just an interface to tell the kernel not to kill the important server processes. Obviously I decided to let it lie, but I just discovered this can be done without modifying the kernel at all when I happened across an interesting line in termrc: /rc/bin/termrc:dontkill '^(ipconfig|factotum|mntgen|fossil|cs|dns|listen|reboot)$' The default cpurc doesn't use dontkill, but I suspect it could be a big help for all-in-one servers. Figured I'd point it out as it seems easy to miss. ... plus everyone can use a good scare every now and then, and what better way than to resurrect sad commentry? -sqweek :D
Re: [9fans] sad commentary
sqweek wrote: On Wed, Jul 2, 2008 at 8:35 PM, erik quanstrom [EMAIL PROTECTED] wrote: Also, public 9grids. Though judging by gdiaz's experiences with sirviente, there's a bit of work to be done in that area - I get the impression things are fairly unstable once the machine gets under memory pressure. -sqweek i think this is an artifact of setting up heavily-used systems combining venti, fossil, auth and cpu server. ... sure crashing is antisocial. the alternative is to add very large amounts of code to the kernel. Swap doesnt work reliable here. :-( I have disabled swaping and let the kernel kill the biggest process skipping any critical server processes and it works well. got ~100 days uptime and i use this machine for linuxemu development/testing. no adding very large amounts of code... maybe fix the swap... or even remove it alltogether. Back when this was first posted I wanted to protest the point that a large kernel modification is necessary, since I figured you can do a good enough job with just an interface to tell the kernel not to kill the important server processes. Obviously I decided to let it lie, but I just discovered this can be done without modifying the kernel at all when I happened across an interesting line in termrc: /rc/bin/termrc:dontkill '^(ipconfig|factotum|mntgen|fossil|cs|dns|listen|reboot)$' The default cpurc doesn't use dontkill, but I suspect it could be a big help for all-in-one servers. Figured I'd point it out as it seems easy to miss. ... plus everyone can use a good scare every now and then, and what better way than to resurrect sad commentry? -sqweek :D good to know :-) cinap
Re: [9fans] sad commentary
Swap doesnt work reliable here. :-( I have disabled swaping and let the kernel kill the biggest process skipping any critical server processes and it works well. got ~100 days uptime and i use this machine for linuxemu development/testing. i'm curious as to what is taking so much memory. - erik
Re: [9fans] sad commentary
the alternative is to add very large amounts of code to the kernel. not really. the alternative is to add some code to the kernel, and varying amounts of code to quite a few applications.
Re: [9fans] sad commentary
no adding very large amounts of code... maybe fix the swap... or even remove it alltogether. assuming it doesn't work now, the paging code used to work, at least in the sense of survive --i used 8l to link kernels on a 4mbyte 386sx16 -- so i imagine it's just a matter of repairing it, if it indeed is responsible. unfortunately it's hard to tell because doesn't work is a little vague.
Re: [9fans] sad commentary
On Tue, Jul 22, 2008 at 11:50 PM, Charles Forsyth [EMAIL PROTECTED] wrote: no adding very large amounts of code... maybe fix the swap... or even remove it alltogether. assuming it doesn't work now, the paging code used to work, at least in the sense of survive --i used 8l to link kernels on a 4mbyte 386sx16 -- so i imagine it's just a matter of repairing it, if it indeed is responsible. unfortunately it's hard to tell because doesn't work is a little vague. I'm still happy to do any testing here. Have a P100 with 24mb ram that I can reliably bring down with man -p or as I found out yesterday, cd /sys/man; mk indices. Symptoms of the swap issue were the drawterm session locking up... can't remember what was on the console. -sqweek
Re: [9fans] Building new kernel.
The kernel mkfiles don't know how to build dependencies from the cmd tree. The mk you're doing knows fossil is missing or out of date, but not how to do anything about it. Build it yourself. I mk all of /sys/src/cmd to be safe, but you could just hit the list you need for your kernel (whatever files you're building in). The 'pc' configuration doesn't have this problem because it doesn't include fossil (and a few other things pcf has). See the 'bootdir' section of the config file. Anthony
Re: [9fans] Building new kernel.
Thank you both for your infromative replies. A 'mk all' in /sys/src/cmd gave errors so I am doing a pull now Bob
Re: [9fans] Building new kernel.
erik quanstrom wrote:
I am having trouble building a new kernel for a terminal.
I do
mk 'CONF=pcf'
and I get the error
mk: don't know how to make '/386/bin/fossil/fossil' in directory
/sys/src/9/pc
does /386/bin/fossil/fossil exist? if not, it's a little
worrying that it doesn't. perhaps the iso was
missing some files. or your network install was
interrupted. assuming that the damage is
not too great, you probablly want to use
/usr/glenda/bin/rc/pull to sync up with sources.
- erik
Ok. I pulled and remade fossil which got over that error. But now I do
mk 'CONF=pcf' and get
size 9pcf
links: incompatible type signitures ..(for a whole load of init
files ie tcpinit, udpinit etc)
and then
mk: 8c -FTVv '-DKERNDATE='`{date ... : exit status=rc 1887: 8l 1891 error
Something not quite right with my system??? It's from the plan9 iso
dated June 26th..
Thanks again
Bob
Re: [9fans] Building new kernel.
Ok. I pulled and remade fossil which got over that error. But now I do
mk 'CONF=pcf' and get
size 9pcf
links: incompatible type signitures ..(for a whole load of init
files ie tcpinit, udpinit etc)
and then
mk: 8c -FTVv '-DKERNDATE='`{date ... : exit status=rc 1887: 8l 1891 error
Something not quite right with my system??? It's from the plan9 iso
dated June 26th..
this would be expected due to the pull which sets the mtimes of
new files to be older than the .8s. try mk clean before proceeding.
- erik
Re: [9fans] Building new kernel.
this would be expected due to the pull which sets the mtimes of
new files to be older than the .8s. try mk clean before proceeding.
i should explain that type signatures are 32-bit
signatures in .$O files that define the type of
external symbols. the c compiler sets the type
signature to zero unless the -T flag is given.
if both signatures are not zero, the linker
checks to see that they match.
thus if you try to link a.c with decl
extern int fu;
with b.c
long fu
it will work perfectly if the -T flag is not
given (since there is a deep assumption
in plan 9 that int == long). but i the
-T flag is given, it will fail with a type
signature error.
- erik
minooka; cat a.c
long fu;
minooka; cat b.c
#include u.h
#include libc.h
extern int fu;
void
main(void)
{
print(%d\n, fu);
}
minooka; 8c a.c 8c b.c 8l a.8 b.8 8.out
0
minooka; 8c -T a.c 8c b.c 8l a.8 b.8 8.out
0
minooka; 8c a.c 8c -T b.c 8l a.8 b.8 8.out
0
minooka; 8c -T a.c 8c -T b.c 8l a.8 b.8 8.out
main: incompatible type signatures 5ef20f47(a.8) and 4151d5bd(b.8) for
fu
Re: [9fans] Building new kernel.
it will work perfectly if the -T flag is not given (since there is a deep assumption in plan 9 that int == long). but i the not exactly. it will work on most Unix systems and on Plan 9 without -T because nothing checks external types across object module boundaries. the linker/loader in both systems will allocate in BSS the largest size seen for a given symbol, so it doesn't matter whether int == long or not.
Re: [9fans] Building new kernel.
not exactly. it will work on most Unix systems and on Plan 9 without -T because nothing checks external types across object module boundaries. the linker/loader in both systems will allocate in BSS the largest size seen for a given symbol, so it doesn't matter whether int == long or not. by work you mean not generate an out-of-range memory access nor not produce unexpected values? - erik
Re: [9fans] Building new kernel.
erik quanstrom wrote:
Ok. I pulled and remade fossil which got over that error. But now I do
mk 'CONF=pcf' and get
size 9pcf
links: incompatible type signitures ..(for a whole load of init
files ie tcpinit, udpinit etc)
and then
mk: 8c -FTVv '-DKERNDATE='`{date ... : exit status=rc 1887: 8l 1891 error
Something not quite right with my system??? It's from the plan9 iso
dated June 26th..
this would be expected due to the pull which sets the mtimes of
new files to be older than the .8s. try mk clean before proceeding.
- erik
Thanks. I realised that wouild be a good idea about 1.5 nanoseconds
after I sent the email
So, now in /sys/src I do
mk cleanok,
mk allfails with
mk ip
8c -FTVv 6in4.c
mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip
doing a mk all in /sys/src/cmd/ip/ gives the same error...
Any ideas.
If I delete all sources and do a pull then try again
Thanks for your patience :-)
Bob
Re: [9fans] 9vx ip stack and page assertion
There have been several discussions on this list about 9vx's IP stack being different from normal Plan 9 in the last two weeks; you should check those out. The short version is that 9vx uses the host networking rather than its own, and (more- or-less) consequently the kernel device presents a more minimal interface. You don't need to do ipconfig. Anthony
Re: [9fans] Building new kernel.
not exactly. it will work on most Unix systems and on Plan 9 without -T because nothing checks external types across object module boundaries. the linker/loader in both systems will allocate in BSS the largest size seen for a given symbol, so it doesn't matter whether int == long or not. by work you mean not generate an out-of-range memory access nor not produce unexpected values? - erik i meant pass muster, which i thought was the sense originally intended (ie, link without diagnostic) but i see now that wasn't intended. sorry. anyhow, that's why it links without diagnostic elsewhere!
[9fans] 9vx ip stack and page assertion
Hi! I'am new to 9vx/p9p and try to configure /net. # uname -a FreeBSD r60e 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Wed Jul 9 17:33:56 UTC 2008 gonzo@:/usr/obj/usr/src/sys/GENERIC i386 % bind -b '#I' /net % ip/ipconfig -g 192.168.0.1 ether /net/ether0 192.168.0.32 255.255.255.0 ipconfig: no ip stack bound onto /net % Do I miss something? And there seems to be a bug in p9p's page. # 9 page paper.pdf swapcontext failed: Invalid argument Assertion failed: (0), function contextswitch, file thread.c, line 289. 1679: signal: sys: abort Thank you -- Pt! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine für Alle: http://www.gmx.net/de/go/messenger03
Re: [9fans] Building new kernel.
9, mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip does /sys/src/cmd/ip/pptpd.c exist? if not, there must be an error in the pull database on sources. you can copy it by hand with 9fs sources cp -x /n/sources/plan9/sys/src/cmd/ip/pptpd.c /sys/src/cmd/ip/ Erik, it already exists and has the same MD5 checksum than the one in sources. Jerome
Re: [9fans] Building new kernel.
Erik, it already exists and has the same MD5 checksum than the one in sources. i'm fresh out of ideas, then. what i know is a) it build just fine on my system, but i don't use pull. b) if for some xyzw mk requires xyzw.8 and there's no xyzw.$x so that there's a mk rule like so %.8: %.$x, i get the following error message ; mk xyzw.8 mk: no recipe to make 'xyzw.8' in directory /sys/src/9/pc since i know there's a rule %.8: %.c, there must be some reason that mk thinks that pptp.c doesn't exist. i have no idea what that would be. mode bits? you might want to fiddle around with mk -de pptp.8 - erik
Re: [9fans] Building new kernel.
9, mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip does /sys/src/cmd/ip/pptpd.c exist? if not, there must be an error in the pull database on sources. you can copy it by hand with 9fs sources cp -x /n/sources/plan9/sys/src/cmd/ip/pptpd.c /sys/src/cmd/ip/ Erik, it already exists and has the same MD5 checksum than the one in sources. Using July 19th's iso and today's (Tue Jul 22 13:51:21 PDT 2008) pull: http://www.eskimo.com/~jibanes/pull.png Hope this helps, Jerome
[9fans] Sam on 9pm or plan9port
As far as I could find, there isn't a newer version of sam for Windows then the one from 9pm, so I started trying to port the plan9port version. So far, I got all of the stuff in the sam/ directory to compile. I'm stuck on lib9, though, since it doesn't compile on Windows in its current form. I've gotten bits and pieces to build, but not the whole thing, so before I end up having to gut it to make it work, I thought I'd ask if anyone might know.. might it be more straightforward to modify the plan9port sam to run on 9pm, or would the only way to get it running on Windows be to port the whole lib9 from p9p at the same time? ... I hate Windows, but alas, it's what I have to live with for my job ... Thanks in advance! -Ben winmail.dat
Re: [9fans] Sam on 9pm or plan9port
Benjamin Huntsman wrote: might it be more straightforward to modify the plan9port sam to run on 9pm, or would the only way to get it running on Windows be to port the whole lib9 from p9p at the same time? ... I hate Windows, but alas, it's what I have to live with for my job .. Here is a stab in the dark -- could p9p possibly compile and run under Cygwin? If so, that could be one way to get p9p working. An extra of indirection may not be the most efficient thing, but... Ed
Re: [9fans] Sam on 9pm or plan9port
could p9p possibly compile and run under Cygwin? Might be an easier port... MinGW might be preferable, as drawterm uses it, and again might be easier... Neither would work out of the box, though. An extra of indirection may not be the most efficient thing, but... My approach thus far has been to just grab the bits sam needs and compile it static... It'd be kind of goofy to need -two- compatibility layers just to run an editor, but you're right in that doing so may be the only feasible way. winmail.dat
Re: [9fans] Sam on 9pm or plan9port
dt can be compiled using either mingw or ms tools. might want to read rsc's recent post about 9vx port to windows and the relative ease compared to porting p9p. could p9p possibly compile and run under Cygwin? Might be an easier port... MinGW might be preferable, as drawterm uses it, and again might be easier... Neither would work out of the box, though. An extra of indirection may not be the most efficient thing, but... My approach thus far has been to just grab the bits sam needs and compile it static... It'd be kind of goofy to need -two- compatibility layers just to run an editor, but you're right in that doing so may be the only feasible way.
Re: [9fans] Sam on 9pm or plan9port
I have a long term project to get somthing like p9p running under windows though my goal is to use a windows box as a plan9 cpu server so /dev/draw is not a priority. My approach is very similar to Russ's p9p for windows alpha on swtch.com but it is many months away from finished - i get a day a week or less to work on it. The DLL kernel works and supports most plan9 command line tools, but has no mount driver yet so no devices and a recent attempt to port over plan9's devmnt and its prerequisits resulted in more problems than it solved. I am happy to share the code I have which might be usefull to you. -Steve
Re: [9fans] Building new kernel.
what i know is a) it build just fine on my system, but i don't use pull. b) if for some xyzw mk requires xyzw.8 and there's no xyzw.$x so that there's a mk rule like so %.8: %.$x, i get the following error message ; mk xyzw.8 mk: no recipe to make 'xyzw.8' in directory /sys/src/9/pc since i know there's a rule %.8: %.c, there must be some reason that mk thinks that pptp.c doesn't exist. i have no idea what that would be. mode bits? pptpd.c is dated Dec 31, 1969, mk doesn't like this. So I touch'd it, and then it compiled just fine. Jerome
Re: [9fans] Building new kernel.
Bob, mk: don't know how to make '/386/bin/fossil/fossil' in directory /sys/src/9/pc touch /386/bin/fossil/fossil then you can mk 'CONF=pcf' if you want. Hope this helps, Jerome Ibanes
Re: [9fans] Building new kernel.
touch /386/bin/fossil/fossil then you can mk 'CONF=pcf' if you want. if you are trying to boot from a fossil root and do this, your kernel will not be able to successfully mount the root filesystem. don't do this if you expect to boot. Only if there was no /386/bin/fossil/fossil before. If instead the problem is that fossil/fossil has mtime==0 but is otherwise a valid binary (as an earlier post suggested was the problem with pptpd.c), then touch is a fine solution. Presumably mk fails to distinguish mtime==0 from file does not exist internally. Russ
