IRIX Base Documentation 2001 May

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2001 May / SGI IRIX Base Documentation 2001 May.iso / usr / relnotes / eoe / ch3.z / ch3

Wrap

Text File | 2001-04-17 | 59.1 KB | 1,387 lines

- 1 - 3. _C_h_a_n_g_e_s__a_n_d__A_d_d_i_t_i_o_n_s 3.1 _P_l_a_t_f_o_r_m_s__s_u_p_p_o_r_t_e_d This is an IRIX major release. It supports all current SGI system types. All system types supported in IRIX 6.2, 6.3, and 6.4 are supported in this release, with the exception of Crimson systems. IRIX 6.2 was the last release to support Crimson. This release of IRIX will support the R12K as it becomes available in systems. The R12000 performance counter implementation is different than the R10000, and this required changes in the ABI providing access to the counters. This change is visible to users using utitilies such as perfex. Please check the man pages for exact differences. (perfex(1), r10k_counters(5)) Use of the performance counters on systems with a mixture of R10000 and R12000 cpus installed is currently not supported, and may cause incorrect results to be reported. A system tuneable "perfcnt_arch_swtch_sig" can be set with systune(1m) to the signal number that will be send to the process group in case a process using performance counters is scheduled on CPUs with different event meanings. The default for this value is "0". Please note that such differences exist between R10000 Rev 2.X and R10000 Rev 3.0 as well and a signal would be sent for these cases as well. The tunable "perfcnt_arch_swtch_msg", if set to a non-zero value, will cause a message to be logged via syslogd when a signal is sent. 3.2 _G_e_n_e_r_a_l__O_S__F_e_a_t_u_r_e__C_h_a_n_g_e_s IRIX 6.2 was an all-platform release which supported all hardware platforms not considered obsolete at its time of release (March 1996). The following features are new or significantly changed since IRIX 6.2 (some were first released in IRIX 6.3 or 6.4). +o The version of sendmail previously installed with IRIX (8.8.8) has been replaced with Sendmail.org's sendmail version 8.9.3. There are many differences between IRIX sendmail version 8.8.8 and version 8.9.3. Some of the new functions in version 8.9.3 are as follows: - 2 - +o The major difference between sendmail versions 8.8.8 and 8.9.3 is their configuration file. The configuration file in sendmail version 8.9.3 is configured with the sendmail.mc file which is processed with the m4 macro processor to create the sendmail.cf file. +o A new version of configmail configures the sendmail.mc file and provides features similar to the configmail utility in previous versions of IRIX. This version of configmail also processes the sendmail.mc file into sendmail.cf by using the m4 macro processor. +o Sendmail 8.9.3 includes many new features requested by IRIX users, such as anti-relay features which can be used to control spam messages. For more information on the 8.9.3 version of sendmail, see the _I_R_I_X _A_d_m_i_n_i_s_t_r_a_t_i_o_n: _N_e_t_w_o_r_k_i_n_g _a_n_d _M_a_i_l guide. For more information on how to configure sendmail 8.9.3, see http://www.sendmail.org/m4/readme.html. +o The Irix name services have been completely rewritten. The new implementation known as the Unified Name Service is fully documented in the _I_R_I_X _A_d_m_i_n: _N_e_t_w_o_r_k_i_n_g _a_n_d _M_a_i_l guide. The following are the most obvious changes: +o All name service lookups are now cached in databases located in the directory /_v_a_r/_n_s/_c_a_c_h_e. +o A new daemon _n_s_d has been added to maintain the name service cache and manage all network name service requests for the system. +o A configuration file /_e_t_c/_n_s_s_w_i_t_c_h._c_o_n_f now controls the resolve order for all name services. The _h_o_s_t_r_e_s_o_r_d_e_r keyword in /_e_t_c/_r_e_s_o_l_v._c_o_n_f is now ignored. +o The _y_p_b_i_n_d and _y_p_s_e_r_v daemons have been replaced by the _n_s_d daemon. The services which were provided by the _y_p_b_i_n_d daemon are now included in the protocol library /_v_a_r/_n_s/_l_i_b/_l_i_b_n_s__n_i_s._s_o. The services which were provided by the _y_p_s_e_r_v daemon are now included in the protocol library /_v_a_r/_n_s/_l_i_b/_l_i_b_n_s__n_i_s_s_e_r_v._s_o. +o The BIND resolver routines in the C library are no longer used in name service lookups. Lookups to - 3 - DNS are now done by the _n_s_d daemon using routines in the protocol library /_v_a_r/_n_s/_l_i_b/_l_i_b_n_s__d_n_s._s_o. +o Certain commands which used to explicitely use NIS calls now call through the name service and may behave differently. An example is finger which used to list non-local users which were not listed in the password file, but now does not. +o The Hardware Graph provides a foundation for managing devices on systems with large, topologically complex I/O subsystems. You will notice that several directories in /_d_e_v are now symlinks to /_h_w. You should not attempt to unmount /_h_w. Please refer to the _h_w_g_r_a_p_h(4) manual entry for more information. +o The device nodes created by XLV are in /_d_e_v/_x_l_v and /_d_e_v/_r_x_l_v. +o Support for the lv(7M) logical volume manager has been removed. It is replaced by the xlv(7M) logical volume manager. The utility lv_to_xlv(1M) can be used to easily convert lv volumes to equivalent xlv volumes. In addition to the disk striping and concatenation features provided by lv, xlv supports disk mirroring and on line volume administration features that are not available with lv. +o The permissions of various devices can now be controlled via the _i_o_c_o_n_f_i_g(1M) program. See _i_o_c_o_n_f_i_g(1M) for more information on setting device file permissions. +o The compiler shipped with this release is the MipsPRO 7.2.1 compiler product. +o IRIX 6.4 was the first operating system release to support the new Scalable Shared Memory Processing (S2MP) architecture from SGI. The Origin200, Origin2000 and Onyx2 are the first machines to implement this new MP architecture, which provides extremely cost effective scaling of memory and processor bandwidth across a wide range of system configurations. The key architectural difference between S2MP systems and previous Symmetric Multiprocessor (SMP) systems, like the Challenge and PowerChallenge, is that the single shared SMP bus has been replaced by an expandable hypercube interconnect which provides a high bandwidth, low latency, cache coherent global view of system memory. A directory based coherency scheme provides a consistent view of - 4 - memory to all processors, but the latency for a particular processor to fetch a particular word from memory depends on the relative position of the processor and memory in the topology of the system. One of the key considerations for the operating system on an S2MP machine is to insure that processes and the data that they access are mapped efficiently onto the resources of the system. Significant work has been done on the design of the IRIX Virtual Memory and Scheduler subsystems to allow IRIX to manage resource locality on S2MP systems. Most of these changes will not be visible to users, system administrators or application programmers. In most cases, the default policies provided by the operating system will allow existing IRIX binaries, both single-threaded and parallel programs, to run extremely efficiently on S2MP systems. For the rare cases in which the default policies provided by IRIX do not match the needs of the application, several levels of tools are provided to allow applications to be mapped onto the hardware in an optimal way: - Compiler directives for sophisticated control of the mapping of application processing and data onto the machine architecture. Refer to Chapter 6 of the _M_I_P_S_p_r_o _F_o_r_t_r_a_n _7_7 _P_r_o_g_r_a_m_m_e_r'_s _G_u_i_d_e (document number 007-2361-004) for more information on the new features to support S2MP systems. - A memory and process placement tool, _d_p_l_a_c_e(1), which allows the programmer or user to specify the mapping of an application onto the system in a simple high level script language without modifying the binary executable. Please refer to the _d_p_l_a_c_e(1) manual entry for more information. - A memory access analysis tool, _d_p_r_o_f(1), which can be used to understand the memory reference patterns of an application. _d_p_r_o_f can also be used automatically to generate _d_p_l_a_c_e input script files. Please refer to the _d_p_r_o_f(1) manual entry for more information. +o IRIX 6.5 on S2MP systems provides a sophisticated dynamic memory migration facility to allow parallel codes with memory sharing patterns that change during execution to achieve excellent performance without code modifications. The S2MP hardware includes a mechanism for detecting pages which are being accessed remotely, rather than locally. An interrupt is generated to the - 5 - kernel, which then migrates the physical page to the appropriate location in the system to maximize locality of references. The migration control system in the kernel contains sophisticated mechanisms to prevent bouncing of pages and to balance the load on the system. On systems up to 32 processors, all memory in the system is sufficiently close topologically that page migration is normally not required. By default, the migration mechanism is not enabled until requested by an application. One way to do this is by using the -_m_i_g_r_a_t_i_o_n command of _d_p_l_a_c_e(1). The default behavior of the migration system can also be controlled by setting the following system tunable parameters: _n_u_m_a__m_i_g_r__b_a_s_e__e_n_a_b_l_e_d and _n_u_m_a__m_i_g_r__b_a_s_e__t_h_r_e_s_h_o_l_d. Refer to the comments in the tunable file /_v_a_r/_s_y_s_g_e_n/_m_t_u_n_e/_n_u_m_a for information about the possible values and their effects. +o The new command _s_n(1) command provides an interface for controlling the migration system. Please see the manual entry for details. +o The new command _n_s_t_a_t_s(1) prints statistics about the behavior of the memory management system. Refer to the _n_s_t_a_t_s(1) manual entry for details. +o IRIX 6.5 on S2MP systems provides dynamic memory replication facility for creating replicas of read-only shared pages, for example code pages of commonly used shared libraries (DSOs) like _l_i_b_c. On S2MP systems up to 32 processors, this facility is not enabled by default, but it can be activated by modifying the system tunable parameter _n_u_m_a__p_a_g_e__r_e_p_l_i_c_a_t_i_o_n__e_n_a_b_l_e which is defined in the file /_v_a_r/_s_y_s_g_e_n/_m_t_u_n_e/_n_u_m_a and can be modified by using the _s_y_s_t_u_n_e(1M) utility. +o The IRIX 6.5 virtual memory system has been enhanced to allow processes to select different page sizes for different portions of their virtual address space. The default page size remains 16KB, as in IRIX 6.2, for systems that support 64bit addresses, and 4KB for systems such as O2 that support only 32 bit addresses. On the Origin200, Origin2000 and Onyx2 systems, using the R10000 processor, the following page sizes may be selected: 16KB, 64KB, 256KB, 1Mb, 4Mb and 16Mb. A process can mix page sizes within a range of addresses, as appropriate. By default, the system will attempt to keep 20% of free system memory available as 64KB pages, but this behavior can be modified by setting the system tunables in the _l_p_a_g_e__w_a_t_e_r_m_a_r_k_s group. By using larger pages, programs with large datasets may achieve - 6 - a significant performance boost by minimizing TLB miss overhead. The _p_e_r_f_e_x(1) program can be used to monitor the number of TLB misses incurred by an application, which will give an indication of whether large pages will useful to a particular code. There are several ways to request page sizes other than the default. Please refer to the _d_p_l_a_c_e(1) manual entry for one example. +o XFS with this release of IRIX supports two new features: XFS quotas and automatically aligned inode allocation. The implementation of these features resulted in changes to the XFS on-disk filesystem data structures. As a result, XFS filesystems made with this release of IRIX will not be mountable by systems running any earlier IRIX release (5.3XFS, 6.2, 6.3, or 6.4) unless the current XFS patch for the older releases are first installed (a new miniroot from the patch will also be necessary if a root disk is to be used). This should normally be installed as part of a patchset, not by itself. +o IRIX 6.5 will be the last major release of IRIX that will support read/write EFS filesystems. In future releases of IRIX, EFS filesystems will be mountable only in read-only mode. EFS will continued to be supported for CD-ROM devices, and to allow old disks to be backed up or read. We strongly encourage that all new filesystems be made as XFS filesystems; the mkfs program and the miniroot now default to creating XFS filesystems. +o The scheduler in IRIX 6.5 has been improved in a number of areas. The previous notions of degrading and non- degrading priority processes have been replaced by more powerful and flexible realtime and timesharing scheduling disciplines. The timesharing discipline implements a currency-style scheduler, rather than the classic UNIX priority degradation mechanism for guaranteeing fairness. The meanings of the process priority values have been changed significantly. Several new system calls were added to request and modify the parameters of the new scheduling disciplines. Please refer to the _r_e_a_l_t_i_m_e(5), _s_c_h_e_d_c_t_l(2), _s_c_h_e_d__s_e_t_s_c_h_e_d_u_l_e_r(2) and _n_p_r_i(1) manual entries for further details. +o The _p_s_e_t(1M) and deadline scheduling facilities of IRIX 6.2 have been obsoleted and are not present in this release. - 7 - +o This release of IRIX contains a system threading facility, and many system daemons (such as _v_h_a_n_d and _b_d_f_l_u_s_h) now run as system threads. These daemons, like all system threads, are not now visible through _p_s(1), though they will be in a future release through a ps- like mechanism. System threads are used for device interrupts, parts of network service code, and user process system call handling. System I/O thread management services will be provided in future releases as part of the Hardware Graph facility. +o The values which are assigned for Process Identifiers (PIDs) have changed significantly from previous releases. This may cause problems for some non- portable applications. Prior to IRIX 6.5, PIDs would generally be assigned in increasing value -- often interpretable as consecutive integers -- which would wrap around in value somewhere around 30 thousand. Under IRIX 6.5 and later, PIDs are assigned values that are not predictable and the maximum PID value is now considerably larger, at approximately 2 billion. All portable applications should treat PID values as opaque objects with a potentially large and sparse value space. This change was made to support larger numbers of simultaneous processes while increasing performance. +o The _r_t_n_e_t_d(1M) command is no longer supported on any platform, and the contents of /_e_t_c/_c_o_n_f_i_g/_r_t_n_e_t_d and /_e_t_c/_c_o_n_f_i_g/_r_t_n_e_t_d._o_p_t_i_o_n_s are ignored. Networking threads such as _n_e_t_p_r_o_c and _s_o_c_k_d may have their priorities adjusted by using _s_y_s_t_u_n_e(1M) to control parameters in the ``sthread'' group. See /_v_a_r/_s_y_s_g_e_n/_m_t_u_n_e/_k_e_r_n_e_l for an explanation of these parameters. +o A new tunable, min_bufmem, has been introduced in IRIX 6.5.1m. It is the minimum amount of memory held by filesystem meta-data that will be cached in the buffer cache when the system runs into low memory conditions. The default value for min_bufmem is set to 2% of physical memory. +o The new 6.5 Desktop has been oriented towards using the Web as a medium to transfer visual/written information. +o A majority of the binaries installed from the 6.5 images have been compiled N32/mips3 instead of O32/mips2. +o The size of _c_p_u_i_d__t has increased from 8 to 16 bits so some /_p_r_o_c interfaces are not backward binary - 8 - compatible +o The default compilation mode with this release has been changed from previous releases, to now be optimized for the machine the compilation is run on. In particular for Origin, Onyx2 and OCTANE systems the default is n32/mips4/R10K. This is controlled by the /etc/compiler.defaults file. Please refer to _c_c(1) for more details on compilation modes. +o The version of Perl that comes with IRIX has been updated to 5.004_04. Previous releases of IRIX shipped with either v4.036 (IRIX 5.1 through 6.3) or v5.003 (IRIX 6.4). The standard Perl library has been moved to /usr/share/lib/perl5, and is in a separate subsystem (eoe.sw.gifts_perl_lib) that is installed by default. Perl5 was a complete rewrite of the language, with many new features. Due to minor incompatibilities, Perl5 is not a strict superset of Perl4. Porting scripts from Perl4 to Perl5 is normally very straight-forward. Instructions are in the "perltrap" man page. For backward compatibility, Perl5 supports the Perl4 method of accessing system structures, using the '*.ph' translated C header files (see the "h2ph" man page). The translation process is error-prone, and is no longer supported by the Perl community. It is highly recommended to translate your Perl scripts to use Perl5 modules. See the "perlmod" manpage. Perl5 was previously available on the Freeware CD. There are several differences between the IRIX EOE Perl5 and the Freeware perl5: This is v5.004_04, the Freeware versions were 5.001m and 5.002 (v5.003 and 5.004_04 were available unofficially). The path to install extensions has changed, from /usr/freeware/lib/perl5/site_perl to /usr/share/lib/perl5/site_perl. Any extensions that you were using with the Freeware Perl will need to be re-installed. The Freeware perl is not removed by this installation, so you can change the interpreter line in your scripts. Version 5.003 changed some of the internal structures from previous versions, so C extensions will need to be re-compiled. Version 5.004_04 is compiled with 5.003 compatibility on, so compiled extensions (for IRIX 6.4 only) should continue to work. The IRIX EOE Perl5 is compiled -n32 -mips3, - 9 - and will not load old or Freeware extensions (compiled -32) anyway, so you must recompile and reinstall any extensions that you use. Non- compiled (perl-only) extensions should work, if they are in the @INC load path. Any customized Perl4 library files placed in the Perl4 library location /usr/lib/perl will need to be copied (and checked for problems under Perl5) to /usr/share/lib/perl5/site_perl. Perl5 is designed to allow different versions and different architectures to coexist. The Freeware (-32) and EOE (-n32) Perls are configured to be different architectures ("irix" and "irix-n32" respectively). Therefore, if /usr/freeware/lib/perl5/site_perl and /usr/share/lib/perl5/site_perl are symlinked to the same directory, then they can safely and usefully share extension modules. +o IRIX 6.5.3 now contains support for the ISO8859-15 encoding which includes the new Euro currency symbol. The new encoding differs from ISO8859-1 by 8 characters: 0xA4 Euro sign 0xA6, 0xA8 Latin capital and small s with caron 0xB4, 0xB5 Latin capital and small z with caron 0xBC, 0xBD Latin capital and small ligature oe 0xBE Latin capital y with diaeresis It is known to _i_c_o_n_v(1) which can be used to convert data to and from other supported encodings such as Unicode. For every locale previously available in IRIX and whose written language could be represented in ISO8859-15, a new locale was added, for a total of 25 new locales. Out of those, 9 locales (de_AT, de_DE, es_ES, fi_FI, fr_BE, fr_FR, it_IT, nl_NL, pt_PT) have had their currency format updated to reflect the participation of their country in the European Monetary Union. The new locales can be selected by a user through the language customization panel, accessible from the toolchest. The locales themselves can be modified with the _l_o_c_a_l_e_d_e_f(1) utility by a call such as: #### ppppwwwwdddd ////uuuussssrrrr////lllliiiibbbb////llllooooccccaaaalllleeee////ffffrrrr____FFFFRRRR....IIIISSSSOOOO8888888855559999----11115555 #### llllooooccccaaaalllleeeeddddeeeeffff ----ffff ........////cccchhhhaaaarrrrmmmmaaaapppp////IIIISSSSOOOO8888888855559999----11115555 ----iiii ffffrrrr____FFFFRRRR....IIIISSSSOOOO8888888855559999----11115555....ssssrrrrcccc .... - 10 - This release of IRIX contains two new fonts (_7_x_1_3_e_u_r_o._p_c_f._Z and _7_x_1_3_e_u_r_o_B._p_c_f._Z) which can be used in conjunction with the new locales. They contain the Euro Symbol and they have the encoding FCD8859-15. They are part of the basic operating system and are installed by default. In addition, the Euro Symbol and encoding ISO8859-15 were added to the twelve European typefaces (4 Dutch 801, 4 Swiss 721, and 4 Courier 10- Pitch). They now each have 1016 characters. They are contained in the subsystem _x__e_o_e._s_w._X_u_n_i_c_o_d_e_f_o_n_t_s. To input the Euro sign, one can either assign it to a specific key using _x_m_o_d_m_a_p(1) or it can be generated using one of the three new compose sequences (see _c_o_m_p_o_s_e_t_a_b_l_e(5)): <<<<AAAAllllttttGGGGrrrr>>>> <<<<cccc>>>> <<<<====>>>> <<<<AAAAllllttttGGGGrrrr>>>> <<<<eeee>>>> <<<<====>>>> <<<<AAAAllllttttGGGGrrrr>>>> <<<<eeee>>>> <<<<---->>>> +o IRIX 6.5 has a newer version of _t_o_p(1) supporting interactive manipulation of running processes and more extensive machine state and multiprocessing support. +o IRIX 6.5 now includes Berkeley DB 1.85 library. +o IRIX 6.5 _i_n_s_t_a_l_l(1) was enhanced to be GNU/BSD compatible. It can now be invoked from typical GNU makefiles using the GNU/BSD syntax and do what's expected. +o A new product called gnu.*.* was added to the IRIX 6.5 base CD. It includes a big subset of the GNU commands. This product installs under /usr/gnu and needs to be explicitly selected for installation (i.e. it does not install by default.) +o IRIX 6.5 _c_r_o_n_t_a_b(1) was enhanced to allow root to edit/list/remove other users' crontabs. _c_r_o_n(1) was enhanced to provide more information on cron/at jobs that produced output like the vixie cron used on Linux and FreeBSD. +o In IRIX 6.5, the content of the _L_C__C_T_Y_P_E locale category has been extended to comply with the XPG/4 standard. The _L_C__C_T_Y_P_E binary format has changed and the old format will not be recognized by the C library. Therefore, all custom-built locales generated under IRIX 6.4 or earlier releases must be re-generated with the IRIX 6.5 version of _l_o_c_a_l_e_d_e_f(1) and associated _c_h_r_t_b_l(1M) or _w_c_h_r_t_b_l(1M) commands when the system is - 11 - upgraded to IRIX 6.5. The change was required because the old data structure created by _c_h_r_t_b_l(1M) allowed a maximum of eight (8) character classes to be defined. This was not sufficient to fully support the 11 basic character classes required by XPG/4. The new data structures were implemented by extending the _c_t_y_p_e(3C) table to contain 32-bit per character of character classification information. The three basic _c_t_y_p_e(3C) macros (_i_s_a_l_p_h_a, _i_s_g_r_a_p_h, and _i_s_p_r_i_n_t) were redefined to comply with XPG/4. These changes were implemented in the C library while preserving backward compatibility. Therefore, the executables compiled under IRIX 6.4 or earlier will continue to work identically under IRIX 6.5. However, new binaries compiled under IRIX 6.5 that use the _c_t_y_p_e(3C) or the _c_o_n_v(3C) macros will not run under a previous release of IRIX. +o IRIX 6.5 now supports the POSIX 1003.1e least-privilege mechanism, _c_a_p_a_b_i_l_i_t_i_e_s. Please refer to _c_a_p_a_b_i_l_i_t_i_e_s(4) for more details. +o IRIX 6.5 now supports POSIX 1003.1e Access Control Lists (_A_C_Ls) on files and directories. Please refer to _a_c_l(4) for more details. +o Both IRIX 6.4 and IRIX 6.5 have introduced changes to the data stream produced by the System Audit Trail facility. Although these changes will not affect users of the IRIX SAT tools (sat_interpret, sat_reduce, etc.), it will affect users of extended accounting (see _e_x_t_a_c_c_t(5)) or of any software that makes use of the extended accounting data. A new tool, _a_c_c_t_c_v_t(1), has been provided to convert the accounting records from the System Audit Trail facility back into the formats written by either IRIX 6.2 or IRIX 6.4. In most cases, this should allow existing extended accounting software to run under IRIX 6.5 without modification. For more details, see the _a_c_c_t_c_v_t(1) reference pages. +o IRIX 6.3, 6.4, and 6.5 have improved serial port support. On newer machines, bit (a.k.a. baud) rates greater than 38400 bps are now supported. O2, OCTANE, Onyx2, Origin2000, and Origin200 all support bit rates up to at least 115200 bps. Audio/Serial Option, on Onyx/Challenge systems, also supports high bit rates. Older machines, including Indigo, Indy, Indigo2, and Onyx/Challenge built-in ports, still support only up to 38400 bps due to hardware limitations. - 12 - Many tools built in to IRIX now support higher bit rates. Examples include _c_u(1), _i_n_i_t(1), _g_e_t_t_y(1), _l_o_g_i_n(1), _p_p_p(1), _s_l_i_p(1), and _s_t_t_y(1). See the _s_e_r_i_a_l(7) and _t_e_r_m_i_o(7) man pages for more information on serial ports hardware and programming. +o A new kernel debugging facility has been introduced with IRIX 6.5.1. This facility is installed with eoe.sw.kdebug but is not enabled by default. Refer to the comments about debug tunables in /_v_a_r/_s_y_s_g_e_n/_m_t_u_n_e/_k_e_r_n_e_l for information about using the facility. +o A set of new _f_c_n_t_l(2) commands is added to implement _o_p_p_o_r_t_u_n_i_s_t_i_c _l_o_c_k_s (_o_p_l_o_c_k_s) over XFS filesystems. An oplock is a _S_e_r_v_e_r _M_e_s_s_a_g_e _B_l_o_c_k (_S_M_B) construct used to grant exclusive access of a file to an SMB client. When another user accesses the same file, the SMB server revokes the oplock to the first user while the second user waits. This kernel level oplock allows the owning SMB server to receive file access notification from users over NFS, XFS, or SMB. See the _f_c_n_t_l(2) manual page for more details. This new feature is available only in the _f_e_a_t_u_r_e _o_v_e_r_l_a_y. These fcntl commands will fail EINVAL when run on a kernel without the feature overlay or when the _o_p_l_o_c_k_s__e_n_a_b_l_e_d systune variable is set to 0. +o _r_u_n_o_n(1) can run a command on a cpu that is part of a cpuset only if the user has proper permission to access the cpuset. +o For systems with the NFS server enabled, the number of nfsd NFS server daemons to create by default at startup has been changed. Previously the default was four. Now the default is to create as many nfsds as the system has CPUs which are available to schedule unrestricted processes, but no less than four. This should improve NFS server performance on larger machines. The new default can be overriden by specifying an alternative in the file /etc/config/nfsd.options. 3.3 _C_h_a_n_g_e_s__t_o__t_h_e__I_n_s_t_a_l_l_a_t_i_o_n__T_o_o_l_s IRIX 6.5 features enhancements to the IRIX software installation utilities, _i_n_s_t and _S_o_f_t_w_a_r_e _M_a_n_a_g_e_r (_s_w_m_g_r). These changes are summarized below. See the _i_n_s_t(_1_M) manual page, and the _S_o_f_t_w_a_r_e _I_n_s_t_a_l_l_a_t_i_o_n _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for more details. - 13 - +o Inst and swmgr now support a new type of installation product called an _o_v_e_r_l_a_y. Overlays, like patches, are products that only contain the subset of files from the base release that have been changed to fix a specific problem or set of problems. Unlike patches, however, the files that are being replaced are not saved. Therefore, it is not possible to remove an overlay without reinstalling the original base product. The name of the overlay product is the same as the name of the product it will upgrade. Thus, an overlay for the eoe product will also have the product name eoe. Two distinct types of overlays are supported : maintenance overlays and feature overlays. Maintenance overlays contain bug fixes and minimal support for new hardware. Feature overlays contain bug fixes, support for new hardware, and new software and hardware features. These two overlay types may not be mixed. Thus, a system may have feature overlays installed or maint overlays installed but not both. Any attempt to install both overlay types will result in an installation conflict. Showfiles has a new option, -_w, that shows only files that were installed as part of an overlay subsystem. Showprods also has a new option, -_o, to show only overlay subsystems. +o For 6.5.5, the default value of the _s_m_a_r_t__c_o_n_f_i_g__h_a_n_d_l_i_n_g preference was changed to _o_n. This change should reduce the amount of config file merging required after 6.5.x installations. +o For 6.5.4, the conflicts mechanism has been improved. When prerequisite conflicts are displayed, the name of the CD where the missing product resides is listed in the conflict message if that information is available. In addition, redundant products are no longer displayed in the conflict messages. +o For 6.5.3, the selection keyword _s_t_a_n_d_a_r_d has been modified to automatically include those subsystems selected by the _p_r_e_r_e_q_s keyword, and to exclude those subsystems selected by _i_n_c_o_m_p_l_e_t_e_o_v_e_r_l_a_y_s keyword. As a result, the command sequence _k_e_e_p * followed by _i_n_s_t_a_l_l _s_t_a_n_d_a_r_d is recommended for performing an upgrade. In Software Manager, the recommended upgrade procedure can be invoked from the Install menu (see below.) +o For 6.5.3, the single inst command _i_n_s_t_a_l_l _m_a_i_n_t can be used to switch from the feature stream to the maintenance stream, and make the appropriate product selections. Similarly, the _i_n_s_t_a_l_l _f_e_a_t_u_r_e command can - 14 - be used to switch from the maintenance stream to the feature stream. These commands should be issued after all the necessary CDs have been opened. Note that when switching streams, it may be necessary to insert the base IRIX 6.5 CDs in addition to the IRIX 6.5.3 overlay CDs. +o For 6.5.3, Software Manager has a new _I_n_s_t_a_l_l menu for convenience. This menu can be used only after opening the desired CD or CDs, and choosing Customize Installation mode. The Install menu has the following three items: Select Recommended Upgrades - this makes the appropriate selections for an upgrade, using the inst commands _k_e_e_p * and _i_n_s_t_a_l_l _s_t_a_n_d_a_r_d, described above; Switch to Maintenance Stream - performs the inst command _i_n_s_t_a_l_l _m_a_i_n_t, described above; Switch to Feature Stream - performs the inst command _i_n_s_t_a_l_l _f_e_a_t_u_r_e, described above. +o For 6.5.2, some of the inst messages displayed when reading distributions were changed slightly to be more descriptive. +o For 6.5.1 and later, two new overlay related inst keywords, _o_v_e_r_l_a_y_s and _i_n_c_o_m_p_l_e_t_e_o_v_e_r_l_a_y_s, have been added. _o_v_e_r_l_a_y_s lists the overlay subsystems present in the distribution. _i_n_c_o_m_p_l_e_t_e_o_v_e_r_l_a_y_s lists the overlay subsystems that are not installable because of missing prerequisites. _k_e_e_p _i_n_c_o_m_p_l_e_t_e_o_v_e_r_l_a_y_s will deselect all the uninstallable overlays. +o Applicable patch products are now selected for default installation. The selected patches will apply to either installed base products or distribution base products that are marked for install. Patches that were automatically selected for install will also be automatically deselected if the accompanying base product is either deselected or marked for remove. See the _a_u_t_o_p_a_t_c_h_s_e_l_e_c_t preference for more information. +o The new inst command _o_p_e_n can be used to view or install software from multiple distributions. The main benefit of this is conflict resolution across distributions. The related command, _c_l_o_s_e, is used to close a distribution that has previously been opened. _s_w_m_g_r provides identical capabilities from the File menu. +o When multiple distributions are open, the available inst keywords may be constrained to a particular distribution by prefacing each keyword with a substring - 15 - that uniquely identifies the distribution of interest followed by a colon. For example, _l_i_s_t _A_p_p_l_i_c_a_t_i_o_n: _N, would list only the new products on the Irix Application CD. +o When attempting to install a product from multi-user mode that requires a miniroot installation, _i_n_s_t or _s_w_m_g_r will boot the miniroot and continue the install automatically in the miniroot. See the _l_i_v_e__i_n_s_t_a_l_l preference in the inst(1M) man page for more information on this feature. +o _s_w_m_g_r has a new, more compact user interface when invoked in automatic (-a) mode. +o swmgr and inst have integrated tardist functionality making /_u_s_r/_s_b_i_n/_t_a_r_d_i_s_t effectively obsolete. By publishing a link to a ._i_n_s_t selections file, you can avoid locking up the browser while the tardist file is downloaded from the web. Details are in the inst(1M) man page. +o Within _s_w_m_g_r, the product release notes can be viewed with a single mouse click on the product of interest. If there are no release notes for that product, nothing will be displayed. +o A new inst keyword, _c_o_n_f_l_i_c_t_i_n_g, refers to products that are causing conflicts. The most common usage, _k_e_e_p _c_o_n_f_l_i_c_t_i_n_g, attempts to deselect all products causing conflicts. In some instances, conflicts may remain after this call since not all conflicts can be resolved by deselecting subsystems. Additionally, some required subsystems such as eoe.sw.base may be erroneously deselected if that product is involved in a conflict. The user should check that all applicable required subsystems are selected for install using the _l_i_s_t _r_e_q_u_i_r_e_d command. +o A new inst keyword, _p_r_e_r_e_q_s, refers to the minimal set of unselected distribution subsystems that will resolve the current prereq conflicts. The most common usage, _i_n_s_t_a_l_l _p_r_e_r_e_q_s, attempts to automatically resolve all prereq conflicts. In some instances, prereq conflicts may remain after this call since certain subsystems required to a resolve a conflict may not be loaded. +o Inst and swmgr record in the installation history the name of the distribution or CD that each product is installed from. This information can be displayed with the _s_h_o_w_p_r_o_d_s -_F command. - 16 - +o Miscellaneous improvements to error messages, online help, and text output, have been made. 3.4 _C_h_a_n_g_e_s__t_o__E_m_b_e_d_d_e_d__S_u_p_p_o_r_t__P_a_r_t_n_e_r__(__E_S_P__) +o The Embedded Support Partner (ESP), introduced with IRIX 6.5.5, provides system administrators with a means of monitoring various events that can occur on their system. ESP, which is an integral part of the IRIX operating system, introduces new daemons and a number of commands that perform the various monitoring activities. The new daemons include an event monitoring daemon (_e_v_e_n_t_m_o_n_d), database daemon (_e_s_p_d_b_d), and event management daemon (_e_s_p_e_m_d). Starting at IRIX 6.5.6, _e_s_p_e_m_d functionality has been merged into _e_v_e_n_t_m_o_n_d. +o Starting at IRIX 6.5.9, fixes and features introduced in ESP2.0 patchSG0003895 ( applicable to IRIX 6.5.7m+f and IRIX 6.5.8 m+f ) are availbale in this overlay. In particular, a _c_h_k_c_o_n_f_i_g _e_s_p flag has been introduced. Please also look at new features ( below ) and bug fixes documented in chapter 4. +o The types of events the Embedded Support Partner is able to monitor include changes in system hardware configuration (Challenge, Onyx, O2, Origin200, Octane, Origin2000 and Onyx2 systems only), changes in software configuration, system availability, system performance, etc. Starting at IRIX 6.5.9, Indy hardware (_I_P_2_2) configuration is now supported in ESP. Based on the nature and severity of a particular event, specific actions (e.g., sending a notification to the system administrator) can be programmed to take place automatically. ESP comes pre-installed with default actions already in place, but can be tuned to address specific customer support needs. In conjunction with ESP, many of the system error messages have been classified and tagged to allow for a more efficient event identification and tracking. Note that the facilities provided by the Embedded Support Partner replace those formerly provided by the Availmon utility. +o The Embedded Support Partner provides system monitoring capabilities on all systems running IRIX 6.5.5. Optionally ESP can be configured to receive event and system configuration data from all systems in a system group. When operating as a Group Manager, ESP is able to provide a single point from which to monitor all systems in the group. ESP is controlled via a Web browser which is connected to the Configurable Web - 17 - Server included as part of the ESP package. The browser interface provides a means for configuring the ESP behavior (e.g. which actions to perform for which events) and for generating ESP reports. In the absence of graphics, the interface uses Lynx up to IRIX 6.5.8. Since IRIX 6.5.9, Lynx interface is _n_o_t _s_u_p_p_o_r_t_e_d and , instead, a command-line interface is provided via _e_s_p_c_o_n_f_i_g(_1) _a_n_d _e_s_p_r_e_p_o_r_t(1) commands. Detailed reports can be generated that provide insight into system event activity, system configuration and changes, system availability, etc. Special user-level event types can also be defined to allow the use of ESP facilities to monitor customer application events. For more information, see the _e_s_p manpage. 3.4.1 _E_S_P__2_._0__N_e_w__f_e_a_t_u_r_e_s 3.4.1.1 _G_e_n_e_r_a_l +o A _c_h_k_c_o_n_f_i_g _e_s_p flag has been introduced. 3.4.1.2 _W_e_b__I_n_t_e_r_f_a_c_e +o The Web Interface has been totally re-designed to ease ESP users. +o For Web users, a printable view icon is provided against all the reports. Clicking the icon will generate a plain text output to the browser. +o Lynx ASCII Web console has been dropped and, instead, has been replaced with a very complete and flexible command-line interface, _e_s_p_c_o_n_f_i_g and _e_s_p_r_e_p_o_r_t. +o Previous version of ESP did not provide subsystem detailed information. Now, all subsystems information is maintained in ESP database for effectively tracking software changes and installation. +o Web Access now support the concept of several users. Each user now have their respective permissions such as configuration,report viewwing, etc ... 3.4.1.3 _E_l_e_c_t_r_o_n_i_c__L_o_g_b_o_o_k +o The Embedded Support Partner also provides the facility of an electronic log book for logging various activities performed on the system. The capability of a logbook has been provided through the graphical user interface. Entries upto 4K can be made using the logbook capability. A set of reports are available to - 18 - view the logbook entries between any given dates. The logbook entries are also cross referenced by the event reports on a date basis. This allows to check if any log entries are made against events. 3.4.1.4 _E_S_P__C_a_l_l__L_o_g_g_i_n_g__t_o__S_G_I +o The Embedded Support Partner may also send ESP events to a centralized database at SGI. An application (_e_s_p_c_a_l_l) has been introduced that gets automatically triggered against events if ESP has been configured to send data back to SGI. The application supports both text and compressed,encrypted, encoded formats. The format is also selectable both in the UI and command line applications. Information transmitted back to SGI depends on the type of event. Information includes customer contact information, event information, hardware and software installed, crash analysis and syslog information. The analysis report and syslog messages are sent only if the system panic'd. Information is mailed out to esp@sgi.com. Optional mail addresses can be entered to receive copies of what is mailed to esp@sgi.com . 3.4.2 _E_S_P__2_._0__M_i_g_r_a_t_i_o_n__i_s_s_u_e_s +o Information maintained in ESP database is migrated in a transparent manner. However, please note that in the case of an SGM environment, all systems in the group must run the same version of ESP (ESP2.0). Install ESP2.0 on the System Group Manager first. Then, on the member systems, must be installed with ESP2.0ed with ESP2.0 +o Database from a 6.5.9 system cannot be read by an earlier version of ESP. +o If an SGM environment exists for ESP1.0, all systems in the SGM environment must be upgraded to ESP2.0 for successful operation. The Group Manager must be upgraded first and then all members should be upgraded. After upgrading run espconfig -sgmconvert -c on each system starting from the group manager. The same license of ESP1.0 if installed will work. Alternately, set up the SGM environment again. +o This patch introduces a 'chkconfig esp' flag. The default is on. When you change this flag, please consult esp(5) man page CAVEATS section for specific instructions. - 19 - +o When the ESP User is 'administrator' and the default password provided in ESP1.0 is used, ESP Web Access is disabled. See details documented about BUG 774645 in chapter 4. +o Support for Lynx ASCII has been dropped in ESP 2.0. We now support a command-line interface. Please consult espconfig(1) and esperport(1) man pages for details. +o Support for espconfig(1) qpage configuration is not present in this release. Qpage configuration can only be performed via the Web interface. See also QuickPage(1M) man pages for more details. 3.5 _C_h_a_n_g_e_s _t_o _I_n_t_e_r_r_u_p_t _R_e_d_i_r_e_c_t_i_n_g _a_f_f_e_c_t_i_n_g _R_e_a_l _T_i_m_e _o_n _T_h_e _S_G_I _3_0_0_0 _s_e_r_i_e_s +o Hardware differences between Origin2000, and The SGI 3000 series, affect the way that interrupts can be redirected through use of the DEVICE_ADMIN and NOINTR directives. On Origin2000, the DEVICE_ADMIN directive can be used to redirect interrupts to a particular hardware CPU. On The SGI 3000 series, because of hardware limitations, interrupts cannot be deterministically redirected to a particular CPU. +o The Irix 6.5.9 release includes changes to compensate for the hardware differences between Origin2000, and The SGI 3000 series. The current behavior on Origin2000 is not affected by these changes. +o On The SGI 3000 series, if a DEVICE_ADMIN directive is used to redirect an interrupt, the hardware limitations may or may not allow the the interrupt to be redirected to the requested CPU. Should this occur, the following message will be seen on the console, and in the system log with the hwgraph path and CPU number being as appropriate for each case): +o WARNING: Override explicit interrupt targetting: /hw/module/001c10/Ibrick/xtalk/15/pci/4/ei(0x2f8), unable to target CPU 4 +o For a threaded interrupt handler, the directive will still ensure that the interrupt handler thread is given control on the CPU specified. This will effectively provide the same behavior that currently exists on Origin2000. - 20 - +o If the interrupt handler is non-threaded, and interrupt redirection is requested to ensure the handler runs on a particular CPU, then choice of the interrupt CPU is critical. A device on a particular PCI bus can only interrupt CPUs on one Processor Interface (PI), either PI-0 or PI-1. (A device can still interrupt CPUs on any node, but only those on one PI.) Knowing which CPUs are interruptable from which PCI bus is less than clear cut, as it is determined at boot time. Once determined, the set of interruptable CPUs for a particular PCI bus should not change from boot to boot, unless a system configuration change (CPU disabled, I/O reconfig) is made. +o If the above mentioned warning message is seen, indicating a interrupt redirect failed, then the following can be done to determine which CPUs an interrupt can be directed to, and the DEVICE_ADMIN directive changed accordingly. From the message, you know that CPU 4 is on a PI that cannot receive interrupts from the device in question. Output from an "ls" command will show which PI this is. In this case, it is PI-0. +o o3000% ls -l /hw/cpumun/4 v lrw------- ... 4 -> /hw/module/001c13/node/cpubus/0/a o3000% ls -l /hw/cpunum total lrw- ------ ... 0 -> /hw/module/001c10/node/cpubus/0/a lrw------- ... 1 -> /hw/module/001c10/node/cpubus/0/b lrw------- ... 2 -> /hw/module/001c10/node/cpubus/1/a lrw------- ... 3 -> /hw/module/001c10/node/cpubus/1/b lrw------- ... 4 -> /hw/module/001c13/node/cpubus/0/a lrw------- ... 5 -> /hw/module/001c13/node/cpubus/0/b lrw------- ... 6 -> /hw/module/001c13/node/cpubus/1/a lrw------- ... 7 -> /hw/module/001c13/node/cpubus/1/b - 21 - +o You now know that the PCI bus this device is on can only interrupt CPUs on PI-1. Using this knowledge and output from "ls -l /hw/cpunum" you can choose an interruptable CPU. In this example, changing the DEVICE_ADMIN directive to use CPU 2, 3, 6, or 7, will allow you to workaround this hardware limitation because as shown above, CPUs 2, 3, 6, and 7 are on PI-1.