Patch Name: PHKL_18800 Patch Description: s700_800 11.00 Cumulative JFS patch - panic:dirty inval Creation Date: 99/06/21 Post Date: 99/06/25 Hardware Platforms - OS Releases: s700: 11.00 s800: 11.00 Products: N/A Filesets: JournalFS.VXFS-BASE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP JournalFS.VXFS-BASE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_18800: PANIC PHKL_16023: CORRUPTION PHKL_13539: PANIC Category Tags: defect_repair general_release critical panic corruption Path Name: /hp-ux_patches/s700_800/11.X/PHKL_18800 Symptoms: PHKL_18800: SR: 4701413864 CR: JAGaa52714 The system panics with a 'Dirty Inval' panic message when unmounting a large ( greater than 128 Gigabyte ) filesystem. stack trace: panic+0x10 brelse+0x230 vx_brelse_bp+0x34 vx_brelse_noflush+0x34 vx_brelse+0x3c vx_brelse_stale+0x2c vx_blkinval+0x184 vx_freeze_level+0x114 vx_freeze+0x10 vx_detach_fset+0x2b4 vx_unmount+0x88 umount_vfs+0x5c umount_root+0x20 umount+0x98 syscall+0x1a4 $syscallrtn+0x0 PHKL_16023: The following error may appear in syslog: vxfs: mesg 048: vx_mapbad - file system extent allocation unit state bitmap number 0 marked bad After the error, filesystem prematurely fills up, causing the filesystem to be unmounted and a full fsck run against it. PHKL_14766: The previous patch has been recut to include compile-based performance tuning. There is no functional change in this patch. PHKL_13539: Panic: data page fault in vx_map_delayflush(). The stack trace looked like: trap sys_trap vx_map_delayflush vx_mapbad vx_extmapupd vx_emtran_process vx_ldonemap vx_map_delaydone vx_getmap vx_getemap vx_extfind vx_searchau vx_extentalloc vx_bmap_ext4 vx_bmap vx_growfile vx_doreserve vx_extset vx_setext vx_uioctl ioctl Defect Description: PHKL_18800: SR: 4701413864 CR: JAGaa52714 vx_smap_flush() calls vx_getsmap() passing the map number as the second parameter while vx_getsmap() expects the allocation unit (AU) number. This causes vx_smap_flush() to NOT wait on the B_DELWRI buffer for this map which will later cause the panic. Resolution: Pass in an Allocation Unit number rather than a map number to vx_getsmap() from vx_smap_flush(). PHKL_16023: In vx_clonemap() we copied the extent map (or smap) bitmaps before the vx_tranflush() that would cause delayed extent frees to be processed. Once the log was flushed, the extents were marked as free and then the clone was written. When the clone write completed, the transaction could be logged as done. If logged as done, and a subsequent system crash occurred before the map with the extents actually marked as free was flushed to disk, then replay would not replay the extent (or AU) free operation the vx_tranflush() that would cause delayed extent frees to be frees to be processed. Once the log was flushed, the extents were marked as free and then the clone was written. When the clone write completed, the transaction could be logged as done. If logged as done, and a subsequent system crash occurred before the map with the extents actually marked as free was flushed to disk, then the replay would not replay the exten (or AU) free operation. PHKL_14766: None PHKL_13539: The panic occurs when the previous mlink was freed while the code was still working on it. The mlink was being freed in the wrong place. SR: 1653265041 4701413864 5003387019 4701377671 4701390245 Patch Files: JournalFS.VXFS-BASE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP: /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o) JournalFS.VXFS-BASE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP: /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o) what(1) Output: JournalFS.VXFS-BASE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP: /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o): vx_bitmaps.c $Date: 1999/06/09 11:15:48 $Revision: r 11ros/4 PATCH_11.00 (PHKL_18800) JournalFS.VXFS-BASE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP: /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o): vx_bitmaps.c $Date: 1999/06/09 11:15:48 $Revision: r 11ros/4 PATCH_11.00 (PHKL_18800) cksum(1) Output: JournalFS.VXFS-BASE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP: 2278646361 13028 /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o) JournalFS.VXFS-BASE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP: 2175722006 31192 /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_16023 PHKL_14766 PHKL_13539 Equivalent Patches: PHKL_17518: s700: 10.20 PHKL_17519: s800: 10.20 Patch Package Size: 70 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_18800 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_18800.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_18800. If you do not wish to retain a copy of the original software, use the patch_save_files option: swinstall -x autoreboot=true -x patch_match_target=true \ -x patch_save_files=false -s /tmp/PHKL_18800.depot 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_18800.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_18800.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_18800.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None