Patch Name: PHKL_14803
Patch Description: s700 10.20 UFS,VM,LVM,I/O,JFS,SCSI,PM cumulative patch
Creation Date: 98/04/20
Post Date: 98/04/22
Hardware Platforms - OS Releases:
s700: 10.20
Products: N/A
Filesets:
AdvJournalFS.VXFS-ADV-KRN JournalFS.VXFS-BASE-KRN
JournalFS.VXFS-PRG LVM.LVM-KRN OS-Core.CORE-KRN
OS-Core.KERN-RUN ProgSupport.C-INC
Automatic Reboot?: Yes
Status: General Superseded
Critical:
Yes
PHKL_14803: HANG
PHKL_14568: PANIC
Panic while trying to perform an lvmerge operation.
PHKL_14613: HANG
PHKL_11316: HANG
The system hangs when a large number of users try
to log in/out of the system simultaneously.
PHKL_14490: PANIC HANG
PHKL_14321: PANIC
PHKL_14225: ABORT
PHKL_14126: PANIC CORRUPTION
PHKL_14049: PANIC
PHKL_13911: PANIC
PHKL_13768: OTHER
Prevents MC/Service Guard TOC on PA8000 systems.
PHKL_13452: PANIC
PHKL_13305: HANG
PHKL_13260: HANG
This patch fixes a defect which could essentially
hang the systems with VISUALIZE-FX graphics
hardware. The patch in addition to this fixes a
performance problem seen on systems that use
applications with large number of shared memory
segments. The systems spend too much time
servicing protection id faults.
PHKL_13247: ABORT PANIC
PHKL_13206: CORRUPTION
a clean file on VxFS can be marked bad.
PHKL_13155: HANG
PHKL_12963: PANIC
PHKL_12901: PANIC
PHKL_12662: HANG
PHKL_12397: PANIC HANG
PHKL_12110: PANIC HANG
PHKL_12100: CORRUPTION
Kernel portion of fix for unrepairable JFS
file system where fsck produces the error
message "no valid ILIST in fileset 999".
PHKL_12088: OTHER
Patch REQUIRED for the OmniStorage 2.20 product
PHKL_11860: PANIC
PHKL_11766: PANIC
PHKL_11733: OTHER
Unmountable VxFS (JFS) file system.
PHKL_11730: PANIC
PHKL_11696: PANIC
PHKL_11607: PANIC
PHKL_11561: CORRUPTION
This patch when used with the appropriate
SG/DLM version will avoid any potential
windows for data corruption during
reconfiguration in a HA cluster env. using
SG or DLM.
PHKL_11519: ABORT
PHKL_11408: CORRUPTION
PHKL_11406: CORRUPTION
PHKL_11358: PANIC
PHKL_11321: PANIC
PHKL_11238: PANIC
So far, the panic only appears on MP systems
running the latest Informix release.
PHKL_11164: PANIC
PHKL_11085: CORRUPTION
From a customer perspective, EMC Symmetrix disks
can appear to lose or corrupt data when rare
spurious errors are reported. The data is actually
able to be recovered on the disk, and this patch
allows LVM to ignore the fact that the block was
once "bad" and obtain the good data from the
repaired block.
PHKL_11055: HANG
PHKL_11039: CORRUPTION
This patch fixes data corruption for applications
that create large files which keep changing their
size dynamically.
PHKL_11013: OTHER
This problem leaves the file system disabled and
unusable, and requires a system reboot to regain
access to it.
PHKL_10953: HANG
PHKL_10932: OTHER
HPMC on Emerald-class systems at boot time.
PHKL_10930: HANG
PHKL_10757: PANIC
PHKL_10675: PANIC CORRUPTION
PHKL_10643: PANIC
PHKL_10554: PANIC
The HPMC/panic that is fixed by this patch has been
observed only in rare instances on pre-release
hardware. However, the potential exists for similar
problems in the field only if PHKL_9151 has been
applied. This fix should also provide increased
performance for PA-8000 systems.
PHKL_10452: PANIC
PHKL_10288: PANIC
PHKL_10257: PANIC
PHKL_10234: PANIC
PHKL_10199: CORRUPTION
PHKL_9931: HANG
PHKL_9909: HANG
PHKL_9569: HANG
PHKL_9517: CORRUPTION
PHKL_9372: PANIC
PHKL_9370: OTHER
Unmountable VxFS (JFS) file system.
PHKL_9365: CORRUPTION
PHKL_9361: PANIC
PHKL_9075: PANIC
PHKL_8953: HANG
PHKL_8683: PANIC
PHKL_8532: CORRUPTION
PHKL_8331: CORRUPTION
PHKL_8294: HANG
PHKL_8203: HANG
PHKL_8084: ABORT
PHKL_7899: PANIC HANG OTHER
The KI instrumentation fix does not fall into any of
specified symptoms; the root setuid fix does not
either.
PHKL_7870: PANIC
PHKL_7776: OTHER
Unmountable VxFS (JFS) file system.
Path Name: /hp-ux_patches/s700/10.X/PHKL_14803
Symptoms:
PHKL_14803:
SR: 5003407601 DTS: JAGaa02119
System hangs during reboot.
SR: 5003407619 DTS: JAGaa01516
Under heavy I/O, after the buffer cache allocation has
reached its system defined maximum, the system
eventually hangs when all I/O processes sleep on waiting
for buffer cache.
PHKL_14740:
When a Service Guard cluster experiences a failure on one
node, the volume groups may fail to activate on the
surviving node when the shared disks are using Fibre
Channel.
PHKL_14685:
When the customer installs the flock manager driver, the
library libflkmgr.a does not exist. This is seen only
in those environments running flock manager.
PHKL_14568:
This patch fixes 3 defects:
- SR:1653254987 DTS:JAGaa01797
MP systems using LVM mirroring could experience panics
(data fage fault) while doing an lvmerge() operation.
- SR:4701379347 DTS:DSDe441470
Add flock manager driver functionality
- SR:1653216952 DTS:DSDe437110
sleep(3C) behaves incorrectly for values larger than
(2^32-1)/200 = 21474836 seconds. The man page documents
legal values up to 2^32-1 seconds + 10^9-1 nanoseconds.
PHKL_14613:
System hangs under extreme load on UFS file system
while a logical volume creation is in progress.
PHKL_11316:
A system "HANG" occurs whenever a large number of users
log In/Out at the same time. The password file has large
number of entries and the system can have around 1000
concurrent connections. Problem occurs when many
processes try to access the same file concurrently, the
inode locking routines start dealing with the contention
very inefficiently.
PHKL_14490:
This patch fixes three defects:
- SR: 4701382564, DTS: DSDe441726
If the kernel free sysmap space falls to 0, the system
panics without prior warning that indicates this condition.
- SR: 1653251934 DTS: JAGaa01592
The System hangs under heavy I/O involving
VxFS type of filesystems. When the buffer
cache virtual space is heavily fragmented
and a readhead is being done, system hangs.
- SR: 1653252544 DTS: DSDe441877
Some user applications will hang with high system load.
These processes cannot be killed and the system needs to
be rebooted to clear these processes.
PHKL_14323:
Command lvlnboot may fail with the following error:
"No Boot Logical Volume Configured".
PHKL_14321:
This patch fixes two defects :
- SR: 1653235176, DTS: JAGaa01482
This defect causes a panic in a multi processor system
when two processes are doing mmap/munmap on portions of
the same file using a sliding window. The user will see
the system panic with "panic: rmfree: overlap" message.
The stack trace will be as shown below:
panic+0x10
rmfree+0x268
quaddealloc34+0x30
hdl_detach+0x108
detachreg+0x3c
do_munmap+0x190
do_munmap+0x84
syscall+0x1a4
A different panic could occur due to an unrelated race
condition when mmap/munmap is called. This second panic
is a result of data page fault. The stack trace in this
case will be as shown below:
panic+0x3C
report_trap_or_int_and_panic+0x8C
trap+0xC18
$RDB_trap_patch+0x20
smmap+0x8F0
syscall+0x1A4
- SR: 4701383612, DTS: DSDe441827
The defect's symptoms are that writes to a VME device
will succeed on 10.20 but reads will fail with EFAULT.
PHKL_14225:
Application experiences random illegal instruction trap
when executing cache flushing code.
PHKL_14183:
This patch is part of the 10.20 ACE 2 bundle which adds
networking enhancements to 10.20. New networking features
supported in ACE 2 include NFS Version 3.0, AutoFS, and
CacheFS.
PHKL_14126:
This patch fixes two defects :
- SR: 4701381608, DTS: DSDe441567
Patch PHKL_13684 introduced a defect that can break
applications which use the vnode layer procedure
vn_open(). This can result in a panic due to an invalid
address or possibly on data corruption. Currently we are
only aware of conflicts with Netware.
- SR: 1653223404, DTS: DSDe438306
vgchange display couldn't query one physical volume
The specified path does not correspond to physical volume
attached to this volume group. After issue vgchange with
-a y -q n options, system trap panic.
PHKL_14049:
This patch fixes three problems:
a) SR: 1653247486, DTS: JAGaa01357
For a mirrored LVM root disk containing 2**n extents, if
the system is booted in maintenance mode (hpux -lm), it
will panic with trap 15 data page fault on the next
reboot.
b) SR: 1653239137, DTS: JAGaa01378
For a root volume group with two disks which are mirror
partners, if one disk becomes inaccessible, the system
panics on bootup with trap 15 data page fault.
c) SR: 1653248690, DTS: JAGaa01406
System panics in lv_end() with isr.ior=0.58 data page
fault when a bad block is detected on disk. The console
message shows:
lv_readvgdats: Could not read VGDA 1 header & trailer
from disk H/W path x/x.x.0 (error = 5)
lv_readvgdats: Could not read VGDA 2 header & trailer
from disk H/W path x/x.x.0 (error = 5)
PHKL_14012:
This is an enhancement to add the flock manager driver hooks
to the kernel. This patch is only needed if you are planning
to use the flock manager driver.
PHKL_14009:
pstat_getlv() returns information about first VG only.
PHKL_13911:
In a mixed hfs/vxfs environment, the system panics with a
dirty invalid buffer which was associated with an hfs fs
that has since been unmounted. The typical stack trace
of the panic looks like the following:
panic+0x14
brelse+0x1ec
getnewbuf+0x6b0
ogetblk+0x104
getblk1+0x258
vx_getblk+0x5c
PHKL_13874:
This patch fixes two problems:
a) When running fsadm on a file which was created under JFS
version 2, sometimes "Invalid Argument" would be reported
b) When running fsadm on a file which was created under JFS
version 2, sometimes "No such device or address" would be
reported
PHKL_13795:
This patch is part of the 10.20 ACE 2 bundle which adds
networking enhancements to 10.20. New networking features
supported in ACE 2 include NFS Version 3.0, AutoFs, and
CacheFS.
PHKL_13768:
Temporary system hang on PA8000 systems, possibly resulting
in TOC to preserve system integrity (if running MC/Service
Guard). When analysing the system crash dump, a processor
would be executing in the kernel routine alloc_large_page().
PHKL_13761:
mprotect() system call causes high system time resulting
in poor system performance.
PHKL_13713:
When using chown for certain user IDs, the command would
fail.
PHKL_13684:
In a multi-vendor client-server environment (HP client or
HP server), a user-supplied umask is ignored during file
creation, even if no default ACL is present. This appears
to violate POSIX ACL draft 12.
PHKL_13680:
10.xx read/write via block special device file is slower
than 9.xx.
PHKL_13508:
On a heavy fragmented JFS filesystem bdf and df show only
small amounts of available space. df furthermore shows a
larger percentage number for minfree although this concept
is unknown to JFS. All this is ok on a JFS Version 2 fs,
but on a Version 3 fs extents smaller than 8k are available
for files.
PHKL_13452:
The user will see a data page fault PANIC with
vx_attr_alloc(), vx_attr_indadd(), or vx_attr_iget() at the
top of the stack.
A sample stack trace might look like:
panic+0x10
report_trap_or_int_and_panic+0xe8
trap+0x1054
$RDB_trap_patch+0x20
vx_attr_iget+0x90
vx_iremove_attr+0x358
vx_attr_uset+0x374
vx_do_ioctl+0x73c
vx_ioctl+0x38
vno_ioctl+0x98
ioctl+0x444
syscall+0x1a4
PHKL_13305:
This problem manifests as a hang during a reboot operation.
The reboot can be initiated with a shutdown command. The
problem will only appear on a multi-processor machine. I/O
in progress during the reboot either from disk or from the
network can cause the primary reboot processor to wait for
an indefinite amount of time.
PHKL_13260:
This patch fixes three problems:
a) SR: 1653237842, DTS: JAGaa01160
Slow performance with high system time on PA2.0 and PA1.1
systems. The system slows down under user applications
with lots of shared memory segments (like Informix
database which uses lots of shared memory segments).
b) SR: 1653237842, DTS: JAGaa01160
Illegal sharing of protection id's lead to silent data
corruption (SHMEM_MAGIC applications)
c) SR: 4701373969, DTS: DSDe440766
This defect causes VISUALIZE-FX graphics hardware to
lock-up. If the VISUALIZE-FX device is the console for
the machine, this will render the machine unusable unless
it can be reached over a network (in which case killing
and restarting the X server should fix the problem).
CTRL-SHIFT-RESET from the console keyboard will not
terminate the X server in this case.
PHKL_13247:
The shared PV LINKS will not switch when needed.
The activation of the volume group using vgchange -a s
may fail on one of the nodes if the command is being run
simultaneously on all the nodes.
HPMC or bad pointer panic in FibreChannel
driver on ServiceGuard cluster fail-over.
Failure to activate volume group (any I/O
connect type) on ServiceGuard cluster
fail-over.
PHKL_13237:
If serialize() command is executed as: 'serialize ls', the
command fails with the error number set to EINVAL. (User id
must be 0, or user belong to a group that has privilege to
execute the serialize command). The serialize command
should have serialized the target process, in this case the
command 'ls', and should have listed the content of the
current directory.
PHKL_13206:
When getdirentries() is incorrectly called with a regular
file on VxFS(JFS) file system, following message will be
reported and the clean file can be marked bad.
"vxfs: mesg 008: vx_direrr - <FS> file system inode X
block Y error 6" or
"vxfs: mesg 017: vx_dirbread - <FS> file system inode X
marked bad" or
"vxfs: mesg 016: vx_ilisterr - <FS> file system error
reading inode X"
PHKL_13155:
Processes hang intermittently due to process deactivation
and reactivation.
PHKL_12997:
When dump is configured past 2GB on a device connected to a
HSC F/W SCSI interface card, the device fails to configure:
WARNING: Dump space on device <device ID> cannot be
configured past 2097151 bytes.
Device <device ID> skipped.
PHKL_12963:
In the past, a process running in a group could consume
more than just its own groups entitlement if excess CPU
cycles were available. This change allows this to optionally
be disallowed / capped within PRM
Also, there was a problem when PRM, thread stealing and
processor affinity were used/occurred on a system at the
same time. In this case, it was possible for a processor
to not find a process, which could cause a panic.
PHKL_12901:
A kernel stack overflow panic occurs when the stack is
valid and all the 3 pages allocated for kernel stack
are consumed. The defect is seen when a combination of
NFS,LVM,JFS related modules are called.
PHKL_12669:
This patch contains problems in three areas:
1. There are no warning to user when bad block alternates
were allocated inside the user data area.
2. There is no way to use lv timeout feature when the async
driver minor number is not 0.
3. Add a new lvol flag in lv_lvsubr.c to support a command
patch.
PHKL_12662:
HFS file system may hang on system reboot.
PHKL_12633:
SHMEM_MAGIC executables suffer from unacceptable performance
greatly impairing its usefulness.
PHKL_12601:
VxFS systems do not allow a process to ftruncate() a file
it has opened, write-locked and read from. When the program
fails, errno is set to 11 which means resource is
temporarily unavailable.
PHKL_12409:
Applications relying on alarm() returning a number greater
than zero will fail if there was time remaining on the
cancelled alarm and were trying to re-schedule the original
alarm.
alarm() returns "zero" when cancelling a previous alarm()
with an alarm pending.
PHKL_12397:
This patch fixes two defects :
- System panic (data page fault) when debugging processes
over an interruptable NFS mount point.
- After call to pstat_getmsg(), all accesses to the message
queue hang.
PHKL_12378:
Multiprocessor systems running applications that require
many files with filenames longer than 14 characters to
be accessed will experience severe CPU contention.
Netscape Mail server v3.0 with Netscape mail server
Benchmark puts this in evidence by reporting a very low
message receive/deliver rate. Systems with large buffer
cache will have spinlock contention problem.
PHKL_12217:
The tar command can go into a close loop, backing up the
same file over and over on a nfs mounted filesystem. So
far this problem has been seen only on nfs filesystems
exported from SGI IRIX 6.2 systems.
PHKL_12110:
System hangs on UP systems or spinlock deadlocks on MP
systems, when using nanosleep system call. If using signals
which were to be ignored when in nanosleep() we were awaken
eventhough we should not. Patch is especially critical as
soon as newer libc patches are installed on the system too.
The first releases of libc to be critical are PHCO_10384
for 10.10, PHCO_11004 for 10.20 and PHCO_10652 for 10.01.
PHKL_12100:
kernel part of the fix for the slow fsck problem:
command patch PHCO_12922
The following problems are fixed:
1) Under certain circumstances after a hard failure,
VxFs fsck log replay would fail requiring a full fsck.
2) On large file systems containing a very large number
of files, full fsck would run extremely slowly.
PHKL_12088:
The DMAPI functionality as delivered with HP-UX 10.20 is not
functional. Thus the OmniStorage product, which relies
exclusively on this functionality, will not work with the
shipped JFS DMAPI software provided with the OnlineJFS
product.
PHKL_12073:
With sa_flags (in sigaction structure) set to SA_SIGINFO,
after a child process abnormally terminates without a core
file being generated, the si_code number of the siginfo_t
structure is supposed to contain CLD_KILLED. This failed
to happen when the child process abnormally terminated
with a SIGPOLL signal.
PHKL_12042:
Resource-intensive processes (such as an Informix oninit)
either perform poorly over time (as timeshare) or
monopolize the system (as realtime).
Also, MP systems show processes frequently being moved
from one CPU to another.
PHKL_11902:
pid information is missing from a diagnostic
message which tries to explain to a user that their
process does not have the correct locking priveleges
required for using large text pages.
PHKL_11860:
The PHKL_9371 installed system panic's during reboot, if
reboot command is used. This patch fixes this problem.
PHKL_11766:
1. vgextend command will complain "too many links" if
user wants to add an addition physical volume to a
volume group, and the total physical volume and
their links add up to total number of max physical
volume allowed in a volume group.
2. trap panic in lv_resyncpv from LVM.
lots of "pvnum is POWERFAILED" messages
PHKL_11733:
After a hard failure (panic/hang/TOC), a JFS file system may
not mount and will return the following error message:
vxfs mount: %s is not a vxfs file system.
This could even happen with patches PHKL_9371 and PHCO_11223
installed. A full fsck does not clean the file system; a
newfs/mkfs is the only solution.
PHKL_11730:
Data page fault in bwrite.
PHKL_11696:
panic: hdl_alloc_spaceid: spacemap exhausted
PHKL_11637:
CDROM drive remains locked when system is rebooted.
PHKL_11614:
Accounting does not work for the clients (diskless) in a
cluster. The accounting file does not get updated for
users other than ROOT when accounting is ON.(when pacct
file is on NFS file system).
PHKL_11607:
System may panic in vx_itimes() when mounting a JFS file
system after a boot from a hard failure.
PHKL_11561:
A customer might find corrupt data on disk after a Service
Guard or Distributed Lock Manager fail-over. This defect
is specific to the HA cluster environments.
PHKL_11519:
On a NFS server with a Vxfs file system exported, the
file /var/adm/nettl.LOG0x grows dramatically with the
recording of "read failed with errno 22" (EINVAL).
This problem is addressed by kernel patch PHKL_11322
among other problems. However, after the patch is installed,
some NFS clients experience command coredump on the NFS
mounted VxFS disk.
PHKL_11471:
Quota command shows poor performance on a busy system
under JFS.
PHKL_11408:
Corruption of memory pages on systems with PA-RISC 2.0 cpu.
Problem should happen rarely and only under extreme memory
stress.
PHKL_11406:
When using large environments greater than 20 kbytes
user applications dump core sometimes, or get bad
data.
PHKL_11358:
A panic would result when trying to rename a vnode which was
a UFS mount point under a JFS directory. The reverse did not
cause a panic but was not being handled properly either.
PHKL_11339:
A process launched from shell sees (getrlimit) limits set in
the shell via ulimit -t but ignores them. When a process
forks, the child sees the limits set by the parent via
setrlimit but ignores them
PHKL_11321:
This patch fixes two JFS performance problems and one
defect:
1) Upgrading from 10.10 to 10.20, customer experienced
approximately 25% performance degradation in read operation
under JFS.
2) Loading a program for a second and subsequent time takes
much longer if the program is using shared libraries on
JFS.
3) Occasional panic occurs when running an executable which
attempts to pagein through vnode level, producing a stack:
trap+0xf84 0.0xe21c4 0x6954.0x7ffe75b8 ...
$RDB_trap_patch+0x20 0.0x22608 0x6954.0x7ffe75b8 ...
lbcopy_fp_method1+0x58 0.0x222b98 0x6954.0x7ffe7108 ...
privlbcopy+0x1c 0.0x222fc4 0x6954.0x7ffe70c8 ...
uiomove+0x4f0 0.0xfabe8 0x6954.0x7ffe7008 ...
vx_read1+0x26c 0.0xb9744 0x6954.0x7ffe6ec8 ...
vx_rdwr+0x16c 0.0xc5164 0x6954.0x7ffe6e08 ...
vn_rdwr+0x8c 0.0x107b04 0x6954.0x7ffe6d48 ...
mfs_hpux_pagein+0x448 0.0x1cbb5c 0x6954.0x7ffe6c88 ...
virtual_fault+0x9a0 0.0xf1fc8 0x6954.0x7ffe6b48 ...
vfault+0x104 0.0xf281c 0x6954.0x7ffe6ac8 ...
trap+0x129c
and the message:
trap type 15, pcsq.pcoq = 0.222b98, isr.ior = 18e.4179000
savestate ptr = 0x7ffe7108, savestate return ptr = 0x222fc4
9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996
panic: (display==0xbd00, flags==0x0) Data page fault
This is mostly seen on PureAtria's Clearcase product which
sets the UIOSEG_PAGEIN flag for vn_rdwr() calls.
PHKL_11247:
On a VxFS with quota turned on, users who do not have
quota set receive "write: Disk quota exceeded" error
message when creating files on this file system.
PHKL_11244:
When accessing an address returned by mmap(), the
application gets a SIGBUS error and core is dumped.
PHKL_11238:
Panic on S800 MP systems using 10.01+ with latest Informix
PHKL_11164:
The system message buffer would show many "sysmap: rmap
ovflo, lost [...]". Eventually, the system would panic
with "kalloc: out of kernel virtual space." This problem
would only be seen on PA8000 systems.
PHKL_11085:
On very rare occasions EMC Symmetrix disk drives will
report a disk error which causes LVM to mark the block as
bad in its bad block directory. The Symmetrix drive can
be "repaired" online by EMC support, but the entry in the
LVM bad block directory will prevent any further I/O to
the affected block. This patch enables a new relocation
policy which will prevent entries from being added to
the bad block directory. In order to make use of this
new relocation policy, a commands patch, PHCO_10826
must also be installed.
Also, algorithms within LVM that deal with PVLinks had
built in the assumption that NIKE serial numbers were
unique. This turned out to not be the case. The only
time that the serial numbers need to be unique is in
OPS clusters. This patch removes this restriction
for all non-OPS cluster environments.
PHKL_11055:
Large memory systems could hang while trying to allocate
kernel memory. A TOC crash dump would show a processor
executing in alloc_large_page() while other processors
would be spinning waiting for the pfdat_lock spinlock.
This problem would only be seen on PA8000 systems.
PHKL_11039:
JFS file system corruption when running applications
using file truncation on large files. The system message
buffer will show: "vxfs: mesg 017: vx_trunc - /mnt file
system inode 123 marked bad.
vxfs: mesg 016: vx_ilisterr - /mnt file system error
reading inode 123". It also fixes a malloc panic which
was found while fixing this defect.
PHKL_11013:
The vxupgrade command, used to convert a JFS version 2 file
system to a version 3, can give an I/O error on execution.
This causes the file system to be marked as unavailable, and
a full fsck to be run.
PHKL_11006:
timer_settime(2) does not set 10ms timer interval
properly. The smallest interval can be set is 20ms.
PHKL_10966:
When running fsadm to reorganize extents (de-fragment) the
command fails with error:
exclusion zone for bno = 323584, len = 2048 failed
This error message does not occur at all times. It has
been observed when running fsadm on file systems which
contain directories with many small files.
PHKL_10953:
Severe system hang: the crash dump (TOC) would show many
threads waiting for the filesystem alpha semaphore.
The kernel stack trace of the thread owning filesys_sema
would show bc_yield() calling swtch().
PHKL_10932:
(4701353078/DSDe436182) Emerald-class (890, T5x0, T600)
systems will experience an HPMC at boot when IODC for memory
controllers is being accessed. Note: if you are not
experiencing this problem now, then your memory controllers
are not subject to this problem. (This problem is NOT
intermittant.)
PHKL_10930:
The system hangs when trying to dump core, as the result
of a system panic or TOC. (Normally, it would dump core
and reboot.)
PHKL_10821:
Although users can now exec() programs with up to 2048000
bytes of argument and env strings, sysconfig() _SC_ARG_MAX
continues to return 20480 bytes as the maximum length of
all arguments and env strings.
PHKL_10800:
audit records contain relative path names which the user has
no idea where they are anchored. this fix prepends the cwd
to the relative path name yielding a complete absolute path
PHKL_10757:
Workstation Additional Core Enhancements for HP-UX 10.20
(July 1997). This patch provides additional enhancements
to support new HP workstations. The primary change is
the addition of a new signal (SIGGFAULT) and virtual
memory subsystem changes to support virtual device locking
for new VISUALIZE-FX graphics hardware. It also contains
two bug fixes: one for the MP PDIR bug (could panic the
system) and the other for the pstat_cmd() panic.
PHKL_10689:
HP-UX didn't log any error when a user process:
1. encounters a swap space shortage
2. exceeds a system resource limitation
Processes were terminated but the errors were not
recorded on any of the system log files.
PHKL_10675:
(1) System may panic with "panic: sync not stale" while
running lvmerge (merging LVM mirrors). For the panic
to occur, an i/o timeout must occur during the lvmerge
operation which results in a resync getting scheduled.
(2) Potential data corruption if user i/o's encounter errors
to the same extents which are being reimaged by lvmerge.
(3) Various panics during vg activation(vgchange -a).
A bit is cleared in a kernel structure which LVM has already
freed. If another kernel subsystem has been allocated the
freed memory before the bit is cleared, panics or other
strange behaviors may occur. This particular defect
was introduced by PHKL_9000.
PHKL_10643:
System panic with Memory Mapped Files on UFS filesystem.
A typical kernel stack trace would show a data page fault
panic in hdl_unsetbits() called from async_pagein_comp().
PHKL_10554:
PA-8000 performance; fix kernel-assisted branch prediction.
Corrects corner case condition that causes an HPMC. The
stack trace would point to module flip_comb(). This corner
case has only been seen in lab-internal testing, using
pre-release hardware. It has not been seen on any
customer's system.
PHKL_10452:
Panic: kernel stack overflow; trace includes lv_end().
PHKL_10316:
When ptrace is called from the DDE debugger while the DDE
debugger has watchpoints set, the ptrace system call is
called to single step the user process. If the ptrace call
is handling a user signal and another signal event is pro-
cessed before returning to the user process from ptrace,
ptrace may incorretly sent the user's save_state program
counter to an incorrect value and return EIO to the parent
debugger.
PHKL_10288:
Panic trap 15 in bwrite() under heavy disk I/O stress.
PHKL_10257:
Panic with "vn_rele" with EXEC_MAGIC executable run over NFS
PHKL_10234:
panic: kernel scheduler interrupt
PHKL_10199:
10.20 JFS version 3 file system returns the following file
allocation error on file systems large than 64Gb before the
file system is actually full:
vxfs: msg001: vx_nospace - /dev/vgXX/lvolY file system full
(1 block extent)
The following console message may also be seen:
vxfs: mesg 003: vx_mapbad - /dev/vgXX/lvolY file system
free extent bitmap in au nnnn marked bad
PHKL_10176:
The total length (including terminators) of all argv and
env strings passed to a newly-EXECed process was 20480
bytes. If a greater length was detected, the exec() failed
with E2BIG.
PHKL_10064:
Setting a negative timestamp with utime() fails
PHKL_9931:
VxFS hangs waiting for I/O to finish..
PHKL_9919:
Timing differences between CPU to large, causes MI Daemon
to die frequently (often in less than 15 minutes).
PHKL_9909:
A deadlock can occur on system running LVM, JFS and HFS.
The hang was introduced by one process running lvmerge
on HFS logical volumes and another process running umount
on a JFS logical volume. This deadlock can only occur
with the following scenario:
(1). Process A is running a lvmerge or a lvsplit on a HFS
logical volume
(2). Process B is running a mount, umount or sync on a JFS
logical volume.
PHKL_9711:
Each time edquota -t is invoked for a VxFS file system, it
resets the previously defined file system time limit back
to default (7 days).
PHKL_9569:
This patch addresses 2 distinct VxFS (JFS) symptoms:
- When trying to take a file-system snapshot, the mount
command could fail with the following error message:
# mount -F vxfs -o snapof=/dev/vg00/vxonline \
/dev/vg00/vxbackup /vxbackup
vxfs mount: /dev/vg00/vxbackup is already mounted,
/vxbackup is busy, or allowable number of mount
points exceeded
- The system could hang when manipulating directories.
PHKL_9529:
vgdisplay(1M)/vgextend(1M) show incorrect value for
max number of PE per PV.
PHKL_9517:
VxFS file system corruption can occur when running the reorg
option of the fsadm command on a busy file system. System
diagnostic messages from the dmesg command will include the
following:
vxfs: mesg 008: vx_direrr - /??? file system inode X block Y
error 6
vxfs: mesg 017: vx_iread - /??? file system inode X marked
bad
vxfs: mesg 016: vx_ilisterr - /??? file system error reading
inode X
vxfs: mesg 008: vx_direrr - /??? file system inode X block Y
error 6
vxfs: mesg 017: vx_iread - /??? file system error reading
inode X
.
.
.
PHKL_9372:
Panic: "data page fault" when using fsadm to resize a
mounted VxFS filesystem with disk quotas.
PHKL_9370:
If a customer upgrades from 10.01 or 10.10 to 10.20, and
tries to increase their VxFS file systems via SAM, the file
system will not mount after completion of extending the
volume and file system. The typical approach for SAM is:
1) unmount the file system
2) lvextend the volume
3) extendfs the file system
4) mount the file system
The mount will always fail in this case.
PHKL_9365:
The only symptom is random, spurious, rare instances of
data corruption, usually in I/O to devices. This is rare
enough (and masked by normal system configurations) that
it has not been observed in customer systems, only within
HP.
PHKL_9361:
MP machine used as a nfs client panics with:
panic: (display==0xb800, flags==0x0) Data page fault
panic stack:
crash event was a panic
panic+0x10
report_trap_or_int_and_panic+0x8c
trap+0xbfc
$call_trap+0x20
binvalfree_vfs+0x5c
rinval+0x10
nfs_unmount+0x20
umount_vfs+0x5c
umount_root+0x20
umount+0x98
syscall+0x1a4
PHKL_9273:
On MP systems with several processors, applications which
do file locking frequently can perform poorly. The symptoms
are a high switch rate (switch rate > syscall rate) and
heavy system activity (%sys > 90%).
PHKL_9153:
Add write-gathering support for NFS servers.
PHKL_9151:
This patch includes 3 separate performance enhancements.
All are targetted for PA-RISC 8000 processors.
1. Kernel-assisted branch prediction.
2. bl->bll branch stub elimination.
3. Re-positioning perf-critical kernel assembly routines.
PHKL_9075:
Applications using Memory Mapped Files were performing
poorly when mapping thousands of pregions to the same file.
The problem would mainly be noticed with shared (MAP_SHARED)
and exclusive (MAP_FIXED with address in the process private
data space) mappings. This patch is required when using the
Object Store database product from ODI.
Additionally, this patch provides an enhancement to the
mprotect(2) system call: mprotect(2) used to fail protecting
non mmap(2)'ed addresses. This patch enables to mprotect(2)
data, stack and shared memory segment addresses.
Finally, this patch fixes a kernel panic with large buffer
cache: kernel panic with a data page fault when attempting
to copy data from the last page of the third quadrant.
This will only occur on systems with a buffer cache of one
gigabyte or larger. The panic message will display the
following: isr.ior = 0.bffffffc
running strings on a raw sar(1) output file can show some
printable strings (sar ignores these).
PHKL_8999:
Without this patch customers are limited to supporting
2 nodes in a shared environment
With this patch customers can now use SLVM in a 4 node
cluster
Alternate links for devices such as the Nike disk
array are now supported in a shared environment
This change supports a new -t switch for lvchange allowing
the administrator the option to limit the time lvm holds
i/os to be retried on logical volumes when disks are
powerfailed.
Without using this option, LVM will hold the i/os as long
as there is is one disk where the data resides which may
eventually return. Using this option would cause LVM to
give up on the powerfailed disk and return i/o errors to
the user application using the logical volume. This
feature is obviously not to be used indiscriminately.
For many High Availability applications, having i/os
held in kernel indefinitely is not acceptable.
Most customers should not need to use the new switch.
PHKL_8953:
The K400 4-way suddenly stopped to work. The user heavily
accessed vxfs snapshot filesystem and have done sync's in
parallel. We TOC'ed the system.
PHKL_8716:
After call to pstat_getmsg(), all accesses to the message
queue pstat_getmsg() was called hang.
PHKL_8683:
System panic with data page fault on ICS.
PHKL_8532:
System crash dumps are corrupt and unusable.
PHKL_8481:
JFS performance in 10.20 has improved disk i/o throughput
at the cost of extra CPU utilization. This patch improves
JFS performance by implementing a log buffer re-use scheme
and also by making modifications to the read/write sleep
lock primitives.
PHKL_8346:
Executables cannot access more than 1.75 GB shared memory
PHKL_8331:
Data loss with UFS files using fragments.
PHKL_8294:
When multiple nfsd's access the same file simultaneously,
they hang in a deadlock.
PHKL_8203:
MP system hangs during panic. The LED shows system staying
at INIT CB0B. Machine needs to be TOC'ed to save the core
dump.
PHKL_8084:
LVM may return I/O's with errors instead of sending them to
an alternate link. This patch also facilitates using
"vgreduce -f" for physical volumes which have alternate
links; without this patch "vgreduce -f" is not allowed on
LVM disks with alternate links.
PHKL_7951:
Ptrace not allowing writes on PCUX to some f.p regs
PHKL_7899:
KI queuedone, enqueue and queuestart traces on JFS may
contain NULL values in the b_apid and b_upid fields.
With a system running a heavy load using JFS on LVM, the
following panic may occur: "lv_syncx: returning error: 5"
Systems running JFS may hang due to a deadlock problem.
The setuid bit will be removed on a JFS file when the file
is edited or text has been appended to it when run as root.
PHKL_7870:
lvreduce(1M) may cause a system panic, if it is used to
reduce an lvol which was left inconsistent by a prior
LVM operation. lvreduce(1M) could not be used to remove
lvols that were somehow corrupted, if it was, the command
would cause a system panic.
PHKL_7776:
It's possible for a JFS file system to get into a state
where it can't be mounted (except read-only), but fsck(1M)
does not report any problem with it.
At mount time, the kernel prints the following warning on
the console:
vxfs: mesg 012: vx_iget - <null> file system invalid
inode number XXX
and mount(1M) fails with the following message:
vxfs mount: /dev/XXX is not a vxfs file system.
Once a file system has gotten into this state, it remains
unmountable, even after running fsck(1M).
Defect Description:
PHKL_14803:
SR: 5003407601 DTS: JAGaa02119
The reboot process is stuck at biowait() while sync'ing
disks because of a failure in acquiring LVM physical
buffer. The lv_reschedule() routine needs to ensure
a successful retry in this case because there is no
other process to trigger the emptying of physical buffer
wait queue during reboot.
SR: 5003407619 DTS: JAGaa01516
When buffer cache allocation reaches the defined maximum,
the allocation of new buffers from system memory stops.
When buffers are freed, their physical memory spaces,
instead of being returned to the system, are saved in
a pool to be reused for new buffers. A bug in the
getnewbuf() routine disallows the reclaiming of this
available memory when bufpages reaches the ceiling.
Further more, another bug in the routine that frees up
space for the buffer cache resource map erroneously
releases more buffers than necessary. The prohibition
of reusing the memory from the reserved pool and the
lost of free buffers result running out of buffers in
the freelist, causing all I/O processes hung in sleep
wait.
PHKL_14740:
Device resets on Fibre Channel devices can overlap and
interfere with subsequent volume group activation.
PHKL_14685:
The master file had to be changed to point to libhp-ux.a
instead of libflkmgr.a.
PHKL_14568:
- SR:1653254987 DTS:JAGaa01797
The problem is an MP race condition caused by a defect in
the routine lv_tbl_reimage_realloc().It is freeing the
lv_bitmap before pausing the logical volume.This results
in I/Os possibly reaching scheduling routines (such as
lv_parallel()) while lv_tbl_reimage_realloc() is in
the middle of freeing the lv_bitmap.
The fix is to call lv_pause() before calling KFREE() on
lv_bitmap
- SR:4701379347 DTS:DSDe441470
Add flock manager driver functionality to the kernel.
- SR:1653216952 DTS:DSDe437110
The data path in the kernel code that supports sleep(3C) is
not wide enough to support parameter values larger than
21474836 seconds. If a larger value is passed, incorrect
arithmetic is performed, with results varying from immediate
return (with or without error) to sleeping for the wrong
length of time.
PHKL_14613:
This system hang is hard to reproduce. Once in a while,
during heavy load on UFS file systems if a logical volume
is being created or extended, the UFS code deadlocks
due to ordering problems in acquiring the inode lock and
the device vnode lock.
PHKL_11316:
Classic "thundering herd" problem was made worse by the
fact that the first thing each woken process did was to
try to lock a "COMMON" spinlock. A process that gets
the spinlock first, locks the INODE and releases the
spinlock has to try hard to be able to get the spinlock
second time while it tries to unlock the same inode.
Hence the inode was locked whilst no useful work was
being done.
PHKL_14490:
-SR: 4701382564, DTS: DSDe441726
If the free kernel sysmap space, as a percentage of 1GB,
falls below the threshold value indicated by the variable
kern_vm_pct, now a warning message is printed to indicate
this. The variable kern_vm_scan_rate, in seconds, is used
to set the frequency this check is performed. The variables
kern_vm_pct and kern_vm_scan_rate are tunables that can be
set in the /stand/system file.
Reproduce: Run an application that uses up lot of
kernel sysmap space, or run a defective kernel module
that uses up kernel sysmap space continuously without
releasing the allocated space.
-SR: 1653251934 DTS: JAGaa01592
An Uniprocessor system hangs when heavy I/O is
performed. When the buffer cache virtual space
is heavily fragmented and we are doing a readahead,
system hangs. The allocbuf1() won't do a
bcfeeding_frenzy() to de-frag because readahead sets
BX_NONBLOCK|BX_NOBUFWAIT flags. Instead it returns an
error to ogetblk(). A bug there keeps us looping
instead of returning to the original caller.
Reproduce: On a UP K-series system with 64Mb,
create a 400 Mb VxFS file system mounted at
/new_fs. Make sure that /usr is also of type
VxFS type. The following code will produce
the hang.
while true
do
rm -rf /new_fs/*
cp -r /usr/* /new_fs
done &
while true
do
date
sleep 10
done &
The system will hang in about 15 minutes.
- SR: 1653252544 DTS: DSDe441877
In the routine csuperpage_lock() if an attempt to acquire
pfdat lock on every pfd in the superpage of which the input
page frame number is a part of fails, then in some cases
the lock on the original input page frame number will not
be released thereby resulting in any process that
subsequently tries accquiring the same pfdat lock on the
same page frame to hang.
Reproduction: difficult to reproduce the failure case.
Requires execution of large number of user applications
that subject the system to a high stress load.
PHKL_14323:
mkboot -p uses the block device. Because block devices use
the buffer cache, the label may be overwritten with
incorrect label information once the buffer cache is
sync'ed. The solution involved removing use of buffer cache
by block devices until a mkboot patch is available.
PHKL_14321:
-SR: 1653235176, DTS: JAGaa01482
Both the problems (panics) discussed earlier occur in a
multiprocessor system when two processes are doing
map/munmap on portions of the same file using a
sliding window.
Panic-1
--------
The panic is caused by a race condition in hdl_mmf_attach()
in hdl_policy.c in the machine directory.
The race condition is in case-3 of "overlapping" pregions.
In this case, the new process' pregion starts within
and extends past the existing process pregion.
In the original implementation,we were releasing the region
lock to call mapvnode(). At that time, the new pregion is
not yet placed on the region's pregion-list and hence opens
a window for a race condition.
With the fix, the pregion is placed on the region's
pregion-list before releasing the region lock, thereby
eliminating the race condition.
Panic-2
--------
The second panic is caused by a race condition in the error
path of smmap() in vm_map.c in the sys directory.
In a code segment following the label "bad", in the case
where vnode is associated with the region, we release the
region lock to be able to call dectext(), we copy the file
descriptor from the vas, acquire the file-table lock and
then check that the file descriptor is not zero before
proceeding further. In the meantime, the file descriptor
could have been closed and hence dereferencing it would
cause a data page fault.
To avoid this race condition, we need to postpone calling
dectext(), which is what the fix does.
-SR #4701383612 maps to DTS #DSDe441827
The problem is due to the space register not being set
before jumping to the code that handles ulbcopies to
I/O space. The fix is to move one line of assembler
up above the check to see if this is a ulbcopy to
I/O space.
PHKL_14225:
When disallowing user write permission for copy-on-write,
an execution permission is added to every translation. For
pages which do not have execution right before, this misses
the R/W to execute promotion through fault and the proper
cache flushing.
PHKL_14183:
New functionality to support networking features in 10.20.
PHKL_14126:
This patch fixes two defects :
- SR: 4701381608, DTS: DSDe441567
Patch PHKL_13684 introduced a problem with procedure
vn_open(). By adding one extra argument to this procedure,
compatibility with older users of vn_open (now believed
to be limited to Netware) was broken. Because of this
extra argument it is possible that the vnode returned
by this procedure can be a random memory location.
This patch backs out the addition of the extra argument
and it restores compatibility.
- SR: 1653223404, DTS: DSDe438306
Trap panic in lv_init_immediate_reporting at 10.20 because
currentPhysicalLink field in the struct pvol associated
with the PV which the vgcfgrestore had been performed on
was NULL. The problem will only be seen on 10.20 with
patch PHKL_8999 or superseding patches as this patch
introduced this new pointer field to the struct pvol.
The panic problem will only be seen on multi-PV VGs.
PHKL_14049:
This patch fixes three defects:
1) SR: 1653247486, DTS: JAGaa01357
After a maintenance mode reboot, if the root LV is mirrored,
we make the copy of root on the boot device the only fresh
copy. Before updating the VGSA with the new stale/fresh
information, a structure used to pass physical extent info
to the configuration is set up. In the case of a LV
containing 2**n extents, memory allocated for the array of
structures is exactly enough for the extents. The terminator
of the array was written beyond the allocated memory.
This corrupts the memory at the next address and causes
system to panic when the next piece of memory is accessed.
2) SR: 1653239137, DTS: JAGaa01378
When the root VG has a mirror PV missing with a lower PV
index number than the boot disc, the PV's current physical
link field is zero. The code attempts to dereference this
null pointer in the bootup path and traps.
3) SR: 1653248690, DTS: JAGaa01378
The problem is caused by a disc with bad blocks in the
LVM structure area. This results the logical volume field
in the physical request buffer to be zero. Deferencing this
null pointer causes data page fault.
PHKL_14012:
This is an enhancement to add the flock manager driver hooks
to the kernel.
PHKL_14009:
pstat_lvinfo() algorithm describes that if the number of
entries requested is non-zero, it will traverse through
all the Volume Groups (VG) to report the open logical
volume information. The test (lvix >= vgp->num_lvols) is
used to test if LV index is covered by VG. This should be
(lvix > cur_lvs) which is lvix compared to the number of
open logical volumes. Also there can be some volumes
that are configured but not mounted.(the VG where they
reside is still ACTIVE). The fix now shows the all the
logical volumes that are open in the system (within
any Volume Group). The defect can be reproduced by
writing a program based on pstat_getlvinfo() to display
information about Logical Volumes configured on a
system. The output of this program only shows logical
volumes for the first volume group.
PHKL_13911:
Essentially, in getnewbuf, we might set a B_DELWRI buffer
to B_BUSY, but later decide to NOT write it out (in fixing
some deadlock problem). Rather, we will simply brelse it.
If an umount process of the device or filesystem comes in
between the time of setting B_BUSY and brelse(), it will
skip the buffer thinking that someone else is flushing
it out. Later when it calls binval() assuming all buffers
should have been written out, it may invalidate a dirty
buffer.
PHKL_13874:
There were two defects fixed by this patch:
a) Report of "Invalid Argument":
The problem occurs when reorganizing a version 2 JFS with
EXT4 type of extents from an original indirect extent to
a reorg'ed indirect extent. In this case, vx_reorg_emap()
does not allocate a fixed size extent for the reorg'ed
inode's indirect data extent. The incorrect size causes
vx_enter_ext4() fail to enter the allocated extent to
the extent map, resulting an EINVAL error.
b) Report of "No such device or address"
This was caused also by incorrectly handling the indirect
extent of an IORG_EXT4 type of file (alson created under
version 2). In this case vx_reorg_copy() would blindly
attempt to copy pad bytes if the indirect extent of the
original file was not completely filled. (Pad bytes are
used in the last indirect extent if the data does not fit
exactly)(This is a consequence of having a fixed size for
all indirect extents of the IORG_EXT4 type of file).
PHKL_13795:
New functionality to support networking features in 10.20
PHKL_13768:
On PA8000 systems, when free physical memory becomes heavily
fragmented, the time needed to find free large pages
(superpages) increases drastically. During this time
(possibly several seconds) the kernel would preempt any user
or system processes. This could result in MC/Service Guard
TOC'ing the system. The fix was to yield the cpu when
spending too much time in alloc_large_page().
PHKL_13761:
Use of a global mprot_list_lock lock caused spinlock
contention as its one lock per system and hence poor
system performance. It is still used to protect
mprot_list. The fix was to use another pool of locks
called prp_hash_locks for protection ids. The hashing
function chooses different locks (from this pool of hash
locks) for different range of addresses thus removing
dependency on the various locks that should be acquired
before the protection ids for a given page are changed.
PHKL_13713:
The defect was due to an uninitialized field (ex_elen) in
the vx_extent structure when allocated by the vx_dqnewid
procedure.
PHKL_13684:
The system supplies a "default" ACL even if none has been
configured. This in turn overrides any umask, and produces
unexpected file access behaviors.
PHKL_13680:
In 10.xx buffer caching was disabled for block devices. This
produced degraded performance in reads/writes to block
devices.
PHKL_13508:
vx_statvfs doesn't count extents smaller than 8k for
f_bavail.
PHKL_13452:
When changing multiple attributes on a file, VxFS (JFS)
code creates a "ghost" inode, or working copy to make
changes. When the changes are complete the ghost inode
is swapped into the real inode, thus making the changes
visible in the file system.
Some parts of the "ghost" inode may not be set by the
time other parts of the VxFS code try to use them.
These uninitialized parts of the "ghost" inode cause a
data page fault and panic when they are referenced before
they are initialized.
When only one attribute is changed, no "ghost" inode is
created. Changes are made directly to the inode involved.
PHKL_13305:
The defect is that the scheduling algorithm in idle() was
preventing the reboot processor from picking up the thread
that needed to complete processing because that thread was
locked to another processor.
PHKL_13260:
This patch fixes three problems:
a) SR: 1653237842, DTS: JAGaa01160
Poor performance on PA2.0 machines due to protection id
fault that is resolved in software instead of hardware.
The system resolves half of the protection id faults in
software and hald in hardware. The fix was to use the
hardware support from PA2.0 chip so that we will resolve
greater number of protection id faults in hardware than
in software. PA2.0 systems have 4 64-bit protection id
registers instead of 4 32-bit registers. By software
convention, the lower 32-bits of cr8 and cr9 are used for
text and data protection id's. This way we never have to
resolve protection id faults for text and data segments
via software. The higher order 32-bits of cr8 and cr9 are
used to cache protection id's. In addition to that we have
another 4 registers (2 32-bit register pairs) i.e cr12
and cr13 for caching protection id's. This way, we now have
6 control registers to cache protection id's instead of 2.
This results in performance boost and less number of
protection id faults to be handled by software. Here's a
pictorial explanation of the difference in PA1.1 and PA2.0
control registers:
PA1.1:
Protection id cache registers = 2 (32-bit)
0 31
--------------------
| TEXT |- CR8
| |
--------------------
| DATA |- CR9
| |
--------------------
| pid3 |- CR12
| |
--------------------
| pid4 |- CR13
| |
--------------------
PA2.0:
Protection id cache registers = 6 (32-bit)
0 31 63
----------------------------------------
| TEXT | pid2 |-CR8
| | |
----------------------------------------
| DATA | pid4 |-CR9
| | |
----------------------------------------
| pid5 | pid6 |-CR12
| | |
----------------------------------------
| pid7 | pid8 |-CR13
| | |
----------------------------------------
Hence, the 10.20 HP-UX code was using only
pid5 and pid7 for caching protection id's
whereas pid2, pid4, pid6 and pid8 were not
used.
b) SR: 1653237842, DTS: JAGaa01160
The other defect which leads to silent data corruption
was due to a patch PHKL_13624 which "incorrectly" uses
stack pointer to get space id for the key to access
fast protection id list. This is true for all the
applications "except" for SHMEM_MAGIC applications who
define their own stack on the shared memory segment.
The fix for PA1.1 and PA2.0 systems (for PHKL_12634) was
to find out which key to use for accessing the fast
protection id list. Non SHMEM_MAGIC applications will
always have a non-zero value in sr5 and this value cannot
be equal to the value in q2_spaceid.
The reason that non SHMEM_MAGIC applications will always
have a non-zero sr5 is that they attach a stack region in
the second quadrant before they begin execution. So we now
have a simple test that can be used by fast_resolvepid:
if (sr5 == 0 || sr5 == q2_spaceid) {
/* Application is SHMEM_MAGIC, compare sid to sr4 */
}
else {
/*Applications is non SHMEM_MAGIC, compare sid to sr5 */
}
q2_spaceid is covered by the kernel mapping so we know it
is mapped equivalently. q2_spaceid is a global which is
initialised at boot time and holds the space id that
SHMEM_MAGIC applications share for the second quadrant
(controlled by sr5).This global will be zero until the
first SHMEM_MAGIC application attaches something in the
second quadrant, but that doesn't matter. Anyway, all
SHMEM_MAGIC applications will have sr5 set to either 0 or
the value in q2_spaceid. It will be zero if the application
hasn't gotten around to attaching any shared memory in the
second quadrant, otherwise sr5 will contain the value in
q2_spaceid. This fix will work for PA1.1 and PA2.0 systems.
c) SR: 4701373969, DTS: DSDe440766
The driver for VISUALIZE-FX hardware uses PA-RISC
protection id's to arbitrate access to the hardware.
Flow control for the graphics pipeline by revoking
the graphics protection id under interrupt. Some
routines that manipulate protection ids in the kernel
were not protected from this interrupt, so they could
wind up restoring the graphics protection id from a
temporary variable after it was revoked, leading to
either the graphics pipeline being overflowed, or two
graphics processes simultaneously accessing the hardware.
PHKL_13247:
DDTS #JAGaa00964 : When "vgchange -a s" is invoked to
PV-LINK volume group of Nike, which has the mixing of GSC
and HP-PB interfaces on shared bus, on both nodes at the
same time, vgchange fails, leaving the following error;
vgchange: Couldn't activate volume group "vg02": I/O error
while reading the VGDA. Reproduction : Set up two systems
with 10.20 OS, NIKE disk array on a shared bus, DLM
software, and start up the cluster. Then use some mechanism
to invoke the vgchange -a s command simultaneously on both
nodes. This could be done using synchronized clocks and
timed jobs. After some time the command will fail on one of
the nodes.
DSDe441112 : The configuration is two T600's, shared EMC
disk arrays on fiber channel, HPUX 10.20, ServiceGuard
10.10, in a new installation. They are testing ServiceGuard
by introducing various faults. Most work ok, and
ServiceGuard responds as designed.
Certain manipulations are done on one node, and the other
node panics. Manipulations leading to the panic include:
1. Powering off the node. 2. Disconnecting both fiber
channel cables (disconnecting only one is ok). 3. Powering
off an expansion bay.
PHKL_13237:
serialize() is checking if the "pid" argument passed to the
system call from the user application is less than
PID_MAXSYS. If so, the call fails with errno set to EINVAL.
PHKL_13206:
getdirentries() and getdents() system calls did not check if
the argument is a directory file. When it is called on
VxFS(JFS)file systems with a regular file, VxFS reports an
error such as "vxfs: mesg 008:..." and the clean file can
be marked bad. VNODE type check codes have been added in
getdirentries() and getdents().
PHKL_13155:
The scheduler decides the system is thrashing in some
occations when pageout rate is low and free memory is
plenty and hence deactivates certain processes.
PHKL_12997:
The HSC F/W SCSI card was not being identified as an
interface capable of addressing in the 2GB->4GB range. To
reproduce, simply attach a >2GB disk to an HSC F/W SCSI
interface and put a >2GB file system on the device. Leave
enough room at the end of the disk for dump space and
attempt to configure dump on the device to start between
2GB-4GB.
PHKL_12963:
No real defect for 1st problem. Its just that a CPU
intensive process would/could consume more CPU cycles than
the entitlement granted to a group under PRM control.
2nd problem could occur on an SMP machine, if mulitple
processors go after a single process simultaneously. In
some situations, a hang can occur. PRM would need to be
running on the system, and processes would have to be
locked to processor through process affinity. In this
situation, a processor can be fooled into thinking a
process is available to run, when none is, and the result
of this can be a hung system.
PHKL_12901:
The defect is due to allocation of large data structures
(local variables) on stack when a function is called.
The fix was to re-compile the object modules(LVM,JFS) with
a compiler option (+ESssf - small stack frame) to align
the stack pointer to 32-byte boundary instead of 64-byte
boundary. This prevents the kernel stack overflow panic.
PHKL_12669:
1. When a physical volume which has bad block alternates
allocated and is begin added/extended to a volume group
without doing a pvcreate -f. If the bad block alternate
resides inside the user data area, this could cause
data corruption.
2. The problem has to do with how the LVM interprets the
B_PFTIMEOUT flag. For mirrored reads, the LVM works as
desired: if the first disc is bad, the LVM tries the
second disc. If the second disc is also bad, then the
LVM reports a disc error. In the case of PV links
however, the LVM reports a disc error immediately
without trying the alternate link.
3. The new lvol flag (LVM_NONCONTIGUOUS) is defined for a
new allocation policy begin implemented in a LVM
command patch.
PHKL_12662:
A thread owns a resourse needed by the reboot process,
yet is stuck on a frozen spu, causing a deadlock.
PHKL_12633:
Problem was due to an incorrect assumption in determining
the SID to be used. Procedures fast_resolvepid and
fast_resolvepid2_0 incorrectly assumed the SID would reside
in SR5. This has now been corrected providing better
performance of SHMEM_MAGIC executables.
PHKL_12601:
ftruncate() retuns EAGAIN on madatory locking regardless
of lock owner. If we have mandatory locking on a VxFS file
and if there is a pending lock, then we return EAGAIN
regardless of the owner of the lock.
vx_setattr() does not allow a file to be truncated if
there is mandatory file lock owned by another process,
even if it does not overlap the range being truncated.
PHKL_12409:
alarm() rounds the time remaining to the nearest second
so if the time remaining is less than 0.5 seconds, the
result is rounded to zero. This makes it impossible to
reschedule the original alarm.
There was no check made in alarm() to determine if the
result has been rounded to zero. The fix is to have a
check to ensure that we never return zero if there was
any time remaining.
PHKL_12397:
This patch fixes two defects :
-When debugging processes over an interruptable NFS mount
point there is a window during which a traced process could
sleep in exec() while the debugger would exit clearing the
traced bit and freeing the ptrace data structure. Upon
wakeup, the no longer traced process would panic the system
trying to dereference a NULL pointer.
-pstat_msginfo() calls msgconv() to convert the offset into
a message queue pointer. msgconv() then locks the queue and
returns a pointer to the queue's lock. pstat_msginfo() had
not been released the lock of the message queue.
PHKL_12378:
Filenames longer than 14 characters are not put in the path
name lookup cache. Applications using very long filenames
and pathnames will not find their filenames/patchnames
cached. This results in a lot of filesystem block read.
When many processes simultaniously scan many directories
then path name lookup cache and buffer cache spinlock
contention will show up.
The solution was to increase the maximum filename length
that can be cached from 14 to 39 and extend the the spinlock
pool.
In the test configuration using Netscape the message accept
rate increased from 4.5 to 9.2 messages/second and message
delivery rate increased from 3.8 to 5.0 messages/second.
PHKL_12217:
lseek() is not allowed to specify negative offsets. NFS
servers use so called cookies which might have negative
values.
PHKL_12110:
System hangs or panics when signal is received which has
action set to ignore when in nanosleep system call. Libc
patch that changed sleep()'s underlying system call to
nanosleep() makes situation worse.
PHKL_12100:
fsck was not able to handle iau data spread across
multiple extents. The kernel, on the other hand, seems
capabable of multiple extents for iau. fsck was fixed to
agree with kernel with respect to iau.
PHKL_12088:
If a customer installs the HP-UX OmniStorage product on the
10.20 release, the product would not be functional. The
DMAPI extensions available with the OnlineJFS product
(currently only being utilized by OmniStorage and not linked
into the kernel by default), had several severe bugs that
were fixed in the 10.30 release. This patch backports the
DMAPI functionality from 10.30 into 10.20.
PHKL_12073:
The problem was caused by improperly handling the SIGPOLL
signal. The si_code number of the siginfo_t structure
contained CLD_DUMPED and a core file produced. si_code
should have contained CLD_KILLED.
PHKL_12042:
The scheduling policies available prior to this patch did
not have a provision for a fixed-priority timeshare
(non-realtime) process, one which could use many system
resources without being degraded to a very low priority.
This patch provides this "no aging" timeshare facility
for applications which need it. This facility uses
the same interface which is in 11.00, through the POSIX
interface routines: applications which need to use this
facility should use the sched_setscheduler(2) system call
with a new policy of 8 (to be defined in 11.00 as
SCHED_NOAGE).
Idle processors were stealing processes from other run
queues, even when those processes were running frequently
already.
PHKL_11902:
Missing argument inside of diagnostic printf().
PHKL_11860:
It is assumed that there is one active reference to a
disk quota at vx_quotaoff(), which enables to free
vx_dquota blocks in vx_dqlist. This assumption is not
true during vx_replay() since there is still a VX_MLDQUOT
mlink in the file system mlink chain waiting to be flushed.
Hence, flushing the file system's mlink queue before
calling vx_quotaoff will fix the problem.
PHKL_11766:
1. When an alternate link is added to a volume group, LVM
counts this link as an individual disk. This mistake
will cause vgextend to fail when user wants to add an
additional disk to a volume group when the total
number of disks and its alternate links reach the
maximum allowed.
2. LVM panic the system when running one of the stress test.
trap panic in lv_resyncpv due to failure return from
lv_lvhold call.
PHKL_11733:
After a hard system failure, a JFS file system may not mount
even if PHKL_9371 and PHCO_11223 are installed. If the
VX_IETRUNC flag is set for a file, then vx_trunc() is called
and returns without clearing the ip->i_eopflags field. Since
VX_IETRUNC alone is still set after vx_trunc(), the error
return is set to EINVAL (reason why the mount fails). Prior
to returning, if error is non-zero, vxfs sets the
VX_FULLFSCK flag and returns. Patch PHKL_9371 added the
setting of the VX_FULLFSCK flag; the bug leaving the
ip->i_eopflags set to VX_IETRUNC still existed prior to
PHKL_9371, however after the first failed mount, a second
mount would have been successful.
PHKL_11730:
Conditions needed to be re-checked after acquiring lock.
Functions changed: bflush1, bflush_vfs, binval, blkflush,
bpurge, ogetblk and syncip_flush_cache
PHKL_11696:
Backout code in dupvas() does not free the vas. One line
accidentally deleted in 10.20 checkin of multithreaded vas
locking. Seen in 10.30 testing but never reported on
customer installations.
PHKL_11637:
Mount an HFS file system from the CDROM drive then
reboot the system without unmounting the file system.
When the system comes up, the CDROM draw will remain locked.
PHKL_11614:
Defect occurs when the accounting file is physically on
the server and not on the local file system. The function
_acct() was setting the process credentials before doing
a vnode operation (vn_rdwr()), instead of setting the
thread's credentials. The vnode operation that was
performed on a file was instead using thread's
credentials. Because of this users other than ROOT were
unable to update the accounting file and there was no
information regarding commands executed by user in
/var/adm/pacct (accounting) file.
PHKL_11607:
The file system that was being mounted had previously been
under a reorg operation. The panic occurred during replay
on the structural fileset where an inode with the org type
of IORG_TYPED was being truncated. The truncate operation
produced a transaction with over VX_MAXTRAN subfunctions.
vx_trunc_typed() is called to truncate the file to size 0.
This function makes an accounting error in its loop that
frees extents. For each iteration of the loop vxfs only
accounts for one subfunction to add to the transaction
while more than one subfunction can be added.
PHKL_11561:
When a node dies in an HA cluster environment, there may be
IO requests still pending on its intellegent disk IO boards
(eg. Wizard). The IO boards may continue to write
this stale data to disks. This process is known as "Ghost
IO". This situation may lead to data corruption when the
other nodes in the HA cluster detect the failure, apply
recovery logic, and perform IO to the disks. There is a
need for detecting the death of a node and reseting the bus.
This feature only impacts Service Guard/Distributed Lock
Manager environments.
PHKL_11519:
During vnode read operation, if the request is from
NFS, the request size is checked against the VX_MAXBSIZE
and an EINVAL is returned if the request size is greater
than or equal to VX_MAXBSIZE. The EINVAL is always
returned because the request size is set to VX_MAXBSIZE
(8K) for NFS by the calling routine.
When PHKL_11322 fixes this problem, the code proceeds
to read the data block and returns the buffer back
to NFS. This exposes a bug in which if the data we need
starts at a non-zero offset within the buffer and the
caller receives the whole buffer assuming the good data
starts at the beginning, invalid data is loaded and
command coredumps.
PHKL_11471:
The quota command uses quotactl(Q_SYNC, NULL, 0, NULL)
to update the quota usage file on all quota active file
systems. For each VxFS file system, the quota sync
operation flushes all transactions and writes quota
information to the disk file synchronously. On a system
with heavy I/O, this results long delay. The fix is to
flush the transaction log only and use asynchronous I/O
for disk file update.
PHKL_11408:
One of the kernel macros used for locking pfdats was using
the &htbl[] hash list of locks instead of the &htbl2_0[]
hash list of locks, causing it think it had locked a pfdat
when it hadn't.
PHKL_11406:
During the final stages of EXEC, the kernel has to
relocate the argv and envp pointers to point to the
argument and environment strings which reside in the
user stack. There was a defect in this reloction code
that caused all pointers pointing to locations in
the user's stack at offsets of 20K from the base to
have bad addresses.
PHKL_11358:
Problem was due to calling vx_rename (the rename filesystem
specific procedure) for a ufs vnode. This was done because
the parent vnode was of JFS type and it was used to
determine the operation type (JFS or UFS). The problem
should have been detected and avoided at the vfs layer.
PHKL_11339:
CPU limit was not being inherited by the child from the
parent and hence if cpulimit is set, child ignores it.
Also SIGXCPU is not delivered solely depending on the
sigmask, but is triggered by arming the timer. When
a child is forked, kt->sigmask is copied from parent
to the child but if there is a non infinite cpu limit
set in the parent, not only does that field needs to
be copied to the child process, the timer for the
cpulimit must also be armed for the child.
PHKL_11321:
1) In vx_read1(), some unnecessary conditions prevented
vx_read_ahead() from being called for large reads. The fix
is to remove these extra checkings to allow read_ahead to
be performed.
2) When we are done with a shared library, pageout
routine is called to flush the changes to disk. The
way vx_pageout() works is that it invalidates the
cached copy of the file then calls vx_do_pageout()
to figure out the MMF pages need to be written and
write them. A more efficient way of doing this is to
invalidate and flush buffers in the buffer cache only
if there are and may have been dirty pages.
3) When reading a sparse portion of a file on JFS,
vx_read1() calls uiomove() to copy a page of zeroes to the
target buffer. If the UIOSEG_PAGEIN flag is set in the uio
structure, uiomove() by default will copy vx_zeropage from
the buffer cache. Since vx_zeropage is not in the buffer
cache's space, but is in space 0, this references an invalid
address and triggers a panic. The fix is to replace
uiomove() with long_uiomove() which allows the correct
space id to be specified.
PHKL_11247:
An uninitialized variable, depending on what value it picks
up from the stack, causes the quota checking routine to
return EDQUOT erroneously during extent allocation.
PHKL_11244:
mmap() to a file with holes does not work correctly if
MAP_PRIVATE is used.
PHKL_11238:
Random S800 MP system panics when running the latest
Informix because of a corner-case MP hole in nanosleep
which is seen when nanosleep() is called from within
a signal handler.
PHKL_11164:
The variable page size memory allocator was preallocating
kernel virtual space aligned on the largest possible
superpage size instead of the largest available. The excess
was then freed, causing gaps (fragmentation) in the sysmap.
The fix was to allocate kernel virtual space only after the
determination of the largest available superpage size. This
problem would only be seen on PA8000 systems.
PHKL_11085:
On very rare occasions EMC Symmetrix disk drives will
report a disk error which causes LVM to mark the block as
bad in its bad block directory. The Symmetrix drive can
be "repaired" online by EMC support, but the entry in the
LVM bad block directory will prevent any further I/O to
the affected block. This patch enables a new relocation
policy which will prevent entries from being added to
the bad block directory. In order to make use of this
new relocation policy, a commands patch, PHCO_10826
must also be installed.
Also, algorithms within LVM that deal with PVLinks had
built in the assumption that NIKE serial numbers were
unique. This turned out to not be the case. The only
time that the serial numbers need to be unique is in
OPS clusters. This patch removes this restriction
for all non-OPS cluster environments.
PHKL_11055:
Large memory MP systems could hang if the processors
were mallocing kernel dynamic data at the same time.
The contention on the pfdat_lock spinlock would caused
excessive cpu time being burned spinning. This problem
would only be seen on PA8000 (PA2.0) systems.
PHKL_11039:
There was a defect in the routine checking the validity
of extent buffers. This defect would cause inodes to be
marked wrongly as BAD, when they were perfectly valid.
This also fixes a defect that was found while
fixing this problem. The bug is in the routine that
splits the extent. It assumes that the allocated extent
is same as it had requested, which is not always the
case. The defect was that it copied half the entries
from extent being split to the new extent, and it may
be that not all the entries will fix.(if it allocated
less than requested).
PHKL_11013:
During vxupgrade, it is possible for the allocation unit
length to change; thus the same inode located in the same
block will change allocation unit numbers. There was a
check in vx_iremount() to verify that the allocation unit
numbers matched, and returned ENOSPC if not. This was the
root cause of the problem which was easily reproducible:
o Create a version 2 JFS file system on a 1GB volume:
mkfs -Fvxfs -oversion=2 /dev/vg01/onegigvol
o mount it:
mount -Fvxfs /dev/vg01/onegigvol /tmp_mnt
o fill up the file system halfway:
prealloc /tmp_mnt/bigfile 500000000
o copy some files into the filesystem:
cp -r /usr /tmp_mnt &
o wait a few minutes and execute the vxupgrade command:
vxupgrade -n 3 /tmp_mnt
PHKL_11006:
A defect in the implementation of timer reload causes
the 1 tick (10ms) interval be rounded to 2 ticks (20ms).
PHKL_10966:
The exclusion zones were not being properly merged for some
orders of sets if they wound up being adjacent. When at-
tempting to clear the exclusion zones, the clearing code did
not bother to look at the next zone on the list to see if it
was an exact match since adjacent zones should have been
merged.
PHKL_10953:
The bc_yield() buffer cache routine was calling swtch()
without first releasing the file-system alpha semaphore.
This defect would impact mainly systems using a large
buffer cache.
PHKL_10932:
(4701353078/DSDe436182) uiomove accesses memory via
load-byte operations to improve performance on PA-8000
systems. Load-byte is not a valid operation for I/O address
space, though most I/O cards handle it without problems.
Some Emerald-class (890, T5x0, T600) memory controllers do
not. We now use load-word for I/O space.
PHKL_10930:
The hang is due to the system taking a floating point
exception as the result of a PDC defect.
PHKL_10821:
An earlier patch, (10177, shown without prefix so as not to
confuse search engines) expanded the actual space available
to execve(), but failed to modify sysconfig() to report the
new maximum. This patch corrects that. There is no change
to module kern_exec.c (home of execve()) other than a
revision roll to ensure its inclusion in this patch.
PHKL_10800:
current system does not keep track of chdir() calls which
alter the current working directory. there is no in kernel
ascii record of the current path just the vnode/inode
which can not be easily converted to the ascii pathname
PHKL_10757:
This patch provides additional enhancements to support new
HP workstations (See "Symptoms" section for more details).
It also contains two bug fixes. One fix is for the MP PDIR
bug. On MP systems the system could crash due to a race
condition where one processor would attempt to read a
translation that was being modified by another processor.
The other fix was for a panic that was introduced by
a previous patch which expanded the argv/envp buffer
from 20480 bytes to 2048000 bytes. pstat_cmd() could get
a data segmentation violation due to a defect which would
keep looking for a null termination beyond one of the
internal buffers, possibly referencing an illegal memory
address.
PHKL_10689:
This patch provide support for logging of errors in memory
management related system calls such as brk/sbrk as well
as handling error cases during stack growth. Errors are
logged on the system console (dmesg) and also in syslog.
The variable mman_elog, which defaults to OFF, is used to
control the logging. This variable can be set through adb
at a customer site to enable error logging.
PHKL_10675:
LVM resyncs are not held off long enough during lvmerge.
If an i/o timeout occurs during reimaging, then a resync is
scheduled. Towards the end of lvmerge, there is a window
in which the resync is allowed to run for a little bit. If
the resync gets started on resyncing a stale extent during
that interval, and the lvmerge is reimaging the same extent,
the panic can occur.
User i/o's can encounter errors during lvmerge, but lvmerge
wasn't taking these errors into account. There is the
potential that extents can be falsely marked fresh during
lvmerge if user i/o's occur, resulting in data corruption
if those extents are read.
During activation (vgchange -a), LVM allocates various
pvol structures. A bit is cleared after a structure
has been freed. 32 bit systems expect this low-order bit
to be zero anyway (aligned addrs), so there is no impact
if the freed memory has not yet been allocated to another
subsystem before the bit is cleared. However, if the memory
has been reallocated during this interval (i.e. on MP
systems), various panics and strange behaviors could occur.
PHKL_10643:
There were two defects in the UFS read-ahead pagein code
causing the system to request more read-ahead pages than the
system maximum limit. Since the number of requested pages
exceeded the allowed maximum, this resulted in overflowing
internal arrays, and the system could then panic while using
garbled data.
First, the book-keeping of the variables tracking the "last
read-ahead" and the "expected next fault" was not always
done properly. There was a situation where the "expected
next fault" could end up exceeding the "last read-ahead",
and this resulted in a read-ahead count greater than the
system maximum limit.
Second, there was a corner case code path using the "last
read-ahead" variable before it had been initialized.
PHKL_10554:
PA-8000 systems with patch PHKL_9151 applied could
experience an HPMC if the following were true: an external
interrupt occurred while on the gateway page and the IIR in
the save-state happened to contain a comb* instruction.
Applying this fix will not only prevent this kind of
failure, but should also boost performance on PA-8000
systems.
PHKL_10452:
Defect is quite rare. Kernel stack overflow may result from
other causes. This fix reduces frame size of lv_end() from
over 600 bytes to under 200 bytes.
PHKL_10316:
If ptrace() is single stepping an user signal handler and
handling a sigcleanup call, and another signal is handled
during the return of this system call, the user's PC is
overwritten by the single step breakpoint address before
returning to the user. One way to reproduce the problem is
to use DDE on a program that generates a lot of signals.
Signal stepping through the program will eventually cause
an internal I/O error.
PHKL_10288:
A buffer arrives in bwrite() with B_ASYNC/B_DELWRI
and B_INVAL on and bp-vp == 0 (buffer disowned). On
attempting to complete the write, VOP_STRATEGY
resolution results in a trap 15 due to null vp.
PHKL_10257:
The problem fixed was a wrong assumption in add_text which
expects the fstore to be the same as the bstore. Because
of this assumption the original (and correct) bstore gets
trashed when it is overwritten with the fstore after a
call to duplicate a region.
For an NFS executale with the sticky bit set, the fstore
will NOT be the same as the bstore. We know have removed
this assumption.
PHKL_10234:
Running an EXEC_MAGIC program using a stack pointer in
the first quadrant could result in a panic: kernel scheduler
interrupt. This problem would only be seen on UP systems.
PHKL_10199:
The bug is in the allocation and freeing of entire
allocation units on file systems larger than 64Gb in JFS
version 3. When calculating the buddy allocation unit to
allocate and free, the code fails to add back in the map
section that it subtracts out earlier, causing the summary
of the wrong AU to be updated. The incorrect values in
AU summaries and all higher level summaries lead to the
allocation failure.
PHKL_10176:
The internal buffer within the kernel was created with
a length of 20480 bytes, with no provision for increasing
its size. This patch provides for up to 100 such buffers,
with all but the first allocated only if required (that
is, if more than 20480 bytes of argv/env information is
found). Thus, exec() now supports up to 2048000 bytes of
argv/env information.
PHKL_10064:
Negative time values for file modtimes are not defined in
standards. Release 10.0 opted to make such values invalid.
Unfortunately, some vendors were using negative times as
flags rather than timestamps, and disallowing such values
broke the application.
The fix was to allow negative timestamps again.
PHKL_9931:
Currently, biodone() sets B_DONE and drops the spinlock for
the buffer before making a callback to an I/O completion
routine, if one has been set up. This means that biowait()
can return while the callback is in progress, and the buffer
might be released. The solution is to always set B_DONE in
finish_biodone() instead of biodone().
PHKL_9919:
Upon synchronization, non-monarch's expect the monarch to
be waiting for them to synchronize. If the monarch is not
waiting, the synchronization fails, and the
offset_correction is set to 0. This happens only on bootup
and may not happen every time. This causes times in the
KI buffers to vary greatly, and that causes the MI Daemon
to crash frequently. The problem is only at boot time, and
will not occur later. This means a succesful boot will
keep stay good, and a bad boot will stay bad.
PHKL_9909:
A deadlock resulted from a process running lvmerge on HFS
logical volumes, and another process running umount on a
JFS logical volume. The umount process grabs the JFS
update sleep lock (used to serialize JFS syncs/mounts/
umounts), calls spec_close to close the device we are
unmounting, and eventually gets to a LVM close routine
which is sleeping waiting to acquire the LVM volume-group
lock. The lvmerge process is holding the LVM volume-group
lock and proceeds to call freeze_and_sync_fs_dev() to
freeze and sync the file system associated with the
device. The routine ufs_freeze() is first called which in
turn calls walk_and_freeze_fs() without a pointer to a
vfs structure. This proves faulty since update() is
now called without a vfsp and will proceed to try and sync
every mounted file system instead of just the file system
being frozen. So we proceeded to try and sync a JFS file
system which first tries to grab the JFS update sleep
lock, and a deadlock occurs. This problem can be
reproduced by having one process running a lvsplit or
lvmerge on a HFS logical volume, and another process
running a mount, umount or sync on a JFS logical volume.
The fix for this problem is to pass the vfsp to
walk_and_freeze_fs() from ufs_freeze() instead of the
do_sync argument. The routine walk_and_freeze_fs()
now uses vfsp when it calls update().
PHKL_9711:
VxFS quota routine vx_getquota() resets the time limit for
root because it thinks root should not have a quota limit.
Somehow it ignores the fact that the timelimit fields in
root's dqblk structure are used to store the file system
time limit.
PHKL_9569:
This patch fixes two different VxFS (JFS) defects:
- A snapshot could not be mounted if a process was waiting
arbitrarily long for a file record lock. An application
using lockf() or fcntl() to get file record locks, and
holding the locks for a long period of time, could prevent
from mounting a file-system snapshot.
- The VxFS rmdir(2) routine could run into a deadlock
situation where the directory would be kept locked.
Processes attempting to access the locked directory would
then wait forever, and eventually this could cause the
entire system to hang.
PHKL_9529:
The lv_queryvg() function in ioctl(2) failed to copy
the maxpxs field to the returning data structure.
This problem was introduced in PHKL_8999.
PHKL_9517:
The problem can be reproduced by executing the following:
- create a version 2 VxFS fs the same size as /usr
- fragment the fs (ie. fill up the fs with 8k files, and
then remove every other one. Proceed to remove
groups of files until enough space is available
to copy /usr over
- cpio /usr to new fs, and run upgrade fs to version 3
- change /etc/fstab to use new volname for /usr, and reboot
- start up /usr applications like sam, vi, swinstall, etc.
- run several scripts to do things like add/delete small
files, and ``ls'' commands in /usr
- with ``busy'' filesystem, run "fsadm -Fvxfs -e /usr"
The problem was that the resulting geometry was not being
taken into account in vx_reorg_copy() if the reorg range
was broken up due to lack of free extents of the requested
size. The amount of data to be copied cannot be greater
than the minimum of the two extent sizes returned by the
bmap calls.
PHKL_9372:
Resizing VxFS filesystems online effectively does quick
unmounts and remounts of the filesystem, switching quickly
between the two different data areas containing the
filesystem structure information. The VxFS disk quota
tracking structures were not updated during the switch, with
the end result that the disk quota code was accessing
invalid memory. The fix was to update the disk quota
structures during the switch.
PHKL_9370:
The inode summary fields in the new allocation unit added by
extendfs were not properly initialized, so whatever happened
to be in the block wound up being treated as inode summary
data. The vxfs fsck command never detected this, and the
mount command was failing in the kernel due to a file system
validation error. The problem is easily reproduced by
executing the following:
# lvcreate -L 40 -n testvol /dev/vg00
# mkfs -Fvxfs -oversion=2 /dev/vg00/rtestvol
# mount -Fvxfs /dev/vg00/testvol /tmp_mnt
# umount /tmp_mnt
# lvextend -L 80 /dev/vg00/testvol
# extendfs -Fvxfs /dev/vg00/rtestvol
# mount -Fvxfs /dev/vg00/testvol /tmp_mnt
PHKL_9365:
A defect in the kernel causes some processor data cache
lines not to be flushed to memory prior to I/O operations.
This can cause stale data to corrupt the user or system
data. This defect only affects PA-8000-based systems
(supported with HP-UX 10.20 and later releases). All
systems based on earlier SPUs (PA-7200, PA-7100, PA-7150,
for example) are not affected. This problem is rare;
so far it has not been detected on customer systems,
only within HP. However, all customers with PA-8000
systems are advised to apply the appropriate patch.
PHKL_9361:
binvalfree_vfs() has a race window where while one process
is checking to see if a vnode buffer can be freed, another
process dereferences the vnode pointer from the same buffer.
The fix is to use a local variable to avoid the MP race.
PHKL_9273:
The file locking code is protected by a single semaphore
(the filesys sema). As the semaphore becomes heavily
utilized, starvation prevention code activates which
leads to excessive spinning and switching.
PHKL_9153:
Added code to update the v_last_fsync field on the vnode.
This field will be used by rfs_write to implement write
gathering on nfs servers. Patch PHKL_9155/56, which updates
rfs_write(), must also be applied for this patch to be
effective. If both patches are applied, server throughput
should increase for write-intensive workloads, and I/O
traffic to disk should decrease.
PHKL_9151:
The changes are designed to improve locality of reference
within the kernel, thus improving the i-cache
hit rate. The "flipper" tool will reduce mis-predicted
branches. All will improve the processor efficiency, or
CPI rate, when executing kernel code.
PHKL_9075:
This patch provides two enhancements to Memory Mapped Files:
increased performance when using thousands of mappings, and
mprotect(2) opened to non-mmap(2) addresses. It also
provides a fix for a defect with large buffer cache.
The pregions list associated to a shared region was designed
as a doubly-linked list thus providing a linear access to
pregions in the list. This design was not suited to deal
with thousands of pregions and the doubly-linked list was
replaced by a skip-list for faster access. Two other changes
were required to deliver better performance: the algorithm
to check the total virtual address space and the routine to
locate the stack pregion were enhanced.
Only those addresses returned from a call to mmap(2) could
be used for mprotect(2). However there were applications who
needed to protect addresses in data, stack or shared memory
segments; objects not created via call to mmap(2).
So mprotect(2) was opened to allow mprotect'ing on data,
stack and shared memory objects. Text is not allowed unless
the executable is EXEC_MAGIC.
A compiler feature with C language structure copies results
in a reference to an untranslated address when copying the
last 4 bytes in quadrant 3. This only shows up when the data
in the buffer that is being copied includes address
0xbffffffc that is, it is the last full word in quadrant 3.
The problem appears as a trap type 15: "data page fault".
pstat_dynamic() allocates a buffer but fails to initialize
it before using it. Buffer ends up containing some garbage.
This is a cosmetic defect only; sar ignores the
uninitialized spaces.
PHKL_8999:
Support for SLVM is currently limited to 2 nodes.
This patch will allow SLVM to work in a 4 node cluster.
Alternate link support has also been added for SLVM
so that devices such as the Nike disk array can
now be used in a high availability cluster.
LVM makes every effort to avoid returning an error to user
applications. LVM will hold onto an I/O to retry it later
if there is even the smallest hope that the device will
return. If a disk simply does not respond and no bad
writes made it to the media, LVM will hang onto the i/o as
long as the disk does not respond with an indication that
there was actually a bad write or read. The patch
provides a new feature that allows administrators
the option of limiting the time lvm will wait for disks
in an logical volume to return, and cause lvm to return
i/os with EIO instead of hanging onto them indefinitely.
PHKL_8953:
The problem is caused by a defect in getnewbuf procedure in
vfs_bio.c file. When Vxfs calls getnewbuf() to acquire a
buffer, it passes BX_NONBLOCK in bxflags to avoid potential
deadlock. However, the getnewbuf() proceeds to call
bwrite() to flush the buffer without checking the bxflags
when it finds a B_DELWRI buffer. This causes Vxfs with
snapshot to hang.
The fix for this defect is to make fix for getnewbuf() in
file vfs_bio.c. When getnewbuf() ends up grabbing a DELWRI
buffer with BX_NONBLOCK, it will release the buffer and
return NULL instead of flushing and returning the buffer.
PHKL_8716:
pstat_msginfo() calls msgconv() to convert the offset into
a message queue pointer. msgconv() was changed to not only
do the conversion, but to lock the queue and return a
pointer to the queue's lock. pstat_msginfo() had not been
changed to take into account msgconv()'s new behavior.
PHKL_8683:
While on the ICS, sysmemunreserve() was deferencing a no
longer valid uarea pointer although its caller kalloc() took
care of specifying "uarea/proc checking." The fix was to
honor the flag passed by the callers.
PHKL_8532:
Intermittent corrupted dumps on PA-RISC2.0 (PA8000) machines
on HP-UX 10.20.
PHKL_8481:
JFS extra CPU utilization may cause system performance
problems on some configurations.
PHKL_8346:
Current executable types cannot access more than 1.75 GB
of shared memory. A new executable type is defined which
uses the second quadrant of the address space for shared
memory rather than process private data thus resulting in
2.75 GB of shared memory.
With short pointer addressing on 32-bit PA architecture,
each pointer addresses one of four quadrants each of which
is 1 GB in size. Current executable types use quadrant 3
and quadrant 4 for shared memory. In user mode, quadrant 1
and quadrant 2 are used for user text and data,
respectively. This results in a system wide maximum of
1.75 GB of shared memory (.25 GB in quadrant 4 is set
aside for IO).
In the new executable type, user data and stack are pushed
into quadrant 1 and quad 2 is also used for shared memory.
An existing application has to be relinked as the new
executable type to avail of this feature. Alternately
the application can be linked as an EXEC_MAGIC and
the n the executable can be chatr'd to be the new
executable type (SHMEM_MAGIC). The related patch for
chatr is PHSS_8358. Only the chatr method is currently
supported.
Please note that this is an interim solution for
increased shared memory addressing till 64-bit hp-ux
becomes available. There are several limitations:
- Only executables that are linked to be the
new SHMEM_MAGIC executable type(or chatrd to
be so) can avail of this feature. Other
executables will continue to see a system wide
maximum of 1.75 GB of shared memory. Processes
that execute other types of executables will
not be able to share the memory in quadrant 2
with a process that is executing the new
executable type.
- In the new SHMEM_MAGIC type, quadrant 2 is
only used for system V shared memory (unlike
quadrants 3 and 4 which are also used for
shared memory mapped files).
- In the new executable type text is mapped
at different virtual addresses and so process
intensive applications may not benefit.
Any increase in performance due to the larger
shared memory may be offset by decreases due
to TLB inefficiency. Applications that use
one process per processor may however benefit.
- This will not be supported on future
HP implementations of 64-bit architectures
(beyond PA 2.0), nor will it need to be as
with a 64-bit kernel the size of shared
memory supported will be much larger than
2.75 GB. Programs that need more than 1.75
GB of shared memory on these architectures
will have to be recompiled for these
architectures.
- Programs that are compiled as 64-bit
executables on any 64-bit HP implementation
(including PA 2.0) cannot be marked as
SHMEM_MAGIC nor do they need to be as they
will already have access to more than 1.75
GB of shared memory.
PHKL_8331:
There was a code path where dirty buffers could possibly
be dropped (not flushed) when extending UFS files using
fragments.
PHKL_8294:
ufs_bread(), called by nfs server routines, prematurely
unlocks the inode while the caller still owns the buffer.
This opens a window for another process to grab the inode
lock. Deadlock occurs when the process owning the buffer
tries to access the inode again and the process holding
the inode waits for the buffer to be available before
it can release the inode lock.
The fix is to delay the inode unlocking in ufs_bread()
until the inode is no longer needed.
PHKL_8203:
In 10.X, interrupt distribution is implemented to allow
reassignment of interrupt processors to I/O interfaces
for workload balancing. The assigned interrupt processor
for an I/O interface may or may not be the system monarch
depending on the the number of I/O cards and processors
available.
During a panic, if the panic processor is the system
monarch, it will flush the buffer cache on its way down.
If the interrupt of the disk it is syncing is serviced by
one of the other processor(s), the I/O completion interrupt
will not be received and the ISR will not be called
because the other processor(s) are TOC'ed at this point.
Without the ISR to signal biodone(), the biowait() sleeps
forever.
The fix is to add a timeout in the panic_boot path to break
out from the hang in disk sync'ing and continue with the
reboot.
PHKL_8084:
Without this patch LVM will not retry failed i/os on
alternate links unless the error is one that denotes that
the device is offline or powerfailed. Other errors,
are not retried on an alternate link and may cause LVM to
report the error to users applications. Typically,
customers with unmirrored lvols using multiported devices
like the HP3232 (Nike) disk array would see the problem
when an EIO error is reported to LVM from the underlying
device driver due to a device or driver problem. In this
situation LVM would report the EIO to user applications
without trying any available alternate link. Another
problem this patch fixes allows reducing out physical
volumes from a volume group when the device is not
available and the device has links, formerly devices with
links could not be removed if they were not available.
PHKL_7951:
32 bit registers were allowed to be modified after 64 bit
registers have been modified.
PHKL_7899:
KI problem: The JFS buffer allocation and IO paths were not
fully instrumented causing buffer header b_apid and b_upid
fields not to be updated consistently. The resulting KI
queuedone, enqueue, and queuestart traces contain NULL
values in these fields.
A panic can occur with JFS on LVM due to an inode being
able to change identity before it and its dirty pages
are flushed to disk in vx_freeze_iflush().
System can deadlock due to a locking order problem in JFS
when vx_fast_read() is called from VOP_BREAD.
When a JFS file is created with the SETUID flag, the setuid
bit is removed when the file has been edited with vi or text
has been appended to it; this should only be the case when
the writer is not root.
PHKL_7870:
The problem was that the kernel forced a panic whenever any
inconsistency was found during an lvreduce. For example,
if a logical extent in an lvol referred to a physical
extent that was not allocated, it would cause
lvreduce(1M) to panic the system. This occured even when
the objective was to remove the offending lvol.
This is a very rare occurance.
PHKL_7776:
At mount time, the kernel completes any pending "extended
operations" for a JFS file system. (These might include,
for example, removing a file that has no links but couldn't
be removed when the last link went away because some process
had the file open.) We maintain a bitmap on disk with one
bit per inode indicating whether the inode has any extended
operations pending, to avoid having to inspect every single
inode at mount time. However, the calculation of an inode
number from a bit in the bitmap is done incorrectly. This
means, first of all, that some extended operations are never
completed. More seriously, the inode number we calculate
could be out of range, causing the mount to fail. Running
fsck(1M) will not help, since there's nothing wrong with the
file system. Although the file system can't be mounted in
read/write mode, it can be mounted read-only.
If a file system gets into this unmountable state, the only
recourse is to mount it read-only and to copy the files from
it to another (replacement) file system.
SR:
1653096131 1653138164 1653166066 1653166496 1653166983
1653177089 1653179895 1653183699 1653189738 1653192294
1653194555 1653194977 1653199802 1653202754 1653207175
1653211607 1653213082 1653214338 1653215467 1653216077
1653216606 1653216952 1653218065 1653220079 1653221820
1653221895 1653223404 1653227983 1653230771 1653235176
1653237842 1653239137 1653247486 1653248690 1653253229
1653254987 4701327338 4701327544 4701329292 4701329300
4701329433 4701329441 4701330647 4701333419 4701334367
4701334698 4701334847 4701334995 4701335497 4701335935
4701336412 4701339226 4701341362 4701341479 4701341644
4701341669 4701342121 4701342147 4701344515 4701345843
4701346791 4701347922 4701348359 4701349175 4701349431
4701350157 4701350975 4701351932 4701352278 4701352799
4701353078 4701353094 4701353102 4701354274 4701355321
4701355560 4701355610 4701356931 4701358143 4701358523
4701360925 4701361188 4701361444 4701361758 4701364182
4701365114 4701365791 4701371294 4701371617 4701372276
4701374520 4701375956 4701376269 4701376863 4701378117
4701379347 4701380808 4701381608 4701382564 4701383612
5000716225 5003281469 5003314633 5003317487 5003318667
5003323493 5003325506 5003328237 5003330910 5003334961
5003341925 5003344630 5003348425 5003353797 5003356345
5003357616 5003359414 5003360024 5003360446 5003361766
5003363523 5003363820 5003364224 5003365692 5003366500
5003366971 5003367979 5003368290 5003379156 5003380113
5003384586 5003385203 5003385393 5003387019 5003387183
5003397174 5003398800 5003399188 5003407221 5003407601
5003407619
Patch Files:
/usr/conf/h/_flkmgr.h
/usr/conf/h/audit.h
/usr/conf/h/dnlc.h
/usr/conf/h/fss.h
/usr/conf/lib/libdmapi.a(kdm_core.o)
/usr/conf/lib/libdmapi.a(vx_dmattr_table.o)
/usr/conf/lib/libhp-ux.a(asm_rv.o)
/usr/conf/lib/libhp-ux.a(asm_scall.o)
/usr/conf/lib/libhp-ux.a(asm_utl.o)
/usr/conf/lib/libhp-ux.a(asm_vm.o)
/usr/conf/lib/libhp-ux.a(asm_vm_pdir.o)
/usr/conf/lib/libhp-ux.a(audctl.o)
/usr/conf/lib/libhp-ux.a(bcopy.o)
/usr/conf/lib/libhp-ux.a(btlb.o)
/usr/conf/lib/libhp-ux.a(bzero.o)
/usr/conf/lib/libhp-ux.a(clock.o)
/usr/conf/lib/libhp-ux.a(cpd.o)
/usr/conf/lib/libhp-ux.a(dump.o)
/usr/conf/lib/libhp-ux.a(dump_conf.o)
/usr/conf/lib/libhp-ux.a(flipper.o)
/usr/conf/lib/libhp-ux.a(flkmgr.o)
/usr/conf/lib/libhp-ux.a(flkmgr_dom.o)
/usr/conf/lib/libhp-ux.a(flkmgr_flk.o)
/usr/conf/lib/libhp-ux.a(flkmgr_hp.o)
/usr/conf/lib/libhp-ux.a(flkmgr_main.o)
/usr/conf/lib/libhp-ux.a(flkmgr_mm.o)
/usr/conf/lib/libhp-ux.a(flkmgr_pm.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(interrupt.o)
/usr/conf/lib/libhp-ux.a(kern_acct.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_fork.o)
/usr/conf/lib/libhp-ux.a(kern_kload.o)
/usr/conf/lib/libhp-ux.a(kern_mman.o)
/usr/conf/lib/libhp-ux.a(kern_sig.o)
/usr/conf/lib/libhp-ux.a(lbcopy.o)
/usr/conf/lib/libhp-ux.a(lbzero.o)
/usr/conf/lib/libhp-ux.a(lv_config.o)
/usr/conf/lib/libhp-ux.a(lv_lvm.o)
/usr/conf/lib/libhp-ux.a(lw_scall.o)
/usr/conf/lib/libhp-ux.a(machdep.o)
/usr/conf/lib/libhp-ux.a(outlaw.o)
/usr/conf/lib/libhp-ux.a(pgcopy.o)
/usr/conf/lib/libhp-ux.a(pm_clockint.o)
/usr/conf/lib/libhp-ux.a(pm_config.o)
/usr/conf/lib/libhp-ux.a(pm_context.o)
/usr/conf/lib/libhp-ux.a(pm_core.o)
/usr/conf/lib/libhp-ux.a(pm_getpid.o)
/usr/conf/lib/libhp-ux.a(pm_policy.o)
/usr/conf/lib/libhp-ux.a(pm_proc.o)
/usr/conf/lib/libhp-ux.a(pm_procdup.o)
/usr/conf/lib/libhp-ux.a(pm_ptrace.o)
/usr/conf/lib/libhp-ux.a(pm_resource.o)
/usr/conf/lib/libhp-ux.a(pm_rtsched.o)
/usr/conf/lib/libhp-ux.a(pm_sendsig.o)
/usr/conf/lib/libhp-ux.a(pm_signal.o)
/usr/conf/lib/libhp-ux.a(pm_swtch.o)
/usr/conf/lib/libhp-ux.a(pm_threads.o)
/usr/conf/lib/libhp-ux.a(pm_timers.o)
/usr/conf/lib/libhp-ux.a(protection.o)
/usr/conf/lib/libhp-ux.a(pstat.o)
/usr/conf/lib/libhp-ux.a(resume.o)
/usr/conf/lib/libhp-ux.a(sem_alpha.o)
/usr/conf/lib/libhp-ux.a(spec_vnops.o)
/usr/conf/lib/libhp-ux.a(spinlock.o)
/usr/conf/lib/libhp-ux.a(subr_ksleep.o)
/usr/conf/lib/libhp-ux.a(subr_timers.o)
/usr/conf/lib/libhp-ux.a(sysV_shm.o)
/usr/conf/lib/libhp-ux.a(trap.o)
/usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
/usr/conf/lib/libhp-ux.a(ulbcopy.o)
/usr/conf/lib/libhp-ux.a(vfs.o)
/usr/conf/lib/libhp-ux.a(vfs_bio.o)
/usr/conf/lib/libhp-ux.a(vfs_dnlc.o)
/usr/conf/lib/libhp-ux.a(vfs_scalls.o)
/usr/conf/lib/libhp-ux.a(vfs_vm.o)
/usr/conf/lib/libhp-ux.a(vfs_vnode.o)
/usr/conf/lib/libhp-ux.a(vm_fault.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_mmap.o)
/usr/conf/lib/libhp-ux.a(vm_page.o)
/usr/conf/lib/libhp-ux.a(vm_pdir1_1.o)
/usr/conf/lib/libhp-ux.a(vm_pdir2_0.o)
/usr/conf/lib/libhp-ux.a(vm_pregion.o)
/usr/conf/lib/libhp-ux.a(vm_region.o)
/usr/conf/lib/libhp-ux.a(vm_sched.o)
/usr/conf/lib/libhp-ux.a(vm_superpage.o)
/usr/conf/lib/libhp-ux.a(vm_text.o)
/usr/conf/lib/libhp-ux.a(vm_vas.o)
/usr/conf/lib/libhp-ux.a(vm_vhand.o)
/usr/conf/lib/liblvm.a(lv_block.o)
/usr/conf/lib/liblvm.a(lv_cluster_lock.o)
/usr/conf/lib/liblvm.a(lv_defect.o)
/usr/conf/lib/liblvm.a(lv_hp.o)
/usr/conf/lib/liblvm.a(lv_ioctls.o)
/usr/conf/lib/liblvm.a(lv_kdb.o)
/usr/conf/lib/liblvm.a(lv_lvsubr.o)
/usr/conf/lib/liblvm.a(lv_malloc.o)
/usr/conf/lib/liblvm.a(lv_mircons.o)
/usr/conf/lib/liblvm.a(lv_pbuf.o)
/usr/conf/lib/liblvm.a(lv_phys.o)
/usr/conf/lib/liblvm.a(lv_schedule.o)
/usr/conf/lib/liblvm.a(lv_spare.o)
/usr/conf/lib/liblvm.a(lv_strategy.o)
/usr/conf/lib/liblvm.a(lv_stub.o)
/usr/conf/lib/liblvm.a(lv_subr.o)
/usr/conf/lib/liblvm.a(lv_syscalls.o)
/usr/conf/lib/liblvm.a(lv_vgda.o)
/usr/conf/lib/liblvm.a(lv_vgsa.o)
/usr/conf/lib/liblvm.a(sh_vgsa.o)
/usr/conf/lib/liblvm.a(slvm_comm.o)
/usr/conf/lib/liblvm.a(slvm_schedule.o)
/usr/conf/lib/libprm.a(kern_fss.o)
/usr/conf/lib/libufs.a(ufs_alloc.o)
/usr/conf/lib/libufs.a(ufs_inode.o)
/usr/conf/lib/libufs.a(ufs_vfsops.o)
/usr/conf/lib/libufs.a(ufs_vnops.o)
/usr/conf/lib/libvxfs_adv.a(vx_dmattr.o)
/usr/conf/lib/libvxfs_adv.a(vx_kdmi.o)
/usr/conf/lib/libvxfs_adv.a(vx_reorg.o)
/usr/conf/lib/libvxfs_adv.a(vx_sample_dmattr.o)
/usr/conf/lib/libvxfs_base.a(vx_alloc.o)
/usr/conf/lib/libvxfs_base.a(vx_attr.o)
/usr/conf/lib/libvxfs_base.a(vx_bio.o)
/usr/conf/lib/libvxfs_base.a(vx_bmapext4.o)
/usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o)
/usr/conf/lib/libvxfs_base.a(vx_bsdquota.o)
/usr/conf/lib/libvxfs_base.a(vx_dmstubs.o)
/usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o)
/usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o)
/usr/conf/lib/libvxfs_base.a(vx_iflush.o)
/usr/conf/lib/libvxfs_base.a(vx_inode.o)
/usr/conf/lib/libvxfs_base.a(vx_itrunc.o)
/usr/conf/lib/libvxfs_base.a(vx_lite.o)
/usr/conf/lib/libvxfs_base.a(vx_log.o)
/usr/conf/lib/libvxfs_base.a(vx_mount.o)
/usr/conf/lib/libvxfs_base.a(vx_rdwri.o)
/usr/conf/lib/libvxfs_base.a(vx_replay.o)
/usr/conf/lib/libvxfs_base.a(vx_vfsops.o)
/usr/conf/lib/libvxfs_base.a(vx_vm.o)
/usr/conf/lib/libvxfs_base.a(vx_vnops.o)
/usr/conf/machine/reg.h
/usr/conf/master.d/core-hpux
/usr/conf/master.d/flkmgr
/usr/conf/space.h.d/core-hpux.h
/usr/conf/space.h.d/flkmgr_globals.h
/usr/include/dmapi.h
/usr/include/machine/reg.h
/usr/include/sys/audit.h
/usr/include/sys/dnlc.h
/usr/include/sys/fs/vx_hpux.h
/usr/include/sys/fss.h
what(1) Output:
/usr/conf/h/_flkmgr.h:
_flkmgr.h $Date: 98/02/02 14:04:07 $ $Revision: 1
.1.98.3 $ PATCH_10.20 (PHKL_14012)
/usr/conf/h/audit.h:
audit.h $Date: 97/04/21 13:54:38 $ $Revision:
1.10.98.5 $ PATCH_10.20 (PHKL_10800)
/usr/conf/h/dnlc.h:
dnlc.h $Date: 97/09/02 15:03:34 $ $Revision: 1.4.98
.3 $ PATCH_10.20 (PHKL_12378)
/usr/conf/h/fss.h:
fss.h $Date: 98/01/08 14:50:28 $ $Revision: 1.5.9
8.4 $ PATCH_10.20 (PHKL_12963)
fss.h: $Revision: 1.5.98.4 $ $Date: 98/01/08 14:50:2
8 $
/usr/conf/lib/libdmapi.a(kdm_core.o):
kdm_core.c $Date: 97/09/02 13:10:59 $ $Revision: 1.2
.98.9 $ PATCH_10.20 (PHKL_12088)
/usr/conf/lib/libdmapi.a(vx_dmattr_table.o):
vx_dmattr_table.c $Date: 97/10/15 15:06:43 $ $Revisi
on: 1.2.98.5 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libhp-ux.a(asm_rv.o):
asm_rv.s $Date: 97/12/02 15:04:48 $ $Revision: 1.57
.98.15 $ PATCH_10.20 (PHKL_13260)
/usr/conf/lib/libhp-ux.a(asm_scall.o):
asm_scall.s $Date: 96/11/22 10:45:59 $ $Revision: 1
.39.98.6 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(asm_utl.o):
asm_utl.s $Date: 96/11/22 10:49:42 $ $Revision: 1.1
17.98.10 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(asm_vm.o):
asm_vm.s $Date: 98/01/13 15:04:01 $ $Revision:
1.60.98.11 $ PATCH_10.20 (PHKL_13795)
/usr/conf/lib/libhp-ux.a(asm_vm_pdir.o):
asm_vm_pdir.s $Date: 97/05/02 01:58:51 $ $Revision:
1.2.98.5 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(audctl.o):
audctl.c $Date: 98/02/09 14:10:00 $ $Revision: 1.
13.98.5 $ PATCH_10.20 (PHKL_14126)
/usr/conf/lib/libhp-ux.a(bcopy.o):
bcopy.s $Date: 96/11/22 10:51:06 $ $Revision: 1.7.9
8.4 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(btlb.o):
btlb.c $Date: 97/05/02 02:00:53 $ $Revision: 1.9.
98.4 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(bzero.o):
bzero.s $Date: 96/11/22 10:52:32 $ $Revision: 1.9.9
8.4 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(clock.o):
clock.c $Date: 97/01/23 16:09:43 $ $Revision: 1.39.
98.4 $ PATCH_10.20 (PHKL_9919)
/usr/conf/lib/libhp-ux.a(cpd.o):
cpd.c $Date: 96/10/26 09:39:05 $ $Revision: 1.9.98.8
$ PATCH_10.20 (PHKL_8999)
/usr/conf/lib/libhp-ux.a(dump.o):
dump.c $Date: 96/10/26 09:49:44 $ $Revision:
1.11.98.6 $ PATCH_10.20 (PHKL_8999)
/usr/conf/lib/libhp-ux.a(dump_conf.o):
dump_conf.c $Date: 97/12/17 14:28:07 $ $Revision:
1.6.98.6 $ PATCH_10.20 (PHKL_13247)
/usr/conf/lib/libhp-ux.a(flipper.o):
flipper.c $Date: 97/03/31 14:58:19 $ $Revision: 1.3.
98.8 $ PATCH_10.20 (PHKL_10554)
/usr/conf/lib/libhp-ux.a(flkmgr.o):
flkmgr.c $Date: 98/03/25 16:12:57 $ $Revision:
1.1.98.2 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/libhp-ux.a(flkmgr_dom.o):
flkmgr_dom.c $Date: 98/03/20 09:26:00 $ $Revision:
1.1.98.3 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/libhp-ux.a(flkmgr_flk.o):
flkmgr_flk.c $Date: 98/03/20 09:26:12 $ $Revision:
1.1.98.3 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/libhp-ux.a(flkmgr_hp.o):
flkmgr_hp.c $Date: 98/03/20 09:30:11 $ $Revision:
1.1.98.4 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/libhp-ux.a(flkmgr_main.o):
flkmgr_main.c $Date: 98/03/20 09:28:37 $ $Revision:
1.1.98.5 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/libhp-ux.a(flkmgr_mm.o):
flkmgr_mm.c $Date: 98/03/20 09:28:56 $ $Revision:
1.1.98.3 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/libhp-ux.a(flkmgr_pm.o):
flkmgr_pm.c $Date: 98/03/20 09:30:21 $ $Revision:
1.1.98.3 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/libhp-ux.a(hdl_fault.o):
hdl_fault.c $Date: 97/05/02 02:00:56 $ $Revision:
1.13.98.11 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(hdl_init.o):
hdl_init.c $Date: 96/08/26 22:38:17 $ $Revision:
1.9.98.5 $ PATCH_10.20 (PHKL_8346)
/usr/conf/lib/libhp-ux.a(hdl_mprotect.o):
hdl_mprotect.c $Date: 98/01/09 15:32:02 $ $Revision:
1.4.98.6 $ PATCH_10.20 (PHKL_13761)
/usr/conf/lib/libhp-ux.a(hdl_policy.o):
hdl_policy.c $Date: 98/03/04 10:37:17 $ $Revision: 1
.15.98.13 $ PATCH_10.20 (PHKL_14321)
/usr/conf/lib/libhp-ux.a(hdl_trans.o):
hdl_trans.c $Date: 98/02/19 09:36:04 $ $Revision:
1.12.98.12 $ PATCH_10.20 (PHKL_14225)
/usr/conf/lib/libhp-ux.a(init_main.o):
init_main.c $Date: 97/06/17 15:09:59 $ $Revision:
1.120.98.13 $ PATCH_10.20 (PHKL_11406)
/usr/conf/lib/libhp-ux.a(interrupt.o):
interrupt.s $Date: 97/03/31 13:22:48 $ $Revision: 1
.12.98.10 $ PATCH_10.20 (PHKL_10554)
/usr/conf/lib/libhp-ux.a(kern_acct.o):
kern_acct.c $Date: 98/02/09 14:26:42 $ $Revision: 1.
30.98.7 $ PATCH_10.20 (PHKL_14126)
/usr/conf/lib/libhp-ux.a(kern_exec.o):
kern_exec.c $Date: 97/09/03 18:56:26 $ $Revision:
1.93.98.24 $ PATCH_10.20 (PHKL_12397)
/usr/conf/lib/libhp-ux.a(kern_exit.o):
kern_exit.c $Date: 98/02/02 14:05:08 $ $Revision:
1.77.98.16 $ PATCH_10.20 (PHKL_14012)
/usr/conf/lib/libhp-ux.a(kern_fork.o):
kern_fork.c $Date: 98/02/02 14:05:13 $ $Revision:
1.71.98.19 $ PATCH_10.20 (PHKL_14012)
/usr/conf/lib/libhp-ux.a(kern_kload.o):
kern_kload.c $Date: 97/05/02 02:02:58 $ $Revision
: 1.4.98.5 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(kern_mman.o):
kern_mman.c $Date: 97/04/09 11:33:14 $ $Revision:
1.35.98.5 $ PATCH_10.20 (PHKL_10689)
/usr/conf/lib/libhp-ux.a(kern_sig.o):
kern_sig.c $Date: 97/05/02 02:03:00 $ $Revision:
1.66.98.4 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(lbcopy.o):
lbcopy.s $Date: 97/05/02 16:44:13 $ $Revision: 1.7.
98.6 $ PATCH_10.20 (PHKL_10932)
/usr/conf/lib/libhp-ux.a(lbzero.o):
lbzero.s $Date: 96/11/22 10:57:29 $ $Revision: 1.9.
98.4 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(lv_config.o):
lv_config.c $Date: 97/10/15 15:28:02 $ $Revision: 1.
13.98.7 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libhp-ux.a(lv_lvm.o):
lv_lvm.c $Date: 97/12/17 14:24:01 $ $Revision: 1.3.9
8.4 $ PATCH_10.20 (PHKL_13247)
/usr/conf/lib/libhp-ux.a(lw_scall.o):
lw_scall.s $Date: 97/05/02 02:01:00 $ $Revision:
1.18.98.7 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(machdep.o):
machdep.c $Date: 97/09/23 11:23:01 $ $Revision: 1.12
6.98.8 $ PATCH_10.20 (PHKL_12662)
/usr/conf/lib/libhp-ux.a(outlaw.o):
outlaw.c $Date: 96/11/22 11:17:11 $ $Revision:
1.2.98.3 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(pgcopy.o):
pgcopy.s $Date: 96/11/22 18:05:02 $ $Revision: 1.7.
98.5 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(pm_clockint.o):
pm_clockint.c $Date: 98/01/08 10:02:23 $ $Revision:
1.7.98.8 $ PATCH_10.20 (PHKL_12963)
/usr/conf/lib/libhp-ux.a(pm_config.o):
pm_config.c $Date: 97/06/17 15:09:55 $ $Revision: 1.
6.98.8 $ PATCH_10.20 (PHKL_11406)
/usr/conf/lib/libhp-ux.a(pm_context.o):
pm_context.c $Date: 96/08/26 22:35:25 $ $Revision
: 1.3.98.6 $ PATCH_10.20 (PHKL_8346)
/usr/conf/lib/libhp-ux.a(pm_core.o):
pm_core.c $Date: 98/02/09 14:28:20 $ $Revision: 1
.9.98.11 $ PATCH_10.20 (PHKL_14126)
/usr/conf/lib/libhp-ux.a(pm_getpid.o):
pm_getpid.c $Date: 98/02/02 14:05:16 $ $Revision:
1.6.98.2 $ PATCH_10.20 (PHKL_14012)
/usr/conf/lib/libhp-ux.a(pm_policy.o):
pm_policy.c $Date: 98/03/17 10:21:04 $ $Revision:
1.7.98.11 $ PATCH_10.20 (PHKL_14490)
/usr/conf/lib/libhp-ux.a(pm_proc.o):
pm_proc.c $Date: 97/06/11 17:26:34 $ $Revision: 1.13
.98.12 $ PATCH_10.20 (PHKL_11339)
/usr/conf/lib/libhp-ux.a(pm_procdup.o):
pm_procdup.c $Date: 97/11/18 12:02:39 $ $Revision: 1
.11.98.14 $ PATCH_10.20 (PHKL_13260)
/usr/conf/lib/libhp-ux.a(pm_ptrace.o):
pm_ptrace.c $Date: 97/05/02 02:03:08 $ $Revision: 1.
6.98.25 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(pm_resource.o):
pm_resource.c $Date: 97/06/11 17:28:51 $ $Revision:
1.7.98.14 $ PATCH_10.20 (PHKL_11339)
/usr/conf/lib/libhp-ux.a(pm_rtsched.o):
pm_rtsched.c $Date: 97/09/08 22:31:38 $ $Revision: 1
.6.98.4 $ PATCH_10.20 (PHKL_12042)
/usr/conf/lib/libhp-ux.a(pm_sendsig.o):
pm_sendsig.c $Date: 97/05/02 02:01:02 $ $Revision
: 1.4.98.12 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(pm_signal.o):
pm_signal.c $Date: 97/08/08 16:59:26 $ $Revision:
1.6.98.17 $ PATCH_10.20 (PHKL_12073)
/usr/conf/lib/libhp-ux.a(pm_swtch.o):
pm_swtch.c $Date: 98/01/09 10:23:24 $ $Revision:
1.7.98.20 $ PATCH_10.20 (PHKL_12963)
/usr/conf/lib/libhp-ux.a(pm_threads.o):
pm_threads.c $Date: 97/05/02 02:03:13 $ $Revision
: 1.3.98.11 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(pm_timers.o):
pm_timers.c $Date: 98/03/25 15:04:15 $ $Revision: 1.
7.98.11 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/libhp-ux.a(protection.o):
protection.s $Date: 96/11/22 11:00:38 $ $Revision:
1.10.98.4 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(pstat.o):
pstat.c $Date: 98/01/30 11:43:58 $ $Revision: 1.18.9
8.24 $ PATCH_10.20 (PHKL_14009)
/usr/conf/lib/libhp-ux.a(resume.o):
resume.s $Date: 96/11/22 11:01:44 $ $Revision: 1.11
.98.4 $ PATCH_10.20 (PHKL_9151)
/usr/conf/lib/libhp-ux.a(sem_alpha.o):
sem_alpha.c $Date: 96/11/20 16:33:04 $ $Revision:
1.11.98.5 $ PATCH_10.20 (PHKL_9273)
/usr/conf/lib/libhp-ux.a(spec_vnops.o):
spec_vnops.c $Date: 98/03/05 18:02:15 $ $Revision: 1
.13.98.7 $ PATCH_10.20 (PHKL_14323)
/usr/conf/lib/libhp-ux.a(spinlock.o):
spinlock.c $Date: 98/02/12 09:33:34 $ $Revision: 1.1
6.98.9 $ PATCH_10.20 (PHKL_14183)
/usr/conf/lib/libhp-ux.a(subr_ksleep.o):
subr_ksleep.c $Date: 97/05/02 02:03:21 $ $Revisio
n: 1.1.98.13 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(subr_timers.o):
subr_timers.c $Date: 97/08/13 17:10:50 $ $Revision:
1.8.98.13 $ PATCH_10.20 (PHKL_12110)
/usr/conf/lib/libhp-ux.a(sysV_shm.o):
sysV_shm.c $Date: 96/11/20 11:01:21 $ $Revision:
1.54.98.5 $ PATCH_10.20 (PHKL_9075)
/usr/conf/lib/libhp-ux.a(trap.o):
trap.c $Date: 97/09/23 11:22:02 $ $Revision: 1.16
9.98.14 $ PATCH_10.20 (PHKL_12662)
/usr/conf/lib/libhp-ux.a(ufs_mchdep.o):
ufs_mchdep.c $Date: 98/04/15 10:11:21 $ $Revision: 1
.18.98.5 $ PATCH_10.20 (PHKL_14803)
/usr/conf/lib/libhp-ux.a(ulbcopy.o):
ulbcopy.s $Date: 98/03/03 16:51:57 $ $Revision:
1.4.98.9 $ PATCH_10.20 (PHKL_14321)
/usr/conf/lib/libhp-ux.a(vfs.o):
vfs.c $Date: 98/01/13 00:20:08 $ $Revision: 1.25.98.
14 $ PATCH_10.20 (PHKL_13795)
/usr/conf/lib/libhp-ux.a(vfs_bio.o):
vfs_bio.c $Date: 98/04/15 10:05:25 $ $Revision: 1.26
.98.24 $ PATCH_10.20 (PHKL_14803)
/usr/conf/lib/libhp-ux.a(vfs_dnlc.o):
vfs_dnlc.c $Date: 98/01/13 00:22:28 $ $Revision: 1.1
8.98.4 $ PATCH_10.20 (PHKL_13795)
/usr/conf/lib/libhp-ux.a(vfs_scalls.o):
vfs_scalls.c $Date: 98/02/09 14:29:54 $ $Revision:
1.18.98.18 $ PATCH_10.20 (PHKL_14126)
/usr/conf/lib/libhp-ux.a(vfs_vm.o):
vfs_vm.c $Date: 97/10/15 14:57:20 $ $Revision: 1.17.
98.18 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libhp-ux.a(vfs_vnode.o):
vfs_vnode.c $Date: 98/02/09 14:32:04 $ $Revision:
1.14.98.7 $ PATCH_10.20 (PHKL_14126)
/usr/conf/lib/libhp-ux.a(vm_fault.o):
vm_fault.c $Date: 98/02/02 14:05:21 $ $Revision:
1.22.98.15 $ PATCH_10.20 (PHKL_14012)
/usr/conf/lib/libhp-ux.a(vm_kern.o):
vm_kern.c $Date: 97/05/20 15:19:14 $ $Revision: 1.
9.98.5 $ PATCH_10.20 (PHKL_11164)
/usr/conf/lib/libhp-ux.a(vm_machdep.o):
vm_machdep.c $Date: 98/01/13 15:00:59 $ $Revision:
1.157.98.34 $ PATCH_10.20 (PHKL_13795)
/usr/conf/lib/libhp-ux.a(vm_machreg.o):
vm_machreg.c $Date: 97/11/19 12:38:57 $ $Revision: 1
.17.98.22 $ PATCH_10.20 (PHKL_13260)
/usr/conf/lib/libhp-ux.a(vm_mmap.o):
vm_mmap.c $Date: 98/03/04 10:48:36 $ $Revision:
1.17.98.16 $ PATCH_10.20 (PHKL_14321)
/usr/conf/lib/libhp-ux.a(vm_page.o):
vm_page.c $Date: 98/02/02 14:05:23 $ $Revision: 1.
91.98.14 $ PATCH_10.20 (PHKL_14012)
/usr/conf/lib/libhp-ux.a(vm_pdir1_1.o):
vm_pdir1_1.c $Date: 97/05/02 02:00:37 $ $Revision:
1.3.98.14 $ PATCH_10.20 (PHKL_10757)
/usr/conf/lib/libhp-ux.a(vm_pdir2_0.o):
vm_pdir2_0.c $Date: 97/06/18 13:12:17 $ $Revision: 1
.3.98.11 $ PATCH_10.20 (PHKL_11408)
/usr/conf/lib/libhp-ux.a(vm_pregion.o):
vm_pregion.c $Date: 97/04/07 13:34:27 $ $Revision:
1.16.98.13 $ PATCH_10.20 (PHKL_10643)
/usr/conf/lib/libhp-ux.a(vm_region.o):
vm_region.c $Date: 96/11/20 11:01:58 $ $Revision:
1.20.98.4 $ PATCH_10.20 (PHKL_9075)
/usr/conf/lib/libhp-ux.a(vm_sched.o):
vm_sched.c $Date: 98/02/02 14:05:25 $ $Revision:
1.58.98.12 $ PATCH_10.20 (PHKL_14012)
/usr/conf/lib/libhp-ux.a(vm_superpage.o):
vm_superpage.c $Date: 98/03/18 17:20:25 $ $Revisi
on: 1.2.98.7 $ PATCH_10.20 (PHKL_14490)
/usr/conf/lib/libhp-ux.a(vm_text.o):
vm_text.c $Date: 97/03/03 12:25:55 $ $Revision: 1
.56.98.9 $ PATCH_10.20 (PHKL_10257)
/usr/conf/lib/libhp-ux.a(vm_vas.o):
vm_vas.c $Date: 97/07/07 15:53:17 $ $Revision:
1.18.98.16 $ PATCH_10.20 (PHKL_11696)
/usr/conf/lib/libhp-ux.a(vm_vhand.o):
vm_vhand.c $Date: 98/02/02 14:05:27 $ $Revision:
1.20.98.7 $ PATCH_10.20 (PHKL_14012)
/usr/conf/lib/liblvm.a(lv_block.o):
lv_block.c $Date: 97/10/15 15:27:22 $ $Revision: 1.1
3.98.5 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_cluster_lock.o):
lv_cluster_lock.c $Date: 97/10/15 15:27:47 $ $Revisi
on: 1.10.98.5 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_defect.o):
lv_defect.c $Date: 97/10/15 15:28:20 $ $Revision: 1.
16.98.6 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_hp.o):
lv_hp.c $Date: 98/03/27 10:35:58 $ $Revision: 1.18.9
8.24 $ PATCH_10.20 (PHKL_14568)
/usr/conf/lib/liblvm.a(lv_ioctls.o):
lv_ioctls.c $Date: 98/04/07 15:45:30 $ $Revision: 1.
18.98.23 $ PATCH_10.20 (PHKL_14740)
/usr/conf/lib/liblvm.a(lv_kdb.o):
lv_kdb.c $Date: 97/10/15 17:16:54 $ $Revision: 1.9.9
8.4 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_lvsubr.o):
lv_lvsubr.c $Date: 97/10/15 15:31:26 $ $Revision: 1.
15.98.17 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_malloc.o):
lv_malloc.c $Date: 97/10/15 15:31:46 $ $Revision: 1.
11.98.4 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_mircons.o):
lv_mircons.c $Date: 97/10/15 15:32:02 $ $Revision: 1
.14.98.7 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_pbuf.o):
lv_pbuf.c $Date: 97/10/15 15:32:20 $ $Revision: 1.11
.98.7 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_phys.o):
lv_phys.c $Date: 98/02/05 10:20:02 $ $Revision: 1.14
.98.13 $ PATCH_10.20 (PHKL_14049)
/usr/conf/lib/liblvm.a(lv_schedule.o):
lv_schedule.c $Date: 98/04/15 10:15:35 $ $Revision:
1.18.98.12 $ PATCH_10.20 (PHKL_14803)
/usr/conf/lib/liblvm.a(lv_spare.o):
lv_spare.c $Date: 97/10/15 15:33:09 $ $Revision: 1.3
.98.6 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_strategy.o):
lv_strategy.c $Date: 97/10/15 15:33:32 $ $Revision:
1.14.98.8 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_stub.o):
lv_stub.c $Date: 96/10/25 20:54:05 $ $Revision: 1.13
.98.2 $ PATCH_10.20 (PHKL_8999)
/usr/conf/lib/liblvm.a(lv_subr.o):
lv_subr.c $Date: 97/10/15 15:33:47 $ $Revision: 1.18
.98.7 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_syscalls.o):
lv_syscalls.c $Date: 97/12/16 16:36:09 $ $Revision:
1.14.98.9 $ PATCH_10.20 (PHKL_13247)
/usr/conf/lib/liblvm.a(lv_vgda.o):
lv_vgda.c $Date: 97/10/15 15:34:41 $ $Revision: 1.18
.98.4 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(lv_vgsa.o):
lv_vgsa.c $Date: 97/10/15 15:35:07 $ $Revision: 1.14
.98.7 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/liblvm.a(sh_vgsa.o):
sh_vgsa.c $Date: 97/06/26 12:07:10 $ $Revision: 1.3
.98.9 $ PATCH_10.20 (PHKL_11561)
/usr/conf/lib/liblvm.a(slvm_comm.o):
slvm_comm.c $Date: 96/10/25 17:03:40 $ $Revision: 1.
3.98.4 $ PATCH_10.20 (PHKL_8999)
/usr/conf/lib/liblvm.a(slvm_schedule.o):
slvm_schedule.c $Date: 96/10/25 17:03:49 $ $Revision
: 1.3.98.6 $ PATCH_10.20 (PHKL_8999)
/usr/conf/lib/libprm.a(kern_fss.o):
kern_fss.c $Date: 98/01/08 09:59:27 $ $Revision:
1.11.98.3 $ PATCH_10.20 (PHKL_12963)
/usr/conf/lib/libufs.a(ufs_alloc.o):
ufs_alloc.c $Date: 97/10/15 16:50:46 $ $Revision: 1.
38.98.8 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libufs.a(ufs_inode.o):
ufs_inode.c $Date: 98/03/25 11:09:25 $ $Revision: 1.
48.98.14 $ PATCH_10.20 (PHKL_14613)
/usr/conf/lib/libufs.a(ufs_vfsops.o):
ufs_vfsops.c $Date: 98/03/25 11:09:21 $ $Revision: 1
.20.98.18 $ PATCH_10.20 (PHKL_14613)
/usr/conf/lib/libufs.a(ufs_vnops.o):
ufs_vnops.c $Date: 98/03/25 11:08:57 $ $Revision: 1.
30.98.24 $ PATCH_10.20 (PHKL_14613)
/usr/conf/lib/libvxfs_adv.a(vx_dmattr.o):
vx_dmattr.c $Date: 97/10/15 15:06:19 $ $Revision: 1.
2.98.8 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_adv.a(vx_kdmi.o):
vx_kdmi.c $Date: 97/10/15 15:22:37 $ $Revision: 1.2.
98.15 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_adv.a(vx_reorg.o):
vx_reorg.c $Date: 98/01/19 21:01:45 $ $Revision: 1.6
.98.15 $ PATCH_10.20 (PHKL_13874)
/usr/conf/lib/libvxfs_adv.a(vx_sample_dmattr.o):
vx_sample_dmattr.c $Date: 97/10/15 15:25:55 $ $Revis
ion: 1.2.98.9 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_alloc.o):
vx_alloc.c $Date: 97/10/15 14:58:22 $ $Revision: 1.5
.98.15 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_attr.o):
vx_attr.c $Date: 97/12/08 10:57:39 $ $Revision: 1.7.
98.12 $ PATCH_10.20 (PHKL_13452)
/usr/conf/lib/libvxfs_base.a(vx_bio.o):
vx_bio.c $Date: 97/10/15 15:02:52 $ $Revision: 1.7.9
8.11 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_bmapext4.o):
vx_bmapext4.c $Date: 97/10/15 15:05:13 $ $Revision:
1.2.98.13 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o):
vx_bmaptyped.c $Date: 97/10/15 15:05:31 $ $Revision:
1.2.98.18 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_bsdquota.o):
vx_bsdquota.c $Date: 98/01/06 13:13:40 $ $Revision:
1.7.98.15 $ PATCH_10.20 (PHKL_13713)
/usr/conf/lib/libvxfs_base.a(vx_dmstubs.o):
vx_dmstubs.c $Date: 97/10/15 15:07:05 $ $Revision: 1
.2.98.8 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o):
vx_fsetsubr.c $Date: 97/10/15 15:07:36 $ $Revision:
1.2.98.14 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o):
vx_hpuxsubr.c $Date: 97/10/15 15:20:24 $ $Revision:
1.7.98.14 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_iflush.o):
vx_iflush.c $Date: 97/10/15 15:19:38 $ $Revision: 1.
6.98.15 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_inode.o):
vx_inode.c $Date: 97/10/15 15:20:59 $ $Revision: 1.7
.98.20 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_itrunc.o):
vx_itrunc.c $Date: 97/10/15 15:22:10 $ $Revision: 1.
7.98.19 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_lite.o):
vx_lite.c $Date: 97/10/15 15:23:00 $ $Revision: 1.4.
98.8 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_log.o):
vx_log.c $Date: 97/10/15 15:24:16 $ $Revision: 1.6.9
8.7 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_mount.o):
vx_mount.c $Date: 98/03/05 18:11:21 $ $Revision: 1.7
.98.18 $ PATCH_10.20 (PHKL_14323)
/usr/conf/lib/libvxfs_base.a(vx_rdwri.o):
vx_rdwri.c $Date: 97/10/15 15:24:56 $ $Revision: 1.7
.98.25 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_replay.o):
vx_replay.c $Date: 97/10/15 15:25:29 $ $Revision: 1.
2.98.14 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_vfsops.o):
vx_vfsops.c $Date: 97/12/11 01:03:47 $ $Revision: 1.
7.98.16 $ PATCH_10.20 (PHKL_13508)
/usr/conf/lib/libvxfs_base.a(vx_vm.o):
vx_vm.c $Date: 97/10/15 15:26:32 $ $Revision: 1.7.98
.16 $ PATCH_10.20 (PHKL_12901)
/usr/conf/lib/libvxfs_base.a(vx_vnops.o):
vx_vnops.c $Date: 97/10/15 15:26:53 $ $Revision: 1.8
.98.25 $ PATCH_10.20 (PHKL_12901)
/usr/conf/machine/reg.h:
$Revision: 1.16.98.3 $ */
reg.h $Date: 97/11/18 12:00:25 $ $Revision: 1.16.98.
3 $ PATCH_10.20 (PHKL_13260)
/usr/conf/master.d/core-hpux:
core-hpux $Date: 98/03/17 10:01:16 $ $Revision: 1.
6.98.16 $ PATCH_10.20 (PHKL_14490)
/usr/conf/master.d/flkmgr:
flkmgr $Date: 98/04/03 08:42:38 $ $Revision: 1
.1.98.5 $ PATCH_10.20 (PHKL_14685)
/usr/conf/space.h.d/core-hpux.h:
core-hpux.h $Date: 98/03/17 10:03:30 $ $Revision:
1.6.98.15 $ PATCH_10.20 (PHKL_14490)
/usr/conf/space.h.d/flkmgr_globals.h:
flkmgr_globals.h $Date: 98/02/02 14:03:23 $ $Revisio
n: 1.1.98.3 $ PATCH_10.20 (PHKL_14012)
/usr/include/dmapi.h:
dmapi.h: $Revision: 1.2.98.7 $ $Date: 97/09/02 13:03
:46 $
dmapi.h $Date: 97/09/02 13:03:46 $ $Revision: 1.
2.98.7 $ PATCH_10.20 (PHKL_12088)
src/kernel/dmapi/dmapi.h 2.12 14 Aug 1996 18:51:12 -
*/
/usr/include/machine/reg.h:
$Revision: 1.16.98.3 $ */
reg.h $Date: 97/11/18 12:00:25 $ $Revision: 1.16.98.
3 $ PATCH_10.20 (PHKL_13260)
/usr/include/sys/audit.h:
audit.h $Date: 97/04/21 13:54:38 $ $Revision:
1.10.98.5 $ PATCH_10.20 (PHKL_10800)
/usr/include/sys/dnlc.h:
dnlc.h $Date: 97/09/02 15:03:34 $ $Revision: 1.4.98
.3 $ PATCH_10.20 (PHKL_12378)
/usr/include/sys/fs/vx_hpux.h:
vx_hpux.h: $Revision: 1.7.98.14 $ $Date: 97/09/03 09
:28:45 $ PATCH_10.20 (PHKL_12088)
src/kernel/vxfs/vx_hpux.h 2.14.4.3 30 Jul 1996 17:05
:11 - */
fshp:src/kernel/vxfs/vx_hpux.h 2.14.4.3
/usr/include/sys/fss.h:
fss.h $Date: 98/01/08 14:50:28 $ $Revision: 1.5.9
8.4 $ PATCH_10.20 (PHKL_12963)
fss.h: $Revision: 1.5.98.4 $ $Date: 98/01/08 14:50:2
8 $
cksum(1) Output:
1849128454 8068 /usr/conf/h/_flkmgr.h
309306691 13103 /usr/conf/h/audit.h
2131780918 1777 /usr/conf/h/dnlc.h
2593525881 3565 /usr/conf/h/fss.h
2308637956 48664 /usr/conf/lib/libdmapi.a(kdm_core.o)
3851147702 1784 /usr/conf/lib/libdmapi.a(vx_dmattr_table.o)
538984117 20076 /usr/conf/lib/libhp-ux.a(asm_rv.o)
3109290296 7640 /usr/conf/lib/libhp-ux.a(asm_scall.o)
1231112847 18512 /usr/conf/lib/libhp-ux.a(asm_utl.o)
1918067463 19548 /usr/conf/lib/libhp-ux.a(asm_vm.o)
1650397953 4584 /usr/conf/lib/libhp-ux.a(asm_vm_pdir.o)
1908120037 11228 /usr/conf/lib/libhp-ux.a(audctl.o)
3455675956 4668 /usr/conf/lib/libhp-ux.a(bcopy.o)
4158269677 10276 /usr/conf/lib/libhp-ux.a(btlb.o)
4124458617 2432 /usr/conf/lib/libhp-ux.a(bzero.o)
1053092530 19912 /usr/conf/lib/libhp-ux.a(clock.o)
4114346575 11604 /usr/conf/lib/libhp-ux.a(cpd.o)
797819625 12752 /usr/conf/lib/libhp-ux.a(dump.o)
1748908507 8704 /usr/conf/lib/libhp-ux.a(dump_conf.o)
1084924137 8028 /usr/conf/lib/libhp-ux.a(flipper.o)
3521987937 75560 /usr/conf/lib/libhp-ux.a(flkmgr.o)
1503982196 3176 /usr/conf/lib/libhp-ux.a(flkmgr_dom.o)
3192008703 7148 /usr/conf/lib/libhp-ux.a(flkmgr_flk.o)
3027257443 3240 /usr/conf/lib/libhp-ux.a(flkmgr_hp.o)
3675135296 8552 /usr/conf/lib/libhp-ux.a(flkmgr_main.o)
2389894881 3120 /usr/conf/lib/libhp-ux.a(flkmgr_mm.o)
185498796 4696 /usr/conf/lib/libhp-ux.a(flkmgr_pm.o)
3189247447 13408 /usr/conf/lib/libhp-ux.a(hdl_fault.o)
555026448 6348 /usr/conf/lib/libhp-ux.a(hdl_init.o)
4283888750 15772 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
1090773941 11992 /usr/conf/lib/libhp-ux.a(hdl_policy.o)
367858484 10748 /usr/conf/lib/libhp-ux.a(hdl_trans.o)
3231555571 18508 /usr/conf/lib/libhp-ux.a(init_main.o)
3476683986 6584 /usr/conf/lib/libhp-ux.a(interrupt.o)
1062453135 5180 /usr/conf/lib/libhp-ux.a(kern_acct.o)
1125379815 16964 /usr/conf/lib/libhp-ux.a(kern_exec.o)
2229502215 17528 /usr/conf/lib/libhp-ux.a(kern_exit.o)
3691736042 16348 /usr/conf/lib/libhp-ux.a(kern_fork.o)
50317043 6492 /usr/conf/lib/libhp-ux.a(kern_kload.o)
4163060998 3948 /usr/conf/lib/libhp-ux.a(kern_mman.o)
2216617969 10284 /usr/conf/lib/libhp-ux.a(kern_sig.o)
3276898957 6160 /usr/conf/lib/libhp-ux.a(lbcopy.o)
300166288 2428 /usr/conf/lib/libhp-ux.a(lbzero.o)
630638081 26628 /usr/conf/lib/libhp-ux.a(lv_config.o)
1237596189 156552 /usr/conf/lib/libhp-ux.a(lv_lvm.o)
228543399 7008 /usr/conf/lib/libhp-ux.a(lw_scall.o)
2111739438 30444 /usr/conf/lib/libhp-ux.a(machdep.o)
2457463992 3348 /usr/conf/lib/libhp-ux.a(outlaw.o)
3029803182 2988 /usr/conf/lib/libhp-ux.a(pgcopy.o)
807433184 6308 /usr/conf/lib/libhp-ux.a(pm_clockint.o)
1701549902 5388 /usr/conf/lib/libhp-ux.a(pm_config.o)
3811483497 2236 /usr/conf/lib/libhp-ux.a(pm_context.o)
3785773729 6872 /usr/conf/lib/libhp-ux.a(pm_core.o)
2304745347 2580 /usr/conf/lib/libhp-ux.a(pm_getpid.o)
1855111803 16844 /usr/conf/lib/libhp-ux.a(pm_policy.o)
3933929381 17908 /usr/conf/lib/libhp-ux.a(pm_proc.o)
2742363982 6684 /usr/conf/lib/libhp-ux.a(pm_procdup.o)
3682830469 15732 /usr/conf/lib/libhp-ux.a(pm_ptrace.o)
775863340 7076 /usr/conf/lib/libhp-ux.a(pm_resource.o)
4277200061 8728 /usr/conf/lib/libhp-ux.a(pm_rtsched.o)
1066734922 16212 /usr/conf/lib/libhp-ux.a(pm_sendsig.o)
4157339108 11544 /usr/conf/lib/libhp-ux.a(pm_signal.o)
4206257236 20536 /usr/conf/lib/libhp-ux.a(pm_swtch.o)
3233056101 12032 /usr/conf/lib/libhp-ux.a(pm_threads.o)
3249449452 6464 /usr/conf/lib/libhp-ux.a(pm_timers.o)
18384036 11264 /usr/conf/lib/libhp-ux.a(protection.o)
2330409141 24000 /usr/conf/lib/libhp-ux.a(pstat.o)
2317800830 3876 /usr/conf/lib/libhp-ux.a(resume.o)
3665684469 9532 /usr/conf/lib/libhp-ux.a(sem_alpha.o)
3933277056 16880 /usr/conf/lib/libhp-ux.a(spec_vnops.o)
1179856871 18256 /usr/conf/lib/libhp-ux.a(spinlock.o)
3306390220 10616 /usr/conf/lib/libhp-ux.a(subr_ksleep.o)
1319709682 10572 /usr/conf/lib/libhp-ux.a(subr_timers.o)
925297696 8712 /usr/conf/lib/libhp-ux.a(sysV_shm.o)
1671896846 23616 /usr/conf/lib/libhp-ux.a(trap.o)
2692169925 10584 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
3495714284 6340 /usr/conf/lib/libhp-ux.a(ulbcopy.o)
3120713060 20444 /usr/conf/lib/libhp-ux.a(vfs.o)
2201525231 29276 /usr/conf/lib/libhp-ux.a(vfs_bio.o)
3897607434 8616 /usr/conf/lib/libhp-ux.a(vfs_dnlc.o)
2911854326 31728 /usr/conf/lib/libhp-ux.a(vfs_scalls.o)
1439345029 29828 /usr/conf/lib/libhp-ux.a(vfs_vm.o)
1482457387 8920 /usr/conf/lib/libhp-ux.a(vfs_vnode.o)
482152261 13384 /usr/conf/lib/libhp-ux.a(vm_fault.o)
1473182150 10480 /usr/conf/lib/libhp-ux.a(vm_kern.o)
1962971277 92676 /usr/conf/lib/libhp-ux.a(vm_machdep.o)
2851321488 15524 /usr/conf/lib/libhp-ux.a(vm_machreg.o)
3859003674 21644 /usr/conf/lib/libhp-ux.a(vm_mmap.o)
2208932717 21312 /usr/conf/lib/libhp-ux.a(vm_page.o)
290807052 30900 /usr/conf/lib/libhp-ux.a(vm_pdir1_1.o)
1469266556 53368 /usr/conf/lib/libhp-ux.a(vm_pdir2_0.o)
1265397058 12324 /usr/conf/lib/libhp-ux.a(vm_pregion.o)
1266053234 11316 /usr/conf/lib/libhp-ux.a(vm_region.o)
692138061 25108 /usr/conf/lib/libhp-ux.a(vm_sched.o)
1800879851 10040 /usr/conf/lib/libhp-ux.a(vm_superpage.o)
2800961341 14444 /usr/conf/lib/libhp-ux.a(vm_text.o)
1841465344 13360 /usr/conf/lib/libhp-ux.a(vm_vas.o)
1688897665 14904 /usr/conf/lib/libhp-ux.a(vm_vhand.o)
2971522811 2632 /usr/conf/lib/liblvm.a(lv_block.o)
303437109 9964 /usr/conf/lib/liblvm.a(lv_cluster_lock.o)
1367795889 12596 /usr/conf/lib/liblvm.a(lv_defect.o)
1537531955 83148 /usr/conf/lib/liblvm.a(lv_hp.o)
1045412530 32344 /usr/conf/lib/liblvm.a(lv_ioctls.o)
872237003 720 /usr/conf/lib/liblvm.a(lv_kdb.o)
1466831003 36100 /usr/conf/lib/liblvm.a(lv_lvsubr.o)
2374339579 2544 /usr/conf/lib/liblvm.a(lv_malloc.o)
4288668251 17420 /usr/conf/lib/liblvm.a(lv_mircons.o)
2331070456 6576 /usr/conf/lib/liblvm.a(lv_pbuf.o)
1800616120 7736 /usr/conf/lib/liblvm.a(lv_phys.o)
3075337331 26432 /usr/conf/lib/liblvm.a(lv_schedule.o)
1405315567 36420 /usr/conf/lib/liblvm.a(lv_spare.o)
3767976309 7176 /usr/conf/lib/liblvm.a(lv_strategy.o)
4115391771 732 /usr/conf/lib/liblvm.a(lv_stub.o)
2518086102 10064 /usr/conf/lib/liblvm.a(lv_subr.o)
1101210836 13616 /usr/conf/lib/liblvm.a(lv_syscalls.o)
1382667354 9108 /usr/conf/lib/liblvm.a(lv_vgda.o)
3655615117 12600 /usr/conf/lib/liblvm.a(lv_vgsa.o)
58167558 42028 /usr/conf/lib/liblvm.a(sh_vgsa.o)
2159002800 27264 /usr/conf/lib/liblvm.a(slvm_comm.o)
4188283521 6724 /usr/conf/lib/liblvm.a(slvm_schedule.o)
2592552461 8200 /usr/conf/lib/libprm.a(kern_fss.o)
2981279314 17624 /usr/conf/lib/libufs.a(ufs_alloc.o)
2953936705 26772 /usr/conf/lib/libufs.a(ufs_inode.o)
2086674135 20460 /usr/conf/lib/libufs.a(ufs_vfsops.o)
2691216524 35752 /usr/conf/lib/libufs.a(ufs_vnops.o)
760609908 2964 /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o)
1161747513 24748 /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o)
3486377848 20588 /usr/conf/lib/libvxfs_adv.a(vx_reorg.o)
3582414206 4592 /usr/conf/lib/
libvxfs_adv.a(vx_sample_dmattr.o)
3334723579 28228 /usr/conf/lib/libvxfs_base.a(vx_alloc.o)
3079465245 37688 /usr/conf/lib/libvxfs_base.a(vx_attr.o)
3014150328 10452 /usr/conf/lib/libvxfs_base.a(vx_bio.o)
2280461010 10824 /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o)
1802836350 18340 /usr/conf/lib/
libvxfs_base.a(vx_bmaptyped.o)
3341046136 29164 /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o)
1851387969 4928 /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o)
2357795855 21168 /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o)
1502964316 16292 /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o)
3531998086 29724 /usr/conf/lib/libvxfs_base.a(vx_iflush.o)
347435613 44852 /usr/conf/lib/libvxfs_base.a(vx_inode.o)
1839120165 14412 /usr/conf/lib/libvxfs_base.a(vx_itrunc.o)
1857910709 3600 /usr/conf/lib/libvxfs_base.a(vx_lite.o)
945378166 9620 /usr/conf/lib/libvxfs_base.a(vx_log.o)
4198919323 28312 /usr/conf/lib/libvxfs_base.a(vx_mount.o)
4227507470 35424 /usr/conf/lib/libvxfs_base.a(vx_rdwri.o)
1686960615 7052 /usr/conf/lib/libvxfs_base.a(vx_replay.o)
2409040095 15220 /usr/conf/lib/libvxfs_base.a(vx_vfsops.o)
3054202871 11924 /usr/conf/lib/libvxfs_base.a(vx_vm.o)
1359133065 26564 /usr/conf/lib/libvxfs_base.a(vx_vnops.o)
2426350973 5075 /usr/conf/machine/reg.h
1340823251 17122 /usr/conf/master.d/core-hpux
425791205 5474 /usr/conf/master.d/flkmgr
2799878239 19242 /usr/conf/space.h.d/core-hpux.h
1447084439 1119 /usr/conf/space.h.d/flkmgr_globals.h
1315928410 16548 /usr/include/dmapi.h
2426350973 5075 /usr/include/machine/reg.h
309306691 13103 /usr/include/sys/audit.h
2131780918 1777 /usr/include/sys/dnlc.h
1556434298 9724 /usr/include/sys/fs/vx_hpux.h
2593525881 3565 /usr/include/sys/fss.h
Patch Conflicts: None
Patch Dependencies:
s700: 10.20: PHCO_12922 PHCO_8871 PHNE_13245
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHKL_7776 PHKL_7870 PHKL_7899 PHKL_7951 PHKL_8084 PHKL_8203
PHKL_8294 PHKL_8331 PHKL_8346 PHKL_8481 PHKL_8532 PHKL_8683
PHKL_8716 PHKL_8953 PHKL_8999 PHKL_9075 PHKL_9151 PHKL_9153
PHKL_9273 PHKL_9361 PHKL_9365 PHKL_9370 PHKL_9372 PHKL_9517
PHKL_9529 PHKL_9569 PHKL_9711 PHKL_9909 PHKL_9919 PHKL_9931
PHKL_10064 PHKL_10176 PHKL_10199 PHKL_10234 PHKL_10257 PHKL_10288
PHKL_10316 PHKL_10452 PHKL_10554 PHKL_10643 PHKL_10675 PHKL_10689
PHKL_10757 PHKL_10800 PHKL_10821 PHKL_10930 PHKL_10932 PHKL_10953
PHKL_10966 PHKL_11006 PHKL_11013 PHKL_11039 PHKL_11055 PHKL_11085
PHKL_11164 PHKL_11238 PHKL_11244 PHKL_11247 PHKL_11316 PHKL_11321
PHKL_11339 PHKL_11358 PHKL_11406 PHKL_11408 PHKL_11471 PHKL_11519
PHKL_11561 PHKL_11607 PHKL_11614 PHKL_11637 PHKL_11696 PHKL_11730
PHKL_11733 PHKL_11766 PHKL_11860 PHKL_11902 PHKL_12042 PHKL_12073
PHKL_12088 PHKL_12100 PHKL_12110 PHKL_12217 PHKL_12378 PHKL_12397
PHKL_12409 PHKL_12601 PHKL_12633 PHKL_12662 PHKL_12669 PHKL_12901
PHKL_12963 PHKL_12997 PHKL_13155 PHKL_13206 PHKL_13237 PHKL_13247
PHKL_13260 PHKL_13305 PHKL_13452 PHKL_13508 PHKL_13680 PHKL_13684
PHKL_13713 PHKL_13761 PHKL_13768 PHKL_13795 PHKL_13874 PHKL_13911
PHKL_14009 PHKL_14012 PHKL_14049 PHKL_14126 PHKL_14183 PHKL_14225
PHKL_14321 PHKL_14323 PHKL_14490 PHKL_14568 PHKL_14613 PHKL_14685
PHKL_14740
Equivalent Patches:
PHKL_14804:
s800: 10.20
Patch Package Size: 2770 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_14803
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHKL_14803.depot
5b. For a homogeneous NFS Diskless cluster run swcluster on the
server to install the patch on the server and the clients:
swcluster -i -b
This will invoke swcluster in the interactive mode and
force all clients to be shut down.
WARNING: All cluster clients must be shut down prior to the
patch installation. Installing the patch while the
clients are booted is unsupported and can lead to
serious problems.
The swcluster command will invoke an swinstall session in which
you must specify:
alternate root path - default is /export/shared_root/OS_700
source depot path - /tmp/PHKL_14803.depot
To complete the installation, select the patch by choosing
"Actions -> Match What Target Has" and then "Actions -> Install"
from the Menubar.
5c. For a heterogeneous NFS Diskless cluster:
- run swinstall on the server as in step 5a to install
the patch on the cluster server.
- run swcluster on the server as in step 5b to install
the patch on the cluster clients.
By default swinstall will archive the original software in
/var/adm/sw/patch/PHKL_14803. If you do not wish to retain a
copy of the original software, you can create an empty file
named /var/adm/sw/patch/PATCH_NOSAVE.
Warning: If this file exists when a patch is installed, the
patch cannot be deinstalled. Please be careful
when using this feature.
It is recommended that you move the PHKL_14803.text file to
/var/adm/sw/patch for future reference.
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHKL_14803.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
- SR: 4701382564, DTS: DSDe441726
Two tunable variables have been defined for this patch.
They are:
kern_vm_pct - the threshold percentage. When the free
sysmap space as a percentage of 1 GB falls below the value
of kern_vm_pct, warning message is printed to notify the
user of this condition.
kern_vm_scan_rate - the time interval in seconds between
subsequent checks that statdaemon makes to determine if the
free kernel sysmap space as a percentage of 1GB is below the
threshold percentage (kern_vm_pct) value or not; if below
the threshold value print the warning message about the
condition. By default both kern_vm_pct and
kern_vm_scan_rate are set to 0 ie. by default the
monitoring of the free kernel sysmap space is turned off.
To turn on the feature you need to set kern_vm_scan_rate and
kern_vm_pct variables to non zero value.
eg. In file /stand/system
* Tunable parameters
kern_vm_pct 10
kern_vm_scan_rate 10
Threshold percentage is 10%; scan rate is 10 seconds.
CAUTION: Failure to follow the instructions in this section
could result in undesired system behavior up to and
including data corruption or a system panic!
This kernel patch need to work with the command patch
PHCO_12922; please install PHCO_12922 with this patch.
Installed alone, this kernel patch will not solve the fsck
problem.
---
If you are planning to install the advanced VxFS product
(AdvJournalFS.VXFS-ADV-KRN), it is imperative that this
patch, and all listed superseded patches, be removed from
the system via swremove(1M) before the actual product
installation. After the installation of the advanced VxFS
product has completed, this patch can be re-installed. (It
is not necessary to re-install superseded patches.) All
patches listed in the Supersedes field are subject to this
behavior and need to be removed before installing the
advanced VxFS product. After running swremove(1M), use the
swlist(1M) command to insure that none of the previous
patches were restored during the removal process. If one
was, remove it using swremove(1M).
---
When this patch is installed the default environment size
is 20478 bytes. To enable the system to use the larger
environment size of 2048000 bytes, the following
steps must be followed.
1. A new tunable called `large_ncargs_enabled' must be
defined in the sytem file in the following manner
large_ncargs_enabled 1
2. A new kernel must be built (using this system file)
and the system rebooted.
To return to the default environment size, the new tunable
needs to be either removed from the system file, or its
value set to zero. A new kernel should then be built
(using the modified system file) and the machine
rebooted.
---
Due to the number of objects in this patch, the
customization phase of the update may take more than 10
minutes. During that time the system will not appear to
make forward progress, but it will actually be installing
the objects.