 |
» |
|
|
|
|
|
|
|
|
|
Patch Name: PHKL_33988
Patch Description: s700_800 11.11 Cumulative VM patch
Creation Date: 05/10/17
Post Date: 05/10/24
Repost: 06/01/26
The Symptoms and Defect Description sections of the patch
documentation for PHKL_33261 were modified to remove
unnecessary information related to SR 8606391584
(JAGaf51716).
Hardware Platforms - OS Releases:
s700: 11.11
s800: 11.11
Products: N/A
Filesets:
ProgSupport.PAUX-ENG-A-MAN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP
Automatic Reboot?: Yes
Status: General Superseded
Critical:
No (superseded patches were critical)
PHKL_33270: ABORT
PHKL_33261: PANIC
PHKL_32806: ABORT
PHKL_32578: PANIC
PHKL_31003: PANIC
PHKL_30158: HANG
PHKL_28990: ABORT CORRUPTION HANG
The defect described in JAGae67573 can result in
seemingly random application failures for those
applications that call mprotect(2) with the
PROT_CHECK flag.
PHKL_28428: PANIC CORRUPTION
PHKL_28267: PANIC CORRUPTION
PHKL_27278: PANIC CORRUPTION
PHKL_26744: PANIC
PHKL_26233: PANIC
PHKL_25614: CORRUPTION PANIC ABORT
JAGad62420: a process with a private 3rd quadrant
can obtain an erroneous address when calling mmap(2)
for a large mapping ( size > 1 GB). The erroneous
address can match an already existing address for
that process. If this is the case, subsequent use
of this address could lead to corruption of data
already at that address, as now 2 pointers with
different meaning refer to the same block of data.
The corruption is limited to the own address space
of the process, and possibly files mapped by the
process.
The corruption is limited to the calling process
address space, and will not affect system or other
process memory.
PHKL_25129: CORRUPTION
PHKL_24073: HANG
Category Tags:
defect_repair enhancement general_release critical panic
halts_system corruption
Path Name: /hp-ux_patches/s700_800/11.X/PHKL_33988
Symptoms:
PHKL_33988:
( SR:8606308359 CR:JAGae71394 )
msync(2) system call is returning an undocumented error
code, EAGAIN.
PHKL_33270:
( SR:8606397870 CR:JAGaf57852 )
Binaries executing on one node of a CFS dump core, when
shared libraries associated with the binary are accessed
on another node. (for instance, by a backup application.)
PHKL_33261:
( SR:8606391584 CR:JAGaf51716 )
In rare cases, system may panic with the stack trace similar
to one give below while processing mmap64(2) requests.
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xf04
thandler+0xd20
smmap_common+0xd48
smmap+0x50
syscall+0x768
syscallinit+0x55c
PHKL_32806:
( SR:8606387618 CR:JAGaf47771 )
Process running on Cluster File System (vxfs-cfs) node may
dump core when the disk image of the executable is
"touched" on any other CFS node.
PHKL_32578:
( SR:8606379142 CR:JAGaf39391 )
Sharing a memory map between processes using memory windows
may lead to panic with the panic message "rmfree: overlap"
and the following panic stack trace:
panic+0x6c
do_rmfree+0x208
rmfree+0x3c
shared_space_return+0xc8
hdl_detach+0x144
detachreg+0x98
dispreg+0x114
exit+0x724
rexit+0x24
syscall+0xaec
syscallinit+0x55c
( SR:8606380135 CR:JAGaf40371 )
With profiling enabled, killing an application may lead
to a panic due to Data Page Fault with following stack
trace:
panic+0x154
report_trap_or_int_and_panic+0x94
trap+0xef4
nokgdb+0x8
ki_mmap+0x8c
ki_syscalltrace+0x4c
syscall+0xb14
$syscallrtn+0x0
PHKL_31003:
( SR:8606354805 CR:JAGaf15561 )
In rare cases, system may panic with the stacktrace similar
to one give below while processing mmap(2) requests.
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xed4
thandler+0xd20
shrinkvfd+0x70
growreg+0x1e8
mapvnode+0x1e0
mmap_file_object+0x128
smmap_common+0x2e8
smmap+0x50
syscall+0xaec
syscallinit+0x554
( SR:8606351558 CR:JAGaf12363 )
The system may panic with a stacktrace similar to one given
below while processing fork()/mmap() requests.
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xef4
thandler+0xd20
mrg_return_freemem+0x1d0
freepfd+0x254
do_freepagesc+0x1b4
for_val2+0x29c
for_val2+0x13c
foreach_chunk+0x3c
pgfree+0x9c
freereg+0x3c
private_copy+0x1c0
dupvas+0x220
procdup+0x3c
newproc+0x640
fork1+0x1c0
fork+0x14
syscall+0xaec
syscallinit+0x554
PHKL_30616:
( SR:8606341242 CR:JAGaf02151 )
This product update is a member of a set needed to enable
the optional HP-UX Mmap-Perf feature.
Upon installation, the HP-UX Mmap-Perf bundle(EnhancedMMAP)
will install the full set of product updates
(including this one) to enable the Mmap-Perf feature.
If the HP-UX Mmap-Perf feature product is not
installed, this product update will have no impact on your
system.
PHKL_30158:
( SR:8606335008 CR:JAGae96085 )
System may hang when fork(2) fails due to unavailable
protection or space ids. The following is the stack
trace when the hang is TOC'ed.
su_waiters+0x10
call_su_waiters+0x1c
lock_write+0xfc
findpreg+0x150
pfault+0xe4
trap+0xa1c
nokgdb+0x8
b_eight_word_loop+0x4
long_copyin+0xb4
long_uiomove+0xfc
vx_write_default+0xab0
vx_write1+0x878
vx_rdwr+0x144
vn_rdwr+0x84
write_to_core+0xe0
write_prp_core+0x3c
pa32_write_prp_seg+0x7c
pa32_walkpregions+0x50
pa32_core+0x134
core+0x1b8
psig+0x4fc
syscall+0xb38
$syscallrtn+0x0
syscall+0xb38
$syscallrtn+0x0
PHKL_28990:
( SR:8606304228 CR:JAGae67573 )
Applications that use the mprotect(2) system call with the
PROT_CHECK flag may fail randomly due to an incorrect
result returned from mprotect(2).
( SR:8606283720 CR:JAGae47665 )
This patch is required for systems running Hyper Messaging
Protocol(HMP)/Message Passing Interface (MPI)
applications. The MPI applications hang after some time
as they receive corrupt data. This problem can be seen on
systems running MPI or HMP applications with the
hyperfabric cards.
When the parent forks and the child exits before the parent
(MPI/HMP application) sends/receives data, there could be
data corruption. The behavior is evident when using a
popen(), pclose() call and immediately starting data
transfer via HMP.
PHKL_28428:
( SR:8606267409 CR:JAGae31651 )
System panic when removing an iomap range from a child
process of a fork() system call when the parent process
has already removed the range.
Trap Type 15 (Data page fault):
Instruction Address (pcsq.pcoq) = 0x0.0x1256c4
Instruction (iir) = 0x4134002e (load/store)
Target Address (isr.ior) = 0x0.0x0000000000000017
Base Register (gr9) = 0x0000000000000000
Savestate Ptr (ssp) = 0xe57bc00.0x400003ffffff1378
Savestate Return Pointer (ss_rp) = 0x00000000001256c0
panic: Data page fault
A typical stack trace for this problem is:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xef4
nokgdb+0x8
pddpage+0xc4
io_unmap+0x25c
iomap_nuke+0x24
iomap_exit+0xa4
exit+0xf30
rexit+0x24
syscall+0x20c
$syscallrtn+0x0
( SR:8606267454 CR:JAGae31696 )
This problem was found in HP internal analysis and
has not been encountered on customer systems. If
the problem occurs, the system may panic or experience
system memory corruption (which may in turn cause user
memory corruption). Because the exact behavior depends
entirely on the state of the system, a typical stack
trace for such a panic is not possible.
PHKL_28267:
( SR:8606220721 CR:JAGad89858 ) Duplicate
( SR:8606227157 CR:JAGad96219 )
Under certain conditions of a process fork/exit, the system
may panic with the panic string: "freevas: vas cnt 0, but
still pointing to pregions".
The stack trace may be similar to:
panic+0x14
freevas+0x164
freeproc+0x22c
wait1+0x25c
waitpid+0x38
syscall+0x394
$syscallrtn+0x0
PHKL_27278:
( SR:8606262338 CR:JAGae26673 )
Using glance, or any tools based on pstat, to report memory
information about a single-threaded process, can cause a
panic.
The panic will occur in psl_search(). Before the panic
occurs, corruption is possible as the process address space
is corrupted.
PHKL_26744:
( SR:8606202772 CR:JAGad71946 )
A data page fault panic may occur as the result of running
mmap(2) more than 65535 times on a file. The resulting
stack trace may look similar to the following:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xa9c
nokgdb+0x8
skl_deletevalue+0x4
remove_pregion_from_region+0xc8
detachreg+0xa4
dispreg+0x164
exit+0xb3c
rexit+0x24
syscall+0x724
$syscallrtn+0x0
PHKL_26386:
( SR:8606186482 CR:JAGad55686 )
This product update provides pre-enablement of extensions
to mmap to allow mapping of I/O registers or address
ranges.
This product update will have no impact on your system
until the extensions to mmap are fully enabled.
PHKL_26233:
( SR:8606230627 CR:JAGad99677 )
System panic with the following stack trace.
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xed4
thandler+0xd20
hdl_vfault+0x80
vfault+0x12c
trap+0x234
thandler+0xd20
PHKL_25614:
( SR:8606193208 CR:JAGad62420 )
A 32 bit process with the 3rd quadrant private (obtained
with the command chattr +q3 enable) can obtain an incorrect
address when requesting a large (~1 GB) mapping with the
mmap(2) call.
Observed symptoms are :
-process aborted because of a memory fault
(signals SIGBUS or SIGSEGV).
-corruption of the memory for the calling process,
including files that are mapped in memory by the process.
System memory and memory from other processes are not
impacted.
( SR:8606212954 CR:JAGad82141 )
When a 32 bit process uses mmap64(2) to mmap(2) a large file
on a 64 bit kernel, if the offset is bigger than 4 GB, the
call returns EINVAL.
( SR:8606188767 CR:JAGad57983 )
Applications requiring large amounts of private memory
address space (greater than 2GB) may use shared memory space
to offset their private memory space needs. This is done by
using the mmap(2) flags:
MAP_ANONYMOUS|MAP_GLOBAL|MAP_SHARED.
Even with this effort to conserve private memory space,
these applications are running out of private memory space.
A close examination shows that allocations intended for
shared space were put into private memory space in error.
( SR:8606205797 CR:JAGad74972 )
A panic "Returning ID that is already free" may occur as a
result of a process (proc A) calling mmap(2) with MAP_FIXED
and an address that overlaps with an existing text mapping.
This will result in a panic in one of the following ways:
(1) Panic occurs when process proc A exits.
(2) The process proc A does a munmap(2) of the previous
mmap(2) (as mentioned above) and subsequent mmap(2)
calls from any process (proc X) get assigned the same
address. When process proc X exits (case 1) the panic
occurs.
A stack trace may look similar to the following:
panic+0x6c
hdl_return_id+0xb8
hdl_free_protid+0x1c
hdl_detach+0x17c
attachreg+0x228
mmap_anon_object+0xc4
smmap_common+0x35c
smmap+0x50
syscall+0x750
$syscallrtn+0x0
PHKL_25129:
( SR:8606215349 CR:JAGad84536 )
Memory corruption may occur after the installation of
PHKL_24679.
PHKL_24679:
( SR:8606201639 CR:JAGad70813 )
The system takes a lot of time in creating a large number of
threads. The cost of creating threads increases
exponentially as the number of threads increases and so the
system appears to be very slow when one tries to create a
lot of threads.
PHKL_25227:
( SR:8606188435 CR:JAGad57643 )
Narrow mode (32bit) HP-UX 11.11 programs cannot mmap64() any
part of a large file beyond the first 2GB.
PHKL_24743:
( SR:8606205558 CR:JAGad74733 ) Duplicate
( SR:8606204858 CR:JAGad74036 )
Decreased performance for mmap() operations has occasionally
been observed in superdome systems with more than 32 cpus.
These symptoms are not specific to superdomes, but could
possibly occur on other high end systems as well.
PHKL_24073:
( SR:8606189205 CR:JAGad58421 )
A multi-threaded process hangs and cannot be killed. This
process will have been repeatedly mmap()ing parts of the
same file, while at the same time reading or writing to it
with the read(), write(), readv(), or writev() system calls
from a different thread. That file must also be on a JFS
file system.
The Netscape Messaging Server's smtpd process is the only
application we've seen do the particular combination of
operations required to get into this state.
Defect Description:
PHKL_33988:
( SR:8606308359 CR:JAGae71394 )
msync(2) system call incorrectly returned EAGAIN.
Resolution:
Changed msync(2) system call to return EAGAIN only when the
error condition is truly transient. Otherwise, return EIO.
Updated the msync(2) man page to this effect.
PHKL_33270:
( SR:8606397870 CR:JAGaf57852 )
Translations for a shared library, used by a binary
executing on one node of a CFS system, are invalidated when
accessed on another node. This includes modified private
pages. Any application depending on this private data then
dumps core.
Resolution:
An additional check was introduced in the invalidation
routine invoked by CFS, which checked for and avoided
the invalidation if the file was a shared library.
PHKL_33261:
( SR:8606391584 CR:JAGaf51716 )
Some mmap64(2) requests are not processed correctly.
Resolution:
mmap64(2) requests are now processed correctly.
PHKL_32806:
( SR:8606387618 CR:JAGaf47771 )
CFS semantics guarantees that change in data or metadata of
a vnode being shared across different nodes will be
reflected to all the nodes using this vnode. This is done
by calling a "Virtual Memory" function to perform
invalidation of the data/metadata pages being mapped for
the vnode. The "VM" invalidate function invalidates all the
pages being mapped for this vnode, However there are some
critical information (PLT/DLT tables) for an executable
that should not be invalidated. This is not taken care
currently, leading to a core dump of a process using this
vnode.
Resolution:
The invalidate function is modified to prevent the
critical information from being invalidated. The critical
data is PLT/DLT tables of the executables which are present
in the PT_DATA pages for a process. The invalidate function
is modified to prevent invalidation of the PT_DATA pages.
PHKL_32578:
( SR:8606379142 CR:JAGaf39391 )
This occurs due to a missing validation check for flags
passed with mmap(2).
Resolution:
The resolution is to validate mmap(2) flags across all
processes sharing the memory map.
( SR:8606380135 CR:JAGaf40371 )
This occurs due to an uninitialized value being interpreted
which leads to a Data Page Fault.
Resolution:
The resolution is to initialize the variable before use and
validate the data before interpretation.
PHKL_31003:
( SR:8606354805 CR:JAGaf15561 )
Some mmap(2) requests are not correctly processed.
Resolution:
mmap(2) requests are now processed correctly.
( SR:8606351558 CR:JAGaf12363 )
Under certain circumstances when fork()/mmap() fails, the
system may panic.
In the failure path of fork()/mmap(), the source's region
lock is released before the destination's partially created
region is freed back. Releasing source's region lock creates
a window where vhand() acquires it and pushes valid pages
into swap. Now in the failure path of fork()/mmap(),
freereg() is invoked to release the same pages (COW'd) from
the destination's region. Since destination is not yet
completely setup, it's MRG pointer is NULL which when
referenced leads to a panic.
Resolution:
The solution involves releasing the pages from destination's
region before the source's region lock is released. This
ensures that it is source's responsibility to release
the page to the free memory pool.
PHKL_30616:
( SR:8606341242 CR:JAGaf02151 )
This product update contains minor enhancements required to
enable the HP-UX Mmap-Perf.
Resolution:
Enhancements added to set up the system for loading the
HP-UX Mmap-Perf feature when this product is
configured.
PHKL_30158:
( SR:8606335008 CR:JAGae96085 )
When a process having called mprotect(PROT_NONE) on
private region(s) calls fork(2) system call and if
fork(2) does not succeed due to unavailability of
protection or space ids, it may result in hang.
This is due to freeing the parent process' resources
incorrectly in the fork(2) cleanup path.
Resolution:
Incorrect logic in the fork(2) cleanup path is corrected.
PHKL_28990:
( SR:8606304228 CR:JAGae67573 )
mprotect(2), when called with the PROT_CHECK flag, was
checking access rights on pages from the beginning of the
specified pregion instead of from the pregion offset that
is passed in.
Resolution:
Corrected the access protection checking code to begin at
the given offset instead of at the beginning of the
pregion.
( SR:8606283720 CR:JAGae47665 )
When MPI/HMP applications fork a child process and
make the child exit, the child - which shares the parent's
address space because of the Copy On Write feature of
fork - clears bits incorrectly in the shared pages.
This action leads to data corruption for the parent.
Since the bit is incorrectly cleared, the HMP call
back function is not called when the parent does a
copy-on-write. So, the lowfat code writes new data
to the old page causing data corruption. This defect
exists in the large page (> 4k) code only.
Resolution:
Corrected the code to disallow the child from
incorrectly clearing bits in the shared address space.
PHKL_28428:
( SR:8606267409 CR:JAGae31651 )
The fork() system call does not add the child process
address space to the iomap control structures as intended
when the parent of the fork() has performed an iomap.
Resolution:
Revised the fork() system call to add the child address
space as intended.
( SR:8606267454 CR:JAGae31696 )
The exec() system call re-uses the address space of the
calling process for the target process. If the calling
process had performed an iomap operation (via a device
driver), the mapping is removed from the address space.
However, the address space is not being removed from
the iomap control structures. When the target process
exits, the kernel memory address of this address space
remains in the control structures. This address may now
reference a new kernel structure, kernel data, or memory
which is not in use. Since the use of this reference in
the control structures involves memory reads and writes,
using the invalid reference may cause a kernel panic
or may overwrite kernel or user data.
Resolution:
Perform the removal of such a mapping in the exec()
system call in the same way as an explicit unmap,
ensuring that the address space reference is also
removed.
PHKL_28267:
( SR:8606220721 CR:JAGad89858 ) Duplicate
( SR:8606227157 CR:JAGad96219 )
The reference count for the process' Virtual Address Space
(vas) is not protected from multiple concurrent accesses
by any lock. This results in a race condition and possible
ambiguous value in the reference count. If the reference
count is decremented to zero but the vas is still pointing
to valid pregions that are still in use, the freevas panic
will occur when attempting to free the vas.
Resolution:
The resolution is to lock the vas whenever the reference
count is incremented/decremented, thereby serializing
any changes and maintaining coherency of the reference
count.
PHKL_27278:
( SR:8606262338 CR:JAGae26673 )
There is a race condition between pstat and a function
managing a process address space. This causes the corruption
of the list representing a process address space, leading
to a panic.
Resolution:
The fix consists of enforcing locking even for
single-threaded processes, to protect them from
external pstat requests.
PHKL_26744:
( SR:8606202772 CR:JAGad71946 )
The variable holding the mmap reference count is not checked
for overflow. When the variable resets to zero, the system
panics with a data page fault.
Resolution:
The overflow condition is now detected. The panic is
avoided by returning ENOMEM when the mmap(2) reference count
variable overflows.
PHKL_26386:
( SR:8606186482 CR:JAGad55686 )
This product update contains minor enhancements required to
enable extensions to mmap to allow mapping of I/O registers
or address ranges.
Resolution:
Extended mmap to recognize MAP_IO flag and perform mapping
if functionality is enabled.
PHKL_26233:
( SR:8606230627 CR:JAGad99677 )
Kernel incorrectly handles some of the parameters to
setrlimit.
Resolution:
The kernel is fixed to handle the particular parameters
correctly.
PHKL_25614:
( SR:8606193208 CR:JAGad62420 )
On 64 bit systems, calls to mmap(2) by 32 bit processes with
sizes in the range of 1 GB or greater cause the allocation
algorithm to allocate a segment in the 64 bit address space
instead of the 32 bit address space. The 64 bit address is
truncated to 32 bits on return to the 32 bit calling
process. The cause of this error is an incorrect boundaries
checking in the allocation algorithm. When using a
debugger, one can observe a 64 bit segment in the process
address space.
Resolution:
The allocation algorithm now checks boundary conditions
correctly, producing a correct memory address.
( SR:8606212954 CR:JAGad82141 )
One kernel structure associated with the mapped file is
based on the type of the process address space. Thus a 32
bit process creates a 32 bit mapped file kernel structure.
The kernel structure should be independent from the type of
the calling process.
Resolution:
The creation of the kernel structure associated with a mmap
file has been made independent from the type of the process.
( SR:8606188767 CR:JAGad57983 )
The mmap(2) system call ignores the MAP_GLOBAL flag when
used in combination with the MAP_SHARED and MAP_ANONYMOUS
flags.
Resolution:
Checking for the MAP_GLOBAL option in mmap(2) when the
MAP_ANONYMOUS and MAP_SHARED flags are used. The allocation
is then made from the appropriate quadrant.
( SR:8606205797 CR:JAGad74972 )
This panic results from trying to free the same ID twice as
a result of the system allowing a mapping that overlaps with
an existing mapping of text.
Resolution:
mmap(2) calls with addresses that overlap with existing text
mappings will now fail.
PHKL_25129:
( SR:8606215349 CR:JAGad84536 )
In one corner case the fix for "PHKL_24679" overwrites some
memory beyond the allocated limit for an internal data
structure.
Resolution:
Overwriting of memory is fixed by checking for a corner
case.
PHKL_24679:
( SR:8606201639 CR:JAGad70813 )
When ever a range of virtual address space is allocated for
a thread the OS always searches for a hole from the highest
possible address so as to give maximum possible space for
the heap to grow. When large number of threads are created
and all space in the proximity of the highest address is
occupied it takes a while before the search could get a
hole of required size, which slows down the thread creation
process.
Resolution:
The fix to the problem is to keep a hint for starting the
search next time so we do not have to start always from the
highest address.
PHKL_25227:
( SR:8606188435 CR:JAGad57643 )
The kernel code was limited by design to allow narrow
mode mmap64() to 2GB or less only.
Resolution:
The kernel was enhanced to remove this limitation. Narrow
mode mmap64() can now map up to 4GB.
PHKL_24743:
( SR:8606205558 CR:JAGad74733 ) Duplicate
( SR:8606204858 CR:JAGad74036 )
Unnecessary acquisition and release of region locks in
common execution paths can cause unpredictable performance
degradation.
Resolution:
ltered code path to minimize frequency of region
lock/release in procedures mmap_file_pieces() and
mmap_file_object(). Note that this is only one of the
causes for unpredictable performance degradation in mmap.
PHKL_24073:
( SR:8606189205 CR:JAGad58421 )
This problem was caused by a lock ordering problem between
VM and JFS. JFS can call VM while holding an inode lock;
the routines called may require a vas lock. VM can call JFS
while holding a vas lock; the routines called may require
an inode lock. If we get unlucky, we hit the same vas/inode
lock combination from both directions, and the threads
deadlock. Because the vas lock potentially held by VM is
a per process resource, this situation can only be
encountered by a multithreaded process.
Resolution:
The fix is to have the VM routine drop the vas lock before
calling the file system code; fortunately, the VM routine
can safely drop and reacquire the lock around the call ...
it was mostly holding it to avoid dropping and reacquiring
it repeatedly in a loop.
Enhancement:
No (superseded patches contained enhancements)
PHKL_30616:
Support added for Mmap-Perf
Enhancement to improve the performance of
smmap_hole_file which is called via mmap(2).
The smmap_hole_file improvement will be derived
when this patch will be configured.
PHKL_28428:
Enhancements were delivered in a patch this one has
superseded. Please review the Defect Description
text for more information.
SR:
8606308359 8606186482 8606188435 8606188767 8606189205
8606193208 8606201639 8606202772 8606204858 8606205558
8606205797 8606212954 8606215349 8606220721 8606227157
8606230627 8606262338 8606267409 8606267454 8606283720
8606304228 8606335008 8606341242 8606351558 8606354805
8606379142 8606380135 8606387618 8606391584 8606397870
Patch Files:
ProgSupport.PAUX-ENG-A-MAN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
/usr/share/man/man2.Z/msync.2
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o)
/usr/conf/lib/libvm.a(vm_mmap.o)
/usr/conf/lib/libvm.a(vm_pregion.o)
/usr/conf/lib/libvm-pdk.a(vm_procdup.o)
/usr/conf/lib/libvm.a(vm_vas.o)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o)
/usr/conf/lib/libvm.a(vm_mmap.o)
/usr/conf/lib/libvm.a(vm_pregion.o)
/usr/conf/lib/libvm-pdk.a(vm_procdup.o)
/usr/conf/lib/libvm.a(vm_vas.o)
what(1) Output:
ProgSupport.PAUX-ENG-A-MAN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
/usr/share/man/man2.Z/msync.2:
None
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o):
hdl_policy.c $Date: 2004/12/23 02:57:50 $Revision: r
11.11/4 PATCH_11.11 (PHKL_32578)
/usr/conf/lib/libvm.a(vm_mmap.o):
vm_mmap.c $Date: 2005/10/14 06:41:32 $Revision: r11.
11/16 PATCH_11.11 (PHKL_33988)
/usr/conf/lib/libvm.a(vm_pregion.o):
vm_pregion.c $Date: 2003/04/11 12:42:27 $Revision: r
11.11/6 PATCH_11.11 (PHKL_28990)
/usr/conf/lib/libvm-pdk.a(vm_procdup.o):
vm_procdup.c $Date: 2002/11/21 12:14:20 $Revision: r
11.11/2 PATCH_11.11 (PHKL_28267)
/usr/conf/lib/libvm.a(vm_vas.o):
vm_vas.c $Date: 2004/06/03 05:32:10 $Revision: r11.1
1/7 PATCH_11.11 (PHKL_31003)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o):
hdl_policy.c $Date: 2004/12/23 02:57:50 $Revision: r
11.11/4 PATCH_11.11 (PHKL_32578)
/usr/conf/lib/libvm.a(vm_mmap.o):
vm_mmap.c $Date: 2005/10/14 06:41:32 $Revision: r11.
11/16 PATCH_11.11 (PHKL_33988)
/usr/conf/lib/libvm.a(vm_pregion.o):
vm_pregion.c $Date: 2003/04/11 12:42:27 $Revision: r
11.11/6 PATCH_11.11 (PHKL_28990)
/usr/conf/lib/libvm-pdk.a(vm_procdup.o):
vm_procdup.c $Date: 2002/11/21 12:14:20 $Revision: r
11.11/2 PATCH_11.11 (PHKL_28267)
/usr/conf/lib/libvm.a(vm_vas.o):
vm_vas.c $Date: 2004/06/03 05:32:10 $Revision: r11.1
1/7 PATCH_11.11 (PHKL_31003)
cksum(1) Output:
ProgSupport.PAUX-ENG-A-MAN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
1317553546 3524 /usr/share/man/man2.Z/msync.2
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
3169779172 19004 /usr/conf/lib/libvm-pdk.a(hdl_policy.o)
356232788 32932 /usr/conf/lib/libvm.a(vm_mmap.o)
3259427715 16404 /usr/conf/lib/libvm.a(vm_pregion.o)
1980103915 8576 /usr/conf/lib/libvm-pdk.a(vm_procdup.o)
3939936681 16024 /usr/conf/lib/libvm.a(vm_vas.o)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
867533119 42800 /usr/conf/lib/libvm-pdk.a(hdl_policy.o)
2942735447 72408 /usr/conf/lib/libvm.a(vm_mmap.o)
3818223674 33312 /usr/conf/lib/libvm.a(vm_pregion.o)
2443799411 17144 /usr/conf/lib/libvm-pdk.a(vm_procdup.o)
4062190142 37472 /usr/conf/lib/libvm.a(vm_vas.o)
Patch Conflicts: None
Patch Dependencies:
s700: 11.11: PHKL_33363
s800: 11.11: PHKL_33363
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHKL_33261 PHKL_32806 PHKL_32578 PHKL_31003 PHKL_30616 PHKL_30158
PHKL_28990 PHKL_28428 PHKL_28267 PHKL_27278 PHKL_26744 PHKL_26386
PHKL_26233 PHKL_25614 PHKL_25227 PHKL_25129 PHKL_24743 PHKL_24679
PHKL_24073 PHKL_33270
Equivalent Patches: None
Patch Package Size: 190 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_33988
5. Run swinstall to install the patch:
swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHKL_33988.depot
By default swinstall will archive the original software in
/var/adm/sw/save/PHKL_33988. 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_33988.text file is
available in the product readme:
swlist -l product -a readme -d @ /tmp/PHKL_33988.depot
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHKL_33988.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
|
Printable version
