Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!usc!wuarchive!uunet!ibmsupt.uucp!bass.paloalto.ibm.com!webb
From: webb@bass.paloalto.ibm.com (Bill Webb)
Newsgroups: comp.sys.ibm.pc.rt
Subject: Re: problems with /etc/suspend (was: 6152 coprocessor card(s?))
Message-ID: <1990Aug9.181954.21524@ibmpa>
Date: 9 Aug 90 18:19:54 GMT
References: <5417@uwm.edu> <F?.1.n91@cs.psu.edu> <5535@uwm.edu> <1990Aug6.184720.24494@ibmpa> <5600@uwm.edu> <1990Aug7.202533.18455@ibmpa> <5625@uwm.edu>
Sender: news@ibmpa (news id)
Reply-To: webb@bass.paloalto.ibm.com (Bill Webb)
Organization: IBM AWD Paloalto
Lines: 51


In article <5625@uwm.edu>, jgreco@archimedes.math.uwm.edu (Joe Greco) writes:
|>...
|> 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?
|> ... Joe

The way that the suspend/restart code works is that it brings down each
of the devices by calling their suspend entry point. It then puts a 
magic number (RESTART_MAGIC) into low Romp processor memory and then sits 
there with interrupts disabled (except for the clock) waiting for the 
magic number to go to zero. All of this code is in the suspend() function
in /sys/ca/autoconf.c. The corresponding PC code is in the romprestart
function in /sys/pc_code/rbinit.c. 

From your description of the problem, it appears that the magic number
is OK (if it isn't you get the message "coprocessor not waiting for restart"),
but that the Risc processor isn't actually executing (the PC code checks to
see that the counter is being incremented by the Risc processor to tell
that it is still alive).

I can't see how changing the library code is likely to affect any of the 
above.

One thing that might affect the ethernet code is the use of the UB TSR
routine (nicpshh.exe) that was supposed to watch the UB driver ROM code to
see if it failed. If you are still running this code out of the
autoexec.bat file then you should delete it. The current driver does
not use the UB code in ROM and drives the UB card directly from the
Risc processor.

I'm hoping to send a kernel to ACSC today (if our internet connection
is working) so that they can see if that works. 

PS: I'm curious what you've changed to make "AOS a few steps closer to
true 4.3 compatibility" since it was based on BSD 4.3 to begin with, and
BSD 4.2 before that. If you mean 4.3 TAHOE then I can understand what
you are doing, but I thought we had 4.3 compatibility by being based on
4.3.

----------------------------------------------------------------
The above views are my own, not necessarily those of my employer.
Bill Webb (IBM AWD Palo Alto), (415) 855-4457.
UUCP: ...!uunet!ibmsupt!webb