Patch Name: PHKL_28865 Patch Description: s700 10.20 VM read-ahead panic, buffer cache, paging Creation Date: 03/04/03 Post Date: 03/04/07 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: OS-Core.CORE-KRN Automatic Reboot?: Yes Status: General Release Critical: No (superseded patches were critical) PHKL_23173: PANIC PHKL_17714: HANG PHKL_17624: HANG Path Name: /hp-ux_patches/s700/10.X/PHKL_28865 Symptoms: PHKL_28865: (SR: 8606271932 CR: JAGae36110) After the system is up for more than 248 continuous days, paging performance decreases dramatically. PHKL_23173: ( SR: 8606168886 CR: JAGad38164 ) Customer will see a data-page-fault panic in pdprotget2_0(). A typical panic stack would look like this: panic report_trap_or_int_and_panic trap $call_trap pdprotget2_0 process_read_ahead_pages hdl_vfault vfault trap $call_trap ( SR: 8606177173 CR: JAGad46407 ) Customer will see a data-page-fault panic in pdprotget2_0(). A typical panic stack would look like this: panic report_trap_or_int_and_panic trap $call_trap pdprotget2_0 process_read_ahead_pages hdl_pfault pfault trap $call_trap PHKL_19755: ( SR: 8606104707 DTS: JAGab69485 ) Files removed from an NFS client would sometimes leave behind .nfsXXX files which would be unremovable until the next reboot. This problem only occurs on systems with more than 1GB of RAM. PHKL_18551: ( SR: 4701422873 DTS: JAGab11378 ) Systems that continuously write and truncate a large number of files could see CPU consumption increase over time for those buffer cache routines that traverse hash link-lists. PHKL_17714: ( SR: 1653286468 DTS: JAGaa44872 ) Processes may hang when accessing files in a VxFS file system due to a race condition on MP systems between VxFS and the buffer cache. PHKL_17624: ( SR: 5003443622 DTS: JAGaa43921 ) System appears to hang intermittently due to processes being deactivated by the scheduler. The symptom is particularly visible on Netscape servers or on systems running applications using large amount of mmap files. Patch PHKL_13155 which is supposed to address the exact problem is not enough to solve the deactivation. Defect Description: PHKL_28865: (SR: 8606271932 CR: JAGae36110) 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_23173: ( SR: 8606168886 CR: JAGad38164 ) Incorrect parameter passed to pdprotget() call. Resolution: Pass the updated virtual address instead of the starting address again and again. ( SR: 8606177173 CR: JAGad46407 ) process_read_ahead_pages() both in its forward and backward loops, does not correctly check for the presence of translation. Resolution: Check both for the existence of an address translation for the physical page, and make sure it is translated to our address. PHKL_19755: ( SR: 8606104707 DTS: JAGab69485 ) The buffer cache was inadvertently keeping a hold on vnodes which had the side effect of preventing unlinked files from going inactive, which for NFS would mean leaving .nfsXXX files around. Resolution: Buffer cache routines will no longer clear the vnode field of the buffer header during invalidation, thereby ensuring that the hold on the vnode will be released when the buffer is reused. PHKL_18551: ( SR: 4701422873 DTS: JAGab11378 ) Buffer cache routines in the kernel are gradually consuming more cpu time as buffer hash queues become longer. Resolution: This problem is resolved by ensuring buffers associated with unlinked (or truncated) files are re-used immediately ensuring they do not accumulate on any particular link-list. PHKL_17714: ( SR: 1653286468 DTS: JAGaa44872 ) When a new buffer is obtained via getnewbuf(), the identity may change. However, some processes may be sleeping waiting on the original buffer identity, and these never wake up. Resolution: The fix is to wakeup any process sleeping on a buffer returned by getnewbuf() when it changes the buffer identity. PHKL_17624: ( SR: 5003443622 DTS: JAGaa43921 ) The scheduler determines the system is thrashing based on the pageout rate. However, for systems with large amount of mmap files, syncing these files to disk is a normal operation which generates very high pageout rate that has nothing to do with thrashing due to lack of free memory. Resolution: A kernel variable is added to decouple user (system call) and kernel (vhand) initiated pageouts. Thrashing determination is based on the kernel pageout only. SR: 1653286468 4701422873 5003443622 8606104707 8606168886 8606177173 8606271932 Patch Files: /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) /usr/conf/lib/libhp-ux.a(vfs_bio.o) /usr/conf/lib/libhp-ux.a(vfs_vm.o) /usr/conf/lib/libhp-ux.a(vm_devswap.o) /usr/conf/lib/libhp-ux.a(vm_sched.o) /usr/conf/lib/libhp-ux.a(vm_swp.o) /usr/conf/lib/libhp-ux.a(vm_vhand.o) what(1) Output: /usr/conf/lib/libhp-ux.a(ufs_mchdep.o): ufs_mchdep.c $Date: 99/09/13 10:04:29 $ $Revision: 1 .18.98.10 $ PATCH_10.20 (PHKL_19755) /usr/conf/lib/libhp-ux.a(vfs_bio.o): vfs_bio.c $Date: 99/09/13 10:05:07 $ $Revision: 1.26 .98.32 $ PATCH_10.20 (PHKL_19755) /usr/conf/lib/libhp-ux.a(vfs_vm.o): vfs_vm.c $Date: 2001/01/17 16:25:47 $ $Revision: 1.1 7.98.20 $ PATCH_10.20 (PHKL_23173) /usr/conf/lib/libhp-ux.a(vm_devswap.o): vm_devswap.c $Date: 99/02/17 14:23:50 $ $Revision : 1.19.98.8 $ PATCH_10.20 (PHKL_17624) /usr/conf/lib/libhp-ux.a(vm_sched.o): vm_sched.c $Date: 99/02/17 14:24:58 $ $Revision: 1.58.98.13 $ PATCH_10.20 (PHKL_17624) /usr/conf/lib/libhp-ux.a(vm_swp.o): vm_swp.c $Date: 99/02/17 14:25:34 $ $Revision: 1. 49.98.4 $ PATCH_10.20 (PHKL_17624) /usr/conf/lib/libhp-ux.a(vm_vhand.o): vm_vhand.c $Date: 2003/04/03 14:01:19 $ $Revision : 1.20.98.9 $ PATCH_10.20 (PHKL_28865) cksum(1) Output: 3417064481 10420 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) 3784054785 29676 /usr/conf/lib/libhp-ux.a(vfs_bio.o) 3116338425 29896 /usr/conf/lib/libhp-ux.a(vfs_vm.o) 3031568726 15464 /usr/conf/lib/libhp-ux.a(vm_devswap.o) 4032129670 25200 /usr/conf/lib/libhp-ux.a(vm_sched.o) 1245976871 7848 /usr/conf/lib/libhp-ux.a(vm_swp.o) 1533704275 15064 /usr/conf/lib/libhp-ux.a(vm_vhand.o) Patch Conflicts: None Patch Dependencies: s700: 10.20: PHKL_16750 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_17624 PHKL_17714 PHKL_18551 PHKL_19755 PHKL_23173 Equivalent Patches: PHKL_28866: s800: 10.20 Patch Package Size: 200 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_28865 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_28865.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_28865. 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_28865.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_28865.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: This patch depends on base patch PHKL_16750. For successful installation, please ensure that PHKL_16750 is in the same depot with this patch, or PHKL_16750 is already installed.