Patch Name: PHKL_9707
Patch Description: s700 10.01 JFS, LVM, UFS, pstat cumulative patch
Creation Date: 97/01/15
Post Date: 97/01/26
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
ProgSupport.C-INC
Automatic Reboot?: Yes
Status: General Superseded
Critical:
No (superseded patches were critical)
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_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_5737: HANG
Path Name: /hp-ux_patches/s700/10.X/PHKL_9707
Symptoms:
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_8580:
After call to pstat_getmsg(), all accesses to the message
queue pstat_getmsg() was called hang.
PHKL_8602:
trap 15 panic in pstat_fileinfo()
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_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_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_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_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_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_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.30.
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_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_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 1653150698
1653150938 1653161471 1653162297 1653162669 1653166041
1653166066 1653166983 1653170464 1653178590 1653180810
1653182501 1653186502 1653194555 4701293480 4701295428
4701296657 4701297390 4701304790 4701309070 4701314179
4701314302 4701315317 4701318352 4701320788 4701329441
4701330647 4701334698 4701336412 5000697466 5000714352
5003268524 5003276485 5003281469 5003285528 5003289496
5003294421 5003306258 5003309385 5003311837 5003317487
5003318667 5003323493 5003325506 5003336214 5003336933
5003344184 5003348425
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(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(subr_prf.o)
/usr/conf/lib/libhp-ux.a(sys_ki.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_swp.o)
/usr/conf/lib/libhp-ux.a(vxfs.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/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(kern_exec.o):
kern_exec.c $Date: 96/08/13 10:58:03 $ $Revision:
1.88.72.43 $ PATCH_10.01 (PHKL_8282)
/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: 96/08/13 11:00:41 $ $Revision:
1.2.71.16 $ PATCH_10.01 (PHKL_8282)
/usr/conf/lib/libhp-ux.a(pstat.o):
pstat.c $Date: 96/09/26 15:12:11 $ $Revision: 1.13.7
2.51 $ PATCH_10.01 (PHKL_8580)
/usr/conf/lib/libhp-ux.a(subr_prf.o):
subr_prf.c $Date: 95/12/14 13:58:05 $ $Revision: 1.6
1.72.29 $ PATCH_10.01 (PHKL_6529)
/usr/conf/lib/libhp-ux.a(sys_ki.o):
sys_ki.c $Date: 95/12/14 13:58:32 $ $Revision: 1.13.
72.62 $ PATCH_10.01 (PHKL_6529)
/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: 96/02/21 09:35:16 $ $Revision:
1.11.72.31 $ PATCH_10.01 (PHKL_6888)
/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_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(vxfs.o):
vxfs.c $Date: 96/04/02 12:34:56 $ $Revision:
1.2.71.2 $ PATCH_10.01 (PHKL_6081)
/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: 96/09/03 18:02:11 $ $Revi
sion: 1.2.71.12 $ PATCH_10.01 (PHKL_8391)
/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: 96/09/03 18:02:27 $ $Revision:
1.6.71.45 $ PATCH_10.01 (PHKL_8391)
/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: 96/09/03 18:02:32 $ $Revision:
1.6.71.22 $ PATCH_10.01 (PHKL_8391)
/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: 96/09/03 18:02:43 $ $Revision: 1.6.
71.19 $ PATCH_10.01 (PHKL_8391)
/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: 96/09/03 18:02:50 $ $Revision:
1.6.71.26 $ PATCH_10.01 (PHKL_8391)
/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: 95/09/28 16:51:08 $ $Revision:
1.2.71.9 $ PATCH_10.01 (PHKL_6081)
/usr/conf/lib/libvxfs_adv.a(vx_snap.o):
vx_snap.c $Date: 95/09/28 16:51:12 $ $Revision:
1.2.71.11 $ PATCH_10.01 (PHKL_6081)
/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/01/14 15:03:24 $ $Revision:
1.2.71.18 $ PATCH_10.01 (PHKL_9707)
/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: 95/09/28 16:50:27 $ $Revision:
1.2.71.10 $ PATCH_10.01 (PHKL_6081)
/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: 95/09/28 16:50:36 $ $Revision:
1.2.71.9 $ PATCH_10.01 (PHKL_6081)
/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: 96/11/18 14:21:09 $ $Revision:
1.2.71.21 $ PATCH_10.01 (PHKL_9263)
/usr/conf/lib/libvxfs_base.a(vx_vnops.o):
vx_vnops.c $Date: 96/12/20 15:19:43 $ $Revision:
1.2.71.24 $ PATCH_10.01 (PHKL_9565)
/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)
3336419585 16328 /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)
920064525 5628 /usr/conf/lib/libhp-ux.a(pm_config.o)
3530051992 22388 /usr/conf/lib/libhp-ux.a(pstat.o)
417619664 15880 /usr/conf/lib/libhp-ux.a(subr_prf.o)
3695960620 50904 /usr/conf/lib/libhp-ux.a(sys_ki.o)
2999147290 8536 /usr/conf/lib/libhp-ux.a(vfs_dnlc.o)
1593660871 28276 /usr/conf/lib/libhp-ux.a(vfs_vm.o)
3900460760 74852 /usr/conf/lib/libhp-ux.a(vm_machdep.o)
884770181 7188 /usr/conf/lib/libhp-ux.a(vm_swp.o)
3071564967 186476 /usr/conf/lib/libhp-ux.a(vxfs.o)
4109240189 2240 /usr/conf/lib/liblvm.a(lv_block.o)
3894381727 9600 /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)
3611755561 21204 /usr/conf/lib/liblvm.a(lv_ioctls.o)
493308582 580 /usr/conf/lib/liblvm.a(lv_kdb.o)
1113054594 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)
2993994076 4920 /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)
2982738768 6944 /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)
2593909221 16836 /usr/conf/lib/libvxfs_adv.a(vx_reorg.o)
2700406447 9544 /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)
4124590141 26452 /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)
1844114972 7256 /usr/conf/lib/libvxfs_base.a(vx_dirop.o)
1180476710 13268 /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o)
2401657086 9592 /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)
2261395020 10328 /usr/conf/lib/libvxfs_base.a(vx_vm.o)
1862032893 23252 /usr/conf/lib/libvxfs_base.a(vx_vnops.o)
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_5813 PHKL_5839 PHKL_5888 PHKL_6024
PHKL_6081 PHKL_6272 PHKL_6446 PHKL_6448 PHKL_6462 PHKL_6494
PHKL_6529 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_7508 PHKL_7578
PHKL_7666 PHKL_7846 PHKL_7901 PHKL_7908 PHKL_8024 PHKL_8080
PHKL_8199 PHKL_8282 PHKL_8386 PHKL_8391 PHKL_8580 PHKL_8602
PHKL_8731 PHKL_8757 PHKL_9263 PHKL_9404 PHKL_9565
Equivalent Patches:
PHKL_9708:
s800: 10.01
PHKL_9709:
s700: 10.10
PHKL_9710:
s800: 10.10
PHKL_9711:
s700: 10.20
PHKL_9712:
s800: 10.20
Patch Package Size: 1700 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_9707
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHKL_9707.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_9707.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_9707. 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_9707.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_9707.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
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.
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 this patch, with the exception
of PHKL_7846 PHKL_7306 PHKL_7217 PHKL_7037 PHKL_6448
PHKL_6024 PHKL_5888 PHKL_5839 PHKL_5813 PHKL_5737 PHKL_5663.