Patch Name: PHKL_12901 Patch Description: s700 10.20 cache, PM, VM, LVM, VxFS, UFS cumulative patch Creation Date: 97/10/20 Post Date: 97/10/24 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: AdvJournalFS.VXFS-ADV-KRN JournalFS.VXFS-BASE-KRN JournalFS.VXFS-PRG LVM.LVM-KRN OS-Core.CORE-KRN OS-Core.KERN-RUN ProgSupport.C-INC Automatic Reboot?: Yes Status: General Superseded Critical: Yes PHKL_12901: PANIC PHKL_11730: PANIC PHKL_10953: HANG PHKL_10288: PANIC PHKL_9931: HANG PHKL_9361: PANIC PHKL_8953: HANG PHKL_8331: CORRUPTION PHKL_12662: HANG PHKL_10930: HANG PHKL_8203: HANG PHKL_9909: HANG PHKL_12088: OTHER Patch REQUIRED for the OmniStorage 2.20 product PHKL_9569: HANG PHKL_8294: HANG PHKL_10199: CORRUPTION PHKL_9372: PANIC PHKL_11519: ABORT PHKL_11321: PANIC PHKL_11013: OTHER This problem leaves the file system disabled and unusable, and requires a system reboot to regain access to it. PHKL_7899: PANIC HANG OTHER The KI instrumentation fix does not fall into any of specified symptoms; the root setuid fix does not either. PHKL_11733: OTHER Unmountable VxFS (JFS) file system. PHKL_11860: PANIC PHKL_9370: OTHER Unmountable VxFS (JFS) file system. PHKL_7776: OTHER Unmountable VxFS (JFS) file system. PHKL_12100: CORRUPTION Kernel portion of fix for unrepairable JFS file system where fsck produces the error message "no valid ILIST in fileset 999". PHKL_11607: PANIC PHKL_11039: CORRUPTION This patch fixes data corruption for applications that create large files which keep changing their size dynamically. PHKL_9517: CORRUPTION PHKL_12397: PANIC HANG PHKL_12110: PANIC HANG PHKL_11766: PANIC PHKL_11696: PANIC PHKL_11561: CORRUPTION This patch when used with the appropriate SG/DLM version will avoid any potential windows for data corruption during reconfiguration in a HA cluster env. using SG or DLM. PHKL_11408: CORRUPTION PHKL_11406: CORRUPTION PHKL_11238: PANIC So far, the panic only appears on MP systems running the latest Informix release. PHKL_11085: CORRUPTION From a customer perspective, EMC Symmetrix disks can appear to lose or corrupt data when rare spurious errors are reported. The data is actually able to be recovered on the disk, and this patch allows LVM to ignore the fact that the block was once "bad" and obtain the good data from the repaired block. PHKL_10932: OTHER HPMC on Emerald-class systems at boot time. PHKL_10757: PANIC PHKL_10675: PANIC CORRUPTION PHKL_10643: PANIC PHKL_10554: PANIC The HPMC/panic that is fixed by this patch has been observed only in rare instances on pre-release hardware. However, the potential exists for similar problems in the field only if PHKL_9151 has been applied. This fix should also provide increased performance for PA-8000 systems. PHKL_10452: PANIC PHKL_10257: PANIC PHKL_10234: PANIC PHKL_9075: PANIC PHKL_8532: CORRUPTION PHKL_8084: ABORT PHKL_7870: PANIC Path Name: /hp-ux_patches/s700/10.X/PHKL_12901 Symptoms: PHKL_12901: A kernel stack overflow panic occurs when the stack is valid and all the 3 pages allocated for kernel stack are consumed. The defect is seen when a combination of NFS,LVM,JFS related modules are called. PHKL_11730: Data page fault in bwrite. PHKL_10953: Severe system hang: the crash dump (TOC) would show many threads waiting for the filesystem alpha semaphore. The kernel stack trace of the thread owning filesys_sema would show bc_yield() calling swtch(). PHKL_10288: Panic trap 15 in bwrite() under heavy disk I/O stress. PHKL_9931: VxFS hangs waiting for I/O to finish.. PHKL_9361: MP machine used as a nfs client panics with: panic: (display==0xb800, flags==0x0) Data page fault panic stack: crash event was a panic panic+0x10 report_trap_or_int_and_panic+0x8c trap+0xbfc $call_trap+0x20 binvalfree_vfs+0x5c rinval+0x10 nfs_unmount+0x20 umount_vfs+0x5c umount_root+0x20 umount+0x98 syscall+0x1a4 PHKL_8953: The K400 4-way suddenly stopped to work. The user heavily accessed vxfs snapshot filesystem and have done sync's in parallel. We TOC'ed the system. PHKL_8331: Data loss with UFS files using fragments. PHKL_12669: This patch contains problems in three areas: 1. There are no warning to user when bad block alternates were allocated inside the user data area. 2. There is no way to use lv timeout feature when the async driver minor number is not 0. 3. Add a new lvol flag in lv_lvsubr.c to support a command patch. PHKL_12662: HFS file system may hang on system reboot. PHKL_10930: The system hangs when trying to dump core, as the result of a system panic or TOC. (Normally, it would dump core and reboot.) PHKL_8203: MP system hangs during panic. The LED shows system staying at INIT CB0B. Machine needs to be TOC'ed to save the core dump. PHKL_11637: CDROM drive remains locked when system is rebooted. PHKL_9909: A deadlock can occur on system running LVM, JFS and HFS. The hang was introduced by one process running lvmerge on HFS logical volumes and another process running umount on a JFS logical volume. This deadlock can only occur with the following scenario: (1). Process A is running a lvmerge or a lvsplit on a HFS logical volume (2). Process B is running a mount, umount or sync on a JFS logical volume. PHKL_12601: VxFS systems do not allow a process to ftruncate() a file it has opened, write-locked and read from. When the program fails, errno is set to 11 which means resource is temporarily unavailable. PHKL_12088: The DMAPI functionality as delivered with HP-UX 10.20 is not functional. Thus the OmniStorage product, which relies exclusively on this functionality, will not work with the shipped JFS DMAPI software provided with the OnlineJFS product. PHKL_12100: kernel part of the fix for the slow fsck problem: command patch PHCO_11909 The following problems are fixed: 1) Under certain circumstances after a hard failure, VxFs fsck log replay would fail requiring a full fsck. 2) On large file systems containing a very large number of files, full fsck would run extremely slowly. PHKL_11860: The PHKL_9371 installed system panic's during reboot, if reboot command is used. This patch fixes this problem. PHKL_11733: After a hard failure (panic/hang/TOC), a JFS file system may not mount and will return the following error message: vxfs mount: %s is not a vxfs file system. This could even happen with patches PHKL_9371 and PHCO_11223 installed. A full fsck does not clean the file system; a newfs/mkfs is the only solution. PHKL_11607: System may panic in vx_itimes() when mounting a JFS file system after a boot from a hard failure. PHKL_11519: On a NFS server with a Vxfs file system exported, the file /var/adm/nettl.LOG0x grows dramatically with the recording of "read failed with errno 22" (EINVAL). This problem is addressed by kernel patch PHKL_11322 among other problems. However, after the patch is installed, some NFS clients experience command coredump on the NFS mounted VxFS disk. PHKL_11471: Quota command shows poor performance on a busy system under JFS. PHKL_11321: This patch fixes two JFS performance problems and one defect: 1) Upgrading from 10.10 to 10.20, customer experienced approximately 25% performance degradation in read operation under JFS. 2) Loading a program for a second and subsequent time takes much longer if the program is using shared libraries on JFS. 3) Occasional panic occurs when running an executable which attempts to pagein through vnode level, producing a stack: trap+0xf84 0.0xe21c4 0x6954.0x7ffe75b8 ... $RDB_trap_patch+0x20 0.0x22608 0x6954.0x7ffe75b8 ... lbcopy_fp_method1+0x58 0.0x222b98 0x6954.0x7ffe7108 ... privlbcopy+0x1c 0.0x222fc4 0x6954.0x7ffe70c8 ... uiomove+0x4f0 0.0xfabe8 0x6954.0x7ffe7008 ... vx_read1+0x26c 0.0xb9744 0x6954.0x7ffe6ec8 ... vx_rdwr+0x16c 0.0xc5164 0x6954.0x7ffe6e08 ... vn_rdwr+0x8c 0.0x107b04 0x6954.0x7ffe6d48 ... mfs_hpux_pagein+0x448 0.0x1cbb5c 0x6954.0x7ffe6c88 ... virtual_fault+0x9a0 0.0xf1fc8 0x6954.0x7ffe6b48 ... vfault+0x104 0.0xf281c 0x6954.0x7ffe6ac8 ... trap+0x129c and the message: trap type 15, pcsq.pcoq = 0.222b98, isr.ior = 18e.4179000 savestate ptr = 0x7ffe7108, savestate return ptr = 0x222fc4 9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996 panic: (display==0xbd00, flags==0x0) Data page fault This is mostly seen on PureAtria's Clearcase product which sets the UIOSEG_PAGEIN flag for vn_rdwr() calls. PHKL_11247: On a VxFS with quota turned on, users who do not have quota set receive "write: Disk quota exceeded" error message when creating files on this file system. PHKL_11039: JFS file system corruption when running applications using file truncation on large files. The system message buffer will show: "vxfs: mesg 017: vx_trunc - /mnt file system inode 123 marked bad. vxfs: mesg 016: vx_ilisterr - /mnt file system error reading inode 123". It also fixes a malloc panic which was found while fixing this defect. PHKL_11013: The vxupgrade command, used to convert a JFS version 2 file system to a version 3, can give an I/O error on execution. This causes the file system to be marked as unavailable, and a full fsck to be run. PHKL_10966: When running fsadm to reorganize extents (de-fragment) the command fails with error: exclusion zone for bno = 323584, len = 2048 failed This error message does not occur at all times. It has been observed when running fsadm on file systems which contain directories with many small files. PHKL_10199: 10.20 JFS version 3 file system returns the following file allocation error on file systems large than 64Gb before the file system is actually full: vxfs: msg001: vx_nospace - /dev/vgXX/lvolY file system full (1 block extent) The following console message may also be seen: vxfs: mesg 003: vx_mapbad - /dev/vgXX/lvolY file system free extent bitmap in au nnnn marked bad PHKL_9711: Each time edquota -t is invoked for a VxFS file system, it resets the previously defined file system time limit back to default (7 days). PHKL_9569: This patch addresses 2 distinct VxFS (JFS) symptoms: - When trying to take a file-system snapshot, the mount command could fail with the following error message: # mount -F vxfs -o snapof=/dev/vg00/vxonline \ /dev/vg00/vxbackup /vxbackup vxfs mount: /dev/vg00/vxbackup is already mounted, /vxbackup is busy, or allowable number of mount points exceeded - The system could hang when manipulating directories. PHKL_9517: VxFS file system corruption can occur when running the reorg option of the fsadm command on a busy file system. System diagnostic messages from the dmesg command will include the following: vxfs: mesg 008: vx_direrr - /??? file system inode X block Y error 6 vxfs: mesg 017: vx_iread - /??? file system inode X marked bad vxfs: mesg 016: vx_ilisterr - /??? file system error reading inode X vxfs: mesg 008: vx_direrr - /??? file system inode X block Y error 6 vxfs: mesg 017: vx_iread - /??? file system error reading inode X . . . PHKL_9372: Panic: "data page fault" when using fsadm to resize a mounted VxFS filesystem with disk quotas. PHKL_9370: If a customer upgrades from 10.01 or 10.10 to 10.20, and tries to increase their VxFS file systems via SAM, the file system will not mount after completion of extending the volume and file system. The typical approach for SAM is: 1) unmount the file system 2) lvextend the volume 3) extendfs the file system 4) mount the file system The mount will always fail in this case. PHKL_9153: Add write-gathering support for NFS servers. PHKL_8481: JFS performance in 10.20 has improved disk i/o throughput at the cost of extra CPU utilization. This patch improves JFS performance by implementing a log buffer re-use scheme and also by making modifications to the read/write sleep lock primitives. PHKL_8294: When multiple nfsd's access the same file simultaneously, they hang in a deadlock. PHKL_7899: KI queuedone, enqueue and queuestart traces on JFS may contain NULL values in the b_apid and b_upid fields. With a system running a heavy load using JFS on LVM, the following panic may occur: "lv_syncx: returning error: 5" Systems running JFS may hang due to a deadlock problem. The setuid bit will be removed on a JFS file when the file is edited or text has been appended to it when run as root. PHKL_7776: It's possible for a JFS file system to get into a state where it can't be mounted (except read-only), but fsck(1M) does not report any problem with it. At mount time, the kernel prints the following warning on the console: vxfs: mesg 012: vx_iget - file system invalid inode number XXX and mount(1M) fails with the following message: vxfs mount: /dev/XXX is not a vxfs file system. Once a file system has gotten into this state, it remains unmountable, even after running fsck(1M). PHKL_12633: SHMEM_MAGIC executables suffer from unacceptable performance greatly impairing its usefulness. PHKL_12409: Applications relying on alarm() returning a number greater than zero will fail if there was time remaining on the cancelled alarm and were trying to re-schedule the original alarm. alarm() returns "zero" when cancelling a previous alarm() with an alarm pending. PHKL_12042: Resource-intensive processes (such as an Informix oninit) either perform poorly over time (as timeshare) or monopolize the system (as realtime). Also, MP systems show processes frequently being moved from one CPU to another. PHKL_12397: This patch fixes two defects : - System panic (data page fault) when debugging processes over an interruptable NFS mount point. - After call to pstat_getmsg(), all accesses to the message queue hang. PHKL_12110: System hangs on UP systems or spinlock deadlocks on MP systems, when using nanosleep system call. If using signals which were to be ignored when in nanosleep() we were awaken eventhough we should not. Patch is especially critical as soon as newer libc patches are installed on the system too. The first releases of libc to be critical are PHCO_10384 for 10.10, PHCO_11004 for 10.20 and PHCO_10652 for 10.01. PHKL_12073: With sa_flags (in sigaction structure) set to SA_SIGINFO, after a child process abnormally terminates without a core file being generated, the si_code number of the siginfo_t structure is supposed to contain CLD_KILLED. This failed to happen when the child process abnormally terminated with a SIGPOLL signal. PHKL_11902: pid information is missing from a diagnostic message which tries to explain to a user that their process does not have the correct locking priveleges required for using large text pages. PHKL_11766: 1. vgextend command will complain "too many links" if user wants to add an addition physical volume to a volume group, and the total physical volume and their links add up to total number of max physical volume allowed in a volume group. 2. trap panic in lv_resyncpv from LVM. lots of "pvnum is POWERFAILED" messages PHKL_11696: panic: hdl_alloc_spaceid: spacemap exhausted PHKL_11561: A customer might find corrupt data on disk after a Service Guard or Distributed Lock Manager fail-over. This defect is specific to the HA cluster environments. PHKL_11408: Corruption of memory pages on systems with PA-RISC 2.0 cpu. Problem should happen rarely and only under extreme memory stress. PHKL_11406: When using large environments greater than 20 kbytes user applications dump core sometimes, or get bad data. PHKL_11339: A process launched from shell sees (getrlimit) limits set in the shell via ulimit -t but ignores them. When a process forks, the child sees the limits set by the parent via setrlimit but ignores them PHKL_11244: When accessing an address returned by mmap(), the application gets a SIGBUS error and core is dumped. PHKL_11238: Panic on S800 MP systems using 10.01+ with latest Informix PHKL_11085: On very rare occasions EMC Symmetrix disk drives will report a disk error which causes LVM to mark the block as bad in its bad block directory. The Symmetrix drive can be "repaired" online by EMC support, but the entry in the LVM bad block directory will prevent any further I/O to the affected block. This patch enables a new relocation policy which will prevent entries from being added to the bad block directory. In order to make use of this new relocation policy, a commands patch, PHCO_10826 must also be installed. Also, algorithms within LVM that deal with PVLinks had built in the assumption that NIKE serial numbers were unique. This turned out to not be the case. The only time that the serial numbers need to be unique is in OPS clusters. This patch removes this restriction for all non-OPS cluster environments. PHKL_11006: timer_settime(2) does not set 10ms timer interval properly. The smallest interval can be set is 20ms. PHKL_10932: (4701353078/DSDe436182) Emerald-class (890, T5x0, T600) systems will experience an HPMC at boot when IODC for memory controllers is being accessed. Note: if you are not experiencing this problem now, then your memory controllers are not subject to this problem. (This problem is NOT intermittant.) PHKL_10821: Although users can now exec() programs with up to 2048000 bytes of argument and env strings, sysconfig() _SC_ARG_MAX continues to return 20480 bytes as the maximum length of all arguments and env strings. PHKL_10800: audit records contain relative path names which the user has no idea where they are anchored. this fix prepends the cwd to the relative path name yielding a complete absolute path PHKL_10757: Workstation Additional Core Enhancements for HP-UX 10.20 (July 1997). This patch provides additional enhancements to support new HP workstations. The primary change is the addition of a new signal (SIGGFAULT) and virtual memory subsystem changes to support virtual device locking for new VISUALIZE-FX graphics hardware. It also contains two bug fixes: one for the MP PDIR bug (could panic the system) and the other for the pstat_cmd() panic. PHKL_10689: HP-UX didn't log any error when a user process: 1. encounters a swap space shortage 2. exceeds a system resource limitation Processes were terminated but the errors were not recorded on any of the system log files. PHKL_10675: (1) System may panic with "panic: sync not stale" while running lvmerge (merging LVM mirrors). For the panic to occur, an i/o timeout must occur during the lvmerge operation which results in a resync getting scheduled. (2) Potential data corruption if user i/o's encounter errors to the same extents which are being reimaged by lvmerge. (3) Various panics during vg activation(vgchange -a). A bit is cleared in a kernel structure which LVM has already freed. If another kernel subsystem has been allocated the freed memory before the bit is cleared, panics or other strange behaviors may occur. This particular defect was introduced by PHKL_9000. PHKL_10643: System panic with Memory Mapped Files on UFS filesystem. A typical kernel stack trace would show a data page fault panic in hdl_unsetbits() called from async_pagein_comp(). PHKL_10554: PA-8000 performance; fix kernel-assisted branch prediction. Corrects corner case condition that causes an HPMC. The stack trace would point to module flip_comb(). This corner case has only been seen in lab-internal testing, using pre-release hardware. It has not been seen on any customer's system. PHKL_10452: Panic: kernel stack overflow; trace includes lv_end(). PHKL_10316: When ptrace is called from the DDE debugger while the DDE debugger has watchpoints set, the ptrace system call is called to single step the user process. If the ptrace call is handling a user signal and another signal event is pro- cessed before returning to the user process from ptrace, ptrace may incorretly sent the user's save_state program counter to an incorrect value and return EIO to the parent debugger. PHKL_10257: Panic with "vn_rele" with EXEC_MAGIC executable run over NFS PHKL_10234: panic: kernel scheduler interrupt PHKL_10176: The total length (including terminators) of all argv and env strings passed to a newly-EXECed process was 20480 bytes. If a greater length was detected, the exec() failed with E2BIG. PHKL_9919: Timing differences between CPU to large, causes MI Daemon to die frequently (often in less than 15 minutes). PHKL_9529: vgdisplay(1M)/vgextend(1M) show incorrect value for max number of PE per PV. PHKL_9273: On MP systems with several processors, applications which do file locking frequently can perform poorly. The symptoms are a high switch rate (switch rate > syscall rate) and heavy system activity (%sys > 90%). PHKL_9151: This patch includes 3 separate performance enhancements. All are targetted for PA-RISC 8000 processors. 1. Kernel-assisted branch prediction. 2. bl->bll branch stub elimination. 3. Re-positioning perf-critical kernel assembly routines. PHKL_9075: Applications using Memory Mapped Files were performing poorly when mapping thousands of pregions to the same file. The problem would mainly be noticed with shared (MAP_SHARED) and exclusive (MAP_FIXED with address in the process private data space) mappings. This patch is required when using the Object Store database product from ODI. Additionally, this patch provides an enhancement to the mprotect(2) system call: mprotect(2) used to fail protecting non mmap(2)'ed addresses. This patch enables to mprotect(2) data, stack and shared memory segment addresses. Finally, this patch fixes a kernel panic with large buffer cache: kernel panic with a data page fault when attempting to copy data from the last page of the third quadrant. This will only occur on systems with a buffer cache of one gigabyte or larger. The panic message will display the following: isr.ior = 0.bffffffc running strings on a raw sar(1) output file can show some printable strings (sar ignores these). PHKL_8999: Without this patch customers are limited to supporting 2 nodes in a shared environment With this patch customers can now use SLVM in a 4 node cluster Alternate links for devices such as the Nike disk array are now supported in a shared environment This change supports a new -t switch for lvchange allowing the administrator the option to limit the time lvm holds i/os to be retried on logical volumes when disks are powerfailed. Without using this option, LVM will hold the i/os as long as there is is one disk where the data resides which may eventually return. Using this option would cause LVM to give up on the powerfailed disk and return i/o errors to the user application using the logical volume. This feature is obviously not to be used indiscriminately. For many High Availability applications, having i/os held in kernel indefinitely is not acceptable. Most customers should not need to use the new switch. PHKL_8716: After call to pstat_getmsg(), all accesses to the message queue pstat_getmsg() was called hang. PHKL_8532: System crash dumps are corrupt and unusable. PHKL_8346: Executables cannot access more than 1.75 GB shared memory PHKL_8084: LVM may return I/O's with errors instead of sending them to an alternate link. This patch also facilitates using "vgreduce -f" for physical volumes which have alternate links; without this patch "vgreduce -f" is not allowed on LVM disks with alternate links. PHKL_7951: Ptrace not allowing writes on PCUX to some f.p regs PHKL_7870: lvreduce(1M) may cause a system panic, if it is used to reduce an lvol which was left inconsistent by a prior LVM operation. lvreduce(1M) could not be used to remove lvols that were somehow corrupted, if it was, the command would cause a system panic. Defect Description: PHKL_12901: The defect is due to allocation of large data structures (local variables) on stack when a function is called. The fix was to re-compile the object modules(LVM,JFS) with a compiler option (+ESssf - small stack frame) to align the stack pointer to 32-byte boundary instead of 64-byte boundary. This prevents the kernel stack overflow panic. PHKL_11730: Conditions needed to be re-checked after acquiring lock. Functions changed: bflush1, bflush_vfs, binval, blkflush, bpurge, ogetblk and syncip_flush_cache PHKL_10953: The bc_yield() buffer cache routine was calling swtch() without first releasing the file-system alpha semaphore. This defect would impact mainly systems using a large buffer cache. PHKL_10288: A buffer arrives in bwrite() with B_ASYNC/B_DELWRI and B_INVAL on and bp-vp == 0 (buffer disowned). On attempting to complete the write, VOP_STRATEGY resolution results in a trap 15 due to null vp. PHKL_9931: Currently, biodone() sets B_DONE and drops the spinlock for the buffer before making a callback to an I/O completion routine, if one has been set up. This means that biowait() can return while the callback is in progress, and the buffer might be released. The solution is to always set B_DONE in finish_biodone() instead of biodone(). PHKL_9361: binvalfree_vfs() has a race window where while one process is checking to see if a vnode buffer can be freed, another process dereferences the vnode pointer from the same buffer. The fix is to use a local variable to avoid the MP race. PHKL_8953: The problem is caused by a defect in getnewbuf procedure in vfs_bio.c file. When Vxfs calls getnewbuf() to acquire a buffer, it passes BX_NONBLOCK in bxflags to avoid potential deadlock. However, the getnewbuf() proceeds to call bwrite() to flush the buffer without checking the bxflags when it finds a B_DELWRI buffer. This causes Vxfs with snapshot to hang. The fix for this defect is to make fix for getnewbuf() in file vfs_bio.c. When getnewbuf() ends up grabbing a DELWRI buffer with BX_NONBLOCK, it will release the buffer and return NULL instead of flushing and returning the buffer. PHKL_8331: There was a code path where dirty buffers could possibly be dropped (not flushed) when extending UFS files using fragments. PHKL_12669: 1. When a physical volume which has bad block alternates allocated and is begin added/extended to a volume group without doing a pvcreate -f. If the bad block alternate resides inside the user data area, this could cause data corruption. 2. The problem has to do with how the LVM interprets the B_PFTIMEOUT flag. For mirrored reads, the LVM works as desired: if the first disc is bad, the LVM tries the second disc. If the second disc is also bad, then the LVM reports a disc error. In the case of PV links however, the LVM reports a disc error immediately without trying the alternate link. 3. The new lvol flag (LVM_NONCONTIGUOUS) is defined for a new allocation policy begin implemented in a LVM command patch. PHKL_12662: A thread owns a resourse needed by the reboot process, yet is stuck on a frozen spu, causing a deadlock. PHKL_10930: The hang is due to the system taking a floating point exception as the result of a PDC defect. PHKL_8203: In 10.X, interrupt distribution is implemented to allow reassignment of interrupt processors to I/O interfaces for workload balancing. The assigned interrupt processor for an I/O interface may or may not be the system monarch depending on the the number of I/O cards and processors available. During a panic, if the panic processor is the system monarch, it will flush the buffer cache on its way down. If the interrupt of the disk it is syncing is serviced by one of the other processor(s), the I/O completion interrupt will not be received and the ISR will not be called because the other processor(s) are TOC'ed at this point. Without the ISR to signal biodone(), the biowait() sleeps forever. The fix is to add a timeout in the panic_boot path to break out from the hang in disk sync'ing and continue with the reboot. PHKL_11637: Mount an HFS file system from the CDROM drive then reboot the system without unmounting the file system. When the system comes up, the CDROM draw will remain locked. PHKL_9909: A deadlock resulted from a process running lvmerge on HFS logical volumes, and another process running umount on a JFS logical volume. The umount process grabs the JFS update sleep lock (used to serialize JFS syncs/mounts/ umounts), calls spec_close to close the device we are unmounting, and eventually gets to a LVM close routine which is sleeping waiting to acquire the LVM volume-group lock. The lvmerge process is holding the LVM volume-group lock and proceeds to call freeze_and_sync_fs_dev() to freeze and sync the file system associated with the device. The routine ufs_freeze() is first called which in turn calls walk_and_freeze_fs() without a pointer to a vfs structure. This proves faulty since update() is now called without a vfsp and will proceed to try and sync every mounted file system instead of just the file system being frozen. So we proceeded to try and sync a JFS file system which first tries to grab the JFS update sleep lock, and a deadlock occurs. This problem can be reproduced by having one process running a lvsplit or lvmerge on a HFS logical volume, and another process running a mount, umount or sync on a JFS logical volume. The fix for this problem is to pass the vfsp to walk_and_freeze_fs() from ufs_freeze() instead of the do_sync argument. The routine walk_and_freeze_fs() now uses vfsp when it calls update(). PHKL_12601: ftruncate() retuns EAGAIN on madatory locking regardless of lock owner. If we have mandatory locking on a VxFS file and if there is a pending lock, then we return EAGAIN regardless of the owner of the lock. vx_setattr() does not allow a file to be truncated if there is mandatory file lock owned by another process, even if it does not overlap the range being truncated. PHKL_12088: If a customer installs the HP-UX OmniStorage product on the 10.20 release, the product would not be functional. The DMAPI extensions available with the OnlineJFS product (currently only being utilized by OmniStorage and not linked into the kernel by default), had several severe bugs that were fixed in the 10.30 release. This patch backports the DMAPI functionality from 10.30 into 10.20. PHKL_12100: fsck was not able to handle iau data spread across multiple extents. The kernel, on the other hand, seems capabable of multiple extents for iau. fsck was fixed to agree with kernel with respect to iau. PHKL_11860: It is assumed that there is one active reference to a disk quota at vx_quotaoff(), which enables to free vx_dquota blocks in vx_dqlist. This assumption is not true during vx_replay() since there is still a VX_MLDQUOT mlink in the file system mlink chain waiting to be flushed. Hence, flushing the file system's mlink queue before calling vx_quotaoff will fix the problem. PHKL_11733: After a hard system failure, a JFS file system may not mount even if PHKL_9371 and PHCO_11223 are installed. If the VX_IETRUNC flag is set for a file, then vx_trunc() is called and returns without clearing the ip->i_eopflags field. Since VX_IETRUNC alone is still set after vx_trunc(), the error return is set to EINVAL (reason why the mount fails). Prior to returning, if error is non-zero, vxfs sets the VX_FULLFSCK flag and returns. Patch PHKL_9371 added the setting of the VX_FULLFSCK flag; the bug leaving the ip->i_eopflags set to VX_IETRUNC still existed prior to PHKL_9371, however after the first failed mount, a second mount would have been successful. PHKL_11607: The file system that was being mounted had previously been under a reorg operation. The panic occurred during replay on the structural fileset where an inode with the org type of IORG_TYPED was being truncated. The truncate operation produced a transaction with over VX_MAXTRAN subfunctions. vx_trunc_typed() is called to truncate the file to size 0. This function makes an accounting error in its loop that frees extents. For each iteration of the loop vxfs only accounts for one subfunction to add to the transaction while more than one subfunction can be added. PHKL_11519: During vnode read operation, if the request is from NFS, the request size is checked against the VX_MAXBSIZE and an EINVAL is returned if the request size is greater than or equal to VX_MAXBSIZE. The EINVAL is always returned because the request size is set to VX_MAXBSIZE (8K) for NFS by the calling routine. When PHKL_11322 fixes this problem, the code proceeds to read the data block and returns the buffer back to NFS. This exposes a bug in which if the data we need starts at a non-zero offset within the buffer and the caller receives the whole buffer assuming the good data starts at the beginning, invalid data is loaded and command coredumps. PHKL_11471: The quota command uses quotactl(Q_SYNC, NULL, 0, NULL) to update the quota usage file on all quota active file systems. For each VxFS file system, the quota sync operation flushes all transactions and writes quota information to the disk file synchronously. On a system with heavy I/O, this results long delay. The fix is to flush the transaction log only and use asynchronous I/O for disk file update. PHKL_11321: 1) In vx_read1(), some unnecessary conditions prevented vx_read_ahead() from being called for large reads. The fix is to remove these extra checkings to allow read_ahead to be performed. 2) When we are done with a shared library, pageout routine is called to flush the changes to disk. The way vx_pageout() works is that it invalidates the cached copy of the file then calls vx_do_pageout() to figure out the MMF pages need to be written and write them. A more efficient way of doing this is to invalidate and flush buffers in the buffer cache only if there are and may have been dirty pages. 3) When reading a sparse portion of a file on JFS, vx_read1() calls uiomove() to copy a page of zeroes to the target buffer. If the UIOSEG_PAGEIN flag is set in the uio structure, uiomove() by default will copy vx_zeropage from the buffer cache. Since vx_zeropage is not in the buffer cache's space, but is in space 0, this references an invalid address and triggers a panic. The fix is to replace uiomove() with long_uiomove() which allows the correct space id to be specified. PHKL_11247: An uninitialized variable, depending on what value it picks up from the stack, causes the quota checking routine to return EDQUOT erroneously during extent allocation. PHKL_11039: There was a defect in the routine checking the validity of extent buffers. This defect would cause inodes to be marked wrongly as BAD, when they were perfectly valid. This also fixes a defect that was found while fixing this problem. The bug is in the routine that splits the extent. It assumes that the allocated extent is same as it had requested, which is not always the case. The defect was that it copied half the entries from extent being split to the new extent, and it may be that not all the entries will fix.(if it allocated less than requested). PHKL_11013: During vxupgrade, it is possible for the allocation unit length to change; thus the same inode located in the same block will change allocation unit numbers. There was a check in vx_iremount() to verify that the allocation unit numbers matched, and returned ENOSPC if not. This was the root cause of the problem which was easily reproducible: o Create a version 2 JFS file system on a 1GB volume: mkfs -Fvxfs -oversion=2 /dev/vg01/onegigvol o mount it: mount -Fvxfs /dev/vg01/onegigvol /tmp_mnt o fill up the file system halfway: prealloc /tmp_mnt/bigfile 500000000 o copy some files into the filesystem: cp -r /usr /tmp_mnt & o wait a few minutes and execute the vxupgrade command: vxupgrade -n 3 /tmp_mnt PHKL_10966: The exclusion zones were not being properly merged for some orders of sets if they wound up being adjacent. When at- tempting to clear the exclusion zones, the clearing code did not bother to look at the next zone on the list to see if it was an exact match since adjacent zones should have been merged. PHKL_10199: The bug is in the allocation and freeing of entire allocation units on file systems larger than 64Gb in JFS version 3. When calculating the buddy allocation unit to allocate and free, the code fails to add back in the map section that it subtracts out earlier, causing the summary of the wrong AU to be updated. The incorrect values in AU summaries and all higher level summaries lead to the allocation failure. PHKL_9711: VxFS quota routine vx_getquota() resets the time limit for root because it thinks root should not have a quota limit. Somehow it ignores the fact that the timelimit fields in root's dqblk structure are used to store the file system time limit. PHKL_9569: This patch fixes two different VxFS (JFS) defects: - A snapshot could not be mounted if a process was waiting arbitrarily long for a file record lock. An application using lockf() or fcntl() to get file record locks, and holding the locks for a long period of time, could prevent from mounting a file-system snapshot. - The VxFS rmdir(2) routine could run into a deadlock situation where the directory would be kept locked. Processes attempting to access the locked directory would then wait forever, and eventually this could cause the entire system to hang. PHKL_9517: The problem can be reproduced by executing the following: - create a version 2 VxFS fs the same size as /usr - fragment the fs (ie. fill up the fs with 8k files, and then remove every other one. Proceed to remove groups of files until enough space is available to copy /usr over - cpio /usr to new fs, and run upgrade fs to version 3 - change /etc/fstab to use new volname for /usr, and reboot - start up /usr applications like sam, vi, swinstall, etc. - run several scripts to do things like add/delete small files, and ``ls'' commands in /usr - with ``busy'' filesystem, run "fsadm -Fvxfs -e /usr" The problem was that the resulting geometry was not being taken into account in vx_reorg_copy() if the reorg range was broken up due to lack of free extents of the requested size. The amount of data to be copied cannot be greater than the minimum of the two extent sizes returned by the bmap calls. PHKL_9372: Resizing VxFS filesystems online effectively does quick unmounts and remounts of the filesystem, switching quickly between the two different data areas containing the filesystem structure information. The VxFS disk quota tracking structures were not updated during the switch, with the end result that the disk quota code was accessing invalid memory. The fix was to update the disk quota structures during the switch. PHKL_9370: The inode summary fields in the new allocation unit added by extendfs were not properly initialized, so whatever happened to be in the block wound up being treated as inode summary data. The vxfs fsck command never detected this, and the mount command was failing in the kernel due to a file system validation error. The problem is easily reproduced by executing the following: # lvcreate -L 40 -n testvol /dev/vg00 # mkfs -Fvxfs -oversion=2 /dev/vg00/rtestvol # mount -Fvxfs /dev/vg00/testvol /tmp_mnt # umount /tmp_mnt # lvextend -L 80 /dev/vg00/testvol # extendfs -Fvxfs /dev/vg00/rtestvol # mount -Fvxfs /dev/vg00/testvol /tmp_mnt PHKL_9153: Added code to update the v_last_fsync field on the vnode. This field will be used by rfs_write to implement write gathering on nfs servers. Patch PHKL_9155/56, which updates rfs_write(), must also be applied for this patch to be effective. If both patches are applied, server throughput should increase for write-intensive workloads, and I/O traffic to disk should decrease. PHKL_8481: JFS extra CPU utilization may cause system performance problems on some configurations. PHKL_8294: ufs_bread(), called by nfs server routines, prematurely unlocks the inode while the caller still owns the buffer. This opens a window for another process to grab the inode lock. Deadlock occurs when the process owning the buffer tries to access the inode again and the process holding the inode waits for the buffer to be available before it can release the inode lock. The fix is to delay the inode unlocking in ufs_bread() until the inode is no longer needed. PHKL_7899: KI problem: The JFS buffer allocation and IO paths were not fully instrumented causing buffer header b_apid and b_upid fields not to be updated consistently. The resulting KI queuedone, enqueue, and queuestart traces contain NULL values in these fields. A panic can occur with JFS on LVM due to an inode being able to change identity before it and its dirty pages are flushed to disk in vx_freeze_iflush(). System can deadlock due to a locking order problem in JFS when vx_fast_read() is called from VOP_BREAD. When a JFS file is created with the SETUID flag, the setuid bit is removed when the file has been edited with vi or text has been appended to it; this should only be the case when the writer is not root. PHKL_7776: At mount time, the kernel completes any pending "extended operations" for a JFS file system. (These might include, for example, removing a file that has no links but couldn't be removed when the last link went away because some process had the file open.) We maintain a bitmap on disk with one bit per inode indicating whether the inode has any extended operations pending, to avoid having to inspect every single inode at mount time. However, the calculation of an inode number from a bit in the bitmap is done incorrectly. This means, first of all, that some extended operations are never completed. More seriously, the inode number we calculate could be out of range, causing the mount to fail. Running fsck(1M) will not help, since there's nothing wrong with the file system. Although the file system can't be mounted in read/write mode, it can be mounted read-only. If a file system gets into this unmountable state, the only recourse is to mount it read-only and to copy the files from it to another (replacement) file system. PHKL_12633: Problem was due to an incorrect assumption in determining the SID to be used. Procedures fast_resolvepid and fast_resolvepid2_0 incorrectly assumed the SID would reside in SR5. This has now been corrected providing better performance of SHMEM_MAGIC executables. PHKL_12409: alarm() rounds the time remaining to the nearest second so if the time remaining is less than 0.5 seconds, the result is rounded to zero. This makes it impossible to reschedule the original alarm. There was no check made in alarm() to determine if the result has been rounded to zero. The fix is to have a check to ensure that we never return zero if there was any time remaining. PHKL_12042: The scheduling policies available prior to this patch did not have a provision for a fixed-priority timeshare (non-realtime) process, one which could use many system resources without being degraded to a very low priority. This patch provides this "no aging" timeshare facility for applications which need it. This facility uses the same interface which is in 11.00, through the POSIX interface routines: applications which need to use this facility should use the sched_setscheduler(2) system call with a new policy of 8 (to be defined in 11.00 as SCHED_NOAGE). Idle processors were stealing processes from other run queues, even when those processes were running frequently already. PHKL_12397: This patch fixes two defects : -When debugging processes over an interruptable NFS mount point there is a window during which a traced process could sleep in exec() while the debugger would exit clearing the traced bit and freeing the ptrace data structure. Upon wakeup, the no longer traced process would panic the system trying to dereference a NULL pointer. -pstat_msginfo() calls msgconv() to convert the offset into a message queue pointer. msgconv() then locks the queue and returns a pointer to the queue's lock. pstat_msginfo() had not been released the lock of the message queue. PHKL_12110: System hangs or panics when signal is received which has action set to ignore when in nanosleep system call. Libc patch that changed sleep()'s underlying system call to nanosleep() makes situation worse. PHKL_12073: The problem was caused by improperly handling the SIGPOLL signal. The si_code number of the siginfo_t structure contained CLD_DUMPED and a core file produced. si_code should have contained CLD_KILLED. PHKL_11902: Missing argument inside of diagnostic printf(). PHKL_11766: 1. When an alternate link is added to a volume group, LVM counts this link as an individual disk. This mistake will cause vgextend to fail when user wants to add an additional disk to a volume group when the total number of disks and its alternate links reach the maximum allowed. 2. LVM panic the system when running one of the stress test. trap panic in lv_resyncpv due to failure return from lv_lvhold call. PHKL_11696: Backout code in dupvas() does not free the vas. One line accidentally deleted in 10.20 checkin of multithreaded vas locking. Seen in 10.30 testing but never reported on customer installations. PHKL_11561: When a node dies in an HA cluster environment, there may be IO requests still pending on its intellegent disk IO boards (eg. Wizard). The IO boards may continue to write this stale data to disks. This process is known as "Ghost IO". This situation may lead to data corruption when the other nodes in the HA cluster detect the failure, apply recovery logic, and perform IO to the disks. There is a need for detecting the death of a node and reseting the bus. This feature only impacts Service Guard/Distributed Lock Manager environments. PHKL_11408: One of the kernel macros used for locking pfdats was using the &htbl[] hash list of locks instead of the &htbl2_0[] hash list of locks, causing it think it had locked a pfdat when it hadn't. PHKL_11406: During the final stages of EXEC, the kernel has to relocate the argv and envp pointers to point to the argument and environment strings which reside in the user stack. There was a defect in this reloction code that caused all pointers pointing to locations in the user's stack at offsets of 20K from the base to have bad addresses. PHKL_11339: CPU limit was not being inherited by the child from the parent and hence if cpulimit is set, child ignores it. Also SIGXCPU is not delivered solely depending on the sigmask, but is triggered by arming the timer. When a child is forked, kt->sigmask is copied from parent to the child but if there is a non infinite cpu limit set in the parent, not only does that field needs to be copied to the child process, the timer for the cpulimit must also be armed for the child. PHKL_11244: mmap() to a file with holes does not work correctly if MAP_PRIVATE is used. PHKL_11238: Random S800 MP system panics when running the latest Informix because of a corner-case MP hole in nanosleep which is seen when nanosleep() is called from within a signal handler. PHKL_11085: On very rare occasions EMC Symmetrix disk drives will report a disk error which causes LVM to mark the block as bad in its bad block directory. The Symmetrix drive can be "repaired" online by EMC support, but the entry in the LVM bad block directory will prevent any further I/O to the affected block. This patch enables a new relocation policy which will prevent entries from being added to the bad block directory. In order to make use of this new relocation policy, a commands patch, PHCO_10826 must also be installed. Also, algorithms within LVM that deal with PVLinks had built in the assumption that NIKE serial numbers were unique. This turned out to not be the case. The only time that the serial numbers need to be unique is in OPS clusters. This patch removes this restriction for all non-OPS cluster environments. PHKL_11006: A defect in the implementation of timer reload causes the 1 tick (10ms) interval be rounded to 2 ticks (20ms). PHKL_10932: (4701353078/DSDe436182) uiomove accesses memory via load-byte operations to improve performance on PA-8000 systems. Load-byte is not a valid operation for I/O address space, though most I/O cards handle it without problems. Some Emerald-class (890, T5x0, T600) memory controllers do not. We now use load-word for I/O space. PHKL_10821: An earlier patch, (10177, shown without prefix so as not to confuse search engines) expanded the actual space available to execve(), but failed to modify sysconfig() to report the new maximum. This patch corrects that. There is no change to module kern_exec.c (home of execve()) other than a revision roll to ensure its inclusion in this patch. PHKL_10800: current system does not keep track of chdir() calls which alter the current working directory. there is no in kernel ascii record of the current path just the vnode/inode which can not be easily converted to the ascii pathname PHKL_10757: This patch provides additional enhancements to support new HP workstations (See "Symptoms" section for more details). It also contains two bug fixes. One fix is for the MP PDIR bug. On MP systems the system could crash due to a race condition where one processor would attempt to read a translation that was being modified by another processor. The other fix was for a panic that was introduced by a previous patch which expanded the argv/envp buffer from 20480 bytes to 2048000 bytes. pstat_cmd() could get a data segmentation violation due to a defect which would keep looking for a null termination beyond one of the internal buffers, possibly referencing an illegal memory address. PHKL_10689: This patch provide support for logging of errors in memory management related system calls such as brk/sbrk as well as handling error cases during stack growth. Errors are logged on the system console (dmesg) and also in syslog. The variable mman_elog, which defaults to OFF, is used to control the logging. This variable can be set through adb at a customer site to enable error logging. PHKL_10675: LVM resyncs are not held off long enough during lvmerge. If an i/o timeout occurs during reimaging, then a resync is scheduled. Towards the end of lvmerge, there is a window in which the resync is allowed to run for a little bit. If the resync gets started on resyncing a stale extent during that interval, and the lvmerge is reimaging the same extent, the panic can occur. User i/o's can encounter errors during lvmerge, but lvmerge wasn't taking these errors into account. There is the potential that extents can be falsely marked fresh during lvmerge if user i/o's occur, resulting in data corruption if those extents are read. During activation (vgchange -a), LVM allocates various pvol structures. A bit is cleared after a structure has been freed. 32 bit systems expect this low-order bit to be zero anyway (aligned addrs), so there is no impact if the freed memory has not yet been allocated to another subsystem before the bit is cleared. However, if the memory has been reallocated during this interval (i.e. on MP systems), various panics and strange behaviors could occur. PHKL_10643: There were two defects in the UFS read-ahead pagein code causing the system to request more read-ahead pages than the system maximum limit. Since the number of requested pages exceeded the allowed maximum, this resulted in overflowing internal arrays, and the system could then panic while using garbled data. First, the book-keeping of the variables tracking the "last read-ahead" and the "expected next fault" was not always done properly. There was a situation where the "expected next fault" could end up exceeding the "last read-ahead", and this resulted in a read-ahead count greater than the system maximum limit. Second, there was a corner case code path using the "last read-ahead" variable before it had been initialized. PHKL_10554: PA-8000 systems with patch PHKL_9151 applied could experience an HPMC if the following were true: an external interrupt occurred while on the gateway page and the IIR in the save-state happened to contain a comb* instruction. Applying this fix will not only prevent this kind of failure, but should also boost performance on PA-8000 systems. PHKL_10452: Defect is quite rare. Kernel stack overflow may result from other causes. This fix reduces frame size of lv_end() from over 600 bytes to under 200 bytes. PHKL_10316: If ptrace() is single stepping an user signal handler and handling a sigcleanup call, and another signal is handled during the return of this system call, the user's PC is overwritten by the single step breakpoint address before returning to the user. One way to reproduce the problem is to use DDE on a program that generates a lot of signals. Signal stepping through the program will eventually cause an internal I/O error. PHKL_10257: The problem fixed was a wrong assumption in add_text which expects the fstore to be the same as the bstore. Because of this assumption the original (and correct) bstore gets trashed when it is overwritten with the fstore after a call to duplicate a region. For an NFS executale with the sticky bit set, the fstore will NOT be the same as the bstore. We know have removed this assumption. PHKL_10234: Running an EXEC_MAGIC program using a stack pointer in the first quadrant could result in a panic: kernel scheduler interrupt. This problem would only be seen on UP systems. PHKL_10176: The internal buffer within the kernel was created with a length of 20480 bytes, with no provision for increasing its size. This patch provides for up to 100 such buffers, with all but the first allocated only if required (that is, if more than 20480 bytes of argv/env information is found). Thus, exec() now supports up to 2048000 bytes of argv/env information. PHKL_9919: Upon synchronization, non-monarch's expect the monarch to be waiting for them to synchronize. If the monarch is not waiting, the synchronization fails, and the offset_correction is set to 0. This happens only on bootup and may not happen every time. This causes times in the KI buffers to vary greatly, and that causes the MI Daemon to crash frequently. The problem is only at boot time, and will not occur later. This means a succesful boot will keep stay good, and a bad boot will stay bad. PHKL_9529: The lv_queryvg() function in ioctl(2) failed to copy the maxpxs field to the returning data structure. This problem was introduced in PHKL_8999. PHKL_9273: The file locking code is protected by a single semaphore (the filesys sema). As the semaphore becomes heavily utilized, starvation prevention code activates which leads to excessive spinning and switching. PHKL_9151: The changes are designed to improve locality of reference within the kernel, thus improving the i-cache hit rate. The "flipper" tool will reduce mis-predicted branches. All will improve the processor efficiency, or CPI rate, when executing kernel code. PHKL_9075: This patch provides two enhancements to Memory Mapped Files: increased performance when using thousands of mappings, and mprotect(2) opened to non-mmap(2) addresses. It also provides a fix for a defect with large buffer cache. The pregions list associated to a shared region was designed as a doubly-linked list thus providing a linear access to pregions in the list. This design was not suited to deal with thousands of pregions and the doubly-linked list was replaced by a skip-list for faster access. Two other changes were required to deliver better performance: the algorithm to check the total virtual address space and the routine to locate the stack pregion were enhanced. Only those addresses returned from a call to mmap(2) could be used for mprotect(2). However there were applications who needed to protect addresses in data, stack or shared memory segments; objects not created via call to mmap(2). So mprotect(2) was opened to allow mprotect'ing on data, stack and shared memory objects. Text is not allowed unless the executable is EXEC_MAGIC. A compiler feature with C language structure copies results in a reference to an untranslated address when copying the last 4 bytes in quadrant 3. This only shows up when the data in the buffer that is being copied includes address 0xbffffffc that is, it is the last full word in quadrant 3. The problem appears as a trap type 15: "data page fault". pstat_dynamic() allocates a buffer but fails to initialize it before using it. Buffer ends up containing some garbage. This is a cosmetic defect only; sar ignores the uninitialized spaces. PHKL_8999: Support for SLVM is currently limited to 2 nodes. This patch will allow SLVM to work in a 4 node cluster. Alternate link support has also been added for SLVM so that devices such as the Nike disk array can now be used in a high availability cluster. LVM makes every effort to avoid returning an error to user applications. LVM will hold onto an I/O to retry it later if there is even the smallest hope that the device will return. If a disk simply does not respond and no bad writes made it to the media, LVM will hang onto the i/o as long as the disk does not respond with an indication that there was actually a bad write or read. The patch provides a new feature that allows administrators the option of limiting the time lvm will wait for disks in an logical volume to return, and cause lvm to return i/os with EIO instead of hanging onto them indefinitely. PHKL_8716: pstat_msginfo() calls msgconv() to convert the offset into a message queue pointer. msgconv() was changed to not only do the conversion, but to lock the queue and return a pointer to the queue's lock. pstat_msginfo() had not been changed to take into account msgconv()'s new behavior. PHKL_8532: Intermittent corrupted dumps on PA-RISC2.0 (PA8000) machines on HP-UX 10.20. PHKL_8346: Current executable types cannot access more than 1.75 GB of shared memory. A new executable type is defined which uses the second quadrant of the address space for shared memory rather than process private data thus resulting in 2.75 GB of shared memory. With short pointer addressing on 32-bit PA architecture, each pointer addresses one of four quadrants each of which is 1 GB in size. Current executable types use quadrant 3 and quadrant 4 for shared memory. In user mode, quadrant 1 and quadrant 2 are used for user text and data, respectively. This results in a system wide maximum of 1.75 GB of shared memory (.25 GB in quadrant 4 is set aside for IO). In the new executable type, user data and stack are pushed into quadrant 1 and quad 2 is also used for shared memory. An existing application has to be relinked as the new executable type to avail of this feature. Alternately the application can be linked as an EXEC_MAGIC and the n the executable can be chatr'd to be the new executable type (SHMEM_MAGIC). The related patch for chatr is PHSS_8358. Only the chatr method is currently supported. Please note that this is an interim solution for increased shared memory addressing till 64-bit hp-ux becomes available. There are several limitations: - Only executables that are linked to be the new SHMEM_MAGIC executable type(or chatrd to be so) can avail of this feature. Other executables will continue to see a system wide maximum of 1.75 GB of shared memory. Processes that execute other types of executables will not be able to share the memory in quadrant 2 with a process that is executing the new executable type. - In the new SHMEM_MAGIC type, quadrant 2 is only used for system V shared memory (unlike quadrants 3 and 4 which are also used for shared memory mapped files). - In the new executable type text is mapped at different virtual addresses and so process intensive applications may not benefit. Any increase in performance due to the larger shared memory may be offset by decreases due to TLB inefficiency. Applications that use one process per processor may however benefit. - This will not be supported on future HP implementations of 64-bit architectures (beyond PA 2.0), nor will it need to be as with a 64-bit kernel the size of shared memory supported will be much larger than 2.75 GB. Programs that need more than 1.75 GB of shared memory on these architectures will have to be recompiled for these architectures. - Programs that are compiled as 64-bit executables on any 64-bit HP implementation (including PA 2.0) cannot be marked as SHMEM_MAGIC nor do they need to be as they will already have access to more than 1.75 GB of shared memory. PHKL_8084: Without this patch LVM will not retry failed i/os on alternate links unless the error is one that denotes that the device is offline or powerfailed. Other errors, are not retried on an alternate link and may cause LVM to report the error to users applications. Typically, customers with unmirrored lvols using multiported devices like the HP3232 (Nike) disk array would see the problem when an EIO error is reported to LVM from the underlying device driver due to a device or driver problem. In this situation LVM would report the EIO to user applications without trying any available alternate link. Another problem this patch fixes allows reducing out physical volumes from a volume group when the device is not available and the device has links, formerly devices with links could not be removed if they were not available. PHKL_7951: 32 bit registers were allowed to be modified after 64 bit registers have been modified. PHKL_7870: The problem was that the kernel forced a panic whenever any inconsistency was found during an lvreduce. For example, if a logical extent in an lvol referred to a physical extent that was not allocated, it would cause lvreduce(1M) to panic the system. This occured even when the objective was to remove the offending lvol. This is a very rare occurance. SR: 0000000000 1653096131 1653166066 1653166496 1653166983 1653179895 1653192294 1653194555 1653194977 1653199802 1653202754 1653207175 1653211607 1653216077 1653218065 1653220079 1653221895 1653227983 4701327338 4701327544 4701329292 4701329300 4701329433 4701329441 4701330647 4701333419 4701334367 4701334698 4701334847 4701334995 4701335497 4701335935 4701336412 4701339226 4701341362 4701341479 4701341644 4701341669 4701342121 4701344515 4701345843 4701347922 4701348359 4701349431 4701350157 4701350975 4701351932 4701352278 4701352799 4701353078 4701353094 4701353102 4701354274 4701355321 4701355560 4701355610 4701356931 4701358143 4701358523 4701360925 4701361188 4701361444 4701361758 4701364182 4701365114 4701365791 5003281469 5003314633 5003317487 5003318667 5003323493 5003325506 5003328237 5003330910 5003334961 5003341925 5003344630 5003348425 5003353797 5003357616 5003359414 5003360024 5003360446 5003361766 5003363523 5003363820 5003364224 5003366500 5003368290 5003379156 5003380113 5003385203 5003385393 5003387019 5003387183 Patch Files: /usr/conf/h/audit.h /usr/conf/lib/libdmapi.a(kdm_core.o) /usr/conf/lib/libdmapi.a(vx_dmattr_table.o) /usr/conf/lib/libhp-ux.a(asm_rv.o) /usr/conf/lib/libhp-ux.a(asm_scall.o) /usr/conf/lib/libhp-ux.a(asm_utl.o) /usr/conf/lib/libhp-ux.a(asm_vm_pdir.o) /usr/conf/lib/libhp-ux.a(bcopy.o) /usr/conf/lib/libhp-ux.a(btlb.o) /usr/conf/lib/libhp-ux.a(bzero.o) /usr/conf/lib/libhp-ux.a(clock.o) /usr/conf/lib/libhp-ux.a(cpd.o) /usr/conf/lib/libhp-ux.a(dump.o) /usr/conf/lib/libhp-ux.a(flipper.o) /usr/conf/lib/libhp-ux.a(hdl_fault.o) /usr/conf/lib/libhp-ux.a(hdl_init.o) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) /usr/conf/lib/libhp-ux.a(hdl_policy.o) /usr/conf/lib/libhp-ux.a(hdl_trans.o) /usr/conf/lib/libhp-ux.a(init_main.o) /usr/conf/lib/libhp-ux.a(interrupt.o) /usr/conf/lib/libhp-ux.a(kern_exec.o) /usr/conf/lib/libhp-ux.a(kern_fork.o) /usr/conf/lib/libhp-ux.a(kern_kload.o) /usr/conf/lib/libhp-ux.a(kern_mman.o) /usr/conf/lib/libhp-ux.a(kern_sig.o) /usr/conf/lib/libhp-ux.a(lbcopy.o) /usr/conf/lib/libhp-ux.a(lbzero.o) /usr/conf/lib/libhp-ux.a(lv_config.o) /usr/conf/lib/libhp-ux.a(lv_lvm.o) /usr/conf/lib/libhp-ux.a(lw_scall.o) /usr/conf/lib/libhp-ux.a(machdep.o) /usr/conf/lib/libhp-ux.a(outlaw.o) /usr/conf/lib/libhp-ux.a(pgcopy.o) /usr/conf/lib/libhp-ux.a(pm_clockint.o) /usr/conf/lib/libhp-ux.a(pm_config.o) /usr/conf/lib/libhp-ux.a(pm_context.o) /usr/conf/lib/libhp-ux.a(pm_core.o) /usr/conf/lib/libhp-ux.a(pm_policy.o) /usr/conf/lib/libhp-ux.a(pm_proc.o) /usr/conf/lib/libhp-ux.a(pm_procdup.o) /usr/conf/lib/libhp-ux.a(pm_ptrace.o) /usr/conf/lib/libhp-ux.a(pm_resource.o) /usr/conf/lib/libhp-ux.a(pm_rtsched.o) /usr/conf/lib/libhp-ux.a(pm_sendsig.o) /usr/conf/lib/libhp-ux.a(pm_signal.o) /usr/conf/lib/libhp-ux.a(pm_swtch.o) /usr/conf/lib/libhp-ux.a(pm_threads.o) /usr/conf/lib/libhp-ux.a(pm_timers.o) /usr/conf/lib/libhp-ux.a(protection.o) /usr/conf/lib/libhp-ux.a(pstat.o) /usr/conf/lib/libhp-ux.a(resume.o) /usr/conf/lib/libhp-ux.a(sem_alpha.o) /usr/conf/lib/libhp-ux.a(subr_ksleep.o) /usr/conf/lib/libhp-ux.a(subr_timers.o) /usr/conf/lib/libhp-ux.a(sysV_shm.o) /usr/conf/lib/libhp-ux.a(trap.o) /usr/conf/lib/libhp-ux.a(ulbcopy.o) /usr/conf/lib/libhp-ux.a(vfs.o) /usr/conf/lib/libhp-ux.a(vfs_bio.o) /usr/conf/lib/libhp-ux.a(vfs_vm.o) /usr/conf/lib/libhp-ux.a(vm_machdep.o) /usr/conf/lib/libhp-ux.a(vm_machreg.o) /usr/conf/lib/libhp-ux.a(vm_mmap.o) /usr/conf/lib/libhp-ux.a(vm_pdir1_1.o) /usr/conf/lib/libhp-ux.a(vm_pdir2_0.o) /usr/conf/lib/libhp-ux.a(vm_pregion.o) /usr/conf/lib/libhp-ux.a(vm_region.o) /usr/conf/lib/libhp-ux.a(vm_sched.o) /usr/conf/lib/libhp-ux.a(vm_superpage.o) /usr/conf/lib/libhp-ux.a(vm_text.o) /usr/conf/lib/libhp-ux.a(vm_vas.o) /usr/conf/lib/libhp-ux.a(vm_vhand.o) /usr/conf/lib/liblvm.a(lv_block.o) /usr/conf/lib/liblvm.a(lv_cluster_lock.o) /usr/conf/lib/liblvm.a(lv_defect.o) /usr/conf/lib/liblvm.a(lv_hp.o) /usr/conf/lib/liblvm.a(lv_ioctls.o) /usr/conf/lib/liblvm.a(lv_kdb.o) /usr/conf/lib/liblvm.a(lv_lvsubr.o) /usr/conf/lib/liblvm.a(lv_malloc.o) /usr/conf/lib/liblvm.a(lv_mircons.o) /usr/conf/lib/liblvm.a(lv_pbuf.o) /usr/conf/lib/liblvm.a(lv_phys.o) /usr/conf/lib/liblvm.a(lv_schedule.o) /usr/conf/lib/liblvm.a(lv_spare.o) /usr/conf/lib/liblvm.a(lv_strategy.o) /usr/conf/lib/liblvm.a(lv_stub.o) /usr/conf/lib/liblvm.a(lv_subr.o) /usr/conf/lib/liblvm.a(lv_syscalls.o) /usr/conf/lib/liblvm.a(lv_vgda.o) /usr/conf/lib/liblvm.a(lv_vgsa.o) /usr/conf/lib/liblvm.a(sh_vgsa.o) /usr/conf/lib/liblvm.a(slvm_comm.o) /usr/conf/lib/liblvm.a(slvm_schedule.o) /usr/conf/lib/libufs.a(ufs_alloc.o) /usr/conf/lib/libufs.a(ufs_vfsops.o) /usr/conf/lib/libufs.a(ufs_vnops.o) /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o) /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) /usr/conf/lib/libvxfs_adv.a(vx_sample_dmattr.o) /usr/conf/lib/libvxfs_base.a(vx_alloc.o) /usr/conf/lib/libvxfs_base.a(vx_attr.o) /usr/conf/lib/libvxfs_base.a(vx_bio.o) /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o) /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o) /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o) /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o) /usr/conf/lib/libvxfs_base.a(vx_iflush.o) /usr/conf/lib/libvxfs_base.a(vx_inode.o) /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) /usr/conf/lib/libvxfs_base.a(vx_lite.o) /usr/conf/lib/libvxfs_base.a(vx_log.o) /usr/conf/lib/libvxfs_base.a(vx_mount.o) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) /usr/conf/lib/libvxfs_base.a(vx_replay.o) /usr/conf/lib/libvxfs_base.a(vx_vfsops.o) /usr/conf/lib/libvxfs_base.a(vx_vm.o) /usr/conf/lib/libvxfs_base.a(vx_vnops.o) /usr/conf/master.d/core-hpux /usr/conf/space.h.d/core-hpux.h /usr/include/dmapi.h /usr/include/sys/audit.h /usr/include/sys/fs/vx_hpux.h what(1) Output: /usr/conf/h/audit.h: audit.h $Date: 97/04/21 13:54:38 $ $Revision: 1.10.98.5 $ PATCH_10.20 (PHKL_10800) /usr/conf/lib/libdmapi.a(kdm_core.o): kdm_core.c $Date: 97/09/02 13:10:59 $ $Revision: 1.2 .98.9 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libdmapi.a(vx_dmattr_table.o): vx_dmattr_table.c $Date: 97/10/15 15:06:43 $ $Revisi on: 1.2.98.5 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libhp-ux.a(asm_rv.o): asm_rv.s $Date: 97/09/22 17:37:18 $ $Revision: 1.57 .98.13 $ PATCH_10.20 (PHKL_12633) /usr/conf/lib/libhp-ux.a(asm_scall.o): asm_scall.s $Date: 96/11/22 10:45:59 $ $Revision: 1 .39.98.6 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(asm_utl.o): asm_utl.s $Date: 96/11/22 10:49:42 $ $Revision: 1.1 17.98.10 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(asm_vm_pdir.o): asm_vm_pdir.s $Date: 97/05/02 01:58:51 $ $Revision: 1.2.98.5 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(bcopy.o): bcopy.s $Date: 96/11/22 10:51:06 $ $Revision: 1.7.9 8.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(btlb.o): btlb.c $Date: 97/05/02 02:00:53 $ $Revision: 1.9. 98.4 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(bzero.o): bzero.s $Date: 96/11/22 10:52:32 $ $Revision: 1.9.9 8.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(clock.o): clock.c $Date: 97/01/23 16:09:43 $ $Revision: 1.39. 98.4 $ PATCH_10.20 (PHKL_9919) /usr/conf/lib/libhp-ux.a(cpd.o): cpd.c $Date: 96/10/26 09:39:05 $ $Revision: 1.9.98.8 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(dump.o): dump.c $Date: 96/10/26 09:49:44 $ $Revision: 1.11.98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(flipper.o): flipper.c $Date: 97/03/31 14:58:19 $ $Revision: 1.3. 98.8 $ PATCH_10.20 (PHKL_10554) /usr/conf/lib/libhp-ux.a(hdl_fault.o): hdl_fault.c $Date: 97/05/02 02:00:56 $ $Revision: 1.13.98.11 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(hdl_init.o): hdl_init.c $Date: 96/08/26 22:38:17 $ $Revision: 1.9.98.5 $ PATCH_10.20 (PHKL_8346) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o): hdl_mprotect.c $Date: 96/11/20 10:52:46 $ $Revision : 1.4.98.3 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(hdl_policy.o): hdl_policy.c $Date: 97/05/02 02:00:58 $ $Revision: 1.15.98.11 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(hdl_trans.o): hdl_trans.c $Date: 96/11/21 16:23:49 $ $Revision: 1.12.98.11 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(init_main.o): init_main.c $Date: 97/06/17 15:09:59 $ $Revision: 1.120.98.13 $ PATCH_10.20 (PHKL_11406) /usr/conf/lib/libhp-ux.a(interrupt.o): interrupt.s $Date: 97/03/31 13:22:48 $ $Revision: 1 .12.98.10 $ PATCH_10.20 (PHKL_10554) /usr/conf/lib/libhp-ux.a(kern_exec.o): kern_exec.c $Date: 97/09/03 18:56:26 $ $Revision: 1.93.98.24 $ PATCH_10.20 (PHKL_12397) /usr/conf/lib/libhp-ux.a(kern_fork.o): kern_fork.c $Date: 97/05/02 02:02:56 $ $Revision: 1.71.98.18 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(kern_kload.o): kern_kload.c $Date: 97/05/02 02:02:58 $ $Revision : 1.4.98.5 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(kern_mman.o): kern_mman.c $Date: 97/04/09 11:33:14 $ $Revision: 1.35.98.5 $ PATCH_10.20 (PHKL_10689) /usr/conf/lib/libhp-ux.a(kern_sig.o): kern_sig.c $Date: 97/05/02 02:03:00 $ $Revision: 1.66.98.4 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(lbcopy.o): lbcopy.s $Date: 97/05/02 16:44:13 $ $Revision: 1.7. 98.6 $ PATCH_10.20 (PHKL_10932) /usr/conf/lib/libhp-ux.a(lbzero.o): lbzero.s $Date: 96/11/22 10:57:29 $ $Revision: 1.9. 98.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(lv_config.o): lv_config.c $Date: 97/10/15 15:28:02 $ $Revision: 1. 13.98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libhp-ux.a(lv_lvm.o): lv_lvm.c $Date: 97/10/15 15:30:56 $ $Revision: 1.3.9 8.3 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libhp-ux.a(lw_scall.o): lw_scall.s $Date: 97/05/02 02:01:00 $ $Revision: 1.18.98.7 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(machdep.o): machdep.c $Date: 97/09/23 11:23:01 $ $Revision: 1.12 6.98.8 $ PATCH_10.20 (PHKL_12662) /usr/conf/lib/libhp-ux.a(outlaw.o): outlaw.c $Date: 96/11/22 11:17:11 $ $Revision: 1.2.98.3 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(pgcopy.o): pgcopy.s $Date: 96/11/22 18:05:02 $ $Revision: 1.7. 98.5 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(pm_clockint.o): pm_clockint.c $Date: 97/09/23 11:09:00 $ $Revision: 1.7.98.7 $ PATCH_10.20 (PHKL_12662) /usr/conf/lib/libhp-ux.a(pm_config.o): pm_config.c $Date: 97/06/17 15:09:55 $ $Revision: 1. 6.98.8 $ PATCH_10.20 (PHKL_11406) /usr/conf/lib/libhp-ux.a(pm_context.o): pm_context.c $Date: 96/08/26 22:35:25 $ $Revision : 1.3.98.6 $ PATCH_10.20 (PHKL_8346) /usr/conf/lib/libhp-ux.a(pm_core.o): pm_core.c $Date: 97/05/02 02:03:02 $ $Revision: 1 .9.98.9 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(pm_policy.o): pm_policy.c $Date: 97/09/08 22:29:55 $ $Revision: 1.7.98.8 $ PATCH_10.20 (PHKL_12042) /usr/conf/lib/libhp-ux.a(pm_proc.o): pm_proc.c $Date: 97/06/11 17:26:34 $ $Revision: 1.13 .98.12 $ PATCH_10.20 (PHKL_11339) /usr/conf/lib/libhp-ux.a(pm_procdup.o): pm_procdup.c $Date: 97/05/02 02:03:06 $ $Revision : 1.11.98.13 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(pm_ptrace.o): pm_ptrace.c $Date: 97/05/02 02:03:08 $ $Revision: 1. 6.98.25 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(pm_resource.o): pm_resource.c $Date: 97/06/11 17:28:51 $ $Revision: 1.7.98.14 $ PATCH_10.20 (PHKL_11339) /usr/conf/lib/libhp-ux.a(pm_rtsched.o): pm_rtsched.c $Date: 97/09/08 22:31:38 $ $Revision: 1 .6.98.4 $ PATCH_10.20 (PHKL_12042) /usr/conf/lib/libhp-ux.a(pm_sendsig.o): pm_sendsig.c $Date: 97/05/02 02:01:02 $ $Revision : 1.4.98.12 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(pm_signal.o): pm_signal.c $Date: 97/08/08 16:59:26 $ $Revision: 1.6.98.17 $ PATCH_10.20 (PHKL_12073) /usr/conf/lib/libhp-ux.a(pm_swtch.o): pm_swtch.c $Date: 97/09/08 22:32:43 $ $Revision: 1.7.98.17 $ PATCH_10.20 (PHKL_12042) /usr/conf/lib/libhp-ux.a(pm_threads.o): pm_threads.c $Date: 97/05/02 02:03:13 $ $Revision : 1.3.98.11 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(pm_timers.o): pm_timers.c $Date: 97/09/11 17:55:12 $ $Revision: 1. 7.98.10 $ PATCH_10.20 (PHKL_12409) /usr/conf/lib/libhp-ux.a(protection.o): protection.s $Date: 96/11/22 11:00:38 $ $Revision: 1.10.98.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(pstat.o): pstat.c $Date: 97/09/03 18:53:40 $ $Revision: 1.18.9 8.23 $ PATCH_10.20 (PHKL_12397) /usr/conf/lib/libhp-ux.a(resume.o): resume.s $Date: 96/11/22 11:01:44 $ $Revision: 1.11 .98.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(sem_alpha.o): sem_alpha.c $Date: 96/11/20 16:33:04 $ $Revision: 1.11.98.5 $ PATCH_10.20 (PHKL_9273) /usr/conf/lib/libhp-ux.a(subr_ksleep.o): subr_ksleep.c $Date: 97/05/02 02:03:21 $ $Revisio n: 1.1.98.13 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(subr_timers.o): subr_timers.c $Date: 97/08/13 17:10:50 $ $Revision: 1.8.98.13 $ PATCH_10.20 (PHKL_12110) /usr/conf/lib/libhp-ux.a(sysV_shm.o): sysV_shm.c $Date: 96/11/20 11:01:21 $ $Revision: 1.54.98.5 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(trap.o): trap.c $Date: 97/09/23 11:22:02 $ $Revision: 1.16 9.98.14 $ PATCH_10.20 (PHKL_12662) /usr/conf/lib/libhp-ux.a(ulbcopy.o): ulbcopy.s $Date: 97/05/02 17:43:33 $ $Revision: 1.4. 98.8 $ PATCH_10.20 (PHKL_10932) /usr/conf/lib/libhp-ux.a(vfs.o): vfs.c $Date: 97/10/15 14:54:39 $ $Revision: 1.25.98. 13 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libhp-ux.a(vfs_bio.o): vfs_bio.c $Date: 97/10/15 16:56:14 $ $Revision: 1.26 .98.21 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libhp-ux.a(vfs_vm.o): vfs_vm.c $Date: 97/10/15 14:57:20 $ $Revision: 1.17. 98.18 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libhp-ux.a(vm_machdep.o): vm_machdep.c $Date: 97/05/02 02:00:47 $ $Revision: 1.157.98.32 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(vm_machreg.o): vm_machreg.c $Date: 97/05/02 02:01:05 $ $Revision : 1.17.98.19 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(vm_mmap.o): vm_mmap.c $Date: 96/11/20 11:02:00 $ $Revision: 1.17.98.14 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vm_pdir1_1.o): vm_pdir1_1.c $Date: 97/05/02 02:00:37 $ $Revision: 1.3.98.14 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(vm_pdir2_0.o): vm_pdir2_0.c $Date: 97/06/18 13:12:17 $ $Revision: 1 .3.98.11 $ PATCH_10.20 (PHKL_11408) /usr/conf/lib/libhp-ux.a(vm_pregion.o): vm_pregion.c $Date: 97/04/07 13:34:27 $ $Revision: 1.16.98.13 $ PATCH_10.20 (PHKL_10643) /usr/conf/lib/libhp-ux.a(vm_region.o): vm_region.c $Date: 96/11/20 11:01:58 $ $Revision: 1.20.98.4 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vm_sched.o): vm_sched.c $Date: 96/11/20 11:01:54 $ $Revision: 1.58.98.9 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vm_superpage.o): vm_superpage.c $Date: 97/07/22 16:29:07 $ $Revisi on: 1.2.98.5 $ PATCH_10.20 (PHKL_11902) /usr/conf/lib/libhp-ux.a(vm_text.o): vm_text.c $Date: 97/03/03 12:25:55 $ $Revision: 1 .56.98.9 $ PATCH_10.20 (PHKL_10257) /usr/conf/lib/libhp-ux.a(vm_vas.o): vm_vas.c $Date: 97/07/07 15:53:17 $ $Revision: 1.18.98.16 $ PATCH_10.20 (PHKL_11696) /usr/conf/lib/libhp-ux.a(vm_vhand.o): vm_vhand.c $Date: 96/11/20 11:02:03 $ $Revision: 1.20.98.5 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/liblvm.a(lv_block.o): lv_block.c $Date: 97/10/15 15:27:22 $ $Revision: 1.1 3.98.5 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_cluster_lock.o): lv_cluster_lock.c $Date: 97/10/15 15:27:47 $ $Revisi on: 1.10.98.5 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_defect.o): lv_defect.c $Date: 97/10/15 15:28:20 $ $Revision: 1. 16.98.6 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_hp.o): lv_hp.c $Date: 97/10/15 15:28:40 $ $Revision: 1.18.9 8.21 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_ioctls.o): lv_ioctls.c $Date: 97/10/15 15:29:29 $ $Revision: 1. 18.98.19 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_kdb.o): lv_kdb.c $Date: 97/10/15 17:16:54 $ $Revision: 1.9.9 8.4 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_lvsubr.o): lv_lvsubr.c $Date: 97/10/15 15:31:26 $ $Revision: 1. 15.98.17 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_malloc.o): lv_malloc.c $Date: 97/10/15 15:31:46 $ $Revision: 1. 11.98.4 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_mircons.o): lv_mircons.c $Date: 97/10/15 15:32:02 $ $Revision: 1 .14.98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_pbuf.o): lv_pbuf.c $Date: 97/10/15 15:32:20 $ $Revision: 1.11 .98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_phys.o): lv_phys.c $Date: 97/10/15 15:32:37 $ $Revision: 1.14 .98.12 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_schedule.o): lv_schedule.c $Date: 97/10/15 15:32:55 $ $Revision: 1.18.98.11 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_spare.o): lv_spare.c $Date: 97/10/15 15:33:09 $ $Revision: 1.3 .98.6 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_strategy.o): lv_strategy.c $Date: 97/10/15 15:33:32 $ $Revision: 1.14.98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_stub.o): lv_stub.c $Date: 96/10/25 20:54:05 $ $Revision: 1.13 .98.2 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_subr.o): lv_subr.c $Date: 97/10/15 15:33:47 $ $Revision: 1.18 .98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_syscalls.o): lv_syscalls.c $Date: 97/10/15 15:34:06 $ $Revision: 1.14.98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_vgda.o): lv_vgda.c $Date: 97/10/15 15:34:41 $ $Revision: 1.18 .98.4 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_vgsa.o): lv_vgsa.c $Date: 97/10/15 15:35:07 $ $Revision: 1.14 .98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(sh_vgsa.o): sh_vgsa.c $Date: 97/06/26 12:07:10 $ $Revision: 1.3 .98.9 $ PATCH_10.20 (PHKL_11561) /usr/conf/lib/liblvm.a(slvm_comm.o): slvm_comm.c $Date: 96/10/25 17:03:40 $ $Revision: 1. 3.98.4 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(slvm_schedule.o): slvm_schedule.c $Date: 96/10/25 17:03:49 $ $Revision : 1.3.98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libufs.a(ufs_alloc.o): ufs_alloc.c $Date: 97/10/15 16:50:46 $ $Revision: 1. 38.98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libufs.a(ufs_vfsops.o): ufs_vfsops.c $Date: 97/10/15 14:02:56 $ $Revision: 1 .20.98.13 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libufs.a(ufs_vnops.o): ufs_vnops.c $Date: 97/10/15 14:28:25 $ $Revision: 1. 30.98.20 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o): vx_dmattr.c $Date: 97/10/15 15:06:19 $ $Revision: 1. 2.98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o): vx_kdmi.c $Date: 97/10/15 15:22:37 $ $Revision: 1.2. 98.15 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o): vx_reorg.c $Date: 97/10/15 15:25:14 $ $Revision: 1.6 .98.14 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_adv.a(vx_sample_dmattr.o): vx_sample_dmattr.c $Date: 97/10/15 15:25:55 $ $Revis ion: 1.2.98.9 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_alloc.o): vx_alloc.c $Date: 97/10/15 14:58:22 $ $Revision: 1.5 .98.15 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_attr.o): vx_attr.c $Date: 97/10/15 15:00:16 $ $Revision: 1.7. 98.11 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_bio.o): vx_bio.c $Date: 97/10/15 15:02:52 $ $Revision: 1.7.9 8.11 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o): vx_bmapext4.c $Date: 97/10/15 15:05:13 $ $Revision: 1.2.98.13 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o): vx_bmaptyped.c $Date: 97/10/15 15:05:31 $ $Revision: 1.2.98.18 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o): vx_bsdquota.c $Date: 97/10/15 15:05:46 $ $Revision: 1.7.98.14 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o): vx_dmstubs.c $Date: 97/10/15 15:07:05 $ $Revision: 1 .2.98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o): vx_fsetsubr.c $Date: 97/10/15 15:07:36 $ $Revision: 1.2.98.14 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o): vx_hpuxsubr.c $Date: 97/10/15 15:20:24 $ $Revision: 1.7.98.14 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_iflush.o): vx_iflush.c $Date: 97/10/15 15:19:38 $ $Revision: 1. 6.98.15 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_inode.o): vx_inode.c $Date: 97/10/15 15:20:59 $ $Revision: 1.7 .98.20 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_itrunc.o): vx_itrunc.c $Date: 97/10/15 15:22:10 $ $Revision: 1. 7.98.19 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_lite.o): vx_lite.c $Date: 97/10/15 15:23:00 $ $Revision: 1.4. 98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_log.o): vx_log.c $Date: 97/10/15 15:24:16 $ $Revision: 1.6.9 8.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_mount.o): vx_mount.c $Date: 97/10/15 15:24:32 $ $Revision: 1.7 .98.16 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o): vx_rdwri.c $Date: 97/10/15 15:24:56 $ $Revision: 1.7 .98.25 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_replay.o): vx_replay.c $Date: 97/10/15 15:25:29 $ $Revision: 1. 2.98.14 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_vfsops.o): vx_vfsops.c $Date: 97/10/15 15:26:15 $ $Revision: 1. 7.98.15 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_vm.o): vx_vm.c $Date: 97/10/15 15:26:32 $ $Revision: 1.7.98 .16 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_vnops.o): vx_vnops.c $Date: 97/10/15 15:26:53 $ $Revision: 1.8 .98.25 $ PATCH_10.20 (PHKL_12901) /usr/conf/master.d/core-hpux: core-hpux $Date: 97/06/17 16:43:58 $ $Revision: 1. 6.98.15 $ PATCH_10.20 (PHKL_11406) /usr/conf/space.h.d/core-hpux.h: core-hpux.h $Date: 97/06/17 16:40:59 $ $Revision: 1.6.98.13 $ PATCH_10.20 (PHKL_11406) /usr/include/dmapi.h: dmapi.h: $Revision: 1.2.98.7 $ $Date: 97/09/02 13:03 :46 $ dmapi.h $Date: 97/09/02 13:03:46 $ $Revision: 1. 2.98.7 $ PATCH_10.20 (PHKL_12088) src/kernel/dmapi/dmapi.h 2.12 14 Aug 1996 18:51:12 - */ /usr/include/sys/audit.h: audit.h $Date: 97/04/21 13:54:38 $ $Revision: 1.10.98.5 $ PATCH_10.20 (PHKL_10800) /usr/include/sys/fs/vx_hpux.h: vx_hpux.h: $Revision: 1.7.98.14 $ $Date: 97/09/03 09 :28:45 $ PATCH_10.20 (PHKL_12088) src/kernel/vxfs/vx_hpux.h 2.14.4.3 30 Jul 1996 17:05 :11 - */ fshp:src/kernel/vxfs/vx_hpux.h 2.14.4.3 cksum(1) Output: 309306691 13103 /usr/conf/h/audit.h 2308637956 48664 /usr/conf/lib/libdmapi.a(kdm_core.o) 3851147702 1784 /usr/conf/lib/libdmapi.a(vx_dmattr_table.o) 3946416601 19540 /usr/conf/lib/libhp-ux.a(asm_rv.o) 3109290296 7640 /usr/conf/lib/libhp-ux.a(asm_scall.o) 1231112847 18512 /usr/conf/lib/libhp-ux.a(asm_utl.o) 1650397953 4584 /usr/conf/lib/libhp-ux.a(asm_vm_pdir.o) 3455675956 4668 /usr/conf/lib/libhp-ux.a(bcopy.o) 4158269677 10276 /usr/conf/lib/libhp-ux.a(btlb.o) 4124458617 2432 /usr/conf/lib/libhp-ux.a(bzero.o) 1053092530 19912 /usr/conf/lib/libhp-ux.a(clock.o) 4114346575 11604 /usr/conf/lib/libhp-ux.a(cpd.o) 797819625 12752 /usr/conf/lib/libhp-ux.a(dump.o) 1084924137 8028 /usr/conf/lib/libhp-ux.a(flipper.o) 3189247447 13408 /usr/conf/lib/libhp-ux.a(hdl_fault.o) 555026448 6348 /usr/conf/lib/libhp-ux.a(hdl_init.o) 997333578 15648 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 2213765960 11900 /usr/conf/lib/libhp-ux.a(hdl_policy.o) 2718340289 10016 /usr/conf/lib/libhp-ux.a(hdl_trans.o) 3231555571 18508 /usr/conf/lib/libhp-ux.a(init_main.o) 3476683986 6584 /usr/conf/lib/libhp-ux.a(interrupt.o) 1125379815 16964 /usr/conf/lib/libhp-ux.a(kern_exec.o) 303743927 15144 /usr/conf/lib/libhp-ux.a(kern_fork.o) 50317043 6492 /usr/conf/lib/libhp-ux.a(kern_kload.o) 4163060998 3948 /usr/conf/lib/libhp-ux.a(kern_mman.o) 2216617969 10284 /usr/conf/lib/libhp-ux.a(kern_sig.o) 3276898957 6160 /usr/conf/lib/libhp-ux.a(lbcopy.o) 300166288 2428 /usr/conf/lib/libhp-ux.a(lbzero.o) 630638081 26628 /usr/conf/lib/libhp-ux.a(lv_config.o) 1000939560 156552 /usr/conf/lib/libhp-ux.a(lv_lvm.o) 228543399 7008 /usr/conf/lib/libhp-ux.a(lw_scall.o) 2111739438 30444 /usr/conf/lib/libhp-ux.a(machdep.o) 2457463992 3348 /usr/conf/lib/libhp-ux.a(outlaw.o) 3029803182 2988 /usr/conf/lib/libhp-ux.a(pgcopy.o) 2352687526 6200 /usr/conf/lib/libhp-ux.a(pm_clockint.o) 1701549902 5388 /usr/conf/lib/libhp-ux.a(pm_config.o) 3811483497 2236 /usr/conf/lib/libhp-ux.a(pm_context.o) 1145535485 6872 /usr/conf/lib/libhp-ux.a(pm_core.o) 862275123 15948 /usr/conf/lib/libhp-ux.a(pm_policy.o) 3933929381 17908 /usr/conf/lib/libhp-ux.a(pm_proc.o) 3189023695 6680 /usr/conf/lib/libhp-ux.a(pm_procdup.o) 3682830469 15732 /usr/conf/lib/libhp-ux.a(pm_ptrace.o) 775863340 7076 /usr/conf/lib/libhp-ux.a(pm_resource.o) 4277200061 8728 /usr/conf/lib/libhp-ux.a(pm_rtsched.o) 1066734922 16212 /usr/conf/lib/libhp-ux.a(pm_sendsig.o) 4157339108 11544 /usr/conf/lib/libhp-ux.a(pm_signal.o) 2012431499 20412 /usr/conf/lib/libhp-ux.a(pm_swtch.o) 3233056101 12032 /usr/conf/lib/libhp-ux.a(pm_threads.o) 1547729896 6456 /usr/conf/lib/libhp-ux.a(pm_timers.o) 18384036 11264 /usr/conf/lib/libhp-ux.a(protection.o) 645611836 25956 /usr/conf/lib/libhp-ux.a(pstat.o) 2317800830 3876 /usr/conf/lib/libhp-ux.a(resume.o) 3665684469 9532 /usr/conf/lib/libhp-ux.a(sem_alpha.o) 3306390220 10616 /usr/conf/lib/libhp-ux.a(subr_ksleep.o) 1319709682 10572 /usr/conf/lib/libhp-ux.a(subr_timers.o) 925297696 8712 /usr/conf/lib/libhp-ux.a(sysV_shm.o) 1671896846 23616 /usr/conf/lib/libhp-ux.a(trap.o) 3959296490 6328 /usr/conf/lib/libhp-ux.a(ulbcopy.o) 381024053 20444 /usr/conf/lib/libhp-ux.a(vfs.o) 1889856450 28960 /usr/conf/lib/libhp-ux.a(vfs_bio.o) 1439345029 29828 /usr/conf/lib/libhp-ux.a(vfs_vm.o) 3286507644 91100 /usr/conf/lib/libhp-ux.a(vm_machdep.o) 3448592545 14300 /usr/conf/lib/libhp-ux.a(vm_machreg.o) 133406500 21604 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 290807052 30900 /usr/conf/lib/libhp-ux.a(vm_pdir1_1.o) 1469266556 53368 /usr/conf/lib/libhp-ux.a(vm_pdir2_0.o) 1265397058 12324 /usr/conf/lib/libhp-ux.a(vm_pregion.o) 1266053234 11316 /usr/conf/lib/libhp-ux.a(vm_region.o) 3119256795 24816 /usr/conf/lib/libhp-ux.a(vm_sched.o) 1951534836 9992 /usr/conf/lib/libhp-ux.a(vm_superpage.o) 2800961341 14444 /usr/conf/lib/libhp-ux.a(vm_text.o) 1841465344 13360 /usr/conf/lib/libhp-ux.a(vm_vas.o) 1919993849 14372 /usr/conf/lib/libhp-ux.a(vm_vhand.o) 2971522811 2632 /usr/conf/lib/liblvm.a(lv_block.o) 303437109 9964 /usr/conf/lib/liblvm.a(lv_cluster_lock.o) 1367795889 12596 /usr/conf/lib/liblvm.a(lv_defect.o) 2042175758 83132 /usr/conf/lib/liblvm.a(lv_hp.o) 1071502609 32060 /usr/conf/lib/liblvm.a(lv_ioctls.o) 872237003 720 /usr/conf/lib/liblvm.a(lv_kdb.o) 1466831003 36100 /usr/conf/lib/liblvm.a(lv_lvsubr.o) 2374339579 2544 /usr/conf/lib/liblvm.a(lv_malloc.o) 4288668251 17420 /usr/conf/lib/liblvm.a(lv_mircons.o) 2331070456 6576 /usr/conf/lib/liblvm.a(lv_pbuf.o) 690758779 7732 /usr/conf/lib/liblvm.a(lv_phys.o) 294142816 26368 /usr/conf/lib/liblvm.a(lv_schedule.o) 1405315567 36420 /usr/conf/lib/liblvm.a(lv_spare.o) 3767976309 7176 /usr/conf/lib/liblvm.a(lv_strategy.o) 4115391771 732 /usr/conf/lib/liblvm.a(lv_stub.o) 2518086102 10064 /usr/conf/lib/liblvm.a(lv_subr.o) 929532253 13528 /usr/conf/lib/liblvm.a(lv_syscalls.o) 1382667354 9108 /usr/conf/lib/liblvm.a(lv_vgda.o) 3655615117 12600 /usr/conf/lib/liblvm.a(lv_vgsa.o) 58167558 42028 /usr/conf/lib/liblvm.a(sh_vgsa.o) 2159002800 27264 /usr/conf/lib/liblvm.a(slvm_comm.o) 4188283521 6724 /usr/conf/lib/liblvm.a(slvm_schedule.o) 2981279314 17624 /usr/conf/lib/libufs.a(ufs_alloc.o) 62866743 20412 /usr/conf/lib/libufs.a(ufs_vfsops.o) 1860948998 33284 /usr/conf/lib/libufs.a(ufs_vnops.o) 760609908 2964 /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o) 1161747513 24748 /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o) 3433476596 20344 /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) 3582414206 4592 /usr/conf/lib/ libvxfs_adv.a(vx_sample_dmattr.o) 3334723579 28228 /usr/conf/lib/libvxfs_base.a(vx_alloc.o) 3571863284 37648 /usr/conf/lib/libvxfs_base.a(vx_attr.o) 3014150328 10452 /usr/conf/lib/libvxfs_base.a(vx_bio.o) 2280461010 10824 /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o) 1802836350 18340 /usr/conf/lib/ libvxfs_base.a(vx_bmaptyped.o) 3842610421 29032 /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o) 1851387969 4928 /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o) 2357795855 21168 /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) 1502964316 16292 /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o) 3531998086 29724 /usr/conf/lib/libvxfs_base.a(vx_iflush.o) 347435613 44852 /usr/conf/lib/libvxfs_base.a(vx_inode.o) 1839120165 14412 /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) 1857910709 3600 /usr/conf/lib/libvxfs_base.a(vx_lite.o) 945378166 9620 /usr/conf/lib/libvxfs_base.a(vx_log.o) 800355575 28312 /usr/conf/lib/libvxfs_base.a(vx_mount.o) 4227507470 35424 /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) 1686960615 7052 /usr/conf/lib/libvxfs_base.a(vx_replay.o) 3337737873 15156 /usr/conf/lib/libvxfs_base.a(vx_vfsops.o) 3054202871 11924 /usr/conf/lib/libvxfs_base.a(vx_vm.o) 1359133065 26564 /usr/conf/lib/libvxfs_base.a(vx_vnops.o) 245948872 16914 /usr/conf/master.d/core-hpux 1898168158 18969 /usr/conf/space.h.d/core-hpux.h 1315928410 16548 /usr/include/dmapi.h 309306691 13103 /usr/include/sys/audit.h 1556434298 9724 /usr/include/sys/fs/vx_hpux.h Patch Conflicts: None Patch Dependencies: s700: 10.20: PHCO_11909 PHCO_8871 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_7776 PHKL_7870 PHKL_7899 PHKL_7951 PHKL_8084 PHKL_8203 PHKL_8294 PHKL_8331 PHKL_8346 PHKL_8481 PHKL_8532 PHKL_8716 PHKL_8953 PHKL_8999 PHKL_9075 PHKL_9151 PHKL_9153 PHKL_9273 PHKL_9361 PHKL_9370 PHKL_9372 PHKL_9517 PHKL_9529 PHKL_9569 PHKL_9711 PHKL_9909 PHKL_9919 PHKL_9931 PHKL_10176 PHKL_10199 PHKL_10234 PHKL_10257 PHKL_10288 PHKL_10316 PHKL_10452 PHKL_10554 PHKL_10643 PHKL_10675 PHKL_10689 PHKL_10757 PHKL_10800 PHKL_10821 PHKL_10930 PHKL_10932 PHKL_10953 PHKL_10966 PHKL_11006 PHKL_11013 PHKL_11039 PHKL_11085 PHKL_11238 PHKL_11244 PHKL_11247 PHKL_11321 PHKL_11339 PHKL_11406 PHKL_11408 PHKL_11471 PHKL_11519 PHKL_11561 PHKL_11607 PHKL_11637 PHKL_11696 PHKL_11730 PHKL_11733 PHKL_11766 PHKL_11860 PHKL_11902 PHKL_12042 PHKL_12073 PHKL_12088 PHKL_12100 PHKL_12110 PHKL_12397 PHKL_12409 PHKL_12601 PHKL_12633 PHKL_12662 PHKL_12669 Equivalent Patches: PHKL_12902: s800: 10.20 Patch Package Size: 2360 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_12901 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_12901.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_12901.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_12901. 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_12901.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_12901.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: This kernel patch need to work with the command patch PHCO_11909; please install PHCO_11909 with this patch. Installed alone, this kernel patch will not solve the fsck problem. If you are planning to install the advanced VxFS product (AdvJournalFS.VXFS-ADV-KRN), it is imperative that this patch, and all listed superseded patches, be removed from the system via swremove(1M) before the actual product installation. After the installation of the advanced VxFS product has completed, this patch can be re-installed. (It is not necessary to re-install superseded patches.) All patches listed in the Supersedes field are subject to this behavior and need to be removed before installing the advanced VxFS product. After running swremove(1M), use the swlist(1M) command to insure that none of the previous patches were restored during the removal process. If one was, remove it using swremove(1M). When this patch is installed the default environment size is 20478 bytes. To enable the system to use the larger environment size of 2048000 bytes, the following steps must be followed. 1. A new tunable called `large_ncargs_enabled' must be defined in the sytem file in the following manner large_ncargs_enabled 1 2. A new kernel must be built (using this system file) and the system rebooted. To return to the default environment size, the new tunable needs to be either removed from the system file, or its value set to zero. A new kernel should then be built (using the modified system file) and the machine rebooted. Due to the number of objects in this patch, the customization phase of the update may take more than 10 minutes. During that time the system will not appear to make forward progress, but it will actually be installing the objects.