========================================================================== The checksum's (found through sum -r) of the files that you have received (other than this README) are as follows: 11906 23 patchSG0002185 07874 12 patchSG0002185.dev_man 27913 35 patchSG0002185.eoe1_man 44063 14750 patchSG0002185.eoe1_sw 18268 1043 patchSG0002185.eoe2_sw 44300 77 patchSG0002185.idb 40351 1 patchSG0002185.nfs_sw ========================================================================== - 1 - 1. Patch_SG0002185_Release_Note This release note describes patch SG0002185. 1.1 Supported_Hardware_Platforms This patch contains bug fixes for the following machine types. The software cannot be installed on other configurations: o Challenge and Onyx with R4400 processors o Crimson (4D/510) o PowerSeries (4D/120, 4D/2x0, 4D/3x0 and 4D/4x0) o Indy o Indigo o Indigo2 o Challenge-S o Personal IRIS (4D/2x, 4D/3x) 1.2 Supported_Software_Platforms This patch contains bug fixes for IRIX 5.3 and 5.3XFS, as well as hardware specific releases based on those releases, including IRIX 5.3 for all Indigo2 Impact, and IRIX 5.3 for Indy R5000. The software cannot be installed on other configurations. This patch is a kernel rollup. It replaces the following kernel rollup patches for IRIX 5.3 and/or IRIX 5.3XFS: SG0000158 SG0000186 SG0000244 SG0000279 SG0000280 SG0000288 SG0000339 SG0000372 SG0000393 SG0000404 SG0000425 SG0000446 SG0000448 SG0000475 SG0000487 SG0000624 SG0000676 SG0000679 SG0000766 SG0000934 SG0000990 SG0001003 SG0001004 SG0001008 SG0001034 SG0001036 SG0001116 SG0001117 SG0001123 SG0001171 SG0001255 SG0001268 SG0001541 SG0001489 SG0002068 1.2.1 Special_procedure_for_removing_this_patch Removing this patch may require reinstalling certain other patches. Reinstalling a patch is necessary whenever two unrelated patches that install the same file(s) have been installed and one of those patches is then removed. This occurs because removing one of the patches replaces the file - 2 - in common with the version of the file that was in place before either patch was installed. Reinstalling the remaining patch replaces the file with the newer version from the patch. Almost all patches are designed to avoid this situation (patches containing common files). However, in a few cases it's necessary. The files this patch has in common with other patches are xfsstubs.a and xlvstubs.a. Patches 452, 547, 920, and 1102 contain xfsstubs.a. Patches 1050, 1072, and 1120 contain xlvstubs.a. Any patch that replaces one of the listed patches will also contain the same stubs files. If you remove any one of patches that contain xfsstubs.a (xlvstubs.a) you must reinstall the others that also contain xfsstubs.a (xlvstubs.a) Note that if you have just one of the affected patches installed this procedure doesn't apply and it may be removed without difficulty. What happens when one of these overlapping patches is removed without (one of) the other(s) being reinstalled is that the kernel won't link due to undefined symbols. If the kernel links there is not a problem. Nothing in the operation of your system can be affected by using the wrong XFS or XLV stubs files. With some combinations of patches on some system types, you may see a warning during the kernel configuration, similar to: Warning: ng1.a(newport.o): _irix5_mips4: multiply defined The warning can be ignored; it is "normal". It is caused by the requirement that patches install on multiple base OS releases and hardware configurations, without requiring an otherwise unnecessary dependency between patches. 1.2.2 Warning_for_5.3_with_XFS_configurations Because of an addition to the xlvstubs.a image shipped as a part of this patch, upon relinking the kernel after installing this patch a warning may be printed out by the linker. This warning will only appear if XLV is not configured into the kernel. The text of the warning is: Warning: xlvstubs.a(xlvstubs.o): xlv_next_config_request: multiply defined previous (used) definition from 'xlvplexstubs.a'; new (ignored) definition from 'xlvstubs.a' This warning is harmless and expected. It does not affect - 3 - the correctness of the kernel output by the linker, and should be ignored. 1.3 Bugs_Fixed_by_Patch_SG0002185 Descriptions of fixes in this patch include bug numbers from the Silicon Graphics bug tracking system for reference. This patch includes support for Rev.C (and higher) DANG chips. Previously only Rev.B DANG chips were recognized, in order to protect against bugs in Rev.A chips. This patch recognizes DANG chips whose version is Rev.B or higher. It is required for support of products on Challenge and Onyx systems such as the following, which use the Rev.C chip: o HIO FDDI mezz (XPI) o HIO 8-port Ethernet (E-plex) The following bug fixes in IRIX 5.3 are included in this patch. o A deadlock could result if the system ran out of memory while processing file I/O, especially if due to references to mmap'ed pages. The deadlock would happen, for instance, if memory was filled up with dirty pages (via mmap) all belonging to a single file (bugs 170982, 500561). Bugs fixed in Patch SG0002068 o Fixes problem where a system which appears hung will not respond to an NMI request to produce a vmcore. Problem is that an NMI which occurs while the putbuflck is held will not produce a dump and no output appears to console. This problem may occur if one of the cpus has an uncorrectable cpu cache error and is more likely in large memory configurations (Bug 485624). o The pseudo-tty subsystem could drop data if more than 4096 characters were written in a single operation (Bug 334558). o Fixes problem on IP19 cpus which causes the cache error handling code to incorrectly determine if a cache error is correctable or not (Bug 494558). o Processes could hang in exit() due to a negative tty reference count. (Bug #453965) - 4 - Bugs fixed in Patch SG0001489 and ancestors o There are several race conditions in tpisocket. This can cause the kernel to panic under load (Bug #284409). Important note. The fixes for bug 284409 require that patch #1654 also be installed. patch #1654 and patch #1489 may be installed in either order. If patch #1654 is not installed, then the complete fixes for bug# 284409 will not be present and there is the possibility that the kernel may panic when svr4net is enabled (rpcbind) and used under load. o Added a workaround for a hardware problem in the Challenge/Onyx platforms with R4400 processors. This problem could cause kernel bus errors. (Bug #414116) o Fixed a potential synchronization problem between cpu and io on Challenge systems. (Bug #418568) o Fix for a bug introduced in patch 1268. Only affects systems that have detachreg_check_enable tunable parameter turned on. The symptom of this bug was that the kernel could panic with a `Read TLB Miss' kernel fault. (Bug #427113) o A problem with the cycle counter (the SGI_QUERY_CYCLECNTR syssgi() system call) on some Indigo2 250 MHz systems that was fixed in patches 1034 and 1123 was inadvertently omitted from patches 1255 and 1268. The fix has been restored in this this patch. (Bug #326421) o The same code error that caused the bug above could also cause itimers to fire at the wrong frequency, on the same system types. (Bug #426946) o Truncate system calls to files in XFS filesystems did not check for write permission correctly. A current XFS kernel patch is also required for the complete fix to this problem. (Bug #447743) o An R5000 CPU bug. Refer to the MIPS Errata list item (12). A spurious TLBMOD exception is taken under circumstances. "A load instruction is executed which puts a page entry in the micro-DTLB and a subsequent store to the same page takes a TLB Mod exception. The instruction just before the store stalls the pipeline and at the same time an instruction address page crossing results in the micro-ITLB taking a miss and accessing the JTLB. This collision of events results in - 5 - the C0_BADVADDR and C0_ENHI registers to hold corrupted addresses for the TLB Mod exception." (Bug #436779) o Fixed bug # 469770 - the description on this bug read: "IP17 won't boot after installing patch 1268." This bug turned out to be an R4000/R4400 chip bug, which was tickled by patch 1268. The chip bug went as follows: In the tlbmiss refill handler, we had the C0_WRITER opcode in the delay slot of a branch instruction. That branch/WRITER pair was near the end of the icache line. Suppose that there is a C0_READI hanging out in the icache, and that READI happens to be in the first word of the next line of the icache. The R4000/4400 starts the READI down the pipeline before it realizes that it is actually a cache miss, but apparently some processor state is not properly restored when the READI is killed. This leads to a processor hang. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bugs listed below this line were fixed in one or more earlier kernel rollup patches, from the list above. o This patch fixes a bug introduced by patch 766 that caused the very first device probe done on behalf of lboot to fail under some circumstances, even if a device was actually present. This bug affects mostly Onyx systems, although any EVEREST-based system could potentially see this problem. (Bug #349621) o Unique ID creation across multiple boots of the same system was not as unique as it should have been. This is much less likely to happen on a Challenge (IP19) than on the other platforms. This problem could affect XFS or XLV adversely, with results including XLV confusion about the identity of volume elements, and NFS refusing to export multiple XFS filesystems. (Bug #365043) o This patch fixes a problem caused by patch 1117 where the use of XLV or the REACT/Pro products could deadlock the system. (Bug #362875) o On earlier versions of IRIX 5.3, the kernel can crash if one thread of a parallel process group deletes a memory segment that is simultaneously in use by another thread in the same sproc group for an I/O operation. This is fixed by detecting munmap and shmdt calls that reference segments in use by another sproc for I/O and rejecting those calls with EBUSY. (Bug #275207) - 6 - o 133MHz R4600SC loses time at about 30 seconds/day. (Bug #253937) Fix causes hinv to report CPU speed as 132MHz. Previously hinv would report an incorrect CPU speed of 134MHz. o The 175MHz R4400SC keeps inaccurate UST. o An Indy or Challenge S would panic after a power failure warning. This was generally the result of a temporary power brown out (bug #249413) o When an Indy or Challenge S encountered a bad kernel memory reference, it would sometimes hang uninterruptibly (so that even the power switch would not work). (Bug #254936) o Parity error reporting does not report correct SIMM or physical address in some circumstances. (Bug #265516) o It is possible for the system to loop forever printing the message "CPU x WARNING:tlbmiss: invalid badvaddr XXX". This could happen if there is an invalid reference in the kernel to kernel heap space. When this situation arose the system would have to be forcibly rebooted. The kernel has now been corrected to panic whenever such a situation arises so that the errant code can be isolated. (Bug #189291 and #251742) o Lost clock interrupts on Power Series machines cause time to drift under a heavy system load. This patch provides a temporary workaround to the problem on machines equipped with an IO3 board. Machines which do not have an IO3 board installed will be unaffected by this patch. (Bug #192233) o On large memory systems, the kernel previously had no throttle mechanism on the use of kernel virtual address space. Kernel virtual address space is used to map the kernel and its control data structures. Sometimes, EFS, NFS, raw I/O and other operations could cause the O/S to consume too much kernel virtual space to map file systems buffers. A new kernel variable "bmappedpct", dynamically tuneable, has been added to limit the % of "syssegsz" kernel virtual space allowed to be used by the file system buffers. When that value is exceeded, the system actively attempts to reclaim virtual address space. As shipped, this patch sets this value at 50%. Setting this tunable variable to "100" (or 100%) effectively disables this new control. In addition, this patch increases the maximum amount of kernel virtual space a 32-bit Challenge system can allocate - 7 - from 256MB to 384MB. The default formula, which is used when the tuneable parameter "syssegsz" is 0, is still 1/2 the system's memory size. (Bug #205422) o Two optimizations were made to the cache flushing code in this patch. One change applies to all platforms and pertains to situations where user code pages are faulted in. In this scenario it is necessary to flush the code page out of all the caches in order to guarantee that stale code is not executed. This change ensures that once the code page has been flushed and then executed, it will remain in the caches if it is faulted in again. The second change applies to Challenge systems. For these systems it is necessary for all cpus to occasionally flush all of their caches in order to avoid virtual coherency exceptions on kernel stack pages. What this change does is to greatly reduce the frequency of this event by ensuring that all free pages in the system are marked as clean in the caches. (Bug #248890) o Symmon sometimes hangs or gets exceptions on Indigo2 and Indy R4000 and R4400 machines, when single stepping, continuing from a breakpoint or entering into symmon from either cntrl-a or symstop or dbgstop. (Bug #249285) o This patch fixes a problem which arose when programs were execed by pre-loading all their text. In such a situation the lack of coherency between the instruction and data caches was not accounted for and the results were not reliable. This now works correctly. (Bug #249652) o A race condition exists between a process exiting and looking at that same process's credentials using the /proc interface. The /proc interface attempts to look at process's credentials after releasing a lock on the process entry. If the process exits within a few instructions the lock being released, then the /proc support can use an invalid pointer and panic the system. The solution in this patch holds the process entry locked until all credential information is copied. (Bug #249685) o The logical volume driver has a race condition between the "open" and "ioctl" entry points. This patch includes a fix that serializes opens and ioctls on logical volumes. This fixes problems encountered by running multiple mklv commands on the same LV at the same time. (Bug #250334) - 8 - o On an MP system, a process can change the priority of another process which could be running on another cpu. This fix will allow it to do so without running into any kernel stack extension page mismatches. (Bug #252308) o Doing frequent raw I/O operations to buffers scattered throughout large data areas (regions in excess of 32 Meg) can cause large numbers of tfaults in certain circumstances. These tfaults have no effect on the correctness of the system, but can reduce overall performance if they occur too frequently. (The tfault rate can be observed with osview(1).) This fix eliminates the excessive tfaults. (Bug #253861) o Kernel multi-access, single-update locks are fixed in this patch to work properly for single-processor systems. (Bug #254554) o A bug in the getdents system call would cause a system crash if a zero-length request was passed to getdents. This case is now fixed to return EINVAL. (Bug #255067) o A related bug where the getdents system call would cause a system crash if a really huge request was passed to getdents. This case is now fixed to return lesser data. (Bug #255067) o Previously, when a region of user memory grew large enough to require a multi-level chunk tree, and when the user program did a "shrink" via sbreak, and when the shrink happened to occur on certain boundaries that are significant to the anon chunk management code, it was possible for the process to hang or for the system to crash. This now works correctly. (Bug #255268) (Bug #250249) o There is a small race condition that can cause the kernel to get a segmentation violation with a NULL pointer. This can happen in special cases that can occur when the following conditions simultaneously happen: (1) the kernel tries to page out pages from a process's data or bss, (2) this is after the data has been modified by the debugger (or in other cases that cause the data or bss to be shared between multiple processes), and (3) the process then shrinks its bss segment with either the brk or sbrk system calls while the paging I/O is in progress for the pages being affected by the brk or sbrk call. This now works correctly. (Bug #255378) - 9 - o A special case file-system buffer cache bug could produce an incorrect buffer page list. This now works correctly. (Bug #257730) o When an application sets the ioctl flag CLOCAL (man termio), hardware flow control (CTS) is disabled. This is incorrect and results in data being lost. Hardware flow control should only depend on the value of CNEW_RTSCTS. (Bug #243836) o When the posix_tcsendbreak parameter is set, this fix defers release of the controlling tty vnode in certain cases of exit by the process group/session leader, in compliance with PCTS FIPS 151-2, DC/tcsetpgrp test 10. It is not recommended that the posix_tcsendbreak parameter be set for normal operation. (Bug #228386) o When there is a previous alarm() request with less than one second remaining, a call to alarm() is fixed to return 1, in compliance with PCTS FIPS 151-2, Section PP, alarm(); Assertion 9. (Bug #229122) o Signal handling is fixed to deliver SIGSTOP before other lower numbered signals, in compliance with PCTS FIPS 151-2 sigsuspend(). (Bug #235511) o Currently, IRIX returns an error on sending a signal to a zombie process - a fix in this patch causes a return value of 0 for a kill() that delivers a signal to a zombie process (one that has terminated, but who has not been waited on by its parent process), subject to permission checking. This change is in compliance with PCTS FIPS 151-2, DEF/gen_terms test 3. (Bug #237358) o When the posix_tty_default parameter is set, this fix causes SIGHUP to be issued instead of SIGTSTP on modem disconnect, in compliance with PCTS FIPS 151-2, DC/tcsetattr test 21. (Bug #237980) o Fixes POSIX 151-2 DC/tcsendbreak 4. Prevents possible corruption of data sent immediately prior to issuing break on serial ports running at baud rates below 19.2Kbaud. (Bug #261242) o When the posix_tty_default parameter is set, this fix avoids placing a STREAMS message boundary at the location of an INTR, QUIT, SUSP special character in the input stream, in compliance with PCTS FIPS 151-2, DC/settable tests 67, 68. (Bug #238249) - 10 - o Fixes POSIX 151-2: DC/settable 33. Ensures that STOP character is always sent when input buffer approaches overflow. The systune parameter posix_tty_default must be set to 1 to activate the fix. (Bug #261561) o Certain real time applications have surfaced a performance problem. The symptoms are bursts of rfaults that last for about 3 seconds and occur once every 3-5 minutes. These bursts can cause a real time application to miss its deadlines. This patch includes a fix which eliminates these bursts by getting rid of most of the region lookups in tfault. (Bug #251286) o A fix in this patch ensures that the last process to close a terminal device file causes any data in the output queue to be sent to the device. (Bug #259751) o This patch contains support for REACT/PRO 1.1. Previous versions of REACT/PRO will not work with this patch. Customers running version 1.0 of REACT/PRO should remove it or replace it at the time this patch is installed (bugs 266215 and 266216) o In fork, the parent process calls save() and then copies the save area to the child's uarea. In between, there is a call to page_mapin() which could switch out the parent process and that ends up changing the save area. Therefore, the child ends up with a bad save area and resumes at the wrong place. This bug fix switches the order of copying save area and calling page_mapin() to close the window for the manifestation of the bug. (Bug #262839) o On EVEREST and ONYX, when a processor was isolated, timeouts running on a processor would be incorrectly migrated to another processor. Side effects of the migration is that timeouts could take effect either immediately, or be delayed 10 times as long. This could cause premature SCSI timeouts and resets, as well as other bad effects. (Bug #267583) o Symmon, the kernel debugger, would sometimes fail on certain configurations due to uncached accesses conflicting with cached accesses. This problem affects IP19 Everest processors of all speeds, but is more likely to occur on the faster CPUs. It is manifested as either an infinite loop of "SYMMON EXCEPTION" during boot, or CPUs not starting. Symmon now runs cached, and the kernel initializes the cache in such a way as to not cause any conflicting cached and uncached accesses (bug 245913). - 11 - o Production kernels would not support some of the symmon commands such as "plist" and "slpproc". This was caused by tlb misses that neither the kernel or symmon were prepared to handle. The fix is to use a more general utlbmiss handler if symmon is loaded (the same as a developers DEBUG kernel). This may cause a small decrease in performance for kernels running with symmon. (Bug #256363) o On EVEREST and ONYX it was possible that a timeout interrupt from a timeout that had previously been moved off the processor would still interrupt the processor. This would disrupt real time programs. (Bug #267112) o On a large MP system under heavy rcp network load it is possible for the kernel udp multireader/writer lock to thrash while one process attempts to release it and many are attempting to acquire it. The symptoms are that gr_osview shows several cpus pegged in the red (%sys) for several seconds at a time every few seconds, and "ping localhost" reports erratic very high (seconds!) ping times. This behavior is fixed in this patch. (Bug #266961) o Resource limits were getting reset any time a process execed a setuid/setgid program. This fix allows restriction to only those processes which exec a setuid/setgid-to-root program, and adds a configuration option, reset_limits_on_exec, to enable the restricted behavior (i.e., not reset limits even when program is setuid to root). The default setting for this variable is one, which retains the current behavior. If the new restricted behavior is needed, reset_limits_on_exec should be set to zero. Refer to the comments in mtune/kernel system file. (Bug #250430) o If a process using OpenGL created a child process which shared the address space of the parent, then attempted to use OpenGL from the child process the process or system could hang. This problem could be encountered by applications using the OpenGL version of the movie library (libmovieGL), since the movie library creates a thread which uses OpenGL to display frames from the movie. This problem has been fixed. (Bug #265136) o Changes were put into the kernel which allow the poll system call to accept file descriptors (nfds) up to the current resource limit of maximum number of open files per process. (Bug #268855) - 12 - o Challenge and Onyx systems can crash during probing at times when the combination of hardware error bits set in the IO4 error registers are not expected. Although rare, these cases are fixed in this patch. (Bug #267292) o Under rare circumstances a process on a local scheduler affinity queue could be starved of cpu time because of a bug in the clock-based affinity queue cleanup that caused the first affinity queue that should have been examined to be skipped. A simple fix in this patch ensures that all local queues are examined and that processes with expired affinity on the local queues are correctly moved to the global queue. (Bug #268443) o This patch includes kernel changes that improve the performance of the pty subsystem by reducing system overhead. A new version of the streamio(7) manual page is included with this patch, which documents two new ioctls added in support of the performance optimization See the following section, "STREAMS STRHOLD capability", for complete interface description. (Bug #243813) o Long running processes that continuously forked new children faster than the old children would exit or exec encountered a performance problem when running for long periods of time. The symptoms exhibited were a steadily increasing amount of time spent in the kernel mode, a corresponding decrease in application performance, and an increasing amount of kernel zone memory. This performance problem (including the excessive zone memory usage) has been fixed. (Bug #267904) o When isolated processors and processor affinity are in use, the kernel heap may be corrupted. This can happen if memory used by the scheduler for the process using affinity is freed (at exit) time, the process is still around (wait not yet called), the memory is reallocated, and the processor isolations are changed. The result is often that a file's extent list is trashed, this might not be noticed until the next crash and reboot, or the next access to that file. (Bug #276262) o The select system call does not recognize a MSG_BAND message received on a file descriptor as an exception condition which should be set in the exception file descriptors set. Fixed to set an exception condition on receipt of a MSG_BAND message. This fixes a MIPS - 13 - ABI test failure. (Bug #279550) o A fix in this patch enables debugging (reading/writing) of isolated processes and sprocs. Reads of isolated procs and sprocs introduce no latency to the affected isolated processors. Writes of isolated procs and sprocs do introduce latency due to the need to synchronize instruction and tlb caches. (Bug #216158) o This patch fixes a bug whereby accesses to /dev/kmem could cause EVEREST systems to crash. Addresses were not properly filtered by the /dev/kmem driver before the driver attempted to access the given address. An improper address could therefore cause a bus error, which would in turn cause the system to panic. (Bug #283505) o This patch fixes a problem whereby realtime processes being made runnable after waiting on a semaphore could preempt a lower priority process. (Bug #286083) o This patch has optimizations for faster core dumps in the event of the kernel panicing. This is particularly useful for large memory configurations. Dumping of free and user pages is now controllable thru a systune variable dump_all_pages, which, when set to 0, will ignore dumping such pages. This systune value should normally be kept at its default value of 1 and should only be set to 0 if reboot time after a panic causes major inconvenience. (Bug #285989) o This patch fixes a problem in crash dump code which causes it to dump bad information above 512M when a page is not compressible. (Bug #286718) o This patch fixes a bug which prevented the enable_sysad_parity and disable_sysad_parity kernel functions from working properly when called from a kernel driver's interrupt handler. (Bug #291175) o On Challenge S and Indy, modem connections would sometimes stay open after PPP, SLIP, cu, or other software had requested the line be dropped. This patch fixes that bug. (Bug #277949) o This patch fixes a race condition where isolating a processor could cause a kernel panic. (Bug #271295) o This patch fixes a bug whereby cause bits were not set correctly in certain cases of FP exceptions on R3000 systems. (Bug #276012) - 14 - o This patch fixes several small race conditions that could cause performance spikes in certain cases for kernel virtual memory allocation. (Bug #295101) o This patch supplies VME group interrupt support for the frame scheduler. (Bug #272870) o This patch fixes bugs in memory parity error reporting and fixing on Indigo/Indigo II/Indy machines (bugs 256521 and 270168) o This patch fixes a race condition whereby proc0 (sched) would sometimes not wake up and re-activate a process that was in the SXBRK state, even though there was plenty of free memory. (Bug #300641) This patch enables SVR4 semaphores to scale linearly as semids are added to the system. In addition (and the primary reason this is in a patch and not just in the next release of Irix) a thundering heard problem was observed by a customer when more than one process was sleeping on a semaphore and waiting for its value to be incremented. On a customer's IP19 machine this caused tremendous degradation in performance as CPUs were added. This patch also fixes this problem. (Bug #315833). o Fix zduart driver (CONSOLE_D2 code), to only check for a on the port that is set to the console not both. o Added two routines need for the dmedia video driver (__ll_bit_extract & __ll_bit_insert). o Added "impactgm" variable that can be set in the PROM before booting the kernel. This will enable global texture manager. o There was a small race in the IRIX kernel between the paging daemon and a process which had breakpoints set and was in the midst of a fork system call, which could cause a system crash. The race is now avoided with a kernel mutual exclusion lock. (Bug #274621) o This patch fixes a race between an exiting sproc process which is getting rid of its prda, then goes to sleep, and another process tries to schedule it and tries to access its prda. (Bug #324871) o Added workaround for a hardware bug present in R4600 (all revs) and R4700 rev1.0: The following instruction sequence causes a bogus SEGV to be delivered to user - 15 - programs: PC: Instruction Where -------- ----------- -------- 0x...ff4 lw causes a dcache miss. 0x...ff8 sw causes a TLB mod exception. 0x...ffc is the last instruction on the page and doesn't cause slips or stalls. (Bug #316772) o Challenge and Onyx systems currently will not allow more than 64MB of address space to be mapped for DMA by A32 VME devices using the dma_mapalloc call. This patch allows this limit to be adjusted using systune(1m) by modifying the value of the variable "nvme32_dma". The value of nvme32_dma is the maximum amount of address space (in megabytes) that may be allocated for A32 VME devices. The default value for nvme32_dma is 64 (corresponding to the previous limit of 64MB of address space). nvme32_dma must be a power of 2 and may not exceed 512 (i.e. 512MB). If a value larger than 512 is specified, it will be forced back down to 512. If the value is not a power of 2, it will be rounded up to the next higher power of 2 (but not to exceed 512) o When a profiled process uses sprocs or sprocsp, the amount of time for the sproc or sprocsp reported to prof is wrong, often times negative. This is now fixed. (Bug #258217) o Use of the 'mknod name s' command will crash or hang the system. This can be done by any user on the system. This fix makes such operations invalid rather than allowing them to crash or hang the system. (Bug #318531) o A IRIX4 binary that uses libc function getcwd() fails on a file system mounted on a XLV volume. The problem is that the IRIX4 dev_t is only 16 bits and XLV has a major number greater than 127. This fix adds support for compressing XLV into a 16 bits dev_t. (Bug #326869) o Added code for multiple IO4 support to workaround bug 323277. o Fixed a problem in the multiple IO4 support added to the lv driver in patch1034. It was possible for the lv driver to crash the system with a SEGV under heavy use - 16 - of logical volumes on machines with multiple IO4s. o By adding the prototype for the setsr routine, this fixes a bug in the recovery mechanism for parity errors detected in memory by the floating point unit. o Applications using large Shared Memory segments (greater than 500 MBytes) can cause kernel virtual memory to be exhausted. This happens when a lot of independent processes (hundreds) are attaching to the same SHM segment. On large configurations, several Relational Databases may exhibit this behavior. If the kernel virtual memory becomes exhausted the system appears unable to perform any work and a reboot is necessary. This patch fixes this problem, by allowing independent processes to share the kernel data structures that describe their address space. These data structures are called Page Tables and contain information about the virtual to physical address translation. For instance let's assume that a SHM segment has size 750 Megabytes and 500 processes are attached to it. With private Page Tables IRIX uses 375 Megabytes of Kernel Memory. With shared Page Table IRIX uses 750 Kilobytes. Another big benefit of sharing Page Table is speed. In fact any new process attaching to the SHM segment benefits from the page faulting activity performed by other attached processes. This dramatically reduces the number of page faults and makes a great difference in the overall performance. This patch is highly recommended for installation running large Oracle Data Bases. Processes that want to make use of this feature should specify a special flags when calling shmat. This option is only available if both the attaching address and the size of the SHM segment satisfy appropriate restrictions. See shmat(2) for detailed information. (Bug #350853) o Some 250MHz processors modules can sometimes return an incorrect value under special conditions. This a problem in the 250MHz processor's TLB. (Bug #320415) o Xsgi using large amounts of virtual memory (reserved swap). This requires Patch 1098 or it's successors (currently patch 1441), which contain the corresponding X server fixes, for systems other than Indigo2 Impact (Impact X servers already had that fix). (Bug #254412) o Some Indigo2 configurations with FDDI would not cleanly shutdown or reboot. This has been fixed by resetting cards on the IO bus before shutting down the system. - 17 - o A process using the guaranteed rate I/O mechanism to read or write data from an XFS realtime file system partition could hang indefinitely. (Bug #350423) o Fixed a bug that caused pixel dma errors on IP22 systems with more than 256 MB of memory (bugs #334324, #328843) o Fixed a bug that leaves bogus pregions on a vnode's m_vreg list because in fs_map_subr(),in case reattachpreg() fails, then that pregion doesn't get cleaned up. (Bug #353433) o This patch fixes a bug in real-time operation whereby a non-degrading process becomes ready to run on an isolated, non-preemptive idle processor but does not run for up to 14 milliseconds, while the cpu remains idle. (Bug #346059) o This fix is only for "Challenge and Onyx with R4400 processors" systems. This patch fixes a bug where the settimeofday puts the time one day ahead if the date is after 28th Feb in a LEAP Year. (Bug #354103) o Some kernel variables that can be adjusted with systune(1m) would not take effect, due to a bug when both static and run classes of the same tag were present. This was fixed by making the static class always occur first in the configuration file. (Bug #346319) o A security bug which permitted par(1M) to trace setuid programs has been fixed. Now setuid programs are only traceable by super-user. (Bug #250103) o A newly forked process could incur VCEs on its kernel stack due to races in cache flushing in the page allocation routines and cpus turning non-isolated. This bug has been fixed. (Bug #433967) o If the clock crystal is off a little bit (either inherently slightly off speed or due to temperature), an Indy may be confused about whether it has a 175Mhz (R4400) or 180Mhz (R5000) processor. This could lead to incorrect output from hinv, the system clock may run inaccurately, etc. (Bug #433639) o This fixes a potential EBUS deadlock on MP systems (Challenge). (Bug #451134) - 18 - o For EVEREST systems, stop all cpus before reading MC3 Config Registers to avoid a potential hang. (Bug #469254) o For Challenge (EVEREST) systems, increased the dang chip timeout since it was too small. (Bug #455481) o This is a bug fix in swmgr. (Bug #235551) o This fixes all kernel stack overflow problems. (Bug #240710) o This fixes all kernel stack overflow problems. (Bug #240710) o FIxed a bug where nfs2 mounts can produce incorrect access to files. (Bug #255462) o "pc-sampling sproc'd app appears busted in 5.3" is expected behavior. (Bug #260287) o This fixes dthe bug where evice ddriver using physiock() hangs waiting for sptbitmap. (Bug #270754) o This adds single bit error srubbing functionality. (Bug #272877) o This fixes IP22 related bus-error handling etc. (Bug #285925) o This changed the number of dang adapters from 8 to 12. (Bug #289976) o This fixes kernel stack underflow/overflow problem related to EOP WAR. (Bug #290185) o This adds triton support to the kernel.o rollup patch. (Bug #322905) o This fixes a bug where blockproc was returning without being unblocked. (Bug #324044) o This makes the maximum amount of DMA mappings tuneable with systune via the "nvme32_dma" variable. (Bug #325466) o This fixes a panic in unuseracc. (Bug #326899) o This is an EVEREST only bug which was in lv (logical volume) code. (Bug #338236) - 19 - o This fixes the bug where in /var/sysgen/system/irix.sm: DUMPDEV & SWAPDEV were ignored. (Bug #348498) o This fixes a bug in Specialix serial ports. were ignored. (Bug #411429) o Partial fix for a bug where too much memory would be dedicated to user file data on a small memory system, for XFS filesystems. The remainder of this bug is fixed in the XFS rollup patch. (Bug #261228) 1.4 XFS_conversion_instructions_for_Indigo2 These instructions apply only to Indigo2 Impact systems, and Indigo2 175MHz, 200MHz (if they have 2MB secondary cache) and 250MHz systems. Warning: After following this procedure, do not convert the / (root) filesystem (and /usr, if it is a separate filesystem) to use XFS filesystems, because there is no IRIX 5.3 miniroot available that will worth with both XFS and these hardware combinations. By using patch 1117 or it successor, and the 5.3 XFS images. An Indigo2 system can be converted to an Indigo2+XFS machine. An XFS filesystem can NOT be installed on the /root file system, using this patch. Thus this patch will allow user(s) to configure NON-ROOT DISKS ONLY as XFS filesystems. The /root filesystem must be a EFS filesystem. Will need the following : System running IRIX 5.3 Indigo2 175MHz and 2MB cache software, patch 1117 or is successor, and IRIX 5.3 XFS images (also any additional patches). The assumption is that IRIX 5.3 Indigo2 175MHz and 2MB cache images are already installed, or if somebody is starting from a clean disk, that they have the Indigo2 175MHz and 2MB cache CD's. NOTE : If you have previously installed any patches, they maybe automatically removed when doing this process. You will have to re-install your patches (see "Step 10" below). Write down the patch numbers which are currently installed on the system BEFORE doing this process. Step 1: Start an Indigo2 installed with IRIX 5.3 175MHz and 2MB cache, or any Indigo2 Impact release (or install it first, if necessary). Step 2: With the system booted normally, login as the super user - 20 - Step 3: Start up inst ... Choose the appropriate distribution source (/CDROM, network directory) for IRIX 5.3 XFS images. YOU HAVE TO DO THE FOLLOWING : Start "inst" with following "-X" options turned on. It will look like this (it is easier to create a shell script (see sh(1)) to start inst since this line might be too long for command line): "inst -Xsbin/hinv -Xusr/sbin/inst -Xusr/sbin/swmgr -Xusr/lib/libinst.so -Xvar/inst/machfile -Xvar/sysgen/system/gfx.sm -Xstand -Xusr/cpu/sysgen/IP22boot/tport.a -Xusr/cpu/sysgen/IP22boot/gfx.o -Xusr/cpu/sysgen/IP22boot/gfxs.a -Xusr/cpu/sysgen/IP22boot/rrm.o" Make sure that the inst command is one continues line (no line feed, or ) and check to see that the shell script has execution permission (see chmod(1)). Choose the appropriate distribution source (/CDROM, or directory) for 5.3 XFS images. Step 4: Type "install eoe1.sw.unix eoe1.sw.irix_lib eoe2.sw.xfs eoe2.sw.efs" Step 5: Type "keep eoe1.sw.gfx_lib" Step 6: Choose any new subsystems you want (or accept only images in Step 4) Step 7: Type "set neweroverride on" Step 8: Type "go" Step 9: When all new s/w is installed, use the "from" command to select Patch 1255 or its successor. DO NOT EXIT from inst yet ... just issue the "from" command from the inst prompt (If using the CDROM you will have to switch CD's from the XFS CD to the distribution with Patch 1255). Step 10: Type "list", and then select all subsystems from patch 1255 that are not marked "X" for "uninstallable". Then type "go". Step 10: Install any additional patches Step 11: "quit" from inst. Step 12: Reboot the system (using /etc/reboot). You may get "warnings" about some symbols being taken from xfs.a, and being ignored from xfsstubs.a The XFS kernel is now installed and usable. - 21 - To setup XFS filesystem(s) please refer to the XFS filesystem User's Guide. 1.5 STREAMS_STRHOLD_capability This patch implements the STREAMS STRHOLD feature in the stream head. This feature allows the stream head to coalesce several small fast writes into a single streams message before sending the data downstream, thus reducing STREAMS overhead. The STRHOLD feature can be activated on a stream by stream basis by setting the STRHOLD flag in the stream head. From within a driver or module, the STRHOLD flag can be set by setting the new SO_STRHOLD flag in the so_flags field of an M_SETOPS message and sending it upstream towards the stream head. Likewise, the STRHOLD flag can be cleared by setting the new SO_NOSTRHOLD flag in the so_flags field. Example: int set_strhold(queue_t *rq, int set) { mblk_t *bp; struct stroptions *sop; if ((bp = allocb(sizeof(struct stroptions), BPRI_HI)) == NULL) return -1; bp->b_datap->db_type = M_SETOPTS; sop = (struct stroptions*)bp->b_rptr; if (set) sop->so_flags |= SO_STRHOLD; else /* clear */ sop->so_flags |= SO_NOSTRHOLD; putnext(rq, bp); } To view and manipulate the STRHOLD flag in the stream head from a user application, it is necessary to use the new, expanded I_GWROPT and I_SWROPT ioctls. Refer to the following in the updated version of streamio(7) with this patch: I_SWROPT Sets write mode using the value of the argument "arg". Legal bit settings for "arg" are: SNDZERO Send a zero-length message downstream when a write of 0 bytes occurs. SNDPIPE Send SIGPIPE to process if sd_werror is set and the process is doing a write or putmsg. SNDHOLD Activate the STRHOLD feature. - 22 - I_GWROPT Returns current write mode setting, as described above, in the int that is pointed to by argument "arg". Example: int set_strhold(int fd, int set) { int flags; if (ioctl(fd, I_GWROPT, &flags) < 0) return -1; if (set) flags |= SNDHOLD; else flags &= ~SNDHOLD; return (ioctl(fd, I_SWROPT, flags)); } At a system level, the STRHOLD feature is controlled by two new tunable parameters, strholdtime and tty_auto_strhold: strholdtime this is the maximum time (in milliseconds) that a stream on which the STRHOLD feature is active will hold written data at the stream head in the hope of being able to coalesce it with data from a following write. Note that the STRHOLD feature trades overhead for latency. The default value is 50ms. If this parameter is 0, the STRHOLD feature is effectively turned off on the system. tty_auto_strhold if set, the line discipline module stty_ld will automatically set STRHOLD in the stream head whenever the line discipline is doing both echo and line canonicalization (ICANON|ECHO) and will automatically clear STRHOLD in the stream head otherwise (regardless of any I_SWROPT value requested by the user). This allows existing pty-based applications to take advantage of the STRHOLD feature without modification. The default value is 0. 1.6 Subsystems_Included_in_Patch_SG0002185 This patch release includes these subsystems: o patchSG0002185.eoe1_man.unix o patchSG0002185.eoe1_sw.unix - 23 - o patchSG0002185.eoe2_sw.kdebug o patchSG0002185.eoe2_sw.perf o patchSG0002185.dev_man.irix_lib o patchSG0002185.eoe2_sw.perf 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. 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. 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. Select the desired patches for installation. 3. Initiate the installation sequence. Type Inst> go 4. You may find that two patches have been marked as incompatible. If this occurs, you must deselect one of the patches. Inst> keep patchSGxxxxxxx where xxxxxxx is the patch number. 5. After completing the installation process, exit the inst program by typing - 24 - Inst> quit 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 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 where xxxxxxx is the patch number.