Patch Name: PHKL_10821 Patch Description: s700 10.20 LVM kernel and pstat cumulative patch Creation Date: 97/04/23 Post Date: 97/04/29 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: LVM.LVM-KRN OS-Core.CORE-KRN OS-Core.KERN-RUN Automatic Reboot?: Yes Status: General Superseded Critical: No (superseded patches were critical) PHKL_10675: PANIC CORRUPTION PHKL_10643: PANIC PHKL_10452: PANIC PHKL_10257: PANIC PHKL_10234: PANIC PHKL_9075: PANIC PHKL_8532: CORRUPTION PHKL_8084: ABORT PHKL_7870: PANIC Path Name: /hp-ux_patches/s700/10.X/PHKL_10821 Symptoms: PHKL_10821: Although users can now exec() programs with up to 2048000 bytes of argument and env strings, sysconfig() _SC_ARG_MAX continues to return 20480 bytes as the maximum length of all arguments and env strings. PHKL_10689: HP-UX didn't log any error when a user process: 1. encounters a swap space shortage 2. exceeds a system resource limitation Processes were terminated but the errors were not recorded on any of the system log files. PHKL_10675: (1) System may panic with "panic: sync not stale" while running lvmerge (merging LVM mirrors). For the panic to occur, an i/o timeout must occur during the lvmerge operation which results in a resync getting scheduled. (2) Potential data corruption if user i/o's encounter errors to the same extents which are being reimaged by lvmerge. (3) Various panics during vg activation(vgchange -a). A bit is cleared in a kernel structure which LVM has already freed. If another kernel subsystem has been allocated the freed memory before the bit is cleared, panics or other strange behaviors may occur. This particular defect was introduced by PHKL_9000. PHKL_10643: System panic with Memory Mapped Files on UFS filesystem. A typical kernel stack trace would show a data page fault panic in hdl_unsetbits() called from async_pagein_comp(). PHKL_10452: Panic: kernel stack overflow; trace includes lv_end(). PHKL_10316: When ptrace is called from the DDE debugger while the DDE debugger has watchpoints set, the ptrace system call is called to single step the user process. If the ptrace call is handling a user signal and another signal event is pro- cessed before returning to the user process from ptrace, ptrace may incorretly sent the user's save_state program counter to an incorrect value and return EIO to the parent debugger. PHKL_10257: Panic with "vn_rele" with EXEC_MAGIC executable run over NFS PHKL_10234: panic: kernel scheduler interrupt PHKL_10176: The total length (including terminators) of all argv and env strings passed to a newly-EXECed process was 20480 bytes. If a greater length was detected, the exec() failed with E2BIG. PHKL_9919: Timing differences between CPU to large, causes MI Daemon to die frequently (often in less than 15 minutes). PHKL_9529: vgdisplay(1M)/vgextend(1M) show incorrect value for max number of PE per PV. PHKL_9075: Applications using Memory Mapped Files were performing poorly when mapping thousands of pregions to the same file. The problem would mainly be noticed with shared (MAP_SHARED) and exclusive (MAP_FIXED with address in the process private data space) mappings. This patch is required when using the Object Store database product from ODI. Additionally, this patch provides an enhancement to the mprotect(2) system call: mprotect(2) used to fail protecting non mmap(2)'ed addresses. This patch enables to mprotect(2) data, stack and shared memory segment addresses. Finally, this patch fixes a kernel panic with large buffer cache: kernel panic with a data page fault when attempting to copy data from the last page of the third quadrant. This will only occur on systems with a buffer cache of one gigabyte or larger. The panic message will display the following: isr.ior = 0.bffffffc _____9022: running strings on a raw sar(1) output file can show some printable strings (sar ignores these). (This was not shipped as a separate patch.) PHKL_8999: Without this patch customers are limited to supporting 2 nodes in a shared environment With this patch customers can now use SLVM in a 4 node cluster Alternate links for devices such as the Nike disk array are now supported in a shared environment This change supports a new -t switch for lvchange allowing the administrator the option to limit the time lvm holds i/os to be retried on logical volumes when disks are powerfailed. Without using this option, LVM will hold the i/os as long as there is is one disk where the data resides which may eventually return. Using this option would cause LVM to give up on the powerfailed disk and return i/o errors to the user application using the logical volume. This feature is obviously not to be used indiscriminately. For many High Availability applications, having i/os held in kernel indefinitely is not acceptable. Most customers should not need to use the new switch. PHKL_8716: After call to pstat_getmsg(), all accesses to the message queue pstat_getmsg() was called hang. PHKL_8532: System crash dumps are corrupt and unusable. PHKL_8346: Executables cannot access more than 1.75 GB shared memory PHKL_8084: LVM may return I/O's with errors instead of sending them to an alternate link. This patch also facilitates using "vgreduce -f" for physical volumes which have alternate links; without this patch "vgreduce -f" is not allowed on LVM disks with alternate links. PHKL_7870: lvreduce(1M) may cause a system panic, if it is used to reduce an lvol which was left inconsistent by a prior LVM operation. lvreduce(1M) could not be used to remove lvols that were somehow corrupted, if it was, the command would cause a system panic. Defect Description: PHKL_10821: An earlier patch, (10177, shown without prefix so as not to confuse search engines) expanded the actual space available to execve(), but failed to modify sysconfig() to report the new maximum. This patch corrects that. There is no change to module kern_exec.c (home of execve()) other than a revision roll to ensure its inclusion in this patch. PHKL_10689: This patch provide support for logging of errors in memory management related system calls such as brk/sbrk as well as handling error cases during stack growth. Errors are logged on the system console (dmesg) and also in syslog. The variable mman_elog, which defaults to OFF, is used to control the logging. This variable can be set through adb at a customer site to enable error logging. PHKL_10675: LVM resyncs are not held off long enough during lvmerge. If an i/o timeout occurs during reimaging, then a resync is scheduled. Towards the end of lvmerge, there is a window in which the resync is allowed to run for a little bit. If the resync gets started on resyncing a stale extent during that interval, and the lvmerge is reimaging the same extent, the panic can occur. User i/o's can encounter errors during lvmerge, but lvmerge wasn't taking these errors into account. There is the potential that extents can be falsely marked fresh during lvmerge if user i/o's occur, resulting in data corruption if those extents are read. During activation (vgchange -a), LVM allocates various pvol structures. A bit is cleared after a structure has been freed. 32 bit systems expect this low-order bit to be zero anyway (aligned addrs), so there is no impact if the freed memory has not yet been allocated to another subsystem before the bit is cleared. However, if the memory has been reallocated during this interval (i.e. on MP systems), various panics and strange behaviors could occur. PHKL_10643: There were two defects in the UFS read-ahead pagein code causing the system to request more read-ahead pages than the system maximum limit. Since the number of requested pages exceeded the allowed maximum, this resulted in overflowing internal arrays, and the system could then panic while using garbled data. First, the book-keeping of the variables tracking the "last read-ahead" and the "expected next fault" was not always done properly. There was a situation where the "expected next fault" could end up exceeding the "last read-ahead", and this resulted in a read-ahead count greater than the system maximum limit. Second, there was a corner case code path using the "last read-ahead" variable before it had been initialized. PHKL_10452: Defect is quite rare. Kernel stack overflow may result from other causes. This fix reduces frame size of lv_end() from over 600 bytes to under 200 bytes. PHKL_10316: If ptrace() is single stepping an user signal handler and handling a sigcleanup call, and another signal is handled during the return of this system call, the user's PC is overwritten by the single step breakpoint address before returning to the user. One way to reproduce the problem is to use DDE on a program that generates a lot of signals. Signal stepping through the program will eventually cause an internal I/O error. PHKL_10257: The problem fixed was a wrong assumption in add_text which expects the fstore to be the same as the bstore. Because of this assumption the original (and correct) bstore gets trashed when it is overwritten with the fstore after a call to duplicate a region. For an NFS executale with the sticky bit set, the fstore will NOT be the same as the bstore. We know have removed this assumption. PHKL_10234: Running an EXEC_MAGIC program using a stack pointer in the first quadrant could result in a panic: kernel scheduler interrupt. This problem would only be seen on UP systems. PHKL_10176: The internal buffer within the kernel was created with a length of 20480 bytes, with no provision for increasing its size. This patch provides for up to 100 such buffers, with all but the first allocated only if required (that is, if more than 20480 bytes of argv/env information is found). Thus, exec() now supports up to 2048000 bytes of argv/env information. PHKL_9919: Upon synchronization, non-monarch's expect the monarch to be waiting for them to synchronize. If the monarch is not waiting, the synchronization fails, and the offset_correction is set to 0. This happens only on bootup and may not happen every time. This causes times in the KI buffers to vary greatly, and that causes the MI Daemon to crash frequently. The problem is only at boot time, and will not occur later. This means a succesful boot will keep stay good, and a bad boot will stay bad. PHKL_9529: The lv_queryvg() function in ioctl(2) failed to copy the maxpxs field to the returning data structure. This problem was introduced in PHKL_8999. PHKL_9075: This patch provides two enhancements to Memory Mapped Files: increased performance when using thousands of mappings, and mprotect(2) opened to non-mmap(2) addresses. It also provides a fix for a defect with large buffer cache. The pregions list associated to a shared region was designed as a doubly-linked list thus providing a linear access to pregions in the list. This design was not suited to deal with thousands of pregions and the doubly-linked list was replaced by a skip-list for faster access. Two other changes were required to deliver better performance: the algorithm to check the total virtual address space and the routine to locate the stack pregion were enhanced. Only those addresses returned from a call to mmap(2) could be used for mprotect(2). However there were applications who needed to protect addresses in data, stack or shared memory segments; objects not created via call to mmap(2). So mprotect(2) was opened to allow mprotect'ing on data, stack and shared memory objects. Text is not allowed unless the executable is EXEC_MAGIC. A compiler feature with C language structure copies results in a reference to an untranslated address when copying the last 4 bytes in quadrant 3. This only shows up when the data in the buffer that is being copied includes address 0xbffffffc that is, it is the last full word in quadrant 3. The problem appears as a trap type 15: "data page fault". _____9022: pstat_dynamic() allocates a buffer but fails to initialize it before using it. Buffer ends up containing some garbage. This is a cosmetic defect only; sar ignores the uninitialized spaces. (not shipped as a separate patch). PHKL_8999: Support for SLVM is currently limited to 2 nodes. This patch will allow SLVM to work in a 4 node cluster. Alternate link support has also been added for SLVM so that devices such as the Nike disk array can now be used in a high availability cluster. LVM makes every effort to avoid returning an error to user applications. LVM will hold onto an I/O to retry it later if there is even the smallest hope that the device will return. If a disk simply does not respond and no bad writes made it to the media, LVM will hang onto the i/o as long as the disk does not respond with an indication that there was actually a bad write or read. The patch provides a new feature that allows administrators the option of limiting the time lvm will wait for disks in an logical volume to return, and cause lvm to return i/os with EIO instead of hanging onto them indefinitely. PHKL_8716: pstat_msginfo() calls msgconv() to convert the offset into a message queue pointer. msgconv() was changed to not only do the conversion, but to lock the queue and return a pointer to the queue's lock. pstat_msginfo() had not been changed to take into account msgconv()'s new behavior. PHKL_8532: Intermittent corrupted dumps on PA-RISC2.0 (PA8000) machines on HP-UX 10.20. PHKL_8346: Current executable types cannot access more than 1.75 GB of shared memory. A new executable type is defined which uses the second quadrant of the address space for shared memory rather than process private data thus resulting in 2.75 GB of shared memory. With short pointer addressing on 32-bit PA architecture, each pointer addresses one of four quadrants each of which is 1 GB in size. Current executable types use quadrant 3 and quadrant 4 for shared memory. In user mode, quadrant 1 and quadrant 2 are used for user text and data, respectively. This results in a system wide maximum of 1.75 GB of shared memory (.25 GB in quadrant 4 is set aside for IO). In the new executable type, user data and stack are pushed into quadrant 1 and quad 2 is also used for shared memory. An existing application has to be relinked as the new executable type to avail of this feature. Alternately the application can be linked as an EXEC_MAGIC and the n the executable can be chatr'd to be the new executable type (SHMEM_MAGIC). The related patch for chatr is PHSS_8358. Only the chatr method is currently supported. Please note that this is an interim solution for increased shared memory addressing till 64-bit hp-ux becomes available. There are several limitations: - Only executables that are linked to be the new SHMEM_MAGIC executable type(or chatrd to be so) can avail of this feature. Other executables will continue to see a system wide maximum of 1.75 GB of shared memory. Processes that execute other types of executables will not be able to share the memory in quadrant 2 with a process that is executing the new executable type. - In the new SHMEM_MAGIC type, quadrant 2 is only used for system V shared memory (unlike quadrants 3 and 4 which are also used for shared memory mapped files). - In the new executable type text is mapped at different virtual addresses and so process intensive applications may not benefit. Any increase in performance due to the larger shared memory may be offset by decreases due to TLB inefficiency. Applications that use one process per processor may however benefit. - This will not be supported on future HP implementations of 64-bit architectures (beyond PA 2.0), nor will it need to be as with a 64-bit kernel the size of shared memory supported will be much larger than 2.75 GB. Programs that need more than 1.75 GB of shared memory on these architectures will have to be recompiled for these architectures. - Programs that are compiled as 64-bit executables on any 64-bit HP implementation (including PA 2.0) cannot be marked as SHMEM_MAGIC nor do they need to be as they will already have access to more than 1.75 GB of shared memory. PHKL_8084: Without this patch LVM will not retry failed i/os on alternate links unless the error is one that denotes that the device is offline or powerfailed. Other errors, are not retried on an alternate link and may cause LVM to report the error to users applications. Typically, customers with unmirrored lvols using multiported devices like the HP3232 (Nike) disk array would see the problem when an EIO error is reported to LVM from the underlying device driver due to a device or driver problem. In this situation LVM would report the EIO to user applications without trying any available alternate link. Another problem this patch fixes allows reducing out physical volumes from a volume group when the device is not available and the device has links, formerly devices with links could not be removed if they were not available. PHKL_7870: The problem was that the kernel forced a panic whenever any inconsistency was found during an lvreduce. For example, if a logical extent in an lvol referred to a physical extent that was not allocated, it would cause lvreduce(1M) to panic the system. This occured even when the objective was to remove the offending lvol. This is a very rare occurance. SR: 1653096131 1653194977 4701330647 4701334367 4701334698 4701334847 4701335497 4701335935 4701336412 4701341362 4701345843 4701347922 4701349431 4701350975 5003314633 5003318667 5003323493 5003325506 5003334961 5003341925 5003344630 5003357616 5003359414 5003363820 Patch Files: /usr/conf/lib/libhp-ux.a(asm_rv.o) /usr/conf/lib/libhp-ux.a(clock.o) /usr/conf/lib/libhp-ux.a(cpd.o) /usr/conf/lib/libhp-ux.a(dump.o) /usr/conf/lib/libhp-ux.a(hdl_fault.o) /usr/conf/lib/libhp-ux.a(hdl_init.o) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) /usr/conf/lib/libhp-ux.a(hdl_policy.o) /usr/conf/lib/libhp-ux.a(hdl_trans.o) /usr/conf/lib/libhp-ux.a(kern_exec.o) /usr/conf/lib/libhp-ux.a(kern_mman.o) /usr/conf/lib/libhp-ux.a(lv_config.o) /usr/conf/lib/libhp-ux.a(lv_lvm.o) /usr/conf/lib/libhp-ux.a(pm_config.o) /usr/conf/lib/libhp-ux.a(pm_context.o) /usr/conf/lib/libhp-ux.a(pm_procdup.o) /usr/conf/lib/libhp-ux.a(pm_resource.o) /usr/conf/lib/libhp-ux.a(pm_sendsig.o) /usr/conf/lib/libhp-ux.a(pstat.o) /usr/conf/lib/libhp-ux.a(sysV_shm.o) /usr/conf/lib/libhp-ux.a(vfs_vm.o) /usr/conf/lib/libhp-ux.a(vm_machdep.o) /usr/conf/lib/libhp-ux.a(vm_mmap.o) /usr/conf/lib/libhp-ux.a(vm_pregion.o) /usr/conf/lib/libhp-ux.a(vm_region.o) /usr/conf/lib/libhp-ux.a(vm_sched.o) /usr/conf/lib/libhp-ux.a(vm_superpage.o) /usr/conf/lib/libhp-ux.a(vm_text.o) /usr/conf/lib/libhp-ux.a(vm_vas.o) /usr/conf/lib/libhp-ux.a(vm_vhand.o) /usr/conf/lib/liblvm.a(lv_block.o) /usr/conf/lib/liblvm.a(lv_cluster_lock.o) /usr/conf/lib/liblvm.a(lv_defect.o) /usr/conf/lib/liblvm.a(lv_hp.o) /usr/conf/lib/liblvm.a(lv_ioctls.o) /usr/conf/lib/liblvm.a(lv_kdb.o) /usr/conf/lib/liblvm.a(lv_lvsubr.o) /usr/conf/lib/liblvm.a(lv_malloc.o) /usr/conf/lib/liblvm.a(lv_mircons.o) /usr/conf/lib/liblvm.a(lv_pbuf.o) /usr/conf/lib/liblvm.a(lv_phys.o) /usr/conf/lib/liblvm.a(lv_schedule.o) /usr/conf/lib/liblvm.a(lv_spare.o) /usr/conf/lib/liblvm.a(lv_strategy.o) /usr/conf/lib/liblvm.a(lv_stub.o) /usr/conf/lib/liblvm.a(lv_subr.o) /usr/conf/lib/liblvm.a(lv_syscalls.o) /usr/conf/lib/liblvm.a(lv_vgda.o) /usr/conf/lib/liblvm.a(lv_vgsa.o) /usr/conf/lib/liblvm.a(sh_vgsa.o) /usr/conf/lib/liblvm.a(slvm_comm.o) /usr/conf/lib/liblvm.a(slvm_schedule.o) /usr/conf/master.d/core-hpux /usr/conf/space.h.d/core-hpux.h what(1) Output: /usr/conf/lib/libhp-ux.a(asm_rv.o): asm_rv.s $Date: 97/02/28 14:51:08 $ $Revision: 1.57 .98.11 $ PATCH_10.20 (PHKL_10234) /usr/conf/lib/libhp-ux.a(clock.o): clock.c $Date: 97/01/23 16:09:43 $ $Revision: 1.39. 98.4 $ PATCH_10.20 (PHKL_9919) /usr/conf/lib/libhp-ux.a(cpd.o): cpd.c $Date: 96/10/26 09:39:05 $ $Revision: 1.9.98.8 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(dump.o): dump.c $Date: 96/10/26 09:49:44 $ $Revision: 1.11.98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(hdl_fault.o): hdl_fault.c $Date: 97/04/09 11:42:59 $ $Revision: 1.13.98.10 $ PATCH_10.20 (PHKL_10689) /usr/conf/lib/libhp-ux.a(hdl_init.o): hdl_init.c $Date: 96/08/26 22:38:17 $ $Revision: 1.9.98.5 $ PATCH_10.20 (PHKL_8346) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o): hdl_mprotect.c $Date: 96/11/20 10:52:46 $ $Revision : 1.4.98.3 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(hdl_policy.o): hdl_policy.c $Date: 96/11/20 10:58:41 $ $Revision: 1.15.98.10 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(hdl_trans.o): hdl_trans.c $Date: 96/11/21 16:23:49 $ $Revision: 1.12.98.11 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(kern_exec.o): kern_exec.c $Date: 97/04/21 18:01:01 $ $Revision: 1.93.98.18 $ PATCH_10.20 (PHKL_10821) /usr/conf/lib/libhp-ux.a(kern_mman.o): kern_mman.c $Date: 97/04/09 11:33:14 $ $Revision: 1.35.98.5 $ PATCH_10.20 (PHKL_10689) /usr/conf/lib/libhp-ux.a(lv_config.o): lv_config.c $Date: 96/10/25 20:52:33 $ $Revision: 1. 13.98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(lv_lvm.o): lv_lvm.c $Date: 96/10/25 21:03:34 $ $Revision: 1.3.9 8.2 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(pm_config.o): pm_config.c $Date: 97/04/21 18:10:36 $ $Revision: 1. 6.98.5 $ PATCH_10.20 (PHKL_10821) /usr/conf/lib/libhp-ux.a(pm_context.o): pm_context.c $Date: 96/08/26 22:35:25 $ $Revision : 1.3.98.6 $ PATCH_10.20 (PHKL_8346) /usr/conf/lib/libhp-ux.a(pm_procdup.o): pm_procdup.c $Date: 96/08/26 22:42:06 $ $Revision : 1.11.98.12 $ PATCH_10.20 (PHKL_8346) /usr/conf/lib/libhp-ux.a(pm_resource.o): pm_resource.c $Date: 96/08/26 22:36:15 $ $Revisio n: 1.7.98.13 $ PATCH_10.20 (PHKL_8346) /usr/conf/lib/libhp-ux.a(pm_sendsig.o): pm_sendsig.c $Date: 97/03/05 13:52:09 $ $Revision : 1.4.98.11 $ PATCH_10.20 (PHKL_10316) /usr/conf/lib/libhp-ux.a(pstat.o): pstat.c $Date: 96/10/28 11:20:16 $ $Revision: 1.18.9 8.20 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(sysV_shm.o): sysV_shm.c $Date: 96/11/20 11:01:21 $ $Revision: 1.54.98.5 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vfs_vm.o): vfs_vm.c $Date: 97/04/07 13:35:26 $ $Revision: 1.1 7.98.16 $ PATCH_10.20 (PHKL_10643) /usr/conf/lib/libhp-ux.a(vm_machdep.o): vm_machdep.c $Date: 97/01/23 16:10:42 $ $Revision: 1.157.98.31 $ PATCH_10.20 (PHKL_9919) /usr/conf/lib/libhp-ux.a(vm_mmap.o): vm_mmap.c $Date: 96/11/20 11:02:00 $ $Revision: 1.17.98.14 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vm_pregion.o): vm_pregion.c $Date: 97/04/07 13:34:27 $ $Revision: 1.16.98.13 $ PATCH_10.20 (PHKL_10643) /usr/conf/lib/libhp-ux.a(vm_region.o): vm_region.c $Date: 96/11/20 11:01:58 $ $Revision: 1.20.98.4 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vm_sched.o): vm_sched.c $Date: 96/11/20 11:01:54 $ $Revision: 1.58.98.9 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vm_superpage.o): vm_superpage.c $Date: 96/08/26 22:40:13 $ $Revisi on: 1.2.98.3 $ PATCH_10.20 (PHKL_8346) /usr/conf/lib/libhp-ux.a(vm_text.o): vm_text.c $Date: 97/03/03 12:25:55 $ $Revision: 1 .56.98.9 $ PATCH_10.20 (PHKL_10257) /usr/conf/lib/libhp-ux.a(vm_vas.o): vm_vas.c $Date: 96/11/20 11:01:49 $ $Revision: 1.18.98.14 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vm_vhand.o): vm_vhand.c $Date: 96/11/20 11:02:03 $ $Revision: 1.20.98.5 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/liblvm.a(lv_block.o): lv_block.c $Date: 96/10/25 20:54:08 $ $Revision: 1.1 3.98.4 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_cluster_lock.o): lv_cluster_lock.c $Date: 96/10/25 16:50:50 $ $Revisi on: 1.10.98.4 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_defect.o): lv_defect.c $Date: 96/10/25 17:01:38 $ $Revision: 1. 16.98.4 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_hp.o): lv_hp.c $Date: 97/04/09 11:07:16 $ $Revision: 1.18.9 8.18 $ PATCH_10.20 (PHKL_10675) /usr/conf/lib/liblvm.a(lv_ioctls.o): lv_ioctls.c $Date: 96/12/11 16:51:19 $ $Revision: 1. 18.98.14 $ PATCH_10.20 (PHKL_9529) /usr/conf/lib/liblvm.a(lv_kdb.o): lv_kdb.c $Date: 96/10/25 20:54:10 $ $Revision: 1.9.9 8.3 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_lvsubr.o): lv_lvsubr.c $Date: 97/04/09 11:12:55 $ $Revision: 1.15.98.12 $ PATCH_10.20 (PHKL_10675) /usr/conf/lib/liblvm.a(lv_malloc.o): lv_malloc.c $Date: 96/10/25 20:55:45 $ $Revision: 1. 11.98.3 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_mircons.o): lv_mircons.c $Date: 97/04/09 11:13:04 $ $Revision: 1 .14.98.6 $ PATCH_10.20 (PHKL_10675) /usr/conf/lib/liblvm.a(lv_pbuf.o): lv_pbuf.c $Date: 96/10/25 20:54:12 $ $Revision: 1.11 .98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_phys.o): lv_phys.c $Date: 97/03/18 09:02:42 $ $Revision: 1.14 .98.9 $ PATCH_10.20 (PHKL_10452) /usr/conf/lib/liblvm.a(lv_schedule.o): lv_schedule.c $Date: 97/04/09 11:13:34 $ $Revision: 1.18.98.10 $ PATCH_10.20 (PHKL_10675) /usr/conf/lib/liblvm.a(lv_spare.o): lv_spare.c $Date: 96/10/28 11:23:00 $ $Revision: 1.3 .98.4 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_strategy.o): lv_strategy.c $Date: 97/04/09 11:13:41 $ $Revision: 1.14.98.6 $ PATCH_10.20 (PHKL_10675) /usr/conf/lib/liblvm.a(lv_stub.o): lv_stub.c $Date: 96/10/25 20:54:05 $ $Revision: 1.13 .98.2 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_subr.o): lv_subr.c $Date: 96/10/25 17:02:45 $ $Revision: 1.18 .98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_syscalls.o): lv_syscalls.c $Date: 96/10/25 17:02:53 $ $Revision: 1.14.98.7 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_vgda.o): lv_vgda.c $Date: 96/10/25 17:03:01 $ $Revision: 1.18 .98.3 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_vgsa.o): lv_vgsa.c $Date: 96/10/25 17:03:05 $ $Revision: 1.14 .98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(sh_vgsa.o): sh_vgsa.c $Date: 96/10/25 17:03:23 $ $Revision: 1.3 .98.7 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(slvm_comm.o): slvm_comm.c $Date: 96/10/25 17:03:40 $ $Revision: 1. 3.98.4 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(slvm_schedule.o): slvm_schedule.c $Date: 96/10/25 17:03:49 $ $Revision : 1.3.98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/master.d/core-hpux: core-hpux $Date: 96/11/20 11:08:41 $ $Revision: 1. 6.98.13 $ PATCH_10.20 (PHKL_9075) /usr/conf/space.h.d/core-hpux.h: core-hpux.h: $Revision: 1.6.98.11 $ $Date: 96/11/20 11:07:03 $ PATCH_10.20 (PHKL_9075) cksum(1) Output: 3294814409 19476 /usr/conf/lib/libhp-ux.a(asm_rv.o) 1053092530 19912 /usr/conf/lib/libhp-ux.a(clock.o) 4114346575 11604 /usr/conf/lib/libhp-ux.a(cpd.o) 797819625 12752 /usr/conf/lib/libhp-ux.a(dump.o) 4216505336 13380 /usr/conf/lib/libhp-ux.a(hdl_fault.o) 555026448 6348 /usr/conf/lib/libhp-ux.a(hdl_init.o) 997333578 15648 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 3636937882 11908 /usr/conf/lib/libhp-ux.a(hdl_policy.o) 2718340289 10016 /usr/conf/lib/libhp-ux.a(hdl_trans.o) 2533919486 16844 /usr/conf/lib/libhp-ux.a(kern_exec.o) 4163060998 3948 /usr/conf/lib/libhp-ux.a(kern_mman.o) 3609837110 26628 /usr/conf/lib/libhp-ux.a(lv_config.o) 3955047993 156556 /usr/conf/lib/libhp-ux.a(lv_lvm.o) 476359382 5308 /usr/conf/lib/libhp-ux.a(pm_config.o) 3811483497 2236 /usr/conf/lib/libhp-ux.a(pm_context.o) 3662312379 6696 /usr/conf/lib/libhp-ux.a(pm_procdup.o) 2226603191 7076 /usr/conf/lib/libhp-ux.a(pm_resource.o) 2327822087 16172 /usr/conf/lib/libhp-ux.a(pm_sendsig.o) 943711055 23736 /usr/conf/lib/libhp-ux.a(pstat.o) 925297696 8712 /usr/conf/lib/libhp-ux.a(sysV_shm.o) 3310110528 29820 /usr/conf/lib/libhp-ux.a(vfs_vm.o) 2384454065 91012 /usr/conf/lib/libhp-ux.a(vm_machdep.o) 133406500 21604 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 1265397058 12324 /usr/conf/lib/libhp-ux.a(vm_pregion.o) 1266053234 11316 /usr/conf/lib/libhp-ux.a(vm_region.o) 3119256795 24816 /usr/conf/lib/libhp-ux.a(vm_sched.o) 4017694933 9992 /usr/conf/lib/libhp-ux.a(vm_superpage.o) 2800961341 14444 /usr/conf/lib/libhp-ux.a(vm_text.o) 1181531280 13300 /usr/conf/lib/libhp-ux.a(vm_vas.o) 1919993849 14372 /usr/conf/lib/libhp-ux.a(vm_vhand.o) 2908410957 2624 /usr/conf/lib/liblvm.a(lv_block.o) 3171795420 9956 /usr/conf/lib/liblvm.a(lv_cluster_lock.o) 896200314 12464 /usr/conf/lib/liblvm.a(lv_defect.o) 236599734 83108 /usr/conf/lib/liblvm.a(lv_hp.o) 3824188877 31668 /usr/conf/lib/liblvm.a(lv_ioctls.o) 3467347777 728 /usr/conf/lib/liblvm.a(lv_kdb.o) 1307949015 36088 /usr/conf/lib/liblvm.a(lv_lvsubr.o) 71576499 2544 /usr/conf/lib/liblvm.a(lv_malloc.o) 4246721683 17420 /usr/conf/lib/liblvm.a(lv_mircons.o) 311558564 6568 /usr/conf/lib/liblvm.a(lv_pbuf.o) 2632588947 7712 /usr/conf/lib/liblvm.a(lv_phys.o) 3179031424 26360 /usr/conf/lib/liblvm.a(lv_schedule.o) 2221436812 36328 /usr/conf/lib/liblvm.a(lv_spare.o) 2281280116 7164 /usr/conf/lib/liblvm.a(lv_strategy.o) 4115391771 732 /usr/conf/lib/liblvm.a(lv_stub.o) 492882945 10056 /usr/conf/lib/liblvm.a(lv_subr.o) 1066182273 13520 /usr/conf/lib/liblvm.a(lv_syscalls.o) 4142623297 9100 /usr/conf/lib/liblvm.a(lv_vgda.o) 3239541967 12592 /usr/conf/lib/liblvm.a(lv_vgsa.o) 3517786406 41964 /usr/conf/lib/liblvm.a(sh_vgsa.o) 2159002800 27264 /usr/conf/lib/liblvm.a(slvm_comm.o) 4188283521 6724 /usr/conf/lib/liblvm.a(slvm_schedule.o) 151105656 16751 /usr/conf/master.d/core-hpux 534048381 18816 /usr/conf/space.h.d/core-hpux.h Patch Conflicts: None Patch Dependencies: s700: 10.20: PHCO_8871 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_7870 PHKL_8084 PHKL_8346 PHKL_8532 PHKL_8716 PHKL_8999 PHKL_9075 PHKL_9529 PHKL_9919 PHKL_10176 PHKL_10234 PHKL_10257 PHKL_10316 PHKL_10452 PHKL_10643 PHKL_10675 PHKL_10689 Equivalent Patches: PHKL_10822: s800: 10.20 Patch Package Size: 1170 Kbytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHKL_10821 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_10821.depot 5b. For a homogeneous NFS Diskless cluster run swcluster on the server to install the patch on the server and the clients: swcluster -i -b This will invoke swcluster in the interactive mode and force all clients to be shut down. WARNING: All cluster clients must be shut down prior to the patch installation. Installing the patch while the clients are booted is unsupported and can lead to serious problems. The swcluster command will invoke an swinstall session in which you must specify: alternate root path - default is /export/shared_root/OS_700 source depot path - /tmp/PHKL_10821.depot To complete the installation, select the patch by choosing "Actions -> Match What Target Has" and then "Actions -> Install" from the Menubar. 5c. For a heterogeneous NFS Diskless cluster: - run swinstall on the server as in step 5a to install the patch on the cluster server. - run swcluster on the server as in step 5b to install the patch on the cluster clients. By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_10821. If you do not wish to retain a copy of the original software, you can create an empty file named /var/adm/sw/patch/PATCH_NOSAVE. Warning: If this file exists when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. It is recommended that you move the PHKL_10821.text file to /var/adm/sw/patch for future reference. To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_10821.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: Due to the number of objects in this patch, the customization phase of the update may take more than 10 minutes. During that time the system will not appear to make forward progress, but it will actually be installing the objects.