Problems upgrading UX400s running 743 to 80

[miller@SOL.CS.ROCHESTER.EDU (Brad Miller)]

[CC'd to slug because this "informational purposes only" concept deserves
 discussion]

    Date: Mon, 4 Jun 90 11:11 EDT
    From: Richard Munoz <MUNOZ@YUKON.SCRC.Symbolics.COM>

	Date: Wed, 30 May 90 20:01 EDT
	From: Brad Miller <miller@SOL.CS.ROCHESTER.EDU>

    Our UX expert suspects that you aren't running rpc.lockd.  He believes
    the UNIX file-locking substrate requires that daemon, even when the
    file(s) being locked is (are) on the local host. If you aren't running
    rpc.lockd, try reinstalling 8.0 (with 7.4 files cleared out first) and
    bringing up Genera with rpc.lockd running.

We are running rpc.lockd. I'm not sure if it's started b4 life support,
but that doesn't seem to be the problem...(life support doesn't use a
lock call) On the other hand, lockd may be crashing for some reason, I
didn't check; I suppose that could cause it to hang. At this point, I
have a working system, so I'm not going to spend a lot of time tracking
down this problem.

    FYI, we include the UNIX program sources for informational purposes
    only. Unfortunately, installing by hand or recompiling the sources
    provided will very likely cause you to lose in obscure ways. 

Now wait a minute. I use the sources supplied as basic and optional and
with the ux to make local changes. As far as I'm concerned, that's why I
want the sources. If Symbolics isn't supplying the right sources, then
they should! I don't understand why recompiling would cause any lossage,
but if you compile with static libraries, and our site uses dynamic as
a standard, we should be able to recompile them that way. Sure I had to
rewrite the makefile, but I didn't send you a bug report on that. 

And as for installation by hand vs. program, we don't put any of our
sources (to the kernel) in any of the SUN standard places. We also have
a number of local drivers. You really need to be able to support
installation by hand for sites that need that; in fact getting the UNIX
sources for the kernel, etc. was something we required of Symbolics
before our staff would approve the purchase of a UX400s because we
thought we may have to do a lot of stuff ourselves... You can't now
claim they are for information purposes only; that's breech of implied
contract. 

Furthermore I understand there was a bug in the automatic installer that
could crunch a non-standard installed device in the major device switch
table. So there's another reason for customers to be as self-sufficient as
possible, and another reason for you guys to send WORKING sources.

Last, I wouldn't be up under 8.0 right now, nor have been able to tell
you where the problem with the genera program was without the sources,
and without being able to recompile them. I don't see why progress on
our applications should be held ransom to fixes and workarounds supplied
by Symbolics (which we pay for, through warrenties and/or software
service contracts). 

If "informational purposes only" is a policy, I suggest it be
reconsidered IMMEDIATELY.

    Let me know if you get any farther. Thanks.
     - Rick

	SN: UX01119

	Got the upgrade tape today. Our UNIX gurus don't like the idea
	of installer programs, (why did you delete the instructions
	for installing manually if one should so desire) so after
	loading the new world from fep-tape, we overlaid the old
	software with the new stuff (for sun4s) <that is, the bin and
	etc directory), and overlaid the old .o s with the new, and
	rebuilt the kernel. New fonts were installed too. Life support
	started up without any problems, but running genera or
	describe-ivory causes the programs to go into state D
	(according to ps) on wchan of "socket". They never go out of
	this state, print no output, use no cpu time.

	Any ideas? Interestingly enough, the new software with the OLD
	kernel has the same symptoms. I didn't try the new software
	with the old kernel, i'm just now back to old/old.

	Date: Fri, 1 Jun 90 17:36 EDT
	From: Brad Miller <miller@SOL.CS.ROCHESTER.EDU>

	Comments: I#<900531-39869>

	More info:

	When I run trace on genera, I get (last few calls)

	open ("/etc/hosts", 0, 0666) =3
	ioctl (3, 0x40125401, 0xf7ffedae) = -1 ENOTTY (Inappropriate ioctl for device)
	fstat (3, 0xf7ffee20) = 0
	read (3, "######################".., 8192) = 8192
	close (3) = 0
	open ("/dev/ivory0", 02, 0) = 3
	mmap (0, 131072, 3, 0x80000001, 3, 0) = 0xf77a0000
	fcntl (3, 010, 0xf7ffec20) =

	at this point the program hangs as previously described.
	Observation of the source indicates it's trying to do a write
	lock on /dev/ivory0 from the beginning to the eof. I have no
	idea why the kernel doesn't return from this. As I said, the
	ps state is D and the WCHAN is socket.

	Date: Fri, 1 Jun 90 19:32 EDT
	From: Brad Miller <miller@SOL.CS.ROCHESTER.EDU>

	Comments: I#<900531-39869>

	1. One of our local unix gurus noted that the functions had
	been compiled with STATIC libraries, since we use dynamic, I
	recompiled. The lookup the function was doing in /etc/hosts
	now properly queried a nameserver... (which we run at our
	site) and we DONT use YP, btw...

	The main problem still remained:

	2. The fcntl is trying to lock the board. It appears in 
	boot.c in function boot_ivory.

	A similar problem (lockup) appears when using
	describe-ivory, and at the same point, the lock is done in 
	describe.c function describe_ivory

	I commented out both (we are only running one board, and I'm
	the only one with permission to open the dev), since the 7-4-3
	version didn't have these locks.

	Recompiled, installed, and the cold load window and genera
	CAME UP.

	So, I suggest you research this fcntl, it doesn't appear to
	work on all systems; I'm running on a 4/330 4.0.3(c). Further
	info on our kernel and local configuration can be had from
	roche@cs.rochester.edu; he is our local unix guru, I'm just the
	lowly lisp hacker :-)

	----
	 Brad Miller		U. Rochester Comp Sci Dept.
	 miller@cs.rochester.edu {...allegra!rochester!miller}
----
 Brad Miller		U. Rochester Comp Sci Dept.
 miller@cs.rochester.edu {...allegra!rochester!miller}