webb@bass.paloalto.ibm.com (Bill Webb) (08/08/90)
In article <5600@uwm.edu>, jgreco@archimedes.math.uwm.edu (Joe Greco) writes: |> ... |> By the way, as far as I know Steve hasn't gotten an answer from ACSC yet on |> why /etc/suspend won't work with the new ethernet patches. Has anyone had a |> problem with this? |> |> ... Joe 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. ---------------------------------------------------------------- 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
jgreco@archimedes.math.uwm.edu (Joe Greco) (08/09/90)
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.
webb@bass.paloalto.ibm.com (Bill Webb) (08/10/90)
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
jgreco@archimedes.math.uwm.edu (Joe Greco) (08/10/90)
In comp.sys.ibm.pc.rt article <1990Aug9.181954.21524@ibmpa>, webb@bass.paloalto.ibm.com (Bill Webb) wrote:
:
:In article <5625@uwm.edu>, jgreco@archimedes.math.uwm.edu (Joe Greco) writes:
:|> 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.
Okay, this is the kind of info I need! ;-) I'm glad that unix.exe doesn't
do anything insane, but in an attempt to locate the problem I think I'll
build an old (unpatched) Kernel on the RT with the new C lib and includes.
This should help clarify whether or not these really *are* an issue.
: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).
Okay, now the Dec 88 release unix.exe complains that the coprocessor is not
waiting for restart. Yours says not running. Just to make sure you
understand that....
:I can't see how changing the library code is likely to affect any of the
:above.
Neither can we. I personally believe I've been careful and prudent. The
only thing I can imagine is that occasionally I do a hand-compile and leave
out the -DLIBC_SCCS or something like that, to quickly incorporate something
into the C library (?to?? routines, see below)...
: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.
Absolutely not. I'm booting unix.exe from the command line (no scripts,
etc). I have tried all four permutations of:
unix go
unix irq +3 go ( to boot unix)
and
unix restart 1 go
unix irq +3 restart 1 go ( to re-enter unix)
and a few other things that I did not document, in frustration ;-)
: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.
My apologies, I had been told that AOS was built around 4.2 with some
4.3isms. I must admit I believed this; it bears more similarity to our
Ultrix and VAX BSD 4.2 systems than the 4.3/Tahoe system we have on campus.
The C library in AOS is missing some useful (and necessary) routines such as
strcasecmp. I've been upgrading the networking utilities to the latest
Berkeley releases (available on uunet) and have found that several other C
library routines had to be added (strerror, I'm fairly sure, I don't recall
too many details). It seems even Berkeley calls a few different things BSD
4.3.
One of my most vehement complaints about AOS are the routines htonl,
htons, ntohl, and ntohs. These are macro defined in the include file
netinet/in.h (?). The Berkeley networking software doesn't consistently
include this include file (though apparently it does include sys/types.h)
and as a result I get linker errors up the kazoo. I finally got frustrated
and shot four "transparent" functions into the C library.
Don't get me wrong. I think it's an excellent idea to put it in as a macro,
since it saves processor time and memory. But that particular problem has
bit me several times even before the Berkeley networking software (and I
tell you, I get a kick out of the fact that Berkeley doesn't follow their
own specs.)
Problems like that just wreck my entire day. I used to curse IBM until I
finally understood enough to realize that IBM really had done a very good
job and it was more often the application programmer's fault...
As for the rest, I don't have a 4.3 machine to compare to. If I had Tahoe
source, I'd work on that some more. As it is, I just add what I need as I
need (and find) it. Actually I'm quite pleased at this point: I've been
porting sources intended for 4.3/Tahoe on the machine and I haven't had to
wrestle with them at all.
In case it doesn't show, I knew *no* C and only a very few UNIX commands
just two years ago. Please forgive any shortcomings in my knowledge. I'm
learning faster than I can.
... 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.