Patch Name: PHKL_31239 Patch Description: s700_800 11.11 Cumulative VM, Psets, Preemption, PRM, MRG Creation Date: 04/07/19 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_31239: OTHER Performance degradation in garbage collection path while garbage collecting long freelist of a small block arena. PHKL_28695: PANIC HANG PHKL_28121: HANG PHKL_27825: HANG PHKL_26893: PANIC MEMORY_LEAK PHKL_23425: PANIC PHKL_26938: PANIC PHKL_26549: PANIC PHKL_25304: OTHER Because of the defect, MRG based paging could result in some MRGs being targeted more harshly than others. Applications in those MRGs that are targeted more may lose almost all their pages of memory and eventually get swapped out. The problem could also manifest itself in another fashion wherein applications belonging to the MRGs that are being targeted more than others, experience a performance degradation. This patch corrects the limitations of the paging and process deactivation logic and therefore prevents these problems from occuring. PHKL_23445: ABORT The application falsely believes an "out of memory" condition has occurred and reacts according to its logic, possibly resulting in an abort. Category Tags: defect_repair enhancement general_release critical panic halts_system memory_leak Path Name: /hp-ux_patches/s700_800/11.X/PHKL_31239 Symptoms: PHKL_31239: ( SR:8606356423 CR:JAGaf17131 ) Garbage collection of a small block arena may take long time. This might affect real time threads on the system. PHKL_28695: ( SR:8606287713 CR:JAGae51648 ) When an application mmap's an NFS or UFS file that is larger than 2GB, the system may panic when accessing the file. For an NFS file, the panic stack trace may be similar to: panic: pdremap panic+0x6c pdremap+0x5a4 hdl_addtrans+0x358 hdl_kmap_bp+0x39c nfs_read_ahead+0x3ac start_next_read_ahead+0xb8 checkprotid+0x318 hdl_pfault+0x4c4 pfault+0x120 trap+0x444 thandler+0xd20 The panic has not been seen on UFS, although theoretically it could occur. This panic will not be seen on local VxFS files. ( SR:8606297057 CR:JAGae60589 ) With PHKL_28121 or PHKL_28405 installed, the system may panic during or shortly after periods of heavy memory usage. The panic stack trace may be similar to: panic string: Unexpected interrupt while PSW-Q = 0 panic+94 report_trap_or_int_and_panic+94 mp_ext_interrupt+370 ivti_patch_to_nop3 There will also be a random process with a stack trace similar to the following: _swtch+0xd8 preemption_point+0x27c kmem_gc_large+0x20c kmem_gc_freelist+0xa0 kmem_gc_arena+0x94 kmem_do_gc+0x60 foreach_arena+0x84 kmem_garbage_collect+0xa4 schedpaging+0x214 invoke_callouts_for_self+0x8c sw_service+0xc4 mp_ext_interrupt+0x11c ihandler+0x8b8 The system message buffer, as displayed by dmesg(1M), will contain the following message: System is close to kernel virtual memory limit (KVMLIMIT). This is an abnormal condition and the kernel will attempt to reclaim some space. Please check the tunable parameters. ( SR:8606289313 CR:JAGae53244 ) After periods of memory pressure, large processes that have been deactivated take a long time to be reactivated, even after memory pressure is alleviated. ( SR:8606301947 CR:JAGae65310 ) With PHKL_27825, PHKL_28121, or PHKL_28405 installed and Memory Resource Groups (MRGs) enabled, a marked increase in process deactivation is seen, which may result in a non-interruptible application hang and possibly eventually a system hang. ( SR:8606301260 CR:JAGae64729 ) When MRGs are enabled, deactivated processes that belong to an MRG may stay deactivated forever. ( SR:8606302612 CR:JAGae65971 ) When MRGs are enabled and there are processes in an MRG sleeping on memory, they may sleep forever. ( SR:8606297833 CR:JAGae61335 ) When MRGs are enabled and a process involved in an MRG_MOVE is deactivated, it will never be reactivated. PHKL_28405: ( SR:8606271933 CR:JAGae36111 ) After the system is up for more than 248 continuous days, paging performance decreases dramatically. PHKL_28121: ( SR:8606261213 CR:JAGae25535 ) An external event causes most of the memory to be consumed by the kernel and then be freed. This puts the machine in a state of a perceived hang, waiting for the memory to be reclaimed. PHKL_27825: ( SR:8606256617 CR:JAGae20932 ) A uniprocessor machine will hang. If a TOC is taken, vhand's stack trace will look similar to this: csuperpage_lock vhand_vfdcheck for_val3 for_val2 for_val2 for_val2 foreach_valid agepages vhand_core vhand im_vhand DoCalllist main $vstart istackatbase On a multiprocessor system, vhand will consume 100% of a cpu in system mode as seen using a performance monitoring tool. This has been observed in a system under high memory pressure while starting up a large database application. ( SR:8606230137 CR:JAGad99188 ) When a system is running extremely low on physical memory, caused by high kernel centric memory loads, all user applications stall for memory and the system hangs. PHKL_26893: ( SR:8606192761 CR:JAGad61973 ) When the system is under heavy memory/swap pressure, a defect in the page fault path may result in a variety of symptoms, from a thread/process or system hang to a system panic. No such hangs/panics have been seen or reported, either externally or in internal testing. ( SR:8606232994 CR:JAGae02219 ) When under heavy memory/swap pressure, the system may panic with a data page fault in page handling routines. ( SR:8606203416 CR:JAGad72590 ) Memory leak and resulting poor system performance when using Memory Resource Groups. PHKL_24538: ( SR:8606200799 CR:JAGad69975 ) This patch is a member of a set of patches needed to enable the HP-UX Processor Sets product (PROCSETS). When PROCSETS product is installed, it will install the full set of required patches for that product, including this patch. If the HP-UX Processor Sets product is not installed, this change will have no impact on your system. PHKL_23425: ( SR:8606179363 CR:JAGad48587 ) This patch addresses an extremely rare race condition between the madvise() system call and the internal VM page-in path. The result was a panic with the following stack trace: panic() devswap_strategy() asyncpageio() dvswpgin_io() devswap_pagein() virtual_fault() vfault() The panic string is: "devswap_strategy: request exceeds swchunk" This race only occurred on a VERY heavily loaded system. For this race to be hit, the madvise() system call has to have the "MADV_DONTNEED" flag set. This flag, as defined in the madvise() man page, "Informs the kernel that the specified range is no longer needed by the process. This allows the kernel to release the physical pages associated with an address range back to the system for use by other processes." PHKL_26938: ( SR:8606249546 CR:JAGae15936 ) When using the Process Resource Manager (PRM) to manage memory groups, EXEC_MAGIC processes (with private text) migrating from one memory group to another may cause a Data Page Fault system panic. If a dump is taken, it shows the panicing process in the function mrg_break_cow_core() or possibly in the function virtual_fault(). A typical stack trace will be: ... mrg_break_cow_core+0xb4 for_val2+0x2c0 for_val2+0x224 foreach_chunk+0x3c mrg_break_priv_cow+0x8c mrg_self_move+0x394 syscall+0xb54 syscallinit+0x554 PHKL_26549: ( SR:8606234459 CR:JAGae03659 ) The PRM (Process Resource Management) tool can cause a panic with a kernel page fault under memory pressure, during VHAND (pager daemon) execution. The stack trace for this defect looks like this: stack trace for event 0 crash event was a panic panic+0x6c report_trap_or_int_and_panic+0x94 trap+0xed4 nokgdb+0x8 mrg_break_cow_core+0x110 for_val2+0x1b4 foreach_chunk+0x3c mrg_break_priv_cow+0x8c mrg_self_move+0x394 syscall+0xb54 $syscallrtn+0x0 Disabling the PRM tool makes the symptom disappear, but reduces the functionality of the system. PHKL_25304: ( SR:8606184381 CR:JAGad53590 ) MRGs fail to provide minimum entitlements under extreme memory pressure conditions. PHKL_23908: ( SR:8606128017 CR:JAGac78818 ) If a system is under a heavy application load, time critical processes such as realtime heartbeat process threads may not be scheduled to run while the pager is reducing the memory pressure. This delay may cause time critical processes to timeout. For example, ServiceGuard may failover. There are many causes of delay while the system is under a heavy application load; this change addresses only one, and may not alleviate all delay for all process loads. This problem will most likely be seen on systems with one or two processors. PHKL_24566: ( SR:8606200799 CR:JAGad69975 ) This patch is a member of a set of patches needed to enable the HP-UX Processor Sets product (PROCSETS). When PROCSETS product is installed, it will install the full set of required patches for that product, including this patch. If the HP-UX Processor Sets product is not installed, this change will have no impact on your system. PHKL_23445: ( SR:8606172440 CR:JAGad41700 ) The system will behave as if it was out of kernel memory, even when memory is still available. Defect Description: PHKL_31239: ( SR:8606356423 CR:JAGaf17131 ) Garbage collection on small block arena might take long time if the arena free list is too long. Due to lack of preemption points in the path, real time threads may not be scheduled on the CPU on which garbage collector is running. This will affect response time of real time threads. Resolution: Introduced preemption points in the garbage collector path so that real time threads are scheduled on the CPU on which garbage collector is running at the earliest possible time. PHKL_28695: ( SR:8606287713 CR:JAGae51648 ) When calculating the next read ahead address for a large NFS or UFS file, data types used in the calculation may cause sign extension, resulting in an incorrect address being generated. When the kernel tries to access the faulty address, it causes a panic. Resolution: Added casts for variables in the next read ahead address calculations to prevent sign extension. ( SR:8606297057 CR:JAGae60589 ) PHKL_28121 introduced a change to speed up returning free memory to the system (garbage collection) (JAGae25535). A preemption point was introduced to prevent the garbage collector from monopolizing a cpu for an extended time. However, preemption must be called from process context. Whenever there is severe memory pressure and kernel virtual space is exhausted, the garbage collector can be called directly from the scheduler, which means we will be in interrupt mode when the garbage collector runs. If it is necessary to preempt the garbage collector during such a run, the system will panic. Resolution: Check to see if we are in interrupt mode before calling preemption. If we are, skip the call to preemption. ( SR:8606289313 CR:JAGae53244 ) The algorithm used to determine how long a process must wait to be reactivated was based on the process size. Thus, large processes could take hours to be reactivated. Resolution: Improve the reactivation algorithm to decrease the amount of time a process must wait for reactivation when there is adequate memory available. ( SR:8606301947 CR:JAGae65310 ) PHKL_27825 introduced a change to re-enable process deactivation when Memory Resource Groups (MRGs) are enabled and there is system-wide memory pressure. However, in this case inactive processes were never chosen for deactivation. Resolution: Re-enabled deactivation of inactive processes when MRGs are enabled. ( SR:8606301260 CR:JAGae64729 ) When MRGs are enabled and there are deactivated processes in an MRG, we must take into account the free memory in the MRG to which the process belongs, the system-wide free memory, and how much memory the MRG is able to import when deciding if we can reactivate a process. Before this fix, we were only checking free memory in the MRG and free memory system-wide, and not how much memory the MRG could import. Resolution: Added a check for how much memory an MRG can import when deciding if we can reactivate a deactivated process in the MRG. ( SR:8606302612 CR:JAGae65971 ) MRGs were not attempting to import memory when there were memory sleepers. Resolution: We now wake up memory sleepers periodically to trigger the MRG to attempt to import memory. ( SR:8606297833 CR:JAGae61335 ) The MRG deactivation/reactivation code did not take into account any process that was involved in an MRG_MOVE. Resolution: The deactivation code now checks to see if a process chosen for deactivation is involved in an MRG_MOVE. If so, the process is not deactivated. PHKL_28405: ( SR:8606271933 CR:JAGae36111 ) After 248 days, one of the data types used in the paging calculations overflows, resulting in decreased paging performance. Resolution: Modified the paging calculations to accommodate overflow. PHKL_28121: ( SR:8606261213 CR:JAGae25535 ) There are two issues here: 1) The garbage collector is not aggressive enough to collect all the freed memory in case of a burst. 2) The kernel uses large pages for better TLB performance. However, this has the side effect of fragmentation, making it more difficult to reclaim a page and give it back to the system. Resolution: A change has been made to make the garbage collection more aggressive based on the adjustment of adb'ble variables. This is to avoid unnecassary performance side effects for customers not needing aggressive garbage collection. The tunable unlockable_mem must be set to be equal to 70% of the total physical memory and the adb'ble variable kmem_gc_fraction must be set at an appropriate value less than the default value of 16. The garbage collector is fastest when the variable is set to 1. PHKL_27825: ( SR:8606256617 CR:JAGae20932 ) Vhand uses an incorrect algorithm to lock all the sub-pages of a very large superpage (i.e. 256MB). If it fails to lock the first sub-page, it will try to relock all the sub-pages for each sub-page in the superpage. This is consuming the entire cpu resource for the cpu vhand is running on. Vhand will ultimately recover, but only after a long time (>20 minutes). Resolution: Detect when vhand can not lock the first sub-page, and skip the entire superpage, proceeding to the next. ( SR:8606230137 CR:JAGad99188 ) The pager/swapper implementation in 11.11 has been enhanced to support the notion of Memory Resource Groups (logical partitions of physical memory to which processes may be affiliated). It supports both the notion of per-MRG paging and swapping as well as system-wide paging and swapping. In the case of per-MRG paging and swapping, the state maintained by a particular MRG is used to determine if that group requires the services of the pager and swapper. This aspect of the pager and swapper is working correctly. For system-wide paging and swapping, the current implementation first detects the fact that the system as a whole is under memory pressure and then selects one or more MRGs to steal pages from or to deactivate processes from. However, if no MRGs are under memory pressure (which is the case here because system-wide memory pressure is being caused solely as a result of high kernel memory usage), the algorithm skips over them all in an attempt to find an overloaded MRG. Since all the MRGs are skipped, the system-wide memory pressure is never relieved. Resolution: The fix involves modifying the pager/swapper logic such that under conditions of system-wide physical memory pressure, we always find one or more MRGs to page from or deactivate processes from, even if there are no MRGSs that are themselves under memory pressure. However, an attempt will first be made to pick MRGs that are under memory pressure. PHKL_26893: ( SR:8606192761 CR:JAGad61973 ) When under heavy memory/swap pressure, a thread may have to sleep waiting for memory/swap during a page fault. Upon awakening from the sleep, the page being faulted in by the thread may have already been faulted in by another thread, and there may now be inconsistencies between the page in memory and the page on disk. We do not do a consistency check on the page after the sleep, we simply continue with the page fault and bring the page into memory again. If the page is in an inconsistent state, this can result in a variety of symptoms, such as possible process/ thread or system hangs or a panic. No such hangs/panics have been seen or reported, either externally or in internal testing. Resolution: When we must sleep on memory/swap during a page fault, we now check to see if the page was brought in while we slept and that the page state is still what we expected it to be. ( SR:8606232994 CR:JAGae02219 ) Under heavy memory/swap pressure, it is possible for only a partial subset of pages from a large page to be in the page cache. This can lead to an inconsistent state in the page cache that may subsequently cause panics in many ways, but typically in the fault handler path. Resolution: When there is heavy swap pressure and we fault a page in, we now forcefully remove it from the page cache so that the problem of having partial subsets of a large page in the page cache does not occur. ( SR:8606203416 CR:JAGad72590 ) Swap space was not being reserved for some cases of files shared among different Memory Resource Groups, resulting in those pages not being subject to paging. The pages were essentially locked in memory without being part of the lockable memory total. Resolution: Swap space is now reserved for all pages. PHKL_24538: ( SR:8606200799 CR:JAGad69975 ) This patch contains minor enhancements required to support the HP-UX Processor Sets product. Resolution: Enhancements added to access per processor set run queue of posix realtime scheduler when Processor Sets product is enabled. PHKL_23425: ( SR:8606179363 CR:JAGad48587 ) This defect involves dropping a lock while in the page-in path, and its interaction with the madvise() system call. madvise() was zero'ing out data that we had assumed did not change across our dropped lock in the page-in path. As a result, we paniced when trying to use the data. The conditions that brought about this defect are quite rare, and were discovered in internal testing. Resolution: Some more checking has been added to the page-in path. Specifically, we make sure that our data wasn't zero'ed out by madvise() while we were sleeping. PHKL_26938: ( SR:8606249546 CR:JAGae15936 ) The mrg_break_cow_core() function processes an incorrect range of addresses for some part of the private address space. The computation of the range is incorrect. Resolution: The computation of the range of addresses processed by mrg_break_cow_core() has been corrected. PHKL_26549: ( SR:8606234459 CR:JAGae03659 ) Page fault in the kernel, in mrg_cow_core(), caused by a invalid page obtained from the virtual memory subsytem after a race condition with the swapper daemon (VHAND). Resolution: The function returning the invalid page is called again when the race with VHAND is detected, until a valid page is obtained. PHKL_25304: ( SR:8606184381 CR:JAGad53590 ) When an MRGs is under memory pressure it may be allowed to consume more memory than its fixed quota, upto its maximum allowable import limit. However, when the memory pressure in the remaining MRGs risies, the MRGs exceeding their fixed quotas should return the excess memory. This is not happening in a consistent manner, resulting in some MRGs not getting their fair share when they request for memory. Resolution: The system-wide paging and process deactivation alrogithms were revised to ensure that all MRGs get paged accordingly when the system is under extreme memory pressure. The MRGs that are consuming more memory than their fixed quota are forced to return the excess amount before other MRGs on the system are targeted for paging. PHKL_23908: ( SR:8606128017 CR:JAGac78818 ) Time critical process threads will not be scheduled to run until there is an available processor. There are instances in the kernel where a process thread may not be scheduled to run even when it is the highest priority process thread. This occurs when another process thread is executing on a processor and must complete a time consuming task before releasing the processor. There are several such places in the kernel; this patch addresses one specific kernel path. When the system is under memory pressure, the pager addresses this pressure by freeing a specified number of pages. While the pager is running, no other process threads may be scheduled on that processor until the quota of free pages is met. The amount of work performed along this path is proportional to memory pressure and thus impacts delay time of waiting process threads. This problem will most likely be seen on systems with one or two processors when all processors are executing along these long kernel paths. Resolution: This patch enables kernel preemption along the kernel pager paths: If the system pager has been executing within the kernel for over a specified period of time, the kernel will preempt the pager and schedule a higher priority process thread to run. The pager will be placed back on the run queue to resume where it left off in the kernel once rescheduled. The scheduler dictates the kernel execution time allotted to a single process and the policies governing which process priorities may preempt the current process. This enhancement may not necessarily improve performance or response time for all processes as the pager may not be executing along these preemptible paths. PHKL_24566: ( SR:8606200799 CR:JAGad69975 ) This patch contains minor enhancements required to support the HP-UX Processor Sets product. Resolution: Enhancements added to access per processor set run queue of posix realtime scheduler when Processor Sets product is enabled. PHKL_23445: ( SR:8606172440 CR:JAGad41700 ) A kernel memory allocation failure can occur when an attempt to allocate memory is made with spinlocks held, even if there is a lot of free memory available on the system. To prevent system errors caused from holding spinlocks for too long, kernel memory allocation is disabled for processes that hold spinlocks if the superpage pool has not been filled. This is because filling the superpage pool normally takes longer than a process is allowed to hold a splinlock. The superpage pool remains empty until another request for memory is made on the superpage pool by a process that does not hold spinlocks. Resolution: A one-page-cache of superpages was created for use by processes that attempt to allocate memory while holding spinlocks. This one-page-cache is filled up asynchronously through the schedpaging() daemon. When a memory request comes in from a process that holds spinlocks and the superpage pool, has not been filled, we allocate memory from the 4K pool of free pages for that request, and also mark the one-page-cache to be asynchronously filled up by the schedpaging() daemon. So, even if the superpage pool is not filled soon, we still have the one-page-cache to get memory from for subsequent requests. Enhancement: No (superseded patches contained enhancements) PHKL_28405: Enhancements were delivered in a patch this one has superseded. Please review the Defect Description text for more information. SR: 8606128017 8606172440 8606179363 8606184381 8606192761 8606200799 8606203416 8606230137 8606232994 8606234459 8606249546 8606256617 8606261213 8606271933 8606287713 8606289313 8606297057 8606297833 8606301260 8606301947 8606302612 8606356423 Patch Files: OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP: /usr/conf/lib/libvm.a(subr_mrg.o) /usr/conf/lib/libvm.a(vfs_vm.o) /usr/conf/lib/libvm.a(vm_arena_gc.o) /usr/conf/lib/libvm.a(vm_devswap.o) /usr/conf/lib/libvm.a(vm_fault.o) /usr/conf/lib/libvm.a(vm_kalloc.o) /usr/conf/lib/libvm.a(vm_mrg.o) /usr/conf/lib/libvm.a(vm_sched.o) /usr/conf/lib/libvm.a(vm_vhand.o) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: /usr/conf/lib/libvm.a(subr_mrg.o) /usr/conf/lib/libvm.a(vfs_vm.o) /usr/conf/lib/libvm.a(vm_arena_gc.o) /usr/conf/lib/libvm.a(vm_devswap.o) /usr/conf/lib/libvm.a(vm_fault.o) /usr/conf/lib/libvm.a(vm_kalloc.o) /usr/conf/lib/libvm.a(vm_mrg.o) /usr/conf/lib/libvm.a(vm_sched.o) /usr/conf/lib/libvm.a(vm_vhand.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.a(subr_mrg.o): subr_mrg.c $Date: 2003/06/09 07:25:48 $Revision: r11 .11/4 PATCH_11.11 (PHKL_28695) /usr/conf/lib/libvm.a(vfs_vm.o): vfs_vm.c $Date: 2003/02/18 12:12:38 $Revision: r11.1 1/2 PATCH_11.11 (PHKL_28695) /usr/conf/lib/libvm.a(vm_arena_gc.o): vm_arena_gc.c $Date: 2004/07/16 06:19:34 $Revision: r11.11/4 PATCH_11.11 (PHKL_31239) /usr/conf/lib/libvm.a(vm_devswap.o): vm_devswap.c $Date: 2002/09/03 13:27:14 $Revision: r 11.11/4 PATCH_11.11 (PHKL_27825) /usr/conf/lib/libvm.a(vm_fault.o): vm_fault.c $Date: 2002/09/03 13:27:44 $Revision: r11 .11/5 PATCH_11.11 (PHKL_27825) /usr/conf/lib/libvm.a(vm_kalloc.o): vm_kalloc.c $Date: 2001/02/26 11:47:24 $Revision: r1 1.11/1 PATCH_11.11 (PHKL_23445) /usr/conf/lib/libvm.a(vm_mrg.o): vm_mrg.c $Date: 2001/09/18 14:26:14 $Revision: r11.1 1/1 PATCH_11.11 (PHKL_25304) /usr/conf/lib/libvm.a(vm_sched.o): vm_sched.c $Date: 2003/06/18 16:59:37 $Revision: r11 .11/6 PATCH_11.11 (PHKL_28695) /usr/conf/lib/libvm.a(vm_vhand.o): vm_vhand.c $Date: 2003/04/24 06:53:17 $Revision: r11 .11/6 PATCH_11.11 (PHKL_28695) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: /usr/conf/lib/libvm.a(subr_mrg.o): subr_mrg.c $Date: 2003/06/09 07:25:48 $Revision: r11 .11/4 PATCH_11.11 (PHKL_28695) /usr/conf/lib/libvm.a(vfs_vm.o): vfs_vm.c $Date: 2003/02/18 12:12:38 $Revision: r11.1 1/2 PATCH_11.11 (PHKL_28695) /usr/conf/lib/libvm.a(vm_arena_gc.o): vm_arena_gc.c $Date: 2004/07/16 06:19:34 $Revision: r11.11/4 PATCH_11.11 (PHKL_31239) /usr/conf/lib/libvm.a(vm_devswap.o): vm_devswap.c $Date: 2002/09/03 13:27:14 $Revision: r 11.11/4 PATCH_11.11 (PHKL_27825) /usr/conf/lib/libvm.a(vm_fault.o): vm_fault.c $Date: 2002/09/03 13:27:44 $Revision: r11 .11/5 PATCH_11.11 (PHKL_27825) /usr/conf/lib/libvm.a(vm_kalloc.o): vm_kalloc.c $Date: 2001/02/26 11:47:24 $Revision: r1 1.11/1 PATCH_11.11 (PHKL_23445) /usr/conf/lib/libvm.a(vm_mrg.o): vm_mrg.c $Date: 2001/09/18 14:26:14 $Revision: r11.1 1/1 PATCH_11.11 (PHKL_25304) /usr/conf/lib/libvm.a(vm_sched.o): vm_sched.c $Date: 2003/06/18 16:59:37 $Revision: r11 .11/6 PATCH_11.11 (PHKL_28695) /usr/conf/lib/libvm.a(vm_vhand.o): vm_vhand.c $Date: 2003/04/24 06:53:17 $Revision: r11 .11/6 PATCH_11.11 (PHKL_28695) cksum(1) Output: OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP: 652538284 32272 /usr/conf/lib/libvm.a(subr_mrg.o) 2033677029 41380 /usr/conf/lib/libvm.a(vfs_vm.o) 2245880052 8412 /usr/conf/lib/libvm.a(vm_arena_gc.o) 1788833775 22460 /usr/conf/lib/libvm.a(vm_devswap.o) 3266035561 13356 /usr/conf/lib/libvm.a(vm_fault.o) 3326502 16020 /usr/conf/lib/libvm.a(vm_kalloc.o) 3902153675 24168 /usr/conf/lib/libvm.a(vm_mrg.o) 427832738 29748 /usr/conf/lib/libvm.a(vm_sched.o) 4269329510 23592 /usr/conf/lib/libvm.a(vm_vhand.o) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: 886560061 73568 /usr/conf/lib/libvm.a(subr_mrg.o) 2537938876 85880 /usr/conf/lib/libvm.a(vfs_vm.o) 3045525490 19872 /usr/conf/lib/libvm.a(vm_arena_gc.o) 3583906595 41896 /usr/conf/lib/libvm.a(vm_devswap.o) 1418910138 25232 /usr/conf/lib/libvm.a(vm_fault.o) 2947659544 43296 /usr/conf/lib/libvm.a(vm_kalloc.o) 1807067910 56960 /usr/conf/lib/libvm.a(vm_mrg.o) 2325304355 76576 /usr/conf/lib/libvm.a(vm_sched.o) 2426870232 51560 /usr/conf/lib/libvm.a(vm_vhand.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_28695 PHKL_28405 PHKL_28121 PHKL_27825 PHKL_26938 PHKL_26893 PHKL_26549 PHKL_25304 PHKL_24566 PHKL_24538 PHKL_23908 PHKL_23445 PHKL_23425 Equivalent Patches: None Patch Package Size: 330 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_31239 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_31239.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_31239. 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_31239.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_31239.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_31239.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: PHKL_23908: There are three patches providing similar kernel preemption enhancements: PHKL_23908, PHKL_23944, PHKL_23946. Each of these may be useful in preventing a time critical process thread time-out. However, these patches, installed either individually or collectively, may not necessarily improve performance or response time for all processes as the process threads causing the delay may not be executing along these preemptible paths. Each of these patches is independent of the others; they may be installed separately or in any combination, and in any order. Each provides kernel preemption for a specific long running kernel path.