4.71 Release Notes for SGI IRIX Computers
Back to 4.71 Release Notes.
Rev: August 1, 2000
CONTENTS
I. FEATURES THAT AFFECT SGI USERS
II. OBJECT-CODE FORMATS
III. KERNEL RECONFIGURATION FOR DATABASE SERVERS
IV. KERNEL RECONFIGURATION FOR System V IPC
V. KERNEL RECONFIGURATION FOR 64-bit Merlinserver
VI. SHARED OBJECTS and RUNTIME DYNAMIC LINKING
VII. THORSERVER & MERLINSERVER
---------------------------------------------------------------------------
I. FEATURES THAT AFFECT SGI USERS
The following shell scripts are provided to run XView programs under SGI's
default "4dwm" window manager;
xvmerlin4d
xvpcmodels4d
xvthor4d
sgi4d
This scripts are supported but are no longer absolutely required. Changes
to the Daylight "Options Manager" system allows automatic adjustment of
options which are window-environment specific (details below). In most
cases, the user environment can be arranged so that these scripts are not
needed. You may safely stop using the "4d" scripts under these conditions:
o you are not using SGI's default "4dwm" window manager, OR
o your client programs are running on an IRIX operating system, OR
o you have set the environment variable DY_WINDOW_ENVIRONMENT to SGI_4DWM
AND
o you are willing to set your default font as described below.
If you stop using the "4d" scripts, you must add a line similar to this to
your X Resources database (i.e. to the file $HOME/.Xdefaults):
Font.Name: -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso8859-1
Without this specified, XView programs will work correctly, but fonts used
for titles and buttons may be big and ugly. This normally takes effect when
you start X-Windows. To make this change effective immediately, enter:
$ xrdb $HOME/.Xdefaults
An example .Xdefaults that contains this line can be found in
$DY_ROOT/contrib/home/sgi/.Xdefaults.
Background:
A bug in the IRIX X Window system combined with bad habits in Sun's XView
code caused the IRIX window system to "lock up" when Daylight applications
were run. In addition, many of the default options (such as fonts, and
graphics parameters) had to be changed for optimum performance when running
under SGI's default window manager "4dwm".
To solve this, Daylight supplies a set of "wrapper" scripts, "xvmerlin4d",
"xvthor4d", and "xvpcmodels4d", that invokes XView programs with parameters
appropriate for use with IRIX X-servers and the 4dwm window manager.
With release 4.33 and later ...
These features are added to the Daylight "Options Manager" package:
1. A new "#if/#else/#endif" feature was added to the Daylight options
manager. This allows selective processing of options.
2. If the environment variable DY_OPERATINGSYSTEM is not defined at
runtime, the Daylight options manager will automatically set it to
the client's operating system (e.g., "IRIX", "SunOS", "HP-UX").
3. A new version of dy_sysprofile.dat is provided as a suggested
system profile. This file uses the new "#if" feature to set up
O/S- and window-specific options from environment variables
DY_OPERATINGSYSTEM and DY_WINDOW_ENVIRONMENT. Options for these
environments are provided: SGI_4D, HP_VUE, MAC_X, and SUN_OLWM.
The file dy_sysprofile.dat sets default SGI_4D option values for IRIX
operating systems, HP_VUE values for HP-UX, SUN_OLWM values for SunOS.
These values will be overridden if the DY_WINDOW_ENVIRONMENT variable
is defined. The MAC_X environment must be specified when needed.
---------------------------------------------------------------------------
II. OBJECT-CODE FORMATS
This version of the Daylight system has been compiled under IRIX 6.4.
A single set of binaries, which run under all IRIX6 machines (on R4000 or
newer CPUs) is distributed. For users of the toolkit libraries, the situation
is complicated by the object file formats.
In order to support 64-bit native systems, SGI has changed its
object code (.o) file formats. Under IRIX 6.X, SGI supports three separate
object file formats: 'old 32-bit', 'new 32-bit' and '64-bit'.
The SGI C and Fortran compilers and linker can generate all three object
format files. SGI supplies system libraries in all three formats.
Format Compiler flag System Library path
old 32-bit -32 /usr/lib
new 32-bit -n32 /usr/lib32
64-bit -64 /usr/lib64
SGI now uses three environment variables for the dynamic linker:
LD_LIBRARY_PATH: default shared library path (/lib:/usr/lib)
LD_LIBRARYN32_PATH: new-format 32-bit shared library path (/lib32:/usr/lib32)
LD_LIBRARY64_PATH: 64-bit shared library path (/lib64:/usr/lib64)
At runtime, the dynamic linker decides which format libraries are required
and uses the appropriate library path environment variable to search for the
needed libraries. LD_LIBRARY_PATH is searched first for libraries which match
the required format. Hence, the typical Daylight installation only requires
that LD_LIBRARY_PATH includes $DY_ROOT/lib. Furthermore, it is legal to
include different format library paths in LD_LIBRARY_PATH, and omit the
definition of LD_LIBRARYN32_PATH or LD_LIBRARY64_PATH.
For this version, Daylight is using -n32 as the default format for all
compilations and executables. We are using slightly different
naming conventions for our libraries.
The old 32-bit format libararies are in the $DY_ROOT/libo32 directory. They
are compiled under the old format (using the -32 option for cc and f77).
The new 32-bit format libraries are in the $DY_ROOT/lib directory.
They are compliled using the -n32 option for cc and f77, which are now
default on the SGI C-compiler. (See previous paragraph)
Under IRIX6.X, Daylight now supports 64-bit native toolkit code. The 64-bit
toolkit libraries are available in the directory $DY_ROOT/lib64.
Unfortunately, XView is not available in either the new 32-bit format or in
64-bit format in this release. If you are developing XView programs using the
Daylight widgets, they must be compiled using the old format libraries. In
this case, at runtime, LD_LIBRARY_PATH must include $DY_ROOT/libo32 in order
for the runtime linker to find the appropriate files.
Our recommendations for this release are to use the new-format libraries for
all development unless you are working with XView or another external factor
dictates otherwise.
See the man page for 'cc' under IRIX 6.X for further discussion of the
differences between the new- and old-format 32-bit libraries.
---------------------------------------------------------------------------
III. KERNEL RECONFIGURATION FOR DATABASE SERVERS
The Problem:
If you have a very large database, such as the SPRESI database, your
kernel may be configured with a memory limit that is too small.
When you try to load the database into the Merlin server, the server
will report "Out of memory," even when there is plenty of memory.
The Solution:
Use the "systune" program to reconfigure your system. The following
example illustrates raising the memory limits for each process to 1
gigabyte (only the super-user can do this):
# systune -i
systune-> resource
group: resource (statically changeable)
rlimit_rss_max = 536870912 (0x20000000)
rlimit_rss_cur = 1054482432 (0x3eda2000)
rlimit_vmem_max = 536870912 (0x20000000)
rlimit_vmem_cur = 536870912 (0x20000000)
rlimit_nofile_max = 2500 (0x9c4)
rlimit_nofile_cur = 200 (0xc8)
rlimit_core_max = 2147483647 (0x7fffffff)
rlimit_core_cur = 2147483647 (0x7fffffff)
rlimit_stack_max = 536870912 (0x20000000)
rlimit_stack_cur = 67108864 (0x4000000)
rlimit_data_max = 536870912 (0x20000000)
rlimit_data_cur = 536870912 (0x20000000)
rlimit_fsize_max = 2147483647 (0x7fffffff)
rlimit_fsize_cur = 2147483647 (0x7fffffff)
rlimit_cpu_max = 2147483647 (0x7fffffff)
rlimit_cpu_cur = 2147483647 (0x7fffffff)
systune-> rlimit_data_max 0x40000000
rlimit_data_max = 536870912 (0x20000000)
Do you really want to change rlimit_data_max to 1073741824
(0x40000000)? (y/n) y
In order for the change in parameter rlimit_data_cur to become
effective, reboot the system.
Do the same for:
systune-> rlimit_data_max 0x40000000 (shown above)
systune-> rlimit_data_cur 0x40000000
systune-> rlimit_vmem_cur 0x40000000
systune-> rlimit_vmem_max 0x40000000
systune-> rlimit_rss_cur 0x40000000
systune-> rlimit_rss_max 0x40000000
One customer trying to use more than 1 GB reports that several other
parameters had to be changed:
rsshogfrac to 98
gpgshi -- still experimenting?
gpgslo -- still experimenting?
See the system administration manual for complete details, and consult with
your SGI representative for more assistance.
---------------------------------------------------------------------------
IV. KERNEL RECONFIGURATION FOR System V IPC
Problem:
Beginning with Version 4.41, the nearneighbors program and the daytoolserver
program use System V semaphores for scheduling and process management. In
some environments, the default numbers of semaphore configured into the
kernel may be too small. This is indicated by problems starting either of
the above applications.
Solution:
Reconfigure the kernel with more semaphores. This is accomplished by
performing the following steps:
1. Run 'systune -i' as root. Within this shell, enter the following two
commands:
semmns 256
semmsl 128
2. Exit the systune shell.
3. Reboot.
This procedure should increase the number of semaphores sufficiently for
almost all installations.
---------------------------------------------------------------------------
V. KERNEL RECONFIGURATION FOR 64-bit Merlinserver
The Problem:
If you have a very large database, such as the SPRESI database, your
kernel may be configured with a memory limit that is too small.
The 64-bit merlinserver enables loading of multiple large databases
provided the process limits and combined RAM and swap allow so.
When you try to load the database into the Merlin server, the server
will report "Out of memory," even when there is plenty of memory.
In practice it has been found that 32-bit Merlinserver can't have a pool
size greater than 1.7 GB on IRIX. For any pool size above this, we
recommend using 64-bit Merlinserver
The Solution:
Use the "systune" program to reconfigure your system. The following
example illustrates raising the memory limits for each process to be
unlimited i.e. limited only by the combined RAM + swap space which should
exceed the combined size of the databases to be loaded.
(only the super-user can do this):
# systune -i
systune-> resource
group: resource (statically changeable)
rlimit_rss_max = 536870912 (0x20000000)
rlimit_rss_cur = 1054482432 (0x3eda2000)
rlimit_vmem_max = 536870912 (0x20000000)
rlimit_vmem_cur = 536870912 (0x20000000)
rlimit_nofile_max = 2500 (0x9c4)
rlimit_nofile_cur = 200 (0xc8)
rlimit_core_max = 2147483647 (0x7fffffff)
rlimit_core_cur = 2147483647 (0x7fffffff)
rlimit_stack_max = 536870912 (0x20000000)
rlimit_stack_cur = 67108864 (0x4000000)
rlimit_data_max = 1073741824 (0x40000000)
rlimit_data_cur = 1073741824 (0x40000000)
rlimit_fsize_max = 2147483647 (0x7fffffff)
rlimit_fsize_cur = 2147483647 (0x7fffffff)
rlimit_cpu_max = 2147483647 (0x7fffffff)
rlimit_cpu_cur = 2147483647 (0x7fffffff)
systune-> rlimit_data_max 0x7fffffffffffffff
rlimit_data_max = 536870912 (0x20000000)
Do you really want to change rlimit_data_max to 9223372036854775807
(0x7fffffffffffffff)? (y/n) y
In order for the change in parameter rlimit_data_cur to become
effective, reboot the system.
Do the same for:
systune-> rlimit_data_max 0x7fffffffffffffff (shown above)
systune-> rlimit_data_cur 0x7fffffffffffffff
systune-> rlimit_vmem_cur 0x7fffffffffffffff
systune-> rlimit_vmem_max 0x7fffffffffffffff
systune-> rlimit_rss_cur 0x7fffffffffffffff
systune-> rlimit_rss_max 0x7fffffffffffffff
To obtain the currently available swap space
# swap -l
which outputs something similar to
swap path dev pri swaplo blocks free maxswap vswap
2 /usr3/swap/swap1
0,315 2 0 8388608 3564512 8388608 0
1 /dev/swap
0,263 0 0 1048576 4128 1048576 0
The swap space is normally mentioned in blocks, each block corresponding to
approximately 0.5K. The combined RAM + swap must be at least as large as
the combined sizes of the databases to be loaded in the pool.
The available RAM on a system can be obtained by running the command
#hinv
which outputs something like
6 195 MHZ IP27 Processors
CPU: MIPS R10000 Processor Chip Revision: 2.6
FPU: MIPS R10010 Floating Point Chip Revision: 0.0
Main memory size: 1024 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
...
The Main memory size refers to the available RAM on the system (in this
case ~1GB)
To increase the swap space several alternatives are available and are
detailed on the system documentation (accessible with the command "insight"
or with "man swap")
After doing this if you're using the C-Shell or a derivative such as tcsh,
make sure that your user limits are all set to be unlimited or are set to
the hard limits set by the OS. To check your limits run:
csh% limit
cputime unlimited
filesize unlimited
datasize unlimited
stacksize 65536 kbytes
coredumpsize unlimited
memoryuse 2097152 kbytes
descriptors 1024
vmemoryuse unlimited
To unlimit any parameter that is limited (e.g. memoryuse) run the command:
csh% limit memoryuse unlimit
If the limit command still shows a limit for memoryuse, this is a parameter
that is hard set in your kernel. If the limit is not sufficient (i.e., it
is < 4GB (2^32)) see the top part of this section for information on
how to increase this limit if needed.
csh% limit datasize unlimit
The datasize limit controls the maximum size of the data segment.
This limit should either be set to unlimited or to a value larger than the
expected merlinserver size.
---------------------------------------------------------------------------
VI. SHARED OBJECTS and RUNTIME DYNAMIC LINKING
With version 4.61, Daylight has converted all of its executables to use
dynamic runtime linking. This feature allows the operating system to
more efficiently use its resources when multiple users are executing
Daylight programs. The operating system only needs to load one copy of
the Daylight libraries into memory to service all program users. This saves
memory, and can significantly improve overall system throughput for a
heavily loaded system.
A secondary benefit of this change is that the binaries of Daylight programs
are smaller by a factor of 5 - 10X. Basically, this is due to the fact
that the core toolkit code is not duplicated in every binary.
There are two issues related to making this switch to dynamic shared
objects. First, there is a slight startup penalty while the operating system
figures out where the dynamic shared libraries are found. This delay is
on the order of 10 milliseconds and should not be noticed by interactive
users. Furthermore, the overall performance of applications appears to be
better, because the system doesn't have to load a copy of the toolkit for
every application.
The second issue is the requirement that an additional environment variable
be set by every Daylight user. The environment varible LD_LIBRARY_PATH
is used by the operating system as a search path to find dynamic shared
objects. If the needed shared objects are not found, then a
program will not execute. The default library search path is typically set
to: /usr/lib:/lib/
The directory $DY_ROOT/lib/ must be added to this path.
sh and ksh:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DY_ROOT/lib/
export LD_LIBRARY_PATH
csh:
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${DY_ROOT}/lib/
Once set, Daylight executable programs will run without further intervention.
If this variable is set incorrectly, Daylight programs will fail with the
following messages:
$ thorls
29525:thorls: rld: Fatal Error: cannot map soname 'libdt_thor.so' using any
of the filenames /usr/lib/libdt_thor.so:/lib/libdt_thor.so: -- either the
file does not exist or the file is not mappable (with reason indicated in
previous msg)
This message indicates that the runtime linker can't figure out where
the file 'libdt_thor.so' is located. Correctly setting the LD_LIBRARY_PATH
will fix this problem.
NOTE: The program testlicense is not dynamically linked, since the license
management code must be present in every executable. Testlicense
will run successfully even though the LD_LIBRARY_PATH variable is not set.
For IRIX6, the situation is slightly complicated by the fact that SGI
supports three separate binary formats. Daylight provides all three
binary formats of the Dynamic Shared libraries. We recommend setting the
three different environment variables as follows:
sh and ksh:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DY_ROOT/lib:$DY_ROOT/libo32
LD_LIBRARYN32_PATH=$LD_LIBRARYN32_PATH:$DY_ROOT/lib
LD_LIBRARY64_PATH=$LD_LIBRARY64_PATH:$DY_ROOT/lib64
export LD_LIBRARY_PATH LD_LIBRARYN32_PATH LD_LIBRARY64_PATH
csh:
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${DY_ROOT}/lib/:${DY_ROOT}/libo32
setenv LD_LIBRARYN32_PATH ${LD_LIBRARYN32_PATH}:${DY_ROOT}/lib/
setenv LD_LIBRARY64_PATH ${LD_LIBRARY64_PATH}:${DY_ROOT}/lib64/
Once these three environment variables are set, the system will
automagically use the correct libraries for a given binary.
---------------------------------------------------------------------------
VII. THORSERVER & MERLINSERVER
The thorserver uses 34-bit file offsets and has a database file size limit
of 16GB. Writing data beyond the limit will cause database corruption.
As a protective measure, the thorserver will deny I/O and issue a
nonfatal error when a load of a TDT begins within 1MB of the limit.
If you want to load large (>1MB) TDT's, you are unprotected from
writing beyond the limit.
|