Patch Name: PHKL_24388 Patch Description: s700 10.20 VxFS fsadm, bmap, performance cumulative patch Creation Date: 01/06/08 Post Date: 01/06/19 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: JournalFS.VXFS-BASE-KRN Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_24388: PANIC PHKL_18670: CORRUPTION PHKL_18026: PANIC Path Name: /hp-ux_patches/s700/10.X/PHKL_24388 Symptoms: PHKL_24388: (SR: 8606198944 CR: JAGad68133) A system may panic if it encounters a corrupted inode while accessing the VxFS filesystem. Stack of panic is given below. panic+0x10 report_trap_or_int_and_panic+0xe8 trap+0xa48 $RDB_trap_patch+0x20 vx_do_extfree+0x64 vx_extfree+0x3cc vx_trunc_typed+0x7b0 vx_trunc_typed+0x230 vx_trunc+0xc08 vx_iinactive+0x378 vx_inactive_list+0x4f0 vx_inactive_thread+0x70 vx_startdaemon+0xac vx_postinit+0x124 vx_sync+0x14 update+0x6c sync+0x20 syscall+0x1a4 $syscallrtn+0x0 PHKL_17520: SR: 4701406454 DTS: JAGaa42801 JFS file systems with large amounts of free space can get 'vx_nospace' (ENOSPC) errors while 'fsadm' is running a defragmentation (-e option). SR:1653244277 DTS: JAGaa01284 System becomes unresponsive while running a defragmentation of a JFS file system using the 'fsadm' command (-e option). When in this state the 'fsadm' process consumes more than 99 percent of the CPU. Performance returns when the PHKL_18670: A VxFS filesystem may become corrupted after upgrading from version 2 (V2) layout to V3/V4 layout. PHKL_18026: ( SR: 4701411561 CR: JAGaa46204 ) The following data page fault panic occurs when using a VxFS filesystem and a certain type of inode corruption is encountered: trap type 15, pcsq.pcoq = 0.2b7de4, isr.ior = 0.8 panic: (display==0xb800, flags==0x0) Data page fault The top of the stack trace looks like: panic+0x10 report_trap_or_int_and_panic+0xe8 trap+0xf84 $RDB_trap_patch+0x20 vx_trunc_typed+0x154 vx_trunc_typed+0x260 vx_trunc_typed+0x260 vx_trunc+0xc6c vx_inactive_remove+0x16c vx_inactive_now+0x2b0 vx_inactive+0x150 [...] Defect Description: PHKL_24388: (SR: 8606198944 CR: JAGad68133) When the extent is read from disk, all structural data in it is assumed to be correct and is not checked for validity. This may result in a panic when the data is corrupted on a disk Resolution: Code was added to validate the structural data in the extents as they are read from disk. PHKL_17520: SR: 4701406454 DTS: JAGaa42801 In some cases we try to allocate more space than is left in a given bitmap in 'vx_extsearchodd()'. This causes a false ENOSPC return. SR:1653244277 DTS: JAGaa01284 The arguments to the functions 'vx_extsearchodd()' and 'vx_extsearchanyodd()' were not searching the correct range in a bitmap in some cases. This would cause useless work to be done for each REORG ioctl, and would cause the ioctl system call to monopolize the CPU. PHKL_18670: When an inode ilist extent map grows beyond 2GB, it is converted from type ext4 to typed. If the inode contains indirect block pointers from a V2 VxFS layout, the inode will be corrupted. Resolution: If an attempt is made to make this conversion, return an error and do not corrupt the filesystem. PHKL_18026: ( SR: 4701411561 CR: JAGaa46204 ) An inode with a corrupted extent map could cause the system to panic. Resolution: When this corruption is detected, the inode is marked bad and an error is returned. This patch does not fix the cause of the corruption, which could be a faulty disk drive for instance, it only disables the inode to avoid a panic. SR: 1653244277 4701406454 4701411561 4701421388 8606198944 Patch Files: /usr/conf/lib/libvxfs_base.a(vx_alloc.o) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o) what(1) Output: /usr/conf/lib/libvxfs_base.a(vx_alloc.o): vx_alloc.c $Date: 2001/06/08 12:05:06 $ $Revision: 1 .5.98.17 $ PATCH_10.20 (PHKL_24388) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o): vx_bmaptyped.c $Date: 2001/06/08 12:06:37 $ $Revisio n: 1.2.98.22 $ PATCH_10.20 (PHKL_24388) cksum(1) Output: 2028106359 28352 /usr/conf/lib/libvxfs_base.a(vx_alloc.o) 2948732324 18688 /usr/conf/lib/ libvxfs_base.a(vx_bmaptyped.o) Patch Conflicts: None Patch Dependencies: s700: 10.20: PHKL_16750 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_17520 PHKL_18026 PHKL_18670 Equivalent Patches: PHKL_24013: s700: 11.00 s800: 11.00 PHKL_24389: s800: 10.20 Patch Package Size: 110 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_24388 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_24388.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_24388. 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_24388.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_24388.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.