rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (03/13/90)
Folks, Thanks to all of you who responded to my earlier posting. Some of you pointed out that I might have been to harsh on NeXT, and after I read the posting over again, perhaps those people are right. Remember, I made the posting after fighting with our NeXTen (like vaxen?) for eight hours. Yelch! Some tips I picked up after those eight hours and from others: -- There apparently IS a work-around for the "skeleton" ttyp's not going away. Eric Scott wrote an App called GHOSTBUSTER that does the trick and Chris Lane (SUMEX, MOTD fame) wrote, well, MOTD as a LoginHook/LogoutHook App to solve the problem. We're implementing BOTH as a test although in one facility we had already used MOTD and have some problem still, but I'll let you all know. -- Although it wasn't part of that post, MANY people have asked about the memory experiments we did. Here are the names, dates, prices: 1 MB SIMM boards from Chip Merchant (adding enough to make 16 MB tot.) Price (at the time - $72.00 with P.O. per SIMM) Type: 80ns page mode, no parity We noticed a BIG difference here esp. with context switching. But, alas, launching an App is still a good time to go for coffee..:-) Adding enough to make 64 MB...even a better difference (still no improvement of launch time though). Note, these were 4MB SIMMs and cost much more. I can't give a price as we got them for evaluation and didn't end up buying them. We eventually bought "Sun" SIMMS from ClearPoint Systems in Massachusetts. But, for you 1 MB fans... Chip Merchant: 9285 Chesapeake Dr. Suite L, San Diego, CA 92123 (619) 268-4774 Good people! Back to the post responses... -- Portmaper and NMSERVER problems: Most everyone who responded here either said they never really nailed the problem down, or that Mach is still too young to really ever KNOW exactly where the problem lies (i.e. kern_loader, dispatcher, RPC, etc.) which is sort of the same thing I suppose. Remember, when running a netboot system, the only key server is the Configuration server as everyone else (clients and servers alike) get their RPCs from lookupd calls back to the config. server. If you read the man page on PORTMAP(8C)...(what's the "C" for?) you'll see that NeXT says if portmap fails you have to reboot the server. We found that under a netbooted system, this means the config. server really. The others don't matter. For nmserver debugging, add the "-p" switch to the portmap call in /etc/rc. This will log meaningfull errors such as the ones we got: netmsgserver[52]: **Dsipatcher: no handler function** netmsgserver[52]: srr_handle_request.disp_rr_simple fails (idsp_hdr=6d0002) netmsgserver[52]: **Dsipatcher: no handler function** netmsgserver[52]: srr_handle_request.disp_rr_simple fails (idsp_hdr=6d0002) At this point you have to rebbot the config. server. If you look in the /usr/adm/messages file you'll see: NFS getattr failed for server <config. server name here>: RPC: (unknown error code) <<-- You just gotta love it! Thanks to everyone who helped out, I hope others can learn from this knowledge! --Roger Jagoda --Cornell University --FQOJ@CORNELLA.CIT.CORNELL.EDU