 |
Welcome, Bogdan Moldovan!
(BR829934)
|
| |
|
|
|
|
Patch Name: PHKL_33258
Patch Description: s700_800 11.11 VxFS cumulative patch ;ml_flag race
Creation Date: 05/05/02
Post Date: 05/06/24
Hardware Platforms - OS Releases:
s700: 11.11
s800: 11.11
Products: N/A
Filesets:
JFS.VXFS-BASE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP
JFS.VXFS-BASE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP
Automatic Reboot?: Yes
Status: General Superseded
Critical:
Yes
PHKL_33258: PANIC
A race condition on a kernel data structure could
lead to memory corruption. This can lead to
a panic when a thread tries to use the memory.
PHKL_32669: HANG
PHKL_32235: HANG
PHKL_30833: PANIC
Data page fault during fs-resize operation.
PHKL_30579: PANIC
Incorrect locking order for releasing spinlocks.
PHKL_30259: PANIC
PHKL_29921: PANIC
PHKL_28529: OTHER
Severe memory pressure that degrades system
performance.
PHKL_28967: PANIC
PHKL_27830: PANIC
PHKL_27554: HANG
PHKL_23374: CORRUPTION
PHKL_25022: HANG
PHKL_23241: PANIC HANG
PHKL_25463: HANG
Category Tags:
defect_repair enhancement general_release critical panic
halts_system corruption manual_dependencies
Path Name: /hp-ux_patches/s700_800/11.X/PHKL_33258
Symptoms:
PHKL_33258:
( SR:8606398556 CR:JAGaf58524 )
System panics due to corruption of memory arena,
M_TEMP. vx_mapbad events could get logged into
the syslog, as below.
Jan 19 xx:xx:xx sd2_hn vmunix: msgcnt
1 vxfs: mesg 003: vx_mapbad -
/dev/vg_bill2/lv_sd2_fs1 file system free
extent bitmap in au 132 marked bad
The stack trace of the thread which lead to
the panic could be as below.
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xefc
nokgdb+0x8
kmalloc+0x80
vx_alloc+0x1c
vx_dunemap+0x124
vx_demap+0x14
vx_trancommit2+0x60
vx_trancommit+0x22c
vx_trunc+0x700
vx_inactive_remove+0x264
vx_inactive_tran+0x108
vx_inactive_list+0x168
vx_worklist_process+0x158
vx_worklist_thread+0x44
kthread_daemon_startup+0x24
kthread_daemon_startup+0x0
PHKL_32669:
( SR:8606348291 CR:JAGaf09113 )
If a sparse file is created and mmapped immediately
afterwards, pages in the hole regions are not
appropriately zero-filled, resulting in invalid data in
the file.
( SR:8606389012 CR:JAGaf49160 )
A process reading or writing to a hole portion of a file
which is mmaped may dead lock with itself. The hanging
threads' stack might be similar to the following:
25_4e59_cl_real_sleep+0x1d64
sleep+0x148
ogetblk+0x970
getblk1+0x128
vx_getblk_cmn+0x88
vx_fgetblk+0x2c
vx_zero_alloc+0x248
vx_alloc_clear+0x33c
vx_mapdbd+0x228
vm_dont_fault_page+0x104
vx_pagein_run+0x104
vx_do_pagein+0x128
vx_pagein+0x1bc
virtual_fault+0x768
vfault+0x324
trap+0x13c8
nokgdb+0x8
accwriteloop+0x0
long_copyout+0x8c
long_uiomove+0x10c
vx_read1+0x658
vx_rdwr+0x494
vno_rw+0xa4
read+0x240
syscall+0x878
$syscallrtn+0x0
OR
_sleep+0x218
ogetblk+0x3d0
getblk1+0x240
vx_getblk_cmn+0x5c
vx_fgetblk+0x2c
vx_zero_alloc+0x3fc
vx_alloc_clear+0x10c
vx_mapdbd+0x2a0
vm_no_io_required+0xec
vx_do_pagein+0xbc
vx_pagein+0xd4
virtual_fault+0x160
vfault+0x14c
trap+0x524
thandler+0xd20
PHKL_32235:
( SR:8606378082 CR:JAGaf38340 )
VxFS file system hang is caused by deadlock
between threads freezing the file system and accessing
some file in the file system.
The stack traces of the deadlocking threads look like
the following:
_sleep+0x218
sleep_spinunlock+0x70
vx_event_wait+0xc0
vx_delay2+0x64
vx_freeze_level+0x278
vx_freeze+0x3c
vx_uioctl+0x544
vx_ioctl+0x58
ioctl+0x120
syscall+0x768
syscallinit+0x55c
_swtch+0xc4
_mp_b_sema_sleep+0x108
vx_rdwr+0x268
vno_rw+0x80
read+0x10c
syscall+0x768
syscallinit+0x55c
_sleep+0x218
sleep_spinunlock+0x70
vx_event_wait+0xc0
vx_delay2+0x64
vx_active_common_flush+0xd8
vx_rdwr+0x2cc
vno_rw+0x80
read+0x10c
syscall+0x768
syscallinit+0x55c
PHKL_31918:
( SR:8606376357 CR:JAGaf36634 )
On Vxfs 3.3, an application using readdir() to scan an
active directory may miss entries that were present
before the opendir() call was made.
PHKL_30904:
( SR:8606360419 CR:JAGaf21113 )
VxFS filesystems, written on devices having sectors of size
greater than 4K, cannot be mounted. The following error
messages would show up
#newfs -F vxfs /dev/rdsk/c5t9d0
#mount -F vxfs /dev/dsk/c5t9d0 /tmp_mnt
vxfs mount: disk image is incompatible with this system
PHKL_30833:
( SR:8606343270 CR:JAGaf04164 )
In very rare cases a panic could occur during a filesystem
resize operation done by running the following command:
fsadm -F vxfs -b 1024000 <Filesystem mountpoint>
showing the following stack trace:
spinlock+0x14
vx_fsq_flush+0x64
vx_tranflush_threaded+0x20
vx_worklist_process+0xfc
vx_worklist_thread+0x44
kthread_daemon_startup+0x24
kthread_daemon_startup
PHKL_30579:
( SR:8606313605 CR:JAGae76403 )
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_30259:
( SR:8606320217 CR:JAGae82701 )
Reduction of VxFS filesystem can occasionally cause the
system to panic and the stack trace would look like as
shown below:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xedc
nokgdb+0x8
vx_allocbuf+0x1c
vx_trunc_range+0x15c
vx_page_trunc+0x30
vx_trunc+0x30c
vx_rsi_cleanup+0x7c
vx_resize+0x3e8
vx_aioctl_full+0xf8
vx_aioctl_common+0x3b4
vx_aioctl+0xbc
vx_ioctl+0xc0
vno_ioctl+0x98
ioctl+0x120
syscall+0x62c
$syscallrtn+0x0
( SR:8606335374 CR:JAGae96449 )
Subdirectories created in a directory having default ACL's
get wrong permissions.
PHKL_29985:
( SR:8606307769 CR:JAGae70804 )
A user with a group that matches a file's owning group
cannot properly access the file if the file was created
in a directory that has default ACL's.
( SR:8606319171 CR:JAGae81661 )
When a file is created in a directory with a default user
ACL entry, other users in the file's owning group are not
allowed to access the file.
PHKL_29921:
( SR:8606317302 CR:JAGae79863 )
System panic appears as a DPF or spinlock timeout in
kdm_k_get_nextevent(), with a stack trace similar to
the one shown below.
panic+0x10
too_much_time+0x238
wait_for_lock_spinner+0x2f4
wait_for_lock_4way+0x2c
sl_retry16+0x44
kdm_eventpost+0x40
kdm_read_event_gen+0x200
vx_rdwr+0x14c
vno_rw+0x68
rwuio+0xc4
read+0x54
syscall+0x1a4
syscallinit+0x320
panic+0x10
PHKL_29110:
( SR:8606311225 CR:JAGae74080 )
Enhancement: Improve performance of VxFS processing
of mmap(2)ed files.
PHKL_28529:
( SR:8606277951 CR:JAGae42012 )
Memory utilization is unusually high when using JFS3.3 on
11.11. This can result in a low memory situation where
processes are slow to start up or may not start up at all,
response time is degraded, there may be many deactivated
processes and the pager daemon (vhand) is one of the top cpu
consumers, as shown by tools such as top(1) or glance(1M).
PHKL_23242:
( SR:8606175351 CR:JAGad44593 )
Systems may exhibit poor throughput or response time when
applications make a lot of mmap(2)/fork(2) system calls,
or when many users try to login simultaneously.
PHKL_28967:
( SR:8606295053 CR:JAGae58750 )
Data page fault occurs when accessing a buffer. While the
stack trace may vary, the following stack trace has been
observed so far:
panic+0x14
report_trap_or_int_and_panic+0x84
trap+0xd9c
nokgdb+0x8
vx_multi_bufinval+0x90
vx_emtran_process+0xe0
vx_dunemap+0x100
vx_demap+0x14
vx_trancommit2+0x6c
vx_trancommit+0x420
vx_rmdir1+0x5cc
vx_rmdir+0x168
vns_remove+0x10c
vn_remove+0xa4
rmdir+0x28
syscall+0x6f8
$syscallrtn+0x0
PHKL_27830:
( SR:8606265910 CR:JAGae30163 )
Reallocation of a buffer with active sendcount may cause a
DPF in different subsystems that are using the same buffer.
The problem was observed when a file being transferred via
ftp or rcp over a slow network link got truncated by
another process while the transfer is still in progress.
The stack trace of the panicking thread may look like the
following but it could be different:
ip_csuma+0x68
ip_wput_ire+0x1cc
ip_wput+0xec
putnext+0xcc
tcp_wput+0x478
tcp_rput+0x3a18
puthere+0x148
put_release+0x194
put_release_return_one+0x10
ip_rput_local+0x778
ip_rput+0x16c
putnext+0xcc
hp_dlpi_mblk_fast_in+0x35c
hp_dlpi_mblk_intr_put+0x91c
streams_put+0xdc
streams_put_release+0x4c
hp_dlpi_mblk_intr+0x184
lanc_ether_ics+0xfc
btlan_receive_frame+0x5e4
btlan_isr+0xfc
sapic_interrupt+0x2c
mp_ext_interrupt+0x2f0
ihandler+0x90c
PHKL_27554:
( SR:8606262053 CR:JAGae26384 )
Filesystems 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_27121:
( SR:8606244250 CR:JAGae10740 )
After a file has been created with 000 permissions in a
directory with one or more default entries in its
Access Control List (ACL, see aclv(5)) 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. The permissions of affected files
can be corrected with chmod(1).
PHKL_26230:
( SR:8606224092 CR:JAGad93188 )
PHKL_25022 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_25885:
( SR:8606235772 CR:JAGae04912 )
Cannot deactivate a Volume Group that has at least one
VxFS file system, no mounted logical volumes, and no one
accessing any of the logical volumes in that VG:
# vgchange -a n /dev/vgtest
vgchange: Couldn't deactivate volume group "/dev/vgtest":
Device busy
( SR:8606221614 CR:JAGad90748 )
Access to a VxFS file system may hang when trying to
flush the intent log. A kernel stack trace of a hung
process will look similar to the following, and there
will be no process in vx_tranflush():
_sleep+0xa5c
sleep_spinunlock+0x70
vx_event_wait+0xc0
vx_delay2+0x64
vx_traninit+0x3d0
vx_write_alloc+0xc8
vx_write1+0x464
vx_rdwr+0x1e4
vno_rw+0x80
write+0x108
syscall+0x750
( SR:8606233921 CR:JAGae03144 )
VxFS performance may be slow when flushing the intent
log during intense file system modifications.
( SR:8606222925 CR:JAGad92031 )
VxFS performance may be slow when there is significant
write activity to the VxFS intent log.
PHKL_23374:
( SR:8606172239 CR:JAGad41499 )
close(2) may cause data corruption by truncating VxFS files.
PHKL_25022:
( SR:8606202113 CR:JAGad71287 )
VxFS may hang a 64 bit system by zeroing out the
interrupt mask (cr15).
( SR:8606198445 CR:JAGad67635 )
Applications invoking system calls fcntl(2) or lockf(2) may
deadlock with applications invoking system calls
truncate(2), ftruncate(2) or creat(2). An example of stack
traces of deadlocked threads is given below.
_sleep+0xa5c
sleep_spinunlock+0x70
vx_rwsleep_rec_lock_rec+0x90
vx_irwlock2_rec+0x3c
vx_getattr2+0x1b0
vx_getattr+0x58
enforcement_mode+0x48
locked+0x78
local_lockf+0xec
lockf+0x244
syscall+0xaec
syscallinit+0x554
_swtch+0x2d4
_mp_b_sema_sleep+0x108
vm_mmf_inval_lock+0x18
vx_setattr+0x304
vns_copen+0xc0
vn_open+0xb4
copen+0xa8
creat+0x44
syscall+0xaec
syscallinit+0x554
( SR:8606200313 CR:JAGad69497 )
Poor performance with VxFS compared to HP-UX 11.00 VxFS 3.1
while multiple threads/processes read from a file
simultaneously.
( SR:8606203915 CR:JAGad73093 )
PHKL_23240 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 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
PHKL_23241:
( SR:8606179185 CR:JAGad48409 )
Poor application performance with VxFS compared to VxFS 3.1
(default version of VxFS on HP-UX 11.00) when the
application does a lot of reads from random offsets of a
file.
( SR:8606183708 CR:JAGad52921 )
Data Page Fault while using Hyperfabric network. Stack of
the panic thread may look like,
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:8606178276 CR:JAGad47503 )
System hang caused by a thread going through the buffer pool
to flush out dirty buffers. A buffer is marked dirty but
also marked busy, and the process or thread decides to wait
for it. Because of this, ServiceGuard commands such as
cmapplyconf and 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
( SR:8606188296 CR:JAGad57504 )
Backup utilities such as fbackup take longer to finish
when JFS fancy read ahead is enabled, i.e., when
vx_fancyra_enable is set to a non-zero value in the system
file.
( 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
( SR:8606179211 CR:JAGad48435 )
sar -v and glance show ninode usage (count of active inodes
on the system) as 0.
PHKL_23240:
( SR:8606175335 CR:JAGad44577 )
Poor system performance with VxFS vs HFS, when applications
like Nastran and Abaqus, which read backward and forward
through a file which cannot be fully contained in the buffer
cache.
PHKL_25360:
( SR:8606209887 CR:JAGad79073 )
Poor vxfs mount performance on systems with large buffer
caches
PHKL_25463:
( SR:8606202670 CR:JAGad71844 )
High end systems may thrash when large number of threads
access a single VxFS filesystem. System may appear to be
hung.
Defect Description:
PHKL_33258:
( SR:8606398556 CR:JAGaf58524 )
Due to a race condition updation of a kernel data structure
could get masked by an update to the same data structure
by another thread. This could lead to memory corruption
by way of a double free of kernel memory, thus leading
to a panic. This is because the updation of the kernel
data structure is not synchronized by appropriate
locks.
Resolution:
Appropriate synchronisation mechanism was added to protect
the kernel data structure from race conditions.
PHKL_32669:
( SR:8606348291 CR:JAGaf09113 )
Write to holes of an mmaped file inside a non-blkclear
mounted filesystem creates delayed write buffers to
zero out the extents allocated to the holes of the
newly created sparse file.
But these buffers are not flushed to disk immediately
afterwards. A subsequent attempt to page in the holes may
still read the non-zeroed data on the disk.
Resolution:
Fixed by flushing dirty buffers so that zeroed out
buffers are written to the disk.
( SR:8606389012 CR:JAGaf49160 )
A process which is reading or writing to an mmaped hole may
deadlock with itself. The defect is caused as the process
which is reading or writing has already taken the buffer
lock and when it encounters a page fault while accessing
the mmap area, it tries to acquire the lock on the same
buffer once again to extend the extent.
Resolution:
The problem is resolved by modifying the kernel code such
that while extending an extent in the page fault path, a
check is made to determine if the buffer is already held
or not. If the buffer is held the extent is not extended.
PHKL_32235:
( SR:8606378082 CR:JAGaf38340 )
It is a three way deadlock. One thread tries to freeze
the file system but needs to wait because the active count
of the file system is greater than zero. A second thread
is doing I/O to a file in the file system, contributing
to the positive active count, but needs to obtain the
vnode lock for the file to proceed the I/O. The vnode
lock is in turn held by a third thread which is waiting
for the first thread to complete the freeze, resulting
in the deadlock
Resolution:
The vx_rdwr() code is fixed such that a thread doing I/O to
a file will first drop the active count of the file system
before trying to obtain the vnode lock.
PHKL_31918:
( SR:8606376357 CR:JAGaf36634 )
The readdir() operation is performed with a series
of system calls to get directory entries. However,
existing directory entries may be moved if other
files are added to the directory between system
calls. These moved entries may not be reported
by subsequent calls to readdir().
Resolution:
Changes were needed in the VxFS code as well as the
C library so that the system calls made on behalf
of readdir() would always return an entire directory
block, preventing the missed entries.
PHKL_30904:
( SR:8606360419 CR:JAGaf21113 )
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_30833:
( SR:8606343270 CR:JAGaf04164 )
During the filesystem resize operation a new superblock
structure for the resized filesystem is created and the old
one is freed in memory. In very rare cases there could
still be unprocessed items on one of the worklists pointing
to the old, and in the meantime freed, superblock structure
which could finally panic the system.
Resolution:
Change in timing to use newly allocated superblock structure
for items queued on the worklists.
PHKL_30579:
( SR:8606313605 CR:JAGae76403 )
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_30259:
( SR:8606320217 CR:JAGae82701 )
The reduction of a VxFS filesystem will occasionally cause
a system to panic because the the vnode associated with a
structural file has v_type set to VNON. The setting of this
flag will prevent a call to the function (bgetvp) which in
turn will produce a buffer structure that will panic the
system.
Resolution:
Checking whether the file type is regular or not. If it is
a regular file then proceed with the truncation of a file
else return 0.
( SR:8606335374 CR:JAGae96449 )
Changes to the file mode creation mask through the umask
command are not applied to subdirectories created in
a directory having default ACL's.This happens if the base
directory has default ACL's and its inode is present in the
inode cache.
Resolution:
Code was modified such that umask settings are applied when
directories are created with ACLs.
PHKL_29985:
( SR:8606307769 CR:JAGae70804 )
Normal ACL entries were being skipped for non-directory
files if default ACL entries were present.
Resolution:
For non-directory files both default and non-default
ACL's are checked.
( SR:8606319171 CR:JAGae81661 )
group permissions were not being checked if there were
ACL's present on the file.
Resolution:
Check the group permissions if there is no group or
default group ACL entries.
PHKL_29921:
( SR:8606317302 CR:JAGae79863 )
The events in hsms_outq may be freed in
kdm_eventprocess() while these addresses are being
traversed in kdm_k_get_nextevent(). This causes
corruption of templist when these free addresses
are reused. It leads either to an infinite loop
that causes spinlock timeout, or a DPF, owing to
an invalid pointer in kdm_k_get_nextevent().
Resolution:
Now we have modified the code to take care of this
race condition problem.
PHKL_29110:
( SR:8606311225 CR:JAGae74080 )
VxFS handles faults on memory mapped pages one at a time
and does sychronous 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_28529:
( SR:8606277951 CR:JAGae42012 )
JFS3.3 incorrectly passes zeros for the start and end
indices in the pageout structure, resulting in incorrect
settings for the next pageout. This prevents "vhand" from
properly paging this area of memory and can contribute to
undue memory utilization, resulting in memory pressure.
Resolution:
Modified the JFS3.3 paging routines to pass the correct
start and end indices in the pageout structure, allowing the
subsequent pageouts to succeed and memory utilization to
decrease.
PHKL_23242:
( SR:8606175351 CR:JAGad44593 )
VxFS uses read-write locks held 'EXCL' on many of the paths
involving the mapping and unmapping of shared memory files.
Resolution:
Switch to read-write locks held 'SHARED' and/or eliminate
locking.
PHKL_28967:
( SR:8606295053 CR:JAGae58750 )
Certain fields in the buffer are modified after the buffer
has been released. This produces a race condition as the
buffer may be re-used for other operations after it is
released, and then the buffer fields are incorrectly
modified.
Resolution:
The buffer fields are modified prior to the buffer being
released.
PHKL_27830:
( SR:8606265910 CR:JAGae30163 )
Reallocation of an active sendcount buffer may cause a DPF
panic in various subsystems when the size of the buffer
with active sendcnt, is changed (i.e., through a delayed
extended operation after truncation of a file).
Resolution:
Reallocation of an active sendcount buffer should invalidate
the buffer. The buffer should be flushed to the disk if it
is a delayed write buffer, before being invalidated.
PHKL_27554:
( SR:8606262053 CR:JAGae26384 )
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_27121:
( SR:8606244250 CR:JAGae10740 )
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.
Resolution:
The modemasks of directories are no longer affected by the
modes of created files.
PHKL_26230:
( SR:8606224092 CR:JAGad93188 )
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_25885:
( SR:8606235772 CR:JAGae04912 )
A failed VxFS mount leaves the device opened.
Resolution:
Ensure device is closed when a VxFS mount fails.
( SR:8606221614 CR:JAGad90748 )
During the flushing of a transaction, a condition
occurred such that the transaction needed to be
retried, but was not. Since the transaction was
never flushed, the intent log fills up and access
to the file system hangs.
Resolution:
Assure proper retry of transactions under all
conditions.
( SR:8606233921 CR:JAGae03144 )
VxFS intent log processing is done using 1K buffers.
Resolution:
Allow larger I/O's when flushing the intent log by
introducing a new logiosize mount option. For
example:
mount -F vxfs -o logiosize=4096
Valid values for logiosize are 1024, 2048, and 4096.
( SR:8606222925 CR:JAGad92031 )
VxFS fails to detect that the intent log is filling
up.
Resolution:
Changed internal VxFS threshold values used to detect
how full the log is to lower values to allow earlier
detection that the log is filling up.
PHKL_23374:
( SR:8606172239 CR:JAGad41499 )
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.
PHKL_25022:
( SR:8606202113 CR:JAGad71287 )
VxFS 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:8606198445 CR:JAGad67635 )
A lock was acquired in the wrong order in a VxFS function
invoked by system calls fcntl(2) and lockf(2).
Resolution:
Eliminated the cases where the lock was acquired in the
wrong order.
( SR:8606200313 CR:JAGad69497 )
1. VxFS 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 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 read code was acquiring two locks in the wrong
order causing deadlock.
Resolution:
VxFS read code is rewritten eliminating the need to
acquire the locks in the wrong order.
PHKL_23241:
( SR:8606179185 CR:JAGad48409 )
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 can be done for random reads.
( SR:8606183708 CR:JAGad52921 )
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:8606178276 CR:JAGad47503 )
In some corner cases, some VxFS meta buffers (map buffers)
will be left in a busy and dirty state. This leads to a
process hang for 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.
( SR:8606188296 CR:JAGad57504 )
The 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
many unnecessary I/Os.
Resolution:
When there are multiple readers to a file, disable fancy
read and do sequential read ahead instead.
( 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.
( SR:8606179211 CR:JAGad48435 )
VxFS was decrementing the number of active inode count
instead of incrementing it when inodes became active.
Resolution:
Increment active inode count when inodes become active.
PHKL_23240:
( SR:8606175335 CR:JAGad44577 )
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.
PHKL_25360:
( SR:8606209887 CR:JAGad79073 )
VXFS mount(2) performance varies depending on the size of
the buffer cache but can be poor for systems with large
buffer caches. The majority of the time is spent in
flushing/invalidation routines which search all buffer
headers then search all hash buckets respectively at VXFS
file system initialization. These flushing/invalidation
routines should not be required since no data should reside
in the buffer cache for the device being mounted.
Resolution:
To reduce the mount time aforementioned,
flushing/invalidation calls are removed.
PHKL_25463:
( SR:8606202670 CR:JAGad71844 )
VxFS logs each operation on the filesystem. When a thread
cannot find free space in the log, it sleeps 2 seconds and
tries again.
The problem arises when there is a large number of threads
operating on the filesystem causing the log to be full most
of the time. All these threads sleep 2 seconds and then
check the log space. This causes the system to thrash
keeping the processors busy all the time. The threads which
are supposed to free up the log space can never do that.
Resolution:
Increase the sleeping time of the threads in each iteration
instead of sleeping 2 seconds always.
Enhancement:
No (superseded patches contained enhancements)
PHKL_28529:
Enhancements were delivered in a patch this one has
superseded. Please review the Defect Description
text for more information.
PHKL_27830:
Enhancements were delivered in a patch this one has
superseded. Please review the Defect Description
text for more information.
SR:
8606172239 8606175335 8606175351 8606178276 8606179185
8606179211 8606181938 8606183708 8606188296 8606198445
8606200313 8606202113 8606202670 8606203915 8606209887
8606221614 8606222925 8606224092 8606233921 8606235772
8606244250 8606262053 8606265910 8606277951 8606295053
8606307769 8606311225 8606313605 8606317302 8606319171
8606320217 8606335374 8606343270 8606348291 8606360419
8606376357 8606378082 8606389012 8606398556
Patch Files:
JFS.VXFS-BASE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libvxfs.a(kdm_core.o)
/usr/conf/lib/libvxfs.a(vx_acl.o)
/usr/conf/lib/libvxfs.a(vx_ausum.o)
/usr/conf/lib/libvxfs.a(vx_bio.o)
/usr/conf/lib/libvxfs.a(vx_bitmaps.o)
/usr/conf/lib/libvxfs.a(vx_freeze.o)
/usr/conf/lib/libvxfs.a(vx_full.o)
/usr/conf/lib/libvxfs.a(vx_iflush.o)
/usr/conf/lib/libvxfs.a(vx_inode.o)
/usr/conf/lib/libvxfs.a(vx_kdmi.o)
/usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o)
/usr/conf/lib/libvxfs.a(vx_lct.o)
/usr/conf/lib/libvxfs.a(vx_lwrite.o)
/usr/conf/lib/libvxfs.a(vx_machdep.o)
/usr/conf/lib/libvxfs.a(vx_message.o)
/usr/conf/lib/libvxfs.a(vx_mount.o)
/usr/conf/lib/libvxfs.a(vx_oltmount.o)
/usr/conf/lib/libvxfs.a(vx_rdwri.o)
/usr/conf/lib/libvxfs.a(vx_tran.o)
/usr/conf/lib/libvxfs.a(vx_vfsops.o)
/usr/conf/lib/libvxfs.a(vx_vm.o)
/usr/conf/lib/libvxfs.a(vx_vnops.o)
JFS.VXFS-BASE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libvxfs.a(kdm_core.o)
/usr/conf/lib/libvxfs.a(vx_acl.o)
/usr/conf/lib/libvxfs.a(vx_ausum.o)
/usr/conf/lib/libvxfs.a(vx_bio.o)
/usr/conf/lib/libvxfs.a(vx_bitmaps.o)
/usr/conf/lib/libvxfs.a(vx_freeze.o)
/usr/conf/lib/libvxfs.a(vx_full.o)
/usr/conf/lib/libvxfs.a(vx_iflush.o)
/usr/conf/lib/libvxfs.a(vx_inode.o)
/usr/conf/lib/libvxfs.a(vx_kdmi.o)
/usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o)
/usr/conf/lib/libvxfs.a(vx_lct.o)
/usr/conf/lib/libvxfs.a(vx_lwrite.o)
/usr/conf/lib/libvxfs.a(vx_machdep.o)
/usr/conf/lib/libvxfs.a(vx_message.o)
/usr/conf/lib/libvxfs.a(vx_mount.o)
/usr/conf/lib/libvxfs.a(vx_oltmount.o)
/usr/conf/lib/libvxfs.a(vx_rdwri.o)
/usr/conf/lib/libvxfs.a(vx_tran.o)
/usr/conf/lib/libvxfs.a(vx_vfsops.o)
/usr/conf/lib/libvxfs.a(vx_vm.o)
/usr/conf/lib/libvxfs.a(vx_vnops.o)
what(1) Output:
JFS.VXFS-BASE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libvxfs.a(kdm_core.o):
kdm_core.c $Date: 2003/10/16 06:26:50 $Revision: r11
.11/2 PATCH_11.11 (PHKL_29921)
/usr/conf/lib/libvxfs.a(vx_acl.o):
vx_acl.c $Date: 2004/01/21 21:31:56 $Revision: r11.1
1/3 PATCH_11.11 (PHKL_30259)
/usr/conf/lib/libvxfs.a(vx_ausum.o):
vx_ausum.c $Date: 2002/04/19 05:55:51 $Revision: r11
.11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_bio.o):
vx_bio.c $Date: 2003/04/07 03:47:29 $Revision: r11.1
1/4 PATCH_11.11 (PHKL_28967)
/usr/conf/lib/libvxfs.a(vx_bitmaps.o):
vx_bitmaps.c $Date: 2005/04/27 00:17:21 $Revision: r
11.11/3 PATCH_11.11 (PHKL_33258)
/usr/conf/lib/libvxfs.a(vx_freeze.o):
vx_freeze.c $Date: 2002/04/19 05:57:23 $Revision: r1
1.11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_full.o):
vx_full.c $Date: 2002/04/19 05:58:26 $Revision: r11.
11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_iflush.o):
vx_iflush.c $Date: 2001/08/27 08:06:20 $Revision: r1
1.11/3 PATCH_11.11 (PHKL_25022)
/usr/conf/lib/libvxfs.a(vx_inode.o):
vx_inode.c $Date: 2004/03/08 21:32:51 $Revision: r11
.11/6 PATCH_11.11 (PHKL_30579)
/usr/conf/lib/libvxfs.a(vx_kdmi.o):
vx_kdmi.c $Date: 2001/08/27 08:06:20 $Revision: r11.
11/1 PATCH_11.11 (PHKL_25022)
/usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o):
vx_kdmi_machdep.c $Date: 2001/08/27 08:06:20 $Revisi
on: r11.11/1 PATCH_11.11 (PHKL_25022)
/usr/conf/lib/libvxfs.a(vx_lct.o):
vx_lct.c $Date: 2002/04/19 05:59:25 $Revision: r11.1
1/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_lwrite.o):
vx_lwrite.c $Date: 2005/01/19 22:02:32 $Revision: r1
1.11/3 PATCH_11.11 (PHKL_32669)
/usr/conf/lib/libvxfs.a(vx_machdep.o):
vx_machdep.c $Date: 2005/01/19 22:00:26 $Revision: r
11.11/8 PATCH_11.11 (PHKL_32669)
/usr/conf/lib/libvxfs.a(vx_message.o):
vx_message.c $Date: 2002/04/19 06:01:28 $Revision: r
11.11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_mount.o):
vx_mount.c $Date: 2004/05/13 02:18:19 $Revision: r11
.11/5 PATCH_11.11 (PHKL_30904)
/usr/conf/lib/libvxfs.a(vx_oltmount.o):
vx_oltmount.c $Date: 2002/04/19 06:02:33 $Revision:
r11.11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_rdwri.o):
vx_rdwri.c $Date: 2005/01/19 21:53:22 $Revision: r11
.11/6 PATCH_11.11 (PHKL_32669)
/usr/conf/lib/libvxfs.a(vx_tran.o):
vx_tran.c $Date: 2002/04/19 06:03:34 $Revision: r11.
11/3 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_vfsops.o):
vx_vfsops.c $Date: 2002/04/19 06:04:51 $Revision: r1
1.11/3 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_vm.o):
vx_vm.c $Date: 2005/01/19 21:58:10 $Revision: r11.11
/4 PATCH_11.11 (PHKL_32669)
/usr/conf/lib/libvxfs.a(vx_vnops.o):
vx_vnops.c $Date: 2004/10/28 02:39:56 $Revision: r11
.11/7 PATCH_11.11 (PHKL_32235)
JFS.VXFS-BASE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libvxfs.a(kdm_core.o):
kdm_core.c $Date: 2003/10/16 06:26:50 $Revision: r11
.11/2 PATCH_11.11 (PHKL_29921)
/usr/conf/lib/libvxfs.a(vx_acl.o):
vx_acl.c $Date: 2004/01/21 21:31:56 $Revision: r11.1
1/3 PATCH_11.11 (PHKL_30259)
/usr/conf/lib/libvxfs.a(vx_ausum.o):
vx_ausum.c $Date: 2002/04/19 05:55:51 $Revision: r11
.11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_bio.o):
vx_bio.c $Date: 2003/04/07 03:47:29 $Revision: r11.1
1/4 PATCH_11.11 (PHKL_28967)
/usr/conf/lib/libvxfs.a(vx_bitmaps.o):
vx_bitmaps.c $Date: 2005/04/27 00:17:21 $Revision: r
11.11/3 PATCH_11.11 (PHKL_33258)
/usr/conf/lib/libvxfs.a(vx_freeze.o):
vx_freeze.c $Date: 2002/04/19 05:57:23 $Revision: r1
1.11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_full.o):
vx_full.c $Date: 2002/04/19 05:58:26 $Revision: r11.
11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_iflush.o):
vx_iflush.c $Date: 2001/08/27 08:06:20 $Revision: r1
1.11/3 PATCH_11.11 (PHKL_25022)
/usr/conf/lib/libvxfs.a(vx_inode.o):
vx_inode.c $Date: 2004/03/08 21:32:51 $Revision: r11
.11/6 PATCH_11.11 (PHKL_30579)
/usr/conf/lib/libvxfs.a(vx_kdmi.o):
vx_kdmi.c $Date: 2001/08/27 08:06:20 $Revision: r11.
11/1 PATCH_11.11 (PHKL_25022)
/usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o):
vx_kdmi_machdep.c $Date: 2001/08/27 08:06:20 $Revisi
on: r11.11/1 PATCH_11.11 (PHKL_25022)
/usr/conf/lib/libvxfs.a(vx_lct.o):
vx_lct.c $Date: 2002/04/19 05:59:25 $Revision: r11.1
1/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_lwrite.o):
vx_lwrite.c $Date: 2005/01/19 22:02:32 $Revision: r1
1.11/3 PATCH_11.11 (PHKL_32669)
/usr/conf/lib/libvxfs.a(vx_machdep.o):
vx_machdep.c $Date: 2005/01/19 22:00:26 $Revision: r
11.11/8 PATCH_11.11 (PHKL_32669)
/usr/conf/lib/libvxfs.a(vx_message.o):
vx_message.c $Date: 2002/04/19 06:01:28 $Revision: r
11.11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_mount.o):
vx_mount.c $Date: 2004/05/13 02:18:19 $Revision: r11
.11/5 PATCH_11.11 (PHKL_30904)
/usr/conf/lib/libvxfs.a(vx_oltmount.o):
vx_oltmount.c $Date: 2002/04/19 06:02:33 $Revision:
r11.11/2 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_rdwri.o):
vx_rdwri.c $Date: 2005/01/19 21:53:22 $Revision: r11
.11/6 PATCH_11.11 (PHKL_32669)
/usr/conf/lib/libvxfs.a(vx_tran.o):
vx_tran.c $Date: 2002/04/19 06:03:34 $Revision: r11.
11/3 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_vfsops.o):
vx_vfsops.c $Date: 2002/04/19 06:04:51 $Revision: r1
1.11/3 PATCH_11.11 (PHKL_25885)
/usr/conf/lib/libvxfs.a(vx_vm.o):
vx_vm.c $Date: 2005/01/19 21:58:10 $Revision: r11.11
/4 PATCH_11.11 (PHKL_32669)
/usr/conf/lib/libvxfs.a(vx_vnops.o):
vx_vnops.c $Date: 2004/10/28 02:39:56 $Revision: r11
.11/7 PATCH_11.11 (PHKL_32235)
cksum(1) Output:
JFS.VXFS-BASE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
4189102658 52220 /usr/conf/lib/libvxfs.a(kdm_core.o)
4271760536 9512 /usr/conf/lib/libvxfs.a(vx_acl.o)
4195028791 10884 /usr/conf/lib/libvxfs.a(vx_ausum.o)
1020861024 15252 /usr/conf/lib/libvxfs.a(vx_bio.o)
2515146938 12824 /usr/conf/lib/libvxfs.a(vx_bitmaps.o)
3935447036 12376 /usr/conf/lib/libvxfs.a(vx_freeze.o)
1878163420 18128 /usr/conf/lib/libvxfs.a(vx_full.o)
2777098015 33576 /usr/conf/lib/libvxfs.a(vx_iflush.o)
1096315887 49848 /usr/conf/lib/libvxfs.a(vx_inode.o)
2843628605 24496 /usr/conf/lib/libvxfs.a(vx_kdmi.o)
2464986860 7240 /usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o)
3785597206 8480 /usr/conf/lib/libvxfs.a(vx_lct.o)
1095604957 17596 /usr/conf/lib/libvxfs.a(vx_lwrite.o)
2201863105 28528 /usr/conf/lib/libvxfs.a(vx_machdep.o)
1522138847 8180 /usr/conf/lib/libvxfs.a(vx_message.o)
2232373557 30576 /usr/conf/lib/libvxfs.a(vx_mount.o)
2624522567 32180 /usr/conf/lib/libvxfs.a(vx_oltmount.o)
601166936 43440 /usr/conf/lib/libvxfs.a(vx_rdwri.o)
1656528092 23276 /usr/conf/lib/libvxfs.a(vx_tran.o)
728993192 14052 /usr/conf/lib/libvxfs.a(vx_vfsops.o)
1951527671 15632 /usr/conf/lib/libvxfs.a(vx_vm.o)
3919074997 40316 /usr/conf/lib/libvxfs.a(vx_vnops.o)
JFS.VXFS-BASE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
211759985 123304 /usr/conf/lib/libvxfs.a(kdm_core.o)
875043905 18504 /usr/conf/lib/libvxfs.a(vx_acl.o)
3686281894 24552 /usr/conf/lib/libvxfs.a(vx_ausum.o)
2557113967 35632 /usr/conf/lib/libvxfs.a(vx_bio.o)
1747573870 31072 /usr/conf/lib/libvxfs.a(vx_bitmaps.o)
3140460389 30728 /usr/conf/lib/libvxfs.a(vx_freeze.o)
2763759696 33336 /usr/conf/lib/libvxfs.a(vx_full.o)
2895105908 81776 /usr/conf/lib/libvxfs.a(vx_iflush.o)
3012692783 117424 /usr/conf/lib/libvxfs.a(vx_inode.o)
877622715 50728 /usr/conf/lib/libvxfs.a(vx_kdmi.o)
492105907 12712 /usr/conf/lib/libvxfs.a(vx_kdmi_machdep.o)
1044535236 19240 /usr/conf/lib/libvxfs.a(vx_lct.o)
340267469 30320 /usr/conf/lib/libvxfs.a(vx_lwrite.o)
2662412727 75208 /usr/conf/lib/libvxfs.a(vx_machdep.o)
708081870 12784 /usr/conf/lib/libvxfs.a(vx_message.o)
2345221393 62872 /usr/conf/lib/libvxfs.a(vx_mount.o)
923851506 54584 /usr/conf/lib/libvxfs.a(vx_oltmount.o)
2595963481 69952 /usr/conf/lib/libvxfs.a(vx_rdwri.o)
1346385777 46072 /usr/conf/lib/libvxfs.a(vx_tran.o)
698298421 30216 /usr/conf/lib/libvxfs.a(vx_vfsops.o)
2776737111 26600 /usr/conf/lib/libvxfs.a(vx_vm.o)
668093025 81240 /usr/conf/lib/libvxfs.a(vx_vnops.o)
Patch Conflicts: None
Patch Dependencies:
s700: 11.11: PHCO_31903
s800: 11.11: PHCO_31903
Hardware Dependencies: None
Other Dependencies:
PHKL_25885: PHCO_26252 is needed to use logiosize=4096.
Supersedes:
PHKL_32669 PHKL_32235 PHKL_31918 PHKL_30904 PHKL_30833 PHKL_30579
PHKL_30259 PHKL_29985 PHKL_29921 PHKL_29110 PHKL_28967 PHKL_28529
PHKL_27830 PHKL_27554 PHKL_27121 PHKL_26230 PHKL_25885 PHKL_25463
PHKL_25360 PHKL_25022 PHKL_23374 PHKL_23242 PHKL_23241 PHKL_23240
Equivalent Patches: None
Patch Package Size: 730 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_33258
5. Run swinstall to install the patch:
swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHKL_33258.depot
By default swinstall will archive the original software in
/var/adm/sw/save/PHKL_33258. 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_33258.text file is
available in the product readme:
swlist -l product -a readme -d @ /tmp/PHKL_33258.depot
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHKL_33258.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
|
|
|
