4.92 Release Notes for SGI IRIX Computers
Back to Release Notes.
CONTENTS
1. FEATURES THAT AFFECT SGI USERS
2. OBJECT-CODE FORMATS
3. KERNEL RECONFIGURATION FOR DATABASE SERVERS
4. KERNEL RECONFIGURATION FOR System V IPC
5. KERNEL RECONFIGURATION FOR 64-bit Merlinserver
6. SHARED OBJECTS and RUNTIME DYNAMIC LINKING
7. THORSERVER & MERLINSERVER
---------------------------------------------------------------------------
1. 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
These 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.
---------------------------------------------------------------------------
2. OBJECT-CODE FORMATS
This version of the Daylight system has been compiled under IRIX 6.5.
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.
Several years ago, in order to support 64-bit native systems, SGI 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 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 libraries are no longer supported and are not
shipped with this release.
The new 32-bit format libraries are in the $DY_ROOT/lib directory.
They are compiled using the -n32 option for cc and f77, which are now
default on the SGI C-compiler. (See previous paragraph)
Under IRIX6.X, Daylight 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 64-bit format in this release.
If you are developing XView programs using the Daylight widgets, they must
be compiled using the new format 32-bit libraries. In this case, at
runtime, LD_LIBRARY_PATH must include $DY_ROOT/lib in order for the
runtime linker to find the appropriate files.
To compile the contrib code in new 32-bit format in $DY_ROOT/contrib/src
type "make install". To compile the contrib code in 64-bit format
in $DY_ROOT/contrib/src type "make install64".
---------------------------------------------------------------------------
3. 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
your SGI representative for more assistance.
---------------------------------------------------------------------------
4. KERNEL RECONFIGURATION FOR System V IPC
The Problem:
Beginning with Version 4.41, the nearneighbors program
uses System V semaphores for scheduling and process management.
In some environments, the default number of semaphores configured
into the kernel may be too small. This is indicated by problems
starting either of the above applications.
The 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.
---------------------------------------------------------------------------
5. 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 = 1073741824 (0x40000000)
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.
---------------------------------------------------------------------------
6. 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 variable
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 supports n32 and 64
binary formats of the Dynamic Shared libraries. We recommend setting the
different environment variables as follows:
sh and ksh:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DY_ROOT/lib
LD_LIBRARY64_PATH=$LD_LIBRARY64_PATH:$DY_ROOT/lib64
export LD_LIBRARY_PATH LD_LIBRARY64_PATH
csh:
setenv LD_LIBRARY_PATH ${LD_LIBRARY_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.
---------------------------------------------------------------------------
7. 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.
Back to Release Notes.
|