========================================================================== The checksum's (found through sum -r) of the files that you have received (other than this README) are as follows: 01883 21 patchSG0003735.idb 06942 1576 patchSG0003735.eoe1_sw 46554 4 patchSG0003735 46771 519 patchSG0003735.eoe1_man ========================================================================== - 1 - 1. Patch_SG0003735_Release_Note This release note describes patch SG0003735 to IRIX OS version 5.3. Patch SG0003735 replaces patches SG0002368, SG0002307, SG0002002, SG0001497, SG0001060, SG0000882, SG0000813, SG0000768, SG0000613, SG0000534, SG0000345 and SG0000343. 1.1 Supported_Hardware_Platforms This patch applies to all hardware platforms supported by the IRIX OS at revision 5.3. 1.2 Supported_Software_Platforms This patch contains bug fixes for IRIX 5.3. The software cannot be installed on other configurations. 1.2.1 Special_procedure_for_installing_this_patch This patch replaces eoe2.*.availmon and availmon.*.*. Before installing this patch, check if eoe2.*.availmon and availmon exist: versions "eoe2.*.availmon" availmon If either exists, run (as appropriate) versions remove "eoe2.*.availmon" availmon Then, follow Section 1.7 to install this patch. If the old version of availmon was used before installing this patch, the local availmon log file, /var/adm/avail/availlog will be renamed as /var/adm/avail/availlog.O. 1.2.2 Special_procedure_for_removing_this_patch If the old version of availmon was used before installing this patch, removing this patch requires reinstalling eoe2.sw.availmon. After reinstallation, rename /var/adm/avail/availlog to another name, and rename /var/adm/avail/availlog.O to /var/adm/avail/availlog. - 2 - 1.3 Bugs_Fixed_by_Patch_SG0003735 Descriptions of fixes in this patch include bug numbers from Silicon Graphics bug tracking system for reference. The following bug fixes in IRIX 5.3 are included in this patch. o Icrash Y2K problem on 5.3, 5.3XFS (Bug #753475). o Availmon 2.1 generates a correction report if a System Serial Number or Hostname change is detected. This generated report is sent to configured e-mail addresses to notify them of change in Serial Number or Hostname. Availmon, before sending this report, should check whether automatic reporting is turned on. This check is missing resulting in the correction report sent to the configured addresses even if availmon reporting is off (bug 516080). o Installation of patches SG0002002 and SG0002307 fails if the file statusinterval is missing from the configuration directory of Availmon (/var/adm/avail/config). This error is fixed in this patch (bug 513818). The following bug fixes are included from patch SG0002307. o Minor bug fixes to /sbin/init (bugs 453524 and 466570) where init under heavy stress could miss signals. Over time this resulted in all process slots being filled with defunct processes and ultimatly with a system panic. The precise symptom is: "PANIC: init died (why = 2, what = 0x9)" This specific symptom ("init died") identifies the critical difference between this patch and patch 2002. Bug 466570 refers to a performance issue in high stress situations in the Irix 6.4 OS release of init from which this edition of init is derrived. The following bug fixes are included from patch SG0002002. o Added the capability to send a "status update" report, at a configurable period (in days), indicating that the system is still up and running. See amconfig(1M) "statusinterval". The default is statusinterval = 60 (days) for high end systems, and statusinterval = 0 for low end systems, which disables sending such reports (rfe 269570). - 3 - o Several errors by the init.d availmon script showed up in abnormal cases, including instances of corrupted saved information. Those errors are fixed (bugs 318047, 326347, 333777, 335887). o Amregister could hang when it was invoked with an invalid argument, such as "root@localhost". In such cases, amregister now properly gives an error (bug 321958). o Certain incomplete or unexpected message formats in SYSLOG could cause the amsyslog command to crash. Amsyslog is run while producing an Availmon report. The correctness and format of every message in SYSLOG is now checked (bugs 336199, 338326, 340193, 485937). o Added a new "pager" report capability. This supports sending a concise report intended for a "chatty pager", idenfitying the hostname, a brief description of the event reason, and the summary (if present). See amconfig(1M) "autoemail.list" (rfe 463973, 463983). The following bug fixes are included from patch SG0001497 and its ancestors. o Systems that have dynamically loaded drivers residing in K2 memory will cause 'icrash' to core dump, because memory routines within 'icrash' did not initialize before the mload symbol table was initialized. The order of the calls were changed to accommodate this (bug 326936). o This patch rotates /var/adm/avail/availlog if the size is larger than 100K bytes (bug 300686). o Access to /dev/tty returns "no such device or address" in single user mode (going from run level 2 to S with tickerd flag on) (bug 389167). o This patch moves availmon binaries to /usr/etc and keeps symbolic links in /var/adm/avail. This is more space efficient for diskless systems (bug 316859). o This patch provides a new command, amdiag, to support live diagnosis utilities, irsaudit, kpm, and field-atp (bug 346837). o The amreport(1M) epoch format list entries need an additional item indicating system restart time (bug 268141). - 4 - o Amreport(1M) cannot handle duplicate reports (bug 268147, 268160). o No relnotes for eoe2.sw.availmon (bug 253243). o Configuration files, /etc/config/avail and /etc/config/availnotify, are missing, and no instructions on how to enable availmon (bug 257068). The following are known problems. o If a system is taken down to single user mode and while in single user mode a reboot is requested, availmon will generate a single user report followed by a reboot report after coming back up to multi user mode. The re-start time for the single user report, and the start time for the reboot report are the same, the event time of the reboot request. However, when the system is reset while in single user mode, availmon is not able to correctly determine the time of the reset event. This will cause amreport to incorrectly display the re-start time for the single user report and the start time for the reset report (as Dec 31, 1969 or Jan 1, 1970). This will also cause computed downtime to be incorrect in such a case. o On older platforms which doesn't have a machine readable serial number and which have been registered to send availmon reports, running 'amconfig autoemail.list' to add e-mail addresses will cause a spurious error message to be printed out saying that 'this platform, does not have a machine-readable serial number. Please use '-s' option'. Consequently, no Registration Report is mailed out. The recommended practice for older platforms (which doesn't have a machine-readable serial number) is to add all the e- mail addresses initially while registering. 1.4 Availmon_Overview This patch provides bug fixes for prior Availmon 2.1 patches. The functionality provided is no different from the patch SG0002002. Patch SG0002002 provides enhanced Availmon functionality as well as bug fixes for previous Availmon versions. It is identified as Availmon version 2.1. Reports sent by Availmon include a field identifiying the 2.1 version. See amreport(1M) for how to verify the installed Availmon version. Patches SG0003735, SG0002369 and SG0002370 provide Availmon 2.1 bug fixes for IRIX releases 5.3, 6.2 and 6.4 - 5 - respectively. 1.4.1 Availmon_2.1_Features New features which were incorporated in patch SG0002002 of Availmon 2.1 include the following. System serial numbers: machine readable serial numbers are strictly enforced. The first time Availmon 2.1 boots on a system, if the saved serial number is not correct (that is, if it is different from the machine readable serial number), a special "ID correction" report will be sent, notifying of the the corrected serial number. Thereafter, only the correct machine readable serial number will ever be used. Only very old hardware platforms do not provide a machine readable system serial number. Single-user handling: taking a system down to single-user and then back up to multi-user will be treated as downtime, and an availmon report will be generated. A shutdown reason prompt will be given (if configured). From single-user, a full reboot or a crash will be handled as a second event. In the case of a full reboot, a second shutdown reason prompt will be given (if configured). Resending prior reports: amreport supports marking historic events and resending them, by default to configured email addresses, but allowing change of addresses for the purpose of the resend. Availability data can always be resent. Diagnostic information can be resent only if the appropriate files have not been removed from the dump directory. In any case, the resend request will always be accepted and whatever data is available will be resent. Amreport is significantly upgraded. In addition to the ability to resend historic data, amreport can display all information interactively or as a report written to standard output. It offers an improved metrics summary that breaks down events by catagories and shows availability overall and per catagory. Amreport also adds -f and/or -t allowing "from" and/or "to" time specifications for either interactive operation or for generated reports. It accepts s in the same form as touch(1). See amreport(1M). Panic analysis: panics are now distinguished as one of three kinds: panics known to be due to hardware or known to be due to software, or panics due to unknown causes. In prior Availmon versions, the last two panic catagories were grouped together (e.g. two catagories: "hardware" and "not hardware"). The three-valued distinction is important on - 6 - high-end platforms IP19, IP21, IP25 and IP27, where built-in analysis of hardware error state provides the distinction of known hardware or known software or inconclusive state. Pager report: a simple, concise pager report is added, designed to be sent to a chatty pager. This includes the hostname, a brief event description, and the summary (if available). See amconfig(1M) for how to configure sending pager reports. 1.4.2 Registering_Availmon On reboot, Availmon 2.1 can send a report via Internet email to SGI in Mountain View or other destinations as desired. Information in such reports is strictly related to system availability, and optionally may contain diagnostic information related to the causes of the reboot. The email addresses and other availmon actions are configurable via the utility "amconfig" (see availmon(5) and amconfig(1M)). It is necessary to enable sending email reports by "registering" after installing this patch. The default configuration will send a diagnostic report on each reboot to "availmon@csd.sgi.com", once registered. Follow these steps to enable Availmon sending reports: 1. After installing patchSG0003735 and rebooting the system, run amconfig if any configuration change is desired (see amconfig(1M)). 2. To "register" availmon and enable sending reports, run /usr/etc/amregister -r unless running on an old hardware platform, which can not return a machine readable system serial number. In that case, run /usr/etc/amregister -r -s In the event the system does not have email access, refer to availmon(5) for configuration examples. Generally, a reboot is required to complete the installation. If the system is running critical applications that can not afford the extra reboot, after installing patchSG0003735, run /etc/init.d/availmon start - 7 - Then follow step 2. above to enable availmon. 1.5 IRIX_System_Crash_Analysis_Utility This section contains a brief description of what 'icrash' provides. More specific information can be obtained from the manual page for icrash(1M). The 'icrash' utility will generate detailed reports about system crash dumps created by savecore(1). The reports are generated when the system reboots after a system crash. The following information is contained in the 'icrash' report: o Status (system name, date and time of crash) o The name and location of the unix.N and vmcore.N.comp core files o Cause of the crash (hardware or software failure, NMI, etc) o Dump of the putbuf containing recent console messages o CPU Summary (name or process running, stack trace, etc) o List of sleeping processes and their sleep state (for NMI core dumps) In addition to generating crash reports, 'icrash' provides a set of commands for displaying detailed kernel information in an easy-to-read format. Most commands report data in an organized fashion so that SGI kernel knowledgable engineers can decipher the system crash more easily. 1.6 Subsystems_Included_in_Patch_SG0003735 This patch release includes these subsystems: o patchSG0003735.eoe1_sw.unix o patchSG0003735.eoe1_man.unix 1.7 Installation_Instructions Because you want to install only the patches for problems you have encountered, patch software is not installed by default. After reading the descriptions of the bugs fixed in this patch (see Section 1.3), determine the patches that meet your specific needs. - 8 - If, after reading Sections 1.1 and 1.2 of these release notes, you are unsure whether your hardware and software meet the requirements for installing a particular patch, run inst. The inst program does not allow you to install patches that are incompatible with your hardware or software. Patch software is installed like any other Silicon Graphics software product. Follow the instructions in your Software Installation Administrator's Guide to bring up the miniroot form of the software installation tools. Follow these steps to select a patch for installation: 1. At the Inst> prompt, type install patchSGxxxxxxx where xxxxxxx is the patch number. 2. Initiate the installation sequence. Type Inst> go 3. You may find that two patches have been marked as incompatible. (The installation tools reject an installation request if an incompatibility is detected.) If this occurs, you must deselect one of the patches. Inst> keep patchSGxxxxxxx where xxxxxxx is the patch number. 4. After completing the installation process, exit the inst program by typing Inst> quit 1.8 Patch_Removal_Instructions To remove a patch, use the versions remove command as you would for any other software subsystem. The removal process reinstates the original version of software unless you have specifically removed the patch history from your system. versions remove patchSGxxxxxxx - 9 - where xxxxxxx is the patch number. To keep a patch but increase your disk space, use the versions removehist command to remove the patch history. versions removehist patchSGxxxxxxx