Path: utzoo!attcan!uunet!snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!uwm.edu!archimedes.math.uwm.edu!jgreco From: jgreco@archimedes.math.uwm.edu (Joe Greco) Newsgroups: comp.sys.ibm.pc.rt Subject: Re: problems with /etc/suspend (was: 6152 coprocessor card(s?)) Message-ID: <5663@uwm.edu> Date: 9 Aug 90 22:07:33 GMT References: <5417@uwm.edu> <5535@uwm.edu> <1990Aug6.184720.24494@ibmpa> <5600@uwm.edu> <1990Aug7.202533.18455@ibmpa> <5625@uwm.edu> <1990Aug9.181954.21524@ibmpa> Sender: news@uwm.edu Organization: University of Wisconsin, Milwaukee - Department of Mathematics Lines: 113 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 Disclaimer: I don't speak for the Math Department, the University, or myself.