Patch Name: PHKL_30927 Patch Description: s700_800 11.00 mmap() perf improvement; locking order;mount Creation Date: 04/08/09 Post Date: 04/08/25 Hardware Platforms - OS Releases: s700: 11.00 s800: 11.00 Products: JFS 3.3; Filesets: JFS.JFS-BASE2-KRN,fr=3.3,fa=HP-UX_B.11.00_32,v=HP JFS.JFS-BASE2-KRN,fr=3.3,fa=HP-UX_B.11.00_64,v=HP Automatic Reboot?: Yes Status: General Release Critical: No (superseded patches were critical) PHKL_30764: PANIC Incorrect locking order for releasing spinlocks. PHKL_28602: HANG PHKL_21499: HANG PHKL_27212: HANG PHKL_25021: PANIC HANG PHKL_21774: HANG PHKL_23773: HANG PHKL_23192: PANIC HANG CORRUPTION PHKL_22121: HANG PHKL_21063: PANIC PHKL_21181: PANIC PHKL_21765: HANG PHKL_21077: MEMORY_LEAK CORRUPTION Category Tags: defect_repair enhancement general_release critical panic halts_system corruption memory_leak Path Name: /hp-ux_patches/s700_800/11.X/PHKL_30927 Symptoms: PHKL_30927: ( SR:8606345000 CR:JAGaf05850 ) VxFS File Systems written on 8K sector sized devices cannot be mounted. #newfs -F vxfs /dev/rdsk/c5t9d0 #mount -F vxfs /dev/dsk/c5t9d0 /tmp_mnt vxfs mount: disk image is incompatible with this system PHKL_30764: ( SR:8606349608 CR:JAGaf10425 ) The customer can come across the following 2 scenarios. 1. System might panic with spinlock/deadlock due to the wrong locking order. The stack trace might be as below. 0) panic_save_register_state+0x144 1) panic+0x14 2) too_much_time+0x2e0 3) wait_for_lock+0x1f4 4) sl_retry+0x1c 5) unselect+0x1c 6) invoke_callouts_for_self+0xc0 7) sw_service+0xb0 8) mp_ext_interrupt+0x150 9) ihandler+0x904 10) spinunlock+0x30 11) vx_iget+0x7c0 12) vx_dirlook+0x3ec 13) vx_lookup+0x10c 14) locallookuppn+0xd4 15) lookuppn+0x104 16) lookupname+0x40 17) stat1+0x38 18) lstat+0x20 19) syscall+0x6f8 20) syscallinit+0x54c 2. The processor remains uninterruptible till a context switch occurs. PHKL_28602: ( SR:8606280077 CR:JAGae44052 ) Filesystem commands that freeze filesystems (such as fsadm resize) may deadlock with processes that use F_WRLCK ioctl() to place locks on files in the filesystem. A stack trace of the hung command will look similar to the following: _sleep+0x210 sleep_spinunlock+0x70 vx_event_wait+0xc0 vx_delay2+0x64 vx_freeze_level+0x278 vx_freeze+0x3c vx_resize+0x120 vx_aioctl_full+0xf8 vx_aioctl_common+0x3b4 vx_aioctl+0xbc vx_ioctl+0xc0 vno_ioctl+0x98 ioctl+0x120 syscall+0x750 $syscallrtn+0x0 Meanwhile, other threads will be sleeping with a stack trace similar to the following: _swtch+0xc4 _sleep+0x4cc locked+0xd84 vx_rdwr+0x234 vno_rw+0x80 read+0x10c syscall+0x204 $syscallrtn+0x0 _sleep+0x210 sleep_spinunlock+0x70 vx_event_wait+0xc0 vx_delay2+0x64 vx_active_common_flush+0xb8 vx_lockctl+0x3c fcntl+0x2d4 syscall+0x750 $syscallrtn+0x0 PHKL_27503: ( SR:8606249539 CR:JAGae15929 ) Enhancement: Improve performance of VxFS processing of mmap(2)ed files. PHKL_21499: ( SR: 8606129559 DTS: JAGac87894 ) VxFS may hang if more than one process writes to a memory mapped file. To reproduce the problem, map a file to memory and keep writing to the pages. Start two other processes which write to this file. VxFS hangs. PHKL_27212: ( SR:8606236411 CR:JAGae05468 ) The system will hang when starting the Veritas HSM Migration software due to a deadlock condition in the DMAPI (see vxenablef(1M)). ( SR:8606236403 CR:JAGae05460 ) Attempting to mount the same filesystem on two different directories may leave the corresponding Logical Volume Manager (LVM) volume group in a state in which it cannot be deactivated, even though its logical volumes are not in use. The following steps would cause the problem to be seen: # mount /dev/vg100/lvol1 /tmp_mnt # mount /dev/vg100/lvol1 /tmp_mnt2 vxfs mount: /dev/vg100/lvol1 is already mounted, /tmp_mnt2 is busy, or allowable number of mount points exceeded # umount /tmp_mnt # vgchange -a n vg100 vgchange: Couldn't deactivate volume group "vg100": Device busy PHKL_26470: ( SR:8606223056 CR:JAGad92160 ) After a file has been created with 000 permissions in a directory with default ACLs on a VxFS filesystem using the version 4 layout, all files created in that directory will be created with 000 permissions until the filesystem that directory is in is unmounted and remounted, or the system is rebooted. The file which initiated this condition need not have 000 permissions at the end of the process that started its creation. For example, if a file is copied into this directory using cp(1), this condition will be triggered. cp(1) first creates a file with 000 permissions, and then sets the permissions as appropriate, using the permissions of the copied file combined with the user's umask and the parent directory's permission mask, which is based upon the directory's default ACLs. Following this, some commands such as cp(1) and mv(1) will behave as documented since they explicitly set the permissions of their target files, but others, such as touch(1) will create files with 000 permissions since they do not explicitly set the permissions of their targets, but instead only use the user's umask and the parent directory's mask. PHKL_26670: ( SR:8606249754 CR:JAGae16140 ) PHKL_25021 introduced behavior that can cause VxFS 3.3 file system performance problems when sequential I/O requests of less than 64KB are performed. This behavior can affect backup utilities and other applications that perform sequential I/O accesses to the file system. PHKL_25021: ( SR:8606202113 CR:JAGad71287 ) VxFS 3.3 may hang a 64 bit system by zeroing out the interrupt mask (cr15). ( SR:8606196201 CR:JAGad65404 ) Data Page Fault panic while using Hyperfabric network. The stack trace may looks as follows: panic+0x14 report_trap_or_int_and_panic+0x84 interrupt+0x1d4 $ihndlr_rtn+0x0 sendfile_rele+0x304 freeb_pullupmsg+0x238 freeb+0x7b4 CLIC_SEND+0x1ecc clicdlpi_wput+0x140 putnext+0xcc ip_wput_ire+0x454 ip_wput+0x470 putnext+0xcc tcp_timer+0x334 tcp_wput+0x828 puthere+0x148 mi_timeout_exec+0x294 sw_service+0xb0 mp_ext_interrupt+0x150 ivti_patch_to_nop3+0x0 idle+0x81c ( SR:8606200313 CR:JAGad69497 ) Poor performance with VxFS 3.3 compared to VxFS 3.1 while multiple threads/processes read from a file simultaneously. ( SR:8606203915 CR:JAGad73093 ) PHKL_23192 introduced behavior that can cause multiple threads to deadlock on a specific file. The behavior only occurs if the file is being flushed at the same time it is being remotely accessed, such as via NFS or other networking access. The behavior could eventually lead to hung processes and subsystems, such as NFS. This problem happens only if VxFS 3.3 fancy read ahead is turned on. Stacks of deadlocked threads may look like as shown below: _sleep+0x1fc sleep_spinunlock+0x74 vx_event_wait+0xf0 vx_delay2+0x64 vx_vnode_flush+0x3bc vx_do_putpage+0x11c vx_idelxwri_flush+0xf8 vx_delxwri_flush+0x1dc vx_worklist_process+0x1b0 vx_worklist_thread+0x4c kthread_daemon_startup+0x24 _sleep+0x1fc vx_rwsleep_lock+0x1f4 vx_iglock2+0x78 vx_iglock+0x28 vx_fancy_read_ahead+0x1c4 vx_read1+0x980 vx_vn_bread+0xfc rfs_read+0x158 rfsexp_dispatch+0x210 svc_getreq+0x13c svc_run+0x1e0 nfsexp_svc+0x4d4 nfs_stub_svc+0xa4 coerce_scall_args+0xcc syscall+0x6f8 syscallinit+0x54c ( SR:8606181938 CR:JAGad51154 ) Data Page Fault in allocbuf1(). Stack of the panic thread may look like: allocbuf1+0xd0 allocbuf+0x30 vx_allocbuf+0x30 vx_async_shorten+0xc30 vx_fsync+0x120 rfs3_commit+0x3a0 rfsexp_dispatch+0x810 svc_getreq+0x500 svc_run+0x930 nfsexp_svc+0x860 nfs_stub_svc+0x390 coerce_scall_args+0x570 syscall+0xe70 PHKL_21774: ( SR: 8606139611 CR: JAGad08922 ) 1. Executing an FSO (File Sharing Option) refresh of a file causes subsequent executions of more(1) on that file to hang. Any read-only node opening a refreshed file may experience similar failures (hangs). 2. A filesystem with FSO enabled may hang while flushing (writing memory contents to disk). If other filesystems interact with this filesystem, the entire system may hang. To recover the filesystem, the system must be rebooted. Both of these problems are specific to FSO on top of VxFS3.3. Without FSO installed and enabled, this patch will have no impact on the system (the components delivered in this patch, while part of VxFS3.3, are currently used only by FSO). PHKL_23773: ( SR: 8606178276 CR: JAGad49578 ) Backup utilities like fbackup take longer time to finish when JFS 3.3 fancy read ahead is enabled. ( SR: 8606179211 CR: JAGad48435 ) sar -v and glance show ninode usage(count of active inodes on the system) as 0. ( SR: 8606178276 CR: JAGad47503 ) System hang caused by someone going through the buffer pool to flush out dirty buffers. The buffer is marked dirty but also marked busy, and the process or thread decide to wait for it. Because of this, ServiceGuard commands like cmapplyconf, cmcheckconf. hang. A typical stack of the hung thread is given below. _swtch+0x138 real_sleep+0x234 _sleep+0x14 syncip_flush_cache+0x190 vx_flushdev+0x10 vx_fsync+0x1cc spec_fsync+0x17c spec_inactive+0x14 vn_rele+0x1e8 vno_close+0x68 closef+0x68 close+0x30 syscall+0x75c $syscallrtn+0x0 PHKL_23254: (SR: 8606177460 DTS: JAGad46692) Poor application performance with VxFS 3.3 compared to VxFS 3.1, when the application does a lot of reads from random offsets of a file. PHKL_23192: ( SR: 8606175336 CR: JAGad44578 ) Poor system performance with VxFS vs HFS, when applications read backward and forward through a file which cannot be fully contained in the buffer cache. ( SR: 8606171316 CR: JAGad40579 ) System may panic or hang during heavy VxFS filesystem use. Due to the nature of these problems, a panic/hang could occur in any VxFS ('vx_') routine. There is no specific stack trace for reference. ( SR: 8606168320 CR: JAGad37601 ) close(2) may cause data corruption by truncating VxFS files. ( SR: 8606162599 CR: JAGad31915 ) VxFS filesystems on disc devices with block size 4096 bytes could not be mounted. ( SR: 8606152097 CR: JAGad21436 ) While umounting a VxFS snapshot filesystem, the filesystem may hang. A reboot would be required to reaccess the filesystem. PHKL_22121: ( SR: 8606135462 CR: JAGad04596 ) VxFS 3.3 write(2) may return incorrect error value 61441 to applications on error. ( SR: 8606138051 CR: JAGad07239 ) System hangs due to VxFS 3.3 deadlock during direct I/O. If a system memory core dump is taken once the system is hung, the stack trace will be similar to the following: _swtch+0x1e4 1c_1d20_cl_real_sleep+0x1464 _sleep_one+0x16c vx_rwsleep_lock+0x108 vx_iglock2+0x58 vx_iglock+0x28 vx_pagein+0x1a4 virtual_fault+0x7d8 vfault+0x274 trap+0x12f0 $RDB_trap_patch+0x30 lacc+0xdc vx_dio_iovec+0xd0 vx_dio_rdwri+0x278 vx_write1+0x654 vx_rdwr+0x1c0 vno_rw+0xbc rwuio+0x154 aio_rw_child_thread+0x204 kthread_daemon_startup+0x2c kthread_daemon_startup+0x0 PHKL_21773: ( SR: 8606139352 CR: JAGad08645 ) VxFS 3.3 direct I/O returns 61441 to applications on error. PHKL_21063: ( SR: 8606114160 CR: JAGac23138 ) A panic under heavy load on a multi-processor machine. The stack trace might look like: panic+0x14 panic+0x48 report_trap_or_int_and_panic+0x7c trap+0x119c nokgdb+0x8 vx_fancyra_predict+0x10 vx_read1+0x2a8 vx_rdwr_0x4c0 vn_rdwr+0x84 exec_file_read+0x40 get_aout_info+0xc0 load_dld+0x10c hdl_load_process+0x300 getxfile+0x33c execve+0x1bec syscall+0x5fc $syscallrtn PHKL_21181: ( SR: 8606129265 DTS: JAGac86811 ) Data Page Fault in VxFS 3.3 vx_memunlock() while using direct IO. The stack of the panic thread is given below. panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 vx_memunlock+0x80 vx_dio_iovec+0x74c vx_dio_rdwri+0x194 vx_write1+0xc58 vx_rdwr+0x3dc vno_rw+0x84 rwuio+0xe8 aio_rw_child_thread+0x80 kthread_daemon_startup+0x24 kthread_daemon_startup+0x0 vx_memunlock+0x20 PHKL_21938: ( SR: 8606142678 DTS: JAGad12033 ) Rcp is slow when file size exceeds 2GB. PHKL_21765: ( SR: 8606137227 DTS: JAGad06345 ) Unmounting VxFS filesystems may hang. PHKL_21077: ( SR: 8606114161 DTS: JAGac23139 ) System calls like open and stat cause memory leak, while accessing VxFS 3.3 file system. ( SR: 8606113817 DTS: JAGac12337 ) ftruncate() corrupts the last page in a memory mapped file. Defect Description: PHKL_30927: ( SR:8606345000 CR:JAGaf05850 ) mount operation on a VxFS filesystem fails if the sector size of the device is greater than the page size of the system(4K). Resolution: Removed this restriction as read/write code can support a minimum disk I/O, which is larger than the page size. PHKL_30764: ( SR:8606349608 CR:JAGaf10425 ) With the current locking order the processor can be interrupted while it still holds a spinlock. This is due to the way the spinlock was acquired. When the processor receives an interrupt the interrupt handler tries to acquire a lock owned by another processor. In this case the other processor is waiting for a lock held by this processor. Thus a deadlock occurs which will lead to a panic. If the processor is not interrupted and it releases the spinlock the eiem will remain set to spl6 till a context switch occurs. During this time the processor will remain uninterruptible. Resolution: The order of releasing the 2 spinlocks was reversed to fix the defect. PHKL_28602: ( SR:8606280077 CR:JAGae44052 ) A thread trying to read a file is allowed to sleep waiting for the read/write lock owned by another thread while the filesystem active count is incremented. The hang occurs when another thread tries to freeze the filesystem before the read/write lock can be released, and hangs in vx_freeze_level(). When the thread tries to release the read/write lock, it hangs in vx_active_common_flush() due to the pending freeze. Resolution: The active count is now decremented before calling locked() and sleeping on the read/write lock. Once the lock is obtained, the active count is incremented again. PHKL_27503: ( SR:8606249539 CR:JAGae15929 ) VxFS handles faults on memory mapped pages one at a time and does synchronous writes to the intent log for each one. Resolution: VxFS will read ahead up to 64 pages when processing a fault on a memory mapped file and the associated intent log processing will always be asynchronous. PHKL_21499: ( SR: 8606129559 DTS: JAGac87894 ) If more than one process write to a memory mapped file, a deadlock may occur between inode locks and buffer cache, because of the incorrect ordering of the locks. Resolution: Deadlock is avoided by returning VX_ERETRY if the buffer is busy, instead of waiting for it. PHKL_27212: ( SR:8606236411 CR:JAGae05468 ) The DMAPI code holds the inode's read-write lock in exclusive mode. Another thread then tries to acquire the lock in shared mode for initializing ACL counts of an inode. This causes the deadlock. Resolution: The code is changed so that the difference in locking methods is expected so that deadlock does not occur. ( SR:8606236403 CR:JAGae05460 ) After the mount of a logical volume failed because the volume was already in use (mounted), the volume group device was left open as a result of the failed mount. This prevents the subsequent deactivation of the volume from completing successfully. Resolution: The error path now makes sure that the device is appropriately closed. PHKL_26470: ( SR:8606223056 CR:JAGad92160 ) The mode of a newly created file on a VxFS filesystem using the version 4 layout (see vxupgrade(1M)) is determined by the mode passed into open(2) or creat(2) combined with the user's umask and the modemask of a directory, determined by its default ACLs. When default ACLs exist, the modemask of the directory would be set to the mode passed into open(2) or creat(2). From the time when a file is created with mode 000 on, all subsequently created files in that directory with default ACLs would be given 000 permissions. The permissions of affected files can be corrected with chmod(1). Resolution: The modemasks of directories are no longer affected by the modes of created files. PHKL_26670: ( SR:8606249754 CR:JAGae16140 ) The readahead algorithm was incorrectly using max_buf_data_size (default 8Kb) to calculate the readahead size instead of read_pref_io (default 64kb), which resulted in a smaller readahead size. Resolution: Use read_pref_io to calculate the readahead size. PHKL_25021: ( SR:8606202113 CR:JAGad71287 ) VxFS 3.3 was using a wrong data type (unsigned int) with spinlock functions. Spinlock functions use "unsigned long". Resolution: Use the correct data type (unsigned long) with spinlock functions. ( SR:8606196201 CR:JAGad65404 ) VxFS may free a vnode while a buffer associated with that vnode is in use in sendfile(2). Later when the sendfile code accesses the vnode through the buffer, the system panics. Resolution: Set up a dummy vnode which is not freed and use that vnode for buffers passed to sendfile(2) so that sendfile(2) code will always be accessing a valid vnode. ( SR:8606200313 CR:JAGad69497 ) 1. VxFS 3.3 read ahead code relies on the unexpected read (buffer cache miss) count to determine if there is any pressure on buffer cache. If there is pressure on buffer cache, the amount of read ahead performed is reduced. If the read ahead performed is less than the size of the read size, there will be unexpected reads. This turns out into a self fulfilling prophecy and read ahead is completely turned off causing each read to read the data from the disk synchronously degrading performance. 2. VxFS 3.3 uses the vxtunefs(1M) tunable "read_pref_io" to calculate the intial and maximum read ahead region length. But the read sizes could vary and this tunable may not trigger enough read ahead for different read sizes. Resolution: 1. Use the current read request size as the floor for the read ahead region length. 2. Use the current read request size times the vxtunefs(1M) "read_nstream" as the ceiling for the read ahead region length. ( SR:8606203915 CR:JAGad73093 ) VxFS 3.3 read code was acquiring two locks in the wrong order causing deadlock. Resolution: VxFS 3.3 read code is rewritten eliminating the need to acquire the locks in the wrong order. ( SR:8606181938 CR:JAGad51154 ) allocbuf1() expects a non-zero value as its second argument, but VxFS was not always passing a non-zero value. Resolution: Make sure that a non-zero value is always passed as the second argument to allocbuf1() from VxFS code. PHKL_21774: ( SR: 8606139611 CR: JAGad08922 ) 1) The vnode counter was set incorrectly to 0, after which another thread was waiting for the value to go to 1 forever. Resolution: Do not set the vnode counter to 0 if the current value is 1 for VxFS3.3. 2) The FSO flushing function tries to incorrectly reacquire a lock which it already holds, causing the FSO filesystem to hang. Resolution: The FSO flushing function should not try to acquire the lock. PHKL_23773: ( SR: 8606178276 CR: JAGad49578 ) VxFS fancy read ahead feature degrades read performance when multiple process/threads read from a file simultaneously. Because the VxFS fancy read ahead feature was designed to handle only one reader for a file at a time, when there are multiple readers for a file, its read ahead pattern matching algorithm fails. This results in a lot of unnecessary I/Os. Resolution: When there are multiple readers to a file, disable fancy read feature and do sequential read ahead instead. ( SR: 8606179211 CR: JAGad48435 ) A function was decrementing the number of active inode counts instead of incrementing when inodes become active. Resolution: Increment active inode count when inodes become active. ( SR: 8606178276 CR: JAGad47503 ) Under some corner cases, some VxFS meta buffers(map buffers) will be left in a busy and dirty state. This leads to hang any process which is directly or indirectly doing a buffer cache flush. Resolution: Make sure the VxFS meta buffers are flushed before doing a buffer cache flush. PHKL_23254: (SR: 8606177460 DTS: JAGad46692) A sanity check at the wrong place in a function disabled read ahead for random reads to a file. Resolution: Move the sanity check to the correct place in the function so that some read ahead could be done for random reads also. PHKL_23192: ( SR: 8606175336 CR: JAGad44578 ) An incorrect sanity check in the VxFS read path turned off both normal read ahead and fancy read ahead when the fancy read ahead was enabled on the system. This caused large I/O wait times for each read. Resolution: Corrected the logic error in the sanity check code such that fancy read ahead is used when enabled. ( SR: 8606171316 CR: JAGad40579 ) Some routines processing VxFS inodes did not follow the locking rules correctly, causing race conditions during heavy stress to the inode cache which resulted in system hangs or panics. Resolution: Enforced correct use of the locking protocol in VxFS icache functions. ( SR: 8606168320 CR: JAGad37601 ) While closing (close(2)) a file, VxFS tried to free up extra space (extents) allocated to the file. While doing this, it incorrectly modified the actual file size, causing data loss. Resolution: Corrected logic to prevent modification of file size while freeing extra extents. ( SR: 8606162599 CR: JAGad31915 ) VxFS was not calculating the disc block size correctly. This prevented filesystems on discs with block size of 4096 bytes from being mounted. Resolution: Using a different function (from LVM) to read the correct disc block size. ( SR: 8606152097 CR: JAGad21436 ) Due to a race condition between two snapshot mounts, a lock on the file system may never get released. Resolution: Make sure that the filesystem lock is released in all cases. PHKL_22121: ( SR: 8606135462 CR: JAGad04596 ) VxFS 3.3 write() was returning an internal error value VX_ERETRY(61441) to applications on certain conditions. Resolution: Reset error = 0 in VxFS 3.3 write function so that internal errors won't be returned to applications. ( SR: 8606138051 CR: JAGad07239 ) During direct I/O VxFS 3.3 was holding a lock which was not required. It may cause a deadlock if a page fault occurs while holding the lock, since this lock is required while resolving the page fault. VxFS does not prevent direct I/O on memory mapped files. Resolution: Remove the unnecessary locks during direct I/O and skip drect I/O if the file is memory mapped. PHKL_21773: ( SR: 8606139352 CR: JAGad08645 ) Direct I/O was returning an internal error VX_ERETRY(61441) to applications on certain conditions. Resolution: If direct I/O fails with VX_ERETRY, continue with normal I/O. PHKL_21063: ( SR: 8606114160 CR: JAGac23138 ) This is caused by checking a pointer for NON-NULL then acquiring the lock that protects the pointer and then using the pointer without re-checking it. While acquiring the lock, the pointer could have been freed. Resolution: Re-check the pointer after acquiring the lock. PHKL_21181: ( SR: 8606129265 DTS: JAGac86811 ) vx_memlock() sets length of actual memory locked incorrectly if it could not lock the requested length of memory. Resolution: mp->m_len is set correctly in vx_memlock(). PHKL_21938: ( SR: 8606142678 DTS: JAGad12033 ) When the file size is greater than 2GB, blocks of file are read twice since the first read is invoked with wrong flags and fails. Resolution: Use the correct flags for the first read. PHKL_21765: ( SR: 8606137227 DTS: JAGad06345 ) Empty buffers returned by vx_vn_bread() are not freed by sendfile_rele() because of the B_BUSY flag set by vx_geteblk(), which causes unmount to loop waiting for the filesystem to become inactive. Resolution: Unset the B_BUSY flag of the buffers in vx_vn_brelse(). PHKL_21077: ( SR: 8606114161 DTS: JAGac23139 ) vx_real_readdir() called by vx_readdir() allocates memory which is not freed always, causing memory leak. Resolution: Removed the unnecessary VX_ZALLOC() call from vx_real_readdir(). ( SR: 8606113817 DTS: JAGac12337 ) There was an error in calculating the page offset in vx_setattr(). Resolution: Corrected the expression calculating the page offset. Enhancement: No (superseded patches contained enhancements) PHKL_27503: Improve performance of VxFS processing of mmap(2)ed files. SR: 8606113817 8606114160 8606114161 8606129265 8606129559 8606135462 8606137227 8606138051 8606139352 8606139611 8606142678 8606152097 8606162599 8606168320 8606171316 8606175336 8606177460 8606178276 8606179211 8606180357 8606181938 8606196201 8606200313 8606202113 8606203915 8606223056 8606236403 8606236411 8606249539 8606249754 8606280077 8606345000 8606349608 Patch Files: JFS.JFS-BASE2-KRN,fr=3.3,fa=HP-UX_B.11.00_32,v=HP: /usr/conf/lib/libvxfs.a(vx33_bio1.o) /usr/conf/lib/libvxfs.a(vx33_iflush.o) /usr/conf/lib/libvxfs.a(vx33_inode.o) /usr/conf/lib/libvxfs.a(vx33_kdmi.o) /usr/conf/lib/libvxfs.a(vx33_mount.o) /usr/conf/lib/libvxfs.a(vx33_rdwri.o) /usr/conf/lib/libvxfs.a(vx33_vm.o) /usr/conf/lib/libvxfs.a(vx33_vnops.o) /usr/conf/lib/libvxfs.a(vx_acl.o) /usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o) /usr/conf/lib/libvxfs.a(vx_machdep.o) JFS.JFS-BASE2-KRN,fr=3.3,fa=HP-UX_B.11.00_64,v=HP: /usr/conf/lib/libvxfs.a(vx33_bio1.o) /usr/conf/lib/libvxfs.a(vx33_iflush.o) /usr/conf/lib/libvxfs.a(vx33_inode.o) /usr/conf/lib/libvxfs.a(vx33_kdmi.o) /usr/conf/lib/libvxfs.a(vx33_mount.o) /usr/conf/lib/libvxfs.a(vx33_rdwri.o) /usr/conf/lib/libvxfs.a(vx33_vm.o) /usr/conf/lib/libvxfs.a(vx33_vnops.o) /usr/conf/lib/libvxfs.a(vx_acl.o) /usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o) /usr/conf/lib/libvxfs.a(vx_machdep.o) what(1) Output: JFS.JFS-BASE2-KRN,fr=3.3,fa=HP-UX_B.11.00_32,v=HP: /usr/conf/lib/libvxfs.a(vx33_bio1.o): vx33_bio1.c $Date: 2000/04/04 10:49:23 $Revision: r1 1ros/2 PATCH_11.00 (PHKL_21499) /usr/conf/lib/libvxfs.a(vx33_iflush.o): vx33_iflush.c $Date: 2001/08/21 12:43:47 $Revision: r11ros/4 PATCH_11.00 (PHKL_25021) /usr/conf/lib/libvxfs.a(vx33_inode.o): vx33_inode.c $Date: 2004/04/15 02:48:55 $Revision: r 11ros/6 PATCH_11.00 (PHKL_30764) /usr/conf/lib/libvxfs.a(vx33_kdmi.o): vx33_kdmi.c $Date: 2002/05/30 13:21:58 $Revision: r1 1ros/2 PATCH_11.00 (PHKL_27212) /usr/conf/lib/libvxfs.a(vx33_mount.o): vx33_mount.c $Date: 2004/05/19 00:14:45 $Revision: r 11ros/4 PATCH_11.00 (PHKL_30927) /usr/conf/lib/libvxfs.a(vx33_rdwri.o): vx33_rdwri.c $Date: 2002/07/25 07:33:38 $Revision: r 11ros/11 PATCH_11.00 (PHKL_27503) /usr/conf/lib/libvxfs.a(vx33_vm.o): vx33_vm.c $Date: 2002/07/25 07:31:11 $Revision: r11r os/3 PATCH_11.00 (PHKL_27503) /usr/conf/lib/libvxfs.a(vx33_vnops.o): vx33_vnops.c $Date: 2003/02/03 21:16:12 $Revision: r 11ros/8 PATCH_11.00 (PHKL_28602) /usr/conf/lib/libvxfs.a(vx_acl.o): vx_acl.c $Date: 2002/05/30 13:25:37 $Revision: r11ro s/3 PATCH_11.00 (PHKL_27212) /usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o): vx_kdmi_machdep.c $Date: 2001/08/21 12:43:47 $Revisi on: r11ros/4 PATCH_11.00 (PHKL_25021) /usr/conf/lib/libvxfs.a(vx_machdep.o): vx_machdep.c $Date: 2004/06/23 00:17:54 $Revision: r 11ros/4 PATCH_11.00 (PHKL_30927) JFS.JFS-BASE2-KRN,fr=3.3,fa=HP-UX_B.11.00_64,v=HP: /usr/conf/lib/libvxfs.a(vx33_bio1.o): vx33_bio1.c $Date: 2000/04/04 10:49:23 $Revision: r1 1ros/2 PATCH_11.00 (PHKL_21499) /usr/conf/lib/libvxfs.a(vx33_iflush.o): vx33_iflush.c $Date: 2001/08/21 12:43:47 $Revision: r11ros/4 PATCH_11.00 (PHKL_25021) /usr/conf/lib/libvxfs.a(vx33_inode.o): vx33_inode.c $Date: 2004/04/15 02:48:55 $Revision: r 11ros/6 PATCH_11.00 (PHKL_30764) /usr/conf/lib/libvxfs.a(vx33_kdmi.o): vx33_kdmi.c $Date: 2002/05/30 13:21:58 $Revision: r1 1ros/2 PATCH_11.00 (PHKL_27212) /usr/conf/lib/libvxfs.a(vx33_mount.o): vx33_mount.c $Date: 2004/05/19 00:14:45 $Revision: r 11ros/4 PATCH_11.00 (PHKL_30927) /usr/conf/lib/libvxfs.a(vx33_rdwri.o): vx33_rdwri.c $Date: 2002/07/25 07:33:38 $Revision: r 11ros/11 PATCH_11.00 (PHKL_27503) /usr/conf/lib/libvxfs.a(vx33_vm.o): vx33_vm.c $Date: 2002/07/25 07:31:11 $Revision: r11r os/3 PATCH_11.00 (PHKL_27503) /usr/conf/lib/libvxfs.a(vx33_vnops.o): vx33_vnops.c $Date: 2003/02/03 21:16:12 $Revision: r 11ros/8 PATCH_11.00 (PHKL_28602) /usr/conf/lib/libvxfs.a(vx_acl.o): vx_acl.c $Date: 2002/05/30 13:25:37 $Revision: r11ro s/3 PATCH_11.00 (PHKL_27212) /usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o): vx_kdmi_machdep.c $Date: 2001/08/21 12:43:47 $Revisi on: r11ros/4 PATCH_11.00 (PHKL_25021) /usr/conf/lib/libvxfs.a(vx_machdep.o): vx_machdep.c $Date: 2004/06/23 00:17:54 $Revision: r 11ros/4 PATCH_11.00 (PHKL_30927) cksum(1) Output: JFS.JFS-BASE2-KRN,fr=3.3,fa=HP-UX_B.11.00_32,v=HP: 1823156169 8312 /usr/conf/lib/libvxfs.a(vx33_bio1.o) 2510254350 35408 /usr/conf/lib/libvxfs.a(vx33_iflush.o) 3250461894 54492 /usr/conf/lib/libvxfs.a(vx33_inode.o) 815168931 27080 /usr/conf/lib/libvxfs.a(vx33_kdmi.o) 602127220 37184 /usr/conf/lib/libvxfs.a(vx33_mount.o) 4170513470 45752 /usr/conf/lib/libvxfs.a(vx33_rdwri.o) 3912353375 14916 /usr/conf/lib/libvxfs.a(vx33_vm.o) 3029614796 42852 /usr/conf/lib/libvxfs.a(vx33_vnops.o) 3652350549 10932 /usr/conf/lib/libvxfs.a(vx_acl.o) 4038935654 7300 /usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o) 1365460295 31728 /usr/conf/lib/libvxfs.a(vx_machdep.o) JFS.JFS-BASE2-KRN,fr=3.3,fa=HP-UX_B.11.00_64,v=HP: 528274726 13104 /usr/conf/lib/libvxfs.a(vx33_bio1.o) 375936232 83176 /usr/conf/lib/libvxfs.a(vx33_iflush.o) 1831413664 124520 /usr/conf/lib/libvxfs.a(vx33_inode.o) 3876639993 56048 /usr/conf/lib/libvxfs.a(vx33_kdmi.o) 2064068175 76480 /usr/conf/lib/libvxfs.a(vx33_mount.o) 4044434194 69840 /usr/conf/lib/libvxfs.a(vx33_rdwri.o) 319977418 25000 /usr/conf/lib/libvxfs.a(vx33_vm.o) 3293098034 80688 /usr/conf/lib/libvxfs.a(vx33_vnops.o) 1042676792 20928 /usr/conf/lib/libvxfs.a(vx_acl.o) 2331806707 12136 /usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o) 1977165788 81728 /usr/conf/lib/libvxfs.a(vx_machdep.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_30764 PHKL_28602 PHKL_27503 PHKL_27212 PHKL_26670 PHKL_26470 PHKL_25021 PHKL_23773 PHKL_23254 PHKL_23192 PHKL_22121 PHKL_21938 PHKL_21774 PHKL_21773 PHKL_21765 PHKL_21499 PHKL_21181 PHKL_21077 PHKL_21063 Equivalent Patches: PHKL_30904: s700: 11.11 s800: 11.11 Patch Package Size: 450 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_30927 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_30927.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_30927. 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_30927.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_30927.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_30927.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None