Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!DCCS.UPENN.EDU!hagan From: hagan@DCCS.UPENN.EDU (John Dotts Hagan) Newsgroups: comp.unix.ultrix Subject: Re: Paging problem on Decstaion 3100 Keywords: 3100 paging memory Message-ID: <23066@netnews.upenn.edu> Date: 11 Apr 90 06:09:28 GMT References: <10680@cbmvax.commodore.com> <10516@netcom.UUCP> <2112@kiwi.mpr.ca> <22773@netnews.upenn.edu> <2982@decuac.DEC.COM> Sender: news@netnews.upenn.edu Reply-To: hagan@DCCS.UPENN.EDU (John Dotts Hagan) Organization: DCCS Lines: 47 % 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 thing, it works. --Kid.