Patch Name: PHKL_31003 Patch Description: s700_800 11.11 Cumulative VM patch Creation Date: 04/06/03 Post Date: 04/07/26 Hardware Platforms - OS Releases: s700: 11.11 s800: 11.11 Products: N/A Filesets: OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_31003: PANIC PHKL_30158: HANG PHKL_28990: ABORT CORRUPTION HANG The defect described in JAGae67573 can result in seemingly random application failures for those applications that call mprotect(2) with the PROT_CHECK flag. PHKL_28428: PANIC CORRUPTION PHKL_28267: PANIC CORRUPTION PHKL_27278: PANIC CORRUPTION PHKL_26744: PANIC PHKL_26233: PANIC PHKL_25614: CORRUPTION PANIC ABORT JAGad62420: a process with a private 3rd quadrant can obtain an erroneous address when calling mmap(2) for a large mapping ( size > 1 GB). The erroneous address can match an already existing address for that process. If this is the case, subsequent use of this address could lead to corruption of data already at that address, as now 2 pointers with different meaning refer to the same block of data. The corruption is limited to the own address space of the process, and possibly files mapped by the process. The corruption is limited to the calling process address space, and will not affect system or other process memory. PHKL_25129: CORRUPTION PHKL_24073: HANG Category Tags: defect_repair enhancement general_release critical panic halts_system corruption Path Name: /hp-ux_patches/s700_800/11.X/PHKL_31003 Symptoms: PHKL_31003: ( SR:8606354805 CR:JAGaf15561 ) In rare cases, system may panic with the stacktrace similar to one give below while processing mmap(2) requests. panic+0x6c report_trap_or_int_and_panic+0x94 trap+0xed4 thandler+0xd20 shrinkvfd+0x70 growreg+0x1e8 mapvnode+0x1e0 mmap_file_object+0x128 smmap_common+0x2e8 smmap+0x50 syscall+0xaec syscallinit+0x554 ( SR:8606351558 CR:JAGaf12363 ) The system may panic with a stacktrace similar to one given below while processing fork()/mmap() requests. panic+0x6c report_trap_or_int_and_panic+0x94 trap+0xef4 thandler+0xd20 mrg_return_freemem+0x1d0 freepfd+0x254 do_freepagesc+0x1b4 for_val2+0x29c for_val2+0x13c foreach_chunk+0x3c pgfree+0x9c freereg+0x3c private_copy+0x1c0 dupvas+0x220 procdup+0x3c newproc+0x640 fork1+0x1c0 fork+0x14 syscall+0xaec syscallinit+0x554 PHKL_30616: ( SR:8606341242 CR:JAGaf02151 ) This product update is a member of a set needed to enable the optional HP-UX Mmap-Perf feature. Upon installation, the HP-UX Mmap-Perf bundle(EnhancedMMAP) will install the full set of product updates (including this one) to enable the Mmap-Perf feature. If the HP-UX Mmap-Perf feature product is not installed, this product update will have no impact on your system. PHKL_30158: ( SR:8606335008 CR:JAGae96085 ) System may hang when fork(2) fails due to unavailable protection or space ids. The following is the stack trace when the hang is TOC'ed. su_waiters+0x10 call_su_waiters+0x1c lock_write+0xfc findpreg+0x150 pfault+0xe4 trap+0xa1c nokgdb+0x8 b_eight_word_loop+0x4 long_copyin+0xb4 long_uiomove+0xfc vx_write_default+0xab0 vx_write1+0x878 vx_rdwr+0x144 vn_rdwr+0x84 write_to_core+0xe0 write_prp_core+0x3c pa32_write_prp_seg+0x7c pa32_walkpregions+0x50 pa32_core+0x134 core+0x1b8 psig+0x4fc syscall+0xb38 $syscallrtn+0x0 syscall+0xb38 $syscallrtn+0x0 PHKL_28990: ( SR:8606304228 CR:JAGae67573 ) Applications that use the mprotect(2) system call with the PROT_CHECK flag may fail randomly due to an incorrect result returned from mprotect(2). ( SR:8606283720 CR:JAGae47665 ) This patch is required for systems running Hyper Messaging Protocol(HMP)/Message Passing Interface (MPI) applications. The MPI applications hang after some time as they receive corrupt data. This problem can be seen on systems running MPI or HMP applications with the hyperfabric cards. When the parent forks and the child exits before the parent (MPI/HMP application) sends/receives data, there could be data corruption. The behavior is evident when using a popen(), pclose() call and immediately starting data transfer via HMP. PHKL_28428: ( SR:8606267409 CR:JAGae31651 ) System panic when removing an iomap range from a child process of a fork() system call when the parent process has already removed the range. Trap Type 15 (Data page fault): Instruction Address (pcsq.pcoq) = 0x0.0x1256c4 Instruction (iir) = 0x4134002e (load/store) Target Address (isr.ior) = 0x0.0x0000000000000017 Base Register (gr9) = 0x0000000000000000 Savestate Ptr (ssp) = 0xe57bc00.0x400003ffffff1378 Savestate Return Pointer (ss_rp) = 0x00000000001256c0 panic: Data page fault A typical stack trace for this problem is: panic+0x6c report_trap_or_int_and_panic+0x94 trap+0xef4 nokgdb+0x8 pddpage+0xc4 io_unmap+0x25c iomap_nuke+0x24 iomap_exit+0xa4 exit+0xf30 rexit+0x24 syscall+0x20c $syscallrtn+0x0 ( SR:8606267454 CR:JAGae31696 ) This problem was found in HP internal analysis and has not been encountered on customer systems. If the problem occurs, the system may panic or experience system memory corruption (which may in turn cause user memory corruption). Because the exact behavior depends entirely on the state of the system, a typical stack trace for such a panic is not possible. PHKL_28267: ( SR:8606220721 CR:JAGad89858 ) Duplicate ( SR:8606227157 CR:JAGad96219 ) Under certain conditions of a process fork/exit, the system may panic with the panic string: "freevas: vas cnt 0, but still pointing to pregions". The stack trace may be similar to: panic+0x14 freevas+0x164 freeproc+0x22c wait1+0x25c waitpid+0x38 syscall+0x394 $syscallrtn+0x0 PHKL_27278: ( SR:8606262338 CR:JAGae26673 ) Using glance, or any tools based on pstat, to report memory information about a single-threaded process, can cause a panic. The panic will occur in psl_search(). Before the panic occurs, corruption is possible as the process address space is corrupted. PHKL_26744: ( SR:8606202772 CR:JAGad71946 ) A data page fault panic may occur as the result of running mmap(2) more than 65535 times on a file. The resulting stack trace may look similar to the following: panic+0x6c report_trap_or_int_and_panic+0x94 trap+0xa9c nokgdb+0x8 skl_deletevalue+0x4 remove_pregion_from_region+0xc8 detachreg+0xa4 dispreg+0x164 exit+0xb3c rexit+0x24 syscall+0x724 $syscallrtn+0x0 PHKL_26386: ( SR:8606186482 CR:JAGad55686 ) This product update provides pre-enablement of extensions to mmap to allow mapping of I/O registers or address ranges. This product update will have no impact on your system until the extensions to mmap are fully enabled. PHKL_26233: ( SR:8606230627 CR:JAGad99677 ) System panic with the following stack trace. panic+0x6c report_trap_or_int_and_panic+0x94 trap+0xed4 thandler+0xd20 hdl_vfault+0x80 vfault+0x12c trap+0x234 thandler+0xd20 PHKL_25614: ( SR:8606193208 CR:JAGad62420 ) A 32 bit process with the 3rd quadrant private (obtained with the command chattr +q3 enable) can obtain an incorrect address when requesting a large (~1 GB) mapping with the mmap(2) call. Observed symptoms are : -process aborted because of a memory fault (signals SIGBUS or SIGSEGV). -corruption of the memory for the calling process, including files that are mapped in memory by the process. System memory and memory from other processes are not impacted. ( SR:8606212954 CR:JAGad82141 ) When a 32 bit process uses mmap64(2) to mmap(2) a large file on a 64 bit kernel, if the offset is bigger than 4 GB, the call returns EINVAL. ( SR:8606188767 CR:JAGad57983 ) Applications requiring large amounts of private memory address space (greater than 2GB) may use shared memory space to offset their private memory space needs. This is done by using the mmap(2) flags: MAP_ANONYMOUS|MAP_GLOBAL|MAP_SHARED. Even with this effort to conserve private memory space, these applications are running out of private memory space. A close examination shows that allocations intended for shared space were put into private memory space in error. ( SR:8606205797 CR:JAGad74972 ) A panic "Returning ID that is already free" may occur as a result of a process (proc A) calling mmap(2) with MAP_FIXED and an address that overlaps with an existing text mapping. This will result in a panic in one of the following ways: (1) Panic occurs when process proc A exits. (2) The process proc A does a munmap(2) of the previous mmap(2) (as mentioned above) and subsequent mmap(2) calls from any process (proc X) get assigned the same address. When process proc X exits (case 1) the panic occurs. A stack trace may look similar to the following: panic+0x6c hdl_return_id+0xb8 hdl_free_protid+0x1c hdl_detach+0x17c attachreg+0x228 mmap_anon_object+0xc4 smmap_common+0x35c smmap+0x50 syscall+0x750 $syscallrtn+0x0 PHKL_25129: ( SR:8606215349 CR:JAGad84536 ) Memory corruption may occur after the installation of PHKL_24679. PHKL_24679: ( SR:8606201639 CR:JAGad70813 ) The system takes a lot of time in creating a large number of threads. The cost of creating threads increases exponentially as the number of threads increases and so the system appears to be very slow when one tries to create a lot of threads. PHKL_25227: ( SR:8606188435 CR:JAGad57643 ) Narrow mode (32bit) HP-UX 11.11 programs cannot mmap64() any part of a large file beyond the first 2GB. PHKL_24743: ( SR:8606205558 CR:JAGad74733 ) Duplicate ( SR:8606204858 CR:JAGad74036 ) Decreased performance for mmap() operations has occasionally been observed in superdome systems with more than 32 cpus. These symptoms are not specific to superdomes, but could possibly occur on other high end systems as well. PHKL_24073: ( SR:8606189205 CR:JAGad58421 ) A multi-threaded process hangs and cannot be killed. This process will have been repeatedly mmap()ing parts of the same file, while at the same time reading or writing to it with the read(), write(), readv(), or writev() system calls from a different thread. That file must also be on a JFS file system. The Netscape Messaging Server's smtpd process is the only application we've seen do the particular combination of operations required to get into this state. Defect Description: PHKL_31003: ( SR:8606354805 CR:JAGaf15561 ) Some mmap(2) requests are not correctly processed. Resolution: mmap(2) requests are now processed correctly. ( SR:8606351558 CR:JAGaf12363 ) Under certain circumstances when fork()/mmap() fails, the system may panic. In the failure path of fork()/mmap(), the source's region lock is released before the destination's partially created region is freed back. Releasing source's region lock creates a window where vhand() acquires it and pushes valid pages into swap. Now in the failure path of fork()/mmap(), freereg() is invoked to release the same pages (COW'd) from the destination's region. Since destination is not yet completely setup, it's MRG pointer is NULL which when referenced leads to a panic. Resolution: The solution involves releasing the pages from destination's region before the source's region lock is released. This ensures that it is source's responsibility to release the page to the free memory pool. PHKL_30616: ( SR:8606341242 CR:JAGaf02151 ) This product update contains minor enhancements required to enable the HP-UX Mmap-Perf. Resolution: Enhancements added to set up the system for loading the HP-UX Mmap-Perf feature when this product is configured. PHKL_30158: ( SR:8606335008 CR:JAGae96085 ) When a process having called mprotect(PROT_NONE) on private region(s) calls fork(2) system call and if fork(2) does not succeed due to unavailability of protection or space ids, it may result in hang. This is due to freeing the parent process' resources incorrectly in the fork(2) cleanup path. Resolution: Incorrect logic in the fork(2) cleanup path is corrected. PHKL_28990: ( SR:8606304228 CR:JAGae67573 ) mprotect(2), when called with the PROT_CHECK flag, was checking access rights on pages from the beginning of the specified pregion instead of from the pregion offset that is passed in. Resolution: Corrected the access protection checking code to begin at the given offset instead of at the beginning of the pregion. ( SR:8606283720 CR:JAGae47665 ) When MPI/HMP applications fork a child process and make the child exit, the child - which shares the parent's address space because of the Copy On Write feature of fork - clears bits incorrectly in the shared pages. This action leads to data corruption for the parent. Since the bit is incorrectly cleared, the HMP call back function is not called when the parent does a copy-on-write. So, the lowfat code writes new data to the old page causing data corruption. This defect exists in the large page (> 4k) code only. Resolution: Corrected the code to disallow the child from incorrectly clearing bits in the shared address space. PHKL_28428: ( SR:8606267409 CR:JAGae31651 ) The fork() system call does not add the child process address space to the iomap control structures as intended when the parent of the fork() has performed an iomap. Resolution: Revised the fork() system call to add the child address space as intended. ( SR:8606267454 CR:JAGae31696 ) The exec() system call re-uses the address space of the calling process for the target process. If the calling process had performed an iomap operation (via a device driver), the mapping is removed from the address space. However, the address space is not being removed from the iomap control structures. When the target process exits, the kernel memory address of this address space remains in the control structures. This address may now reference a new kernel structure, kernel data, or memory which is not in use. Since the use of this reference in the control structures involves memory reads and writes, using the invalid reference may cause a kernel panic or may overwrite kernel or user data. Resolution: Perform the removal of such a mapping in the exec() system call in the same way as an explicit unmap, ensuring that the address space reference is also removed. PHKL_28267: ( SR:8606220721 CR:JAGad89858 ) Duplicate ( SR:8606227157 CR:JAGad96219 ) The reference count for the process' Virtual Address Space (vas) is not protected from multiple concurrent accesses by any lock. This results in a race condition and possible ambiguous value in the reference count. If the reference count is decremented to zero but the vas is still pointing to valid pregions that are still in use, the freevas panic will occur when attempting to free the vas. Resolution: The resolution is to lock the vas whenever the reference count is incremented/decremented, thereby serializing any changes and maintaining coherency of the reference count. PHKL_27278: ( SR:8606262338 CR:JAGae26673 ) There is a race condition between pstat and a function managing a process address space. This causes the corruption of the list representing a process address space, leading to a panic. Resolution: The fix consists of enforcing locking even for single-threaded processes, to protect them from external pstat requests. PHKL_26744: ( SR:8606202772 CR:JAGad71946 ) The variable holding the mmap reference count is not checked for overflow. When the variable resets to zero, the system panics with a data page fault. Resolution: The overflow condition is now detected. The panic is avoided by returning ENOMEM when the mmap(2) reference count variable overflows. PHKL_26386: ( SR:8606186482 CR:JAGad55686 ) This product update contains minor enhancements required to enable extensions to mmap to allow mapping of I/O registers or address ranges. Resolution: Extended mmap to recognize MAP_IO flag and perform mapping if functionality is enabled. PHKL_26233: ( SR:8606230627 CR:JAGad99677 ) Kernel incorrectly handles some of the parameters to setrlimit. Resolution: The kernel is fixed to handle the particular parameters correctly. PHKL_25614: ( SR:8606193208 CR:JAGad62420 ) On 64 bit systems, calls to mmap(2) by 32 bit processes with sizes in the range of 1 GB or greater cause the allocation algorithm to allocate a segment in the 64 bit address space instead of the 32 bit address space. The 64 bit address is truncated to 32 bits on return to the 32 bit calling process. The cause of this error is an incorrect boundaries checking in the allocation algorithm. When using a debugger, one can observe a 64 bit segment in the process address space. Resolution: The allocation algorithm now checks boundary conditions correctly, producing a correct memory address. ( SR:8606212954 CR:JAGad82141 ) One kernel structure associated with the mapped file is based on the type of the process address space. Thus a 32 bit process creates a 32 bit mapped file kernel structure. The kernel structure should be independent from the type of the calling process. Resolution: The creation of the kernel structure associated with a mmap file has been made independent from the type of the process. ( SR:8606188767 CR:JAGad57983 ) The mmap(2) system call ignores the MAP_GLOBAL flag when used in combination with the MAP_SHARED and MAP_ANONYMOUS flags. Resolution: Checking for the MAP_GLOBAL option in mmap(2) when the MAP_ANONYMOUS and MAP_SHARED flags are used. The allocation is then made from the appropriate quadrant. ( SR:8606205797 CR:JAGad74972 ) This panic results from trying to free the same ID twice as a result of the system allowing a mapping that overlaps with an existing mapping of text. Resolution: mmap(2) calls with addresses that overlap with existing text mappings will now fail. PHKL_25129: ( SR:8606215349 CR:JAGad84536 ) In one corner case the fix for "PHKL_24679" overwrites some memory beyond the allocated limit for an internal data structure. Resolution: Overwriting of memory is fixed by checking for a corner case. PHKL_24679: ( SR:8606201639 CR:JAGad70813 ) When ever a range of virtual address space is allocated for a thread the OS always searches for a hole from the highest possible address so as to give maximum possible space for the heap to grow. When large number of threads are created and all space in the proximity of the highest address is occupied it takes a while before the search could get a hole of required size, which slows down the thread creation process. Resolution: The fix to the problem is to keep a hint for starting the search next time so we do not have to start always from the highest address. PHKL_25227: ( SR:8606188435 CR:JAGad57643 ) The kernel code was limited by design to allow narrow mode mmap64() to 2GB or less only. Resolution: The kernel was enhanced to remove this limitation. Narrow mode mmap64() can now map up to 4GB. PHKL_24743: ( SR:8606205558 CR:JAGad74733 ) Duplicate ( SR:8606204858 CR:JAGad74036 ) Unnecessary acquisition and release of region locks in common execution paths can cause unpredictable performance degradation. Resolution: ltered code path to minimize frequency of region lock/release in procedures mmap_file_pieces() and mmap_file_object(). Note that this is only one of the causes for unpredictable performance degradation in mmap. PHKL_24073: ( SR:8606189205 CR:JAGad58421 ) This problem was caused by a lock ordering problem between VM and JFS. JFS can call VM while holding an inode lock; the routines called may require a vas lock. VM can call JFS while holding a vas lock; the routines called may require an inode lock. If we get unlucky, we hit the same vas/inode lock combination from both directions, and the threads deadlock. Because the vas lock potentially held by VM is a per process resource, this situation can only be encountered by a multithreaded process. Resolution: The fix is to have the VM routine drop the vas lock before calling the file system code; fortunately, the VM routine can safely drop and reacquire the lock around the call ... it was mostly holding it to avoid dropping and reacquiring it repeatedly in a loop. Enhancement: No (superseded patches contained enhancements) PHKL_30616: Support added for Mmap-Perf Enhancement to improve the performance of smmap_hole_file which is called via mmap(2). The smmap_hole_file improvement will be derived when this patch will be configured. PHKL_28428: Enhancements were delivered in a patch this one has superseded. Please review the Defect Description text for more information. SR: 8606186482 8606188435 8606188767 8606189205 8606193208 8606201639 8606202772 8606204858 8606205558 8606205797 8606212954 8606215349 8606220721 8606227157 8606230627 8606262338 8606267409 8606267454 8606283720 8606304228 8606335008 8606341242 8606351558 8606354805 Patch Files: OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP: /usr/conf/lib/libvm-pdk.a(hdl_policy.o) /usr/conf/lib/libvm-pdk.a(vm_procdup.o) /usr/conf/lib/libvm.a(vm_mmap.o) /usr/conf/lib/libvm.a(vm_pregion.o) /usr/conf/lib/libvm.a(vm_vas.o) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: /usr/conf/lib/libvm-pdk.a(hdl_policy.o) /usr/conf/lib/libvm-pdk.a(vm_procdup.o) /usr/conf/lib/libvm.a(vm_mmap.o) /usr/conf/lib/libvm.a(vm_pregion.o) /usr/conf/lib/libvm.a(vm_vas.o) what(1) Output: OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP: /usr/conf/lib/libvm-pdk.a(hdl_policy.o): hdl_policy.c $Date: 2001/10/31 14:13:17 $Revision: r 11.11/3 PATCH_11.11 (PHKL_25614) /usr/conf/lib/libvm-pdk.a(vm_procdup.o): vm_procdup.c $Date: 2002/11/21 12:14:20 $Revision: r 11.11/2 PATCH_11.11 (PHKL_28267) /usr/conf/lib/libvm.a(vm_mmap.o): vm_mmap.c $Date: 2004/06/03 05:33:48 $Revision: r11. 11/9 PATCH_11.11 (PHKL_31003) /usr/conf/lib/libvm.a(vm_pregion.o): vm_pregion.c $Date: 2003/04/11 12:42:27 $Revision: r 11.11/6 PATCH_11.11 (PHKL_28990) /usr/conf/lib/libvm.a(vm_vas.o): vm_vas.c $Date: 2004/06/03 05:32:10 $Revision: r11.1 1/7 PATCH_11.11 (PHKL_31003) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: /usr/conf/lib/libvm-pdk.a(hdl_policy.o): hdl_policy.c $Date: 2001/10/31 14:13:17 $Revision: r 11.11/3 PATCH_11.11 (PHKL_25614) /usr/conf/lib/libvm-pdk.a(vm_procdup.o): vm_procdup.c $Date: 2002/11/21 12:14:20 $Revision: r 11.11/2 PATCH_11.11 (PHKL_28267) /usr/conf/lib/libvm.a(vm_mmap.o): vm_mmap.c $Date: 2004/06/03 05:33:48 $Revision: r11. 11/9 PATCH_11.11 (PHKL_31003) /usr/conf/lib/libvm.a(vm_pregion.o): vm_pregion.c $Date: 2003/04/11 12:42:27 $Revision: r 11.11/6 PATCH_11.11 (PHKL_28990) /usr/conf/lib/libvm.a(vm_vas.o): vm_vas.c $Date: 2004/06/03 05:32:10 $Revision: r11.1 1/7 PATCH_11.11 (PHKL_31003) cksum(1) Output: OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP: 843949957 18940 /usr/conf/lib/libvm-pdk.a(hdl_policy.o) 2442264280 8576 /usr/conf/lib/libvm-pdk.a(vm_procdup.o) 2324421623 32856 /usr/conf/lib/libvm.a(vm_mmap.o) 4220781687 16404 /usr/conf/lib/libvm.a(vm_pregion.o) 2006911363 16024 /usr/conf/lib/libvm.a(vm_vas.o) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: 687719852 42680 /usr/conf/lib/libvm-pdk.a(hdl_policy.o) 3574275004 17144 /usr/conf/lib/libvm-pdk.a(vm_procdup.o) 1742111118 72296 /usr/conf/lib/libvm.a(vm_mmap.o) 177078994 33312 /usr/conf/lib/libvm.a(vm_pregion.o) 3451884094 37472 /usr/conf/lib/libvm.a(vm_vas.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_30616 PHKL_30158 PHKL_28990 PHKL_28428 PHKL_28267 PHKL_27278 PHKL_26744 PHKL_26386 PHKL_26233 PHKL_25614 PHKL_25227 PHKL_25129 PHKL_24743 PHKL_24679 PHKL_24073 Equivalent Patches: None Patch Package Size: 170 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_31003 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_31003.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_31003. If you do not wish to retain a copy of the original software, include the patch_save_files option in the swinstall command above: -x patch_save_files=false WARNING: If patch_save_files is false when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. For future reference, the contents of the PHKL_31003.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_31003.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_31003.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None