 |
» |
|
|
|
|
|
|
|
|
|
Patch Name: PHKL_27994
Patch Description: s700_800 11.00 Probe,IDDS,PM,VM,PA-8700,AIO,T600,FS,PDC
Creation Date: 02/10/17
Post Date: 02/11/25
Hardware Platforms - OS Releases:
s700: 11.00
s800: 11.00
Products: N/A
Filesets:
OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP
Automatic Reboot?: Yes
Status: General Superseded
Critical:
Yes
PHKL_27994: HANG
Intermittent system hangs for several minutes.
PHKL_27919: PANIC
PHKL_27759: PANIC
PHKL_27157: ABORT CORRUPTION
PHKL_26800: HANG
Hang - Filesystem or Process Hang
PHKL_25906: PANIC
PHKL_25525: HANG
PHKL_25210: PANIC CORRUPTION
PHKL_25188: PANIC
PHKL_25164: PANIC
PHKL_24612: ABORT
PHKL_24457: PANIC
PHKL_24273: PANIC
The system panics when r_refcnt overflows
PHKL_24116: OTHER
Hung, Unkillable Process
PHKL_24015: PANIC
PHKL_23857: CORRUPTION
PHKL_23813: PANIC
PHKL_23812: HANG
PHKL_23406: OTHER
Hung, Unkillable Process
PHKL_23183: OTHER
A program that uses probe instruction will cause
signal handler to be removed. It will cause a
non-access reference to an invalid virtual memory
address causing SIGSEGV handler to be removed.
So, the application's signal handler is not
invoked and it does not know what to do.
PHKL_22493: PANIC
PHKL_21775: HANG
PHKL_21507: PANIC
PHKL_20439: PANIC MEMORY_LEAK
PHKL_22744: PANIC
PHKL_22549: PANIC
PHKL_22380: PANIC HANG
PHKL_22126: PANIC
PHKL_21781: PANIC CORRUPTION
PHKL_21624: HANG
PHKL_21600: PANIC
PHKL_20647: HANG
PHKL_20449: PANIC
PHKL_20223: PANIC
PHKL_21354: PANIC
PHKL_20335: CORRUPTION
PHKL_20222: MEMORY_LEAK
PHKL_20017: OTHER
Causing degradation in I/O performance of the
system.
PHKL_19314: HANG
PHKL_19201: HANG
PHKL_20836: PANIC
PHKL_20515: PANIC
Category Tags:
defect_repair hardware_enablement enhancement
general_release critical panic halts_system corruption
memory_leak
Path Name: /hp-ux_patches/s700_800/11.X/PHKL_27994
Symptoms:
PHKL_27994:
( SR:8606254033 CR:JAGae18365 )
This problem is limited to customers who have enabled the
kernel preemption point feature. Whenever preemption is
turned on, the system hangs intermittently for several
minutes.
PHKL_27919:
( SR:8606265366 CR:JAGae29684 )
System panic early in the boot process with
"alloc_pdc_pages: real_page_alloc_addr() fails, status = -1"
PHKL_27759:
( SR:8606268349 CR:JAGae32588 )
When the tunable maxswapchunks is manually set to a value
higher than 16384, the system may panic with a stack trace
similar to:
mp_b_sema_sleep: blocking on owned semaphore
panic+0x14
_mp_b_sema_sleep+0x88
hash_insert+0x144
addtocache+0x50
swapchunk+0x1ec
devswap_pageout+0x1c0
stealpages+0x6c
vhand+0x2a8
main+0xa04
$vstart+0x48
$locore+0x94
PHKL_27364:
( SR:8606256133 CR:JAGae20448 )
In a multi-threaded process, if one thread is doing raw
or character device I/O, other threads in the process
may fail to make forward progress until the I/O completes.
PHKL_27238:
( SR:8606237263 CR:JAGae06308 )
Requests for an exclusive mapping of a file in the 3rd
quadrant fail for all executables with a private 3rd
quadrant. Such executables are usually obtained through
a chatr command with the parameter "+q3p enabled".
PHKL_27157:
( SR:8606244346 CR:JAGae10833 )
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.
PHKL_26800:
( SR:8606241742 CR:JAGae09000 )
Processes may hang uninterruptibly during filesystem access.
The type of filesystem is irrelevant - the hang may occur on
any block filesystem access. Once this process hang occurs,
no other processes will be able to access the file system.
PHKL_25906:
( SR:8606226665 CR:JAGad95728 )
On systems with large pages, the kernel can panic
during the remapping of buffers from kernel to user (or
vice versa). The panic stack trace may be similar to
one of the following :
panic+0x14
hdl_remap_bp+0x130
nfs_strat_map+0x84
nfs_strategy+0x3ac
nfs3_strategy+0x18
...
copyin+0xac
uiomove+0x3dc
rw3vp+0x29c
nfs3_write+0xf8
nfs3_rdwr+0xd8
vno_rw+0xb0
write+0x28c
syscall+0x550
syscallrtn+0x0
or possibly
panic+0x14
report_trap_or_int_and_panic+0x4c
trap+0xa08
call_trap+0x38
div2I+0x15c
hdl_remap_bp+0x29c
...
nfs_biodone+0x3c
async_daemon+0x38c
coerce_scall_args+0x9c
syscall+0x1c8
syscallrtn+0x0
PHKL_25525:
( SR:8606186963 CR:JAGad56173 )
On systems using NFS in loopback mode, there exists the
possibility of the system hanging due to a deadlock
between NFS daemons and inode locks held at the filesystem
(VxFS) level.
PHKL_25210:
( SR:8606216082 CR:JAGad85253 )
During normal operation, the system may experience a
"freevas: vas cnt 0, but still pointing to pregions"
panic. The panic stack trace may be similar to:
panic+0x14
freevas+0x140
freeproc+0x204
wait1+0x21c
waitpid+0x34
syscall+0x1c8
$syscallrtn+0x0
( SR:8606188767 CR:JAGad57983 )
When mmap is used with both the MAP_ANONYMOUS and MAP_GLOBAL
flags, addresses allocated are in the 3rd quadrant instead
of being in the 4th quadrant (shared quadrant) as requested
by the MAP_GLOBAL flag.
PHKL_25188:
( SR:8606194618 CR:JAGad63826 )
On K-Class and slower systems, Service Guard may TOC the
system when a process that uses more than a gigabyte of
memory exits. The stack trace of the TOC may look similar
to the following:
pdc_call+0x174
hversion_pdc_call+0xa4
diag2_ioctl+0x170c
spec_ioctl+0xac
vno_ioctl+0x90
ioctl+0x1e4
syscall+0x394
syscallinit+0x54c
or
pdc_call+0x198
pa_generic_psm_pdc_rtc+0x34
psi_rtc+0xb4
checkclock+0x24
invoke_callouts_for_self+0xc0
sw_service+0xb0
mp_ext_interrupt+0x150
ihandler+0x904
splnopreempt+0x8
idle+0x504
swidle+0x20
( SR:8606137149 CR:JAGad06267 )
The system panics with a data memory protection fault when
mmap(2) is used. The stack trace would look similar to the
following:
panic+0x14
report_trap_or_int_and_panic+0x84
trap+0x4b8
nokgdb+0x8
b_sema_enqueue+0x38
<... various other entries ...>
hdl_changerange+0x238
hdl_mprotect+0x150
smmap_hole_anonymous+0x26c
smmap_common+0x3bc
smmap+0x1c0
syscall+0x9fc
$syscallrtn+0x0
PHKL_25164:
( SR:8606204721 CR:JAGad73900 )
A HPMC may occur on T600 (9000/893) systems when cache flush
code is executing. A stack trace may looks similar to the
following:
fdc_one_page_2_0+0x180
fdcache_conditionally+0x90
pdd_large_page2_0+0x1f0
pddpage+0x2d4
hdl_deletetrans+0xbc
do_deltransc+0x118
for_val2+0xb4
foreach_chunk+0x3c
hdl_detach+0x210
detachreg+0x80
kissofdeath+0x64
freethread+0x14c
thread_deallocate+0x94
thread_free+0x94
wait1+0x244
waitpid+0x38
syscall+0x200
syscallinit+0x54c
PHKL_24971:
( SR:8606195331 CR:JAGad64535 )
Doing memory management activities on a large memory segment
which was registered using asynchronous I/O driver, would
take higher number of CPU cycles.
PHKL_24826:
( SR: 8606185728 CR: JAGad54930 )
Narrow mode (32bit) HP-UX 11.00 programs cannot mmap64() any
part of a large file beyond the first 2GB.
PHKL_24612:
( SR: 8606198933 CR: JAGad68122 )
Random process core dumps.
PHKL_24457:
( SR: 8606180059, CR: JAGad49281 )
When using the asyncio driver, applications may exhibit slow
startup time.
( SR: 8606179580, CR: JAGad48804 )
A system panic occurs on process termination, if the process
had registered private memory segment with asyncio driver.
The stack trace will appear as follows:
crash event was a panic
panic+0x14
report_trap_or_int_and_panic+0x84
trap+0xd9c
nokgdb+0x8
asyncdsk_close+0x94
call_open_close+0x1f8
closed+0xb0
spec_close+0x54
vn_close+0x48
vno_close+0x20
closef+0x64
exit+0x1108
psig+0x244
syscall+0x810
$syscallrtn+0x0
( SR: 8606195629, CR: JAGad64833 )
Slow application startup when using asyncio driver
( SR: 8606199485, CR: JAGad68671 )
On systems experiencing low memory conditions, applications
registering memory segments with asyncio driver may get
"Not owner" (EPERM) error.
PHKL_24273:
( SR:8606199847 CR:JAGad69033 )
A user creates a 64-bit program which mmaps a file
65536 times, then exists. It caused data page fault
in freereg() when referencing the region whose
r_refcnt overflowed since it's already freed and
its fields are not valid any more.
Stack trace looks like:
panic+0x14
report_trap_or_int_and_panic+0x84
trap+0xd9c
nokgdb+0x8
hdl_vfault+0x50
vfault+0xf8
trap+0x2a0
nokgdb+0x8
PHKL_24116:
( SR: 8606192498 DTS: JAGad61711 )
When the debugger is killed or sent a signal when trying to
attach to a process, that process will be left in a hung
state.
PHKL_24015:
( SR: 8606192072 DTS: JAGad61280 )
When using memory windows and shared memory (IPC_SHARE32)
between 32 and 64bit processes, the system may panic with
an "hdl_pfault: invalid DBD for intransit page" panic. The
stack trace may look like:
panic+0x14
hdl_pfault+0x638
pfault+0x104
trap+0x724
thandler+0xd20
PHKL_23857:
( SR: 8606178349 DTS: JAGad47576 )
Data corruption can occur when Hyperfabric networking
interface or async I/O driver is being used in the system.
PHKL_23813:
( SR: 8606188675 DTS: JAGad57891 )
When booting 11.00 on a PA-8700 system, the system panics
with the following message :
panic: set_machine_parameters_64: Unidentified cpu type
returned from PDC_MODEL
Panic stack trace:
PC-Offset Stack Trace (read down, top of stack is 1st):
panic+0x54
set_machine_parameters_64+0x1f8
rm_setmachineparams_64+0x40
DoCalllist+0x50
RDB_patch_int_trap+0xb0
End Of Stack
WARNING: Space ID hashing is disabled
PHKL_23812:
(SR: 8606183443 CR: JAGad52656)
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.
PHKL_23628:
(SR: 8606146888 CR: JAGad16231)
If the process core file's size limit has been set to 0 in
setrlimit(), when the process aborts, the core processing
is incorrect.
PHKL_23406:
(SR: 8606103740 CR: JAGab70789)
(SR: 8606159451 CR: JAGad28779)
A multi-threaded process being executed over NFS can become
hung and unkillable while performing either a fork, core,
setrlimit, SIGSTOP, or debugger operations.
PHKL_23183:
(SR: 8606169539 CR: JAGad38814)
An application trying to do a PROBE instruction
results in non-access reference to an invalid
virtual memory address that causes the SIGSEGV
handler to be removed.
This makes an application program's own
error-recovery useless and results in database
crashes.
PHKL_22843:
(SR: 8606162188 CR: JAGad31504)
The output of "ps -f" shows the name of the script being
runs instead of the name of the '#!' interpreter.
(SR: 8606168950 CR: JAGad38228)
When the user exec a script w/o providing the arguments,
the kernel does not exec the shell as it should be
expected to do.
For example,
execve("./t.sh", 0) will not work.
t.sh:
~~~
#!/bin/ksh
echo t.sh script executed OK.
PHKL_22493:
(SR: 8606141875 CR: JAGad11229)
When not running as root, adb will panic the system when
an attempt is made to debug a kernel-threaded application
in which the first thread is in a ZOMBIE state.
panic: Data page fault
stack trace for event 0
crash event was a panic
panic+0x14
report_trap_or_int_and_panic+0x80
trap+0xdb8
nokgdb+0x8
handle_ooc_requests+0x2bc
perform_trace_request+0x260
ttrace1+0x13c
ptrace+0x78
syscall+0x480
$syscallrtn+0x0
PHKL_22032:
(SR: 8606146888 CR: JAGad16231)
Once-setuid/setgid processes could create corefiles or be
attached to with a debugger.
(SR: 8606146889 CR: JAGad16232)
IDDS generated incorrect records in certain cases
PHKL_21775:
Some processes (eg . created by Shared LVM) never get
reaped leading to proc table being filled and leading
to a system hang.
PHKL_21507:
( SR: 8606113684 CR: JAGac07198 )
system panics when doing crfree
panic: crfree: freeing free credential struct
Stack trace for crash event was :
q4> trace event 0
stack trace for event 0
crash event was a panic
panic+0x14
crfree+0xc4
kthread_shared_objects_update+0x30
syscall+0x594
$syscallrtn+0x0
PHKL_21358:
( SR: 8606132621 CR: JAGad01770 )
The Praesidium IDS/9000 product requires this patch in order
to run. This patch has no impact on systems without the
Praesidium IDS/9000 product installed and enabled.
PHKL_21350:
( SR: 8606132613 CR: JAGad01762 )
The Praesidium IDS/9000 product requires this patch in order
to run. This patch has no impact on systems without the
Praesidium IDS/9000 product installed and enabled.
PHKL_20439:
( SR: 8606109770 DTS: JAGaa45170 )
While running an MPI-based program, the system panics with a
"Data page fault" or other memory-related fault.
PHKL_20226:
( SR: 8606107525 DTS: JAGab77768 )
This patch is one of 8 patches necessary to add support
for the 3 Gb private address space feature.
PHKL_21535:
( SR: 8606100830 CR: JAGab39185 )
Application core files do not include the process' attached
shared memory segments.
PHKL_21357:
( SR: 8606132620 CR: JAGad01769 )
The Praesidium IDS/9000 product requires this patch in order
to run. This patch has no impact on systems without the
Praesidium IDS/9000 product installed and enabled.
PHKL_22744:
( SR: 8606161365 CR: JAGad30681 )
A system may experience a data page fault panic with the
following stack trace:
panic+0x14
report_trap_or_int_and_panic+0x80
trap+0xdb8
nokgdb+0x8
thread_pcb_reinit+0x30
thread_alloc+0xe8
thread_create+0x2ac
_lwp_create+0xdc
syscall+0x480
$syscallrtn+0x0
PHKL_22549:
( SR: 8606128066 DTS: JAGab24436 )
Data page fault when trying to flush buffers
which have already been invalidated:
bwrite+0x44
bxwrite+0x44
syncip_flush_cache+01x1dc
vx_flushdev+0x14
vx_fsync+0x248
spec_fsync+0x254.
PHKL_22440:
( SR: 8606154274 CR: JAGad23592 )
When trying to attach to a process that has been swapped
out, both the tracing process and traced process hang and
remain in an unkillable state.
PHKL_22380:
(SR: 8606130240 DTS: JAGac95111)
Kernel paniced with data memory protection fault. This
could happen when using direct I/O on JFS version 3.3
or in other situations.
(SR:8606139945 DTS: JAGad09268)
MP System hang under heavy I/O load.
PHKL_22126:
( SR: 8606155209 DTS: JAGad24526 )
This patch is a replacement for the recalled patch
PHKL_21624 which addressed a system hang caused by memory
scrubber operating on shared memory segment used by the
async I/O driver. The following problems were introduced by
PHKL_21624 and are resolved by this patch.
1. System panic when both Hyperfabric networking interface
and async I/O driver are used on the same system with
PHKL_21624 installed.
2. Applications fail when trying to register shared
segments with async I/O driver. On failure errno is set to
EPERM.
( SR: 8606143996 DTS: JAGad13329 )
Excessive delay in database connect time for database user
processes.
PHKL_21781:
(SR: 8606137220 DTS: JAGad06338)
when a user application makes a large number (over 65535)
of mprotect(2) calls, it fails with ENOSPC - No space left
on device.
(SR: 8606136222 DTS: JAGad05348)
When sendfile_max is configured to be > 0, and when using
ftp or rcp to transfer data, we encounter a spinlock
deadlock panic in sendfile_hold().
A stack trace will look similar to:
panic
spin_deadlock_failure
deadlock_check
sl_pre_check
spinlock
sendfile_hold
sosendfile
sendfile
syscall
PHKL_21624:
(SR: 8606124290 DTS: JAGac39673)
Memory scrubber (memlogd) causes system hang while scrubbing
pages locked by async driver. The async driver is typically
used by database applications.
( SR: CR: JAGab16247 )
HP-UX does not support an interface that allows a driver to
lock user space memory on behalf of a user process in such
a way that prevents the user process from unlocking the
memory. Such a mechanism is required to enable DMA to user
space memory by the operating system (a driver).
PHKL_21600:
(SR: 8606134430 DTS: JAGad03565)
When using mmap with a negative offset or an offset greater
than 2^43, the system panics.
PHKL_20647:
(SR: 8606107024 DTS: JAGab76631)
System hang in b_sema_get_queue() when doing an munmap().
PHKL_20449:
(SR: 8606106816 DTS: JAGab76230)
Incorrect implementation of mmap(2) can cause system panics.
PHKL_20223:
( SR: 8606103245 DTS: JAGab69733)
The system will panic with the following message:
panic: Returning ID that is already free.
( SR: 8606107525 DTS: JAGab77768)
This patch is one of 8 patches necessary to add support
for the 3 Gb private address space feature.
PHKL_21532:
( SR: 8606131990 CR: JAGad01139 )
Approximately every 22 minutes, the system, or one cpu of a
multi-processor system, appears to hang for several minutes.
Then the problem goes away. This primarily affects larger
memory systems.
PHKL_21354:
( SR: 8606132598 CR: JAGad01747 )
After PHKL_21003 is installed on a V2500 or V2600 with at
least 24 CPUs and at least 24 GB of memory, the system fails
to boot. One symptom that has been observed is the
following message displayed during the boot process:
Error found :
- mem_toc zero error encountered.
( SR: 8606132617 CR: JAGad01766 )
The Praesidium IDS/9000 product requires this patch in order
to run. This change has no impact on systems without the
Praesidium IDS/9000 product installed and enabled.
PHKL_21024:
( SR: 8606112164 DTS: JAGab84450 )
Enhancement: Performance changes for corner case in RTSCHED
scheduling. This patch has no impact on most systems.
PHKL_21003:
( SR: 8606112473 CR: JAGab84822 )
V2500 with more than 24GB of memory and more than 24
processors takes a long time (>30min) to boot.
PHKL_20335:
( SR: 8606106466 DTS: JAGab75600)
Unlinked files within NFS filesystems sometimes leave behind
.nfsXXX files which are unremovable until after the system
is rebooted.
( SR: 8606107384 DTS: JAGab77587)
Panic or data corruption due to buffer cache buffers being
released multiple times.
( SR: 8606108724 DTS: JAGab78191)
Memory corruption after copying growing files over the
network multiple times.
PHKL_20222:
( SR: 8606107507 DTS: JAGab77743)
This patch adds support for the PA-8600 processor.
( SR: 8606107525 DTS: JAGab77768)
This patch is one of 8 patches necessary to add support for
the 3 Gb private address space feature.
PHKL_20102:
( SR: 8606106969 DTS: JAGaa45096 )
On systems with 5GB of memory or more, the system will
allocate memory for a static table that it does not use.
This affects 64-bit systems only.
PHKL_20017:
( SR: 8606104415 DTS: JAGab71916)
After installing PHKL_19314, I/O performance of the system
drops substantially.
( SR: 8606103778 CR: JAGab70853 )
64bit systems with large amount of memory (e.g. 32Gb) and
having large buffer cache (e.g. 8Gb) configured find the
syslog is flooded with the following error message:
vmunix : bufmap : rmap : ovflo, lost [xx..)(xx..]
PHKL_19314:
( SR: 4701426775 DTS: JAGab17440 )
On a system with a large number of processors (more than 14)
a hang can occur during boot and after displaying the
following messages:
Starting the STREAMS daemons-phase1
Checking root filesystem
log replay in progress
replay complete - marking super-block clean
Root check done
Create STCP device files
( SR: 8606101604 DTS: JAGab15954)
Attempting to resume from a breakpoint when running a
program under a debugger will cause the program to get a
segmentation violation. This has been seen on G-class
systems but it can occur on any system with block-tlb.
PHKL_19201:
SR: 8606100898 DTS: JAGab39707
A user sees a hang while using snapshot file systems.
Stack trace:
_swtch+0xd4
_sleep_one+0x538
vx_sleep_lock+0xd0
vx_snap_bpcopy+0xf4
vx_snap_copyblk+0x144
vx_snap_copy+0x50
vx_snap_strategy+0x280
vx_buf_strategy+0x24
bwrite+0xe0
getnewbuf+0x918
allocbuf1+0x234
brealloc1+0x5c
getblk1+0x2fc
vx_snap_getblk+0x2c
vx_snap_getblkbp+0x140
vx_snap_lookup+0x1c
vx_snap_bpcopy+0x110
vx_snap_copyblk+0x144
vx_snap_copy+0x50
vx_snap_strategy+0x280
vx_buf_strategy+0x24
bwrite+0xe0
getnewbuf+0x918
ogetblk+0x110
getblk1+0x290
vx_getblk+0x50
vx_bread+0x68
vx_iread+0x88
vx_real_iget+0x398
vx_iget+0x3c
vx_dirlook+0x23c
vx_lookup+0x120
locallookuppn+0xd4
lookuppn+0xf8
lookupname+0x40
vn_open+0x68
copen+0xd0
open+0x3c
syscall+0x480
$syscallrtn+0x0
PHKL_17038:
The system will trap 15 data page fault when tracing for
leaks without also tracing for corruption.
PHKL_20945:
( SR: 8606112164 DTS: JAGab84450 )
Enhancement: Performance changes for corner case in RTSCHED
scheduling. This patch has no impact on most systems.
PHKL_20995:
( SR: 8606127692 CR: JAGac78494 )
Programs using "memory windows" (started via setmemwindow)
will not be able to allocate more than 1 Gb of shared memory
(1 Gb total for all memory windows processes, i.e. this is
not a per process limit). This patch is a replacement for
PHKL_20227, which introduced the bug that this patch
fixes.
PHKL_20836:
( SR: 8606106781 CR: JAGab76169 )
Application issuing large amount of mmap calls to
map multiple virtual addresses to the same physical
page (using flags MAP_SHARED|MAP_FILE|MAP_FIXED)
may cause system panic with the follow stack trace:
panic: hdl_zero_page: page not mapped
panic+0x14
hdl_zero_page+0xc8
virtual_fault+0x418
vfault+0x118
trap+0x280
nokgdb+0x8
Trace on other processor shows:
panic+0x14
report_trap_or_int_and_panic+0x80
trap+0xde8
nokgdb+0x8
allocpfd_from_pond+0x134
allocate_page+0x68
lgpg_vfdfill+0x4c
virtual_fault+0xc3c
vfault+0x118
trap+0x280
nokgdb+0x8
PHKL_20227:
( SR: 8606107525 CR: JAGab77768 )
This patch is one of 8 patches necessary to add support
for the 3 Gb private address space feature.
PHKL_20224:
( SR: 8606107525 CR: JAGab77768 )
This patch is one of 8 patches necessary to add support
for the 3 Gb private address space feature.
PHKL_20515:
(SR: 8606101315, CR: JAGab46368)
System hang while using async I/O module through database
applications with new large block I/O feature when system
is low on memory resources.
(SR: 8606100970, CR: JAGab39977)
Data pagefault during async I/O operations when an I/O is
being done to an unregistered (private) memory.
(SR:8606103126, CR: JAGab69473)
System hang can occur during async I/O operations when an
IO is being done to an unregistered (private) memory
segment designated by the user's IO buffer.
(SR: 8606102862, CR: JAGab68892)
Async driver can hang during async IO with requests larger
than MAXPHYS (allowing async I/O larger than MAXPHYS is a
new feature available in this patch, where MAXPHYS = 256KB).
(SR: 8606108814, CR: JAGab81517)
Async driver I/O completion notifications don't work when
used in conjunction with select(2) system call.
PHKL_20426:
When a multithreaded process does file I/O concurrently with
mmap() or munmap() on the same file, it can result in a
single process deadlock. This process is not killable.
Defect Description:
PHKL_27994:
( SR:8606254033 CR:JAGae18365 )
Preemption feature does not scale well with large memory
objects. So, vhand is affected when working on those objects
and may slow down significantly. This leads to the system
being unresponsive for several minutes.
Resolution:
Remove some unnecessary checking for preemption,
thus improving the performance of vhand for large objects.
This does not take away the effectiveness of the preemption
feature.
PHKL_27919:
( SR:8606265366 CR:JAGae29684 )
If relocating PDC from ROM to main memory fails due to bad
physical memory, the system panics. The panic message does
not adequately describe the reason for the panic.
Resolution:
Made alloc_pdc_pages more flexible. If an allocation
attempt fails, the requested memory range will be shifted to
a lower range of address. This will continue until a
successful allocation, or if 16 attempts are made the system
will panic. The panic message is improved by providing
additional information.
PHKL_27759:
( SR:8606268349 CR:JAGae32588 )
The internal swap table is sized on the value of the
maxswapchunks tunable. However, the maximum value of
the index used to access the swap table is 16384. If
SAM is used to build a kernel, the maximum value of
16384 for maxswapchunks is enforced, but if the system
file is edited and a new kernel built manually, there
were no checks on the size of maxswapchunks. If the
value was above 16384, the swap table would be sized
too large for the index and multiple virtual pages
could be allocated to the same swap block, resulting
in the panic.
Resolution:
We now check the value of maxswapchunks at boot time and
limit it to the maximum value of 16384.
PHKL_27364:
( SR:8606256133 CR:JAGae20448 )
The raw I/O routine was holding the process' virtual
address space (vas) lock for the duration of the I/O,
even though it was not needed for the normal case and
only rarely needed for an exception case. This effectively
blocked any other thread in the process which needed access
to the vas lock, such as for another I/O, thread creation,
mmap, thread exit, etc., for the duration of the I/O.
When the I/O was to a slow device, such as a tape drive,
this could be a considerable delay.
Resolution:
Eliminated use of the vas lock in the normal raw or
character device I/O path, retaining its usage only for
the rare exception case.
PHKL_27238:
( SR:8606237263 CR:JAGae06308 )
The parameter checking code in mmap incorrectly rejects
requests with the MAP_EXCLUSIVE flag, for the 3rd quadrant
regardless if this quadrant is private or not.
Resolution:
The mmap code has been modified to accept exclusive mappings
in the 3rd quadrant when it is private.
PHKL_27157:
( SR:8606244346 CR:JAGae10833 )
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.
PHKL_26800:
( SR:8606241742 CR:JAGae09000 )
The problem is caused by a thread/process waiting on a
buffer that it incorrectly believes is still owned by
another process. The previous process failed to update the
internal data structure used to show that the buffer is no
longer in use. The new process sees this stale information,
goes to sleep believing that the buffer is still in use, and
never wakes up, which results in a filesystem hang. This
was seen with a process accessing a VxFS 3.3 filessytem with
Veritas NetBackup running. However, this defect is not
specific to any one filesystem; it applies to all block
filesystem access.
Resolution:
Changed the code to modify the internal data to indicate
the buffer is no longer in use before releasing the buffer
and doing the wakeup.
PHKL_25906:
( SR:8606226665 CR:JAGad95728 )
When the remapping of a large page based buffer occurs,
its boundaries are adjusted to match the large page.
The round up of the boundaries was incorrect causing the
kernel to fault during the remapping.
Resolution:
The adjustment of large pages aligned boundaries is
modified to ensure the correct remapping of large page
based buffers.
PHKL_25525:
( SR:8606186963 CR:JAGad56173 )
An NFS daemon (nfsd) grabs a directory inode lock and
then tries to acquire a free buffer from the buffer-cache.
For this new buffer, a reference release (vn_rele) must
first be performed for the old vnode associated with the
buffer. This vn_rele causes a .nfsXXX file removal to
occur. A second nfsd attempts to perform the file removal,
but in order to do so it must acquire the same directory
inode lock that the first nfsd is holding. This deadlock
ultimately effects other processes that start getting
blocked behind the directory inode until the system
gradually grinds to a halt.
Resolution:
The buffer-cache code will change to ensure that no invalid
NFS buffers remain in the cache with associated vnodes
thereby eliminating the potential of a locking deadlock
occurring.
PHKL_25210:
( SR:8606216082 CR:JAGad85253 )
The vas was corrupted due to unprotected modifications of
the vas reference count on a vfork.
Resolution:
Lock the vas during modification of the vas reference
count.
( SR:8606188767 CR:JAGad57983 )
The mmap system call does not take the MAP_GLOBAL flag into
account when used in combination with the MAP_ANONYMOUS
flag.
Resolution:
Check for the MAP_GLOBAL flag in mmap when the MAP_ANONYMOUS
flag is used, and allocate the address in the proper
quadrant (4th).
PHKL_25188:
( SR:8606194618 CR:JAGad63826 )
The problem is caused by an exiting process flooding the
bus with cache flush instructions. This in turn may cause
processes executing firmware code to wait until the
exiting process is finished before continuing. If the
Service Guard process is scheduled behind the process
executing the firmware code, the Service Guard process may
not have the chance to run for many seconds, causing it to
TOC the system when it does eventually run.
Resolution:
The exiting process now does its cache flushing less
aggressively and allows processes executing firmware code to
run at the same time. If such processes are allowed to run,
the Service Guard process scheduled after those processes
will be able to maintain contact with the other Service
Guard nodes in the cluster and it will not TOC the system.
( SR:8606137149 CR:JAGad06267 )
There is an invalid boundary check in the mmap(2) system
call that allows protections to be set outside a valid range
of pages. This causes a panic when subsequent mmap(2),
mprotect(2), or munmap(2) calls are made on the same range
of adresses.
Resolution:
The mmap(2) system call now correctly checks the boundaries
of the range of adresses before applying a mprotect
operation on them.
PHKL_25164:
( SR:8606204721 CR:JAGad73900 )
This defect is caused by JAVA chip arbitration bug. This
bug favors the sequential cache flush code over memory
access requests and outstanding I/O requests (from FWSCSI)
will time out and cause an HPMC.
Resolution:
The sequential cache flush code was modified to periodically
provide a time slot for the I/O requests to finish.
PHKL_24971:
( SR:8606195331 CR:JAGad64535 )
Upon removing the last process reference to a shared memory
segment on a memory unlock, the segment is demoted from
64MB pages to 4K pages. Any subsequent attempts to manage
this segment take considerable amount of time as the
number of page management structures has now been increased
by 16K times.
Resolution:
Do not demote the largepages on doing a memory unlock.
PHKL_24826:
( SR: 8606185728 CR: JAGad54930 )
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_24612:
( SR: 8606198933 CR: JAGad68122 )
The VM subsystem was not correctly handling self-modifying
code pages that were not initially mapped with execute
access. There was a possibility that execute access could
be removed, leaving stale data in the instruction cache.
When the page was subsequently reused by another process,
it would fault on the stale instruction cache data.
Resolution:
If a page has execute access, retain the execute access
when adding a new translation. This ensures the data is
flushed from the instruction cache upon page deallocation.
PHKL_24457:
( SR: 8606180059, CR: JAGad49281 )
Before starting I/O's through the asyncio driver,
applications must register shared memory segments with the
driver. As part of the registration, the driver locks the
memory. If this operation needs to be done for a very
large memory segment, the locking may take a significant
amount of time, resulting in slow application startup.
Resolution:
The async driver now supports a new device file minor number
256. If an application uses the async device file with this
new minor number, the driver will defer locking the memory
until I/O's are issued. This avoids the overhead of memory
setup time and thus reduces the application startup time.
Note: This minor number should only be used on systems that
have enough physical memory so that paging is avoided.
Paging can cause serious performance degradation with this
new enhancement. On systems where paging is an issue, this
minor number should not be used.
( SR: 8606179580, CR: JAGad48804 )
When process that registered private memory with asyncio
driver terminates, the memory management subsystem cleans
the associated data structure. The asyncio driver tries to
dereference a pointer to one of these data structures that
has already been freed causing the system to panic.
Resolution:
The driver returns bad address (EFAULT) if any application
tries to register a private memory segment.
( SR: 8606195629, CR: JAGad64833 )
The asyncio driver checks for the user access rights
twice. This duplication of access rights check
contributes to slow application startup.
Resolution:
The redundant access rights check is removed.
( SR: 8606199485, CR: JAGad68671 )
The asyncio driver propagates the wrong error code to the
application when a memory locking function fails due to
low memory conditions.
Resolution
The appropriate error code is returned to the application.
PHKL_24273:
( SR:8606199847 CR:JAGad69033 )
The system panic's while trying to mmap() more than
the maximum allowed limit of pregions to a shared
region. (limited by r_refcnt, which is of type
ushort). This was caused by r_refcnt overflow which
caused it to reset. If a program mmap's more than
this limit, the counter r_refcnt overflow which
causes the system to panic.
Resolution:
The fix is to check for the overflow and return ENOMEM.
PHKL_24116:
( SR: 8606192498 DTS: JAGad61711 )
If the debugger is interrupted while trying to attach to a
single threaded process that is sleeping uninterruptibly,
it will return to the user without unsuspending the
debuggee so the debuggee's suspend count is not decremented
and the debuggee will be suspended forever.
Resolution:
ttrace_prepare_attach() now checks the return from the
sleep of the debugger. If the sleep returns an error, we
know that the debugger has been interrupted by someone
else other than the debuggee so we decrement the suspend
count of the debuggee.
PHKL_24015:
( SR: 8606192072 DTS: JAGad61280 )
A 64bit process cannot map into a private memory window -
it can only map into the global memory window of the
32bit virtual space. A 32bit process needing to share
with a 64bit process must either be mapped into the
global memory window or the object to be shared must
be marked IPC_GLOBAL. These rules were not being
enforced, resulting in incorrect space id assignment
for shared memory (IPC_SHARE32) allocated in a private
memory window.
Resolution:
Shared memory (IPC_SHARE32) allocated in a private memory
window is now remapped into the global memory window when
sharing with a 64bit process.
PHKL_23857:
( SR: 8606178349 DTS: JAGad47576 )
Kernel sub-systems such as Hyperfabric networking
interface and async I/O expect to be notified when a
translation for a page changes that they are using
for DMA. The virtual memory system uses the
cluster-interconnect flag to determine if such sub-systems
should be notified when the translation changes. If there
are two different kernel-locked ranges in the same
largepage, the unlocking of first locked range causes the
cluster-interconnect flag for that page to be cleared, even
though there is another locked range in the same page. This
could cause a DMA operation to occur on the wrong page,
resulting in data corruption, if sub-systems continued to
do DMA on that page.
Resolution:
A check is added to see if there are other kernel-locked
ranges in the same largepage before clearing the
cluster-interconnect flag.
PHKL_23813:
( SR: 8606188675 DTS: JAGad57891 )
11.00 does not recognize the PA-8700 processor.
Additionally, the PA-8700 processor is not IO-PDIR coherent.
Resolution:
This patch, PHKL_23813, is one of three 11.00 PA-8700
enablement patches. The other 11.00 PA-8700 enablement
patches are PHKL_23814 & PHKL_23815. To support 11.00 on
PA-8700, the following changes were made :
- Added code to recognize the PA-8700 processor.
- Added code to check if non-coherent IO-PDIR is set and
performed flushes and syncs whenever IO-PDIR is changed.
- Fixed inverted space hash mask to enable the PA-8700
processor.
PHKL_23812:
(SR: 8606183443 CR: JAGad52656)
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.
PHKL_23628:
(SR: 8606146888 CR: JAGad16231)
If the process core file's size limit has been set to 0 in
setrlimit(), when the process aborts, the core processing
is incorrect.
Resolution:
If the process core file size limit has been set to zero,
don't create a core file.
PHKL_23406:
(SR: 8606103740 CR: JAGab70789)
(SR: 8606159451 CR: JAGad28779)
A thread acquires a lock and then sleeps interruptibly. The
interruptible sleep permits the thread to be stopped. Any
other thread attempting to acquire this lock will sleep
uninterruptably until the lock is available. This
uninterruptable thread is also unkillable. This introduces
a deadlock potential in multi-threaded processes: when a
thread holding the lock, a thread desiring the lock, and a
third thread doing one of fork, setrlimit, core, SIGSTOP, or
debugger optionations, all occur at the same time in the
same process, the deadlock is reached. The only way to
resolve the deadlock is to reboot the system.
This patch is part of a set of four patches (PHKL_23406,
PHKL_23407,PHKL_23408,PHKL_23409) that enable P_NOSTOP, a
new feature that prevents a process from being unkillable.
Each patch is independantly installable. Without all four
installed, P_NOSTOP will be unavailable.
In order to prevent the process executed over NFS from
becoming unkillable, NFS must use the P_NOSTOP feature. An
NFS patch using P_NOSTOP, PHNE_23249, will be released in
Spring of 2001.
Resolution:
If a thread acquires a lock and then sleeps interruptably,
it is not permitted to be stopped if P_NOSTOP is set. This
prevents this thread from becoming unkillable and prevents
the deadlock.
PHKL_23183:
(SR: 8606169539 CR: JAGad38814)
The check to unblock the signal handler was being done
too early inside grow(). This resulted in removal of the
signal handler specified by the application program.
Resolution:
The fix is to move the unblock signal out of grow() into
hdl_vfault() which then calls grow() at a later stage.
PHKL_22843:
(SR: 8606162188 CR: JAGad31504)
When an interpreter is invoked via a shell script, the
script name is mistakenly passed to the kernel as the first
argument (argv[0) instead of the interpreter name.
Resolution:
When an interpreter was being invoked via a shell script,
we passed the interpreter to the kernel as the first
argument instead of passing user's argv[0], which is
the script name.
(SR: 8606168950 CR: JAGad38228)
When user exec a shell script w/o supplying arguments
at all, the kernel failed to account for the extra
argument for the name of the script into the number
of arguments to be passed to the kernel. Also,
it failed to pass the interpreter to the kernel as
the first argument to be executed.
Resolution:
When user exec a shell script w/o supplying arguments
at all, the kernel bumps up argc by 1, to account for
the extra argument that we will be adding later via
via the function setup_shell_argv(). It also passes
the shell name to the kernel as the first argument,
instead of the script name.
PHKL_22493:
(SR: 8606141875 CR: JAGad11229)
When the debugged process initializes each thread's
data pointer, if the thread is in a ZOMBIE state,
that thead is not initialized, leaving the data
pointer NULL. Later, adb attempts to dereference
the NULL pointer, causing a data page fault panic.
Resolution:
Initialize the data pointer for all debugged threads,
including those in a ZOMBIE state.
PHKL_22032:
(SR: 8606146888 CR: JAGad16231)
If a setuid/setgid process completely dropped privileges,
it could create a core file on a subsequent error, and could
be attached to with a debugger.
(SR: 8606146889 CR: JAGad16232)
Some process management system calls generated incorrect
IDDS records.
Resolution:
(SR: 8606146888 CR: JAGad16231)
Remember that the process was once setuid/setgid, and
disallow corefiles and debugger attaches.
(SR: 8606146889 CR: JAGad16232)
Fix the generated records.
PHKL_21775:
Resolution :PM internal function prepare_to_reap_proc in
kern_exit.c changed to reap system processes correctly .
PHKL_21507:
( SR: 8606113684 CR: JAGac07198 )
Analysis of dump showed that we are attempting to free a
credential structure but credential refrence count
is already 0 indicating it was already freed.
Resolution:
Locking of credentials operations were protected by
sched_lock so that credential operations are done properly.
PHKL_21358:
( SR: 8606132621 CR: JAGad01770 )
This patch is one of 16 patches (PHKL_21348-PHKL_21363)
required by the Praesidium IDS/9000 product. These patches
enable the collection and tracking of information from
various system calls. Unless all of the enabling patches
(or their successors) and the product are installed, and the
product is enabled, this patch has no impact on the system.
Resolution:
This patch enables the gathering of information from the
various uid and gid related system calls.
PHKL_21350:
( SR: 8606132613 CR: JAGad01762 )
This patch is one of 16 patches (PHKL_21348-PHKL_21363)
required by the Praesidium IDS/9000 product. These patches
enable the collection and tracking of information from
various system calls. Unless all of the enabling patches
(or their successors) and the product are installed, and the
product is enabled, this patch has no impact on the system.
Resolution:
This patch enables the gathering of information from the
exec*() and exit() system calls.
PHKL_20439:
( SR: 8606109770 DTS: JAGaa45170 )
In the process to process memory copy routines, there were a
number of race conditions and memory leaks. These led to
system panics.
Resolution:
Made structural changes to locking logic to avoid these
race conditions and fixed the memory leaks.
PHKL_20226:
( SR: 8606107525 DTS: JAGab77768 )
This is one of 8 patches necessary to add support for the
3 Gb private address space feature. This feature allows a
process to have a private 3rd quadrant (normally the 3rd
quadrant, which is a 1 Gb range of address space from
0x80000000 to 0xC0000000, is used for shared objects). The
chatr command must be used to enable this feature for an
executable (chatr +q3p enable <a.out>). Note that this
feature is only enabled for 32 bit processes running on the
64 bit version of HP-UX.
The other 7 patches necessary to enable this feature are
PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20227,
PHKL_20228 and PHKL_20229. Each patch may be installed
independently of the others - if enabling the 3 Gb private
address space feature is not desired. If fewer than all 8
patches are installed, the 3 Gb private address space
feature will not be enabled. The code in this patch that is
part of this feature will not have any impact on the system
until all 8 patches are installed.
Resolution:
A subset of the code to support the 3 Gb private address
space feature was added. When all 8 patches are installed
the following code changes to support this feature will
have been added:
1) Code to recognize the request for a private 3rd
quadrant (Q3) during exec() of an executable.
An executable that requests a private 3rd
quadrant will be referred to as a q3p process
below.
2) Code to prevent allocation of shared objects
in q3p processes.
3) Code to allow data to extend over the 2nd/3rd
quadrant boundary for q3p processes.
4) Code to put the stack for the primary thread
in the 3rd quadrant for q3p processes.
5) Code to map a shared library into the private
address space if there is no more room in the
4th shared quadrant for q3p processes.
PHKL_21535:
( SR: 8606100830 CR: JAGab39185 )
This patch corrects application core dump behavior by
allowing dumping of a process' attached shared memory
segments to the application core file. This patch has no
impact on the system unless shared memory dumping is
enabled. See the Special Installation Instructions section
for details on how to enable shared memory dumping after
installing this patch.
A word of caution:
After shared memory dumping is enabled, the new system-wide
core dump behavior for applications will be to include
attached shared memory segments to application core files.
This may not be the desired behavior if you have
applications that use large shared memory segments running
on the system. (eg database applications). If those
applications core dump, the core files will include their
attached shared memory segments. Thus, they can be very
large files. Do not enable shared memory dumping after
installing this patch if you do not want this behavior.
Resolution:
This patch enables shared memory dumping in the coredump
generation code when kernel global variables
core_addshmem_read and/or core_addshmem_write are set to 1.
If both of these variables are set to 0, their default
value, this patch has no impact on the system.
PHKL_21357:
( SR: 8606132620 CR: JAGad01769 )
This patch is one of 16 patches (PHKL_21348-PHKL_21363)
required by the Praesidium IDS/9000 product. These patches
enable the collection and tracking of information from
various system calls. Unless all of the enabling patches
(or their successors) and the product are installed, and the
product is enabled, this patch has no impact on the system.
Resolution:
This patch enables the gathering of information from the
corefile generation code.
PHKL_22744:
( SR: 8606161365 CR: JAGad30681 )
A pregion lookup is done based on the thread id. Thread
id's are cached, so on systems with many threads configured
and running, the thread id may be stale, i.e. reused by
another thread. In this case, the wrong pregion is
returned.
Resolution:
Use the thread pregion pointer to access the pregion
instead of the thread id.
PHKL_22549:
( SR: 8606128066 DTS: JAGab24436 )
When syncing buffers for a particular device the routine
that scans the cache for dirty buffers was not checking
whether the buffers were valid. Those buffers that were
invalid would no longer have a vnode pointer associated
with them which in turn would cause a data page fault when
they were passed to bwrite().
Resolution:
The routine responsible for flushing buffers corresponding
to an individual inode will now ensure that only valid
buffers are attempted to be flushed.
PHKL_22440:
( SR: 8606154274 CR: JAGad23592 )
The kernel debug thread is responsible for receiving and
executing the debugger commands. This is a daemon thread
which is invisible to the user application and is not part
of the thread list of the proc stucuture. Hence while the
process is being swapped this thread is not put on the run
queue even if it were in run state. Since the debug thread
is not reactivated when the procces it is attached to is
swapped back in, both it and the attached process hang.
Resolution:
Explicitly start the debug thread (if it has been created)
when the process is swapped in.
PHKL_22380:
(SR: 8606130240 CR: JAGac95111)
The kernel driver creates an anonymous private mapping
with read-only protection and calls mprotect() to change
the access right to 'read-write'.
Before the dirver tries to write, it calls vaslockpages
to lock those pages down. vaslockpages did not set the
correct access right for the mprotected pages.
Resolution:
Changed kernel to set up the translation with corrent
access right.
(SR:8606139945 DTS: JAGad09268)
In the original design, when allocating/freeing a buffer,
it only does a sleep/wakeup on the list for the current
CPU. Processes sleeping from another CPU will not be
awakened. The result, seen in the dump of a hang, is
dozens of processes sleeping on an empty per-processor
queue.
Resolution:
The design has been changed as follows: When allocating
a buffer, first try to allocate from the cpu's own list,
if fail, allocate from global list, if still fail, steal
from each processor's list back to global list, then
try allocate from global list; if still fail, sleep on
global list. When freeing the buffer, if my cpu list's
number of free buffers is smaller than global list's,
free it to my list, else free it to global list, and
wakes up sleepers on the global list.
PHKL_22126:
( SR: 8606155209 DTS: JAGad24526 )
1. The problem was tied to the use of the global variables
used by legacy HyperFabric driver, the driver assumed that
they are kernel global function pointers owned by
HyperFabric and were initialized to NULL in the driver init
routine.
PHKL_21624 initializes (at compile time) the same function
pointers to the address of a new set of kernel funtions that
VM uses for calling all registered callback functions.
Resolution:
Replace the references to the global function pointers in VM
code with new symbol names, thus leaving the original
symbols initialized to NULL as the legacy HyperFabric driver
expects.
2. PHKL_21624 addressed a problem of system hang caused by
memory scrubber working on shared memory segments used by
the async I/O driver. To fix this problem, the change
required applications using async I/O driver to have MLOCK
privilege. This fact was not documented in PHKL_21624 and
caused application using async I/O driver to fail.
Resolution:
Applications that use the async I/O driver must belong to a
group having MLOCK privilege. Refer to the section
"Special Installation Instructions" for details on how to
check and set MLOCK privilege.
( SR: 8606143996 DTS: JAGad13329
During internal testing with PHKL_21624 using 8GB shared
memory segment and 300 user processes that were tyring
to connect to the database at the same time, we found that
the database user processes had an excessive database
connect delay. Each user process that connects to the
database registers memory with the async I/O driver which in
turn locks the memory so that if the address translation for
that memory is ever changed by VM, the async I/O driver
would be notified. To achieve this VM had to operate on each
4K page that backs-up the memory being locked. If there are
many users trying to register large memory segments almost
at the same time the registration process would take a long
time.
Resolution:
The VM code was modified to manage locking using superpages
rather than 4K pages.
PHKL_21781:
(SR: 8606137220 CR: JAGad06338)
The problem is due to the limitation of the protection
ranges for memory mapped regions. The counter for the
number of pregions that can be mprotected is defined as
a u_short. When an application uses a very large data
segment and makes more than 64K-1 mprotect(2) calls,
the system returns an ENOSPC.
Resolution:
Change the definition of mprotect range counters from
u_short to long.
(SR: 8606136222 CR: JAGad05348)
The major lock order for sendfile_lock was incorrect.
Resolution:
Correct the lock ordering for sendfile_lock.
PHKL_21624:
(SR: 8606124290 DTS: JAGac39673)
The following scenario would cause a deadlock (resulting in
a system hang): memlogd (using the dmem driver) was
scrubbing the 4kB physical pages of a superpage locked by
the async driver. Prior to scrubbing, dmem invalidated the
address translations for all the 4kB pages in the superpage.
Before dmem finished processing the superpage, it was
interrupted by an async I/O request. The I/O transaction
required accessing one of the 4kB pages in the superpage
being scrubbed by dmem. The interrupt handler would wait
for the page to be marked valid; dmem could not mark it
valid until the interrupt returned and it finished scrubbing
the superpage.
Resolution:
Callback registration support has been added to enable the
async driver to register a callback requirement against
memory it has locked. Whenever the address translation of a
locked page is to be invalidated, the callback feature is
invoked if the memory is registered as locked by async.
Thus, the async driver is able to prevent dmem from
scrubbing pages for which async I/Os are either active or
pending.
( SR: CR: JAGab16247 )
The mlock allows a user process to unlock memory locked by
the operating system. It does not allow for a persistant
lock of user space memory by the operating system.
Resolution:
A new interface was added to the VM subsystem to allow
persistant locking of user space memory by an operating
system driver in such a way that a user can not unlock it.
Both the persistant locking mechanism and the callback
registration support are required to support DMA to user
space by the operating system.
PHKL_21600:
(SR: 8606134430 DTS: JAGad03565)
No check for overflow when casting mmap offset from 64 bits
to 32 bits. And no check to prevent a negative value, from
user space.
Resolution:
After casting from 64 to 32 bits, the offset is tested
and if negative, mmap returns EINVAL.
PHKL_20647:
(SR: 8606107024 DTS: JAGab76631)
When calling munmap() to unmap an area that ends within a
superpage, the superpage lock was not properly released,
resulting in a system hang upon a subsequent attempt to lock
the superpage.
Resolution:
When calling munmap() to unmap an area that ends within a
superpage, demote the end points before attempting to lock
the superpage.
PHKL_20449:
(SR: 8606106816 DTS: JAGab76230)
The kernel behaves incorrectly during some mmap(2)
operations.
Resolution:
mmap(2) now returns an error if it can't honor the
request.
PHKL_20223:
( SR: 8606103245 DTS: JAGab69733)
This bug is caused by a race condition in the mmap(2) code
which was using a recursive algorithm to map all of the
file. A lock was being dropped and reacquired each time the
algorithm recursed.
Resolution:
The mmap bug was fixed by changing the algorithm so that is
no longer was recursive. This allowed the lock to be held
for the whole time.
( SR: 8606107525 DTS: JAGab77768)
This is one of 8 patches necessary to add support for the
3 Gb private address space feature. This feature allows a
process to have a private 3rd quadrant (normally the 3rd
quadrant, which is a 1 Gb range of address space from
0x80000000 to 0xC0000000, is used for shared objects). The
chatr command must be used to enable this feature for an
executable (chatr +q3p enable <a.out>). Note that this
feature is only enabled for 32 bit processes running on the
64 bit version of HP-UX.
The other 7 patches necessary to enable this feature are
PHKL_20222, PHKL_20224, PHKL_20225, PHKL_20226, PHKL_20227,
PHKL_20228 and PHKL_20229. Each patch may be installed
independently of the others - if enabling the 3 Gb private
address space feature is not desired. If fewer than all
8 patches are installed, the 3 Gb private address space
feature will not be enabled. The code in this patch that
is part of this feature will not have any impact on the
system until all 8 patches are installed.
Resolution:
A subset of the code to support the 3 Gb private address
space feature was added. When all 8 patches are installed
the following code changes to support this feature will
have been added:
1) Code to recognize the request for a private 3rd
quadrant (Q3) during exec() of an executable.
An executable that requests a private 3rd
quadrant will be referred to as a q3p process
below.
2) Code to prevent allocation of shared objects
in q3p processes.
3) Code to allow data to extend over the 2nd/3rd
quadrant boundary for q3p processes.
4) Code to put the stack for the primary thread
in the 3rd quadrant for q3p processes.
5) Code to map a shared library into the private
address space if there is no more room in the
4th shared quadrant for q3p processes.
PHKL_21532:
( SR: 8606131990 CR: JAGad01139 )
Approximately every 22 minutes, vhand monopolizes one cpu
for a long period of time. Every 22 minutes, vhand calls a
routine which tries to free up kernel memory. It tries to
free up each memory bucket for all cpus on the system each
time it is called.
As memory is freed up, chunks of memory are coalesced into
larger chunks of (contiguous) memory. Each 4k page freed is
added back into the superpage pool.
Another related problem is that the superpage pool chain
becomes long and fragmented (especially on large memory
systems), which implies inefficiency in managing the pool.
Resolution:
The routine called by vhand to free up kernel memory will
now work on one cpu at a time, and on only a few memory
buckets at a time. It will do less for each call, and be
called more often, spreading the workload out in time.
Use a better coalescing algorithm for the superpage pool
list.
PHKL_21354:
( SR: 8606132598 CR: JAGad01747 )
When mapping kernel pages to real memory, if the address
falls beyond 1GB and cannot be found in the 32bit sysmap, we
fail to check the return code and allocate it from the 64bit
sysmap.
Without PHKL_21003, which moved the 64bit sysmap to start at
1GB instead of 4GB to cover an undefined 3GB gap, this has
no effect since the address is not defined. However, when
the address is included in the 64bit sysmap and we do not
remove it properly when the virtual address is being used,
we end up using the same virtual address again because it is
still available in the sysmap. The init process fails when
the vhand daemon starts paging.
Resolution:
Allocate the address from the 64bit sysmap when it is not
found in the 32bit sysmap.
( SR: 8606132617 CR: JAGad01766 )
This patch is one of 16 patches (PHKL_21348-PHKL_21363)
required by the Praesidium IDS/9000 product. These patches
enable the collection and tracking of information from
various system calls. Unless all of the enabling patches
(or their successors) and the product are installed, and the
product is enabled, this change has no impact on the system.
Resolution:
This patch causes the IDS/9000 pseudo-driver to be
initialized at the right place during system boot.
PHKL_21024:
( SR: 8606112164 DTS: JAGab84450 )
This is an enhancement for a corner case in RTSCHED
scheduling.
Resolution:
Code added to fine tune RTSCHED thread scheduling code path.
PHKL_21003:
( SR: 8606112473 CR: JAGab84822 )
In 11.00, the 32bit sysmap contains pages from 0 to 1GB and
the 64bit sysmap contains pages from 4GB to 4TB, leaving a
3GB gap between them. Due to memory interleaving on V2500,
there may not be enough physical memory below 1GB to satisfy
the system initialization. Therefore, memory above 1GB is
used. During system boot, the init process will try to
allocate equivalently mapped virtual addresses from a sysmap
for physical pages between 1GB to 4GB. When it fails
because none of these pages can be found in either sysmap,
it loops through all pages sequentially until it exhausts
all the memory within the 1-4GB range. This may take a long
time depending on the number of physical pages in the range.
Resolution:
Extend 64bit sysmap to start from 1GB to cover the 3GB gap.
PHKL_20335:
( SR: 8606106466 DTS: JAGab75600)
The buffer cache was never releasing references it had on
NFS files which had the side-effect of never allowing these
files to be removed.
Resolution:
The buffer cache now ensures that it correctly releases all
holds on vnodes after data is removed from the cache. This
ensures that NFS files become inactive and are therefore are
removable.
( SR: 8606107384 DTS: JAGab77587)
The buffer cache has the potential to release buffers
multiple times, which could lead to system panics or memory
corruption.
Resolution:
The routine that was writing out dirty buffers then
releasing the buffer will now write and return thereby
ensuring that the buffer is released only once.
( SR: 8606108724 DTS: JAGab78191)
Files that grow in size and are copied over the network
multiple times -- via rcp or ftp commands -- during this
period may cause memory corruption to occur. This happens
because stale checksum data pointers within the buffer
header are reused after the buffer increases in size.
Resolution:
The buffer cache routine responsible for increasing the size
of buffers will now check whether a buffer contains a
pointer to checksum data -- which is used by the networking
code -- in which case it will free the data and clear the
pointer.
PHKL_20222:
( SR: 8606107507 DTS: JAGab77743)
This patch adds support for new machines that contain the
PA-8600 processor.
Resolution:
Code to support the PA-8600 processor was added.
( SR: 8606107525 DTS: JAGab77768)
This is one of 8 patches necessary to add support for the 3
Gb private address space feature. This feature allows a
process to have a private 3rd quadrant (normally the 3rd
quadrant, which is a 1 Gb range of address space from
0x80000000 to 0xC0000000, is used for shared objects). The
chatr command must be used to enable this feature for an
executable (chatr +q3p enable <a.out>). Note that this
feature is only enabled for 32 bit processes running on the
64 bit version of HP-UX.
The other 7 patches necessary to enable this feature are
PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20226, PHKL_20227,
PHKL_20228 and PHKL_20229. Each patch may be installed
independently of the others - if enabling the 3 Gb private
address space feature is not desired. If fewer than all 8
patches are installed, the 3 Gb private address space
feature will not be enabled. The code in this patch that is
part of this feature will not have any impact on the system
until all 8 patches are installed.
Resolution:
A subset of the code to support the 3 Gb private address
space feature was added. When all 8 patches are installed
the following code changes to support this feature will have
been added:
1) Code to recognize the request for a private 3rd
quadrant (Q3) during exec() of an executable.
An executable that requests a private 3rd
quadrant will be referred to as a q3p process
below.
2) Code to prevent allocation of shared objects
in q3p processes.
3) Code to allow data to extend over the 2nd/3rd
quadrant boundary for q3p processes.
4) Code to put the stack for the primary thread
in the 3rd quadrant for q3p processes.
5) Code to map a shared library into the private
address space if there is no more room in the
4th shared quadrant for q3p processes.
PHKL_20102:
( SR: 8606106969 DTS: JAGaa45096 )
On systems with 5GB of memory or more, the system allocates
too much memory for the pdir hash table (32-224MB). This
additional memory is wasted.
Resolution:
Fixed boot time memory allocation algorithm to only allocate
memory that is actually used.
PHKL_20017:
( SR: 8606104415 DTS: JAGab71916)
The fix in PHKL_19314 for the "14-way boot hang" breaks the
interrupt distribution code. This results in all I/O
interrupts being assigned to the monarch CPU, causing I/O
performance degradation.
Resolution:
Add a new spu state SPU_INTR_ENABLED, so that pa_next_cpu
will designate a spu to be an interrupt handler if its
status is either SPU_INTR_ENABLED or SPU_ENABLED. Each
non-monarch CPU sets its state to be SPU_INTR_ENABLED at
the point where it used to set SPU_ENABLED.
( SR: 4701426775 DTS: JAGab17440 )
Historically on a 32bit system, the maximum size in one
quadrant is limited to 1Gb. To handle more than 1Gb of
buffer caches, we use two buffer cache resource maps, bufmap
and bufmap2. For 64bit systems, the maximum size of a
quadrant is not limited to 1Gb anymore and we don't need a
second bufmap to fulfill the buffer cache needs. Therefore,
bufmap2 is not used. However, on 11.00, we still initialize
two resource maps with the size of bufmap limited to 0.9Gb/2
entries regardless of whether we have a 32bit or a 64bit
system. So for 64bit systems with large memory and large
buffer cache defined the system can still run out of bufmap
entries if the virtual address space for the buffer cache
gets fragmented.
Resolution:
For 64bit systems, initialize bufmap to contain
phys_mem_pages/2 entries.
PHKL_19314:
( SR: 4701426775 DTS: JAGab17440 )
While the monarch processor is in MPCONFIG_PHASE2 during
boot and before it gets a chance to tell all non-monarch
processors to continue execution (set mp_sync_after_rendez
to CONTINUE_EXECUTION), a clock interrupt comes in. The
clock interrupt handler will erroneously attempt an
m_itmr_sync with all the processors (which are still waiting
to continue). This m_itmr_sync can take up to 13 msecs per
processor. When the number of processor is high enough,
which is 14 in this case, another clock interrupt arrives
before the current clock handler completes, causing the boot
to hang in an infinite continuous series of servicing clock
interrupts.
Resolution:
In the clock interrupt handling routine, we now make sure
that no m_itmr_sync is attempted by the monarch processor
until after the non-monarch processors are actually ready.
As for the non-monarch processors, in the non_monarch_init
routine, we now make sure that each non-monarch processor
does not signal the monarch processor that it is ready for
an m_itmr_sync until after the monarch sets
mp_sync_after_rendez to CONTINUE_EXECUTION.
( SR: 8606101604 DTS: JAGab15954)
The root cause seems to be a double mapping of the
break_page by both a block TLB entry and an ordinary one,
which causes undefined results in the hardware.
Resolution:
Code has been added to main so that during initialization it
looks at the machine being booted to see whether or not this
machine has a block-tlb. If the machine does not have one,
then the page in the kernel is used for the break-page. If
the machine has a block-tlb, then instead of using the page
in the kernel, a new page is allocated for the break-page.
PHKL_19201:
SR: 8606100898 DTS: JAGab39707
The system hang is caused by jfs snap code trying to lock
the same resource again when it already owns it. A buffer
that partially satisfies a request needs to be marked
invalid when it can't be grown to fit the request. This
will prevent another thread from getting a hit on it and
trying to grow it, which can cause a hang.
Resolution:
SR: 8606100898 DTS: JAGab39707
Mark buffers invalid when the buffer can't be grown to fit
the size of the request.
PHKL_17038:
An uninitialized variable may cause this data page fault
when tracing for memory leaks. The workaround is to also
trace for corruption which will initialize the variable.
The workaround isn't always feasible because tracing for
corruption uses a lot more memory in some environments while
tracing for leaks does not.
PHKL_20945:
( SR: 8606112164 DTS: JAGab84450 )
This is an enhancement for a corner case in RTSCHED
scheduling.
Resolution:
Code added to fine tune RTSCHED thread scheduling code path.
PHKL_20995:
( SR: 8606127692 CR: JAGac78494 )
Code that initialized the space maps for the second and
third quadrant for memory windows processes is not being
run. This means that a memory windows process cannot
allocate shared memory in the second (for SHMEM_MAGIC
processes) or third quadrant, leaving only the fourth
quadrant available, which is shared across all processes.
This defect is only present if all 8 of the Large Data
space patches are installed.
Resolution:
Code was changed to allow the space maps to be properly
initialized for all configured memory windows.
PHKL_20836:
( SR: 8606106781 CR: JAGab76169 )
HP-UX handles multiple virtual addresses mapping to the
same physical page by using virtual address aliasing.
Large number of overlapping exclusive mapping calls
(mmap with MAP_SHARED|MAP_FIXED|MAP_FILE) create excessive
number of virtual address aliases and can exhaust the alias
entries for physical pages. The exhaustion of alias entries
results in failed attempts to add a page translation.
Improper handling of the translation failure results in
corruption in the free memory list, thus causing an unmapped
page to be returned from the free memory pond.
Resolution:
Handle application requested overlapping exclusive mapping
without using aliases.
PHKL_20227:
( SR: 8606107525 CR: JAGab77768 )
This is one of 8 patches necessary to add support for the
3 Gb private address space feature. This feature allows a
process to have a private 3rd quadrant (normally the 3rd
quadrant, which is a 1 Gb range of address space from
0x80000000 to 0xC0000000, is used for shared objects). The
chatr command must be used to enable this feature for an
executable (chatr +q3p enable <a.out>). Note that this
feature is only enabled for 32 bit processes running on the
64 bit version of HP-UX.
The other 7 patches necessary to enable this feature are
PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20226,
PHKL_20228 and PHKL_20229. Each patch may be installed
independently of the others - if enabling the 3 Gb private
address space feature is not desired. If fewer than all
8 patches are installed, the 3 Gb private address space
feature will not be enabled. The code in this patch that
is part of this feature will not have any impact on the
system until all 8 patches are installed.
Resolution:
A subset of the code to support the 3 Gb private address
space feature was added. When all 8 patches are installed
the following code changes to support this feature will
have been added:
1) Code to recognize the request for a private 3rd
quadrant (Q3) during exec() of an executable.
An executable that requests a private 3rd
quadrant will be referred to as a q3p process
below.
2) Code to prevent allocation of shared objects
in q3p processes.
3) Code to allow data to extend over the 2nd/3rd
quadrant boundary for q3p processes.
4) Code to put the stack for the primary thread
in the 3rd quadrant for q3p processes.
5) Code to map a shared library into the private
address space if there is no more room in the
4th shared quadrant for q3p processes.
PHKL_20224:
( SR: 8606107525 CR: JAGab77768 )
This is one of 8 patches necessary to add support for the
3 Gb private address space feature. This feature allows a
process to have a private 3rd quadrant (normally the 3rd
quadrant, which is a 1 Gb range of address space from
0x80000000 to 0xC0000000, is used for shared objects). The
chatr command must be used to enable this feature for an
executable (chatr +q3p enable <a.out>). Note that this
feature is only enabled for 32 bit processes running on the
64 bit version of HP-UX.
The other 7 patches necessary to enable this feature are
PHKL_20222, PHKL_20223, PHKL_20225, PHKL_20226, PHKL_20227,
PHKL_20228 and PHKL_20229. Each patch may be installed
independently of the others - if enabling the 3 Gb private
address space feature is not desired. If fewer than all
8 patches are installed, the 3 Gb private address space
feature will not be enabled. The code in this patch that
is part of this feature will not have any impact on the
system until all 8 patches are installed.
Resolution:
A subset of the code to support the 3 Gb private address
space feature was added. When all 8 patches are installed
the following code changes to support this feature will
have been added:
1) Code to recognize the request for a private 3rd
quadrant (Q3) during exec() of an executable.
An executable that requests a private 3rd
quadrant will be referred to as a q3p process
below.
2) Code to prevent allocation of shared objects
in q3p processes.
3) Code to allow data to extend over the 2nd/3rd
quadrant boundary for q3p processes.
4) Code to put the stack for the primary thread
in the 3rd quadrant for q3p processes.
5) Code to map a shared library into the private
address space if there is no more room in the
4th shared quadrant for q3p processes.
PHKL_20515:
(SR: 8606101315, CR: JAGab46368)
Assertion failure occurs in 'kmalloc' someone called
'kmalloc' holding the 'spinlock' which should not be
done.
Async driver allocated kernel memory while holding spinlock
which causes driver to sleep until memory is available.
Resolution:
Added No-Wait flag to memory allocation call when
spinlock is held.
(SR: 8606100970, CR: JAGab39977)
Async driver called subroutine with uninitialized variable.
In the asyncdsk_dorequest() routine, the 1st argument to
luseracc is tempseg.space -- however, tempseg.space doesn't
get populated until & unless luseracc returns successfully.
Resolution:
Initialize variable before using in subroutine call.
(SR:8606103126, CR: JAGab69473)
Spinlock was held in async driver during call to routine
that did not need spinlock held, and which could take too
long before returning.
Resolution:
Released spinlock before call to the routine, then
reacquired after routine returned.
(SR: 8606102862, CR: JAGab68892)
Async driver should unmap buffers of same size as was
originally mapped for the IO request, but instead it was
unmapping the size based on the number of bytes transferred
successfully in the async IO request.
Resolution:
Unmapped IO request buffer size same as was mapped.
(SR: 8606108814, CR: JAGab81517)
Async driver's IO completion flag notification was checked
in wrong sequence, when used in conjunction with select.
Resolution:
Changed sequence to check for IO notification flag
before checking other types of IO completions.
PHKL_20426:
Violation of lock ordering by filesystem code. The lock
ordering that is safe from deadlock is: vaslock, vnodelock,
inodelock but filesystems are attempting the order:
(vnodelock), inodelock, vaslock
Resolution:
The VM system will drop the vaslock around filesystem
operations, and reacquire it afterwards. This completes
PHKL_18531 that was partially solving the problem.
Enhancement:
No (superseded patches contained enhancements)
PHKL_27994:
Enhancements were delivered in a patch this one has
superseded. Please review the Defect Description
text for more information.
SR:
1653301614 4701402461 4701426775 8606100830 8606100898
8606100970 8606101315 8606101604 8606102862 8606103126
8606103245 8606103740 8606103778 8606104415 8606106466
8606106781 8606106816 8606106969 8606107024 8606107384
8606107507 8606107525 8606108724 8606108814 8606109770
8606112164 8606112473 8606113684 8606124290 8606127692
8606128066 8606130240 8606131318 8606132598 8606132613
8606132617 8606132620 8606132621 8606134430 8606134995
8606136222 8606137149 8606137220 8606139945 8606141875
8606143996 8606146888 8606146889 8606154274 8606155209
8606161365 8606162188 8606168950 8606169539 8606178349
8606179580 8606180059 8606183443 8606185728 8606186963
8606188675 8606188767 8606192072 8606192498 8606194618
8606195331 8606195629 8606198933 8606199485 8606199847
8606204721 8606216082 8606226665 8606237263 8606241742
8606244346 8606254033 8606256133 8606265366 8606268349
Patch Files:
OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/conf/h/map.h
/usr/conf/h/vm_mlock.h
/usr/conf/machine/hdl_preg.h
/usr/conf/machine/pdc_rqsts.h
/usr/conf/sio/async.h
ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/include/machine/hdl_preg.h
/usr/include/machine/pdc_rqsts.h
/usr/include/sio/async.h
/usr/include/sys/map.h
/usr/include/sys/vm_mlock.h
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
/usr/conf/lib/libhp-ux.a(asm_vm.o)
/usr/conf/lib/libhp-ux.a(async.o)
/usr/conf/lib/libhp-ux.a(clic_stubs.o)
/usr/conf/lib/libhp-ux.a(clock.o)
/usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o)
/usr/conf/lib/libhp-ux.a(dmem.o)
/usr/conf/lib/libhp-ux.a(hdl_fault.o)
/usr/conf/lib/libhp-ux.a(hdl_init.o)
/usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
/usr/conf/lib/libhp-ux.a(hdl_policy.o)
/usr/conf/lib/libhp-ux.a(hdl_trans.o)
/usr/conf/lib/libhp-ux.a(init_main.o)
/usr/conf/lib/libhp-ux.a(kern_exec.o)
/usr/conf/lib/libhp-ux.a(kern_exit.o)
/usr/conf/lib/libhp-ux.a(kern_mallo.o)
/usr/conf/lib/libhp-ux.a(kern_mman.o)
/usr/conf/lib/libhp-ux.a(kgdb_machine.o)
/usr/conf/lib/libhp-ux.a(kmall_trace.o)
/usr/conf/lib/libhp-ux.a(onyxe.o)
/usr/conf/lib/libhp-ux.a(pa_generic_psm.o)
/usr/conf/lib/libhp-ux.a(pm_core.o)
/usr/conf/lib/libhp-ux.a(pm_cred.o)
/usr/conf/lib/libhp-ux.a(pm_prot.o)
/usr/conf/lib/libhp-ux.a(pm_ptrace.o)
/usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
/usr/conf/lib/libhp-ux.a(vfs_bio.o)
/usr/conf/lib/libhp-ux.a(vm_clic.o)
/usr/conf/lib/libhp-ux.a(vm_kern.o)
/usr/conf/lib/libhp-ux.a(vm_machdep.o)
/usr/conf/lib/libhp-ux.a(vm_machreg.o)
/usr/conf/lib/libhp-ux.a(vm_memlock.o)
/usr/conf/lib/libhp-ux.a(vm_mlock.o)
/usr/conf/lib/libhp-ux.a(vm_mmap.o)
/usr/conf/lib/libhp-ux.a(vm_pgalloc.o)
/usr/conf/lib/libhp-ux.a(vm_pregion.o)
/usr/conf/lib/libhp-ux.a(vm_realmain.o)
/usr/conf/lib/libhp-ux.a(vm_remap.o)
/usr/conf/lib/libhp-ux.a(vm_sched.o)
/usr/conf/lib/libhp-ux.a(vm_vas.o)
/usr/conf/lib/libhp-ux.a(vm_vfd.o)
/usr/conf/lib/libhp-ux.a(vm_vhand.o)
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
/usr/conf/lib/libhp-ux.a(asm_vm.o)
/usr/conf/lib/libhp-ux.a(async.o)
/usr/conf/lib/libhp-ux.a(clic_stubs.o)
/usr/conf/lib/libhp-ux.a(clock.o)
/usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o)
/usr/conf/lib/libhp-ux.a(dmem.o)
/usr/conf/lib/libhp-ux.a(hdl_fault.o)
/usr/conf/lib/libhp-ux.a(hdl_init.o)
/usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
/usr/conf/lib/libhp-ux.a(hdl_policy.o)
/usr/conf/lib/libhp-ux.a(hdl_trans.o)
/usr/conf/lib/libhp-ux.a(init_main.o)
/usr/conf/lib/libhp-ux.a(kern_exec.o)
/usr/conf/lib/libhp-ux.a(kern_exit.o)
/usr/conf/lib/libhp-ux.a(kern_mallo.o)
/usr/conf/lib/libhp-ux.a(kern_mman.o)
/usr/conf/lib/libhp-ux.a(kgdb_machine.o)
/usr/conf/lib/libhp-ux.a(kmall_trace.o)
/usr/conf/lib/libhp-ux.a(onyxe.o)
/usr/conf/lib/libhp-ux.a(pa_generic_psm.o)
/usr/conf/lib/libhp-ux.a(pm_core.o)
/usr/conf/lib/libhp-ux.a(pm_cred.o)
/usr/conf/lib/libhp-ux.a(pm_prot.o)
/usr/conf/lib/libhp-ux.a(pm_ptrace.o)
/usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
/usr/conf/lib/libhp-ux.a(vfs_bio.o)
/usr/conf/lib/libhp-ux.a(vm_clic.o)
/usr/conf/lib/libhp-ux.a(vm_kern.o)
/usr/conf/lib/libhp-ux.a(vm_machdep.o)
/usr/conf/lib/libhp-ux.a(vm_machreg.o)
/usr/conf/lib/libhp-ux.a(vm_memlock.o)
/usr/conf/lib/libhp-ux.a(vm_mlock.o)
/usr/conf/lib/libhp-ux.a(vm_mmap.o)
/usr/conf/lib/libhp-ux.a(vm_pgalloc.o)
/usr/conf/lib/libhp-ux.a(vm_pregion.o)
/usr/conf/lib/libhp-ux.a(vm_realmain.o)
/usr/conf/lib/libhp-ux.a(vm_remap.o)
/usr/conf/lib/libhp-ux.a(vm_sched.o)
/usr/conf/lib/libhp-ux.a(vm_vas.o)
/usr/conf/lib/libhp-ux.a(vm_vfd.o)
/usr/conf/lib/libhp-ux.a(vm_vhand.o)
what(1) Output:
OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/conf/h/map.h:
map.h $Date: 2000/02/02 11:49:37 $Revision: r11ros/2
PATCH_11.00 (PHKL_21003)
/usr/conf/h/vm_mlock.h:
vm_mlock.h $Date: 2001/04/23 13:03:40 $Revision: r11
ros/2 PATCH_11.00 (PHKL_23857)
/usr/conf/machine/hdl_preg.h:
hdl_preg.h $Date: 2000/05/31 14:27:02 $Revision: r11
ros/1 PATCH_11.00 (PHKL_21781)
/usr/conf/machine/pdc_rqsts.h:
pdc_rqsts.h $Date: 1999/10/28 05:09:19 $Revision: r1
1ros/3 PATCH_11.00 (PHKL_20222)
/usr/conf/sio/async.h:
async.h $Date: 2001/06/26 14:43:30 $Revision: r11ros
/5 PATCH_11.00 (PHKL_24457)
ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
/usr/include/machine/hdl_preg.h:
hdl_preg.h $Date: 2000/05/31 14:27:02 $Revision: r11
ros/1 PATCH_11.00 (PHKL_21781)
/usr/include/machine/pdc_rqsts.h:
pdc_rqsts.h $Date: 1999/10/28 05:09:19 $Revision: r1
1ros/3 PATCH_11.00 (PHKL_20222)
/usr/include/sio/async.h:
async.h $Date: 2001/06/26 14:43:30 $Revision: r11ros
/5 PATCH_11.00 (PHKL_24457)
/usr/include/sys/map.h:
map.h $Date: 2000/02/02 11:49:37 $Revision: r11ros/2
PATCH_11.00 (PHKL_21003)
/usr/include/sys/vm_mlock.h:
vm_mlock.h $Date: 2001/04/23 13:03:40 $Revision: r11
ros/2 PATCH_11.00 (PHKL_23857)
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
/usr/conf/lib/libhp-ux.a(asm_vm.o):
asm_vm.s $Date: 2001/09/05 08:39:29 $Revision: r11ro
s/6 PATCH_11.00 (PHKL_25164)
/usr/conf/lib/libhp-ux.a(async.o):
async.c $Date: 2001/06/26 12:54:22 $Revision: r11ros
/16 PATCH_11.00 (PHKL_24457)
/usr/conf/lib/libhp-ux.a(clic_stubs.o):
clic_stubs.c $Date: 2000/08/14 11:40:53 $Revision: r
11ros/3 PATCH_11.00 (PHKL_22126)
/usr/conf/lib/libhp-ux.a(clock.o):
clock.c $Date: 1999/09/24 17:23:06 $Revision: r11ros
/7 PATCH_11.00 (PHKL_20017)
/usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o):
cnx_p2p_bcopy.c $Date: 1999/11/09 15:03:19 $Revision
: r11ros/7 PATCH_11.00 (PHKL_20439)
/usr/conf/lib/libhp-ux.a(dmem.o):
dmem.c $Date: 2000/08/14 11:40:53 $Revision: r11ros/
6 PATCH_11.00 (PHKL_22126)
/usr/conf/lib/libhp-ux.a(hdl_fault.o):
hdl_fault.c $Date: 2001/12/11 15:54:19 $Revision: r1
1ros/14 PATCH_11.00 (PHKL_25906)
/usr/conf/lib/libhp-ux.a(hdl_init.o):
hdl_init.c $Date: 1999/10/31 21:44:19 $Revision: r11
ros/7 PATCH_11.00 (PHKL_20223)
/usr/conf/lib/libhp-ux.a(hdl_mprotect.o):
hdl_mprotect.c $Date: 2000/05/31 14:25:46 $Revision:
r11ros/9 PATCH_11.00 (PHKL_21781)
/usr/conf/lib/libhp-ux.a(hdl_policy.o):
hdl_policy.c $Date: 2002/05/22 13:51:22 $Revision: r
11ros/16 PATCH_11.00 (PHKL_27157)
/usr/conf/lib/libhp-ux.a(hdl_trans.o):
hdl_trans.c $Date: 2001/07/12 15:49:36 $Revision: r1
1ros/18 PATCH_11.00 (PHKL_24612)
/usr/conf/lib/libhp-ux.a(init_main.o):
init_main.c $Date: 2002/08/28 14:53:39 $Revision: r1
1ros/12 PATCH_11.00 (PHKL_27759)
/usr/conf/lib/libhp-ux.a(kern_exec.o):
kern_exec.c $Date: 2001/04/25 13:09:32 $Revision: r1
1ros/22 PATCH_11.00 (PHKL_24015)
/usr/conf/lib/libhp-ux.a(kern_exit.o):
kern_exit.c $Date: 2001/02/15 11:36:33 $Revision: r1
1ros/18 PATCH_11.00 (PHKL_23406)
/usr/conf/lib/libhp-ux.a(kern_mallo.o):
kern_mallo.c $Date: 2000/04/12 03:18:15 $Revision: r
11ros/7 PATCH_11.00 (PHKL_21532)
/usr/conf/lib/libhp-ux.a(kern_mman.o):
kern_mman.c $Date: 2001/01/25 16:58:55 $Revision: r1
1ros/4 PATCH_11.00 (PHKL_23183)
/usr/conf/lib/libhp-ux.a(kgdb_machine.o):
kgdb_machine.c $Date: 1999/10/28 05:09:19 $Revision:
r11ros/4 PATCH_11.00 (PHKL_20222)
/usr/conf/lib/libhp-ux.a(kmall_trace.o):
kmall_trace.c $Date: 2000/02/02 11:47:27 $Revision:
r11ros/7 PATCH_11.00 (PHKL_21003)
/usr/conf/lib/libhp-ux.a(onyxe.o):
onyxe.c $Date: 1999/10/28 05:09:19 $Revision: r11ros
/2 PATCH_11.00 (PHKL_20222)
onyxe 1.0 (unsupported)
/usr/conf/lib/libhp-ux.a(pa_generic_psm.o):
pa_generic_psm.c $Date: 1999/09/24 17:23:06 $Revisio
n: r11ros/2 PATCH_11.00 (PHKL_20017)
/usr/conf/lib/libhp-ux.a(pm_core.o):
pm_core.c $Date: 2001/03/13 13:32:21 $Revision: r11r
os/7 PATCH_11.00 (PHKL_23628)
/usr/conf/lib/libhp-ux.a(pm_cred.o):
pm_cred.c $Date: 2000/04/06 11:41:10 $Revision: r11r
os/1 PATCH_11.00 (PHKL_21507)
/usr/conf/lib/libhp-ux.a(pm_prot.o):
pm_prot.c $Date: 2000/07/14 09:34:52 $Revision: r11r
os/6 PATCH_11.00 (PHKL_22032)
/usr/conf/lib/libhp-ux.a(pm_ptrace.o):
ttrace_private.h $Date: 1998/12/15 09:21:36 $Revisio
n: r11ros/cup_ros_ep1_pb/3 PATCH_11.00 (PHKL
_17205)
pm_ptrace.c $Date: 2001/05/14 14:45:15 $Revision: r1
1ros/15 PATCH_11.00 (PHKL_24116)
/usr/conf/lib/libhp-ux.a(ufs_mchdep.o):
ufs_mchdep.c $Date: 2000/06/05 17:05:33 $Revision: r
11ros/6 PATCH_11.00 (PHKL_21781)
/usr/conf/lib/libhp-ux.a(vfs_bio.o):
vfs_bio.c $Date: 2002/04/29 12:59:24 $Revision: r11r
os/23 PATCH_11.00 (PHKL_26800)
/usr/conf/lib/libhp-ux.a(vm_clic.o):
vm_clic.c $Date: 2001/04/23 13:03:40 $Revision: r11r
os/4 PATCH_11.00 (PHKL_23857)
/usr/conf/lib/libhp-ux.a(vm_kern.o):
vm_kern.c $Date: 2000/04/12 03:18:15 $Revision: r11r
os/4 PATCH_11.00 (PHKL_21532)
/usr/conf/lib/libhp-ux.a(vm_machdep.o):
vm_machdep.c $Date: 2001/09/05 08:41:26 $Revision: r
11ros/36 PATCH_11.00 (PHKL_25164)
/usr/conf/lib/libhp-ux.a(vm_machreg.o):
vm_machreg.c $Date: 2002/06/25 08:41:53 $Revision: r
11ros/12 PATCH_11.00 (PHKL_27364)
/usr/conf/lib/libhp-ux.a(vm_memlock.o):
vm_memlock.c $Date: 2001/08/17 14:43:30 $Revision: r
11ros/5 PATCH_11.00 (PHKL_24971)
/usr/conf/lib/libhp-ux.a(vm_mlock.o):
vm_mlock.c $Date: 2000/05/03 15:11:15 $Revision: r11
ros/4 PATCH_11.00 (PHKL_21624)
/usr/conf/lib/libhp-ux.a(vm_mmap.o):
vm_mmap.c $Date: 2002/06/04 17:07:42 $Revision: r11r
os/25 PATCH_11.00 (PHKL_27238)
/usr/conf/lib/libhp-ux.a(vm_pgalloc.o):
vm_pgalloc.c $Date: 2000/05/03 15:11:15 $Revision: r
11ros/4 PATCH_11.00 (PHKL_21624)
/usr/conf/lib/libhp-ux.a(vm_pregion.o):
vm_pregion.c $Date: 2001/05/29 15:16:13 $Revision: r
11ros/11 PATCH_11.00 (PHKL_24273)
/usr/conf/lib/libhp-ux.a(vm_realmain.o):
vm_realmain32.c $Date: 1999/10/28 05:09:19 $Revision
: r11ros/5 PATCH_11.00 (PHKL_20222)
/usr/conf/lib/libhp-ux.a(vm_remap.o):
vm_remap.c $Date: 2000/08/14 11:40:53 $Revision: r11
ros/4 PATCH_11.00 (PHKL_22126)
/usr/conf/lib/libhp-ux.a(vm_sched.o):
vm_sched.c $Date: 2000/09/20 14:54:13 $Revision: r11
ros/8 PATCH_11.00 (PHKL_22440)
/usr/conf/lib/libhp-ux.a(vm_vas.o):
vm_vas.c $Date: 2001/09/11 13:56:29 $Revision: r11ro
s/13 PATCH_11.00 (PHKL_25210)
/usr/conf/lib/libhp-ux.a(vm_vfd.o):
vm_vfd.c $Date: 2002/10/16 15:44:52 $Revision: r11ro
s/9 PATCH_11.00 (PHKL_27994)
/usr/conf/lib/libhp-ux.a(vm_vhand.o):
vm_vhand.c $Date: 2000/04/12 03:18:15 $Revision: r11
ros/6 PATCH_11.00 (PHKL_21532)
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
/usr/conf/lib/libhp-ux.a(asm_vm.o):
asm_vm.s $Date: 2001/09/05 08:39:29 $Revision: r11ro
s/6 PATCH_11.00 (PHKL_25164)
/usr/conf/lib/libhp-ux.a(async.o):
async.c $Date: 2001/06/26 12:54:22 $Revision: r11ros
/16 PATCH_11.00 (PHKL_24457)
/usr/conf/lib/libhp-ux.a(clic_stubs.o):
clic_stubs.c $Date: 2000/08/14 11:40:53 $Revision: r
11ros/3 PATCH_11.00 (PHKL_22126)
/usr/conf/lib/libhp-ux.a(clock.o):
clock.c $Date: 1999/09/24 17:23:06 $Revision: r11ros
/7 PATCH_11.00 (PHKL_20017)
/usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o):
cnx_p2p_bcopy.c $Date: 1999/11/09 15:03:19 $Revision
: r11ros/7 PATCH_11.00 (PHKL_20439)
/usr/conf/lib/libhp-ux.a(dmem.o):
dmem.c $Date: 2000/08/14 11:40:53 $Revision: r11ros/
6 PATCH_11.00 (PHKL_22126)
/usr/conf/lib/libhp-ux.a(hdl_fault.o):
hdl_fault.c $Date: 2001/12/11 15:54:19 $Revision: r1
1ros/14 PATCH_11.00 (PHKL_25906)
/usr/conf/lib/libhp-ux.a(hdl_init.o):
hdl_init.c $Date: 1999/10/31 21:44:19 $Revision: r11
ros/7 PATCH_11.00 (PHKL_20223)
/usr/conf/lib/libhp-ux.a(hdl_mprotect.o):
hdl_mprotect.c $Date: 2000/05/31 14:25:46 $Revision:
r11ros/9 PATCH_11.00 (PHKL_21781)
/usr/conf/lib/libhp-ux.a(hdl_policy.o):
hdl_policy.c $Date: 2002/05/22 13:51:22 $Revision: r
11ros/16 PATCH_11.00 (PHKL_27157)
/usr/conf/lib/libhp-ux.a(hdl_trans.o):
hdl_trans.c $Date: 2001/07/12 15:49:36 $Revision: r1
1ros/18 PATCH_11.00 (PHKL_24612)
/usr/conf/lib/libhp-ux.a(init_main.o):
init_main.c $Date: 2002/08/28 14:53:39 $Revision: r1
1ros/12 PATCH_11.00 (PHKL_27759)
/usr/conf/lib/libhp-ux.a(kern_exec.o):
kern_exec.c $Date: 2001/04/25 13:09:32 $Revision: r1
1ros/22 PATCH_11.00 (PHKL_24015)
/usr/conf/lib/libhp-ux.a(kern_exit.o):
kern_exit.c $Date: 2001/02/15 11:36:33 $Revision: r1
1ros/18 PATCH_11.00 (PHKL_23406)
/usr/conf/lib/libhp-ux.a(kern_mallo.o):
kern_mallo.c $Date: 2000/04/12 03:18:15 $Revision: r
11ros/7 PATCH_11.00 (PHKL_21532)
/usr/conf/lib/libhp-ux.a(kern_mman.o):
kern_mman.c $Date: 2001/01/25 16:58:55 $Revision: r1
1ros/4 PATCH_11.00 (PHKL_23183)
/usr/conf/lib/libhp-ux.a(kgdb_machine.o):
kgdb_machine.c $Date: 1999/10/28 05:09:19 $Revision:
r11ros/4 PATCH_11.00 (PHKL_20222)
/usr/conf/lib/libhp-ux.a(kmall_trace.o):
kmall_trace.c $Date: 2000/02/02 11:47:27 $Revision:
r11ros/7 PATCH_11.00 (PHKL_21003)
/usr/conf/lib/libhp-ux.a(onyxe.o):
onyxe 1.0 (unsupported)
onyxe.c $Date: 1999/10/28 05:09:19 $Revision: r11ros
/2 PATCH_11.00 (PHKL_20222)
/usr/conf/lib/libhp-ux.a(pa_generic_psm.o):
pa_generic_psm.c $Date: 1999/09/24 17:23:06 $Revisio
n: r11ros/2 PATCH_11.00 (PHKL_20017)
/usr/conf/lib/libhp-ux.a(pm_core.o):
pm_core.c $Date: 2001/03/13 13:32:21 $Revision: r11r
os/7 PATCH_11.00 (PHKL_23628)
/usr/conf/lib/libhp-ux.a(pm_cred.o):
pm_cred.c $Date: 2000/04/06 11:41:10 $Revision: r11r
os/1 PATCH_11.00 (PHKL_21507)
/usr/conf/lib/libhp-ux.a(pm_prot.o):
pm_prot.c $Date: 2000/07/14 09:34:52 $Revision: r11r
os/6 PATCH_11.00 (PHKL_22032)
/usr/conf/lib/libhp-ux.a(pm_ptrace.o):
ttrace_private.h $Date: 1998/12/15 09:21:36 $Revisio
n: r11ros/cup_ros_ep1_pb/3 PATCH_11.00 (PHKL
_17205)
pm_ptrace.c $Date: 2001/05/14 14:45:15 $Revision: r1
1ros/15 PATCH_11.00 (PHKL_24116)
/usr/conf/lib/libhp-ux.a(ufs_mchdep.o):
ufs_mchdep.c $Date: 2000/06/05 17:05:33 $Revision: r
11ros/6 PATCH_11.00 (PHKL_21781)
/usr/conf/lib/libhp-ux.a(vfs_bio.o):
vfs_bio.c $Date: 2002/04/29 12:59:24 $Revision: r11r
os/23 PATCH_11.00 (PHKL_26800)
/usr/conf/lib/libhp-ux.a(vm_clic.o):
vm_clic.c $Date: 2001/04/23 13:03:40 $Revision: r11r
os/4 PATCH_11.00 (PHKL_23857)
/usr/conf/lib/libhp-ux.a(vm_kern.o):
vm_kern.c $Date: 2000/04/12 03:18:15 $Revision: r11r
os/4 PATCH_11.00 (PHKL_21532)
/usr/conf/lib/libhp-ux.a(vm_machdep.o):
vm_machdep.c $Date: 2001/09/05 08:41:26 $Revision: r
11ros/36 PATCH_11.00 (PHKL_25164)
/usr/conf/lib/libhp-ux.a(vm_machreg.o):
vm_machreg.c $Date: 2002/06/25 08:41:53 $Revision: r
11ros/12 PATCH_11.00 (PHKL_27364)
/usr/conf/lib/libhp-ux.a(vm_memlock.o):
vm_memlock.c $Date: 2001/08/17 14:43:30 $Revision: r
11ros/5 PATCH_11.00 (PHKL_24971)
/usr/conf/lib/libhp-ux.a(vm_mlock.o):
vm_mlock.c $Date: 2000/05/03 15:11:15 $Revision: r11
ros/4 PATCH_11.00 (PHKL_21624)
/usr/conf/lib/libhp-ux.a(vm_mmap.o):
vm_mmap.c $Date: 2002/06/04 17:07:42 $Revision: r11r
os/25 PATCH_11.00 (PHKL_27238)
/usr/conf/lib/libhp-ux.a(vm_pgalloc.o):
vm_pgalloc.c $Date: 2000/05/03 15:11:15 $Revision: r
11ros/4 PATCH_11.00 (PHKL_21624)
/usr/conf/lib/libhp-ux.a(vm_pregion.o):
vm_pregion.c $Date: 2001/05/29 15:16:13 $Revision: r
11ros/11 PATCH_11.00 (PHKL_24273)
/usr/conf/lib/libhp-ux.a(vm_realmain.o):
vm_realmain64.c $Date: 2002/09/19 16:26:16 $Revision
: r11ros/10 PATCH_11.00 (PHKL_27919)
/usr/conf/lib/libhp-ux.a(vm_remap.o):
vm_remap.c $Date: 2000/08/14 11:40:53 $Revision: r11
ros/4 PATCH_11.00 (PHKL_22126)
/usr/conf/lib/libhp-ux.a(vm_sched.o):
vm_sched.c $Date: 2000/09/20 14:54:13 $Revision: r11
ros/8 PATCH_11.00 (PHKL_22440)
/usr/conf/lib/libhp-ux.a(vm_vas.o):
vm_vas.c $Date: 2001/09/11 13:56:29 $Revision: r11ro
s/13 PATCH_11.00 (PHKL_25210)
/usr/conf/lib/libhp-ux.a(vm_vfd.o):
vm_vfd.c $Date: 2002/10/16 15:44:52 $Revision: r11ro
s/9 PATCH_11.00 (PHKL_27994)
/usr/conf/lib/libhp-ux.a(vm_vhand.o):
vm_vhand.c $Date: 2000/04/12 03:18:15 $Revision: r11
ros/6 PATCH_11.00 (PHKL_21532)
cksum(1) Output:
OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
1807138169 5655 /usr/conf/h/map.h
143359630 10831 /usr/conf/h/vm_mlock.h
2017539801 2705 /usr/conf/machine/hdl_preg.h
2704551415 54554 /usr/conf/machine/pdc_rqsts.h
2001644049 11365 /usr/conf/sio/async.h
ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
2017539801 2705 /usr/include/machine/hdl_preg.h
2704551415 54554 /usr/include/machine/pdc_rqsts.h
2001644049 11365 /usr/include/sio/async.h
1807138169 5655 /usr/include/sys/map.h
143359630 10831 /usr/include/sys/vm_mlock.h
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
2456957590 21280 /usr/conf/lib/libhp-ux.a(asm_vm.o)
4111817225 22604 /usr/conf/lib/libhp-ux.a(async.o)
2995762857 4184 /usr/conf/lib/libhp-ux.a(clic_stubs.o)
2200571820 28992 /usr/conf/lib/libhp-ux.a(clock.o)
3673374354 12468 /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o)
2714317938 14204 /usr/conf/lib/libhp-ux.a(dmem.o)
2274047028 20992 /usr/conf/lib/libhp-ux.a(hdl_fault.o)
1950927501 8208 /usr/conf/lib/libhp-ux.a(hdl_init.o)
3547126769 19544 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
820165609 16900 /usr/conf/lib/libhp-ux.a(hdl_policy.o)
968477345 13352 /usr/conf/lib/libhp-ux.a(hdl_trans.o)
1744945478 24136 /usr/conf/lib/libhp-ux.a(init_main.o)
655038534 32016 /usr/conf/lib/libhp-ux.a(kern_exec.o)
355658871 27244 /usr/conf/lib/libhp-ux.a(kern_exit.o)
4220144817 16512 /usr/conf/lib/libhp-ux.a(kern_mallo.o)
1732973767 3892 /usr/conf/lib/libhp-ux.a(kern_mman.o)
261662307 23508 /usr/conf/lib/libhp-ux.a(kgdb_machine.o)
4184237216 12052 /usr/conf/lib/libhp-ux.a(kmall_trace.o)
2830529239 6688 /usr/conf/lib/libhp-ux.a(onyxe.o)
28026516 24204 /usr/conf/lib/libhp-ux.a(pa_generic_psm.o)
994675287 8424 /usr/conf/lib/libhp-ux.a(pm_core.o)
2267808605 3940 /usr/conf/lib/libhp-ux.a(pm_cred.o)
2699697363 17348 /usr/conf/lib/libhp-ux.a(pm_prot.o)
2505421652 55296 /usr/conf/lib/libhp-ux.a(pm_ptrace.o)
552125867 11480 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
1456491622 38576 /usr/conf/lib/libhp-ux.a(vfs_bio.o)
1106579325 4616 /usr/conf/lib/libhp-ux.a(vm_clic.o)
111450070 14300 /usr/conf/lib/libhp-ux.a(vm_kern.o)
2119366129 91552 /usr/conf/lib/libhp-ux.a(vm_machdep.o)
3140688612 23688 /usr/conf/lib/libhp-ux.a(vm_machreg.o)
2447862010 13212 /usr/conf/lib/libhp-ux.a(vm_memlock.o)
3239637922 5508 /usr/conf/lib/libhp-ux.a(vm_mlock.o)
4017747599 30512 /usr/conf/lib/libhp-ux.a(vm_mmap.o)
2363692938 18108 /usr/conf/lib/libhp-ux.a(vm_pgalloc.o)
1142048675 16056 /usr/conf/lib/libhp-ux.a(vm_pregion.o)
616813588 16212 /usr/conf/lib/libhp-ux.a(vm_realmain.o)
3797621466 9864 /usr/conf/lib/libhp-ux.a(vm_remap.o)
2591404438 27896 /usr/conf/lib/libhp-ux.a(vm_sched.o)
922257018 14996 /usr/conf/lib/libhp-ux.a(vm_vas.o)
579042781 15688 /usr/conf/lib/libhp-ux.a(vm_vfd.o)
1278797452 18564 /usr/conf/lib/libhp-ux.a(vm_vhand.o)
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
3906462109 20624 /usr/conf/lib/libhp-ux.a(asm_vm.o)
1872876499 47088 /usr/conf/lib/libhp-ux.a(async.o)
2655725780 11064 /usr/conf/lib/libhp-ux.a(clic_stubs.o)
2036148642 69752 /usr/conf/lib/libhp-ux.a(clock.o)
867340842 27976 /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o)
4179883992 32600 /usr/conf/lib/libhp-ux.a(dmem.o)
3959737292 40384 /usr/conf/lib/libhp-ux.a(hdl_fault.o)
363988396 23664 /usr/conf/lib/libhp-ux.a(hdl_init.o)
3803636533 40584 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
3458366998 35712 /usr/conf/lib/libhp-ux.a(hdl_policy.o)
2397291949 30128 /usr/conf/lib/libhp-ux.a(hdl_trans.o)
99692145 45600 /usr/conf/lib/libhp-ux.a(init_main.o)
3910748425 73064 /usr/conf/lib/libhp-ux.a(kern_exec.o)
3965228775 58008 /usr/conf/lib/libhp-ux.a(kern_exit.o)
2562214966 40688 /usr/conf/lib/libhp-ux.a(kern_mallo.o)
1485995480 9496 /usr/conf/lib/libhp-ux.a(kern_mman.o)
650197126 49456 /usr/conf/lib/libhp-ux.a(kgdb_machine.o)
2315482884 28136 /usr/conf/lib/libhp-ux.a(kmall_trace.o)
2985423105 16120 /usr/conf/lib/libhp-ux.a(onyxe.o)
3394952790 56256 /usr/conf/lib/libhp-ux.a(pa_generic_psm.o)
3497115895 15600 /usr/conf/lib/libhp-ux.a(pm_core.o)
1935319995 11120 /usr/conf/lib/libhp-ux.a(pm_cred.o)
1706233712 38488 /usr/conf/lib/libhp-ux.a(pm_prot.o)
1298300107 128424 /usr/conf/lib/libhp-ux.a(pm_ptrace.o)
3845905395 26936 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
4153440942 87152 /usr/conf/lib/libhp-ux.a(vfs_bio.o)
3690125124 9736 /usr/conf/lib/libhp-ux.a(vm_clic.o)
2977196837 62544 /usr/conf/lib/libhp-ux.a(vm_kern.o)
3632552418 183344 /usr/conf/lib/libhp-ux.a(vm_machdep.o)
3641373914 51592 /usr/conf/lib/libhp-ux.a(vm_machreg.o)
1899366477 32040 /usr/conf/lib/libhp-ux.a(vm_memlock.o)
4276086089 12768 /usr/conf/lib/libhp-ux.a(vm_mlock.o)
3607499471 69080 /usr/conf/lib/libhp-ux.a(vm_mmap.o)
2937271311 40984 /usr/conf/lib/libhp-ux.a(vm_pgalloc.o)
2859231644 32224 /usr/conf/lib/libhp-ux.a(vm_pregion.o)
1270365069 23344 /usr/conf/lib/libhp-ux.a(vm_realmain.o)
163951282 18552 /usr/conf/lib/libhp-ux.a(vm_remap.o)
3273318555 75072 /usr/conf/lib/libhp-ux.a(vm_sched.o)
3924587369 35600 /usr/conf/lib/libhp-ux.a(vm_vas.o)
532300028 37520 /usr/conf/lib/libhp-ux.a(vm_vfd.o)
914166320 46296 /usr/conf/lib/libhp-ux.a(vm_vhand.o)
Patch Conflicts: None
Patch Dependencies:
s700: 11.00: PHKL_18543
s800: 11.00: PHKL_18543
Hardware Dependencies: None
Other Dependencies:
PHKL_21549 is required when using the gang scheduler.
Without PHKL_21549, the gang scheduler exhibits unacceptable
performance after this patch is installed.
PHKL_23406: If NFS is installed on the system, all five
patches (PHNE_23249, PHKL_23406, PHKL_23407, PHKL_23408,
PHKL_23409) are required to resolve the process
hang/deadlock due to unkillable processes executed over NFS.
However, if NFS is not in use, none of these patches are
required.
PHKL_23813: Two other patches work in conjuction with this
patch to enable PA-8700 support. These other two patches
are PHKL_23814 and PHKL_23815.
Supersedes:
PHKL_22843 PHKL_22493 PHKL_22032 PHKL_21775 PHKL_21600 PHKL_21535
PHKL_21507 PHKL_21358 PHKL_21357 PHKL_21350 PHKL_20995 PHKL_20945
PHKL_20836 PHKL_20647 PHKL_20515 PHKL_20449 PHKL_20439 PHKL_20426
PHKL_20227 PHKL_20226 PHKL_20224 PHKL_20223 PHKL_20102 PHKL_20017
PHKL_19314 PHKL_19201 PHKL_17038 PHKL_27919 PHKL_27759 PHKL_27364
PHKL_27238 PHKL_27157 PHKL_26800 PHKL_25906 PHKL_25525 PHKL_25210
PHKL_25188 PHKL_25164 PHKL_24971 PHKL_24826 PHKL_24612 PHKL_24457
PHKL_24273 PHKL_24116 PHKL_24015 PHKL_23857 PHKL_23813 PHKL_23812
PHKL_23628 PHKL_23406 PHKL_23183 PHKL_22744 PHKL_22549 PHKL_22440
PHKL_22380 PHKL_22126 PHKL_21781 PHKL_21624 PHKL_21532 PHKL_21354
PHKL_21024 PHKL_21003 PHKL_20335 PHKL_20222
Equivalent Patches: None
Patch Package Size: 2950 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_27994
5. Run swinstall to install the patch:
swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHKL_27994.depot
By default swinstall will archive the original software in
/var/adm/sw/save/PHKL_27994. 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_27994.text file is
available in the product readme:
swlist -l product -a readme -d @ /tmp/PHKL_27994.depot
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHKL_27994.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
To enable the asyncio enhancement that defers memory
locking to improve application startup times, create the
async device file with minor number 256 using the
following commands. The user must have super-user rights
to execute these commands.
Delete the old device file.
# rmsf -v /dev/async
Create the new device file
# mknod /dev/async c 101 256
Note: This minor number should only be used on systems that
have enough physical memory so that paging is avoided.
Paging can cause serious performance degradation with this
new enhancement. On systems where paging is an issue, this
minor number should not be used.
PHKL_23813:
This patch, PHKL_23813, is one of the three 11.00 PA-8700
enablement patches. The other 11.00 PA-8700 enablement
patches are PHKL_23814 & PHKL_23815. Installation of
each patch individually will have no effect on the system.
PHKL_23406:
If NFS is installed on the system, all five patches
(PHNE_23249, PHKL_23406, PHKL_23407, PHKL_23408, PHKL_23409)
are required to resolve the process hang/deadlock due to
unkillable processes executed over NFS. However, if NFS is
not in use, none of these patches are required. All five of
these patches may be installed independently. If fewer than
four out of the four PHKL patches are installed, the
P_NOSTOP feature will not be enabled.
PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20226, PHKL_20227:
This patch contains part of the enhancement to enable the 3
Gb private address space feature. It is one of 8 patches.
The 8 patches necessary to enable this feature are
PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20226,
PHKL_20227, PHKL_20228 and PHKL_20229. Each patch may be
installed independently of the others - if enabling the 3 Gb
private address space feature is not desired. If fewer than
all 8 patches are installed, the 3 Gb private address space
feature will not be enabled. The code in this patch that is
part of this feature will not have any impact on the system
until all 8 patches are installed.
In order to be able to use this feature you will need to
reconfigure the kernel with a larger value for the kernel
configurable variable "maxdsiz". In order to do this with
SAM, you will also need to install patch PHKL_20174. Without
PHKL_20174 installed SAM will not allow maxdsiz to exceed
~1.9 Gb. Note that if PHKL_20174 is not installed it is
still possible to manually configure a kernel with a larger
value of maxdsiz (up to 3 Gb) using config(1M).
PHKL_21535:
To enable shared memory dumping to application core files,
you must first install this patch. After the new vmunix
has been built by the patch process you need to set some
kernel variables in the new vmunix using adb.
To do this, first invoke adb with write capabilities
on the vmunix file (typically /stand/vmunix):
adb -w /stand/vmunix
You may get some error output "Not an Elf file: No Elf
header". ignore those errors.
Setting core_addshmem_read to 1 enables dumping of
read-protected shared memory segments.
To set core_addshmem_read to 1, the command in adb is:
core_addshmem_read?W1
adb should output:
core_addshmem_read: 0 = 1
Setting core_addshmem_write to 1 enables dumping of
write-protected shared memory segments.
To set core_addshmem_write to 1, the command in adb is:
core_addshmem_write?W1
adb should output:
core_addshmem_write: 0 = 1
exit adb by typing
$q
Now the vmunix file should be enabled for shared memory
dumping. You must reboot in order for the change to take
effect. Note: if a new vmunix is generated in the future,
such as after installing another kernel patch, you will need
to repeat this procedure. This mechanism is typically used
in troubleshooting applications.
The effective user ID of the process calling async driver,
typically called by a process for database applications such
as Oracle and Sybase, must be a superuser or the user must
be a member of a group that has the MLOCK privilege.
To check the privilege capabilities for a group, issue the
command:
/usr/bin/getprivgrp <group-name>
If the output of getprivgrp(1) does not indicate that the
group has the MLOCK privilege, it can be set by issuing the
following command as root:
/usr/bin/setprivgrp <group-name> MLOCK
This patch depends on base patch PHKL_18543.
For successful installation please insure that PHKL_18543
is already installed, or that PHKL_18543 is included
in the same depot with this patch and PHKL_18543
is selected for installation.
|
Printable version
