Patch Name: PHKL_11321 Patch Description: s700 10.20 VxFS/JFS cumulative patch Creation Date: 97/06/13 Post Date: 97/06/17 Warning: 97/06/23 - This Critical Warning has been issued by HP. - This patch appears to have introduced an NFS-related problem. If the patch is installed on an NFS server, the NFS clients cannot run executables from JFS filesystems that are mounted from the server. - The problem has only been reported by one customer on the s800 and the problem is currently being investigated. - A new patch is expected by 97/06/27. Patch PHKL_11013 will be re-released until the replacement patch is available. - It is recommended that PHKL_11321 be removed from any NFS server that exports JFS filesystems. Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: JournalFS.VXFS-BASE-KRN Automatic Reboot?: Yes Status: General Superseded With Warnings Critical: Yes PHKL_11321: PANIC PHKL_11013: OTHER This problem leaves the file system disabled and unusable, and requires a system reboot to regain access to it. PHKL_7899: PANIC HANG OTHER The KI instrumentation fix does not fall into any of specified symptoms; the root setuid fix does not either. Path Name: /hp-ux_patches/s700/10.X/PHKL_11321 Symptoms: PHKL_11321: This patch fixes two JFS performance problems and one defect: 1) Upgrading from 10.10 to 10.20, customer experienced approximately 25% performance degradation in read operation under JFS. 2) Loading a program for a second and subsequent time takes much longer if the program is using shared libraries on JFS. 3) Occasional panic occurs when running an executable which attempts to pagein through vnode level, producing a stack: trap+0xf84 0.0xe21c4 0x6954.0x7ffe75b8 ... $RDB_trap_patch+0x20 0.0x22608 0x6954.0x7ffe75b8 ... lbcopy_fp_method1+0x58 0.0x222b98 0x6954.0x7ffe7108 ... privlbcopy+0x1c 0.0x222fc4 0x6954.0x7ffe70c8 ... uiomove+0x4f0 0.0xfabe8 0x6954.0x7ffe7008 ... vx_read1+0x26c 0.0xb9744 0x6954.0x7ffe6ec8 ... vx_rdwr+0x16c 0.0xc5164 0x6954.0x7ffe6e08 ... vn_rdwr+0x8c 0.0x107b04 0x6954.0x7ffe6d48 ... mfs_hpux_pagein+0x448 0.0x1cbb5c 0x6954.0x7ffe6c88 ... virtual_fault+0x9a0 0.0xf1fc8 0x6954.0x7ffe6b48 ... vfault+0x104 0.0xf281c 0x6954.0x7ffe6ac8 ... trap+0x129c and the message: trap type 15, pcsq.pcoq = 0.222b98, isr.ior = 18e.4179000 savestate ptr = 0x7ffe7108, savestate return ptr = 0x222fc4 9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996 panic: (display==0xbd00, flags==0x0) Data page fault PHKL_11013: The vxupgrade command, used to convert a JFS version 2 file system to a version 3, can give an I/O error on execution. This causes the file system to be marked as unavailable, and a full fsck to be run. PHKL_7899: KI queuedone, enqueue and queuestart traces on JFS may contain NULL values in the b_apid and b_upid fields. With a system running a heavy load using JFS on LVM, the following panic may occur: "lv_syncx: returning error: 5" Systems running JFS may hang due to a deadlock problem. The setuid bit will be removed on a JFS file when the file is edited or text has been appended to it when run as root. Defect Description: PHKL_11321: 1) In vx_read1(), some unnecessary conditions prevented vx_read_ahead() to be called for large reads. The fix is to remove these extra checkings to allow read_ahead to be performed. ) When we are done with a shared library, pageout routine is called to flush the changes to disk. The way vx_pageout() works is that it invalidates the cached copy of the file then calls vx_do_pageout() to figure out the MMF pages need to be written and write them. A more efficient way of doing this is to invalidate and flush buffers in the buffer cache only if there are and may have been dirty pages. 3) When reading a sparse portion of a file on JFS, vx_read1() calls uiomove() to copy a page of zeroes to the target buffer. If the UIOSEG_PAGEIN flag is set in the uio structure, uiomove() by default will copy vx_zeropage from the buffer cache. Since vx_zeropage is not in the buffer cache's space, but is in space 0, this references an invalid address and triggers a panic. The fix is to replace uiomove() with long_uiomove() which allows the correct space id to be specified. PHKL_11013: During vxupgrade, it is possible for the allocation unit length to change; thus the same inode located in the same block will change allocation unit numbers. There was a check in vx_iremount() to verify that the allocation unit numbers matched, and returned ENOSPC if not. This was the root cause of the problem which was easily reproducible: o Create a version 2 JFS file system on a 1GB volume: mkfs -Fvxfs -oversion=2 /dev/vg01/onegigvol o mount it: mount -Fvxfs /dev/vg01/onegigvol /tmp_mnt o fill up the file system halfway: prealloc /tmp_mnt/bigfile 500000000 o copy some files into the filesystem: cp -r /usr /tmp_mnt & o wait a few minutes and execute the vxupgrade command: vxupgrade -n 3 /tmp_mnt PHKL_7899: KI problem: The JFS buffer allocation and IO paths were not fully instrumented causing buffer header b_apid and b_upid fields not to be updated consistently. The resulting KI queuedone, enqueue, and queuestart traces contain NULL values in these fields. A panic can occur with JFS on LVM due to an inode being able to change identity before it and its dirty pages are flushed to disk in vx_freeze_iflush(). System can deadlock due to a locking order problem in JFS when vx_fast_read() is called from VOP_BREAD. When a JFS file is created with the SETUID flag, the setuid bit is removed when the file has been edited with vi or text has been appended to it; this should only be the case when the writer is not root. SR: 1653166066 4701329292 4701329300 4701329441 4701329441 4701355560 5003368290 Patch Files: /usr/conf/lib/libvxfs_base.a(vx_bio.o) /usr/conf/lib/libvxfs_base.a(vx_iflush.o) /usr/conf/lib/libvxfs_base.a(vx_inode.o) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) /usr/conf/lib/libvxfs_base.a(vx_vm.o) what(1) Output: /usr/conf/lib/libvxfs_base.a(vx_bio.o): vx_bio.c $Date: 96/07/09 10:55:03 $ $Revision: 1.7.9 8.9 $ PATCH_10.20 (PHKL_7899) /usr/conf/lib/libvxfs_base.a(vx_iflush.o): vx_iflush.c $Date: 97/05/08 11:08:49 $ $Revision: 1. 6.98.13 $ PATCH_10.20 (PHKL_11013) /usr/conf/lib/libvxfs_base.a(vx_inode.o): vx_inode.c $Date: 96/07/09 10:56:32 $ $Revision: 1.7 .98.18 $ PATCH_10.20 (PHKL_7899) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o): vx_rdwri.c $Date: 97/06/12 16:11:29 $ $Revision: 1.7 .98.22 $ PATCH_10.20 (PHKL_11321) /usr/conf/lib/libvxfs_base.a(vx_vm.o): vx_vm.c $Date: 97/06/09 16:47:28 $ $Revision: 1.7.98 .14 $ PATCH_10.20 (PHKL_11321) cksum(1) Output: 3798845514 10476 /usr/conf/lib/libvxfs_base.a(vx_bio.o) 36074079 29780 /usr/conf/lib/libvxfs_base.a(vx_iflush.o) 1192397402 44784 /usr/conf/lib/libvxfs_base.a(vx_inode.o) 2089320954 35412 /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) 3906324615 11916 /usr/conf/lib/libvxfs_base.a(vx_vm.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_7899 PHKL_11013 Equivalent Patches: PHKL_11322: 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_11321 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_11321.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_11321.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_11321. 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_11321.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_11321.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None