🚀 go-pugleaf

In comp.sys.ibm.pc.rt article <1990Aug7.202533.18455@ibmpa>, webb@bass.paloalto.ibm.com (Bill Webb) wrote:
:I tried /etc/suspend on both token ring and ethernet machines and it
:worked fine for me. I've sent a copy of the unix.exe that I'm using
:to ACSC to see if it works for them as well. If so I expect they will 
:forward a copy to you as well.

They have; no luck.  They said it worked for them.  They were out to lunch
as I was leaving, but I believe Steve is going to try calling again later.

(sigh).

Now here's a question: We've rebuilt parts of the C library and /usr/include
on the RT we use to generate the ATR Kernels.  I was basically very careful
not to wipe out anything that seemed to have been added by IBM.  The point
was to bring up AOS a few steps closer to true 4.3 compatibility, and on
that respect I've been very successful.  Could these changes affect the
Kernel in a way that would cause unix.exe to reject a restart?

Perhaps more simply, I should ask: what the hell does unix.exe do to
determine whether or not the coprocessor is awaiting a restart?

I'm going to try building an old, un-Ethernet-patched ATR Kernel and see if
that works.  If not, perhaps it IS the C lib or the include files.
Suggestions?  (besides obvious permutations such as using the old C lib and
include files, which I'll also try)...

As a sidenote, when we restarted the new Kernels in the past, the 6152
replied "Fatal pc code error (whatever); coprocessor not waiting for
restart".  Your unix.exe simply states "Fatal ....; coprocessor not
running."

... Joe

-------------------------------------------------------------------------------
Joe Greco - University of Wisconsin, Milwaukee - Department of Mathematics
jgreco@archimedes.math.uwm.edu		USnail: Joe Greco
Voice: 414/321-6184				9905 W. Montana Ave.
Data:  414/321-9287 (Happy Hacker's BBS) 	West Allis, WI  53227-3329
#include <witty_and_humorous_saying.h>
Disclaimer: I don't speak for the Math Department, the University, or myself.