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