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