asgard@cpro.UUCP (J.R. Stoner) (12/20/86)
I thought I might post some dialogue I have had with Daniel M. Frank,
who seems to be a "port authority" for Microport Systems V/AT to wit:
{Subject: Re: MicroPort System V/AT info wanted
{In-Reply-To: Your message of Thu, 11 Dec 86 18:51:34 -0800.
{Date: Fri, 12 Dec 86 08:56:32 -0600
{From: Daniel M. Frank <hplabs!ames!uwvax!prairie!dan>
>> 1. I have been seeing a lot of "inode table overflow" messages on my
>> console (especially when doing "busy" things, like unbatching 2.11 news :-)
>> Does that mean the fopen fails and it sends the data to file heaven?
> I don't know what it does with the data. The message means exactly what
>it says: the in-core inode table is too small, and you have run out of
>entries. There are 50 inodes and files, and this number is too small.
>These limits should be much larger in version 1.3.8, which should be out
>soon. In the meantime, you might ask Microport for a linkkit. If you
>have a linkkit, you can rebuild a new kernel with respectable limits in
>minutes. That's what I did.
[aside: There was nothing which says the link kit was stored in a format
which is different from all the other cpio disks. Also there was zero
printed documentation for the link kit.]
O.K. I have recompiled the system with 200 inodes, 200 buffers, and 64 proc
stuctures. Now let us see the system crap out with a table overflow :-)
Seriously, though, will the open(2) call just fail, returning an error
condition which rnews can pick up gracefully, or will the process just abort
and drop everything on the floor (uucp seems to be sending me mail every
time that happens saying an LTMP file could not be opened).
>> 2. The configuration messages seen when the cold boot signon message is
>> displayed is somewhat cryptic, when trying to figure out how much program
>> memory is available.
> The "user memory" field is the one you want.
Apparently not with 1.3.6 Runtime. The message is just nnK memory available,
which in the case of 444K in the report in my case _could_ mean the kernel
found all 1Mb of RAM I have, and set aside 444K of it for TPA, or the system
only found the 512K of it that is below 640K, and does not say which chunk
of RAM is being used for kernel as opposed to TPA.
>> 2.1. Neato/fun programs like larn seem to crash (memory, I think) with a
>> core dump, and the message "segmentation violation". I can't seem to find
>> this documented in Development System documents, and looking something like
>> that up in the Runtime System document is an interesting experience ;-)
> "Segmentation violation" means that a program has attempted to load
>a bad segment number into a segment register. The most common cause of
>this message in public domain programs is an evil belief on the part of
>many programmers that NULL is a pointer to a null string. Other goodies
>include failure to declare functions returning pointers, phoney varargs
>functions with lots of ints in the argument lists (where longs should be
>used), and the use of `0' as a character pointer or long pointer argument
>to a function such as time() or execl().
> In short, segmentation violations are caused by bad pointers of one
>sort or another. Lint your programs with the -Ml flag, and read care-
>fully through the 10,000 or so messages you will get. Also if the
>compiler tells you something about `illegal combination of pointer
>and int', believe it - it usually means an attempt to assign the
>result of an int function to a pointer, which usually means the function
>wasn't declared.
> Also, compile your programs with -g the first time, and use sdb to
>determine where they are dumping.
Here is a different case which is even more frustrating.
I have compiled patch v2.0. Both small model and big model. Both times
lint does not find anything wrong with it, but the big model usually
finds segmentation violation right away and core dumps. The small model
version gets much further before dying, with the following symptoms:
[test case - patch kit number two for 2.11 news]
some of the files get patched, but inevitably, the message:
assertion failed: fillsrc==p_end+1 || fillsrc==repl_beginnin, file pch.c,
line 636
then an IOT trap with a core dump. The funny thing is the death is not
*always* like this. Sometimes I will see the assertion failure, get the
csh prompt, then the next command I type causes the IOT trap and core dump.
The weird thing is that lint did not show up anything which might point out
where the problem might lay.
>> 2.2. Pathalias v2 can never perform a complete scan on the path data,
>> since the array unit seems to be limited to 64Kb - Grrrr.
> Pathalias allocates in 4K chunks. You don't have a malloc failure.
>What you probably do have is a swap device that is too small. The default
>swap space (4000 blocks) is not enough. What's more, if you allocated more
>with divvy (and you should - at least 7000-8000 blocks), there is a bug
>in 1.3.6 that causes the system to think you allocated 4000 anyway. You
>can work around this by patching nswap to the proper number with /etc/patch -k.
>Also, go into mem.c of pathalias and increase the allocation chunk to at
>least 32K, but less than 64K. This will reduce the number of times that
>pathalias swaps while growing, which makes it run MUCH faster.
Sounds like a winner to me, but I will have to wait before I undertake to
re-divvy the hard disk. I have to back up all 60Mb first.
>> 2.3. I an not too hopeful, but is there anybody porting GNU emacs to run
>> in V/AT? 7Mb for the source, and maybe 1Mb for the object - YOW!
> Memory and disk are not a problem (except if the object is larger than
>1Mb., when you will run up against the *&*$^#%^ ULIMIT). There seem to
>be problems with:
> 1) Contiguous memory allocation.
> 2) Brain-damaged machine-dependent programming of the sort I described
> above.
> 3) An unexec routine that doesn't know about multiple segments per
> section.
>
> I understand that Jove will be posted to mod.sources soon. It's not
>as nice as GNU, but it's quite good. If and when the 386 becomes available
>with OS and compiler support (Microport is working on that right now!),
>GNU should be possible.
>> 3. There should be a way to dispense with the printf messages that are
>> hard-wired into getty and login. (System name:... etc.) I can put these in
>> gettydefs, if need be, but I like more control than this (boot time is O.K.
>> for stuff like this).
> The system name stuff is hard wired. I think the login: stuff is in
>gettydefs, isn't it?
Nope. The getty stuff is in gettydefs, and the login program is printing
this hard-wired stuff after the login password is validated. I would rather
have more control over what I print after accounts are validated.
>> 4. UUCP should have the ACU modules in working order (done by hand in
>> L.sys works, but this is a kluge when all modems around are Hayes modems, and
>> it would make the file prettier). My version of 5r0 on the CompuPro has the
>> following in L-devices:
> This is fixed (I know, because I did the work). cu and uucico now use
>the dial(3) library posted to the net, which uses a finite state machine
>specification in /usr/lib/uucp/dialinfo. It handles multiple modem types,
>and is even powerful enough to do full login scripts. Very flexible.
If the documentation for the dialinfo file and how it is used is in the
books it would be a Revelation to me if you can point it out. I *hate*
having to put ATDT in the L.sys file. Very messy.
>> This makes the phonenum field in L.sys work as advertised.
> Right.
Another couple of things:
To make the lp system work properly, you should use the "dumb" file in the
set in the model directory, then remove the stty line, and the if-then group
around it. I can't even do those things by typing them by hand.
The link kit is not initially set up correctly in the 1.3.6 release. You
have to edit the dfile.wini to remove the '*' in front of the lp device
profile and set the maximum inode count from 2 to 3.
| Hope this helps ...
|
| -- Dan
|
|p.s. You might pass this info on to other users, including the net.
O.K. I have done so. BTW I have redone the ansi terminfo driver so that it
works correctly for curses. Here is the source definition for a terminal
called 'js'. You can edit it to be ansi, if you like.
js|jrsansi, am, xon, cols#80, lines#24, bel=^G, cr=^M, ht=^I, ind=^J,
home=\E[H, clear=\E[H\E[J, el=\E[K, ed=\E[J, cup=\E[%i%p1%d;%p2%dH$<12>,
ich1=\E[@, il1=\E[L, dch1=\E[P, dl1=\E[M,
blink=\E[5m, bold=\E[1m, rev=\E[7m, invis=\E[8m, smso=\E[1m, smul=\E[4m,
sgr0=\E[0m, rmso=\E[0m, rmul=\E[0m,
cuu1=\E[A, cud1=^J, cuf1=\E[C, cub1=^H
Cut this info out of this article, (like 'sample') and feed it to tic while
logged in as root with the command:
tic sample
[One more gripe, just to make inews happy about all the '>' lines ;-)
There is no document or man page for tic in the runtime or the development
packages. I do not have the text kit or Merge, but if it can be found there
I will be displeased, as the development kit seems like the perfect place
for something like this.
--
May the farce be with you.
J.R. Stoner asgard@cpro.UUCP