Xref: utzoo unix-pc.general:130 comp.sys.att:1978
Path: utzoo!utgpu!water!watmath!clyde!mtune!cbosgd!mandrill!hal!ncoast!axcess!allbery
From: allbery@axcess.UUCP (Brandon S. Allbery)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: Unix-pc lockup problems - A follow-up
Message-ID: <129@axcess.UUCP>
Date: 3 Jan 88 16:48:30 GMT
References: <71@cjsa.UUCP>
Organization: aXcess Company, Mentor, Ohio
Lines: 40
In-reply-to: jeff@cjsa.UUCP's message of 30 Dec 87 15:10:37 GMT

Just in case anyone's interested:  I've managed to duplicate that lockup.
Notable is that it happened not long after I started rearranging things
around the computer... most notably, that d*mned printer cable.  I still
suspect spurious interrupts; but the printer may not be the only device
capable of sending them.  (Serial ports?  Maybe even bad termination on the
expansion ports?)

I was able to get the window manager to change the current window, but text
output didn't work, and the machine never got to a point in any window where
it was ready for input.  No, I didn't think to check the Caps Lock or Num Lock.

Possibly related?  I've been having a few other oddities:

Using "windy" too many times, or loading/unloading fonts (even the ones that
come with the machine) will cause an "su" in a subwindow to echo the password,
and immediately hang.  It *can* be interrupted without any problems.  I've
noticed that this tends to make the pre-crash sequence happen much sooner...
and this time, the actual crash as well.  (It appears to be based on the
"parent" window; log out and log back in (which closes and re-opens your login
window) and "windy" again works fine... for a while.)

I saw another unusual thing as well:  a program which up until just before the
crash worked perfectly suddenly started spitting out "calloc returned NULL in
_makenew" (yes, it uses curses/terminfo) errors when run.  The pre-crash
sequence began immediately afterward, when I fired up Emacs to look at the
program source....

Conclusion:  I strongly suspect a problem where the windaemon is somehow
interacting with the page daemon.  Spurious interrupts could be causing the
latter to go into some strange state, font mounting and/or whatever "windy"
does to create new windows could be confusing the former, and the two
apparently decide to get into a fight with each other.  (Maybe windaemon is
causing a massive number of page faults?)  The page daemon's involvement would
also explain the "out of memory" aspect.
-- 
 ___  ________________,	Brandon S. Allbery	       cbosgd \
'   \/  __   __,  __,	aXcess Company		       mandrill|
 __  | /__> <__  <__	6615 Center St. #A1-105		       !ncoast!
/  ` | \__. .__> .__>	Mentor, OH 44060-4101	       necntc  | axcess!allbery
\___/\________________.	Moderator, comp.sources.misc   hoptoad/