Patch Name: PHKL_13232
Patch Description: s700 10.01 PM, VM, LVM, KI, VxFS, HSC SCSI cumulative patch
Creation Date: 97/11/18
Post Date: 97/11/25
Hardware Platforms - OS Releases:
s700: 10.01
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_13232: OTHER
Quantum DLT4500/4700 will not operate properly
without this patch.
PHKL_12604: CORRUPTION
PHKL_8904: PANIC CORRUPTION
Panic should occur only if root volume is LVM on
built-in SCSI in 710, 720, 715/50, 725/50.
Corruption should only occur on QUANTUM LPS525S on
built-in SCSI in 710, 720, 715/50, 725/50.
PHKL_8361: HANG
PHKL_6547: HANG
PHKL_6027: PANIC HANG
in general, this patch is not needed on s700
unless you experience the panic with scsi floppy
installed or you are adapting s700's to high
availability (HA) environments.
note that this patch may slow down some
operations on devices which are not ready to
be accessed (e.g., devices with no media
installed).
PHKL_12395: PANIC HANG
PHKL_11889: PANIC
PHKL_11563: OTHER
This patch corrects the standards problem listed
above.
PHKL_11206: CORRUPTION
PHKL_10136: HANG
PHKL_9565: HANG
PHKL_8757: HANG
PHKL_8731: CORRUPTION
PHKL_8602: PANIC
PHKL_8391: HANG
This patch adds a new feature to LVM.
The feature is provided to customers
who need the option to limit the time LVM waits
for powerfailed disks in given logical volumes
to return.
PHKL_8386: CORRUPTION
PHKL_8199: HANG
PHKL_8080: ABORT
PHKL_7901: PANIC OTHER
The setuid fix is non-critical.
PHKL_7846: PANIC
PHKL_7578: CORRUPTION
PHKL_7508: PANIC CORRUPTION
PHKL_7357: PANIC
The defect shows up in extremely rare situations.
PHKL_7306: OTHER
increase limit
PHKL_7250: HANG
PHKL_7217: PANIC HANG CORRUPTION
PHKL_7205: ABORT
PHKL_7185: CORRUPTION
PHKL_7037: PANIC
PHKL_7024: PANIC
PHKL_7015: PANIC OTHER
O_DSYNC flag ignored
PHKL_6888: PANIC
PHKL_6764: HANG
PHKL_6674: PANIC
PHKL_6494: PANIC OTHER
vgchange fails with "Invalid argument"
PHKL_6462: CORRUPTION
PHKL_6024: CORRUPTION PANIC
PHKL_5888: PANIC
PHKL_5767: HANG
PHKL_5737: HANG
Path Name: /hp-ux_patches/s700/10.X/PHKL_13232
Symptoms:
PHKL_13232:
Quantum DLT4500/4700 do not show up properly on ioscan.
PHKL_12604:
VxFS file system corruption with the following message:
vxfs: mesg 003: vx_mapbad - /adabas/P01 file system
free extent bitmap in au 20 marked bad
PHKL_8904:
"SCSI: Unhandled interrupt" and resulting bus reset
can cause panic during boot of 710, 715/50, 720 and
725/50 workstations if root disk is LVM and on
built-in SCSI bus. It's theoretically possible for
the bus reset to cause data corruption on QUANTUM
LPS525S disks on the bus.
Some M/O drives will not work on the above systems
plus 705, 715/33, 730, 735 and 755.
PHKL_8361:
Select timeouts are retried forever, i.e. I/O's never
complete when a device is removed.
SCSI bus hang and reset.
PHKL_7827:
Incorrect geometry determination for 5.25" 360K floppy.
Too long request timeout, 2 min. 30 sec. on EISA SCSI.
Missing SIOC_ABORT and SIOC_RESET_DEV functionality.
PHKL_6547:
auto retries of open on CD-ROM with no media can cause hang
PHKL_6027:
scsi problems, including 743 w/scsi floppy panic on boot
and potential subsystem hangs
PHKL_12653:
Large UID/GID users on NFS (10.20) clients can create JFS
files and directories on pre-10.20 servers with valid,
but incorrect, UIDs.
PHKL_12561:
On a VxFS with quota turned on, users who do not have
quota set should not have a quota limit. However, they
receive a bogus error message "write: Disk quota exceeded"
when creating files on this file system.
PHKL_12395:
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_12153:
Processes hang intermittently due to process deactivation
and reactivation.
PHKL_11889:
System panic's at vx_findino() with data page fault
while creating a file on a VxFS file system:
trap type 15, pcsq.pcoq = 0.291214, isr.ior = 0.294900c
panic: (display==0xb800, flags==0x0) Data page fault
Kernel Stack:
panic+0x10
report_trap_or_int_and_panic+0x8c
trap+0x72c
vx_findino+0xa4
vx_ialloc+0x60
vx_dirmakeinode+0x1d4
vx_dircreate+0x180
vx_dircreate_tran+0x1e4
vx_create+0xe4
vns_create+0xb0
vn_create+0xf8
vn_open+0x194
copen+0xe0
open+0x20
syscall+0x1f4
$syscallrtn+0x0
PHKL_11670:
On hp-ux 9.04 (S800) and 10.x (S700/S800), large MP
systems with a high switch rate result in unacceptable
level of KI CPU overhead. Moreover, the KI has the
processor spinlock during this time with interrupts
disabled! We have observed on a 10.10 TPC benchmark
system that enabling the swtch trace in the KI
reduces TPC throughput by 10%.
PHKL_11563:
The value returned by sysconf(_SC_ARG_MAX) does not
match the value of ARG_MAX (defined in limits.h)
PHKL_11293:
LVM bad block relocation interferes with EMC disk arrays.
PHKL_11242:
When accessing an address returned by mmap(), the
application gets a SIGBUS error and core is dumped.
PHKL_11206:
JFS snapshot files will sometimes disappear or become
corrupt.
PHKL_10281:
Performance suffers for sequential i/o with LVM and disk
arrays with stripe depth > 64k.
Edison ARM utilities (and diagnostic tools that require
exclusive access to a device) fail reporting device busy
(EBUSY) even when all volume groups accessing the device
are deactivated.
Edison ARM utilities (and diagnostic tools that require
exclusive access to a device) fail reporting device busy
(EBUSY) if the device was ever used as a Service Guard
Cluster Lock disk.
PHKL_10136:
Processes accessing memory mapped files "deadlock"
once in a while. Any other processes attempting to
access the memory mapped file HANG as well.
PHKL_10101:
Syslogd fills up file system.
PHKL_9707:
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_9565:
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_9404:
Executables residing on a VxFS (JFS) file-system would no
longer execute after being marked for VX_DIRECT operation.
A typical scenario would be as follow:
# cd /vxfs
# cp /usr/bin/ksh .
# ./ksh
# cc vxdirect.c -o vxdirect
# ./vxdirect ./ksh
# ./ksh
./ksh: ./ksh: cannot execute
See the vxfsio(7) man pages for details on VX_DIRECT.
PHKL_9263:
When MMF activity on VxFS files is very high for a given
process (like a process doing a lot of mmap access), then
the vhand process may want to pageout some pages onto the
VxFS file. On very rare occasion, this pageout process was
in a situation were the pageout write can't be satisfied
without waiting another ressource (like memory). Then, since
vhand can't wait, the page was marked zomb, and later a
fault on that page from the process made that process killed
by the OS.
PHKL_8757:
UFS hangs with heavy use of a filesystem branch by multiple
processes. The hang is due to a three way deadlock with
inodes and bufs being held but not released. This shows
up with the buf being both B_BUSY and B_DONE but not being
released.
PHKL_8731:
Under OnlineJFS, when very large writes (e.g. >phymem/16)
are done to JFS file(s), old data can appear in the middle
of the newly written file(s).
PHKL_8602:
trap 15 panic in pstat_fileinfo()
PHKL_8580:
After call to pstat_getmsg(), all accesses to the message
queue pstat_getmsg() was called hang.
PHKL_8391:
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.
Be sure to read the Special Installation Instructions for
this and all VxFS patches.
PHKL_8386:
Data corruption can occur if HP OnLineJFS is installed and a
very large write (over a megabyte) is done to a JFS file. A
sequence of 1 - 8191 zeros can appear in the middle of the
data just written.
PHKL_8282:
The customer is unable to pass arg/env strings to EXEC
containing more than 20k chars. They require the limit to
be raised to at least 100k.
PHKL_8199:
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_8080:
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_8024:
Files created in setgid directories no longer inherit the
gid of the directory.
PHKL_7908:
Running "strings" on a raw sar(1) output file can show some
printable ASCII characters (sar ignores these).
PHKL_7901:
With a system running a heavy load using JFS on LVM, the
following panic may occur: "lv_syncx: returning error: 5"
The setuid bit will be removed on a JFS file when the file
is modified even when run as root.
PHKL_7846:
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_7666:
Several types of symptoms may occur:
- logins on NFS clients may receive incorrect access on
NFS servers
- files from NFS servers may appear to be owned by the
wrong logins on NFS clients
- setuid and setgid binaries available on NFS servers
may allow client logins to run with incorrect access
PHKL_7578:
(1) Applications using ftruncate(2) on VxFS files could
possibly loose data. This problem was reported with the
Empress database.
(2) msync(2) with the MS_SYNC flag on VxFS memory map files
did not work as documented. Stale data could be found in
the buffer cache when resuming file system operations,
possibly resulting in data corruption.
(3) Poor system performance when directories containing
shared libraries, for example /usr, reside on a VxFS
file-system.
PHKL_7508:
Three distinct problems/symptoms:
1: Applications reading VxFS files through the read(2)
system call could get stale data from the buffer cache
if the files were previously written through a Memory
Mapped File. This is potential data corruption when
using MMFs on VxFS.
2: "panic: data page fault", if using fsadm to resize a
mounted VxFS filesystem with disk quotas
3: "vxfs: mesg 008: vx_direrr - /xxx file system inode x \
block y error 22"
followed by erroneous indications that the filesystem is
corrupt
PHKL_7357:
Conditional trap panic in small_divisor due to a divide by
zero condition, caused due to multiprocessor race condition.
PHKL_7306:
If the path for a script interpreter is longer than 32,
then exec(2) fails.
PHKL_7250:
System hangs, seems unable to process filesystem I/O,
although processes that need no filesystem interaction run.
PHKL_7217:
"panic: lv_validblk: invalid relocation status" or possible
panics, system hang, or data corruption on systems with
disks having bad blocks. Also, the same bad block was
kept relocating until run out of spare.
PHKL_7205:
Attempting to remove linked text file when original file
is busy gets ETXTBSY.
PHKL_7185:
lvmerge could merge an lvol back with all PEs marked as
current and yet the syncing of stale LTGs had failed.
lv_recover_ltg(k), which does the syncing, had no mechanism
to return error to lv_table_reimage(k). lv_table_reimage(k)
therefore returns success when this may not be the case.
PHKL_7122:
For very large /etc/passwd files, passwd command may return
EDEADLK and print an error message about lockf deadlock
detection.
PHKL_7037:
pvmove leads to panic: lv_reducelv extmap, when
the mirrored logical volume contains unallocated
physical extents (might caused by previous
unsuccessful pvmove operation (kill -9).
PHKL_7024:
When a user is deactivating a volume group, the system
panics with "lv_cache_deactivate inflight". PHKL_6675 fixes
some cases and this patch fixes a special case.
PHKL_7015:
This fixes two separate VxFS (JFS) problems.
1) trap type 15 in vx_iget
2) O_DSYNC is ignored for VxFS filesystems
PHKL_6987:
Systems with /usr on a VxFS file-system were experiencing
poor performance.
PHKL_6951:
VxFS reports "No space left on device" when reaching quota
limit rather than "Disc quota exceeded" over NFS.
PHKL_6888:
The panic occurs when a user program calls msync with
MS_INVALIDATE and then immediately tries to access the
mmap'ed region.
PHKL_6792:
If /etc/lvmtab is out of date with the running kernel,
vgcfgbackup fails.
PHKL_6764:
Rename deadlock: This deadlock occurs in the following
situation: Process 1 is moving a directory to a new
parent directory at the same time as Process 2 is doing a
lookup on the new parent directory Process 1's directory
is being moved into. Both processes will sleep forever
and all accesses to both directories will also sleep.
PHKL_6674:
lv_cache_deactivate inflight panic
PHKL_6529:
None. This is a pstat enhancement.
PHKL_6494:
vgchange: Couldn't activate volume group "/dev/vgpam":
Invalid argument
panic with "lv_fixrootlv: could not find boot pvol"
PHKL_6462:
Booting in LVM maintenance mode after changing the path of
a root disk can lead to one of two situations: (1) there is
no device at the old path -- LVM sends a hard partition one
write for the current boot disk to the underlying driver;
(2) there is a non-LVM disk or non-boot LVM disk at the old
path -- LVM writes to where the BDRA would be on that disk.
The write is attempting to set the maintenance mode flag in
the BDRA.
Symptoms such as root file system corruption (for case 1),
LVM meta-data corruption (for case 2), or disk data
corruption (for case 2) could then be observed.
This scenario is possible during any change of hardware
path to an LVM root disk. In particular, the 10.01 K100,
D200, D210, and D310 processor upgrade procedures are
affected.
PHKL_6448:
LVM disk resynchronization fails when disk powerfails
PHKL_6446:
LVM metadata timeouts in multi-initiator configurations,
especially with Nike, causing these error messages:
lv_readvgats: Could not read VGDA 1 header & trailer \
from disk ...
lv_readvgats: Could not read VGDA 2 header & trailer \
from disk ...
lv_readvgats: Could not read VGSA 1 header & trailer \
from disk ...
lv_readvgats: Could not read VGSA 2 header & trailer \
from disk ...
PHKL_6272:
No option to convert a ISO-9660 CDROM filename from
"FILENAME;VERSION" to lower case "filename".
PHKL_6081:
VxFS performance as a NFS exported file system is poor.
PHKL_6024:
Running vgcreate on an LVM disc without re-running pvcreate
before end could create an LVM disc where the start of user
data overlaps the LVM header, as for example with the
sequence:
pvcreate /dev/rdsk/c0t0d0
vgcreate vg05 /dev/dsk/c0t0d0
vgremove vg05
vgcreate -s 1 -e 2033 -p 60 vg05 /dev/dsk/c0t0d0
Symptoms such as file system corruption or LVM header
corruption, showing up as file system panics or LVM panics,
could then be observed.
PHKL_5888:
When the BDRA or the boot file is removed from the boot
disk, and the user tries to boot the system in LVM
maintenance mode, the boot runs a little while, then panics
with "vfs_MOUNTROOTS failed: NEED DRIVERS".
PHKL_5839:
lvreduce hangs when reducing a bad disk from lvol.
PHKL_5813:
May get some junk pages in the coredump.
PHKL_5767:
The system hangs when there is heavy load and some processes
which are swapped out use a lot of large memory mapped
segments.
PHKL_5737:
When booting a NFS Diskless client, the system may hang
when loading the kernel, when loading the RAM file system,
or when loading the ioconfig file.
PHKL_5663:
The vgchange -a r command fails with the message:
vgchange: Activation mode requested for the
volume group <volume group name> conflicts with
configured mode.
Defect Description:
PHKL_13232:
Quantum DLT4500/4700 were not recognized as multilun
devices.
PHKL_12604:
The following steps lead to the root cause of the problem:
1. file system corruption is related to reorg activity.
2. inproper handling of indirect address extents on files.
3. 'sometimes' vx_copy_blk() doesn't seem to copy the block
and apparently no error was reported.
4. VxFS does a flush prior to the copy and then when it is
all done, the extents are freed. But On HP-UX, the file
data is accessed via the file vnode and flushed by an
invalidating putpage, while indirect blocks and
directories are accessed via the file system device
vnode. For regular files, vx_extflush() will exit
without doing anything, so there will still be buffers
laying around in the cache hanging off the system device
vnode.
PHKL_8904:
The c720 driver does not lisc->sclk soon enough.
Chip timing parameters are set up incorrectly.
PHKL_8361:
Select timeouts are retried forever. B_NDELAY should
eliminate retries on select timeout.
Zalon chip bug results in SCSI bus hang.
PHKL_7827:
TEAC floppy firmware bug.
NCR 53C710 and 53C700 chip bug.
Missing SIOC_ABORT and SIOC_RESET_DEV functionality.
PHKL_6547:
a kmio struct was allocated even if the open failed.
see the SR for the reproduction methods.
PHKL_6027:
743 w/floppy panic on boot occurs if iodc search is
performed prior to booting hp-ux -- this leaves scsi bus
in hung state.
potential subsystem hangs occur following request
timeouts from drives that the driver does not recover
from properly.
PHKL_12653:
The large UID/GID is truncated mod 2^16 when creating the
file on the server. For example, a client UID of 2000000
results in a UID of 33920 on the file created on the server.
PHKL_12561:
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_12395:
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_12153:
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_11889:
During inode allocation, vx_findino() references an
unallocated entry in the au summary. This code of
checking for free space in the allocation unit is used
for VxFS version 1 and is no longer valid for version 2.
PHKL_11670:
The ki_swtch trace generation code in the kernel walks
all pregions in the vas of the swtched process. PTC's MI
and performance tools do not need rss values updated every
context switch - the extra overhead is not worth the small
increase in accuracy.
It is sufficient to copy the pid's
vas_t->va.prss+vas_t->va.rss (private + shared) value
which is updated every 5 seconds by statdaemon.
PHKL_11563:
Due to a recent enhancement to EXEC, the maximum
environment size was increased from 20478 bytes to 204798
bytes. However the value of the constant ARG_MAX
(defined in limits.h) was not changed. As a result
there is a standards problem due to this mismatch.
PHKL_11293:
When an EMC disk array returns an EMEDIA error to LVM,
LVM at a minimum marks the block as bad in the bad block
directory (and, normally, relocates the block to a new
location on disk. This is detrimental to the functionality
of EMC disk arrays, since the bad blocks can be fixed
on the hardware itself.
PHKL_11242:
mmap() to a file with holes does not work correctly if
MAP_PRIVATE is used.
PHKL_11206:
Defect was due to a race condition between the reserve
buf and a regular buf for the same block number. The reserve
buffer was being read before the regular buffer had a chance
to complete a write to the same block number.
Problem was reproduced by starinig memory. Small number of
bufs in the buffer cache makes the problme reproduce more
often.
PHKL_10281:
LVM user data was aligned to a 1k bound. For sequential
i/o directed to disk arrays which stripe the data, i/os
with a buf size approaching the stripe depth of the device
(64k for the Edison array) would require the device to
perform two i/os for each i/o directed to the device.
LVM was not always closing and releasing devices held when
volume groups were deactivated or when a device was used
as a Service Guard Cluster Lock disk.
PHKL_10136:
A deadlock is caused by procedure vm_wait_for_io being
called with "iglock" being held and releasing the
region lock prior to sleeping. Deadlock occurs when
another process is able to get the "region lock" and
is waiting for the iglock. The fix is to call
vm_wait_for_io at the the end of vx_pageout after the
iglock has been released.
PHKL_10101:
msg_bufx was set to the value over MSG_BSIZE.
PHKL_9707:
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_9565:
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_9404:
The execve() kernel routine was asking for a KERNEL IO to
read in the a.out header, but the VxFS code handling direct
IOs (VX_DIRECT) was generating a USER IO.
PHKL_9263:
Under MMF high presure, vx_do_pageio called from vhand
incorectly marked a page as r_zomb when EAGAIN occurs on
that page. This as the side effect of killing a process that
do a fault on that page later on.
PHKL_8757:
Problem was due to incorrectly releasing an inode while
still holding a buf. This violates the rule which would
prevent a deadlock from happening. The problem shows up
as a three way deadlock with two processes marching back
to the root from the leaves via ".." and another process
marching from the root to the leaves. This creates a
a deadlock of processes waiting for the same inode and
holding the wanted buf at the same time.
PHKL_8731:
OnLineJFS breaks large write requests into multiple direct
I/O's. Depending on the size of the data block, the
beginnning and end of a direct I/O request may not align on
the block boundaries. In these cases, the data is handled
through buffer cache.
After the first direct I/O, the subsequent iteration may
begin with a write that has data starting in the middle
of the buffer. If this write passes the current EOF, the
buffer is simply allocated and filled with new data. If
this buffer happens to be one that previously used to hold
old data, the old data remains in the portion that is not
overwritten by the new data. Writing this buffer to disk
corrupts the file.
The fix is to check against the correct file size so the
first buffer of the subsequent iteration will be read in
from disk to contain the correct data written in the last
iteration.
PHKL_8602:
When commands that call pstat_fileinfo(2) (e.g. fuser(1m))
on a system where lots of processes are exiting, a race
condition can occur between exit(2) and pstat_fileinfo(2)
where pstat_fileinfo(2) dereferences a pointer exit(2)
has already set to NULL.
PHKL_8580:
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_8391:
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_8386:
The problem can be reproduced with this test program:
char buf[2097152];
main()
{
int fd;
memset((void *)buf, 'A', sizeof(buf));
fd = creat("A.dat", 0644);
write(fd, buf, 512);
write(fd, buf, sizeof(buf));
}
Every byte of the file should contain the character 'A'.
This works fine on UFS. It also works on VxFS as long as
HP OnLineJFS is not installed. But with HP OnLineJFS, a
sequence of null bytes appears in the middle of the file
(not at the boundary between the writes, but in the middle
of the second write).
PHKL_8282:
The max. limit for the number of chars in the arg/env
strings passed to EXEC is currently set at 20k (defined by
ARG_MAX). Attempts to pass more number of chars result in
the E2BIG error. This limit was imposed due to the way the
kernel was allocating memory to copy the arg/env strings and
set them for the newly exec'ed process.
PHKL_8199:
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_8080:
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_8024:
Directories with the setgid bit set have the following
property: when any file is created within that directory,
it inherits the group id of the directory. In addition, any
directory created under such a directory also has the setgid
bit set.
Patch PHKL_7666 inadvertently removed that feature of setgid
directories. This patch restores it.
PHKL_7908:
pstat_dynamic() allocates a buffer but fails to initialize
it before using it, so the buffer ends up containing some
garbage. This is a cosmetic defect only; sar ignores the
uninitialized spaces.
PHKL_7901:
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().
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_7846:
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_7666:
A future HP-UX release will increase the value of MAXUID,
providing for a greater range of valid UIDs and GIDs. It
will also introduce problems in mixed-mode NFS environments.
Let "LUID" specify a machine running a version of HP-UX
with large-UID capability. Let "SUID" specify a machine
with current small-UID capability. The following problems
may occur:
LUID client, SUID server
- Client logins with UIDs outside the server's range
appear as the anonymous user. However, the anonymous
user UID is configurable, and is sometimes configured
as the root user (in order to "trust" all client root
logins without large-scale modifications to the
/etc/exports file). Thus, all logins with large UIDs
on the client could be mapped to root on the server.
- Files owned by the nobody user on the server will
appear to be owned by the wrong user on the client.
SUID client, LUID server
- Files owned by large-UID logins on the server will
appear to be owned by the wrong user on the client.
- Executables with the setuid or setgid mode turned
on will allow logins on the client to run as the
wrong users.
There is a patch to the NFS code that is intended to be used
in parallel with this one. PHKL_7510 (or its successor)
should be installed with this one, although no defects are
introduced by installing only this one of the two.
PHKL_7578:
(1) The VxFS file truncation code was breaking an assumption
in brealloc() causing delayed-write buffers to be discarded
instead of being flushed to disk.
(2) A "purge buffer cache" was not performed by the VxFS
pageout code. Stale data could then be found in the buffer
cache when resuming file-system operations after a msync(2).
(3) VxFS used to purge the buffer cache at mmap(2) time, and
the Dynamic Loader (dld.sl) suffered poor performance with
shared-libraries residing a VxFS file-system. The fix was to
purge the buffer cache at pageout time, and to flush it at
pagein time.
Defects #2 and #3 are fixed in 10.20, but #1 is fixed 10.20.
PHKL_7508:
The three distinct problems:
1: The code change for PHKL_6988 or equivalent (consisting
of only flushing dirty buffers at mmap() time and to no
longer also invalidate valid buffers) broke the mechanism
by which VxFS was handling the consistency of the "page
cache" and the "buffer cache". Valid stale buffers could
be found in the buffer cache after changes would have
been done through a MMF, and this is data corruption.
The fix was to back out the change of PHKL_6988.
2: Resizing VxFS filesystems online effectively does a quick
unmounts and remount of the filesystem, switching quickly
between two different data areas containing information
it. 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.
3: This problem was mainly seen on striped logical volumes.
If multiple processes were scanning VxFS directories via
commands like ls, find, or cpio, they could cause VxFS to
erroneously assume the filesystem is corrupt, making it
impossible to remount it until fscked. There would also
be errors in the syslog referring to vx_direrr.
The defect was in a lack of caching of offsets within the
directory block; if the offset changed at an inopportune
time, the directory read would fail and the filesystem
would be marked corrupt.
PHKL_7357:
Conditional trap panic in small_divisor. In
target_deactime(), the following division is performed:
return (deact_time_factor * deactprss(p) / nz(pageoutrate))
where nz is defined as (x != 0 ? x : 1). Since there is
no MP protection around pageoutrate, it is possible that
pageoutrate changes between the test and assignment. The
fix is to use a local copy of the global pageoutrate to
avoid such a situation.
PHKL_7306:
It had been limited to 32 characters.
PHKL_7250:
On LVM, when the resource "lv_str2_buf" for big-size
IO requests is exhausted, multiple processes could
compete and sleep for the same resource without first
releasing the ones they owned, causing a deadlock.
PHKL_7217:
When LVM encounters a bad block, it asks the disk drive to
spare it out; this is called "hardware relocation." If that
fails, LVM then performs what is called "software
relocation" -- that is, it replaces the bad block with a
block from a reserve area called the bad block directory.
After the relocation, it reads back the data, just to make
sure the new block isn't bad as well; if the new block is
bad, LVM relocates THAT one, again and again until it is
successful.
There was a defect in the code that dealt with the LVM
verification of the new block. Apparently, the block number
was incremented before checking if the second relocation
succeeded; if the last block of that relocation was bad, the
block number indicated that all the data had been
transferred, so LVM assumed that the write was successful.
However, the driver indicated errors (specifically, B_ERROR
was set and b_error was EMEDIA), which led to inconsistent
data in the bad block directory, typically leading to a
panic.
This patch also fixes LVM wrongly relocating a bad block.
It should relocate the bad one instead of the block next to
the bad one.
PHKL_7205:
VxFS forgot to check if nlink is 1.
PHKL_7185:
lvmerge could merge an lvol back with all physical extents
marked as current and yet the syncing of stale LTGs had
failed. lv_recover_ltg(k), which does the syncing, had no
mechanism to return an error to lv_table_reimage(k).
lv_table_reimage(k) therefore returns success when this may
not be the case.
PHKL_7122:
PHKL_6763 caused the kernel routine direnter() to return
EDEADLK if it couldn't lock all the directories and files
it needed to. The change was made to fix a deadlock problem
caused by moving directories, and it was thought that
direnter() could only hit this state for the DE_RENAME
function. The problem can also be hit for large, popular
files like /etc/passwd which are being linked to a new
name. The fix is to have ufs_link() retry direnter() if
EDEADLK is returned, just as ufs_rename() did in the
original patch.
PHKL_7037:
Customer were using pvmove command to move data from
one disk to another. For some reason, the mirrored
logical volume to be moved contains unallocated
physical extents. system panic: lv_reducelv extmap
PHKL_7024:
When deactivating a volume group, if the MWC cache is not
clean, the deactivation routine will detect it and panic.
When the last user LV (/dev/vgXX/lvol[1-n]) of a volume
group is closing and the controlling LV (/dev/vgXX/group) is
still opened, it should also wait for all outstanding MWC
cache writes to be finished.
PHKL_7015:
VxFS neglected to check for the O_DSYNC flag. It only
checked for O_SYNC.
In vx_iget, the code dereferenced a NULL pointer.
PHKL_6987:
When creating a memory mapped file, VxFS was flushing and
invalidating the file-related buffers from the buffer cache.
This behavior caused the dynamic loader (dld.sl) to generate
a physical I/O each time it was reading a shared library
header before calling mmap(), and shared library headers
were never found in the buffer cache. The fix was to only
flush (writing dirty buffers) and not do the invalidation.
PHKL_6951:
Incorrect "No space left on device" errors were generated
when the filesystem was not actually full. The filesystem
in question was a VxFS filesystem mounted over NFS from
another system with quotas enabled on the server. The
message occurred when a user reaches the hard limit on the
mounted directory.
This was caused by the VxFS code in HP-UX interpreting a
class of filesystem space allocation failures all as ENOSPC.
The fix was to correect this misinterpretation. With this
patch installed, when a user exceeds his quota, the error on
his terminal will be "Disk quota exceeded".
PHKL_6888:
The problem encountered at 9.X was fixed in 10.X by delaying
the removal of the mmap'd page (pageremove) until the I/O
had completed. At the same time this was done, there were
also some changes done to speed up MMFs. One of those
changes involved sparse files and resulted in the need for
coordination between rwip() and MMFs. The end result was
rwip() locating pages in the pagecache() and copying data
back to the buffer cache block. At the completion of the
copy, the pages were systematically removed from the
pagecache which removed our "synchronization" link for
msync(). See the SR for reproduction methods.
PHKL_6792:
The customer had a T500 ran into the problem with
"/etc/lvmtab is out of date with running kernel" when doing
a vgcfgbackup. The current PV value was set to 7, while
there were only 6 disks in the /etc/lvmtab.
PHKL_6764:
Directory renaming code locked the new parent directory and
read the new parent directory buffer, thereby locking it.
It then dropped the new parent directory lock and later
tried to reacquire it. If a lookup process had gotten the
new parent directory lock in the meantime and was sleeping
waiting for the new parent directory buffer to be free,
deadlock!
PHKL_6674:
When the last LV of a VG is closing, it should wait for all
outstanding MWC cache writes to be finished. Otherwise, it
may have a running MWC cache write when VG releases its
dynamically allocated structure.
Create multiple LVs on a VG, and make MWC busy (by writing
256K bytes interval) then close All LVs (at almost the same
time).
PHKL_6529:
No defect with the kernel. Although this patch does allow a
patch to fix a defect with fuser -k to work.
PHKL_6494:
Problem is easily duplicatable following the replacement of
a disk mech, or with a simply vgcfgrestore/vgchange
combination to the right disks.
To reproduce one problem, connect an HP-FL disk to 10.01
system, and do the following:
- Install PHKL_6273 (supersedes LVM patch PHKL_6025)
- Create a volume group with this disk in it
(automatically runs vgcfgbackup):
pvcreate -f /dev/rdsk/c0t2d0
mkdir /dev/vgdan
mknod /dev/vgdan/group c 64 0x090000
vgcreate /dev/vgdan /dev/dsk/c0t2d0
- Deactivate the VG:
vgchange -a n /dev/vgdan
- Restore the LVM data structures to the disk:
vgcfgrestore -n /dev/vgdan /dev/rdsk/c0t2d0
- At this point, any further activation of the VG will fail:
vgchange -a y /dev/vgdan
vgchange: Couldn't activate volume group "/dev/vgpam":
Invalid argument
This problem occurred because of a change made in LVM to
support "hot-swapping" of disk mech's. The code to handle
this attempts to set immediate-reporting on the newly-added
disk, but this is not a valid operation on a non-SCSI disk.
The driver returns EINVAL as it should, and LVM heeds this
error and passes it up to the higher levels, causing
vgchange to fail with "Invalid argument". So, now if we
have EINVAL in this case, we return ESUCCESS.
Second problem:
Create a root volume group with more than two disks, and
mirror the root lvol onto the last disk added to the volume
group, and make that pvol bootable.
Remove all but the disks on which root is mirrorred.
Boot into maintenance mode from the last disk added to the
volume group (the one with the highest PV number).
Reboot normally (without maintenance mode) from the same
disk. The system will panic with
"lv_fixrootlv: could not find boot pvol"
This problem occurred because we were searching through the
number of valid pvol array entries which are not necessarily
contiguous in the array instead of searching through the
size of the array.
PHKL_6462:
During maintenance boot (hpux -lm), the kernel tried to
write out a flag to the BDRAs so that the next boot
could resync the root.
The routine which does the maintenance flag write uses the
hardware paths stored in the BDRA. When the path(s) of the
root disk(s) are changed, the old paths may correspond to no
device or to some other disk.
(1) In the case where a path now corresponds to no device,
the routine opens the wrong device -- in particular, the
boot device with the hard partition one bit set.
(2) In the case where a hardware path now corresponds to
some unintended disk, the write goes to where the BDRA would
be on that disk.
For case (1), whether or not the hard partition one write
goes through depends on the underlying driver. Case (2) is
independent of the underlying driver. Either case
represents a potential corruption to the disks involved.
The patch prevents these corruptions by (1) checking if a
hardware path corresponds to NODEV -- if so, no write to
that path is performed; (2) checking if there is a valid
BDRA at that hardware path -- if not, no write to that path
is performed. Since the maintenance flag write is needed
for mirrored roots, another check was added to make sure
that flag gets written to the current boot device.
To reproduce case (1):
- install 10.01 to an NIO tower
- change the address of the root in the tower
- boot in maintenance mode (hpux -lm)
- notice that the maintenance flag is not
set in the BDRA (check 16kb at offset 128)
- notice that the BDRA was written to
hard partition one (check 16kb at hard
partition one for that disk type)
To reproduce case (2):
- install 10.01 to an NIO tower
- change the address of the root in the tower
- change the address of a scratch disk in the
tower to correspond to the root's old address
- boot in maintenance mode (hpux -lm)
- notice that the maintenance flag is not
set in the BDRA (check 16kb at offset 128)
- notice that the BDRA was written to
the scratch disk (check 16kb at offset 128)
PHKL_6448:
LVM metadata I/O requests return erroneous "I/O error"
status and abort resynchronization when the device has
merely timed out or powefailed, but has not been marked
missing.
If a disk is powerfailed, LVM should poll for its return;
the problem is that certain LVM I/O requests did not check
for a mere powerfail condition, but always assumed that any
error indicated that the device was not worth waiting for.
The fix was to check if LVM had decided the device was
powerfailed vs truly missing, and not to abort if the
device was in a potentially temporary powerfail condition.
PHKL_6446:
On LVM, very large I/O requests -- on the order of 256k --
may not complete within LVM's time allotment. With large
logical volumes, the LVM metadata can easily get this large.
This can manifest itself as various errors in reading or
writing the VGDA/VGSA header or trailer, with messages to
the console and system log.
These timeouts can be due to an extremely busy I/O bus, a
multi-initiator environment, or a disk that places the
priority of small I/O requests over large ones. Systems
with Nike disk arrays have seen this particular problem.
The fix was to break down LVM metadata into a more palatable
size, 64k.
PHKL_6272:
HP-UX does not provide a mount option which will convert the
ISO-9660 filename from "FILENAME;VERSION" format to lower
case "filename" like most of the industry Unix platforms do.
PC's and non-HP clients cannot use the ISO-9660 CD-ROM
exported from a HP-UX NFS server because symbolic link, the
only work-around, is not available on these systems.
The fix adds two global kernel variables to the cdfs
operation to provide the filename convertion functionality.
These variables can be turned on and off using adb after the
patch is installed.
The kernel variables which need to be modified are:
cdfs_convert_case - Set this to 1 to display filenames
in lower case.
cdfs_zap_version - Set this to 1 to suppress version
number in filenames.
If you want the variables to be set in the kernel file
/stand/vmunix so the function remains after a system reboot,
type the following:
echo "cdfs_convert_case?W 1" | \
adb -w /stand/vmunix /dev/kmem
echo "cdfs_zap_version?W 1" | \
adb -w /stand/vmunix /dev/kmem
Or you can modify the memory only by typing:
echo "cdfs_convert_case/W 1" | \
adb -w /stand/vmunix /dev/kmem
echo "cdfs_zap_version/W 1" | \
adb -w /stand/vmunix /dev/kmem
PHKL_6081:
For NFS servers with large configurations, i.e for those
servers for which the tunable kernel parameter ninode has
been changed to be in thousands or in hundreds of thousands,
the performance of VxFS as the exported file system will not
be very good. Without this patch VxFS does not support the
hooks for glance.
PHKL_6024:
Due to a defect in the SDS migration code, the kernel was
computing the start of user data only when the data_psn
field in the LVM record was 0 (which is the default value
after running pvcreate). Not running pvcreate on an LVM
disc before re-using it meant using the start of user data
from previous disc usage, and thus causing data corruption
if the new LVM header was bigger than in previous disc
usage. Corruption can be prevented with the work-around of
always running pvcreate before re-using an LVM disc.
For 10.00, the patches PHKL_6022/s700 and PHKL_6023/s800
address also this defect.
The patch will prevent from creating situation where
the start of user data and the LVM header overlap.
Also, a test was added to the activation code to detect
discs which may have potential for data corruption, and a
warning is printing on the system console:
WARNING: The LVM header on the disc at 52.4.0 extends
beyond the start of user data, which therefore
has potential for data corruption.
Please consult the documentation for patch
PHKL_6025 (or any superceeding patch) for how
to reconfigure to fix this.
In the event you have a disk which is showing potential
for this problem, as detected by the patched PV activation
code, the procedure for correcting the problem (which must
be repeated for each individual disk) is as follows.
For this example, the disk which is showing problems is
/dev/dsk/c1t6d0, which is part of vg01:
If you have spare space available in your volume group (or
can make it available by adding a new disk to the volume
group), the procedure is simpler:
- Add the new disk to the volume group if needed (c1t3d0
in this example):
# pvcreate [-B] /dev/dsk/c1t3d0
# vgextend /dev/vg01 /dev/dsk/c1t3d0
- Move all logical extents to the new disk:
# pvmove /dev/dsk/c1t6d0 /dev/dsk/c1t3d0
The second argument here is optional, and is only needed
when you want to make sure all the extents go to the new
disk. Without it, the extents will be moved to the first
available free space elsewhere in the VG.
- Remove the affected disk from the VG, run pvcreate to
clear the data structures, then add it back to the VG.
# vgreduce /dev/vg01 /dev/dsk/c1t6d0
# pvcreate [-B] /dev/dsk/c1t6d0
# vgextend /dev/vg01 /dev/dsk/c1t6d0
- If you want to remove the new disk from the VG again,
you can do so now by reversing the pvmove process, and
removing it:
# pvmove /dev/dsk/c1t3d0 /dev/dsk/c1t6d0
# vgreduce /dev/vg01 /dev/dsk/c1t3d0
If you do not have spare disk space available, the procedure
is slighly more complicated, as you will need to backup and
restore all affected lvols:
- determine which logical volumes are affected:
# pvdisplay -v /dev/dsk/c1t6d0 | more
- Under the heading "- Distribution of physical volume -",
pvdisplay lists all of the logical volumes which are
using this disk. Stop all activity to these logical
volumes, shutting-down (or rebooting) to single-user
mode, if necessary.
- These lvols all need to be backed-up in their entirety,
then removed. For example, if this disk contains file
systems for the following:
/dev/vg01/lvol1 mounted as /fs1
/dev/vg01/lvol2 mounted as /home and
/dev/vg01/lvol3 mounted as /opt:
# fbackup -i /fs1 -i /home -i /opt \
-vf /dev/rmt/c1t0d0BEST
# lvremove /dev/vg01/lvol1
# lvremove /dev/vg01/lvol2
# lvremove /dev/vg01/lvol3
- Remove the affected disk from the VG, run pvcreate to
clear the data structures, then add it back to the VG.
# vgreduce /dev/vg01 /dev/dsk/c1t6d0
# pvcreate [-B] /dev/dsk/c1t6d0
# vgextend /dev/vg01 /dev/dsk/c1t6d0
- Recreate the logical volumes you removed previously,
including the lvols and their fileysystems as needed
(use SAM if you prefer).
# lvcreate -L <size in MB> -n lvol1 /dev/vg01
# lvcreate -L <size in MB> -n lvol2 /dev/vg01
# lvcreate -L <size in MB> -n lvol3 /dev/vg01
# newfs /dev/vg01/rlvol1
# newfs /dev/vg01/rlvol2
# newfs /dev/vg01/rlvol3
# mount -a
- Restore your data to these lvols, and you're back to
where you started, without the problem of potential
data corruption.
# frecover -rvf /dev/rmt/c1t0d0BEST
PHKL_5888:
When the BDRA or the boot file is removed from the boot
disk, user tried to boot system in LVM maintenance mode,
the boot ran a little while, then panic'ed with
vfs_MOUNTROOTS failed: NEED DRIVERS.
PHKL_5839:
lvreduce hung when reducing a bad disk from lvol.
PHKL_5813:
If there are entries in the mpd_array[] (i.e. there are
some bad memory cells) and if this system is not a T500,
K-Series or J-Series, some pages may be padded with junk
data in a coredump.
PHKL_5767:
The system hangs because most processes are swapped out
due to heavy load and the process which is the lead
candidate to be brought in needs a lot of pages much
more than freemem. So the swapper waits until freemem
is high enough for this process to be brought in
but since all the other processes which are swapped
out are not the lead candidate and there is no memory
pressure in the system the vhand does not
push out any more pages. This causes the whole
system to hang until something happes to disturb
this equilibrium point.
This can be reproduced by allocating a lot of
private memory mapped segments of atleast
33 pages each. By introducing heavy load
this process along with many other procces
are forced to be swapped out
This situation can lead to a hang.
PHKL_5737:
The defect is that the Secondary System Loader (hpux(1M))
is called with interrupts enabled. The Secondary System
Loader requires interrupts be disabled when it is called.
To reproduce this problem, keep rebooting your client
until it hangs. NOTE: Make sure you have the latest
firmware for your system.
PHKL_5663:
The vgchange -a r will fail when service guard cluster
services are present in the system. The read only activation
of the volume group fails when it has been activated in
exclusive mode. There is no workaround for this problem.
SR:
1653110189 1653136358 1653141945 1653144071 1653149054
1653150698 1653150938 1653161471 1653162297 1653162669
1653166041 1653166066 1653166983 1653170464 1653177899
1653178590 1653179895 1653180810 1653182501 1653186502
1653194555 1653200501 1653202754 1653216077 1653221820
1653227983 4701293480 4701295428 4701296657 4701297390
4701301721 4701304790 4701309070 4701314179 4701314302
4701315317 4701318352 4701320788 4701321711 4701329441
4701330647 4701334698 4701336412 4701337394 4701339945
4701346650 4701352278 4701355321 4701374975 5000697466
5000714352 5003268524 5003269464 5003276485 5003281469
5003285528 5003289496 5003294421 5003300400 5003306258
5003309385 5003311837 5003311928 5003317487 5003318667
5003323493 5003325506 5003330746 5003336214 5003336933
5003344184 5003348425 5003378968 5003382929
Patch Files:
/usr/conf/h/dnlc.h
/usr/conf/h/pstat.h
/usr/conf/lib/libcdfs.a(cdfs_vnops.o)
/usr/conf/lib/libhp-ux.a(file_sys.o)
/usr/conf/lib/libhp-ux.a(gio_lvl1.o)
/usr/conf/lib/libhp-ux.a(init_main.o)
/usr/conf/lib/libhp-ux.a(kern_exec.o)
/usr/conf/lib/libhp-ux.a(kern_kload.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(machdep.o)
/usr/conf/lib/libhp-ux.a(pm_config.o)
/usr/conf/lib/libhp-ux.a(pstat.o)
/usr/conf/lib/libhp-ux.a(scsi_c700.o)
/usr/conf/lib/libhp-ux.a(scsi_c720.o)
/usr/conf/lib/libhp-ux.a(scsi_ctl.o)
/usr/conf/lib/libhp-ux.a(scsi_disk.o)
/usr/conf/lib/libhp-ux.a(scsi_floppy.o)
/usr/conf/lib/libhp-ux.a(subr_prf.o)
/usr/conf/lib/libhp-ux.a(sys_ki.o)
/usr/conf/lib/libhp-ux.a(ufs_dsort.o)
/usr/conf/lib/libhp-ux.a(vfs_dnlc.o)
/usr/conf/lib/libhp-ux.a(vfs_vm.o)
/usr/conf/lib/libhp-ux.a(vm_machdep.o)
/usr/conf/lib/libhp-ux.a(vm_sched.o)
/usr/conf/lib/libhp-ux.a(vm_swp.o)
/usr/conf/lib/libhp-ux.a(vm_vfd.o)
/usr/conf/lib/libhp-ux.a(vm_vhand.o)
/usr/conf/lib/libhp-ux.a(vxfs.o)
/usr/conf/lib/libhp-ux.a(wsio_scsi.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_strategy.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/libufs.a(ufs_dir.o)
/usr/conf/lib/libufs.a(ufs_vnops.o)
/usr/conf/lib/libvxfs_adv.a(vx_dio.o)
/usr/conf/lib/libvxfs_adv.a(vx_dirsort.o)
/usr/conf/lib/libvxfs_adv.a(vx_full.o)
/usr/conf/lib/libvxfs_adv.a(vx_reorg.o)
/usr/conf/lib/libvxfs_adv.a(vx_snap.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_bio1.o)
/usr/conf/lib/libvxfs_base.a(vx_bitmaps.o)
/usr/conf/lib/libvxfs_base.a(vx_bmap.o)
/usr/conf/lib/libvxfs_base.a(vx_bsdquota.o)
/usr/conf/lib/libvxfs_base.a(vx_chain.o)
/usr/conf/lib/libvxfs_base.a(vx_config.o)
/usr/conf/lib/libvxfs_base.a(vx_dira.o)
/usr/conf/lib/libvxfs_base.a(vx_dirl.o)
/usr/conf/lib/libvxfs_base.a(vx_dirop.o)
/usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o)
/usr/conf/lib/libvxfs_base.a(vx_ialloc.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_kernrdwri.o)
/usr/conf/lib/libvxfs_base.a(vx_lct.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_message.o)
/usr/conf/lib/libvxfs_base.a(vx_mount.o)
/usr/conf/lib/libvxfs_base.a(vx_olt.o)
/usr/conf/lib/libvxfs_base.a(vx_oltmount.o)
/usr/conf/lib/libvxfs_base.a(vx_quota.o)
/usr/conf/lib/libvxfs_base.a(vx_rdwri.o)
/usr/conf/lib/libvxfs_base.a(vx_resize.o)
/usr/conf/lib/libvxfs_base.a(vx_swap.o)
/usr/conf/lib/libvxfs_base.a(vx_ted.o)
/usr/conf/lib/libvxfs_base.a(vx_tran.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/master.d/core-hpux
/usr/conf/space.h.d/core-hpux.h
/usr/include/sys/dnlc.h
/usr/include/sys/fs/vx_inode.h
/usr/include/sys/pstat.h
what(1) Output:
/usr/conf/h/dnlc.h:
dnlc.h $Date: 95/10/10 13:40:56 $ $Revision:
1.3.71.5 $ PATCH_10.01 (PHKL_6081)
/usr/conf/h/pstat.h:
pstat.h $Date: 95/12/14 15:28:37 $ $Revision: 1.8.71
.25 $ PATCH_10.01 (PHKL_6529)
/usr/conf/lib/libcdfs.a(cdfs_vnops.o):
cdfs_vnops.c $Date: 95/11/02 15:00:30 $ $Revision:
1.10.72.28 $ PATCH_10.01 (PHKL_6272)
/usr/conf/lib/libhp-ux.a(file_sys.o):
file_sys.c $Date: 95/09/28 17:51:26 $ $Revision:
1.2.71.4 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libhp-ux.a(gio_lvl1.o):
gio_lvl1.c $Date: 95/07/05 10:16:54 $ $Revision:
1.2.71.15 $ PATCH_10.01 (PHKL_5737)
/usr/conf/lib/libhp-ux.a(init_main.o):
init_main.c $Date: 97/06/26 16:32:26 $ $Revision:
1.114.72.74 $ PATCH_10.01 (PHKL_11563)
/usr/conf/lib/libhp-ux.a(kern_exec.o):
kern_exec.c $Date: 97/09/03 16:10:26 $ $Revision:
1.88.72.45 $ PATCH_10.01 (PHKL_12395)
/usr/conf/lib/libhp-ux.a(kern_kload.o):
kern_kload.c $Date: 96/04/17 16:45:51 $ $Revision:
1.2.71.6 $ PATCH_10.01 (PHKL_7306)
/usr/conf/lib/libhp-ux.a(lv_config.o):
lv_config.c $Date: 96/09/03 18:02:17 $ $Revision: 1.
6.71.27 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/libhp-ux.a(lv_lvm.o):
lv_lvm.c $Date: 96/09/03 18:07:43 $ $Revision: 1.2
.71.2 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/libhp-ux.a(machdep.o):
machdep.c $Date: 96/08/06 15:46:31 $ $Revision: 1.11
8.72.44 $ PATCH_10.01 (PHKL_8199)
/usr/conf/lib/libhp-ux.a(pm_config.o):
pm_config.c $Date: 97/06/26 16:32:49 $ $Revision:
1.2.71.17 $ PATCH_10.01 (PHKL_11563)
/usr/conf/lib/libhp-ux.a(pstat.o):
pstat.c $Date: 97/09/03 16:28:30 $ $Revision: 1.13.7
2.52 $ PATCH_10.01 (PHKL_12395)
/usr/conf/lib/libhp-ux.a(scsi_c700.o):
scsi_c700.c $Date: 96/08/05 08:29:58 $ $Revision:
1.2.72.46 $ PATCH_10.01 (PHKL_7827)
/usr/conf/lib/libhp-ux.a(scsi_c720.o):
scsi_c720.c $Date: 96/11/28 21:35:10 $ $Revision:
1.2.71.33 $ PATCH_10.01 (PHKL_8904)
/usr/conf/lib/libhp-ux.a(scsi_ctl.o):
scsi_ctl.c $Date: 97/11/14 14:32:11 $ $Revision:
1.2.72.72 $ PATCH_10.01 (PHKL_13232)
/usr/conf/lib/libhp-ux.a(scsi_disk.o):
scsi_disk.c $Date: 96/11/25 13:00:25 $ $Revision:
1.2.72.44 $ PATCH_10.01 (PHKL_8904)
/usr/conf/lib/libhp-ux.a(scsi_floppy.o):
scsi_floppy.c $Date: 96/07/02 06:39:02 $ $Revision:
1.2.72.12 $ PATCH_10.01 (PHKL_7827)
/usr/conf/lib/libhp-ux.a(subr_prf.o):
subr_prf.c $Date: 97/02/12 10:35:59 $ $Revision: 1.6
1.72.30 $ PATCH_10.01 (PHKL_10101)
/usr/conf/lib/libhp-ux.a(sys_ki.o):
sys_ki.c $Date: 97/07/03 17:02:39 $ $Revision: 1.13.
72.63 $ PATCH_10.01 (PHKL_11670)
/usr/conf/lib/libhp-ux.a(ufs_dsort.o):
ufs_dsort.c $Date: 97/09/23 21:37:22 $ $Revision:
1.15.72.26 $ PATCH_10.01 (PHKL_12604)
/usr/conf/lib/libhp-ux.a(vfs_dnlc.o):
vfs_dnlc.c $Date: 95/09/28 16:35:26 $ $Revision:
1.13.72.15 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libhp-ux.a(vfs_vm.o):
vfs_vm.c $Date: 97/06/27 16:51:43 $ $Revision:
1.11.72.32 $ PATCH_10.01 (PHKL_11242)
/usr/conf/lib/libhp-ux.a(vm_machdep.o):
vm_machdep.c $Date: 95/12/14 14:00:25 $ $Revision:
1.150.72.101 $ PATCH_10.01 (PHKL_6529)
/usr/conf/lib/libhp-ux.a(vm_sched.o):
vm_sched.c $Date: 97/06/26 16:35:13 $ $Revision:
1.53.72.43 $ PATCH_10.01 (PHKL_11563)
/usr/conf/lib/libhp-ux.a(vm_swp.o):
vm_swp.c $Date: 96/02/21 09:35:11 $ $Revision:
1.44.72.35 $ PATCH_10.01 (PHKL_6888)
/usr/conf/lib/libhp-ux.a(vm_vfd.o):
vm_vfd.c $Date: 95/11/08 18:19:46 $ $Revision:
1.12.72.17 $ PATCH_10.01 (PHKL_5767)
/usr/conf/lib/libhp-ux.a(vm_vhand.o):
vm_vhand.c $Date: 97/08/14 11:05:17 $ $Revision:
1.15.72.31 $ PATCH_10.01 (PHKL_12153)
/usr/conf/lib/libhp-ux.a(vxfs.o):
vxfs.c $Date: 96/04/02 12:34:56 $ $Revision:
1.2.71.2 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libhp-ux.a(wsio_scsi.o):
wsio_scsi.c $Date: 96/11/25 13:30:55 $ $Revision:
1.2.71.5 $ PATCH_10.01 (PHKL_8904)
/usr/conf/lib/liblvm.a(lv_block.o):
lv_block.c $Date: 96/09/03 17:11:04 $ $Revision: 1
.6.71.5 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_cluster_lock.o):
lv_cluster_lock.c $Date: 97/03/03 08:49:36 $ $Revi
sion: 1.2.71.15 $ PATCH_10.01 (PHKL_10281)
/usr/conf/lib/liblvm.a(lv_defect.o):
lv_defect.c $Date: 96/09/03 18:02:21 $ $Revision: 1.
6.71.25 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_hp.o):
lv_hp.c $Date: 96/09/03 18:02:24 $ $Revision: 1.6.71
.56 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_ioctls.o):
lv_ioctls.c $Date: 97/03/03 08:40:51 $ $Revision:
1.6.71.46 $ PATCH_10.01 (PHKL_10281)
/usr/conf/lib/liblvm.a(lv_kdb.o):
lv_kdb.c $Date: 96/09/03 18:02:30 $ $Revision: 1.4
.71.4 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_lvsubr.o):
lv_lvsubr.c $Date: 97/06/06 13:33:50 $ $Revision:
1.6.71.23 $ PATCH_10.01 (PHKL_11293)
/usr/conf/lib/liblvm.a(lv_malloc.o):
lv_malloc.c $Date: 96/09/03 18:02:35 $ $Revision:
1.6.71.4 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_mircons.o):
lv_mircons.c $Date: 96/09/03 18:02:38 $ $Revision: 1
.6.71.19 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_pbuf.o):
lv_pbuf.c $Date: 96/09/03 18:02:40 $ $Revision: 1.
6.71.6 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_phys.o):
lv_phys.c $Date: 97/06/06 13:38:05 $ $Revision: 1.6.
71.20 $ PATCH_10.01 (PHKL_11293)
/usr/conf/lib/liblvm.a(lv_schedule.o):
lv_schedule.c $Date: 96/09/03 18:02:45 $ $Revision:
1.6.71.31 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_strategy.o):
lv_strategy.c $Date: 96/09/03 18:02:48 $ $Revision:
1.6.71.14 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_subr.o):
lv_subr.c $Date: 97/03/03 08:40:45 $ $Revision:
1.6.71.27 $ PATCH_10.01 (PHKL_10281)
/usr/conf/lib/liblvm.a(lv_syscalls.o):
lv_syscalls.c $Date: 96/09/03 18:02:53 $ $Revision:
1.6.71.22 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_vgda.o):
lv_vgda.c $Date: 96/09/03 18:02:55 $ $Revision: 1.
6.71.12 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/liblvm.a(lv_vgsa.o):
lv_vgsa.c $Date: 96/09/03 18:02:57 $ $Revision: 1.
6.71.14 $ PATCH_10.01 (PHKL_8391)
/usr/conf/lib/libufs.a(ufs_dir.o):
ufs_dir.c $Date: 96/10/24 11:22:22 $ $Revision:
1.15.72.31 $ PATCH_10.01 (PHKL_8757)
/usr/conf/lib/libufs.a(ufs_vnops.o):
ufs_vnops.c $Date: 96/03/28 09:00:06 $ $Revision:
1.22.72.83 $ PATCH_10.01 (PHKL_7122)
/usr/conf/lib/libvxfs_adv.a(vx_dio.o):
vx_dio.c $Date: 96/12/04 08:34:27 $ $Revision:
1.2.71.16 $ PATCH_10.01 (PHKL_9404)
/usr/conf/lib/libvxfs_adv.a(vx_dirsort.o):
vx_dirsort.c $Date: 95/09/28 16:50:29 $ $Revision:
1.2.71.7 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_adv.a(vx_full.o):
vx_full.c $Date: 95/09/28 16:50:31 $ $Revision:
1.2.71.13 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_adv.a(vx_reorg.o):
vx_reorg.c $Date: 97/09/23 21:40:14 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_12604)
/usr/conf/lib/libvxfs_adv.a(vx_snap.o):
vx_snap.c $Date: 97/06/02 17:14:21 $ $Revision:
1.2.71.12 $ PATCH_10.01 (PHKL_11206)
/usr/conf/lib/libvxfs_base.a(vx_alloc.o):
vx_alloc.c $Date: 95/09/28 16:43:28 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_attr.o):
vx_attr.c $Date: 95/09/28 16:49:56 $ $Revision:
1.2.71.11 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_bio.o):
vx_bio.c $Date: 95/09/28 16:50:02 $ $Revision:
1.2.71.15 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_bio1.o):
vx_bio1.c $Date: 96/05/29 18:22:41 $ $Revision:
1.2.71.17 $ PATCH_10.01 (PHKL_7578)
/usr/conf/lib/libvxfs_base.a(vx_bitmaps.o):
vx_bitmaps.c $Date: 95/09/28 16:50:06 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_bmap.o):
vx_bmap.c $Date: 95/09/28 16:50:09 $ $Revision:
1.2.71.8 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_bsdquota.o):
vx_bsdquota.c $Date: 97/09/15 11:23:32 $ $Revision:
1.2.71.19 $ PATCH_10.01 (PHKL_12561)
/usr/conf/lib/libvxfs_base.a(vx_chain.o):
vx_chain.c $Date: 95/09/28 16:50:16 $ $Revision:
1.2.71.16 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_config.o):
vx_config.c $Date: 95/09/28 16:50:19 $ $Revision:
1.2.71.14 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_dira.o):
vx_dira.c $Date: 95/09/28 16:50:23 $ $Revision:
1.2.71.8 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_dirl.o):
vx_dirl.c $Date: 96/05/15 13:04:00 $ $Revision:
1.2.71.12 $ PATCH_10.01 (PHKL_7508)
/usr/conf/lib/libvxfs_base.a(vx_dirop.o):
vx_dirop.c $Date: 97/09/23 12:56:55 $ $Revision:
1.2.71.11 $ PATCH_10.01 (PHKL_12653)
/usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o):
vx_hpuxsubr.c $Date: 95/09/28 16:50:34 $ $Revision:
1.2.71.16 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_ialloc.o):
vx_ialloc.c $Date: 97/07/21 10:33:44 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_11889)
/usr/conf/lib/libvxfs_base.a(vx_iflush.o):
vx_iflush.c $Date: 96/08/02 13:19:32 $ $Revision:
1.2.71.14 $ PATCH_10.01 (PHKL_7901)
/usr/conf/lib/libvxfs_base.a(vx_inode.o):
vx_inode.c $Date: 96/08/02 13:19:33 $ $Revision:
1.2.71.21 $ PATCH_10.01 (PHKL_7901)
/usr/conf/lib/libvxfs_base.a(vx_itrunc.o):
vx_itrunc.c $Date: 95/09/28 16:50:43 $ $Revision:
1.2.71.12 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_kernrdwri.o):
vx_kernrdwri.c $Date: 95/09/28 16:50:45 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_lct.o):
vx_lct.c $Date: 95/09/28 16:50:48 $ $Revision:
1.2.71.7 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_lite.o):
vx_lite.c $Date: 95/09/28 16:50:50 $ $Revision:
1.2.71.11 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_log.o):
vx_log.c $Date: 95/09/28 16:50:52 $ $Revision:
1.2.71.9 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_message.o):
vx_message.c $Date: 95/09/28 16:50:54 $ $Revision:
1.2.71.7 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_mount.o):
vx_mount.c $Date: 96/05/15 13:11:37 $ $Revision:
1.2.71.17 $ PATCH_10.01 (PHKL_7508)
/usr/conf/lib/libvxfs_base.a(vx_olt.o):
vx_olt.c $Date: 95/09/28 16:50:58 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_oltmount.o):
vx_oltmount.c $Date: 95/09/28 16:51:01 $ $Revision:
1.2.71.8 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_quota.o):
vx_quota.c $Date: 95/09/28 16:51:03 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_rdwri.o):
vx_rdwri.c $Date: 96/08/02 13:19:35 $ $Revision:
1.2.71.23 $ PATCH_10.01 (PHKL_7901)
/usr/conf/lib/libvxfs_base.a(vx_resize.o):
vx_resize.c $Date: 95/09/28 16:51:10 $ $Revision:
1.2.71.7 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_swap.o):
vx_swap.c $Date: 95/09/28 16:51:14 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_ted.o):
vx_ted.c $Date: 95/09/28 16:51:16 $ $Revision:
1.2.71.11 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_tran.o):
vx_tran.c $Date: 95/09/28 16:51:19 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_vfsops.o):
vx_vfsops.c $Date: 95/09/28 16:51:21 $ $Revision:
1.2.71.21 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_base.a(vx_vm.o):
vx_vm.c $Date: 97/03/20 17:53:26 $ $Revision:
1.2.71.22 $ PATCH_10.01 (PHKL_10136)
/usr/conf/lib/libvxfs_base.a(vx_vnops.o):
vx_vnops.c $Date: 97/09/23 12:57:54 $ $Revision:
1.2.71.25 $ PATCH_10.01 (PHKL_12653)
/usr/conf/master.d/core-hpux:
core-hpux $Date: 97/06/26 16:29:21 $ $Revision: 1.1.
71.54 $ PATCH_10.01 (PHKL_11563)
/usr/conf/space.h.d/core-hpux.h:
core-hpux.h: $Date: 97/06/26 16:30:34 $ $Revision: 1
.2.71.23 $ PATCH_10.01 (PHKL_11563)
/usr/include/sys/dnlc.h:
dnlc.h $Date: 95/10/10 13:40:56 $ $Revision:
1.3.71.5 $ PATCH_10.01 (PHKL_6081)
/usr/include/sys/fs/vx_inode.h:
vx_inode.h: $Revision: 1.2.71.13 $ $Date: 95/10/10 1
3:50:57 $
vx_inode.h $Date: 95/10/10 13:50:57 $ $Revision:
1.2.71.13 $ PATCH_10.01 (PHKL_6081)
src/kernel/vxfs/vx_inode.h 1.28 16 Dec 1994 02:02:01
- */
fshp:src/kernel/vxfs/vx_inode.h 1.28
/usr/include/sys/pstat.h:
pstat.h $Date: 95/12/14 15:28:37 $ $Revision: 1.8.71
.25 $ PATCH_10.01 (PHKL_6529)
cksum(1) Output:
1433825073 1736 /usr/conf/h/dnlc.h
3808513632 30467 /usr/conf/h/pstat.h
3075405600 15512 /usr/conf/lib/libcdfs.a(cdfs_vnops.o)
3551827826 132480 /usr/conf/lib/libhp-ux.a(file_sys.o)
2936849315 7832 /usr/conf/lib/libhp-ux.a(gio_lvl1.o)
30605567 17264 /usr/conf/lib/libhp-ux.a(init_main.o)
3598812146 16280 /usr/conf/lib/libhp-ux.a(kern_exec.o)
3500569250 6304 /usr/conf/lib/libhp-ux.a(kern_kload.o)
2796310244 26456 /usr/conf/lib/libhp-ux.a(lv_config.o)
2101489711 118100 /usr/conf/lib/libhp-ux.a(lv_lvm.o)
414414286 22932 /usr/conf/lib/libhp-ux.a(machdep.o)
2749752799 5724 /usr/conf/lib/libhp-ux.a(pm_config.o)
4205689870 22456 /usr/conf/lib/libhp-ux.a(pstat.o)
3565433618 116100 /usr/conf/lib/libhp-ux.a(scsi_c700.o)
4273961963 78848 /usr/conf/lib/libhp-ux.a(scsi_c720.o)
3981349643 69020 /usr/conf/lib/libhp-ux.a(scsi_ctl.o)
2632648654 16576 /usr/conf/lib/libhp-ux.a(scsi_disk.o)
2031639538 22172 /usr/conf/lib/libhp-ux.a(scsi_floppy.o)
4092521779 15904 /usr/conf/lib/libhp-ux.a(subr_prf.o)
4145372864 50876 /usr/conf/lib/libhp-ux.a(sys_ki.o)
1493949319 8120 /usr/conf/lib/libhp-ux.a(ufs_dsort.o)
2999147290 8536 /usr/conf/lib/libhp-ux.a(vfs_dnlc.o)
117738785 28240 /usr/conf/lib/libhp-ux.a(vfs_vm.o)
3900460760 74852 /usr/conf/lib/libhp-ux.a(vm_machdep.o)
3733035569 19728 /usr/conf/lib/libhp-ux.a(vm_sched.o)
884770181 7188 /usr/conf/lib/libhp-ux.a(vm_swp.o)
2269409180 13744 /usr/conf/lib/libhp-ux.a(vm_vfd.o)
1710210739 15316 /usr/conf/lib/libhp-ux.a(vm_vhand.o)
3071564967 186476 /usr/conf/lib/libhp-ux.a(vxfs.o)
2074771811 147136 /usr/conf/lib/libhp-ux.a(wsio_scsi.o)
4109240189 2240 /usr/conf/lib/liblvm.a(lv_block.o)
3842548525 9744 /usr/conf/lib/liblvm.a(lv_cluster_lock.o)
1235760520 11316 /usr/conf/lib/liblvm.a(lv_defect.o)
1194497640 36824 /usr/conf/lib/liblvm.a(lv_hp.o)
2454298857 21356 /usr/conf/lib/liblvm.a(lv_ioctls.o)
493308582 580 /usr/conf/lib/liblvm.a(lv_kdb.o)
3115921151 20012 /usr/conf/lib/liblvm.a(lv_lvsubr.o)
4203311357 1736 /usr/conf/lib/liblvm.a(lv_malloc.o)
3452571591 17144 /usr/conf/lib/liblvm.a(lv_mircons.o)
1929642907 5712 /usr/conf/lib/liblvm.a(lv_pbuf.o)
39928899 4932 /usr/conf/lib/liblvm.a(lv_phys.o)
461176533 18112 /usr/conf/lib/liblvm.a(lv_schedule.o)
3767986990 6860 /usr/conf/lib/liblvm.a(lv_strategy.o)
1855237486 7292 /usr/conf/lib/liblvm.a(lv_subr.o)
950678520 10072 /usr/conf/lib/liblvm.a(lv_syscalls.o)
2201444731 8216 /usr/conf/lib/liblvm.a(lv_vgda.o)
4230095236 11228 /usr/conf/lib/liblvm.a(lv_vgsa.o)
2103952855 18684 /usr/conf/lib/libufs.a(ufs_dir.o)
3394419873 29280 /usr/conf/lib/libufs.a(ufs_vnops.o)
2582274222 9292 /usr/conf/lib/libvxfs_adv.a(vx_dio.o)
2373645564 6904 /usr/conf/lib/libvxfs_adv.a(vx_dirsort.o)
947372995 13316 /usr/conf/lib/libvxfs_adv.a(vx_full.o)
1366419528 16852 /usr/conf/lib/libvxfs_adv.a(vx_reorg.o)
269209605 9608 /usr/conf/lib/libvxfs_adv.a(vx_snap.o)
1661647864 19092 /usr/conf/lib/libvxfs_base.a(vx_alloc.o)
3066601346 32492 /usr/conf/lib/libvxfs_base.a(vx_attr.o)
3917596612 9576 /usr/conf/lib/libvxfs_base.a(vx_bio.o)
3342111436 4500 /usr/conf/lib/libvxfs_base.a(vx_bio1.o)
2538577070 11960 /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o)
3876620801 10056 /usr/conf/lib/libvxfs_base.a(vx_bmap.o)
2122906447 26456 /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o)
869082722 4620 /usr/conf/lib/libvxfs_base.a(vx_chain.o)
908452954 7356 /usr/conf/lib/libvxfs_base.a(vx_config.o)
773486446 9732 /usr/conf/lib/libvxfs_base.a(vx_dira.o)
2530552644 8256 /usr/conf/lib/libvxfs_base.a(vx_dirl.o)
4060745760 7300 /usr/conf/lib/libvxfs_base.a(vx_dirop.o)
1180476710 13268 /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o)
2449416109 9528 /usr/conf/lib/libvxfs_base.a(vx_ialloc.o)
1315438458 26812 /usr/conf/lib/libvxfs_base.a(vx_iflush.o)
925777145 37536 /usr/conf/lib/libvxfs_base.a(vx_inode.o)
1983630867 10284 /usr/conf/lib/libvxfs_base.a(vx_itrunc.o)
3273714044 2000 /usr/conf/lib/libvxfs_base.a(vx_kernrdwri.o)
478210606 8032 /usr/conf/lib/libvxfs_base.a(vx_lct.o)
2013482013 3000 /usr/conf/lib/libvxfs_base.a(vx_lite.o)
828174554 9996 /usr/conf/lib/libvxfs_base.a(vx_log.o)
2336753589 6864 /usr/conf/lib/libvxfs_base.a(vx_message.o)
3365525404 19132 /usr/conf/lib/libvxfs_base.a(vx_mount.o)
2575180562 20420 /usr/conf/lib/libvxfs_base.a(vx_olt.o)
3187180947 10724 /usr/conf/lib/libvxfs_base.a(vx_oltmount.o)
1958668699 9656 /usr/conf/lib/libvxfs_base.a(vx_quota.o)
3080436405 25880 /usr/conf/lib/libvxfs_base.a(vx_rdwri.o)
2060980719 5920 /usr/conf/lib/libvxfs_base.a(vx_resize.o)
3589907876 2740 /usr/conf/lib/libvxfs_base.a(vx_swap.o)
4116283683 584 /usr/conf/lib/libvxfs_base.a(vx_ted.o)
1908809738 17592 /usr/conf/lib/libvxfs_base.a(vx_tran.o)
4266163946 13500 /usr/conf/lib/libvxfs_base.a(vx_vfsops.o)
44877669 10384 /usr/conf/lib/libvxfs_base.a(vx_vm.o)
2999652835 23332 /usr/conf/lib/libvxfs_base.a(vx_vnops.o)
87808404 16461 /usr/conf/master.d/core-hpux
2334888252 19091 /usr/conf/space.h.d/core-hpux.h
1433825073 1736 /usr/include/sys/dnlc.h
4176674158 39668 /usr/include/sys/fs/vx_inode.h
3808513632 30467 /usr/include/sys/pstat.h
Patch Conflicts: None
Patch Dependencies:
s700: 10.01: PHCO_8458
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHKL_5663 PHKL_5737 PHKL_5767 PHKL_5813 PHKL_5839 PHKL_5888
PHKL_6024 PHKL_6027 PHKL_6081 PHKL_6272 PHKL_6446 PHKL_6448
PHKL_6462 PHKL_6494 PHKL_6529 PHKL_6547 PHKL_6674 PHKL_6764
PHKL_6792 PHKL_6888 PHKL_6951 PHKL_6987 PHKL_7015 PHKL_7024
PHKL_7037 PHKL_7122 PHKL_7185 PHKL_7205 PHKL_7217 PHKL_7250
PHKL_7306 PHKL_7357 PHKL_7508 PHKL_7578 PHKL_7666 PHKL_7827
PHKL_7846 PHKL_7901 PHKL_7908 PHKL_8024 PHKL_8080 PHKL_8199
PHKL_8282 PHKL_8361 PHKL_8386 PHKL_8391 PHKL_8580 PHKL_8602
PHKL_8731 PHKL_8757 PHKL_8904 PHKL_9263 PHKL_9404 PHKL_9565
PHKL_9707 PHKL_10101 PHKL_10136 PHKL_10281 PHKL_11206 PHKL_11242
PHKL_11293 PHKL_11563 PHKL_11670 PHKL_11889 PHKL_12153 PHKL_12395
PHKL_12561 PHKL_12604 PHKL_12653
Equivalent Patches: None
Patch Package Size: 2230 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_13232
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHKL_13232.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_13232.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_13232. 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_13232.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_13232.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
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 sysytem 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.
---
If you are planning to install the advanced VxFS product
(AdvJournalFS.VXFS-ADV-KRN), it is imperative that this
patch and all other VxFS patches be removed from the system,
via swremove, before the actual product installation. After
the installation of the advanced VxFS product has completed,
this patch can be re-installed. All patches listed in the
Supersedes field are subject to this behavior, and need to
be removed before installing the advanced VxFS product, with
the exception of PHKL_7847 PHKL_7307 PHKL_7218 PHKL_7038
PHKL_6449 PHKL_6025 PHKL_5889 PHKL_5840 PHKL_5814 PHKL_5739
PHKL_5662.
---
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.