Patch Name: PHKL_9404 Patch Description: s700 10.01 JFS, LVM, UFS, pstat cumulative patch Creation Date: 96/12/04 Post Date: 96/12/06 Hardware Platforms - OS Releases: s700: 10.01 Products: N/A Filesets: AdvJournalFS.VXFS-ADV-KRN JournalFS.VXFS-BASE-KRN JournalFS.VXFS-PRG LVM.LVM-KRN OS-Core.CORE-KRN ProgSupport.C-INC Automatic Reboot?: Yes Status: General Superseded Critical: No (superseded patches were critical) PHKL_8757: HANG PHKL_8731: CORRUPTION PHKL_8602: PANIC PHKL_8391: HANG This patch adds a new feature to LVM. The feature is provided to customers who need the option to limit the time LVM waits for powerfailed disks in given logical volumes to return. PHKL_8386: CORRUPTION PHKL_8199: HANG PHKL_8080: ABORT PHKL_7901: PANIC OTHER The setuid fix is non-critical. PHKL_7846: PANIC PHKL_7578: CORRUPTION PHKL_7508: PANIC CORRUPTION PHKL_7306: OTHER increase limit PHKL_7250: HANG PHKL_7217: PANIC HANG CORRUPTION PHKL_7205: ABORT PHKL_7185: CORRUPTION PHKL_7037: PANIC PHKL_7024: PANIC PHKL_7015: PANIC OTHER O_DSYNC flag ignored PHKL_6888: PANIC PHKL_6764: HANG PHKL_6674: PANIC PHKL_6494: PANIC OTHER vgchange fails with "Invalid argument" PHKL_6462: CORRUPTION PHKL_6024: CORRUPTION PANIC PHKL_5888: PANIC PHKL_5737: HANG Path Name: /hp-ux_patches/s700/10.X/PHKL_9404 Symptoms: PHKL_9404: Executables residing on a VxFS (JFS) file-system would no longer execute after being marked for VX_DIRECT operation. A typical scenario would be as follow: # cd /vxfs # cp /usr/bin/ksh . # ./ksh # cc vxdirect.c -o vxdirect # ./vxdirect ./ksh # ./ksh ./ksh: ./ksh: cannot execute See the vxfsio(7) man pages for details on VX_DIRECT. PHKL_9263: When MMF activity on VxFS files is very high for a given process (like a process doing a lot of mmap access), then the vhand process may want to pageout some pages onto the VxFS file. On very rare occasion, this pageout process was in a situation were the pageout write can't be satisfied without waiting another ressource (like memory). Then, since vhand can't wait, the page was marked zomb, and later a fault on that page from the process made that process killed by the OS. PHKL_8757: UFS hangs with heavy use of a filesystem branch by multiple processes. The hang is due to a three way deadlock with inodes and bufs being held but not released. This shows up with the buf being both B_BUSY and B_DONE but not being released. PHKL_8731: Under OnlineJFS, when very large writes (e.g. >phymem/16) are done to JFS file(s), old data can appear in the middle of the newly written file(s). PHKL_8580: After call to pstat_getmsg(), all accesses to the message queue pstat_getmsg() was called hang. PHKL_8602: trap 15 panic in pstat_fileinfo() PHKL_8391: This change supports a new -t switch for lvchange allowing the administrator the option to limit the time lvm holds i/os to be retried on logical volumes when disks are powerfailed. Without using this option, LVM will hold the i/os as long as there is is one disk where the data resides which may eventually return. Using this option would cause LVM to give up on the powerfailed disk and return i/o errors to the user application using the logical volume. This feature is obviously not to be used indiscriminately. For many High Availability applications, having i/os held in kernel indefinitely is not acceptable. Most customers should not need to use the new switch. Be sure to read the Special Installation Instructions for this and all VxFS patches. PHKL_8386: Data corruption can occur if HP OnLineJFS is installed and a very large write (over a megabyte) is done to a JFS file. A sequence of 1 - 8191 zeros can appear in the middle of the data just written. PHKL_8282: The customer is unable to pass arg/env strings to EXEC containing more than 20k chars. They require the limit to be raised to at least 100k. PHKL_8199: MP system hangs during panic. The LED shows system staying at INIT CB0B. Machine needs to be TOC'ed to save the core dump. PHKL_8080: LVM may return I/O's with errors instead of sending them to an alternate link. This patch also facilitates using "vgreduce -f" for physical volumes which have alternate links; without this patch "vgreduce -f" is not allowed on LVM disks with alternate links. PHKL_8024: Files created in setgid directories no longer inherit the gid of the directory. PHKL_7908: Running "strings" on a raw sar(1) output file can show some printable ASCII characters (sar ignores these). PHKL_7901: With a system running a heavy load using JFS on LVM, the following panic may occur: "lv_syncx: returning error: 5" The setuid bit will be removed on a JFS file when the file is modified even when run as root. PHKL_7846: lvreduce(1M) may cause a system panic, if it is used to reduce an lvol which was left inconsistent by a prior LVM operation. lvreduce(1M) could not be used to remove lvols that were somehow corrupted, if it was, the command would cause a system panic. PHKL_7666: Several types of symptoms may occur: - logins on NFS clients may receive incorrect access on NFS servers - files from NFS servers may appear to be owned by the wrong logins on NFS clients - setuid and setgid binaries available on NFS servers may allow client logins to run with incorrect access PHKL_7578: (1) Applications using ftruncate(2) on VxFS files could possibly loose data. This problem was reported with the Empress database. (2) msync(2) with the MS_SYNC flag on VxFS memory map files did not work as documented. Stale data could be found in the buffer cache when resuming file system operations, possibly resulting in data corruption. (3) Poor system performance when directories containing shared libraries, for example /usr, reside on a VxFS file-system. PHKL_7508: Three distinct problems/symptoms: 1: Applications reading VxFS files through the read(2) system call could get stale data from the buffer cache if the files were previously written through a Memory Mapped File. This is potential data corruption when using MMFs on VxFS. 2: "panic: data page fault", if using fsadm to resize a mounted VxFS filesystem with disk quotas 3: "vxfs: mesg 008: vx_direrr - /xxx file system inode x \ block y error 22" followed by erroneous indications that the filesystem is corrupt PHKL_7306: If the path for a script interpreter is longer than 32, then exec(2) fails. PHKL_7250: System hangs, seems unable to process filesystem I/O, although processes that need no filesystem interaction run. PHKL_7217: "panic: lv_validblk: invalid relocation status" or possible panics, system hang, or data corruption on systems with disks having bad blocks. Also, the same bad block was kept relocating until run out of spare. PHKL_7205: Attempting to remove linked text file when original file is busy gets ETXTBSY. PHKL_7185: lvmerge could merge an lvol back with all PEs marked as current and yet the syncing of stale LTGs had failed. lv_recover_ltg(k), which does the syncing, had no mechanism to return error to lv_table_reimage(k). lv_table_reimage(k) therefore returns success when this may not be the case. PHKL_7122: For very large /etc/passwd files, passwd command may return EDEADLK and print an error message about lockf deadlock detection. PHKL_7037: pvmove leads to panic: lv_reducelv extmap, when the mirrored logical volume contains unallocated physical extents (might caused by previous unsuccessful pvmove operation (kill -9). PHKL_7024: When a user is deactivating a volume group, the system panics with "lv_cache_deactivate inflight". PHKL_6675 fixes some cases and this patch fixes a special case. PHKL_7015: This fixes two separate VxFS (JFS) problems. 1) trap type 15 in vx_iget 2) O_DSYNC is ignored for VxFS filesystems PHKL_6987: Systems with /usr on a VxFS file-system were experiencing poor performance. PHKL_6951: VxFS reports "No space left on device" when reaching quota limit rather than "Disc quota exceeded" over NFS. PHKL_6888: The panic occurs when a user program calls msync with MS_INVALIDATE and then immediately tries to access the mmap'ed region. PHKL_6792: If /etc/lvmtab is out of date with the running kernel, vgcfgbackup fails. PHKL_6764: Rename deadlock: This deadlock occurs in the following situation: Process 1 is moving a directory to a new parent directory at the same time as Process 2 is doing a lookup on the new parent directory Process 1's directory is being moved into. Both processes will sleep forever and all accesses to both directories will also sleep. PHKL_6674: lv_cache_deactivate inflight panic PHKL_6529: None. This is a pstat enhancement. PHKL_6494: vgchange: Couldn't activate volume group "/dev/vgpam": Invalid argument panic with "lv_fixrootlv: could not find boot pvol" PHKL_6462: Booting in LVM maintenance mode after changing the path of a root disk can lead to one of two situations: (1) there is no device at the old path -- LVM sends a hard partition one write for the current boot disk to the underlying driver; (2) there is a non-LVM disk or non-boot LVM disk at the old path -- LVM writes to where the BDRA would be on that disk. The write is attempting to set the maintenance mode flag in the BDRA. Symptoms such as root file system corruption (for case 1), LVM meta-data corruption (for case 2), or disk data corruption (for case 2) could then be observed. This scenario is possible during any change of hardware path to an LVM root disk. In particular, the 10.01 K100, D200, D210, and D310 processor upgrade procedures are affected. PHKL_6448: LVM disk resynchronization fails when disk powerfails PHKL_6446: LVM metadata timeouts in multi-initiator configurations, especially with Nike, causing these error messages: lv_readvgats: Could not read VGDA 1 header & trailer \ from disk ... lv_readvgats: Could not read VGDA 2 header & trailer \ from disk ... lv_readvgats: Could not read VGSA 1 header & trailer \ from disk ... lv_readvgats: Could not read VGSA 2 header & trailer \ from disk ... PHKL_6272: No option to convert a ISO-9660 CDROM filename from "FILENAME;VERSION" to lower case "filename". PHKL_6081: VxFS performance as a NFS exported file system is poor. PHKL_6024: Running vgcreate on an LVM disc without re-running pvcreate before end could create an LVM disc where the start of user data overlaps the LVM header, as for example with the sequence: pvcreate /dev/rdsk/c0t0d0 vgcreate vg05 /dev/dsk/c0t0d0 vgremove vg05 vgcreate -s 1 -e 2033 -p 60 vg05 /dev/dsk/c0t0d0 Symptoms such as file system corruption or LVM header corruption, showing up as file system panics or LVM panics, could then be observed. PHKL_5888: When the BDRA or the boot file is removed from the boot disk, and the user tries to boot the system in LVM maintenance mode, the boot runs a little while, then panics with "vfs_MOUNTROOTS failed: NEED DRIVERS". PHKL_5839: lvreduce hangs when reducing a bad disk from lvol. PHKL_5813: May get some junk pages in the coredump. PHKL_5737: When booting a NFS Diskless client, the system may hang when loading the kernel, when loading the RAM file system, or when loading the ioconfig file. PHKL_5663: The vgchange -a r command fails with the message: vgchange: Activation mode requested for the volume group conflicts with configured mode. Defect Description: PHKL_9404: The execve() kernel routine was asking for a KERNEL IO to read in the a.out header, but the VxFS code handling direct IOs (VX_DIRECT) was generating a USER IO. PHKL_9263: Under MMF high presure, vx_do_pageio called from vhand incorectly marked a page as r_zomb when EAGAIN occurs on that page. This as the side effect of killing a process that do a fault on that page later on. PHKL_8757: Problem was due to incorrectly releasing an inode while still holding a buf. This violates the rule which would prevent a deadlock from happening. The problem shows up as a three way deadlock with two processes marching back to the root from the leaves via ".." and another process marching from the root to the leaves. This creates a a deadlock of processes waiting for the same inode and holding the wanted buf at the same time. PHKL_8731: OnLineJFS breaks large write requests into multiple direct I/O's. Depending on the size of the data block, the beginnning and end of a direct I/O request may not align on the block boundaries. In these cases, the data is handled through buffer cache. After the first direct I/O, the subsequent iteration may begin with a write that has data starting in the middle of the buffer. If this write passes the current EOF, the buffer is simply allocated and filled with new data. If this buffer happens to be one that previously used to hold old data, the old data remains in the portion that is not overwritten by the new data. Writing this buffer to disk corrupts the file. The fix is to check against the correct file size so the first buffer of the subsequent iteration will be read in from disk to contain the correct data written in the last iteration. PHKL_8580: pstat_msginfo() calls msgconv() to convert the offset into a message queue pointer. msgconv() was changed to not only do the conversion, but to lock the queue and return a pointer to the queue's lock. pstat_msginfo() had not been changed to take into account msgconv()'s new behavior. PHKL_8602: When commands that call pstat_fileinfo(2) (e.g. fuser(1m)) on a system where lots of processes are exiting, a race condition can occur between exit(2) and pstat_fileinfo(2) where pstat_fileinfo(2) dereferences a pointer exit(2) has already set to NULL. PHKL_8391: LVM makes every effort to avoid returning an error to user applications. LVM will hold onto an I/O to retry it later if there is even the smallest hope that the device will return. If a disk simply does not respond and no bad writes made it to the media, LVM will hang onto the i/o as long as the disk does not respond with an indication that there was actually a bad write or read. The patch provides a new feature that allows administrators the option of limiting the time lvm will wait for disks in an logical volume to return, and cause lvm to return i/os with EIO instead of hanging onto them indefinitely. PHKL_8386: The problem can be reproduced with this test program: char buf[2097152]; main() { int fd; memset((void *)buf, 'A', sizeof(buf)); fd = creat("A.dat", 0644); write(fd, buf, 512); write(fd, buf, sizeof(buf)); } Every byte of the file should contain the character 'A'. This works fine on UFS. It also works on VxFS as long as HP OnLineJFS is not installed. But with HP OnLineJFS, a sequence of null bytes appears in the middle of the file (not at the boundary between the writes, but in the middle of the second write). PHKL_8282: The max. limit for the number of chars in the arg/env strings passed to EXEC is currently set at 20k (defined by ARG_MAX). Attempts to pass more number of chars result in the E2BIG error. This limit was imposed due to the way the kernel was allocating memory to copy the arg/env strings and set them for the newly exec'ed process. PHKL_8199: In 10.X, interrupt distribution is implemented to allow reassignment of interrupt processors to I/O interfaces for workload balancing. The assigned interrupt processor for an I/O interface may or may not be the system monarch depending on the the number of I/O cards and processors available. During a panic, if the panic processor is the system monarch, it will flush the buffer cache on its way down. If the interrupt of the disk it is syncing is serviced by one of the other processor(s), the I/O completion interrupt will not be received and the ISR will not be called because the other processor(s) are TOC'ed at this point. Without the ISR to signal biodone(), the biowait() sleeps forever. The fix is to add a timeout in the panic_boot path to break out from the hang in disk sync'ing and continue with the reboot. PHKL_8080: Without this patch LVM will not retry failed i/os on alternate links unless the error is one that denotes that the device is offline or powerfailed. Other errors, are not retried on an alternate link and may cause LVM to report the error to users applications. Typically, customers with unmirrored lvols using multiported devices like the HP3232 (Nike) disk array would see the problem when an EIO error is reported to LVM from the underlying device driver due to a device or driver problem. In this situation LVM would report the EIO to user applications without trying any available alternate link. Another problem this patch fixes allows reducing out physical volumes from a volume group when the device is not available and the device has links, formerly devices with links could not be removed if they were not available. PHKL_8024: Directories with the setgid bit set have the following property: when any file is created within that directory, it inherits the group id of the directory. In addition, any directory created under such a directory also has the setgid bit set. Patch PHKL_7666 inadvertently removed that feature of setgid directories. This patch restores it. PHKL_7908: pstat_dynamic() allocates a buffer but fails to initialize it before using it, so the buffer ends up containing some garbage. This is a cosmetic defect only; sar ignores the uninitialized spaces. PHKL_7901: A panic can occur with JFS on LVM due to an inode being able to change identity before it and its dirty pages are flushed to disk in vx_freeze_iflush(). When a JFS file is created with the SETUID flag, the setuid bit is removed when the file has been edited with vi or text has been appended to it; this should only be the case when the writer is not root. PHKL_7846: The problem was that the kernel forced a panic whenever any inconsistency was found during an lvreduce. For example, if a logical extent in an lvol referred to a physical extent that was not allocated, it would cause lvreduce(1M) to panic the system. This occured even when the objective was to remove the offending lvol. This is a very rare occurance. PHKL_7666: A future HP-UX release will increase the value of MAXUID, providing for a greater range of valid UIDs and GIDs. It will also introduce problems in mixed-mode NFS environments. Let "LUID" specify a machine running a version of HP-UX with large-UID capability. Let "SUID" specify a machine with current small-UID capability. The following problems may occur: LUID client, SUID server - Client logins with UIDs outside the server's range appear as the anonymous user. However, the anonymous user UID is configurable, and is sometimes configured as the root user (in order to "trust" all client root logins without large-scale modifications to the /etc/exports file). Thus, all logins with large UIDs on the client could be mapped to root on the server. - Files owned by the nobody user on the server will appear to be owned by the wrong user on the client. SUID client, LUID server - Files owned by large-UID logins on the server will appear to be owned by the wrong user on the client. - Executables with the setuid or setgid mode turned on will allow logins on the client to run as the wrong users. There is a patch to the NFS code that is intended to be used in parallel with this one. PHKL_7510 (or its successor) should be installed with this one, although no defects are introduced by installing only this one of the two. PHKL_7578: (1) The VxFS file truncation code was breaking an assumption in brealloc() causing delayed-write buffers to be discarded instead of being flushed to disk. (2) A "purge buffer cache" was not performed by the VxFS pageout code. Stale data could then be found in the buffer cache when resuming file-system operations after a msync(2). (3) VxFS used to purge the buffer cache at mmap(2) time, and the Dynamic Loader (dld.sl) suffered poor performance with shared-libraries residing a VxFS file-system. The fix was to purge the buffer cache at pageout time, and to flush it at pagein time. Defects #2 and #3 are fixed in 10.20, but #1 is fixed 10.30. PHKL_7508: The three distinct problems: 1: The code change for PHKL_6988 or equivalent (consisting of only flushing dirty buffers at mmap() time and to no longer also invalidate valid buffers) broke the mechanism by which VxFS was handling the consistency of the "page cache" and the "buffer cache". Valid stale buffers could be found in the buffer cache after changes would have been done through a MMF, and this is data corruption. The fix was to back out the change of PHKL_6988. 2: Resizing VxFS filesystems online effectively does a quick unmounts and remount of the filesystem, switching quickly between two different data areas containing information it. The VxFS disk quota tracking structures were not updated during the switch, with the end result that the disk quota code was accessing invalid memory. The fix was to update the disk quota structures during the switch. 3: This problem was mainly seen on striped logical volumes. If multiple processes were scanning VxFS directories via commands like ls, find, or cpio, they could cause VxFS to erroneously assume the filesystem is corrupt, making it impossible to remount it until fscked. There would also be errors in the syslog referring to vx_direrr. The defect was in a lack of caching of offsets within the directory block; if the offset changed at an inopportune time, the directory read would fail and the filesystem would be marked corrupt. PHKL_7306: It had been limited to 32 characters. PHKL_7250: On LVM, when the resource "lv_str2_buf" for big-size IO requests is exhausted, multiple processes could compete and sleep for the same resource without first releasing the ones they owned, causing a deadlock. PHKL_7217: When LVM encounters a bad block, it asks the disk drive to spare it out; this is called "hardware relocation." If that fails, LVM then performs what is called "software relocation" -- that is, it replaces the bad block with a block from a reserve area called the bad block directory. After the relocation, it reads back the data, just to make sure the new block isn't bad as well; if the new block is bad, LVM relocates THAT one, again and again until it is successful. There was a defect in the code that dealt with the LVM verification of the new block. Apparently, the block number was incremented before checking if the second relocation succeeded; if the last block of that relocation was bad, the block number indicated that all the data had been transferred, so LVM assumed that the write was successful. However, the driver indicated errors (specifically, B_ERROR was set and b_error was EMEDIA), which led to inconsistent data in the bad block directory, typically leading to a panic. This patch also fixes LVM wrongly relocating a bad block. It should relocate the bad one instead of the block next to the bad one. PHKL_7205: VxFS forgot to check if nlink is 1. PHKL_7185: lvmerge could merge an lvol back with all physical extents marked as current and yet the syncing of stale LTGs had failed. lv_recover_ltg(k), which does the syncing, had no mechanism to return an error to lv_table_reimage(k). lv_table_reimage(k) therefore returns success when this may not be the case. PHKL_7122: PHKL_6763 caused the kernel routine direnter() to return EDEADLK if it couldn't lock all the directories and files it needed to. The change was made to fix a deadlock problem caused by moving directories, and it was thought that direnter() could only hit this state for the DE_RENAME function. The problem can also be hit for large, popular files like /etc/passwd which are being linked to a new name. The fix is to have ufs_link() retry direnter() if EDEADLK is returned, just as ufs_rename() did in the original patch. PHKL_7037: Customer were using pvmove command to move data from one disk to another. For some reason, the mirrored logical volume to be moved contains unallocated physical extents. system panic: lv_reducelv extmap PHKL_7024: When deactivating a volume group, if the MWC cache is not clean, the deactivation routine will detect it and panic. When the last user LV (/dev/vgXX/lvol[1-n]) of a volume group is closing and the controlling LV (/dev/vgXX/group) is still opened, it should also wait for all outstanding MWC cache writes to be finished. PHKL_7015: VxFS neglected to check for the O_DSYNC flag. It only checked for O_SYNC. In vx_iget, the code dereferenced a NULL pointer. PHKL_6987: When creating a memory mapped file, VxFS was flushing and invalidating the file-related buffers from the buffer cache. This behavior caused the dynamic loader (dld.sl) to generate a physical I/O each time it was reading a shared library header before calling mmap(), and shared library headers were never found in the buffer cache. The fix was to only flush (writing dirty buffers) and not do the invalidation. PHKL_6951: Incorrect "No space left on device" errors were generated when the filesystem was not actually full. The filesystem in question was a VxFS filesystem mounted over NFS from another system with quotas enabled on the server. The message occurred when a user reaches the hard limit on the mounted directory. This was caused by the VxFS code in HP-UX interpreting a class of filesystem space allocation failures all as ENOSPC. The fix was to correect this misinterpretation. With this patch installed, when a user exceeds his quota, the error on his terminal will be "Disk quota exceeded". PHKL_6888: The problem encountered at 9.X was fixed in 10.X by delaying the removal of the mmap'd page (pageremove) until the I/O had completed. At the same time this was done, there were also some changes done to speed up MMFs. One of those changes involved sparse files and resulted in the need for coordination between rwip() and MMFs. The end result was rwip() locating pages in the pagecache() and copying data back to the buffer cache block. At the completion of the copy, the pages were systematically removed from the pagecache which removed our "synchronization" link for msync(). See the SR for reproduction methods. PHKL_6792: The customer had a T500 ran into the problem with "/etc/lvmtab is out of date with running kernel" when doing a vgcfgbackup. The current PV value was set to 7, while there were only 6 disks in the /etc/lvmtab. PHKL_6764: Directory renaming code locked the new parent directory and read the new parent directory buffer, thereby locking it. It then dropped the new parent directory lock and later tried to reacquire it. If a lookup process had gotten the new parent directory lock in the meantime and was sleeping waiting for the new parent directory buffer to be free, deadlock! PHKL_6674: When the last LV of a VG is closing, it should wait for all outstanding MWC cache writes to be finished. Otherwise, it may have a running MWC cache write when VG releases its dynamically allocated structure. Create multiple LVs on a VG, and make MWC busy (by writing 256K bytes interval) then close All LVs (at almost the same time). PHKL_6529: No defect with the kernel. Although this patch does allow a patch to fix a defect with fuser -k to work. PHKL_6494: Problem is easily duplicatable following the replacement of a disk mech, or with a simply vgcfgrestore/vgchange combination to the right disks. To reproduce one problem, connect an HP-FL disk to 10.01 system, and do the following: - Install PHKL_6273 (supersedes LVM patch PHKL_6025) - Create a volume group with this disk in it (automatically runs vgcfgbackup): pvcreate -f /dev/rdsk/c0t2d0 mkdir /dev/vgdan mknod /dev/vgdan/group c 64 0x090000 vgcreate /dev/vgdan /dev/dsk/c0t2d0 - Deactivate the VG: vgchange -a n /dev/vgdan - Restore the LVM data structures to the disk: vgcfgrestore -n /dev/vgdan /dev/rdsk/c0t2d0 - At this point, any further activation of the VG will fail: vgchange -a y /dev/vgdan vgchange: Couldn't activate volume group "/dev/vgpam": Invalid argument This problem occurred because of a change made in LVM to support "hot-swapping" of disk mech's. The code to handle this attempts to set immediate-reporting on the newly-added disk, but this is not a valid operation on a non-SCSI disk. The driver returns EINVAL as it should, and LVM heeds this error and passes it up to the higher levels, causing vgchange to fail with "Invalid argument". So, now if we have EINVAL in this case, we return ESUCCESS. Second problem: Create a root volume group with more than two disks, and mirror the root lvol onto the last disk added to the volume group, and make that pvol bootable. Remove all but the disks on which root is mirrorred. Boot into maintenance mode from the last disk added to the volume group (the one with the highest PV number). Reboot normally (without maintenance mode) from the same disk. The system will panic with "lv_fixrootlv: could not find boot pvol" This problem occurred because we were searching through the number of valid pvol array entries which are not necessarily contiguous in the array instead of searching through the size of the array. PHKL_6462: During maintenance boot (hpux -lm), the kernel tried to write out a flag to the BDRAs so that the next boot could resync the root. The routine which does the maintenance flag write uses the hardware paths stored in the BDRA. When the path(s) of the root disk(s) are changed, the old paths may correspond to no device or to some other disk. (1) In the case where a path now corresponds to no device, the routine opens the wrong device -- in particular, the boot device with the hard partition one bit set. (2) In the case where a hardware path now corresponds to some unintended disk, the write goes to where the BDRA would be on that disk. For case (1), whether or not the hard partition one write goes through depends on the underlying driver. Case (2) is independent of the underlying driver. Either case represents a potential corruption to the disks involved. The patch prevents these corruptions by (1) checking if a hardware path corresponds to NODEV -- if so, no write to that path is performed; (2) checking if there is a valid BDRA at that hardware path -- if not, no write to that path is performed. Since the maintenance flag write is needed for mirrored roots, another check was added to make sure that flag gets written to the current boot device. To reproduce case (1): - install 10.01 to an NIO tower - change the address of the root in the tower - boot in maintenance mode (hpux -lm) - notice that the maintenance flag is not set in the BDRA (check 16kb at offset 128) - notice that the BDRA was written to hard partition one (check 16kb at hard partition one for that disk type) To reproduce case (2): - install 10.01 to an NIO tower - change the address of the root in the tower - change the address of a scratch disk in the tower to correspond to the root's old address - boot in maintenance mode (hpux -lm) - notice that the maintenance flag is not set in the BDRA (check 16kb at offset 128) - notice that the BDRA was written to the scratch disk (check 16kb at offset 128) PHKL_6448: LVM metadata I/O requests return erroneous "I/O error" status and abort resynchronization when the device has merely timed out or powefailed, but has not been marked missing. If a disk is powerfailed, LVM should poll for its return; the problem is that certain LVM I/O requests did not check for a mere powerfail condition, but always assumed that any error indicated that the device was not worth waiting for. The fix was to check if LVM had decided the device was powerfailed vs truly missing, and not to abort if the device was in a potentially temporary powerfail condition. PHKL_6446: On LVM, very large I/O requests -- on the order of 256k -- may not complete within LVM's time allotment. With large logical volumes, the LVM metadata can easily get this large. This can manifest itself as various errors in reading or writing the VGDA/VGSA header or trailer, with messages to the console and system log. These timeouts can be due to an extremely busy I/O bus, a multi-initiator environment, or a disk that places the priority of small I/O requests over large ones. Systems with Nike disk arrays have seen this particular problem. The fix was to break down LVM metadata into a more palatable size, 64k. PHKL_6272: HP-UX does not provide a mount option which will convert the ISO-9660 filename from "FILENAME;VERSION" format to lower case "filename" like most of the industry Unix platforms do. PC's and non-HP clients cannot use the ISO-9660 CD-ROM exported from a HP-UX NFS server because symbolic link, the only work-around, is not available on these systems. The fix adds two global kernel variables to the cdfs operation to provide the filename convertion functionality. These variables can be turned on and off using adb after the patch is installed. The kernel variables which need to be modified are: cdfs_convert_case - Set this to 1 to display filenames in lower case. cdfs_zap_version - Set this to 1 to suppress version number in filenames. If you want the variables to be set in the kernel file /stand/vmunix so the function remains after a system reboot, type the following: echo "cdfs_convert_case?W 1" | \ adb -w /stand/vmunix /dev/kmem echo "cdfs_zap_version?W 1" | \ adb -w /stand/vmunix /dev/kmem Or you can modify the memory only by typing: echo "cdfs_convert_case/W 1" | \ adb -w /stand/vmunix /dev/kmem echo "cdfs_zap_version/W 1" | \ adb -w /stand/vmunix /dev/kmem PHKL_6081: For NFS servers with large configurations, i.e for those servers for which the tunable kernel parameter ninode has been changed to be in thousands or in hundreds of thousands, the performance of VxFS as the exported file system will not be very good. Without this patch VxFS does not support the hooks for glance. PHKL_6024: Due to a defect in the SDS migration code, the kernel was computing the start of user data only when the data_psn field in the LVM record was 0 (which is the default value after running pvcreate). Not running pvcreate on an LVM disc before re-using it meant using the start of user data from previous disc usage, and thus causing data corruption if the new LVM header was bigger than in previous disc usage. Corruption can be prevented with the work-around of always running pvcreate before re-using an LVM disc. For 10.00, the patches PHKL_6022/s700 and PHKL_6023/s800 address also this defect. The patch will prevent from creating situation where the start of user data and the LVM header overlap. Also, a test was added to the activation code to detect discs which may have potential for data corruption, and a warning is printing on the system console: WARNING: The LVM header on the disc at 52.4.0 extends beyond the start of user data, which therefore has potential for data corruption. Please consult the documentation for patch PHKL_6025 (or any superceeding patch) for how to reconfigure to fix this. In the event you have a disk which is showing potential for this problem, as detected by the patched PV activation code, the procedure for correcting the problem (which must be repeated for each individual disk) is as follows. For this example, the disk which is showing problems is /dev/dsk/c1t6d0, which is part of vg01: If you have spare space available in your volume group (or can make it available by adding a new disk to the volume group), the procedure is simpler: - Add the new disk to the volume group if needed (c1t3d0 in this example): # pvcreate [-B] /dev/dsk/c1t3d0 # vgextend /dev/vg01 /dev/dsk/c1t3d0 - Move all logical extents to the new disk: # pvmove /dev/dsk/c1t6d0 /dev/dsk/c1t3d0 The second argument here is optional, and is only needed when you want to make sure all the extents go to the new disk. Without it, the extents will be moved to the first available free space elsewhere in the VG. - Remove the affected disk from the VG, run pvcreate to clear the data structures, then add it back to the VG. # vgreduce /dev/vg01 /dev/dsk/c1t6d0 # pvcreate [-B] /dev/dsk/c1t6d0 # vgextend /dev/vg01 /dev/dsk/c1t6d0 - If you want to remove the new disk from the VG again, you can do so now by reversing the pvmove process, and removing it: # pvmove /dev/dsk/c1t3d0 /dev/dsk/c1t6d0 # vgreduce /dev/vg01 /dev/dsk/c1t3d0 If you do not have spare disk space available, the procedure is slighly more complicated, as you will need to backup and restore all affected lvols: - determine which logical volumes are affected: # pvdisplay -v /dev/dsk/c1t6d0 | more - Under the heading "- Distribution of physical volume -", pvdisplay lists all of the logical volumes which are using this disk. Stop all activity to these logical volumes, shutting-down (or rebooting) to single-user mode, if necessary. - These lvols all need to be backed-up in their entirety, then removed. For example, if this disk contains file systems for the following: /dev/vg01/lvol1 mounted as /fs1 /dev/vg01/lvol2 mounted as /home and /dev/vg01/lvol3 mounted as /opt: # fbackup -i /fs1 -i /home -i /opt \ -vf /dev/rmt/c1t0d0BEST # lvremove /dev/vg01/lvol1 # lvremove /dev/vg01/lvol2 # lvremove /dev/vg01/lvol3 - Remove the affected disk from the VG, run pvcreate to clear the data structures, then add it back to the VG. # vgreduce /dev/vg01 /dev/dsk/c1t6d0 # pvcreate [-B] /dev/dsk/c1t6d0 # vgextend /dev/vg01 /dev/dsk/c1t6d0 - Recreate the logical volumes you removed previously, including the lvols and their fileysystems as needed (use SAM if you prefer). # lvcreate -L -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_5737: The defect is that the Secondary System Loader (hpux(1M)) is called with interrupts enabled. The Secondary System Loader requires interrupts be disabled when it is called. To reproduce this problem, keep rebooting your client until it hangs. NOTE: Make sure you have the latest firmware for your system. PHKL_5663: The vgchange -a r will fail when service guard cluster services are present in the system. The read only activation of the volume group fails when it has been activated in exclusive mode. There is no workaround for this problem. SR: 1653110189 1653136358 1653141945 1653144071 1653150698 1653150938 1653161471 1653162297 1653162669 1653166041 1653166066 1653170464 1653178590 1653180810 1653182501 1653186502 4701293480 4701295428 4701296657 4701297390 4701304790 4701309070 4701314179 4701314302 4701315317 4701318352 4701320788 4701329441 4701330647 4701334698 4701336412 5000697466 5000714352 5003268524 5003276485 5003281469 5003285528 5003289496 5003294421 5003306258 5003309385 5003311837 5003317487 5003318667 5003323493 5003325506 5003336214 5003336933 5003344184 Patch Files: /usr/conf/h/dnlc.h /usr/conf/h/pstat.h /usr/conf/lib/libcdfs.a(cdfs_vnops.o) /usr/conf/lib/libhp-ux.a(file_sys.o) /usr/conf/lib/libhp-ux.a(gio_lvl1.o) /usr/conf/lib/libhp-ux.a(kern_exec.o) /usr/conf/lib/libhp-ux.a(kern_kload.o) /usr/conf/lib/libhp-ux.a(lv_config.o) /usr/conf/lib/libhp-ux.a(lv_lvm.o) /usr/conf/lib/libhp-ux.a(machdep.o) /usr/conf/lib/libhp-ux.a(pm_config.o) /usr/conf/lib/libhp-ux.a(pstat.o) /usr/conf/lib/libhp-ux.a(subr_prf.o) /usr/conf/lib/libhp-ux.a(sys_ki.o) /usr/conf/lib/libhp-ux.a(vfs_dnlc.o) /usr/conf/lib/libhp-ux.a(vfs_vm.o) /usr/conf/lib/libhp-ux.a(vm_machdep.o) /usr/conf/lib/libhp-ux.a(vm_swp.o) /usr/conf/lib/libhp-ux.a(vxfs.o) /usr/conf/lib/liblvm.a(lv_block.o) /usr/conf/lib/liblvm.a(lv_cluster_lock.o) /usr/conf/lib/liblvm.a(lv_defect.o) /usr/conf/lib/liblvm.a(lv_hp.o) /usr/conf/lib/liblvm.a(lv_ioctls.o) /usr/conf/lib/liblvm.a(lv_kdb.o) /usr/conf/lib/liblvm.a(lv_lvsubr.o) /usr/conf/lib/liblvm.a(lv_malloc.o) /usr/conf/lib/liblvm.a(lv_mircons.o) /usr/conf/lib/liblvm.a(lv_pbuf.o) /usr/conf/lib/liblvm.a(lv_phys.o) /usr/conf/lib/liblvm.a(lv_schedule.o) /usr/conf/lib/liblvm.a(lv_strategy.o) /usr/conf/lib/liblvm.a(lv_subr.o) /usr/conf/lib/liblvm.a(lv_syscalls.o) /usr/conf/lib/liblvm.a(lv_vgda.o) /usr/conf/lib/liblvm.a(lv_vgsa.o) /usr/conf/lib/libufs.a(ufs_dir.o) /usr/conf/lib/libufs.a(ufs_vnops.o) /usr/conf/lib/libvxfs_adv.a(vx_dio.o) /usr/conf/lib/libvxfs_adv.a(vx_dirsort.o) /usr/conf/lib/libvxfs_adv.a(vx_full.o) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) /usr/conf/lib/libvxfs_adv.a(vx_snap.o) /usr/conf/lib/libvxfs_base.a(vx_alloc.o) /usr/conf/lib/libvxfs_base.a(vx_attr.o) /usr/conf/lib/libvxfs_base.a(vx_bio.o) /usr/conf/lib/libvxfs_base.a(vx_bio1.o) /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o) /usr/conf/lib/libvxfs_base.a(vx_bmap.o) /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o) /usr/conf/lib/libvxfs_base.a(vx_chain.o) /usr/conf/lib/libvxfs_base.a(vx_config.o) /usr/conf/lib/libvxfs_base.a(vx_dira.o) /usr/conf/lib/libvxfs_base.a(vx_dirl.o) /usr/conf/lib/libvxfs_base.a(vx_dirop.o) /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o) /usr/conf/lib/libvxfs_base.a(vx_ialloc.o) /usr/conf/lib/libvxfs_base.a(vx_iflush.o) /usr/conf/lib/libvxfs_base.a(vx_inode.o) /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) /usr/conf/lib/libvxfs_base.a(vx_kernrdwri.o) /usr/conf/lib/libvxfs_base.a(vx_lct.o) /usr/conf/lib/libvxfs_base.a(vx_lite.o) /usr/conf/lib/libvxfs_base.a(vx_log.o) /usr/conf/lib/libvxfs_base.a(vx_message.o) /usr/conf/lib/libvxfs_base.a(vx_mount.o) /usr/conf/lib/libvxfs_base.a(vx_olt.o) /usr/conf/lib/libvxfs_base.a(vx_oltmount.o) /usr/conf/lib/libvxfs_base.a(vx_quota.o) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) /usr/conf/lib/libvxfs_base.a(vx_resize.o) /usr/conf/lib/libvxfs_base.a(vx_swap.o) /usr/conf/lib/libvxfs_base.a(vx_ted.o) /usr/conf/lib/libvxfs_base.a(vx_tran.o) /usr/conf/lib/libvxfs_base.a(vx_vfsops.o) /usr/conf/lib/libvxfs_base.a(vx_vm.o) /usr/conf/lib/libvxfs_base.a(vx_vnops.o) /usr/include/sys/dnlc.h /usr/include/sys/fs/vx_inode.h /usr/include/sys/pstat.h what(1) Output: /usr/conf/h/dnlc.h: dnlc.h $Date: 95/10/10 13:40:56 $ $Revision: 1.3.71.5 $ PATCH_10.01 (PHKL_6081) /usr/conf/h/pstat.h: pstat.h $Date: 95/12/14 15:28:37 $ $Revision: 1.8.71 .25 $ PATCH_10.01 (PHKL_6529) /usr/conf/lib/libcdfs.a(cdfs_vnops.o): cdfs_vnops.c $Date: 95/11/02 15:00:30 $ $Revision: 1.10.72.28 $ PATCH_10.01 (PHKL_6272) /usr/conf/lib/libhp-ux.a(file_sys.o): file_sys.c $Date: 95/09/28 17:51:26 $ $Revision: 1.2.71.4 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libhp-ux.a(gio_lvl1.o): gio_lvl1.c $Date: 95/07/05 10:16:54 $ $Revision: 1.2.71.15 $ PATCH_10.01 (PHKL_5737) /usr/conf/lib/libhp-ux.a(kern_exec.o): kern_exec.c $Date: 96/08/13 10:58:03 $ $Revision: 1.88.72.43 $ PATCH_10.01 (PHKL_8282) /usr/conf/lib/libhp-ux.a(kern_kload.o): kern_kload.c $Date: 96/04/17 16:45:51 $ $Revision: 1.2.71.6 $ PATCH_10.01 (PHKL_7306) /usr/conf/lib/libhp-ux.a(lv_config.o): lv_config.c $Date: 96/09/03 18:02:17 $ $Revision: 1. 6.71.27 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/libhp-ux.a(lv_lvm.o): lv_lvm.c $Date: 96/09/03 18:07:43 $ $Revision: 1.2 .71.2 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/libhp-ux.a(machdep.o): machdep.c $Date: 96/08/06 15:46:31 $ $Revision: 1.11 8.72.44 $ PATCH_10.01 (PHKL_8199) /usr/conf/lib/libhp-ux.a(pm_config.o): pm_config.c $Date: 96/08/13 11:00:41 $ $Revision: 1.2.71.16 $ PATCH_10.01 (PHKL_8282) /usr/conf/lib/libhp-ux.a(pstat.o): pstat.c $Date: 96/09/26 15:12:11 $ $Revision: 1.13.7 2.51 $ PATCH_10.01 (PHKL_8580) /usr/conf/lib/libhp-ux.a(subr_prf.o): subr_prf.c $Date: 95/12/14 13:58:05 $ $Revision: 1.6 1.72.29 $ PATCH_10.01 (PHKL_6529) /usr/conf/lib/libhp-ux.a(sys_ki.o): sys_ki.c $Date: 95/12/14 13:58:32 $ $Revision: 1.13. 72.62 $ PATCH_10.01 (PHKL_6529) /usr/conf/lib/libhp-ux.a(vfs_dnlc.o): vfs_dnlc.c $Date: 95/09/28 16:35:26 $ $Revision: 1.13.72.15 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libhp-ux.a(vfs_vm.o): vfs_vm.c $Date: 96/02/21 09:35:16 $ $Revision: 1.11.72.31 $ PATCH_10.01 (PHKL_6888) /usr/conf/lib/libhp-ux.a(vm_machdep.o): vm_machdep.c $Date: 95/12/14 14:00:25 $ $Revision: 1.150.72.101 $ PATCH_10.01 (PHKL_6529) /usr/conf/lib/libhp-ux.a(vm_swp.o): vm_swp.c $Date: 96/02/21 09:35:11 $ $Revision: 1.44.72.35 $ PATCH_10.01 (PHKL_6888) /usr/conf/lib/libhp-ux.a(vxfs.o): vxfs.c $Date: 96/04/02 12:34:56 $ $Revision: 1.2.71.2 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/liblvm.a(lv_block.o): lv_block.c $Date: 96/09/03 17:11:04 $ $Revision: 1 .6.71.5 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_cluster_lock.o): lv_cluster_lock.c $Date: 96/09/03 18:02:11 $ $Revi sion: 1.2.71.12 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_defect.o): lv_defect.c $Date: 96/09/03 18:02:21 $ $Revision: 1. 6.71.25 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_hp.o): lv_hp.c $Date: 96/09/03 18:02:24 $ $Revision: 1.6.71 .56 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_ioctls.o): lv_ioctls.c $Date: 96/09/03 18:02:27 $ $Revision: 1.6.71.45 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_kdb.o): lv_kdb.c $Date: 96/09/03 18:02:30 $ $Revision: 1.4 .71.4 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_lvsubr.o): lv_lvsubr.c $Date: 96/09/03 18:02:32 $ $Revision: 1.6.71.22 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_malloc.o): lv_malloc.c $Date: 96/09/03 18:02:35 $ $Revision: 1.6.71.4 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_mircons.o): lv_mircons.c $Date: 96/09/03 18:02:38 $ $Revision: 1 .6.71.19 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_pbuf.o): lv_pbuf.c $Date: 96/09/03 18:02:40 $ $Revision: 1. 6.71.6 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_phys.o): lv_phys.c $Date: 96/09/03 18:02:43 $ $Revision: 1.6. 71.19 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_schedule.o): lv_schedule.c $Date: 96/09/03 18:02:45 $ $Revision: 1.6.71.31 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_strategy.o): lv_strategy.c $Date: 96/09/03 18:02:48 $ $Revision: 1.6.71.14 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_subr.o): lv_subr.c $Date: 96/09/03 18:02:50 $ $Revision: 1.6.71.26 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_syscalls.o): lv_syscalls.c $Date: 96/09/03 18:02:53 $ $Revision: 1.6.71.22 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_vgda.o): lv_vgda.c $Date: 96/09/03 18:02:55 $ $Revision: 1. 6.71.12 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/liblvm.a(lv_vgsa.o): lv_vgsa.c $Date: 96/09/03 18:02:57 $ $Revision: 1. 6.71.14 $ PATCH_10.01 (PHKL_8391) /usr/conf/lib/libufs.a(ufs_dir.o): ufs_dir.c $Date: 96/10/24 11:22:22 $ $Revision: 1.15.72.31 $ PATCH_10.01 (PHKL_8757) /usr/conf/lib/libufs.a(ufs_vnops.o): ufs_vnops.c $Date: 96/03/28 09:00:06 $ $Revision: 1.22.72.83 $ PATCH_10.01 (PHKL_7122) /usr/conf/lib/libvxfs_adv.a(vx_dio.o): vx_dio.c $Date: 96/12/04 08:34:27 $ $Revision: 1.2.71.16 $ PATCH_10.01 (PHKL_9404) /usr/conf/lib/libvxfs_adv.a(vx_dirsort.o): vx_dirsort.c $Date: 95/09/28 16:50:29 $ $Revision: 1.2.71.7 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_adv.a(vx_full.o): vx_full.c $Date: 95/09/28 16:50:31 $ $Revision: 1.2.71.13 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o): vx_reorg.c $Date: 95/09/28 16:51:08 $ $Revision: 1.2.71.9 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_adv.a(vx_snap.o): vx_snap.c $Date: 95/09/28 16:51:12 $ $Revision: 1.2.71.11 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_alloc.o): vx_alloc.c $Date: 95/09/28 16:43:28 $ $Revision: 1.2.71.10 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_attr.o): vx_attr.c $Date: 95/09/28 16:49:56 $ $Revision: 1.2.71.11 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_bio.o): vx_bio.c $Date: 95/09/28 16:50:02 $ $Revision: 1.2.71.15 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_bio1.o): vx_bio1.c $Date: 96/05/29 18:22:41 $ $Revision: 1.2.71.17 $ PATCH_10.01 (PHKL_7578) /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o): vx_bitmaps.c $Date: 95/09/28 16:50:06 $ $Revision: 1.2.71.10 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_bmap.o): vx_bmap.c $Date: 95/09/28 16:50:09 $ $Revision: 1.2.71.8 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o): vx_bsdquota.c $Date: 96/05/15 13:06:40 $ $Revision: 1.2.71.17 $ PATCH_10.01 (PHKL_7508) /usr/conf/lib/libvxfs_base.a(vx_chain.o): vx_chain.c $Date: 95/09/28 16:50:16 $ $Revision: 1.2.71.16 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_config.o): vx_config.c $Date: 95/09/28 16:50:19 $ $Revision: 1.2.71.14 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_dira.o): vx_dira.c $Date: 95/09/28 16:50:23 $ $Revision: 1.2.71.8 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_dirl.o): vx_dirl.c $Date: 96/05/15 13:04:00 $ $Revision: 1.2.71.12 $ PATCH_10.01 (PHKL_7508) /usr/conf/lib/libvxfs_base.a(vx_dirop.o): vx_dirop.c $Date: 95/09/28 16:50:27 $ $Revision: 1.2.71.10 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o): vx_hpuxsubr.c $Date: 95/09/28 16:50:34 $ $Revision: 1.2.71.16 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_ialloc.o): vx_ialloc.c $Date: 95/09/28 16:50:36 $ $Revision: 1.2.71.9 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_iflush.o): vx_iflush.c $Date: 96/08/02 13:19:32 $ $Revision: 1.2.71.14 $ PATCH_10.01 (PHKL_7901) /usr/conf/lib/libvxfs_base.a(vx_inode.o): vx_inode.c $Date: 96/08/02 13:19:33 $ $Revision: 1.2.71.21 $ PATCH_10.01 (PHKL_7901) /usr/conf/lib/libvxfs_base.a(vx_itrunc.o): vx_itrunc.c $Date: 95/09/28 16:50:43 $ $Revision: 1.2.71.12 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_kernrdwri.o): vx_kernrdwri.c $Date: 95/09/28 16:50:45 $ $Revision: 1.2.71.10 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_lct.o): vx_lct.c $Date: 95/09/28 16:50:48 $ $Revision: 1.2.71.7 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_lite.o): vx_lite.c $Date: 95/09/28 16:50:50 $ $Revision: 1.2.71.11 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_log.o): vx_log.c $Date: 95/09/28 16:50:52 $ $Revision: 1.2.71.9 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_message.o): vx_message.c $Date: 95/09/28 16:50:54 $ $Revision: 1.2.71.7 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_mount.o): vx_mount.c $Date: 96/05/15 13:11:37 $ $Revision: 1.2.71.17 $ PATCH_10.01 (PHKL_7508) /usr/conf/lib/libvxfs_base.a(vx_olt.o): vx_olt.c $Date: 95/09/28 16:50:58 $ $Revision: 1.2.71.10 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_oltmount.o): vx_oltmount.c $Date: 95/09/28 16:51:01 $ $Revision: 1.2.71.8 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_quota.o): vx_quota.c $Date: 95/09/28 16:51:03 $ $Revision: 1.2.71.10 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o): vx_rdwri.c $Date: 96/08/02 13:19:35 $ $Revision: 1.2.71.23 $ PATCH_10.01 (PHKL_7901) /usr/conf/lib/libvxfs_base.a(vx_resize.o): vx_resize.c $Date: 95/09/28 16:51:10 $ $Revision: 1.2.71.7 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_swap.o): vx_swap.c $Date: 95/09/28 16:51:14 $ $Revision: 1.2.71.10 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_ted.o): vx_ted.c $Date: 95/09/28 16:51:16 $ $Revision: 1.2.71.11 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_tran.o): vx_tran.c $Date: 95/09/28 16:51:19 $ $Revision: 1.2.71.10 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_vfsops.o): vx_vfsops.c $Date: 95/09/28 16:51:21 $ $Revision: 1.2.71.21 $ PATCH_10.01 (PHKL_6081) /usr/conf/lib/libvxfs_base.a(vx_vm.o): vx_vm.c $Date: 96/11/18 14:21:09 $ $Revision: 1.2.71.21 $ PATCH_10.01 (PHKL_9263) /usr/conf/lib/libvxfs_base.a(vx_vnops.o): vx_vnops.c $Date: 96/04/04 15:33:11 $ $Revision: 1.2.71.23 $ PATCH_10.01 (PHKL_7205) /usr/include/sys/dnlc.h: dnlc.h $Date: 95/10/10 13:40:56 $ $Revision: 1.3.71.5 $ PATCH_10.01 (PHKL_6081) /usr/include/sys/fs/vx_inode.h: vx_inode.h: $Revision: 1.2.71.13 $ $Date: 95/10/10 1 3:50:57 $ vx_inode.h $Date: 95/10/10 13:50:57 $ $Revision: 1.2.71.13 $ PATCH_10.01 (PHKL_6081) src/kernel/vxfs/vx_inode.h 1.28 16 Dec 1994 02:02:01 - */ fshp:src/kernel/vxfs/vx_inode.h 1.28 /usr/include/sys/pstat.h: pstat.h $Date: 95/12/14 15:28:37 $ $Revision: 1.8.71 .25 $ PATCH_10.01 (PHKL_6529) cksum(1) Output: 1433825073 1736 /usr/conf/h/dnlc.h 3808513632 30467 /usr/conf/h/pstat.h 3075405600 15512 /usr/conf/lib/libcdfs.a(cdfs_vnops.o) 3551827826 132480 /usr/conf/lib/libhp-ux.a(file_sys.o) 2936849315 7832 /usr/conf/lib/libhp-ux.a(gio_lvl1.o) 3336419585 16328 /usr/conf/lib/libhp-ux.a(kern_exec.o) 3500569250 6304 /usr/conf/lib/libhp-ux.a(kern_kload.o) 2796310244 26456 /usr/conf/lib/libhp-ux.a(lv_config.o) 2101489711 118100 /usr/conf/lib/libhp-ux.a(lv_lvm.o) 414414286 22932 /usr/conf/lib/libhp-ux.a(machdep.o) 920064525 5628 /usr/conf/lib/libhp-ux.a(pm_config.o) 3530051992 22388 /usr/conf/lib/libhp-ux.a(pstat.o) 417619664 15880 /usr/conf/lib/libhp-ux.a(subr_prf.o) 3695960620 50904 /usr/conf/lib/libhp-ux.a(sys_ki.o) 2999147290 8536 /usr/conf/lib/libhp-ux.a(vfs_dnlc.o) 1593660871 28276 /usr/conf/lib/libhp-ux.a(vfs_vm.o) 3900460760 74852 /usr/conf/lib/libhp-ux.a(vm_machdep.o) 884770181 7188 /usr/conf/lib/libhp-ux.a(vm_swp.o) 3071564967 186476 /usr/conf/lib/libhp-ux.a(vxfs.o) 4109240189 2240 /usr/conf/lib/liblvm.a(lv_block.o) 3894381727 9600 /usr/conf/lib/liblvm.a(lv_cluster_lock.o) 1235760520 11316 /usr/conf/lib/liblvm.a(lv_defect.o) 1194497640 36824 /usr/conf/lib/liblvm.a(lv_hp.o) 3611755561 21204 /usr/conf/lib/liblvm.a(lv_ioctls.o) 493308582 580 /usr/conf/lib/liblvm.a(lv_kdb.o) 1113054594 20012 /usr/conf/lib/liblvm.a(lv_lvsubr.o) 4203311357 1736 /usr/conf/lib/liblvm.a(lv_malloc.o) 3452571591 17144 /usr/conf/lib/liblvm.a(lv_mircons.o) 1929642907 5712 /usr/conf/lib/liblvm.a(lv_pbuf.o) 2993994076 4920 /usr/conf/lib/liblvm.a(lv_phys.o) 461176533 18112 /usr/conf/lib/liblvm.a(lv_schedule.o) 3767986990 6860 /usr/conf/lib/liblvm.a(lv_strategy.o) 2982738768 6944 /usr/conf/lib/liblvm.a(lv_subr.o) 950678520 10072 /usr/conf/lib/liblvm.a(lv_syscalls.o) 2201444731 8216 /usr/conf/lib/liblvm.a(lv_vgda.o) 4230095236 11228 /usr/conf/lib/liblvm.a(lv_vgsa.o) 2103952855 18684 /usr/conf/lib/libufs.a(ufs_dir.o) 3394419873 29280 /usr/conf/lib/libufs.a(ufs_vnops.o) 2582274222 9292 /usr/conf/lib/libvxfs_adv.a(vx_dio.o) 2373645564 6904 /usr/conf/lib/libvxfs_adv.a(vx_dirsort.o) 947372995 13316 /usr/conf/lib/libvxfs_adv.a(vx_full.o) 2593909221 16836 /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) 2700406447 9544 /usr/conf/lib/libvxfs_adv.a(vx_snap.o) 1661647864 19092 /usr/conf/lib/libvxfs_base.a(vx_alloc.o) 3066601346 32492 /usr/conf/lib/libvxfs_base.a(vx_attr.o) 3917596612 9576 /usr/conf/lib/libvxfs_base.a(vx_bio.o) 3342111436 4500 /usr/conf/lib/libvxfs_base.a(vx_bio1.o) 2538577070 11960 /usr/conf/lib/libvxfs_base.a(vx_bitmaps.o) 3876620801 10056 /usr/conf/lib/libvxfs_base.a(vx_bmap.o) 1558355138 26452 /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o) 869082722 4620 /usr/conf/lib/libvxfs_base.a(vx_chain.o) 908452954 7356 /usr/conf/lib/libvxfs_base.a(vx_config.o) 773486446 9732 /usr/conf/lib/libvxfs_base.a(vx_dira.o) 2530552644 8256 /usr/conf/lib/libvxfs_base.a(vx_dirl.o) 1844114972 7256 /usr/conf/lib/libvxfs_base.a(vx_dirop.o) 1180476710 13268 /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o) 2401657086 9592 /usr/conf/lib/libvxfs_base.a(vx_ialloc.o) 1315438458 26812 /usr/conf/lib/libvxfs_base.a(vx_iflush.o) 925777145 37536 /usr/conf/lib/libvxfs_base.a(vx_inode.o) 1983630867 10284 /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) 3273714044 2000 /usr/conf/lib/libvxfs_base.a(vx_kernrdwri.o) 478210606 8032 /usr/conf/lib/libvxfs_base.a(vx_lct.o) 2013482013 3000 /usr/conf/lib/libvxfs_base.a(vx_lite.o) 828174554 9996 /usr/conf/lib/libvxfs_base.a(vx_log.o) 2336753589 6864 /usr/conf/lib/libvxfs_base.a(vx_message.o) 3365525404 19132 /usr/conf/lib/libvxfs_base.a(vx_mount.o) 2575180562 20420 /usr/conf/lib/libvxfs_base.a(vx_olt.o) 3187180947 10724 /usr/conf/lib/libvxfs_base.a(vx_oltmount.o) 1958668699 9656 /usr/conf/lib/libvxfs_base.a(vx_quota.o) 3080436405 25880 /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) 2060980719 5920 /usr/conf/lib/libvxfs_base.a(vx_resize.o) 3589907876 2740 /usr/conf/lib/libvxfs_base.a(vx_swap.o) 4116283683 584 /usr/conf/lib/libvxfs_base.a(vx_ted.o) 1908809738 17592 /usr/conf/lib/libvxfs_base.a(vx_tran.o) 4266163946 13500 /usr/conf/lib/libvxfs_base.a(vx_vfsops.o) 2261395020 10328 /usr/conf/lib/libvxfs_base.a(vx_vm.o) 4162949619 23172 /usr/conf/lib/libvxfs_base.a(vx_vnops.o) 1433825073 1736 /usr/include/sys/dnlc.h 4176674158 39668 /usr/include/sys/fs/vx_inode.h 3808513632 30467 /usr/include/sys/pstat.h Patch Conflicts: None Patch Dependencies: s700: 10.01: PHCO_8458 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_5663 PHKL_5737 PHKL_5813 PHKL_5839 PHKL_5888 PHKL_6024 PHKL_6081 PHKL_6272 PHKL_6446 PHKL_6448 PHKL_6462 PHKL_6494 PHKL_6529 PHKL_6674 PHKL_6764 PHKL_6792 PHKL_6888 PHKL_6951 PHKL_6987 PHKL_7015 PHKL_7024 PHKL_7037 PHKL_7122 PHKL_7185 PHKL_7205 PHKL_7217 PHKL_7250 PHKL_7306 PHKL_7508 PHKL_7578 PHKL_7666 PHKL_7846 PHKL_7901 PHKL_7908 PHKL_8024 PHKL_8080 PHKL_8199 PHKL_8282 PHKL_8386 PHKL_8391 PHKL_8580 PHKL_8602 PHKL_8731 PHKL_8757 PHKL_9263 Equivalent Patches: PHKL_9405: s800: 10.01 Patch Package Size: 1700 Kbytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHKL_9404 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_9404.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_9404.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_9404. 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_9404.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_9404.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: Due to the number of objects in this patch, the customization phase of the update may take more than 10 minutes. During that time the system will not appear to make forward progress, but it will actually be installing the objects. If you are planning to install the advanced VxFS product (AdvJournalFS.VXFS-ADV-KRN), it is imperative that this patch and all other VxFS patches be removed from the system via swremove, before the actual product installation. After the installation of the advanced VxFS product has completed, this patch can be re-installed. All patches listed in the Supersedes field are subject to this behavior, and need to be removed before installing this patch, with the exception of PHKL_7846 PHKL_7306 PHKL_7217 PHKL_7037 PHKL_6448 PHKL_6024 PHKL_5888 PHKL_5839 PHKL_5813 PHKL_5737 PHKL_5663.