Paging problem on Decstaion 3100

John Dotts Hagan hagan at DCCS.UPENN.EDU
Wed Apr 11 16:09:28 AEST 1990


% I'm occasionally seeing what might be similar paging problems on my DS5800,
% which has 32MB of memory.  What you see is the load average starts to spike
%  over the course of several minutes and eventually everything hangs. 
Sometimes
% it seems to break loose again, sometimes not.
% 

That is the symptom we see, as well, and that is what I reported as a
"paging problem", due to the looks of the ps awwxl output.

> I don't know if this is really the "paging problem" or something else.
 We had
> some similar problems, apparently caused by use of the 3.1C csh where csh
> bugs would make it try to allocate all available memory.  The 3.1C mandatory
> patches replaces this shell as the defeault 'csh', but I still have to make
> it avilable to users who have been accustomed to having some kind of command
> completion shell available for ultrix.
> 
> I'll have to try and get these patches and see if they offer some
improvement.
> 

Interesting.  I have seen some tasks seem to dump core when started, like:
% emacs
Segmentation Fault
(core dumped)
%
but the core file is really from /bin/csh, not emacs!


> In the meantime, does anybody know how to reliably force a dump on a 5800?
> 
> I've tried a couple of times, but been screwed by the non-fixed location of
> "doadump" on the RISC stuff, and now that I finally have the number taped to
> my console, I find that saying "go 0x...." doesn't seem to work! 
Perhaps mips
> code expects more context out of the caller?  If so, it should still be
> possible have some (hopefully) fixed address in the assembly code section of
> the kernel that you can "go to" that tries to fix up the context enough to
> call doadump().
> 

I mentioned this problem in my previous posting as well.  We have about
1 out of 5 times it locks up, and we try the go <doadump> thing, it works.

--Kid.



More information about the Comp.unix.ultrix mailing list