🚀 go-pugleaf

In article <1991Feb14.062908.4073@batcomputer.tn.cornell.edu>,
rogerj@theory.tn.cornell.edu (Roger Jagoda) writes:

Your sendmail.cf problem's already been addressed...

>2) During the kernel configuration, two bugs occur/pop-up/etc.
>The installation procedure asks for a name for your machine and
>then puts it into the configuration file under that name:
>
>For us it was "/sys/conf/mips/PLASMIPS"
>
>Now, just look at the lines in that file for the system name:
>
>
>ident		"PLASMIPS"
>
>..etc. Notice it's in ALL CAPS! Look at the host table entries,
>they're all lower case. See the problem? As soon as you fire up
>nfsd (if you can) you'll get an error:
>
>gethostbyname() failed, nfsd not started. Of course gethostbyname()
>failed, the rpcinfo is looking for "PLASMIPS" and the
>machine name is "plasmips". The "fix" is to go into
>/etc/rc.local and change the /bin/hostname call to lower
>cased name:
>
>
>#
>#  "@(#)rc.local	4.1.1.7	(ULTRIX)	8/9/88"
># /bin/hostname PLASMIPS
>/bin/hostname plasmips

Who put the '/bin/hostname' line into rc.local? Normally, it's the FQDN of the
system.


>
>3) During the kernel configuration/installation, the DECStation's
>RAM is NOT counted properly. We have 24MB configured in one
>machine. During the PROM start-up (no ULTRIX yet), the machine
>SLOWLY ticks through all 24MB.......Great! But, look what it
>put into the configuration file:
>
>physmem		12
>
>Great, so now we have to do a re-config again. Phooey! If the
>ROM can get the CORRECT RAM figure, why can't the installation/
>kernel config procedure??

What led you to  think that you needed to re-config? The 'physmem' line in the
configuration
file isn't necessarily the amount of memory on the system... to quote the 'Guide
to Configuration
File Maintenance':
'This parameter defines an estimate of the amount of physical memory currently
in the
system, in megabytes. The *number* argument is not used to limit the amount of
memory;
it is used to size the system page table.'

Basically, it's not important. Until you raise it above 64k it will have NO
affect on the
kernel that you generate.


>The last bug is in the LATEST but NOT greatest FORTRAN compiler
>for DEC's RISC side: Look at these results:
.... deleted ...
>I regard the latter as the correct result. The RISC fortran compiler
>can't handle external function calls properly??!! That would
>REALLY hinder a LOT of our code. 

This isn't a  compiler error; your program is missing a declaration for routine
'sum', so
it's assuming the default of REAL*4 for the function. What else can the compiler
do? The VAX
gets the 'correct' result due to the layout of the VAX floating point numbers;
the IEEE REAL*8 isn't
just a REAL*4 with a few bits added to the end. Compiling with -r8 makes the
program work
as it makes 'sum' REAL*8 by default;  compiling with -u finds the undeclared
function
reference.
	-Rick
-
Rick Murphy, WA1SPT/4			DEC Washington ULTRIX Resource Center
Domain:  murphy@burfle.dco.dec.com -or- murphy@ufp.enet.dec.com
Bang:    decwrl!ufp.enet!murphy		Ding:  (301) 306-2985
Disclaimer: This nonsense came from an AI program written in TECO. Ignore it.