Patch Name: PHKL_16730 Patch Description: s700 10.20 LVM/UFS/NDDB/flkmgr/VxFS,PCI/SCSI/MO/dump/stape Creation Date: 98/10/19 Post Date: 98/10/27 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: AdvJournalFS.VXFS-ADV-KRN JournalFS.VXFS-BASE-KRN JournalFS.VXFS-PRG LVM.LVM-KRN OS-Core.CORE-KRN OS-Core.KERN-RUN ProgSupport.C-INC Automatic Reboot?: Yes Status: General Superseded Critical: Yes PHKL_16730: PANIC CORRUPTION - Panic may not occur in stape because the buffer overrun causes the driver to corrupt data outside of the driver's memory. One known panic message is: Panic: Returning ID that is already free. There may be others. - Data corruption on reset can only occur is a bus reset or bus device reset occurs while an application has the device open and is writing to the device. PHKL_16592: PANIC HANG MEMORY_LEAK PHKL_15478: HANG PHKL_13572: HANG PHKL_7763: CORRUPTION PHKL_16448: PANIC PHKL_16455: PANIC CORRUPTION PHKL_16387: PANIC HANG PHKL_15081: PANIC PHKL_8735: CORRUPTION PHKL_8388: CORRUPTION PHKL_15958: CORRUPTION Data corruption can occur on tape in the rare case that a SCSI Bus Reset occurs while the tape is open and an application is writing to the tape. PHKL_15787: PANIC HANG PHKL_15766: HANG PHKL_15742: PANIC CORRUPTION PHKL_15619: HANG CORRUPTION PHKL_15495: PANIC PHKL_15456: PANIC HANG PHKL_15321: ABORT PHKL_15244: PANIC HANG PHKL_15199: HANG PHKL_15085: PANIC PHKL_14953: HANG I/O requests hang in LVM wait queue when the FC cord link is broken. PHKL_14856: PANIC This defect was only observed under extremely heavy loaded system with infrequency. PHKL_14803: HANG PHKL_14613: HANG PHKL_14568: PANIC Panic while trying to perform an lvmerge operation. PHKL_14490: PANIC HANG PHKL_14321: PANIC PHKL_14225: ABORT PHKL_14126: PANIC CORRUPTION PHKL_14049: PANIC PHKL_13986: PANIC PHKL_13911: PANIC PHKL_13868: OTHER Port I/O will not work correctly, machine may panic. PHKL_13768: OTHER Prevents MC/Service Guard TOC on PA8000 systems. PHKL_13744: PANIC PHKL_13514: PANIC PHKL_13452: PANIC PHKL_13305: HANG PHKL_13260: HANG This patch fixes a defect which could essentially hang the systems with VISUALIZE-FX graphics hardware. The patch in addition to this fixes a performance problem seen on systems that use applications with large number of shared memory segments. The systems spend too much time servicing protection id faults. PHKL_13247: ABORT PANIC PHKL_13206: CORRUPTION A clean file on VxFS can be marked bad. PHKL_13155: HANG PHKL_13014: PANIC PHKL_12963: PANIC PHKL_12901: PANIC PHKL_12662: HANG PHKL_12397: PANIC HANG PHKL_12306: HANG PHKL_12110: PANIC HANG PHKL_12100: CORRUPTION Kernel portion of fix for unrepairable VxFS filesystem where fsck produces the error message "no valid ILIST in fileset 999". PHKL_12088: OTHER Patch REQUIRED for the OmniStorage 2.20 product. PHKL_11860: PANIC PHKL_11766: PANIC PHKL_11733: OTHER Unmountable VxFS filesystem. PHKL_11730: PANIC PHKL_11696: PANIC PHKL_11607: PANIC PHKL_11561: CORRUPTION This patch when used with the appropriate SG/DLM version will avoid any potential windows for data corruption during reconfiguration in a HA cluster environment using SG or DLM. PHKL_11545: PANIC PHKL_11519: ABORT PHKL_11408: CORRUPTION PHKL_11406: CORRUPTION PHKL_11358: PANIC PHKL_11351: PANIC PHKL_11332: PANIC PHKL_11321: PANIC PHKL_11316: HANG The system hangs when a large number of users try to log in or out of the system simultaneously. PHKL_11238: PANIC So far, the panic only appears on MP systems running the latest Informix release. PHKL_11164: PANIC PHKL_11085: CORRUPTION From a customer perspective, EMC Symmetrix disks can appear to lose or corrupt data when rare spurious errors are reported. The data is actually able to be recovered on the disk, and this patch allows LVM to ignore the fact that the block was once "bad" and obtain the good data from the repaired block. PHKL_11055: HANG PHKL_11039: CORRUPTION This patch fixes data corruption for applications that create large files which keep changing their size dynamically. PHKL_11013: OTHER This problem leaves the filesystem disabled and unusable, and requires a system reboot to regain access to it. PHKL_11002: OTHER T600 will not BOOT. PHKL_10953: HANG PHKL_10932: OTHER HPMC on Emerald-class systems at boot time. PHKL_10930: HANG PHKL_10769: PANIC PHKL_10757: PANIC PHKL_10675: PANIC CORRUPTION PHKL_10643: PANIC PHKL_10554: PANIC The HPMC/panic that is fixed by this patch has been observed only in rare instances on pre-release hardware. However, the potential exists for similar problems in the field only if PHKL_9151 has been applied. This fix should also provide increased performance for PA-8000 systems. PHKL_10452: PANIC PHKL_10288: PANIC PHKL_10257: PANIC PHKL_10234: PANIC PHKL_10199: CORRUPTION PHKL_9931: HANG PHKL_9909: HANG PHKL_9569: HANG PHKL_9517: CORRUPTION PHKL_9372: PANIC PHKL_9370: OTHER Unmountable VxFS filesystem. PHKL_9365: CORRUPTION PHKL_9361: PANIC PHKL_9075: PANIC PHKL_8953: HANG PHKL_8908: PANIC CORRUPTION Panic should occur only if root VG 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_8683: PANIC PHKL_8532: CORRUPTION PHKL_8331: CORRUPTION PHKL_8294: HANG PHKL_8203: HANG PHKL_8187: HANG PHKL_8084: ABORT PHKL_7987: HANG PHKL_7899: PANIC HANG OTHER The KI instrumentation fix does not fall into any of specified symptoms; the root setuid fix does not either. PHKL_7870: PANIC PHKL_7776: OTHER Unmountable VxFS filesystem. Path Name: /hp-ux_patches/s700/10.X/PHKL_16730 Symptoms: PHKL_16730: - Accessing multiple tape drives simultaneously on a multi- processor system can cause a system panic - If a tape drive receives a bus reset the drive could rewind the tape without indicating an error to the application, causing data to be overwritten on the tape. PHKL_16592: SR: 5003435420 System can hang in vx_inval_list() DTS: JAGaa05787 SR: 5003368860 There is a memory leak in the LVM sub-system. DTS: JAGaa40191 SR: 1653277962 Data page fault panic occurs during large file (>1Gb) copy on systems with more than 1Gb of buffer cache defined. DTS: JAGaa12500 SR: 1653263962 A data page fault panic from locallookuppn or mount device busy errors on LOFS file systems. A stack trace might look like: panic+0x10 report_trap_or_int_and_panic+0xe8 trap+0x1054 $RDB_trap_patch+0x20 locallookuppn+0x5c8 lookuppn+0xdc lookupname+0x30 stat1+0x34 lstat64+0x14 syscall+0x1a4 $syscallrtn+0x0 SR: 5003435222 Oracle database stops with error number 7404. The dbwriters are blocked on HFS inodes. This problem has only been found to occur on HFS filesystems. DTS: JAGaa08610 On a busy system, it is possible for a read to contain only part of a concurrent write. This can occur if one process is updating a record at the same time that another process is reading that record. This would result in the reading process reading part of the old record and part of the new record. The write will then finish and no corruption of the record will occur. This problem has only been found to occur on HFS filesystems. DTS: JAGaa21147 SR: 5003410423 sar -c reports incorrect values for rchar/s and wchar/s for VxFS. SR: 5003423814 Processes can hang in wait_for_io() on multi-processor systems using VxFS. DTS: JAGaa13933 SR: 1653271163 A user sees a hang while using snapshot file systems. The stack trace for the hanging processs might look something like: _swtch+0x138 real_sleep+0x234 _sleep+0x14 ogetblk+0x248 getblk1+0x2ac vx_snap_getblk+0x34 vx_snap_getbitbp+0x128 vx_snap_findbit+0x64 vx_snap_copyblk+0xf8 vx_snap_copy+0x50 vx_snap_strategy+0x1e4 vx_buf_strategy+0x20 bwrite+0xf0 getnewbuf+0x4d0 allocbuf1+0x514 brealloc1+0x4c getblk1+0x26c vx_snap_getblk+0x34 vx_snap_getbitbp+0x128 vx_snap_findbit+0x64 vx_snap_read+0x1fc vx_snap_strategy+0x24c vx_reada_chain+0x9c vx_do_read_ahead+0x1d0 vx_read_ahead+0x4d0 vx_read1+0x6b8 vx_rdwr+0x164 vno_rw+0x68 rwuio+0xc4 read+0x54 syscall+0x1a4 $syscallrtn+0x0 DTS: JAGaa13609 SR: 1653269936 DMAPI cannot be used to manage regions of size greater than 2GB. PHKL_15478: This is a backport of patch PHKL_14745 from 11.0 The vnode spinlock will be held for a long time (2-10 sec) when vxfs traverses through the clean or dirty buffer chain When that occur, the system will experience intermittent hang. PHKL_13572: System seems to "hang" for 2-10 seconds intermittently during heavy filesystem I/O. from dts: "The problem seems to be easily reproduced on the customer's system using a simple "cp" command to write large files into a vxfs filesystem on their EMC Symmetrix disks. During the copy, real-time memory locked monitoring processes do not run for several seconds. The side effects first noticed are bad interactive system behavior, but the more severe impact is HA products triggering warnings or false-failover situations. Most severe are the occasional 10-11 second hangs which result in FDDI going off-ring and requiring a re-initialization." PHKL_7763: Applications using ftruncate(2) on VxFS files could possibly loose data. Corruption has been reported with Empress databases, and with Excel 5.0 spreadsheets (via LMX sharing a JFS filesystem). PHKL_16448: The sysmptoms that this patch fixes can only bee seen in the 800 series. This symptoms include: HSC FDDI cards cause an HPMC w/ heavy traffic and ioscans running simultaneously. PHKL_16455: 1) After lvsplit, fsck produces numerous errors 2) Panic during boot into LVM maintenance mode after LIF LABEL file removed 3) Panic with PV Links Patch PHKL_14954. 4) Panic: "all VFS_MOUNTROOTs failed: NEED DRIVERS", LVM corruption on mirrored boot disk. PHKL_15598: The time is not always read correctly when booting a system that has HIL hardware. This can generate the error message: Warning: file system time later than time-of-day register Getting time from file system PHKL_16387: SR: 4701399584 CR: JAGaa14952 9000 A series system with 875 (and up, ex 876, 895, 896..) cards using remote devices experiences device hang during boot-up or up-time. SR: 5003368860 CR: JAGaa05787 Command "vgcreate -e 65535 -p 255 " causes the system to panic with "malloc: allocation too large." SR: 5003428706 CR: JAGaa13736 When shmem magic executables are run on a system with best-fit policy for shared memory space allocation enabled, the system panics due to a data-page fault. SR: 1653250423 CR: JAGaa01479 Systems with PHKL_15081 prevents the panic, however it does not go through normal I/O path if the code returns ERETRY. SR: 4701393884 CR: JAGaa08709 Customers using LOFS may experience a panic (data page fault) after installing PHKL_15620. PHKL_15800: An unexpected EFAULT occurs on a read() system call of a sparse file. PHKL_15081: Systems with advanced JFS and low memory will panic with message "Interrupt Type 17 (Non-accessed data TLB miss)" while trying to access a page with space id of -1. This happens on systems with very low memory ONLY while an application tries to read/write large amounts of data using direct I/O instead of regular I/O. PHKL_12945: Process hang at exec() time on PA8000 (PA-RISC 2.0) systems using Advanced VxFS (OnlineJFS). PHKL_9415: 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_8735: 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_8388: 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_16207: enables control over percentage disk bw granted each group PHKL_15958: SR: 1653263962 CR: JAGaa12500 Stale file handle returned when NFS mounting the loopback filesystem (lofs). Loopback mounts fail for direct map pathname from AUFS (note: this is an enhancement in lofs to support AUFS). Unmount of loopback mounted directories fails. Possible silent data corruption if a SCSI bus is reset while writing to a tape. SR: 4701395822 CR: JAGaa12728 setcontext() function does not restore the user context pointed by ucp properly, causing the application using swapcontext() or setcontext() fail to resume at the correct user context. PHKL_15942: If two PVs powerfail and then one returns then the error "lv_syncx: returning error: 126" is reported and the mirror copy held on the returned PV is not sync'd. Only when both PVs return from powerfail does the mirror copy on that PV get sync'd up and the messages stop. PHKL_15915: An application receives SIGBUS during a memmove() operation on a properly aligned and mmap'd page. PHKL_15787: SR: 4701396200 DTS:JAGaa12818 other lab DTS: DSDe441605 and DSDe442781 LVM PVLink switches with failed FibreChannel hubs can be very slow. This patch is essential for FibreChannel hubs configurations. This patch reintroduces the FibreChannel hub PVLink switch improvements made in PHKL_15200. The prior version caused unexpected side effects for Galaxy and Nike arrays: potential for panic when used with Service Guard clusters and occasional link bounce (ping-pong) on transient link failures and link recovery. SR: 4701394635 DTS: JAGaa12375 UFS filesystems that have had large files unlinked and then new files created may see spikes in I/O for the writes of these later files. PHKL_15766: SR: 5003414540 Enabling the kernel kload driver will cause Enhanced DFS 1.5.1(EFS) to fail since EFS no longer needs it. SR: 4701394163 pfault() not able to update protection ID properly causes hang; this could have happened by accident while using "-Z" flag on a "cc" command for the following code: addr = NULL; mprotect(addr, 4096, PROT_READ); PHKL_15742: 1. SR: 1653236869 DTS: JAGaa01996 Mounting a VxFS filesystem over NFS using a small read buffer size causes failures when reading directories; as a result, directory entries can not be seen. 2. SR: 4701393074 DTS: JAGaa10827 Data page fault panic from vx_spin_lock() 3. SR: 5003295238 DTS: JAGaa09110 ftruncate with memory mapped files on VxFS 4. SR: 4701393819 DTS: JAGaa11061 System panics with a 'Data Page Fault' in ogetblk() after PHKL_15619 is installed. PHKL_15619: SR: 4701393819 CR: JAGaa11061 An 'nfsd' process may hang on the system. If a system dump is taken, the 'nfsd' process will be hanging in the vx_vn_bread() function. SR: 4701349175 DTS: DSDe435102 A System hang occurs whenever a large number of users log in/out at the same time. SR: 4701393884 CR: JAGaa08709 A directory mounted via the loopback filesystem (lofs) can be removed, making the mount inaccessible. SR: 5003413278 DTS: DSDe442455 If mounting a VxFS filesystem fails, processes accessing VxFS filesystems will hang. SR: 5003421628 DTS: JAGaa10135 System with large buffer cache (>1G) and heavy I/O hangs intermittently. The TOC dump shows processes are looping in rmprobe() and bcfeeding_frenzy(). SR: 1653259408 DTS: DSDe441605 The FibreChannel hubs performance improvement fix for DSDe441605 has unexpected side effects for customers with active-passive (Nike and Galaxy) arrays. These changes may cause these arrays to begin a ping-pong between primary and alternate links when a link is restored or when a transient error on the primary link occurs. SR: 4701393058 CR: JAGaa10826 After a VxFS filesystem is full, system panics with data page fault when accessing data buffers. PHKL_15504: VxFS can not update an extended inode for an existing file when the filesystem is completely full. Large file support doesn't allow DMAPI invisible writes. PHKL_15495: Panic occurs during a hazard stress test exercising VxFS on a HA cluster. PHKL_15492: The command: lvlnboot -d returns with the message: Unable to configure dump logical volume. Dump logical volume file beyond the IODC max address whenever any part of the given lies beyond 2G bytes from the start of a PCI-SCSI disk. PHKL_15456: SR 5003418244, DTS JAGaa07539: System experiences intermittent hangs; in some cases the system is able to resume processing without intervention in about 20 minutes, but other times it will lock up and need to be TOC'ed. The event trace in the dump shows: crash event was a TOC timespecfix+0x0 timespecadd+0x30 ktimer_expire+0x24c invoke_callouts+0x160 softclock+0x38 sw_service+0x154 mp_ext_interrupt+0x2a0 At times the system will panic with Spinlock deadlock. SR 4701391730, DTS DSDe438419: processes may hang doing mmap(2) due to a lock-order violation; the offending process' stack trace will look something like this: _swtch+0x138 _mp_b_sema_sleep+0xe0 vnode_vas_lock+0x78 freereg+0x194 smmap_common+0x5d0 smmap+0x38 syscall+0x1a4 $syscallrtn+0x0 SR 1653177089, DTS DSDe429996: 10.xx read/write via block devices is slower than 9.xx. PHKL_15321: Fsadm returns the following error during reorganization: vxfs fsadm: Ioctl failure: Invalid argument PHKL_15244: - DTS: DSDe442455 SR: 5003413278 System panics when multiple processes are trying to mount a snapshot filesystem using the same LV. - DTS: JAGaa02119 SR: 5003407601 Reboot process hangs on a MP system. PHKL_15199: SR:1653259408 DTS: DSDe442757 other lab DTS: DSDe441605 and DSDe442781 LVM PVLink switches with failed FibreChannel hubs can be very slow. LVM PVsparing does not always start using a spare when a device fails. Hang occurs with heavy I/O stress and patch PHKL_14804 installed. This patch is essential for the use of FibreChannel hubs. PHKL_15145: Flush data to disk before splitting mirrored disks. PHKL_15085: The system will panic if a graphics process does graphics DMA on VISUALIZE-FX hardware, and then execs another program without forking first. PHKL_15057: The current first-fit allocation policy for allocating virtual addresses for shared objects (shared memory, memory mapped files, etc.) does not meet certain customers' requirements. It is found to cause fragmentation of the shared virtual space, preventing certain applications from being run. PHKL_14955: This patch allows the NDDB kernel debugger to debug 10.20 kernels running on PA-RISC 2.0 CPUs. Without this patch, NDDB (and landdb/rsddb) may report incorrect status such as "Breakpoint at 0x0". The landdb/rsddb kernel debuggers will no longer function after the patch is applied; the NDDB kernel debugger must be used instead. Other functionality provided in this patch includes: o Support the Core I/O 10Base-T LAN card for NDDB communications. o Support configurations where the console is connected to the second RS-232 port. o Support platforms using RS-232 communications on the GSC-to-PCI bus bridge. o Detach the target kernel using the "free" command; reboot the target using the "kill" or "quit" commands. o NDDB "ps", "ktps", and "cpus" commands show info on processes, "kernel threads", and CPUs. o Various bug fixes. PHKL_14953: I/O requests passing through the LVM layer hang when the pv-link is broken (FC cable is pulled off). The I/O requests are hung even if the pv-link is restored. PHKL_14917: Excessive SCSI timeouts on MO drives. PHKL_14856: Machine under a heavy load can panic with an instruction page fault. PHKL_14803: SR: 5003407601 DTS: JAGaa02119 System hangs during reboot. SR: 5003407619 DTS: JAGaa01516 Under heavy I/O, after the buffer cache allocation has reached its system defined maximum, the system eventually hangs when all I/O processes sleep on waiting for buffer cache. PHKL_14740: When a Service Guard cluster experiences a failure on one node, the VGs may fail to activate on the surviving node when the shared disks are using FibreChannel. PHKL_14685: When the customer installs the flock manager driver, the library libflkmgr.a does not exist. This is seen only in those environments running flock manager. PHKL_14613: System hangs under extreme load on UFS filesystem while a LV creation is in progress. PHKL_14568: This patch fixes 3 defects: - SR:1653254987 DTS:JAGaa01797 MP systems using LVM mirroring could experience panics (data fage fault) while doing an lvmerge() operation. - SR:4701379347 DTS:DSDe441470 Add flock manager driver functionality - SR:1653216952 DTS:DSDe437110 sleep(3C) behaves incorrectly for values larger than (2^32-1)/200 = 21474836 seconds. The man page documents legal values up to 2^32-1 seconds + 10^9-1 nanoseconds. PHKL_14490: This patch fixes three defects: - SR: 4701382564, DTS: DSDe441726 If the kernel free sysmap space falls to 0, the system panics without prior warning that indicates this condition. - SR: 1653251934 DTS: JAGaa01592 The system hangs under heavy I/O involving VxFS filesystems. When the buffer cache virtual space is heavily fragmented and a readhead is being done, system hangs. - SR: 1653252544 DTS: DSDe441877 Some user applications will hang with high system load. These processes cannot be killed and the system needs to be rebooted to clear these processes. PHKL_14323: Command lvlnboot may fail with the following error: "No Boot Logical Volume Configured". PHKL_14321: This patch fixes two defects : - SR: 1653235176, DTS: JAGaa01482 This defect causes a panic in an MP system when two processes are doing mmap/munmap on portions of the same file using a sliding window. The user will see the system panic with "panic: rmfree: overlap" message. The stack trace will be as shown below: panic+0x10 rmfree+0x268 quaddealloc34+0x30 hdl_detach+0x108 detachreg+0x3c do_munmap+0x190 do_munmap+0x84 syscall+0x1a4 A different panic could occur due to an unrelated race condition when mmap/munmap is called. This second panic is a result of data page fault. The stack trace in this case will be as shown below: panic+0x3C report_trap_or_int_and_panic+0x8C trap+0xC18 $RDB_trap_patch+0x20 smmap+0x8F0 syscall+0x1A4 - SR: 4701383612, DTS: DSDe441827 The defect's symptoms are that writes to a VME device will succeed on 10.20 but reads will fail with EFAULT. PHKL_14225: Application experiences random illegal instruction trap when executing cache-flushing code. PHKL_14183: This patch is part of the 10.20 ACE 2 bundle which adds networking enhancements to 10.20. New networking features supported in ACE 2 include NFS Version 3.0, AutoFS, and CacheFS. PHKL_14126: This patch fixes two defects : - SR: 4701381608, DTS: DSDe441567 Patch PHKL_13684 introduced a defect that can break applications which use the vnode layer procedure vn_open(). This can result in a panic due to an invalid address or possibly on data corruption. Currently we are only aware of conflicts with Netware. - SR: 1653223404, DTS: DSDe438306 vgchange display couldn't query one physical volume The specified path does not correspond to PV attached to this VG. After issue vgchange with -a y -q n options, system trap panic. PHKL_14049: This patch fixes three problems: a) SR: 1653247486, DTS: JAGaa01357 For a mirrored LVM root disk containing 2**n extents, if the system is booted in maintenance mode (hpux -lm), it will panic with trap 15 data page fault on the next reboot. b) SR: 1653239137, DTS: JAGaa01378 For a root VG with two disks which are mirror partners, if one disk becomes inaccessible, the system panics on bootup with trap 15 data page fault. c) SR: 1653248690, DTS: JAGaa01406 System panics in lv_end() with isr.ior=0.58 data page fault when a bad block is detected on disk. The console message shows: lv_readvgdats: Could not read VGDA 1 header & trailer from disk H/W path x/x.x.0 (error = 5) lv_readvgdats: Could not read VGDA 2 header & trailer from disk H/W path x/x.x.0 (error = 5) PHKL_14012: This is an enhancement to add the flock manager driver hooks to the kernel. This patch is only needed if you are planning to use the flock manager driver. PHKL_14009: pstat_getlv() returns information about first VG only. PHKL_13986: Allows attachment of external HP-PB card cage to HP-HSC to HP-PB converter. PHKL_13911: In a mixed UFS/VxFS environment, the system panics with a dirty invalid buffer which was associated with a UFS filesystem that has since been unmounted. The typical stack trace of the panic looks like the following: panic+0x14 brelse+0x1ec getnewbuf+0x6b0 ogetblk+0x104 getblk1+0x258 vx_getblk+0x5c PHKL_13874: This patch fixes two problems: a) When running fsadm on a file which was created under VxFS version 2, sometimes "Invalid Argument" would be reported. b) When running fsadm on a file which was created under VxFS version 2, sometimes "No such device or address" would be reported. PHKL_13868: PCI port I/O does not work properly, and machine may panic. PHKL_13795: This patch is part of the 10.20 ACE 2 bundle which adds networking enhancements to 10.20. New networking features supported in ACE 2 include NFS Version 3.0, AutoFs, and CacheFS. PHKL_13768: Temporary system hang on PA8000 systems, possibly resulting in TOC to preserve system integrity (if running MC/Service Guard). When analysing the system crash dump, a processor would be executing in the kernel routine alloc_large_page(). PHKL_13761: mprotect() system call causes high system time resulting in poor system performance. PHKL_13744: Errors in opening a tape device on the HSC bus may cause a data page fault panic. The panic occurs at st_head_pos+0x5c. PHKL_13713: When using chown for certain user IDs, the command would fail. PHKL_13684: In a multi-vendor client-server environment (HP client or HP server), a user-supplied umask is ignored during file creation, even if no default ACL is present. This appears to violate POSIX ACL draft 12. PHKL_13680: 10.xx read/write via block special device file is slower than 9.xx. PHKL_13514: With certain hardware configurations, especially on the J2240, it is possible for the system to panic (at bootup) with the message: panic: Could not assign interrupt handler PHKL_13508: On a heavily fragmented VxFS filesystem, bdf and df show only small amounts of available space. df furthermore shows a larger percentage number for minfree although this concept is unknown to VxFS. All this is ok on a VxFS Version 2 filesystem, but on a Version 3 filesystem extents smaller than 8k are available for files. PHKL_13452: The user will see a data page fault PANIC with vx_attr_alloc(), vx_attr_indadd(), or vx_attr_iget() at the top of the stack. A sample stack trace might look like: panic+0x10 report_trap_or_int_and_panic+0xe8 trap+0x1054 $RDB_trap_patch+0x20 vx_attr_iget+0x90 vx_iremove_attr+0x358 vx_attr_uset+0x374 vx_do_ioctl+0x73c vx_ioctl+0x38 vno_ioctl+0x98 ioctl+0x444 syscall+0x1a4 PHKL_13305: This problem manifests as a hang during a reboot operation. The reboot can be initiated with a shutdown command. The problem will only appear on a multi-processor machine. I/O in progress during the reboot either from disk or from the network can cause the primary reboot processor to wait for an indefinite amount of time. PHKL_13260: This patch fixes three problems: a) SR: 1653237842, DTS: JAGaa01160 Slow performance with high system time on PA2.0 and PA1.1 systems. The system slows down under user applications with lots of shared memory segments (like Informix database which uses lots of shared memory segments). b) SR: 1653237842, DTS: JAGaa01160 Illegal sharing of protection ids lead to silent data corruption (SHMEM_MAGIC applications) c) SR: 4701373969, DTS: DSDe440766 This defect causes VISUALIZE-FX graphics hardware to lock up. If the VISUALIZE-FX device is the console for the machine, this will render the machine unusable unless it can be reached over a network (in which case killing and restarting the X server should fix the problem). CTRL-SHIFT-RESET from the console keyboard will not terminate the X server in this case. PHKL_13247: The shared PV LINKS will not switch when needed. The activation of the VG using vgchange -a s may fail on one of the nodes if the command is being run simultaneously on all the nodes. HPMC or bad pointer panic in FibreChannel driver on ServiceGuard cluster failover. Failure to activate VG (any I/O connect type) on ServiceGuard cluster failover. PHKL_13237: If serialize() command is executed as: 'serialize ls', the command fails with the error number set to EINVAL. (User id must be 0, or user belong to a group that has privilege to execute the serialize command). The serialize command should have serialized the target process, in this case the command 'ls', and should have listed the content of the current directory. PHKL_13206: When getdirentries() is incorrectly called with a regular file on VxFS filesystem, following message will be reported and the clean file can be marked bad. "vxfs: mesg 008: vx_direrr - file system inode X block Y error 6" or "vxfs: mesg 017: vx_dirbread - file system inode X marked bad" or "vxfs: mesg 016: vx_ilisterr - file system error reading inode X" PHKL_13155: Processes hang intermittently due to process deactivation and reactivation. PHKL_13014: - 9000/725/B panic on boot. - Tape driver rejects odd-length write requests. - "Unhandled pending interrupt" declaration and SCSI bus reset. PHKL_12997: When dump is configured past 2GB on a device connected to a HSC F/W SCSI interface card, the device fails to configure: WARNING: Dump space on device cannot be configured past 2097151 bytes. Device skipped. PHKL_12963: In the past, a process running in a group could consume more than just its own groups entitlement if excess CPU cycles were available. This change allows this to optionally be disallowed / capped within PRM. Also, there was a problem when PRM, thread stealing and processor affinity were used/occurred on a system at the same time. In this case, it was possible for a processor to not find a process, which could cause a panic. PHKL_12901: A kernel stack overflow panic occurs when the stack is valid and all three pages allocated for kernel stack are consumed. The defect is seen when a combination of NFS,LVM,VxFS related modules are called. PHKL_12669: This patch contains problems in three areas: 1. There are no warning to user when bad block alternates were allocated inside the user data area. 2. There is no way to use lv timeout feature when the async driver minor number is not 0. 3. Add a new lvol flag in lv_lvsubr.c to support a command patch. PHKL_12662: UFS filesystem may hang on system reboot. PHKL_12660: EINVAL errors on FibreChannel raw disk reads and writes. PHKL_12633: SHMEM_MAGIC executables suffer from unacceptable performance greatly impairing its usefulness. PHKL_12601: VxFS systems do not allow a process to ftruncate() a file it has opened, write-locked and read from. When the program fails, errno is set to 11 which means resource is temporarily unavailable. PHKL_12409: Applications relying on alarm() returning a number greater than zero will fail if there was time remaining on the cancelled alarm and were trying to re-schedule the original alarm. alarm() returns "zero" when cancelling a previous alarm() with an alarm pending. PHKL_12397: This patch fixes two defects : - System panic (data page fault) when debugging processes over an interruptable NFS mount point. - After call to pstat_getmsg(), all accesses to the message queue hang. PHKL_12378: MP systems running applications that require many files with filenames longer than 14 characters to be accessed will experience severe CPU contention. Netscape Mail server v3.0 with Netscape mail server Benchmark puts this in evidence by reporting a very low message receive/deliver rate. Systems with large buffer cache will have spinlock contention problem. PHKL_12306: Glance reports 0 MB/s on GSC disks. EINVAL on read/write to FC EMC Symmetrix. System hang. Device hang. PHKL_12217: The tar command can go into a tight loop, backing up the same file over and over on a NFS-mounted filesystem. So far this problem has been seen only on NFS filesystems exported from SGI IRIX 6.2 systems. PHKL_12110: System hangs on UP systems or spinlock deadlocks on MP systems, when using nanosleep system call. If using signals which were to be ignored when in nanosleep() we were awakened even though we should not have been. This patch is especially critical as soon as newer libc patches are installed on the system. The first releases of libc to be critical are PHCO_10384 for 10.10, PHCO_11004 for 10.20 and PHCO_10652 for 10.01. PHKL_12100: command patch PHCO_12922 The following problems are fixed: 1) Under certain circumstances after a hard failure, VxFs fsck log replay would fail requiring a full fsck. 2) On large filesystems containing a very large number of files, full fsck would run extremely slowly. PHKL_12088: The DMAPI functionality delivered with HP-UX 10.20 OnlineJFS delivers a Kernel-space library, but does not include a User-level library. OmniStorage 2.20 requires a User-space DMAPI library to function successfully. PHKL_12073: With sa_flags (in sigaction structure) set to SA_SIGINFO, after a child process abnormally terminates without a core file being generated, the si_code number of the siginfo_t structure is supposed to contain CLD_KILLED. This failed to happen when the child process abnormally terminated with a SIGPOLL signal. PHKL_12042: Resource-intensive processes (such as an Informix oninit) either perform poorly over time (as timeshare) or monopolize the system (as realtime). Also, MP systems show processes frequently being moved from one CPU to another. PHKL_11902: pid information is missing from a diagnostic message which tries to explain to a user that their process does not have the correct locking priveleges required for using large text pages. PHKL_11860: The PHKL_9371 installed system panics during reboot, if reboot command is used. This patch fixes this problem. PHKL_11766: 1. vgextend command will complain "too many links" if user wants to add an addition PV to a VG, and the total PV and their links add up to total number of maximum PV allowed in a VG. 2. trap panic in lv_resyncpv from LVM. Lots of "pvnum is POWERFAILED" messages. PHKL_11733: After a hard failure (panic/hang/TOC), a VxFS filesystem may not mount and will return the following error message: vxfs mount: %s is not a vxfs filesystem. This could even happen with patches PHKL_9371 and PHCO_11223 installed. A full fsck does not clean the filesystem; a newfs/mkfs is the only solution. PHKL_11730: Data page fault in bwrite. PHKL_11696: panic: hdl_alloc_spaceid: spacemap exhausted PHKL_11637: CDROM drive remains locked when system is rebooted. PHKL_11632: SCSI bus resets when probing bus with DLT library robotic arm via ioscan. PHKL_11614: Accounting does not work for the clients in a diskless cluster. The accounting file does not get updated for users other than ROOT when accounting is ON, if the pacct file is on an NFS filesystem. PHKL_11607: System may panic in vx_itimes() when mounting a VxFS file system after a boot from a hard failure. PHKL_11561: A customer might find corrupt data on disk after a Service Guard or Distributed Lock Manager fail-over. This defect is specific to the HA cluster environments. PHKL_11545: - Fixes an intermittent panic when opening a tape device on the HSC bus. - Improves performance for wide SCSI tape devices connected via the HSC bus. - Allows DLT4000 devices to perform odd-sized writes. PHKL_11519: On a NFS server with a Vxfs filesystem exported, the file /var/adm/nettl.LOG0x grows dramatically with the recording of "read failed with errno 22" (EINVAL). This problem is addressed by kernel patch PHKL_11322 among other problems. However, after the patch is installed, some NFS clients experience command coredump on the NFS-mounted VxFS disk. PHKL_11471: Quota command shows poor performance on a busy system under VxFS. PHKL_11408: Corruption of memory pages on systems with PA-RISC 2.0 CPU. Problem should happen rarely and only under extreme memory stress. PHKL_11406: When using large environments greater than 20 kbytes user applications dump core sometimes, or get bad data. PHKL_11358: A panic would result when trying to rename a vnode which was a UFS mount point under a VxFS directory. The reverse did not cause a panic but was not being handled properly either. PHKL_11351: (DSDe438658) panic: Data Page Fault with FDDI. T600 will HPMC when HSC (GSC) interface cards using a GSCtoPCI interface chip are installed. (4701362111) Any MP system is likely to panic when multiple HSC (GSC) interface cards using GSCtoPCI interface chips are installed. (DSDe437012) Performance enhancement in PCI services. PHKL_11339: A process launched from shell sees (getrlimit) limits set in the shell via ulimit -t but ignores them. When a process forks, the child sees the limits set by the parent via setrlimit but ignores them. PHKL_11332: (4701356766/ DSDe437007; 4701353888/ DSDe436271) T600 systems panics under heavy I/O load stress testing during lab tests. PHKL_11321: This patch fixes two VxFS performance problems and one defect: 1) Upgrading from 10.10 to 10.20, customer experienced approximately 25% performance degradation in read operation under VxFS. 2) Loading a program for a second and subsequent time takes much longer if the program is using shared libraries on VxFS. 3) Occasional panic occurs when running an executable which attempts to pagein through vnode level, producing a stack: trap+0xf84 0.0xe21c4 0x6954.0x7ffe75b8 ... $RDB_trap_patch+0x20 0.0x22608 0x6954.0x7ffe75b8 ... lbcopy_fp_method1+0x58 0.0x222b98 0x6954.0x7ffe7108 ... privlbcopy+0x1c 0.0x222fc4 0x6954.0x7ffe70c8 ... uiomove+0x4f0 0.0xfabe8 0x6954.0x7ffe7008 ... vx_read1+0x26c 0.0xb9744 0x6954.0x7ffe6ec8 ... vx_rdwr+0x16c 0.0xc5164 0x6954.0x7ffe6e08 ... vn_rdwr+0x8c 0.0x107b04 0x6954.0x7ffe6d48 ... mfs_hpux_pagein+0x448 0.0x1cbb5c 0x6954.0x7ffe6c88 ... virtual_fault+0x9a0 0.0xf1fc8 0x6954.0x7ffe6b48 ... vfault+0x104 0.0xf281c 0x6954.0x7ffe6ac8 ... trap+0x129c and the message: trap type 15, pcsq.pcoq = 0.222b98, isr.ior = 18e.4179000 savestate ptr = 0x7ffe7108, savestate return ptr = 0x222fc4 9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996 panic: (display==0xbd00, flags==0x0) Data page fault This is mostly seen on PureAtria's Clearcase product which sets the UIOSEG_PAGEIN flag for vn_rdwr() calls. PHKL_11316: A system hang occurs whenever a large number of users login or logout at the same time. The password file has large number of entries and the system can have around 1000 concurrent connections. The problem occurs when many processes try to access the same file concurrently, the inode locking routines start dealing with the contention very inefficiently. PHKL_11247: On a VxFS filesystem with quotas enabled, users who do not have quotas set receive "write: Disk quota exceeded" error message when creating files on this filesystem. PHKL_11244: When accessing an address returned by mmap(), the application gets a SIGBUS error and core is dumped. PHKL_11238: Panic on S800 MP systems using 10.01+ with latest Informix PHKL_11164: The system message buffer would show many "sysmap: rmap ovflo, lost [...]". Eventually, the system would panic with "kalloc: out of kernel virtual space." This problem would only be seen on PA8000 systems. PHKL_11085: On very rare occasions EMC Symmetrix disk drives will report a disk error which causes LVM to mark the block as bad in its bad block directory. The Symmetrix drive can be "repaired" online by EMC support, but the entry in the LVM bad block directory will prevent any further I/O to the affected block. This patch enables a new relocation policy which will prevent entries from being added to the bad block directory. In order to make use of this new relocation policy, a commands patch, PHCO_10826 must also be installed. Also, algorithms within LVM that deal with PVLinks had built in the assumption that Nike serial numbers were unique. This turned out to not be the case. The only time that the serial numbers need to be unique is in OPS clusters. This patch removes this restriction for all non-OPS cluster environments. PHKL_11055: Large memory systems could hang while trying to allocate kernel memory. A TOC crash dump would show a processor executing in alloc_large_page() while other processors would be spinning waiting for the pfdat_lock spinlock. This problem would only be seen on PA8000 systems. PHKL_11039: VxFS filesystem corruption when running applications using file truncation on large files. The system message buffer will show: "vxfs: mesg 017: vx_trunc - /mnt file system inode \ 123 marked bad. vxfs: mesg 016: vx_ilisterr - /mnt file system error \ reading inode 123". It also fixes a malloc panic which was found while fixing this defect. PHKL_11013: The vxupgrade command, used to convert a VxFS version 2 file system to a version 3, can give an I/O error on execution. This causes the filesystem to be marked as unavailable, and a full fsck to be run. PHKL_11006: timer_settime(2) does not set 10ms timer interval properly. The smallest interval can be set is 20ms. PHKL_11002: (4701353888/ DSDe436271) T600 systems will not boot without this patch on 10.20 HP-UX. PHKL_10966: When running fsadm to reorganize extents (de-fragment) the command fails with error: exclusion zone for bno = 323584, len = 2048 failed This error message does not occur at all times. It has been observed when running fsadm on filesystems which contain directories with many small files. PHKL_10953: Severe system hang: the crash dump (TOC) would show many threads waiting for the filesystem alpha semaphore. The kernel stack trace of the thread owning filesys_sema would show bc_yield() calling swtch(). PHKL_10932: (4701353078/DSDe436182) Emerald-class (890, T5x0, T600) systems will experience an HPMC at boot when IODC for memory controllers is being accessed. Note: if you are not experiencing this problem now, then your memory controllers are not subject to this problem. (This problem is NOT intermittant.) PHKL_10930: The system hangs when trying to dump core, as the result of a system panic or TOC. PHKL_10821: Although users can now exec() programs with up to 2048000 bytes of argument and env strings, sysconfig() _SC_ARG_MAX continues to return 20480 bytes as the maximum length of all arguments and env strings. PHKL_10800: Audit records contain relative path names which the user has no idea where they are anchored. This fix prepends the cwd to the relative path name yielding a complete absolute path. PHKL_10769: On C200 and newer workstations with PCI there is a possible HPMC that can occur due to a hardware bug in certain revisions of the PCI bus ASIC. This patch prevents the HPMC from happening. PHKL_10757: Workstation Additional Core Enhancements for HP-UX 10.20 (July 1997). This patch provides additional enhancements to support new HP workstations. The primary change is the addition of a new signal (SIGGFAULT) and virtual memory subsystem changes to support virtual device locking for new VISUALIZE-FX graphics hardware. It also contains two bug fixes: one for the MP PDIR bug (could panic the system) and the other for the pstat_cmd() panic. PHKL_10756: This patch contains enhancements to support the GSCtoPCI PCI Bus Bridge on HP workstations. PHKL_10755: Performance enhancements for PCI SCSI (Ultra-SCSI). PHKL_10689: HP-UX didn't log any error when a user process: 1. encounters a swap space shortage 2. exceeds a system resource limitation Processes were terminated but the errors were not recorded on any of the system log files. PHKL_10675: (1) System may panic with "panic: sync not stale" while running lvmerge (merging LVM mirrors). For the panic to occur, an I/O timeout must occur during the lvmerge operation which results in a resync getting scheduled. (2) Potential data corruption if user I/O requests encounter errors to the same extents which are being reimaged by lvmerge. (3) Various panics during VG activation (vgchange -a). A bit is cleared in a kernel structure which LVM has already freed. If another kernel subsystem has been allocated the freed memory before the bit is cleared, panics or other strange behaviors may occur. This particular defect was introduced by PHKL_9000. PHKL_10643: System panic with Memory Mapped Files on UFS filesystem. A typical kernel stack trace would show a data page fault panic in hdl_unsetbits() called from async_pagein_comp(). PHKL_10554: PA-8000 performance; fix kernel-assisted branch prediction. Corrects corner case condition that causes an HPMC. The stack trace would point to module flip_comb(). This corner case has only been seen in lab-internal testing, using pre-release hardware. It has not been seen on any customer's system. PHKL_10452: Panic: kernel stack overflow; trace includes lv_end(). PHKL_10421: When reading a tape on a 7980S tape drive, reading a partial record fails and returns I/O Error. If a tape device receives a bus reset the device will rewind. Following this, when the device is closed, the driver will write EOF marks at the beginning of the tape causing the remaining data to be unusable. When a tape device is opened for write access and the media is write protected the driver returns I/O Error, which can be ambiguous. EPERM (Permission denied) is a more descriptive error. PHKL_10316: When ptrace is called from the DDE debugger while the DDE debugger has watchpoints set, the ptrace system call is called to single step the user process. If the ptrace call is handling a user signal and another signal event is pro- cessed before returning to the user process from ptrace, ptrace may incorretly sent the user's save_state program counter to an incorrect value and return EIO to the parent debugger. PHKL_10288: Panic trap 15 in bwrite() under heavy disk I/O stress. PHKL_10257: Panic with "vn_rele" with EXEC_MAGIC executable run over NFS PHKL_10234: panic: kernel scheduler interrupt PHKL_10199: VxFS version 3 filesystem returns the following file allocation error on filesystems large than 64Gb before the filesystem is actually full: vxfs: msg001: vx_nospace - /dev/vgXX/lvolY file system full (1 block extent) The following console message may also be seen: vxfs: mesg 003: vx_mapbad - /dev/vgXX/lvolY file system free extent bitmap in au nnnn marked bad PHKL_10176: The total length (including terminators) of all argv and env strings passed to a newly-EXECed process was 20480 bytes. If a greater length was detected, the exec() failed with E2BIG. PHKL_10064: Setting a negative timestamp with utime() fails. PHKL_9965: The performance of some drivers (mostly Networking, and for example ATM) was not optimal on Cache Coherent IO systems such as the K-series. PHKL_9931: VxFS hangs waiting for I/O to finish. PHKL_9919: Timing differences between CPU too large, causing midaemon to die frequently (often in less than 15 minutes). PHKL_9909: A deadlock can occur on system running LVM, VxFS and UFS. The hang was introduced by one process running lvmerge on UFS LVs and another process running umount on a VxFS LV. This deadlock can only occur with the following scenario: (1) Process A is running a lvmerge or a lvsplit on a UFS LV (2) Process B is running a mount, umount or sync on a VxFS LV. PHKL_9711: Each time edquota -t is invoked for a VxFS filesystem, it resets the previously defined filesystem time limit back to default (7 days). PHKL_9569: This patch addresses 2 distinct VxFS symptoms: - When trying to take a filesystem 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_9529: vgdisplay(1M)/vgextend(1M) show incorrect value for maximum number of PE per PV. PHKL_9517: VxFS filesystem corruption can occur when running the reorg option of the fsadm command on a busy filesystem. System diagnostic messages from the dmesg command will include the following: vxfs: mesg 008: vx_direrr - /??? file system inode X block Y error 6 vxfs: mesg 017: vx_iread - /??? file system inode X marked bad vxfs: mesg 016: vx_ilisterr - /??? file system error reading inode X vxfs: mesg 008: vx_direrr - /??? file system inode X block Y error 6 vxfs: mesg 017: vx_iread - /??? file system error reading inode X PHKL_9372: Panic: "data page fault" when using fsadm to resize a mounted VxFS filesystem with disk quotas. PHKL_9370: If a customer upgrades from 10.01 or 10.10 to 10.20, and tries to increase their VxFS filesystems via SAM, the filesystem will not mount after extending the volume and filesystem. The typical approach for SAM is: 1) unmount the filesystem 2) lvextend the volume 3) extendfs the filesystem 4) mount the filesystem The mount will always fail in this case. PHKL_9365: Random, spurious, rare instances of data corruption, usually in I/O to devices. This is rare enough (and masked by normal system configurations) that it has not been observed in customer systems, only within HP. PHKL_9361: MP machine used as a NFS client panics with: panic: (display==0xb800, flags==0x0) Data page fault panic stack: crash event was a panic panic+0x10 report_trap_or_int_and_panic+0x8c trap+0xbfc $call_trap+0x20 binvalfree_vfs+0x5c rinval+0x10 nfs_unmount+0x20 umount_vfs+0x5c umount_root+0x20 umount+0x98 syscall+0x1a4 PHKL_9273: On MP systems, applications which do file locking frequently can perform poorly. The symptoms are a high switch rate (switch rate > syscall rate) and heavy system activity (%sys > 90%). PHKL_9153: Add write-gathering support for NFS servers. PHKL_9151: This patch includes 3 separate performance enhancements. All are targetted for PA-RISC 8000 processors. 1. Kernel-assisted branch prediction. 2. bl->bll branch stub elimination. 3. Repositioning performance-critical kernel assembly routines. PHKL_9075: Applications using Memory Mapped Files were performing poorly when mapping thousands of pregions to the same file. The problem would mainly be noticed with shared (MAP_SHARED) and exclusive (MAP_FIXED with address in the process private data space) mappings. This patch is required when using the Object Store database product from ODI. Additionally, this patch provides an enhancement to the mprotect(2) system call: mprotect(2) used to fail protecting non mmap(2)'ed addresses. This patch enables to mprotect(2) data, stack and shared memory segment addresses. Finally, this patch fixes a kernel panic with large buffer cache: kernel panic with a data page fault when attempting to copy data from the last page of the third quadrant. This will only occur on systems with a buffer cache of one gigabyte or larger. The panic message will display the following: isr.ior = 0.bffffffc Running strings on a raw sar(1) output file can show some printable strings (sar ignores these). PHKL_8999: Without this patch customers are limited to supporting 2 nodes in a shared environment. With this patch customers can now use SLVM in a 4 node cluster. Alternate links for devices such as the Nike disk array are now supported in a shared environment. This change supports a new -t switch for lvchange, allowing the administrator to limit the time LVM holds I/O requests to be retried on LVs when disks are powerfailed. Without using this option, LVM will hold the I/O requests as long as there 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 LV. This feature is obviously not to be used indiscriminately. For many High Availability applications, having I/O requests held in kernel indefinitely is not acceptable. Most customers should not need to use the new switch. PHKL_8953: The K400 4-way suddenly stopped to work. The user heavily accessed VxFS snapshot filesystem and have done sync's in parallel. PHKL_8908: "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_8755: Fixes a bug with Exabyte tape drives that caused append writes (those not at BOT) to be in non-compressed mode when using the BEST density setting. PHKL_8716: After call to pstat_getmsg(), all accesses to the message queue pstat_getmsg() was called hang. PHKL_8683: System panic with data page fault on ICS. PHKL_8532: System crash dumps are corrupt and unusable. PHKL_8506: This patch changes the behavior of the open() call with a write-protected tape. The open() will now fail with EIO if the mode is not O_RDONLY. PHKL_8481: VxFS performance has improved disk I/O throughput at the cost of extra CPU utilization. This patch improves VxFS performance by implementing a log buffer re-use scheme and also by making modifications to the read/write sleep lock primitives. PHKL_8346: Executables cannot access more than 1.75 GB shared memory. PHKL_8331: Data loss with UFS files using fragments. PHKL_8294: When multiple nfsd processes access the same file simultaneously, they hang in a deadlock. PHKL_8203: MP system hangs during panic. The LED shows system staying at INIT CB0B. Machine needs to be TOC'ed to save the core dump. PHKL_8187: Select timeouts are retried forever, i.e. I/O requests never complete when a device is removed. SCSI bus hang and reset. PHKL_8128: Device files other than those that use the BEST density do not work. Opening such a device file returns EINVAL. This happens only on DLT tape drives. PHKL_8084: LVM may return I/O's with errors instead of sending them to an alternate link. This patch also facilitates using "vgreduce -f" for PVs which have alternate links; without this patch "vgreduce -f" is not allowed on LVM disks with alternate links. PHKL_8028: Without immediate reporting enabled a DLT tape drive will take several seconds for each filemark written. If a user application is writing many filemarks to a tape the performance will be poor. This patch enables immediate reporting of filemarks, which should improve performance for an application that writes many filemarks to a tape. PHKL_7987: System hang. Select timeouts with EMC/Symmetrix disk array. PHKL_7967: fuser does not report processes in lofs. PHKL_7951: Ptrace not allowing writes on PA8000 to some floating point registers. PHKL_7899: KI queuedone, enqueue and queuestart traces on VxFS may contain NULL values in the b_apid and b_upid fields. With a system running a heavy load using VxFS on LVM, the following panic may occur: "lv_syncx: returning error: 5" Systems running VxFS may hang due to a deadlock problem. The setuid bit will be removed on a VxFS file when the file is edited or text has been appended to it when run as root. PHKL_7870: lvreduce(1M) may cause a system panic, if it is used to reduce an LV which was left inconsistent by a prior LVM operation. lvreduce(1M) could not be used to remove LVs that were somehow corrupted, if it was, the command would cause a system panic. PHKL_7776: It's possible for a VxFS filesystem to get into a state where it can't be mounted (except read-only), but fsck(1M) does not report any problem with it. At mount time, the kernel prints the following warning on the console: vxfs: mesg 012: vx_iget - file system invalid inode number XXX and mount(1M) fails with the following message: vxfs mount: /dev/XXX is not a vxfs file system. Once a filesystem has gotten into this state, it remains unmountable, even after running fsck(1M). Defect Description: PHKL_16730: - Panic was caused by a new logging routine which wasn't MP-safe. Two processes running the routine at the same time could cause a pointer to overrun the end of the logging buffer. - Bus reset issue is a problem which as always existed in the driver and was just recently found to be a possible problem. PHKL_16592: SR: 5003435420 Yield the CPU when a time slice has expired. Also, remove the outer retry loop so that we go through the for loop only once. This bug was introduced by PHKL_15478 SR: 5003368860 CR: JAGaa05787 The patch PHKL_16388 (vgcreate can panic the system) bypassed kmalloc and called kalloc directly. This did not allow for the correct freeing of that memory. This bug was introduced by PHKL_16388. DTS: JAGaa40191 SR: 1653277962 On systems with more than .9Gb of buffer cache, two buffer cache resource maps are used. Depending on the requirement of the obtained buffer and the availability of spaces in these resource maps, buffers are allocated and remapped between the maps. When a bufmap allocation fails due to map fragmentation, we will back out. However, a bug in the back out code does not restore the correct space id upon returning, leaving the calling routine with a buffer of a wrong space id. This causes data page fault when this buffer is used. This bug was introduced by PHKL_15620. DTS: JAGaa12500 SR: 1653263962 To reproduce the LOFS PANIC problem: # mkdir -p /mnt/lv1 # mount /dev/vg00/lv1 /mnt/lv1 # mkdir /mnt/lv1/lv2 # mount /dev/vg00/lv2 /mnt/lv1/lv2 # mkdir -p /lofs/lv1 # mount -F lofs /mnt/lv1 /lofs/lv1 # ls -lF /lofs/lv1/lv2/.. To reproduce the mount device busy problem: # mkdir -p /mnt/lv1 # mount /dev/vg00/lv1 /mnt/lv1 # mkdir -p /mnt/lv1/lv2 # mount /dev/vg00/lv2 /mnt/lv1/lv2 # mkdir -p /lofs/lv1 # mount -F lofs /mnt/lv1 /lofs/lv1 # mount -F lofs /mnt/lv1/lv2 /lofs/lv1/lv2 -> device busy The changes invloved setting the VHELD flag in the lnode corresponding to the vnode VROOT flag in the 'makelonode' function. Having the flag set to VROOT instead of VHELD can cause a panic. Check for v_mountedhere and VHELD and returning EBUSY on lo_rmdir has been removed as this caused the device busy problem. This bug was introduced by PHKL_15959. SR: 5003435222 Reading processes were allowed to continuously hold an inode lock such that a writing process would not be able to run. This would continue as long as new reading processes came in before the old ones finished. This was fixed so that new reading processes were not given the inode lock until at one writer was allowed to proceed. Then all reading processes would be again given the lock but new ones which arrived would again have to wait for another writing process arrived. This would continue as long as there were still writing processes waiting. If there were no writing processes waiting reading processes are allowed to share the lock at any time. DTS: JAGaa08610 SR: ??? rwip was allowing readers to come in during the middle of a write. this was fixed so that a process which was doing a write would not release the lock and let reading processes share the lock. DTS: JAGaa21147 SR: 5003410423 Increment the read/write counters for vxfs in vx_bread(), vx_btranwrite(), vx_bcacheclear(), vx_blkinval(), vx_vnode_flush(), vx_reada_chain(), vx_flush_chain() and vx_fast_read(). SR: 5003423814 The problem was that because VxFS chains together buffers for paging, multiple I/O's for a page-out can finish at the same times on different processors. When the vx_pageio_done() routine is called, it doesn't hold the lock while it determines how many buffers are left on the chain. This can cause the final two threads to both think that they are not the last buffer in the chain and thus neither calls pageiodone() to tell the VM subsystem that the page-out is complete. This causes a process that needs to wait until the page-out is complete to hang, since the page-out will never appear to be done. To reproduce try setting up a striped LVM volume with disks from as many different I/O controllers as possible. Then create large files and do mmap() read them and close them. DTS: JAGaa13933 SR: 1653271163 Mark buffers invalid when the buffer can't be grown to fit the size of the request. DTS: JAGaa13609 SR: 1653269936 Change the constant that is used as the maximum size to VX_MAX_OFF which is greater than 2GB. PHKL_15478: in vx_vnode_flush and vx_inval_list routines, we traverse the dirty or clean buffers of the vnode through a single link list. While we traverse the chains, we hold the spinlock to avoid the chain being altered. But starting from 10.20 the files become large (>GB), so does the memory This leads to a long time spent in traversing and holding the lock. PHKL_13572: In vx_vnode_flush or vx_inval_list, there is a for-loop responsible for travesering the buf chains associated with a vnode. For a large file (>2GB), the buf chain gets pretty long and the traversing takes quite a while. Since we need to hold the vnode lock while going thought the chain, sometime we end up hold the lock for too long. This leads to the symptom descrived above. PHKL_7763: The VxFS file truncation code was breaking an assumption of the buffer cache causing delayed-write buffers to be discarded instead of being flushed to disk. This problem would be seen when using version 2 file-systems, but code changes in the allocation policies prevent the problem from occuring on version 3 file-systems. PHKL_16448: The s800 series exhibits an HPMC error under a combination of heavy traffic and ioscans using an HSC FDDI card. The root cause of this problem is a bug in the UPCIFIC 1 chip on the HSC FDDI. This chip interfaces PCI to the onboard DINO. Under heavy traffic, the UPCIFIC 1 would put an invalid address on the HSC bus, which would result in a bus timeout, causing an HPMC. The problem does not exist with the UPCIFIC Rev 2 chips in combination with the ESGSC+ bit set in the bridge feature register of the DINO. The s800 defect is listed under SR: 1653273540. This patch provides the cooresponding PCI interface enhancements to the s700 series. PHKL_16455: 1) lvsplit did not freez and sync file system before the split leaving the file system on split volume corrupt 2) Default boot info was not created if LIF LABEL is missing to boot into maintanance mode. 3) Kalloc would sleep holding the spin lock and panic. The fix is to release spin lock before calling kalloc. 4) Panic: "all VFS_MOUNTROOTs failed: NEED DRIVERS", due to LVM corruption on mirrored boot disk at boot time. The problem was hit in an internal testing on unsupported configuration, the fix is to add sanity checks and taking care of the disk failure conditions. PHKL_15598: The operating system normally accesses the real time clock via the Boot ROM (PDC code). The operating system is also designed to be able to use a driver to access the real time clock. The HIL clock is accessed via the HIL driver. However, the clock must be accessed prior to any driver loading. Since the drivers have not been loaded, the operating system attempts to access the HIL real time clock via PDC code. After the drivers are loaded, access to the real time clock is made via the HIL driver. PHKL_16387: SR: 4701399584 CR: JAGaa14952 The scsi_c720 driver incorrectly uses ULTRA speed as the default SDTR negotiated rate to the device. This causes some SCSI devices to hang as they can only really run at FAST speed. SR: 5003368860 CR: JAGaa05787 HPUX 10.20 has a 4K limit on the number of pages that the kernel will allocate via malloc. Panicing the system in this situation is undesirable. The fix is to bypass the call to malloc. This does not mean the request will succeed but, it will not panic the system. Only systems with very large amounts of physical memory are likely to have greater than 64MB of kernel memory available which is what "vgcreate -e 65535 -p 255" needs from the kernel allocatable space. SR: 5003428706 CR: JAGaa13736 The VM resource maps list spaces in best-fit policy. For shmem magic executables first a best-fit is tried in the 2nd quadrant and if no space was available there an attempt is made to find the best-fit in both quadrants 4 and 3. The problem with the implementation was that when the first request was being made to just try best-fit in quad2, the list was not being terminated properly. This list contains only one resource map pointer for quad2, so the list should have been terminated at offset 1. However, it was incorrectly terminated at offset 2. The same problem also exists for quad4 resouce map. SR: 1653250423 CR: JAGaa01479 The error code return from vx_dio_read1 should be checked against VX_ERETRY so that it will fall through the normal code path and do a normal I/O. SR: 4701393884 CR: JAGaa08709 The code put in to correct certain LOFS problems in PHKL_15620 can produce a data page fault when traversing through multiple device and lofs mount points. The fix here is to back out the changes in PHKL_15620. PHKL_15800: If an attempt is made to use direct I/O to read a buffer which starts at a sparse extent (VX_HOLE), and continues into the data area, the direct I/O byte count is incorrect, and the code will check for memory access rights to unrelated addresses. This triggers the EFAULT error where it should not. PHKL_15081: Systems with low memory while an application tries to read/write large chunks of data will panic. This is because VxFS for performance reasons tries to perform a direct I/O. In order to achieve this, the user stack has to be grown to the amount of data requested for read/write. In case vx_dio_iovec() is passed a negative space id (meaning there is no free page left), there is no check for a 0xffffffff (-1) space id. The fix was to perform a useracc() to find out if the process has permissions to write to the page or not. If it fails, then do not perform the direct I/O and instead perform a regular I/O. NOTE: ---- After the fix, running the same application on systems with low memory and davanced JFS to perform huge read/write "should" fail with the following message: "Pid xx received a SIGSEGV for stack growth failure. Possible causes: insufficient memory or swap space, or stack size exceeded maxssiz." -- Where xx is the process id of the application performing read/write system call. PHKL_12945: If the executable was marked for "large text page" (chatr +pi L) then the process would hang at exec() time if one (or more) of the conditions below is (are) met: - the executable text size is > 128KB, - the file system (where the executable resides) was mounted with mincache=direct or convosync=direct, - the executable was marked for VX_DIRECT operation by an application through an ioctl(). To reproduce: # cp /sbin/who /vxfs # Use who(1) as an example. # cd /vxfs # chatr +pi L ./who # ./who # Execute command, process is hung. You cannot kill this process, but you *can* kill the shell running it. PHKL_9415: 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_8735: 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_8388: 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_16207: requires PRM version 1.05 to use (release 12/98) PHKL_15958: SR: 1653263962 CR: JAGaa12500 lo_vget() implementation. enhancement to AUFS to allow overlay filesystems. umount fix for lofs. When a bus reset occurs to a tape device the device will rewind. The next write to the the device returns an error to the driver. The driver would retry the write and then silently continue, overwriting data, without warning the application that the error had occured. SR: 4701395822 CR: JAGaa12728 In setcontext() routine, the SS_WIDEREGS flag is not preserved properly. This results in values being stored in narrow fields of the mcontext structure where wide fields should be used. However, upon return to the user mode the registers are restored from the wide fields of the mcontext, causing an incorrect user context to be restored. PHKL_15942: The sync operation would immediately abort if it found that a PV is down. This way when two PVs are down and one comes up, it is never sync'd up since the other PV is down. This is easily reproduced by powerfailing two PVs and later powering up one of them. PHKL_15915: Failure to allocate page directory alias entries causes the application to receive SIGBUS. Any application that makes extensive use of alias pdir entries running on a fast system will use all the available alias pdir entries before the unhashdaemon wakes up. This daemon wakes up once per second and is responsible for allocating more of alias pdir entries are the are all consumed. The kenel uses alias pdir entries when it want to mmap the same offset twice. When the number of available entries falls below the thresholds (min_alias_entries and min_alias_pdirs) the unhashdaemon calls grow_aatables() to allocate more entries. The fix was to call grow_aatables() directly whenever the need arises instead of relying on the unhashdaemon to wakeup at the right time. PHKL_15787: LVM recovered PVLinks serially, so in situations where hundreds of links can fail simultaneously (eg. FibreChannel hubs) the time to switch all the links can be hours. The prior PHKL_15200 version of this code did not always properly detect active-passive (Nike and Galaxy) disk array paths. UFS files that have been unlinked do not have their associated buffers removed from the buffer cache. This causes the buffers to be reused with their old flags intact which could have the side effect of turning async writes into delayed writes. These delayed writes could then flood the device with I/O during a sync. PHKL_15766: SR 5003414540 With the release of Enhanced DFS 1.5.1(EFS) the kload driver has been removed from the kernel master driver file (/usr/conf/master.d/core-hpux). This was done because EFS no longer requires kload. For users who are still using a version of DFS prior to EFS, they will have to re-enable kload by removing "*replaced-by-efs" from /usr/conf/master.d/core-hpux and then rebuilding the kernel. Another option would be to upgrade to EFS. Example to re-enable kload in /usr/conf/master.d/core-hpux: from: *replaced-by-efs kload kload 14 100 -1 -1 to: kload kload 14 100 -1 -1 SR 4701394163 The defect was in the test done in mprotect. That test checks if the pregion submitted to mprotect has the appropriate type. Because of the defect, pregions that should not be "mprotected" (in our case a NULLDEREF pregion) may go through and get mprotected. PHKL_15742: 1. SR: 1653236869 DTS: JAGaa01996 The problem is that the rfs_readdir() routine in 10.20 calls VOP_READDIR2(); for vxfs, this merely calls generic_readdir2() which was the problem. The generic_readdir2() routine assumes that "real byte offsets" of returned directory entries and the offset of the corresponding entry in the actual directory are one and the same; for VxFS, this is not the case. The fix was to backport the VxFS-specific vx_readdir2(). 2. SR: 4701393074 DTS: JAGaa10827 While creating a new VxFS file, if attributes exist, they are passed from the parent directory to the new files. 3. SR: 5003295238 DTS: JAGaa09110 The problem is that we only do a VX_MPURGE(vp) if we had gotten an error earlier in the routine. The change (in 10.30 and onward) always does a VX_MPURGE(vp) if we're not currently mmap'ped regardless of whether we got an error. 4. SR: 4701393819 DTS: JAGaa11061 vx_vn_bread(), called by NFS via VOP_BREAD(), should not release the buffer to buffer cache without checking as it could have a private buffer if direct I/O is involved. This defect was introduced by PHKL_15619. PHKL_15619: SR: 4701393819 CR: JAGaa11061 The vx_vn_bread() function holds a buffer busy while it tries to get the lock on the buffer's inode. There is a window through which another thread can obtain the inode lock and then wait for the buffer that vx_vn_bread() is holding, thus causing a dead lock. SR: 4701349175 DTS: DSDe435102 Classic "thundering herd" problem was made worse by the fact that the first thing each woken process did was to try to lock a common spinlock. A process that gets the spinlock first, locks the inode and releases the spinlock has to try hard to be able to get the spinlock a second time while it tries to unlock the same inode. SR: 4701393884 CR: JAGaa08709 The lofs code allowed removal of its mount point. SR: 5003413278 DTS: DSDe442455 During VxFS filesystem mount, a filesystem structure is allocated and initialized. If the initialization fails (eg. bad superblock, missing mount device), the backout code in the mount routine does not unlock the filesystem structure and free it from the filesystem list properly. Any processes that walk the filesystem list will hang. This defect was introduced by PHKL_15244. SR: 5003421628 DTS: JAGaa10135 bcfeeding_frenzy() is called to free up virtual space in buffer cache resource maps. In systems with large buffer cache defined, it is called excessively to balance virtual memory allocation in two buffer cache maps. PHKL_14803 introduces some code that has side effects aggravating this problem. The fix is to reduce the calling of bcfeeding_frenzy() and to backout some changes made in PHKL_14803. SR: 1653259408 DTS: DSDe441605 Problem with the FibreChannel hubs PVLinks performance improvement code. May cause Nike and Galaxy disk arrays to switch repeatedly between primary and alternate links when a link is restored or when a transient error on the primary link occurs. Backing out the above code also removes the problem introduced in PHKL_15199 that causes MC/Service Guard cluster system with Nike array to panic. SR: 4701393058 CR: JAGaa10826 When a VxFS filesystem is full, no extent is allocated and there is no room in extent map for a new extent descriptor. In this case, the very first call to extent allocation fails to allocate an extent so the vx_extalloc structure remains uninitialized. A bug in the code assumes that an indirect address extent has been allocated and its descriptor must be added to the map. If the map has unused descriptor records, the existing descriptors are shifted to make room for a new one. We then add a bogus indirect address extent to the map. PHKL_15504: A system that uses DMAPI with extended information stored in inodes is unable to write extended information to existing files after a filesystem becomes full. An application like OmniStorage that uses DMAPI is unable to update existing inodes after the filesystem becomes full. This patch allows a DMAPI ENOSPACE event to be generated when the filesystem is nearly, but not completely, out of space. An application using large file support cannot use the KDM_IOC_WRITEINVIS DMAPI ioctl to do an invisible write. PHKL_15495: After removing a buffer from its hash chain, vx_bcacheclear must set b_which_hlock when it inserts buffer onto the new hash chain, otherwise we can get hash chain corruption. It showed up here as a spinlock deadlock as we started walking one hash chain, but it pointed to a buffer that was actually on another hash chain, so it will never hit our loop termination condition. PHKL_15492: Before lvlnboot will permit the configuration of a dump partition, it checks the addressing range of the interface card's IODC. If the maximum address of the IODC is less than the size of the dump partition plus its offset from the start of the disk, then lvlnboot denies the request and issues the above message to the user. The determination of an interface card's max IODC address is done by the function get_max_iodc_addr() in dump_conf.c The function returns MAXINT (2G) by default, but also uses a hard-coded table which lists the hversion and sversion of each card known to be 4G-capable. If the interface card in question is found in this table, the function returns MAXUINT (4G). Unfortunately, PCI cards do not contain h/sversion numbers therefore all requests to dump beyond 2G through these cards was denied, even though they are capable of it. This patch, augments get_max_iodc_addr() with a test, "isPCI," to determine of the interface card is a PCI device. If true, the routine returns MAXUINT(4G). PHKL_15456: SR 5003418244, DTS JAGaa07539: In 10.X, setitimer() does not check for the validity of user arguments properly. When an application uses setitimer(2) with a negative interrupt timer value, it causes the kernel timer expiration routine to spin in a loop while holding the timer callout_lock. If any other process tries to grab the callout_lock at this time, it will result a spinlock deadlock panic. The fix is to check the validity of the arguments and return an EINVAL for negative values. SR 4701391730, DTS DSDe438419: Under certain conditions, the system could violate internal lock-order rules while mmap(2)ing; the fix was to give up and reacquire the region lock to avoid this. SR 1653177089, DTS DSDe429996: In 10.xx buffer caching was disabled for block devices. This produced degraded performance in reads/writes to block devices; this patch reenables buffer caching for block devices that are not mounted as filesystems, and is a re-implementation of PHKL_13680. PHKL_15321: From Veritas Incident report, HP has reported the problem described below on a V3 filesystem. Basically, we will fail to reorg V3 filesystems when the orgtype of the original inode is IORG_TYPED and the reorg inode has to grow to indirect. In fshp releases an inode is not switched to typed extent when an extent is entered through vx_ext4_enter(). The lack of the switch requires allocating fixed size extents of size fs->fs_iaddrlen for indirect extents of a reorg inode. This is not the case in vx_reorg_emap() when the reorg inode is growing to indirect. PHKL_15244: - DTS: DSDe442455 SR: 5003413278 When multiple processes compete in mounting a snapshot filesystem using the same LV, a race condition in VxFS causes buffers of one of the snapshots to contain partially initialized data. Flushing these buffers results system panic. - DTS: JAGaa02119 SR: 5003407601 During reboot, the reboot processor is handling the reboot process, while all other processors are in idle spin. When the reboot process runs into a situation that it has to wait (e.g. biowait() for I/O completion) and gets switched out, the reboot processor at this time enters idle() and it should pick up the runnable threads from the other processors and complete the processing. The defect is that the reboot processor fails to schedule runnable threads belonging to the other processors. If the reboot's biowait() depends on the completion of other threads, the system hangs indefinitely. PHKL_15199: LVM recovered PVLinks serially so in situations where 100's of links can fail simultaneously (eg. FibreChannel hubs) the time to switch all the links can be hours. The PVSparing defect resulted because when a lock could not be obtained for a key data structure the sparing code assumed that no spares were available instead of retrying the operation at a later time. The UFS defect appeared to have been intruduced with PHKL_14804. Excessive rmprobe calls were being made even when the VM for buffers exceeded the buffer_low watermark. PHKL_15145: Dirty buffers are not flushed to mirrored disk on lvsplit. PHKL_15085: The graphics_exit hook was being called in the wrong place. It was called after all of the pregions were released in the exec path, so graphics DMA buffers were not properly cleaned up, and then graphics_exit could not find them when it was called. The problem can be reproduced by having a process do graphics DMA with VISUALIZE-FX hardware and then call exec without first forking. PHKL_15057: The current first fit policy for allocating virtual addresses for shared objects causes a form of fragmentation that is preventing some user's applciations from running. Since the algorithm is first-fit, small allocation requests can cause a large block of free virtual address range to be broken up into small ranges, thereby preventing bigger allocation requests from succeeding. PHKL_14955: Any kernel booted on PA-RISC 2.0 will not be debuggable, due to firmware changes in PCX-U. PHKL_14953: I/O requests passing through the LVM layer in the process of being sent to the disk hang when the PV-link is broken by pulling the FC cable. The I/O requests wait on the wait queue as the primary LVM link is broken and also the disk is not accessible. But the LVM code was incorrectly setting the disk as unaccessible even after the link-switch, so after the alternate link is restored, the disk is still not accessible to those I/O requests. PHKL_14917: All SCSI timeouts were set to 30 seconds. With this patch, we identify the MO drives and set a longer (5 mins) timeout for those drives. PHKL_14856: Race condition on shared interrupt bit caused the driver to mishandle setting up future I/O jobs. PHKL_14803: SR: 5003407601 DTS: JAGaa02119 The reboot process is stuck at biowait() while sync'ing disks because of a failure in acquiring LVM physical buffers. The lv_reschedule() routine needs to ensure a successful retry in this case because there is no other process to trigger the emptying of the physical buffer wait queue during reboot. SR: 5003407619 DTS: JAGaa01516 When buffer cache allocation reaches the defined maximum, the allocation of new buffers from system memory stops. When buffers are freed, their physical memory spaces, instead of being returned to the system, are saved in a pool to be reused for new buffers. A bug in the getnewbuf() routine disallows the reclaiming of this available memory when bufpages reaches the ceiling. Further more, another bug in the routine that frees up space for the buffer cache resource map erroneously releases more buffers than necessary. The prohibition of reusing the memory from the reserved pool and the lost of free buffers result running out of buffers in the freelist, causing all I/O processes hung in sleep wait. PHKL_14740: Device resets on FibreChannel devices can overlap and interfere with subsequent VG activation. PHKL_14685: The master file had to be changed to point to libhp-ux.a instead of libflkmgr.a. PHKL_14613: This system hang is hard to reproduce. Once in a while, during heavy load on UFS filesystems if a LV is being created or extended, the UFS code deadlocks due to ordering problems in acquiring the inode lock and the device vnode lock. PHKL_14568: - SR:1653254987 DTS:JAGaa01797 The problem is an MP race condition caused by a defect in the routine lv_tbl_reimage_realloc(). It is freeing the lv_bitmap before pausing the LV. This results in I/Os possibly reaching scheduling routines (such as lv_parallel()) while lv_tbl_reimage_realloc() is in the middle of freeing the lv_bitmap. The fix is to call lv_pause() before calling KFREE() on lv_bitmap. - SR:4701379347 DTS:DSDe441470 Add flock manager driver functionality to the kernel. - SR:1653216952 DTS:DSDe437110 The data path in the kernel code that supports sleep(3C) is not wide enough to support parameter values larger than 21474836 seconds. If a larger value is passed, incorrect arithmetic is performed, with results varying from immediate return (with or without error) to sleeping for the wrong length of time. PHKL_14490: -SR: 4701382564, DTS: DSDe441726 If the free kernel sysmap space, as a percentage of 1GB, falls below the threshold value indicated by the variable kern_vm_pct, now a warning message is printed to indicate this. The variable kern_vm_scan_rate, in seconds, is used to set the frequency this check is performed. The variables kern_vm_pct and kern_vm_scan_rate are tunables that can be set in the /stand/system file. Reproduce: Run an application that uses up lot of kernel sysmap space, or run a defective kernel module that uses up kernel sysmap space continuously without releasing the allocated space. -SR: 1653251934 DTS: JAGaa01592 A uniprocessor system hangs when heavy I/O is performed. When the buffer cache virtual space is heavily fragmented and we are doing a readahead, system hangs. The allocbuf1() won't do a bcfeeding_frenzy() to de-frag because readahead sets BX_NONBLOCK|BX_NOBUFWAIT flags. Instead it returns an error to ogetblk(). A bug there keeps us looping instead of returning to the original caller. To reproduce: On a UP K-series system with 64Mb, create a 400 Mb VxFS filesystem mounted at /new_fs. Make sure that /usr is also of type VxFS type. The following code will produce the hang. while true do rm -rf /new_fs/* cp -r /usr/* /new_fs done & while true do date sleep 10 done & The system will hang in about 15 minutes. - SR: 1653252544 DTS: DSDe441877 In the routine csuperpage_lock() if an attempt to acquire pfdat lock on every pfd in the superpage of which the input page frame number is a part of fails, then in some cases the lock on the original input page frame number will not be released thereby resulting in any process that subsequently tries accquiring the same pfdat lock on the same page frame to hang. Reproduction: difficult to reproduce the failure case. Requires execution of large number of user applications that subject the system to a high stress load. PHKL_14323: mkboot -p uses the block device. Because block devices use the buffer cache, the label may be overwritten with incorrect label information once the buffer cache is sync'ed. The solution involved removing use of buffer cache by block devices until a mkboot patch is available. PHKL_14321: -SR: 1653235176, DTS: JAGaa01482 Both the problems (panics) discussed earlier occur in an MP system when two processes are doing map/munmap on portions of the same file using a sliding window. Panic-1 -------- The panic is caused by a race condition in hdl_mmf_attach(). The race condition is in case-3 of "overlapping" pregions. In this case, the new process' pregion starts within and extends past the existing process pregion. In the original implementation,we were releasing the region lock to call mapvnode(). At that time, the new pregion is not yet placed on the region's pregion-list and hence opens a window for a race condition. With the fix, the pregion is placed on the region's pregion-list before releasing the region lock, thereby eliminating the race condition. Panic-2 -------- The second panic is caused by a race condition in the error path of smmap(). In a code segment following the label "bad", in the case where vnode is associated with the region, we release the region lock to be able to call dectext(), we copy the file descriptor from the vas, acquire the file-table lock and then check that the file descriptor is not zero before proceeding further. In the meantime, the file descriptor could have been closed and hence dereferencing it would cause a data page fault. To avoid this race condition, we need to postpone calling dectext(), which is what the fix does. -SR #4701383612 maps to DTS #DSDe441827 The problem is due to the space register not being set before jumping to the code that handles ulbcopies to I/O space. The fix is to move one line of assembler up above the check to see if this is a ulbcopy to I/O space. PHKL_14225: When disallowing user write permission for copy-on-write, an execution permission is added to every translation. For pages which do not have execution right before, this misses the R/W to execute promotion through fault and the proper cache flushing. PHKL_14183: New functionality to support networking features in 10.20. PHKL_14126: This patch fixes two defects : - SR: 4701381608, DTS: DSDe441567 Patch PHKL_13684 introduced a problem with procedure vn_open(). By adding one extra argument to this procedure, compatibility with older users of vn_open (now believed to be limited to Netware) was broken. Because of this extra argument it is possible that the vnode returned by this procedure can be a random memory location. This patch backs out the addition of the extra argument and it restores compatibility. - SR: 1653223404, DTS: DSDe438306 Trap panic in lv_init_immediate_reporting because currentPhysicalLink field in the struct pvol associated with the PV which the vgcfgrestore had been performed on was NULL. The problem will only be seen on 10.20 with patch PHKL_8999 or superseding patches as this patch introduced this new pointer field to the struct pvol. The panic problem will only be seen on multi-PV VGs. PHKL_14049: This patch fixes three defects: 1) SR: 1653247486, DTS: JAGaa01357 After a maintenance mode reboot, if the root LV is mirrored, we make the copy of root on the boot device the only fresh copy. Before updating the VGSA with the new stale/fresh information, a structure used to pass PE information to the configuration is set up. In the case of a LV containing 2**n extents, memory allocated for the array of structures is exactly enough for the extents. The terminator of the array was written beyond the allocated memory. This corrupts the memory at the next address and causes system to panic when the next piece of memory is accessed. 2) SR: 1653239137, DTS: JAGaa01378 When the root VG has a mirror PV missing with a lower PV index number than the boot disk, the PV's current physical link field is zero. The code attempts to dereference this NULL pointer in the bootup path and traps. 3) SR: 1653248690, DTS: JAGaa01378 The problem is caused by a disc with bad blocks in the LVM structure area. This results the LV field in the physical request buffer to be zero. Deferencing this NULL pointer causes data page fault. PHKL_14012: This is an enhancement to add the flock manager driver hooks to the kernel. PHKL_14009: pstat_lvinfo() algorithm describes that if the number of entries requested is non-zero, it will traverse through all the VGs to report the open LV 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 LVs. Also there can be some LVs that are configured but not mounted, as the VG where they reside is still ACTIVE. The fix now shows the all the LVs that are open in the system within any VG. The defect can be reproduced by writing a program based on pstat_getlvinfo() to display information about LVs configured on a system. The output of this program only shows LVs for the first VG. PHKL_13986: In K & D class computers the kernel will panic when an HP-PB external card cage is powered on and attached to the HP-HSC to HP-PB converter. This is caused by the unpatched code erroneously applying all type-B DMA devices to the first IOA instead of treating each IOA as a separate device. PHKL_13911: In getnewbuf, we might set a B_DELWRI buffer to B_BUSY, but later decide to NOT write it out (in fixing some deadlock problem). Rather, we will simply brelse it. If an umount process of the device or filesystem comes in between the time of setting B_BUSY and brelse(), it will skip the buffer thinking that someone else is flushing it out. Later when it calls binval() assuming all buffers should have been written out, it may invalidate a dirty buffer. PHKL_13874: There were two defects fixed by this patch: a) Report of "Invalid Argument": The problem occurs when reorganizing a version 2 VxFS with EXT4 type of extents from an original indirect extent to a reorg'ed indirect extent. In this case, vx_reorg_emap() does not allocate a fixed size extent for the reorg'ed inode's indirect data extent. The incorrect size causes vx_enter_ext4() fail to enter the allocated extent to the extent map, resulting an EINVAL error. b) Report of "No such device or address" This was caused also by incorrectly handling the indirect extent of an IORG_EXT4 type of file (alson created under version 2). In this case vx_reorg_copy() would blindly attempt to copy pad bytes if the indirect extent of the original file was not completely filled. (Pad bytes are used in the last indirect extent if the data does not fit exactly)(This is a consequence of having a fixed size for all indirect extents of the IORG_EXT4 type of file). PHKL_13868: Incorrect values were being written to port I/O registers. PHKL_13795: New functionality to support networking features. PHKL_13768: On PA8000 systems, when free physical memory becomes heavily fragmented, the time needed to find free large pages (superpages) increases drastically. During this time (possibly several seconds) the kernel would preempt any user or system processes. This could result in MC/Service Guard TOC'ing the system. The fix was to yield the cpu when spending too much time in alloc_large_page(). PHKL_13761: Use of a global mprot_list_lock lock caused spinlock contention as it was one lock per system and hence poor system performance. It is still used to protect mprot_list. The fix was to use another pool of locks called prp_hash_locks for protection ids. The hashing function chooses different locks (from this pool of hash locks) for different range of addresses thus removing dependency on the various locks that should be acquired before the protection ids for a given page are changed. PHKL_13744: When an error occurs early in the open process the routine st_dev_sense can get called without any valid sense data. The sense pointer is NULL, and is passed to st_head_pos which tries to dereference the pointer. PHKL_13713: The defect was due to an uninitialized field (ex_elen) in the vx_extent structure when allocated by the vx_dqnewid procedure. PHKL_13684: The system supplies a "default" ACL even if none has been configured. This in turn overrides any umask, and produces unexpected file access behaviors. PHKL_13680: In 10.xx buffer caching was disabled for block devices. This produced degraded performance in reads/writes to block devices. PHKL_13514: This defect is due to an error in the Dino CDIO regarding the reservation and assignment of interrupt resources. PHKL_13508: vx_statvfs doesn't count extents smaller than 8k for f_bavail. PHKL_13452: When changing multiple attributes on a file, VxFS creates a "ghost" inode, or working copy to make changes. When the changes are complete the ghost inode is swapped into the real inode, thus making the changes visible in the filesystem. Some parts of the "ghost" inode may not be set by the time other parts of VxFS try to use them. These uninitialized parts of the "ghost" inode cause a data page fault and panic when they are referenced before they are initialized. When only one attribute is changed, no "ghost" inode is created. Changes are made directly to the inode involved. PHKL_13305: The defect is that the scheduling algorithm in idle() was preventing the reboot processor from picking up the thread that needed to complete processing because that thread was locked to another processor. PHKL_13260: This patch fixes three problems: a) SR: 1653237842, DTS: JAGaa01160 Poor performance on PA2.0 machines due to protection id (PID) faults that are resolved in software instead of hardware. The system resolves half of the PID faults in software and half in hardware. The fix was to use the hardware support from PA2.0 chip so that we will resolve a greater number of PID software. PA2.0 systems have four 64-bit PID registers instead of four 32-bit registers. By software convention, the lower 32-bits of CR8 and CR9 are used for text and data PIDs. This way we never have to resolve PID faults for text and data segments via software. The higher order 32-bits of CR8 and CR9 are used to cache PIDs. In addition to that we have another four registers (two 32-bit register pairs) for caching PIDs: CR12 and CR13. This yields six control registers to cache PIDs instead of two. This results in a performance boost and a lower number of PID faults to be handled by software. Here's a pictorial explanation of the difference in PA1.1 and PA2.0. PA1.1: Protection id cache registers = 2 (32-bit) 0 31 -------------------- | TEXT |- CR8 -------------------- | DATA |- CR9 -------------------- | pid3 |- CR12 -------------------- | pid4 |- CR13 -------------------- PA2.0: Protection id cache registers = 6 (32-bit) 0 31 63 ---------------------------------------- | TEXT | pid2 |-CR8 ---------------------------------------- | DATA | pid4 |-CR9 ---------------------------------------- | pid5 | pid6 |-CR12 ---------------------------------------- | pid7 | pid8 |-CR13 ---------------------------------------- Hence, the code was using only pid5 and pid7 for caching PIDs whereas pid2, pid4, pid6 and pid8 were not used. b) SR: 1653237842, DTS: JAGaa01160 The other defect which leads to silent data corruption was due to PHKL_13624 which "incorrectly" used the stack pointer to get the space id to access the fast protection id list. This is true for all the applications "except" for SHMEM_MAGIC applications who define their own stack on the shared memory segment. The fix for PA1.1 and PA2.0 systems (for PHKL_12634) was to find out which key to use for accessing the fast protection id list. Non SHMEM_MAGIC applications will always have a non-zero value in sr5 and this value cannot be equal to the value in q2_spaceid. The reason that non SHMEM_MAGIC applications will always have a non-zero sr5 is that they attach a stack region in the second quadrant before they begin execution. So we now have a simple test that can be used by fast_resolvepid: if (sr5 == 0 || sr5 == q2_spaceid) { /* Application is SHMEM_MAGIC, compare sid to sr4 */ } else { /*Applications is non SHMEM_MAGIC, compare sid to sr5 */ } q2_spaceid is covered by the kernel mapping so we know it is mapped equivalently. q2_spaceid is a global which is initialised at boot time and holds the space id that SHMEM_MAGIC applications share for the second quadrant (controlled by sr5).This global will be zero until the first SHMEM_MAGIC application attaches something in the second quadrant, but that doesn't matter. Anyway, all SHMEM_MAGIC applications will have sr5 set to either 0 or the value in q2_spaceid. It will be zero if the application hasn't gotten around to attaching any shared memory in the second quadrant, otherwise sr5 will contain the value in q2_spaceid. This fix will work for PA1.1 and PA2.0 systems. c) SR: 4701373969, DTS: DSDe440766 The driver for VISUALIZE-FX hardware uses PIDs to arbitrate access to the hardware. Flow control for the graphics pipeline is controlled by revoking the graphics PID under interrupt. Some routines that manipulate PIDs in the kernel were not protected from this interrupt, so they could wind up restoring the graphics PID from a temporary variable after it was revoked, leading to either the graphics pipeline being overflowed, or two graphics processes simultaneously accessing the hardware. PHKL_13247: DDTS #JAGaa00964: When "vgchange -a s" is invoked to PV-LINK VG of Nikes which mix of GSC and HP-PB interfaces on shared bus on both nodes at the same time, vgchange fails, leaving the following error; vgchange: Couldn't activate volume group "vg02": I/O error while reading the VGDA. To reproduce, set up two systems with a Nuke disk array on a shared bus, DLM software, and start up the cluster. Then use some mechanism to invoke the vgchange -a s command simultaneously on both nodes. This could be done using synchronized clocks and timed jobs. After some time the command will fail on one of the nodes. DSDe441112 : The configuration is two T600's, shared EMC disk arrays on FibreChannel, ServiceGuard 10.10, in a new installation. They are testing ServiceGuard by introducing various faults. Most work ok, and ServiceGuard responds as designed. Certain manipulations are done on one node, and the other node panics. Manipulations leading to the panic include: 1. Powering off the node. 2. Disconnecting BOTH FibreChannel cables. 3. Powering off an expansion bay. PHKL_13237: serialize() is checking if the "pid" argument passed to the system call from the user application is less than PID_MAXSYS. If so, the call fails with errno set to EINVAL. PHKL_13206: getdirentries() and getdents() system calls do not check if the argument is a directory file. When it is called on VxFS filesystems with a regular file, VxFS reports an error such as "vxfs: mesg 008:..." and the clean file can be marked bad. VNODE type check codes have been added in getdirentries() and getdents(). PHKL_13155: The scheduler decides the system is thrashing in some occasions when pageout rate is low and free memory is plenty and hence deactivates certain processes. PHKL_13014: - scsi_wakeup missing; required by ISDN driver - scsi_iodone calls bp->b_iodone directly when B_CALL is set rather than calling biodone and letting it call bp->b_iodone - disk driver uses its own global variable, sd_ki, instead of the system defined global variable, km_disable, for disabling kernel metrics; and it examines sd_ki only on first open - incorrect initialization of NCR 53C700 SCSI chip for systems with sclk <= 37.5 MHz. 705/35, 715/33, 715/75, 725/75, 730/66, 735/99, 735/125/B, 750/66, 755/99, and 755/125 - SCSI bus reset while bus closed results in incorrect "Unandled pending interrupt" declaration and second bus reset. - scsi_tape driver rejects odd-length write requests on wide SCSI busses - scsi_c720 driver reports incorrect number of bytes transferred when IWR is used PHKL_12997: The HSC F/W SCSI card was not being identified as an interface capable of addressing in the 2GB->4GB range. To reproduce, simply attach a >2GB disk to an HSC F/W SCSI interface and put a >2GB filesystem on the device. Leave enough room at the end of the disk for dump space and attempt to configure dump on the device to start between 2GB-4GB. PHKL_12963: No real defect for first problem. A CPU intensive process would/could consume more CPU cycles than the entitlement granted to a group under PRM control. Second problem could occur on an SMP machine, if mulitple processors go after a single process simultaneously. In some situations, a hang can occur. PRM would need to be running on the system, and processes would have to be locked to processor through process affinity. In this situation, a processor can be fooled into thinking a process is available to run, when none is, and the result of this can be a hung system. PHKL_12901: The defect is due to allocation of large data structures local variables) on stack when a function is called. The fix was to re-compile the object modules (LVM,VxFS) with a compiler option (+ESssf - small stack frame) to align the stack pointer to 32-byte boundary instead of 64-byte boundary. This prevents the kernel stack overflow panic. PHKL_12669: 1. When a PV which has bad block alternates allocated and is being added/extended to a VG without doing a pvcreate -f, if the bad block alternate resides inside the user data area, this could cause data corruption. 2. The problem has to do with how the LVM interprets the B_PFTIMEOUT flag. For mirrored reads, the LVM works as desired: if the first disk is bad, the LVM tries the second disk. If the second disk is also bad, then the LVM reports a disk error. In the case of PV links however, the LVM reports a disk error immediately without trying the alternate link. 3. The new LV flag (LVM_NONCONTIGUOUS) is defined for a new allocation policy being implemented in a LVM command patch. PHKL_12662: A thread owns a resourse needed by the reboot process, yet is stuck on a frozen spu, causing a deadlock. PHKL_12660: Disk driver, sdisk, proceeds with partial open rather than failing the open in response to SCTL_INCOMPLETE on TUR or Read Capacity during first open. PHKL_12633: Problem was due to an incorrect assumption in determining the SID to be used. Procedures fast_resolvepid and fast_resolvepid2_0 incorrectly assumed the SID would reside in SR5. This has now been corrected providing better performance of SHMEM_MAGIC executables. PHKL_12601: ftruncate() returns EAGAIN on mandatory locking regardless of lock owner. If we have mandatory locking on a VxFS file and if there is a pending lock, then we return EAGAIN regardless of the owner of the lock. vx_setattr() does not allow a file to be truncated if there is mandatory file lock owned by another process, even if it does not overlap the range being truncated. PHKL_12409: alarm() rounds the time remaining to the nearest second so if the time remaining is less than 0.5 seconds, the result is rounded to zero. This makes it impossible to reschedule the original alarm. There was no check made in alarm() to determine if the result has been rounded to zero. The fix is to have a check to ensure that we never return zero if there was any time remaining. PHKL_12397: This patch fixes two defects : -When debugging processes over an interruptable NFS mount point there is a window during which a traced process could sleep in exec() while the debugger would exit clearing the traced bit and freeing the ptrace data structure. Upon wakeup, the no longer traced process would panic the system trying to dereference a NULL pointer. -pstat_msginfo() calls msgconv() to convert the offset into a message queue pointer. msgconv() then locks the queue and returns a pointer to the queue's lock. pstat_msginfo() had not been released the lock of the message queue. PHKL_12378: Filenames longer than 14 characters are not put in the path name lookup cache. Applications using very long filenames and pathnames will not find their filenames/patchnames cached. This results in a lot of filesystem block read. When many processes simultaneously scan many directories then path name lookup cache and buffer cache spinlock contention will show up. The solution was to increase the maximum filename length that can be cached from 14 to 39 and extend the the spinlock pool. In the test configuration using Netscape the message accept rate increased from 4.5 to 9.2 messages/second and message delivery rate increased from 3.8 to 5.0 messages/second. PHKL_12306: bp->b_resid updated after km_io_done. Select timeout not being retried during sd_open. Unhandled interrupt on 53C895 in single-ended and/or high voltage differential mode. scsi_update_tag_state not always getting called to restart device after Queue Full. PHKL_12217: lseek() is not allowed to specify negative offsets. NFS servers use so-called cookies which might have negative values. PHKL_12110: System hangs or panics when signal is received which has action set to ignore when in nanosleep system call. Libc patch that changed sleep()'s underlying system call to nanosleep() makes situation worse. PHKL_12100: fsck was not able to handle IAU data spread across multiple extents. The kernel, on the other hand, seems capabable of multiple extents for IAU. fsck was fixed to agree with kernel with respect to IAU. PHKL_12088: If a customer installed the HP-UX OmniStorage product, the product would not be functional. The DMAPI extensions available with the OnlineJFS product (currently only being utilized by OmniStorage and not linked into the kernel by default), had several severe bugs that were fixed in the 10.30 release. This patch backports the DMAPI functionality from 10.30 into 10.20. PHKL_12073: The problem was caused by improperly handling the SIGPOLL signal. The si_code number of the siginfo_t structure contained CLD_DUMPED and a core file produced. si_code should have contained CLD_KILLED. PHKL_12042: The scheduling policies available prior to this patch did not have a provision for a fixed-priority timeshare (non-realtime) process, one which could use many system resources without being degraded to a very low priority. This patch provides this "no aging" timeshare facility for applications which need it. This facility uses the same interface which is in 11.00, through the POSIX interface routines: applications which need to use this facility should use the sched_setscheduler(2) system call with a new policy of 8 (to be defined in 11.00 as SCHED_NOAGE). Idle processors were stealing processes from other run queues, even when those processes were running frequently already. PHKL_11902: Missing argument inside of diagnostic printf(). PHKL_11860: It is assumed that there is one active reference to a disk quota at vx_quotaoff(), which enables to free vx_dquota blocks in vx_dqlist. This assumption is not true during vx_replay() since there is still a VX_MLDQUOT mlink in the filesystem mlink chain waiting to be flushed. Hence, flushing the filesystem's mlink queue before calling vx_quotaoff will fix the problem. PHKL_11766: 1. When an alternate link is added to a VG, LVM counts this link as an individual disk. This mistake will cause vgextend to fail when user wants to add an additional disk to a VG when the total number of disks and its alternate links reach the maximum allowed. 2. LVM panic the system when running one of the stress test. trap panic in lv_resyncpv due to failure return from lv_lvhold call. PHKL_11733: After a hard system failure, a VxFS filesystem may not mount even if PHKL_9371 and PHCO_11223 are installed. If the VX_IETRUNC flag is set for a file, then vx_trunc() is called and returns without clearing the ip->i_eopflags field. Since VX_IETRUNC alone is still set after vx_trunc(), the error return is set to EINVAL (reason why the mount fails). Prior to returning, if error is non-zero, vxfs sets the VX_FULLFSCK flag and returns. Patch PHKL_9371 added the setting of the VX_FULLFSCK flag; the bug leaving the ip->i_eopflags set to VX_IETRUNC still existed prior to PHKL_9371, however after the first failed mount, a second mount would have been successful. PHKL_11730: Conditions needed to be re-checked after acquiring lock. Functions changed: bflush1, bflush_vfs, binval, blkflush, bpurge, ogetblk and syncip_flush_cache PHKL_11696: Backout code in dupvas() does not free the vas. One line accidentally deleted in 10.20 checkin of multithreaded vas locking. Seen in 10.30 testing but never reported on customer installations. PHKL_11637: Mount a UFS filesystem from the CDROM drive then reboot the system without unmounting the filesystem. When the system comes up, the CDROM draw will remain locked. PHKL_11632: Driver was not enabling LASI SCSI burst-mode transfers. Driver was using uninitialized variables to initialize chip registers on first open. DLT library robotics do not do synchronous transfers which exposed the bug. PHKL_11614: Defect occurs when the accounting file is physically on the server and not on the local filesystem. The function _acct() was setting the process credentials before doing a vnode operation (vn_rdwr()), instead of setting the thread's credentials. The vnode operation that was performed on a file was instead using thread's credentials. Because of this users other than ROOT were unable to update the accounting file and there was no information regarding commands executed by user in /var/adm/pacct (accounting) file. PHKL_11607: The filesystem that was being mounted had previously been under a reorg operation. The panic occurred during replay on the structural fileset where an inode with the org type of IORG_TYPED was being truncated. The truncate operation produced a transaction with over VX_MAXTRAN subfunctions. vx_trunc_typed() is called to truncate the file to size 0. This function makes an accounting error in its loop that frees extents. For each iteration of the loop vxfs only accounts for one subfunction to add to the transaction while more than one subfunction can be added. PHKL_11561: When a node dies in an HA cluster environment, there may be I/O requests still pending on its intelligent disk I/O boards (eg. Wizard). The I/O boards may continue to write this stale data to disks. This process is known as "Ghost I/O". This situation may lead to data corruption when the other nodes in the HA cluster detect the failure, apply recovery logic, and perform I/O to the disks. There is a need for detecting the death of a node and reseting the bus. This feature only impacts Service Guard/Distributed Lock Manager environments. PHKL_11545: - The tape driver will occasionally panic on the open of a tape device which is attached to the HSC bus. The panic is caused when a tape device responds with a "check condition" very early in the open process. The problem is intermittent and can not be reliably reproduced. - Patches PHKL_10417 through PHKL_10422 changed the way the driver negotiated with the device for narrow (8 bit) or wide (16 bit) transfers. This fixed a problem with 7980S tape drives, but caused the driver to never correctly negotiate for wide transfers. Any wide device on a wide interface would suffer a performance degradation because the driver was throttling it down to 8 bit transfers instead of 16 bit transfers. - Because of problems with transferring an odd number of bytes over a wide bus, the driver prevents doing an odd sized write to a wide device. The DLT4000 is a narrow device, but it is differential so it attaches to a wide bus. The driver was looking at the bus size, rather than the device type, to determine the transfer size and so it was blocking odd-sized transfers to DLT4000 devices even though these should be allowed. Writing an odd-sized record to a DLT4000 would return an EIO error. PHKL_11519: During vnode read operation, if the request is from NFS, the request size is checked against the VX_MAXBSIZE and an EINVAL is returned if the request size is greater than or equal to VX_MAXBSIZE. The EINVAL is always returned because the request size is set to VX_MAXBSIZE (8K) for NFS by the calling routine. When PHKL_11322 fixes this problem, the code proceeds to read the data block and returns the buffer back to NFS. This exposes a bug in which if the data we need starts at a non-zero offset within the buffer and the caller receives the whole buffer assuming the good data starts at the beginning, invalid data is loaded and command coredumps. PHKL_11471: The quota command uses quotactl(Q_SYNC, NULL, 0, NULL) to update the quota usage file on all quota active file systems. For each VxFS filesystem, the quota sync operation flushes all transactions and writes quota information to the disk file synchronously. On a system with heavy I/O, this results in a long delay. The fix is to flush the transaction log only and use asynchronous I/O for disk file update. PHKL_11408: One of the kernel macros used for locking pfdats was using the &htbl[] hash list of locks instead of the &htbl2_0[] hash list of locks, causing it think it had locked a pfdat when it hadn't. PHKL_11406: During the final stages of EXEC, the kernel has to relocate the argv and envp pointers to point to the argument and environment strings which reside in the user stack. There was a defect in this reloction code that caused all pointers pointing to locations in the user's stack at offsets of 20K from the base to have bad addresses. PHKL_11358: Problem was due to calling vx_rename (the rename filesystem specific procedure) for a UFS vnode. This was done because the parent vnode was of VxFS type and it was used to determine the operation type (VxFS or UFS). The problem should have been detected and avoided at the vfs layer. PHKL_11351: The GSC I/O Adapter was not designed to support one of the GSC control lines used by the GSCtoPCI interface chip. The GSCtoPCI services now avoids using this control line. Shared IRQ panics are due to a subtle bug in the way interrupt service routine lists are managed. (DSDe437012) Shortened code paths in PCI services. All HP-UX PCI drivers will benefit from this. (DSDe438658) Added support for an additional return value from PCI services (to FDDI driver). PHKL_11339: CPU limit was not being inherited by the child from the parent and hence if cpulimit is set, child ignores it. Also SIGXCPU is not delivered solely depending on the sigmask, but is triggered by arming the timer. When a child is forked, kt->sigmask is copied from parent to the child but if there is a non infinite cpu limit set in the parent, not only does that field needs to be copied to the child process, the timer for the cpulimit must also be armed for the child. PHKL_11332: (4701356766/ DSDe437007; 4701353888/ DSDe436271) I/O stress tests panic on some of the internal T600 test machines. PHKL_11321: 1) In vx_read1(), some unnecessary conditions prevented vx_read_ahead() from being called for large reads. The fix is to remove these extra checkings to allow read_ahead to be performed. 2) When we are done with a shared library, pageout routine is called to flush the changes to disk. The way vx_pageout() works is that it invalidates the cached copy of the file then calls vx_do_pageout() to figure out the MMF pages need to be written and write them. A more efficient way of doing this is to invalidate and flush buffers in the buffer cache only if there are and may have been dirty pages. 3) When reading a sparse portion of a file on VxFS, vx_read1() calls uiomove() to copy a page of zeroes to the target buffer. If the UIOSEG_PAGEIN flag is set in the uio structure, uiomove() by default will copy vx_zeropage from the buffer cache. Since vx_zeropage is not in the buffer cache's space, but is in space 0, this references an invalid address and triggers a panic. The fix is to replace uiomove() with long_uiomove() which allows the correct space id to be specified. PHKL_11316: Classic "thundering herd" problem was made worse by the fact that the first thing each woken process did was to try to lock a "COMMON" spinlock. A process that gets the spinlock first, locks the INODE and releases the spinlock has to try hard to be able to get the spinlock second time while it tries to unlock the same inode. Hence the inode was locked whilst no useful work was being done. PHKL_11247: An uninitialized variable, depending on what value it picks up from the stack, causes the quota checking routine to return EDQUOT erroneously during extent allocation. PHKL_11244: mmap() to a file with holes does not work correctly if MAP_PRIVATE is used. PHKL_11238: Random S800 MP system panics when running the latest Informix because of a corner-case MP hole in nanosleep which is seen when nanosleep() is called from within a signal handler. PHKL_11164: The variable page size memory allocator was preallocating kernel virtual space aligned on the largest possible superpage size instead of the largest available. The excess was then freed, causing gaps (fragmentation) in the sysmap. The fix was to allocate kernel virtual space only after the determination of the largest available superpage size. This problem would only be seen on PA8000 systems. PHKL_11085: On very rare occasions EMC Symmetrix disk drives will report a disk error which causes LVM to mark the block as bad in its bad block directory. The Symmetrix drive can be "repaired" online by EMC support, but the entry in the LVM bad block directory will prevent any further I/O to the affected block. This patch enables a new relocation policy which will prevent entries from being added to the bad block directory. In order to make use of this new relocation policy, a commands patch, PHCO_10826 must also be installed. Also, algorithms within LVM that deal with PVLinks had built in the assumption that NIKE serial numbers were unique. This turned out to not be the case. The only time that the serial numbers need to be unique is in OPS clusters. This patch removes this restriction for all non-OPS cluster environments. PHKL_11055: Large memory MP systems could hang if the processors were mallocing kernel dynamic data at the same time. The contention on the pfdat_lock spinlock would caused excessive CPU time being burned spinning. This problem would only be seen on PA8000 (PA2.0) systems. PHKL_11039: There was a defect in the routine checking the validity of extent buffers. This defect would cause inodes to be marked wrongly as BAD, when they were perfectly valid. This also fixes a defect that was found while fixing this problem. The bug is in the routine that splits the extent. It assumes that the allocated extent is same as it had requested, which is not always the case. The defect was that it copied half the entries from extent being split to the new extent, and it may be that not all the entries will fix, if it allocated less than requested. PHKL_11013: During vxupgrade, it is possible for the allocation unit length to change; thus the same inode located in the same block will change allocation unit numbers. There was a check in vx_iremount() to verify that the allocation unit numbers matched, and returned ENOSPC if not. This was the root cause of the problem which was easily reproducible: o Create a version 2 VxFS file system on a 1GB VG: mkfs -Fvxfs -oversion=2 /dev/vg01/onegigvol o mount it: mount -Fvxfs /dev/vg01/onegigvol /tmp_mnt o fill up the file system halfway: prealloc /tmp_mnt/bigfile 500000000 o copy some files into the filesystem: cp -r /usr /tmp_mnt & o wait a few minutes and execute the vxupgrade command: vxupgrade -n 3 /tmp_mnt PHKL_11006: A defect in the implementation of timer reload causes the 1 tick (10ms) interval be rounded to 2 ticks (20ms). PHKL_11002: (4701353888/ DSDe436271) This patch is needed for 10.20 HP-UX bring up on T600 systems. PHKL_10966: The exclusion zones were not being properly merged for some orders of sets if they wound up being adjacent. When attempting to clear the exclusion zones, the clearing code did not bother to look at the next zone on the list to see if it was an exact match since adjacent zones should have been merged. PHKL_10953: The bc_yield() buffer cache routine was calling swtch() without first releasing the file-system alpha semaphore. This defect would impact mainly systems using a large buffer cache. PHKL_10932: (4701353078/DSDe436182) uiomove accesses memory via load-byte operations to improve performance on PA-8000 systems. Load-byte is not a valid operation for I/O address space, though most I/O cards handle it without problems. Some Emerald-class (890, T5x0, T600) memory controllers do not. We now use load-word for I/O space. PHKL_10930: The hang is due to the system taking a floating point exception as the result of a PDC defect. PHKL_10821: An earlier patch, (10177, shown without prefix so as not to confuse search engines) expanded the actual space available to execve(), but failed to modify sysconfig() to report the new maximum. This patch corrects that. There is no change to module kern_exec.c (home of execve()) other than a revision roll to ensure its inclusion in this patch. PHKL_10800: Current system does not keep track of chdir() calls which alter the current working directory. There is no in kernel ASCII record of the current path just the vnode/inode which can not be easily converted to the ASCII pathname. PHKL_10769: Certain revisions of the PCI bus ASIC can cause an HPMC due to a incorrectly decoded memory address. Only one 4K page of memory per 256Megabytes of real memory are affected. The fix involves mapping the page(s) out so that they are unavailable to the system. PHKL_10757: This patch provides additional enhancements to support new HP workstations (See "Symptoms" section for more details). It also contains two bug fixes. One fix is for the MP PDIR bug. On MP systems the system could crash due to a race condition where one processor would attempt to read a translation that was being modified by another processor. The other fix was for a panic that was introduced by a previous patch which expanded the argv/envp buffer from 20480 bytes to 2048000 bytes. pstat_cmd() could get a data segmentation violation due to a defect which would keep looking for a null termination beyond one of the internal buffers, possibly referencing an illegal memory address. PHKL_10756: Support for GSCtoPCI PCI Bus Bridge in "card mode". PHKL_10755: The new B180 and C200 workstations include PCI Ultra SCSI devices. The SCSI subsystem has been enhanced to provide optimal performance for for these devices. PHKL_10689: This patch provide support for logging of errors in memory management related system calls such as brk/sbrk as well as handling error cases during stack growth. Errors are logged on the system console (dmesg) and also in syslog. The variable mman_elog, which defaults to OFF, is used to control the logging. This variable can be set through adb at a customer site to enable error logging. PHKL_10675: LVM resyncs are not held off long enough during lvmerge. If an I/O timeout occurs during reimaging, then a resync is scheduled. Towards the end of lvmerge, there is a window in which the resync is allowed to run for a little bit. If the resync gets started on resyncing a stale extent during that interval, and the lvmerge is reimaging the same extent, the panic can occur. User I/O requests can encounter errors during lvmerge, but lvmerge wasn't taking these errors into account. There is the potential that extents can be falsely marked fresh during lvmerge if user I/O requests occur, resulting in data corruption if those extents are read. During activation (vgchange -a), LVM allocates various PV structures. A bit is cleared after a structure has been freed. 32 bit systems expect this low-order bit to be zero anyway (aligned addrs), so there is no impact if the freed memory has not yet been allocated to another subsystem before the bit is cleared. However, if the memory has been reallocated during this interval (i.e. on MP systems), various panics and strange behaviors could occur. PHKL_10643: There were two defects in the UFS read-ahead pagein code causing the system to request more read-ahead pages than the system maximum limit. Since the number of requested pages exceeded the allowed maximum, this resulted in overflowing internal arrays, and the system could then panic while using garbled data. First, the bookkeeping of the variables tracking the "last read-ahead" and the "expected next fault" was not always done properly. There was a situation where the "expected next fault" could end up exceeding the "last read-ahead", and this resulted in a read-ahead count greater than the system maximum limit. Second, there was a corner case code path using the "last read-ahead" variable before it had been initialized. PHKL_10554: PA-8000 systems with patch PHKL_9151 applied could experience an HPMC if the following were true: an external interrupt occurred while on the gateway page and the IIR in the save-state happened to contain a comb* instruction. Applying this fix will not only prevent this kind of failure, but should also boost performance on PA-8000 systems. PHKL_10452: Defect is quite rare. Kernel stack overflow may result from other causes. This fix reduces frame size of lv_end() from over 600 bytes to under 200 bytes. PHKL_10421: 7980S problem was caused by a change in the SCSI interface driver which caused the interface to negotiate for synchronous even when the driver had not enabled that negotiation. The 7980S drive is not SCSI-2 compliant, and has problems with synchronous negotiation in some places. Other changes were enhancements - no defect. PHKL_10316: If ptrace() is single stepping an user signal handler and handling a sigcleanup call, and another signal is handled during the return of this system call, the user's PC is overwritten by the single step breakpoint address before returning to the user. One way to reproduce the problem is to use DDE on a program that generates a lot of signals. Signal stepping through the program will eventually cause an internal I/O error. PHKL_10288: A buffer arrives in bwrite() with B_ASYNC/B_DELWRI and B_INVAL on and bp-vp == 0 (buffer disowned). On attempting to complete the write, VOP_STRATEGY resolution results in a trap 15 due to null vp. PHKL_10257: The problem fixed was a wrong assumption in add_text which expects the fstore to be the same as the bstore. Because of this assumption the original (and correct) bstore gets trashed when it is overwritten with the fstore after a call to duplicate a region. For an NFS executable with the sticky bit set, the fstore will NOT be the same as the bstore. We now have removed this assumption. PHKL_10234: Running an EXEC_MAGIC program using a stack pointer in the first quadrant could result in a panic: kernel scheduler interrupt. This problem would only be seen on UP systems. PHKL_10199: The bug is in the allocation and freeing of entire allocation units on filesystems larger than 64Gb in VxFS version 3. When calculating the buddy allocation unit to allocate and free, the code fails to add back in the map section that it subtracts out earlier, causing the summary of the wrong AU to be updated. The incorrect values in AU summaries and all higher level summaries lead to the allocation failure. PHKL_10176: The internal buffer within the kernel was created with a length of 20480 bytes, with no provision for increasing its size. This patch provides for up to 100 such buffers, with all but the first allocated only if required (that is, if more than 20480 bytes of argv/env information is found). Thus, exec() now supports up to 2048000 bytes of argv/env information. PHKL_10064: Negative time values for file modtimes are not defined in standards. Release 10.0 opted to make such values invalid. Unfortunately, some vendors were using negative times as flags rather than timestamps, and disallowing such values broke the application. The fix was to allow negative timestamps again. PHKL_9965: Drivers using the IO_CONTIGUOUS flag were not delivering optimal performance on Cache Coherent I/O platforms. The CCIO mapping routine was making unnecessary calls to other low level subroutines. PHKL_9931: Currently, biodone() sets B_DONE and drops the spinlock for the buffer before making a callback to an I/O completion routine, if one has been set up. This means that biowait() can return while the callback is in progress, and the buffer might be released. The solution is to always set B_DONE in finish_biodone() instead of biodone(). PHKL_9919: Upon synchronization, non-monarch processors expect the monarch to be waiting for them to synchronize. If the monarch is not waiting, the synchronization fails, and the offset_correction is set to 0. This happens only on bootup and may not happen every time. This causes times in the KI buffers to vary greatly, and that causes the midaemon to crash frequently. The problem is only at boot time, and will not occur later. This means a succesful boot will keep stay good, and a bad boot will stay bad. PHKL_9909: A deadlock resulted from a process running lvmerge on UFS LVs, and another process running umount on a VxFS LV. The umount process grabs the VxFS update sleep lock (used to serialize VxFS 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 VG lock. The lvmerge process is holding the LVM VG lock and proceeds to call freeze_and_sync_fs_dev() to freeze and sync the filesystem associated with the device. The routine ufs_freeze() is first called which in turn calls walk_and_freeze_fs() without a pointer to a vfs structure. This proves faulty since update() is now called without a vfsp and will proceed to try and sync every mounted filesystem instead of just the filesystem being frozen. So we proceeded to try and sync a VxFS file system which first tries to grab the VxFS update sleep lock, and a deadlock occurs. This problem can be reproduced by having one process running a lvsplit or lvmerge on a UFS LV, and another process running a mount, umount or sync on a VxFS LV. The fix for this problem is to pass the vfsp to walk_and_freeze_fs() from ufs_freeze() instead of the do_sync argument. The routine walk_and_freeze_fs() now uses vfsp when it calls update(). PHKL_9711: VxFS quota routine vx_getquota() resets the time limit for root because it thinks root should not have a quota limit. Somehow it ignores the fact that the timelimit fields in root's dqblk structure are used to store the filesystem time limit. PHKL_9569: This patch fixes two different VxFS 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 filesystem 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_9529: The lv_queryvg() function in ioctl(2) failed to copy the maxpxs field to the returning data structure. This problem was introduced in PHKL_8999. PHKL_9517: The problem can be reproduced by executing the following: - create a version 2 VxFS fs the same size as /usr - fragment the fs (ie. fill up the fs with 8k files, and then remove every other one). Proceed to remove groups of files until enough space is available to copy /usr over - cpio /usr to new fs, and run upgrade fs to version 3 - change /etc/fstab to use new volname for /usr, and reboot - start up /usr applications like sam, vi, swinstall, etc. - run several scripts to do things like add/delete small files, and ``ls'' commands in /usr - with ``busy'' filesystem, run "fsadm -Fvxfs -e /usr" The problem was that the resulting geometry was not being taken into account in vx_reorg_copy() if the reorg range was broken up due to lack of free extents of the requested size. The amount of data to be copied cannot be greater than the minimum of the two extent sizes returned by the bmap calls. PHKL_9372: Resizing VxFS filesystems online effectively does quick unmounts and remounts of the filesystem, switching quickly between the two different data areas containing the filesystem structure information. The VxFS disk quota tracking structures were not updated during the switch, with the end result that the disk quota code was accessing invalid memory. The fix was to update the disk quota structures during the switch. PHKL_9370: The inode summary fields in the new allocation unit added by extendfs were not properly initialized, so whatever happened to be in the block wound up being treated as inode summary data. The VxFS fsck command never detected this, and the mount command was failing in the kernel due to a filesystem validation error. The problem is easily reproduced by executing the following: # lvcreate -L 40 -n testvol /dev/vg00 # mkfs -Fvxfs -oversion=2 /dev/vg00/rtestvol # mount -Fvxfs /dev/vg00/testvol /tmp_mnt # umount /tmp_mnt # lvextend -L 80 /dev/vg00/testvol # extendfs -Fvxfs /dev/vg00/rtestvol # mount -Fvxfs /dev/vg00/testvol /tmp_mnt PHKL_9365: A defect in the kernel causes some processor data cache lines not to be flushed to memory prior to I/O operations. This can cause stale data to corrupt the user or system data. This defect only affects PA-8000-based systems (supported with HP-UX 10.20 and later releases). All systems based on earlier SPUs (PA-7200, PA-7100, PA-7150, for example) are not affected. This problem is rare; so far it has not been detected on customer systems, only within HP. However, all customers with PA-8000 systems are advised to apply the appropriate patch. PHKL_9361: binvalfree_vfs() has a race window where while one process is checking to see if a vnode buffer can be freed, another process dereferences the vnode pointer from the same buffer. The fix is to use a local variable to avoid the MP race. PHKL_9273: The file locking code is protected by a single semaphore (the filesys sema). As the semaphore becomes heavily utilized, starvation prevention code activates which leads to excessive spinning and switching. PHKL_9153: Added code to update the v_last_fsync field on the vnode. This field will be used by rfs_write to implement write gathering on NFS servers. Patch PHKL_9155/56, which updates rfs_write(), must also be applied for this patch to be effective. If both patches are applied, server throughput should increase for write-intensive workloads, and I/O traffic to disk should decrease. PHKL_9151: The changes are designed to improve locality of reference within the kernel, thus improving the i-cache hit rate. The "flipper" tool will reduce mis-predicted branches. All will improve the processor efficiency, or CPI rate, when executing kernel code. PHKL_9075: This patch provides two enhancements to Memory Mapped Files: increased performance when using thousands of mappings, and mprotect(2) opened to non-mmap(2) addresses. It also provides a fix for a defect with large buffer cache. The pregions list associated to a shared region was designed as a doubly-linked list thus providing a linear access to pregions in the list. This design was not suited to deal with thousands of pregions and the doubly-linked list was replaced by a skip-list for faster access. Two other changes were required to deliver better performance: the algorithm to check the total virtual address space and the routine to locate the stack pregion were enhanced. Only those addresses returned from a call to mmap(2) could be used for mprotect(2). However there were applications who needed to protect addresses in data, stack or shared memory segments; objects not created via call to mmap(2). So mprotect(2) was opened to allow mprotect'ing on data, stack and shared memory objects. Text is not allowed unless the executable is EXEC_MAGIC. A compiler feature with C language structure copies results in a reference to an untranslated address when copying the last 4 bytes in quadrant 3. This only shows up when the data in the buffer that is being copied includes address 0xbffffffc that is, it is the last full word in quadrant 3. The problem appears as a trap type 15: "data page fault". pstat_dynamic() allocates a buffer but fails to initialize it before using it. Buffer ends up containing some garbage. This is a cosmetic defect only; sar ignores the uninitialized spaces. PHKL_8999: This patch allows SLVM to work in a 4 node cluster. Alternate link support has also been added for SLVM so that devices such as the Nike disk array can now be used in a high availability cluster. LVM makes every effort to avoid returning an error to user applications. LVM will hold onto an I/O to retry it later if there is even the smallest hope that the device will return. If a disk simply does not respond and no bad writes made it to the media, LVM will hang onto the I/O request 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 LV to return, and cause LVM to return I/O requests with EIO instead of hanging onto them indefinitely. PHKL_8953: When VxFS calls getnewbuf() to acquire a buffer, it passes BX_NONBLOCK in bxflags to avoid potential deadlock. However, getnewbuf() calls bwrite() to flush the buffer without checking the bxflags when it finds a B_DELWRI buffer. This causes VxFS with a snapshot to hang. The fix: When getnewbuf() ends up grabbing a DELWRI buffer with BX_NONBLOCK, it will release the buffer and return NULL instead of flushing and returning the buffer. PHKL_8908: The c720 driver does not lisc->sclk soon enough. Chip timing parameters are set up incorrectly. PHKL_8755: The Exabyte bug can be reproduced by writing a large (100 Mb) file to an Exabyte drive using the 'BEST' device file in 'no rewind' mode, then writing the same file again to the same device. The first write will be substantially faster because it is compressed while following writes are not compressed. PHKL_8716: pstat_msginfo() calls msgconv() to convert the offset into a message queue pointer. msgconv() was changed to not only do the conversion, but to lock the queue and return a pointer to the queue's lock. pstat_msginfo() had not been changed to take into account msgconv()'s new behavior. PHKL_8683: While on the ICS, sysmemunreserve() was deferencing a no longer valid uarea pointer although its caller kalloc() took care of specifying "uarea/proc checking." The fix was to honor the flag passed by the callers. PHKL_8532: Intermittent corrupted dumps on PA-RISC2.0 (PA8000) machines. PHKL_8506: Before this patch the open() call did not look at media write protection. A write() to a write-protected tape would fail, but an open() with FWRITE mode would succeed. This change was made to make the GSC driver behave the same as the HP-PB driver. PHKL_8481: VxFS extra CPU utilization may cause system performance problems on some configurations. PHKL_8346: Current executable types cannot access more than 1.75 GB of shared memory. A new executable type is defined which uses the second quadrant of the address space for shared memory rather than process private data thus resulting in 2.75 GB of shared memory. With short pointer addressing on 32-bit PA architecture, each pointer addresses one of four quadrants each of which is 1 GB in size. Current executable types use quadrant 3 and quadrant 4 for shared memory. In user mode, quadrant 1 and quadrant 2 are used for user text and data, respectively. This results in a system wide maximum of 1.75 GB of shared memory (.25 GB in quadrant 4 is set aside for I/O). In the new executable type, user data and stack are pushed into quadrant 1 and quad 2 is also used for shared memory. An existing application has to be relinked as the new executable type to avail of this feature. Alternately the application can be linked as an EXEC_MAGIC and the n the executable can be chatr'd to be the new executable type (SHMEM_MAGIC). The related patch for chatr is PHSS_8358. Only the chatr method is currently supported. Please note that this is an interim solution for increased shared memory addressing till 64-bit HP-UX becomes available. There are several limitations: - Only executables that are linked to be the new SHMEM_MAGIC executable type (or chatrd to be so) can make use of this feature. Other executables will continue to see a system wide maximum of 1.75 GB of shared memory. Processes that execute other types of executables will not be able to share the memory in quadrant 2 with a process that is executing the new executable type. - In the new SHMEM_MAGIC type, quadrant 2 is only used for System V shared memory (unlike quadrants 3 and 4 which are also used for shared memory mapped files). - In the new executable type, text is mapped at different virtual addresses and so process intensive applications may not benefit. Any increase in performance due to the larger shared memory may be offset by decreases due to TLB inefficiency. Applications that use one process per processor may however benefit. - This will not be supported on future HP implementations of 64-bit architectures (beyond PA 2.0), nor will it need to be as with a 64-bit kernel the size of shared memory supported will be much larger than 2.75 GB. Programs that need more than 1.75 GB of shared memory on these architectures will have to be recompiled for these architectures. - Programs that are compiled as 64-bit executables on any 64-bit HP implementation (including PA 2.0) cannot be marked as SHMEM_MAGIC nor do they need to be as they will already have access to more than 1.75 GB of shared memory. PHKL_8331: There was a code path where dirty buffers could possibly be dropped (not flushed) when extending UFS files using fragments. PHKL_8294: ufs_bread(), called by NFS server routines, prematurely unlocks the inode while the caller still owns the buffer. This opens a window for another process to grab the inode lock. Deadlock occurs when the process owning the buffer tries to access the inode again and the process holding the inode waits for the buffer to be available before it can release the inode lock. The fix is to delay the inode unlocking in ufs_bread() until the inode is no longer needed. PHKL_8203: In 10.X, interrupt distribution is implemented to allow reassignment of interrupt processors to I/O interfaces for workload balancing. The assigned interrupt processor for an I/O interface may or may not be the system monarch depending on the the number of I/O cards and processors available. During a panic, if the panic processor is the system monarch, it will flush the buffer cache on its way down. If the interrupt of the disk it is syncing is serviced by one of the other processor(s), the I/O completion interrupt will not be received and the ISR will not be called because the other processor(s) are TOC'ed at this point. Without the ISR to signal biodone(), the biowait() sleeps forever. The fix is to add a timeout in the panic_boot path to break out from the hang in disk sync'ing and continue with the reboot. PHKL_8187: Select timeouts are retried forever. B_NDELAY should eliminate retries on select timeout. Zalon chip bug results in SCSI bus hang. PHKL_8128: A 'break' statement was missing from the end of a switch, causing the code to fall through to an error return. Device files which specify 'BEST' density work, but a DLT device with a density other than BEST will not open. PHKL_8084: Without this patch LVM will not retry failed I/O requests 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 LVs 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 PVs from a VG 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_8028: A flag in the driver indicates, for each device type, whether or not immediate reporting should be enabled for filemarks. That flag was not being set for DLT drives. To reproduce, write a short C program that writes 20 blocks of 1K bytes, each separated by a filemark. Performance will be substantially better with this patch applied. PHKL_7987: Bug in scsi_schedule_retry causes hang. 10 ms select timeout period is too short. PHKL_7967: fuser does not report processes in lofs. To reproduce this problem, do following: mkdir /test #create new directory mount /home /test cd /test Before the fix, "fuser -c /test" reports no process. After the fix, "ufser -c /test" reports the local shell. PHKL_7951: 32 bit registers were allowed to be modified after 64 bit registers have been modified. PHKL_7899: KI problem: The VxFS buffer allocation and I/O paths were not fully instrumented causing buffer header b_apid and b_upid fields not to be updated consistently. The resulting KI queuedone, enqueue, and queuestart traces contain NULL values in these fields. A panic can occur with VxFS on LVM due to an inode being able to change identity before it and its dirty pages are flushed to disk in vx_freeze_iflush(). System can deadlock due to a locking order problem in VxFS when vx_fast_read() is called from VOP_BREAD. When a VxFS 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_7870: The problem was that the kernel forced a panic whenever any inconsistency was found during an lvreduce. For example, if a logical extent in an LV referred to a PE that was not allocated, it would cause lvreduce(1M) to panic the system. This occured even when the objective was to remove the offending LV. This is a very rare occurrence. PHKL_7776: At mount time, the kernel completes any pending "extended operations" for a VxFS filesystem. (These might include, for example, removing a file that has no links but couldn't be removed when the last link went away because some process had the file open.) We maintain a bitmap on disk with one bit per inode indicating whether the inode has any extended operations pending, to avoid having to inspect every single inode at mount time. However, the calculation of an inode number from a bit in the bitmap is done incorrectly. This means, first of all, that some extended operations are never completed. More seriously, the inode number we calculate could be out of range, causing the mount to fail. Running fsck(1M) will not help, since there's nothing wrong with the filesystem. Although the filesystem can't be mounted in read/write mode, it can be mounted read-only. If a filesystem gets into this unmountable state, the only recourse is to mount it read-only and to copy the files from it to another (replacement) filesystem. SR: 1653096131 1653138164 1653166066 1653166496 1653166983 1653170464 1653172908 1653177089 1653179895 1653180810 1653183699 1653189738 1653192294 1653194555 1653194977 1653199406 1653199802 1653202754 1653207175 1653211607 1653213082 1653214338 1653215020 1653215467 1653216077 1653216606 1653216952 1653218065 1653220079 1653221820 1653221895 1653223404 1653223669 1653227983 1653228106 1653229476 1653230771 1653235176 1653236869 1653237842 1653239137 1653244012 1653247486 1653248690 1653250423 1653253229 1653254987 1653258681 1653259408 1653260158 1653263434 1653263962 1653269936 1653271163 1653273540 1653277962 4701327338 4701327544 4701329292 4701329300 4701329417 4701329433 4701329441 4701330647 4701333419 4701334367 4701334698 4701334847 4701334995 4701335497 4701335935 4701336412 4701337394 4701339226 4701341362 4701341479 4701341644 4701341669 4701342089 4701342121 4701342147 4701344515 4701345843 4701346122 4701346791 4701347922 4701348359 4701349175 4701349431 4701350157 4701350975 4701351932 4701352278 4701352799 4701353078 4701353094 4701353102 4701353888 4701354274 4701354803 4701354837 4701354845 4701355123 4701355321 4701355560 4701355610 4701356766 4701356931 4701358143 4701358523 4701360693 4701360925 4701361188 4701361444 4701361758 4701362111 4701364182 4701365114 4701365791 4701371294 4701371617 4701372276 4701373050 4701374520 4701375485 4701375816 4701375956 4701376269 4701376863 4701377226 4701377580 4701377770 4701378117 4701379347 4701379354 4701380519 4701380808 4701381608 4701382564 4701383315 4701383612 4701388975 4701391094 4701391730 4701391797 4701393074 4701393819 4701393884 4701394163 4701394635 4701395822 4701396200 4701398420 4701399519 4701399584 5000698738 5000716225 5003281469 5003295238 5003314633 5003317487 5003318667 5003321760 5003323493 5003325506 5003328237 5003329078 5003330746 5003330910 5003334961 5003336933 5003341925 5003344184 5003344630 5003345496 5003348425 5003353797 5003356345 5003357616 5003359414 5003359489 5003360024 5003360446 5003361766 5003363523 5003363820 5003364224 5003365692 5003366500 5003366971 5003367888 5003367979 5003368290 5003368860 5003379156 5003380113 5003384586 5003385203 5003385393 5003387019 5003387183 5003387407 5003397174 5003398800 5003399188 5003407221 5003407601 5003407619 5003409185 5003410423 5003410977 5003413278 5003414540 5003418244 5003421628 5003422212 5003423814 5003425512 5003428706 5003435222 5003435420 Patch Files: /usr/conf/h/_flkmgr.h /usr/conf/h/audit.h /usr/conf/h/dnlc.h /usr/conf/h/fss.h /usr/conf/h/mtio.h /usr/conf/io/dma.h /usr/conf/lib/libdmapi.a(kdm_core.o) /usr/conf/lib/libdmapi.a(vx_dmattr_table.o) /usr/conf/lib/libhp-ux.a(asm_rdb.o) /usr/conf/lib/libhp-ux.a(asm_rv.o) /usr/conf/lib/libhp-ux.a(asm_scall.o) /usr/conf/lib/libhp-ux.a(asm_utl.o) /usr/conf/lib/libhp-ux.a(asm_vm.o) /usr/conf/lib/libhp-ux.a(asm_vm_pdir.o) /usr/conf/lib/libhp-ux.a(audctl.o) /usr/conf/lib/libhp-ux.a(bcopy.o) /usr/conf/lib/libhp-ux.a(btlb.o) /usr/conf/lib/libhp-ux.a(bzero.o) /usr/conf/lib/libhp-ux.a(clock.o) /usr/conf/lib/libhp-ux.a(cpd.o) /usr/conf/lib/libhp-ux.a(dma_A.o) /usr/conf/lib/libhp-ux.a(dma_s700.o) /usr/conf/lib/libhp-ux.a(dump.o) /usr/conf/lib/libhp-ux.a(dump_conf.o) /usr/conf/lib/libhp-ux.a(eisa.o) /usr/conf/lib/libhp-ux.a(flipper.o) /usr/conf/lib/libhp-ux.a(flkmgr.o) /usr/conf/lib/libhp-ux.a(flkmgr_dom.o) /usr/conf/lib/libhp-ux.a(flkmgr_flk.o) /usr/conf/lib/libhp-ux.a(flkmgr_hp.o) /usr/conf/lib/libhp-ux.a(flkmgr_main.o) /usr/conf/lib/libhp-ux.a(flkmgr_mm.o) /usr/conf/lib/libhp-ux.a(flkmgr_pm.o) /usr/conf/lib/libhp-ux.a(fssdefault.o) /usr/conf/lib/libhp-ux.a(gio_node.o) /usr/conf/lib/libhp-ux.a(hdl_fault.o) /usr/conf/lib/libhp-ux.a(hdl_init.o) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) /usr/conf/lib/libhp-ux.a(hdl_policy.o) /usr/conf/lib/libhp-ux.a(hdl_trans.o) /usr/conf/lib/libhp-ux.a(init_main.o) /usr/conf/lib/libhp-ux.a(interrupt.o) /usr/conf/lib/libhp-ux.a(io.o) /usr/conf/lib/libhp-ux.a(ios_int.o) /usr/conf/lib/libhp-ux.a(ios_mem.o) /usr/conf/lib/libhp-ux.a(kern_acct.o) /usr/conf/lib/libhp-ux.a(kern_exec.o) /usr/conf/lib/libhp-ux.a(kern_exit.o) /usr/conf/lib/libhp-ux.a(kern_fork.o) /usr/conf/lib/libhp-ux.a(kern_kload.o) /usr/conf/lib/libhp-ux.a(kern_mman.o) /usr/conf/lib/libhp-ux.a(kern_sig.o) /usr/conf/lib/libhp-ux.a(lbcopy.o) /usr/conf/lib/libhp-ux.a(lbzero.o) /usr/conf/lib/libhp-ux.a(lo_subr.o) /usr/conf/lib/libhp-ux.a(lo_vfsops.o) /usr/conf/lib/libhp-ux.a(lo_vnops.o) /usr/conf/lib/libhp-ux.a(lv_config.o) /usr/conf/lib/libhp-ux.a(lv_lvm.o) /usr/conf/lib/libhp-ux.a(lw_scall.o) /usr/conf/lib/libhp-ux.a(machdep.o) /usr/conf/lib/libhp-ux.a(outlaw.o) /usr/conf/lib/libhp-ux.a(pa_ccio.o) /usr/conf/lib/libhp-ux.a(pa_cdio.o) /usr/conf/lib/libhp-ux.a(pa_lvl1.o) /usr/conf/lib/libhp-ux.a(pa_map.o) /usr/conf/lib/libhp-ux.a(pci_debug.o) /usr/conf/lib/libhp-ux.a(pgcopy.o) /usr/conf/lib/libhp-ux.a(pm_clockint.o) /usr/conf/lib/libhp-ux.a(pm_config.o) /usr/conf/lib/libhp-ux.a(pm_context.o) /usr/conf/lib/libhp-ux.a(pm_core.o) /usr/conf/lib/libhp-ux.a(pm_getpid.o) /usr/conf/lib/libhp-ux.a(pm_policy.o) /usr/conf/lib/libhp-ux.a(pm_proc.o) /usr/conf/lib/libhp-ux.a(pm_procdup.o) /usr/conf/lib/libhp-ux.a(pm_ptrace.o) /usr/conf/lib/libhp-ux.a(pm_resource.o) /usr/conf/lib/libhp-ux.a(pm_rtsched.o) /usr/conf/lib/libhp-ux.a(pm_sendsig.o) /usr/conf/lib/libhp-ux.a(pm_signal.o) /usr/conf/lib/libhp-ux.a(pm_swtch.o) /usr/conf/lib/libhp-ux.a(pm_threads.o) /usr/conf/lib/libhp-ux.a(pm_timers.o) /usr/conf/lib/libhp-ux.a(protection.o) /usr/conf/lib/libhp-ux.a(pstat.o) /usr/conf/lib/libhp-ux.a(rdb.o) /usr/conf/lib/libhp-ux.a(rdb_boot.o) /usr/conf/lib/libhp-ux.a(rdb_com.o) /usr/conf/lib/libhp-ux.a(rdb_com_lan.o) /usr/conf/lib/libhp-ux.a(rdb_lan.o) /usr/conf/lib/libhp-ux.a(rdb_mp.o) /usr/conf/lib/libhp-ux.a(rdb_rs232.o) /usr/conf/lib/libhp-ux.a(resume.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_tape.o) /usr/conf/lib/libhp-ux.a(sem_alpha.o) /usr/conf/lib/libhp-ux.a(spec_vnops.o) /usr/conf/lib/libhp-ux.a(spinlock.o) /usr/conf/lib/libhp-ux.a(subr_ksleep.o) /usr/conf/lib/libhp-ux.a(subr_rmap.o) /usr/conf/lib/libhp-ux.a(subr_timers.o) /usr/conf/lib/libhp-ux.a(sysV_shm.o) /usr/conf/lib/libhp-ux.a(trap.o) /usr/conf/lib/libhp-ux.a(ufs_dsort.o) /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) /usr/conf/lib/libhp-ux.a(ulbcopy.o) /usr/conf/lib/libhp-ux.a(vfs.o) /usr/conf/lib/libhp-ux.a(vfs_bio.o) /usr/conf/lib/libhp-ux.a(vfs_dnlc.o) /usr/conf/lib/libhp-ux.a(vfs_scalls.o) /usr/conf/lib/libhp-ux.a(vfs_vm.o) /usr/conf/lib/libhp-ux.a(vfs_vnode.o) /usr/conf/lib/libhp-ux.a(vm_fault.o) /usr/conf/lib/libhp-ux.a(vm_kern.o) /usr/conf/lib/libhp-ux.a(vm_machdep.o) /usr/conf/lib/libhp-ux.a(vm_machreg.o) /usr/conf/lib/libhp-ux.a(vm_mmap.o) /usr/conf/lib/libhp-ux.a(vm_page.o) /usr/conf/lib/libhp-ux.a(vm_pdir1_1.o) /usr/conf/lib/libhp-ux.a(vm_pdir2_0.o) /usr/conf/lib/libhp-ux.a(vm_pregion.o) /usr/conf/lib/libhp-ux.a(vm_region.o) /usr/conf/lib/libhp-ux.a(vm_sched.o) /usr/conf/lib/libhp-ux.a(vm_superpage.o) /usr/conf/lib/libhp-ux.a(vm_text.o) /usr/conf/lib/libhp-ux.a(vm_vas.o) /usr/conf/lib/libhp-ux.a(vm_vhand.o) /usr/conf/lib/libhp-ux.a(wsio_scsi.o) /usr/conf/lib/libhp-ux.a(wsio_util.o) /usr/conf/lib/liblvm.a(lv_block.o) /usr/conf/lib/liblvm.a(lv_cluster_lock.o) /usr/conf/lib/liblvm.a(lv_defect.o) /usr/conf/lib/liblvm.a(lv_hp.o) /usr/conf/lib/liblvm.a(lv_ioctls.o) /usr/conf/lib/liblvm.a(lv_kdb.o) /usr/conf/lib/liblvm.a(lv_lvsubr.o) /usr/conf/lib/liblvm.a(lv_malloc.o) /usr/conf/lib/liblvm.a(lv_mircons.o) /usr/conf/lib/liblvm.a(lv_pbuf.o) /usr/conf/lib/liblvm.a(lv_phys.o) /usr/conf/lib/liblvm.a(lv_schedule.o) /usr/conf/lib/liblvm.a(lv_spare.o) /usr/conf/lib/liblvm.a(lv_strategy.o) /usr/conf/lib/liblvm.a(lv_stub.o) /usr/conf/lib/liblvm.a(lv_subr.o) /usr/conf/lib/liblvm.a(lv_syscalls.o) /usr/conf/lib/liblvm.a(lv_vgda.o) /usr/conf/lib/liblvm.a(lv_vgsa.o) /usr/conf/lib/liblvm.a(sh_vgsa.o) /usr/conf/lib/liblvm.a(slvm_comm.o) /usr/conf/lib/liblvm.a(slvm_schedule.o) /usr/conf/lib/libpci.a(dino3.o) /usr/conf/lib/libpci.a(dino_cdio.o) /usr/conf/lib/libpci.a(h2p_iface.o) /usr/conf/lib/libpci.a(pci.o) /usr/conf/lib/libpci.a(pci_cdio.o) /usr/conf/lib/libpci.a(pci_wsio.o) /usr/conf/lib/libprm.a(kern_fss.o) /usr/conf/lib/libufs.a(ufs_alloc.o) /usr/conf/lib/libufs.a(ufs_inode.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_dmattr.o) /usr/conf/lib/libvxfs_adv.a(vx_full.o) /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) /usr/conf/lib/libvxfs_adv.a(vx_sample_dmattr.o) /usr/conf/lib/libvxfs_base.a(vx_alloc.o) /usr/conf/lib/libvxfs_base.a(vx_attr.o) /usr/conf/lib/libvxfs_base.a(vx_bio.o) /usr/conf/lib/libvxfs_base.a(vx_bio1.o) /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o) /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o) /usr/conf/lib/libvxfs_base.a(vx_chain.o) /usr/conf/lib/libvxfs_base.a(vx_dirl.o) /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o) /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o) /usr/conf/lib/libvxfs_base.a(vx_iflush.o) /usr/conf/lib/libvxfs_base.a(vx_inode.o) /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) /usr/conf/lib/libvxfs_base.a(vx_lite.o) /usr/conf/lib/libvxfs_base.a(vx_log.o) /usr/conf/lib/libvxfs_base.a(vx_mount.o) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) /usr/conf/lib/libvxfs_base.a(vx_replay.o) /usr/conf/lib/libvxfs_base.a(vx_vfsops.o) /usr/conf/lib/libvxfs_base.a(vx_vm.o) /usr/conf/lib/libvxfs_base.a(vx_vnops.o) /usr/conf/machine/cpu.h /usr/conf/machine/reg.h /usr/conf/master.d/core-hpux /usr/conf/master.d/flkmgr /usr/conf/space.h.d/core-hpux.h /usr/conf/space.h.d/flkmgr_globals.h /usr/conf/wsio/pci.h /usr/include/dmapi.h /usr/include/machine/cpu.h /usr/include/machine/reg.h /usr/include/sys/audit.h /usr/include/sys/dma.h /usr/include/sys/dnlc.h /usr/include/sys/fs/vx_hpux.h /usr/include/sys/fss.h /usr/include/sys/mtio.h /usr/include/sys/pci.h what(1) Output: /usr/conf/h/_flkmgr.h: _flkmgr.h $Date: 98/02/02 14:04:07 $ $Revision: 1 .1.98.3 $ PATCH_10.20 (PHKL_14012) /usr/conf/h/audit.h: audit.h $Date: 97/04/21 13:54:38 $ $Revision: 1.10.98.5 $ PATCH_10.20 (PHKL_10800) /usr/conf/h/dnlc.h: dnlc.h $Date: 97/09/02 15:03:34 $ $Revision: 1.4.98 .3 $ PATCH_10.20 (PHKL_12378) /usr/conf/h/fss.h: fss.h $Date: 98/01/08 14:50:28 $ $Revision: 1.5.9 8.4 $ PATCH_10.20 (PHKL_12963) fss.h: $Revision: 1.5.98.4 $ $Date: 98/01/08 14:50:2 8 $ /usr/conf/h/mtio.h: mtio.h $Date: 98/08/06 14:02:42 $ $Revision: 1.24.98 .9 $ PATCH_10.20 (PHKL_15958) /usr/conf/io/dma.h: dma.h $Date: 97/05/06 19:10:56 $ $Revision: 1.5.98.3 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libdmapi.a(kdm_core.o): kdm_core.c $Date: 98/10/08 08:26:45 $ $Revision: 1.2 .98.10 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libdmapi.a(vx_dmattr_table.o): vx_dmattr_table.c $Date: 97/10/15 15:06:43 $ $Revisi on: 1.2.98.5 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libhp-ux.a(asm_rdb.o): asm_rdb.s $Date: 98/04/28 15:07:02 $ $Revision: 1.33 .98.2 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(asm_rv.o): asm_rv.s $Date: 97/12/02 15:04:48 $ $Revision: 1.57 .98.15 $ PATCH_10.20 (PHKL_13260) /usr/conf/lib/libhp-ux.a(asm_scall.o): asm_scall.s $Date: 96/11/22 10:45:59 $ $Revision: 1 .39.98.6 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(asm_utl.o): asm_utl.s $Date: 96/11/22 10:49:42 $ $Revision: 1.1 17.98.10 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(asm_vm.o): asm_vm.s $Date: 98/01/13 15:04:01 $ $Revision: 1.60.98.11 $ PATCH_10.20 (PHKL_13795) /usr/conf/lib/libhp-ux.a(asm_vm_pdir.o): asm_vm_pdir.s $Date: 97/05/02 01:58:51 $ $Revision: 1.2.98.5 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(audctl.o): audctl.c $Date: 98/02/09 14:10:00 $ $Revision: 1. 13.98.5 $ PATCH_10.20 (PHKL_14126) /usr/conf/lib/libhp-ux.a(bcopy.o): bcopy.s $Date: 96/11/22 10:51:06 $ $Revision: 1.7.9 8.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(btlb.o): btlb.c $Date: 97/05/02 02:00:53 $ $Revision: 1.9. 98.4 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(bzero.o): bzero.s $Date: 96/11/22 10:52:32 $ $Revision: 1.9.9 8.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(clock.o): clock.c $Date: 98/09/16 10:28:29 $ $Revision: 1.39. 98.8 $ PATCH_10.20 (PHKL_15598) /usr/conf/lib/libhp-ux.a(cpd.o): cpd.c $Date: 96/10/26 09:39:05 $ $Revision: 1.9.98.8 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(dma_A.o): dma_A.c $Date: 97/05/06 19:28:47 $ $Revision: 1.12 .98.4 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(dma_s700.o): dma_s700.c $Date: 97/05/06 19:21:39 $ $Revision: 1.6.98.3 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(dump.o): dump.c $Date: 96/10/26 09:49:44 $ $Revision: 1.11.98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libhp-ux.a(dump_conf.o): dump_conf.c $Date: 98/06/11 05:07:36 $ $Revision: 1.6.98.7 $ PATCH_10.20 (PHKL_15492) /usr/conf/lib/libhp-ux.a(eisa.o): eisa.c $Date: 97/05/06 19:19:30 $ $Revision: 1.11.98 .2 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(flipper.o): flipper.c $Date: 97/03/31 14:58:19 $ $Revision: 1.3. 98.8 $ PATCH_10.20 (PHKL_10554) /usr/conf/lib/libhp-ux.a(flkmgr.o): flkmgr.c $Date: 98/03/25 16:12:57 $ $Revision: 1.1.98.2 $ PATCH_10.20 (PHKL_14568) /usr/conf/lib/libhp-ux.a(flkmgr_dom.o): flkmgr_dom.c $Date: 98/03/20 09:26:00 $ $Revision: 1.1.98.3 $ PATCH_10.20 (PHKL_14568) /usr/conf/lib/libhp-ux.a(flkmgr_flk.o): flkmgr_flk.c $Date: 98/03/20 09:26:12 $ $Revision: 1.1.98.3 $ PATCH_10.20 (PHKL_14568) /usr/conf/lib/libhp-ux.a(flkmgr_hp.o): flkmgr_hp.c $Date: 98/03/20 09:30:11 $ $Revision: 1.1.98.4 $ PATCH_10.20 (PHKL_14568) /usr/conf/lib/libhp-ux.a(flkmgr_main.o): flkmgr_main.c $Date: 98/03/20 09:28:37 $ $Revision: 1.1.98.5 $ PATCH_10.20 (PHKL_14568) /usr/conf/lib/libhp-ux.a(flkmgr_mm.o): flkmgr_mm.c $Date: 98/03/20 09:28:56 $ $Revision: 1.1.98.3 $ PATCH_10.20 (PHKL_14568) /usr/conf/lib/libhp-ux.a(flkmgr_pm.o): flkmgr_pm.c $Date: 98/03/20 09:30:21 $ $Revision: 1.1.98.3 $ PATCH_10.20 (PHKL_14568) /usr/conf/lib/libhp-ux.a(fssdefault.o): fssdefault.c $Date: 98/08/19 10:40:08 $ $Revision : 1.7.98.3 $ PATCH_10.20 (PHKL_16207) /usr/conf/lib/libhp-ux.a(gio_node.o): gio_node.c $Date: 98/04/28 15:02:19 $ $Revision: 1.7 .98.4 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(hdl_fault.o): hdl_fault.c $Date: 98/07/10 15:59:11 $ $Revision: 1. 13.98.12 $ PATCH_10.20 (PHKL_15915) /usr/conf/lib/libhp-ux.a(hdl_init.o): hdl_init.c $Date: 96/08/26 22:38:17 $ $Revision: 1.9.98.5 $ PATCH_10.20 (PHKL_8346) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o): hdl_mprotect.c $Date: 98/01/09 15:32:02 $ $Revision: 1.4.98.6 $ PATCH_10.20 (PHKL_13761) /usr/conf/lib/libhp-ux.a(hdl_policy.o): hdl_policy.c $Date: 98/09/09 14:22:06 $ $Revision: 1 .15.98.15 $ PATCH_10.20 (PHKL_16387) /usr/conf/lib/libhp-ux.a(hdl_trans.o): hdl_trans.c $Date: 98/02/19 09:36:04 $ $Revision: 1.12.98.12 $ PATCH_10.20 (PHKL_14225) /usr/conf/lib/libhp-ux.a(init_main.o): init_main.c $Date: 98/09/16 10:27:09 $ $Revision: 1.120.98.15 $ PATCH_10.20 (PHKL_15598) /usr/conf/lib/libhp-ux.a(interrupt.o): interrupt.s $Date: 97/03/31 13:22:48 $ $Revision: 1 .12.98.10 $ PATCH_10.20 (PHKL_10554) /usr/conf/lib/libhp-ux.a(io.o): io.c $Date: 97/05/07 09:02:22 $ $Revision: 1.3.98.2 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(ios_int.o): ios_int.c $Date: 97/05/06 19:25:20 $ $Revision: 1.10 .98.2 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(ios_mem.o): ios_mem.c $Date: 97/05/06 19:26:47 $ $Revision: 1.9. 98.2 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(kern_acct.o): kern_acct.c $Date: 98/02/09 14:26:42 $ $Revision: 1. 30.98.7 $ PATCH_10.20 (PHKL_14126) /usr/conf/lib/libhp-ux.a(kern_exec.o): kern_exec.c $Date: 98/05/01 05:17:17 $ $Revision: 1.93.98.25 $ PATCH_10.20 (PHKL_15085) /usr/conf/lib/libhp-ux.a(kern_exit.o): kern_exit.c $Date: 98/02/02 14:05:08 $ $Revision: 1.77.98.16 $ PATCH_10.20 (PHKL_14012) /usr/conf/lib/libhp-ux.a(kern_fork.o): kern_fork.c $Date: 98/02/02 14:05:13 $ $Revision: 1.71.98.19 $ PATCH_10.20 (PHKL_14012) /usr/conf/lib/libhp-ux.a(kern_kload.o): kern_kload.c $Date: 97/05/02 02:02:58 $ $Revision : 1.4.98.5 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(kern_mman.o): kern_mman.c $Date: 97/04/09 11:33:14 $ $Revision: 1.35.98.5 $ PATCH_10.20 (PHKL_10689) /usr/conf/lib/libhp-ux.a(kern_sig.o): kern_sig.c $Date: 97/05/02 02:03:00 $ $Revision: 1.66.98.4 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(lbcopy.o): lbcopy.s $Date: 97/05/02 16:44:13 $ $Revision: 1.7. 98.6 $ PATCH_10.20 (PHKL_10932) /usr/conf/lib/libhp-ux.a(lbzero.o): lbzero.s $Date: 96/11/22 10:57:29 $ $Revision: 1.9. 98.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(lo_subr.o): lo_subr.c $Date: 98/10/08 12:53:39 $ $Revision: 1.4. 98.6 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libhp-ux.a(lo_vfsops.o): lo_vfsops.c $Date: 98/09/10 10:29:26 $ $Revision: 1. 4.98.7 $ PATCH_10.20 (PHKL_16387) /usr/conf/lib/libhp-ux.a(lo_vnops.o): lo_vnops.c $Date: 98/10/08 12:54:04 $ $Revision: 1.5 .98.7 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libhp-ux.a(lv_config.o): lv_config.c $Date: 98/09/17 17:41:05 $ $Revision: 1. 13.98.8 $ PATCH_10.20 (PHKL_16455) /usr/conf/lib/libhp-ux.a(lv_lvm.o): lv_lvm.c $Date: 97/12/17 14:24:01 $ $Revision: 1.3.9 8.4 $ PATCH_10.20 (PHKL_13247) /usr/conf/lib/libhp-ux.a(lw_scall.o): lw_scall.s $Date: 97/05/02 02:01:00 $ $Revision: 1.18.98.7 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(machdep.o): machdep.c $Date: 97/09/23 11:23:01 $ $Revision: 1.12 6.98.8 $ PATCH_10.20 (PHKL_12662) /usr/conf/lib/libhp-ux.a(outlaw.o): outlaw.c $Date: 96/11/22 11:17:11 $ $Revision: 1.2.98.3 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(pa_ccio.o): pa_ccio.c $Date: 97/05/16 01:04:22 $ $Revision: 1.6. 98.8 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(pa_cdio.o): pa_cdio.c $Date: 97/05/08 19:37:16 $ $Revision: 1.8. 98.9 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(pa_lvl1.o): pa_lvl1.c $Date: 98/04/28 14:58:54 $ $Revision: 1.5. 98.12 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(pa_map.o): pa_map.c $Date: 97/05/29 09:24:49 $ $Revision: 1.7.9 8.4 $ PATCH_10.20 (PHKL_11002) /usr/conf/lib/libhp-ux.a(pci_debug.o): pci_debug.c $Date: 97/08/18 18:35:45 $ $Revision : 1.2.98.3 $ PATCH_10.20 (PHKL_11351) /usr/conf/lib/libhp-ux.a(pgcopy.o): pgcopy.s $Date: 96/11/22 18:05:02 $ $Revision: 1.7. 98.5 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(pm_clockint.o): pm_clockint.c $Date: 98/01/08 10:02:23 $ $Revision: 1.7.98.8 $ PATCH_10.20 (PHKL_12963) /usr/conf/lib/libhp-ux.a(pm_config.o): pm_config.c $Date: 97/06/17 15:09:55 $ $Revision: 1. 6.98.8 $ PATCH_10.20 (PHKL_11406) /usr/conf/lib/libhp-ux.a(pm_context.o): pm_context.c $Date: 98/08/04 17:48:48 $ $Revision : 1.3.98.7 $ PATCH_10.20 (PHKL_15958) /usr/conf/lib/libhp-ux.a(pm_core.o): pm_core.c $Date: 98/02/09 14:28:20 $ $Revision: 1 .9.98.11 $ PATCH_10.20 (PHKL_14126) /usr/conf/lib/libhp-ux.a(pm_getpid.o): pm_getpid.c $Date: 98/02/02 14:05:16 $ $Revision: 1.6.98.2 $ PATCH_10.20 (PHKL_14012) /usr/conf/lib/libhp-ux.a(pm_policy.o): pm_policy.c $Date: 98/03/17 10:21:04 $ $Revision: 1.7.98.11 $ PATCH_10.20 (PHKL_14490) /usr/conf/lib/libhp-ux.a(pm_proc.o): pm_proc.c $Date: 97/06/11 17:26:34 $ $Revision: 1.13 .98.12 $ PATCH_10.20 (PHKL_11339) /usr/conf/lib/libhp-ux.a(pm_procdup.o): pm_procdup.c $Date: 97/11/18 12:02:39 $ $Revision: 1 .11.98.14 $ PATCH_10.20 (PHKL_13260) /usr/conf/lib/libhp-ux.a(pm_ptrace.o): pm_ptrace.c $Date: 97/05/02 02:03:08 $ $Revision: 1. 6.98.25 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(pm_resource.o): pm_resource.c $Date: 97/06/11 17:28:51 $ $Revision: 1.7.98.14 $ PATCH_10.20 (PHKL_11339) /usr/conf/lib/libhp-ux.a(pm_rtsched.o): pm_rtsched.c $Date: 97/09/08 22:31:38 $ $Revision: 1 .6.98.4 $ PATCH_10.20 (PHKL_12042) /usr/conf/lib/libhp-ux.a(pm_sendsig.o): pm_sendsig.c $Date: 97/05/02 02:01:02 $ $Revision : 1.4.98.12 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(pm_signal.o): pm_signal.c $Date: 97/08/08 16:59:26 $ $Revision: 1.6.98.17 $ PATCH_10.20 (PHKL_12073) /usr/conf/lib/libhp-ux.a(pm_swtch.o): pm_swtch.c $Date: 98/05/12 14:26:30 $ $Revision: 1.7.98.21 $ PATCH_10.20 (PHKL_15244) /usr/conf/lib/libhp-ux.a(pm_threads.o): pm_threads.c $Date: 97/05/02 02:03:13 $ $Revision : 1.3.98.11 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(pm_timers.o): pm_timers.c $Date: 98/05/27 17:58:38 $ $Revision: 1. 7.98.12 $ PATCH_10.20 (PHKL_15456) /usr/conf/lib/libhp-ux.a(protection.o): protection.s $Date: 96/11/22 11:00:38 $ $Revision: 1.10.98.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(pstat.o): pstat.c $Date: 98/01/30 11:43:58 $ $Revision: 1.18.9 8.24 $ PATCH_10.20 (PHKL_14009) /usr/conf/lib/libhp-ux.a(rdb.o): rdb.c $Date: 98/04/28 15:05:14 $ $Revision: 1.34. 98.3 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(rdb_boot.o): rdb_boot.c $Date: 98/04/28 15:08:29 $ $Revision: 1.8.98.2 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(rdb_com.o): rdb_com.c $Date: 98/04/28 15:09:17 $ $Revision: 1 .10.98.3 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(rdb_com_lan.o): rdb_com_lan.c $Date: 98/04/28 15:09:25 $ $Revisio n: 1.5.98.2 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(rdb_lan.o): rdb_lan.c $Date: 98/04/28 15:09:31 $ $Revision: 1 .5.98.3 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(rdb_mp.o): rdb_mp.c $Date: 98/04/28 15:09:42 $ $Revision: 1. 8.98.2 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(rdb_rs232.o): rdb_rs232.c $Date: 98/04/28 15:09:44 $ $Revision: 1.6.98.2 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(resume.o): resume.s $Date: 96/11/22 11:01:44 $ $Revision: 1.11 .98.4 $ PATCH_10.20 (PHKL_9151) /usr/conf/lib/libhp-ux.a(scsi_c720.o): scsi_c720.c $Date: 98/09/09 11:00:54 $ $Revision: 1.5.98.35 $ PATCH_10.20 (PHKL_16387) /usr/conf/lib/libhp-ux.a(scsi_ctl.o): scsi_ctl.c $Date: 97/10/28 09:31:07 $ $Revision: 1.9.98.34 $ PATCH_10.20 (PHKL_13014) /usr/conf/lib/libhp-ux.a(scsi_disk.o): scsi_disk.c $Date: 98/04/21 13:14:59 $ $Revision: 1.7.98.28 $ PATCH_10.20 (PHKL_14917) /usr/conf/lib/libhp-ux.a(scsi_tape.o): scsi_tape.c $Date: 98/10/19 11:33:30 $ $Revision: 1. 8.98.20 $ PATCH_10.20 (PHKL_16730) /usr/conf/lib/libhp-ux.a(sem_alpha.o): sem_alpha.c $Date: 96/11/20 16:33:04 $ $Revision: 1.11.98.5 $ PATCH_10.20 (PHKL_9273) /usr/conf/lib/libhp-ux.a(spec_vnops.o): spec_vnops.c $Date: 98/05/27 18:09:09 $ $Revision: 1 .13.98.8 $ PATCH_10.20 (PHKL_15456) /usr/conf/lib/libhp-ux.a(spinlock.o): spinlock.c $Date: 98/02/12 09:33:34 $ $Revision: 1.1 6.98.9 $ PATCH_10.20 (PHKL_14183) /usr/conf/lib/libhp-ux.a(subr_ksleep.o): subr_ksleep.c $Date: 97/05/02 02:03:21 $ $Revisio n: 1.1.98.13 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(subr_rmap.o): subr_rmap.c $Date: 98/04/30 10:59:49 $ $Revision: 1. 17.98.3 $ PATCH_10.20 (PHKL_15057) /usr/conf/lib/libhp-ux.a(subr_timers.o): subr_timers.c $Date: 97/08/13 17:10:50 $ $Revision: 1.8.98.13 $ PATCH_10.20 (PHKL_12110) /usr/conf/lib/libhp-ux.a(sysV_shm.o): sysV_shm.c $Date: 96/11/20 11:01:21 $ $Revision: 1.54.98.5 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(trap.o): trap.c $Date: 97/09/23 11:22:02 $ $Revision: 1.16 9.98.14 $ PATCH_10.20 (PHKL_12662) /usr/conf/lib/libhp-ux.a(ufs_dsort.o): ufs_dsort.c $Date: 98/08/19 10:42:05 $ $Revision: 1.20.98.11 $ PATCH_10.20 (PHKL_16207) /usr/conf/lib/libhp-ux.a(ufs_mchdep.o): ufs_mchdep.c $Date: 98/10/08 11:10:52 $ $Revision: 1 .18.98.9 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libhp-ux.a(ulbcopy.o): ulbcopy.s $Date: 98/03/03 16:51:57 $ $Revision: 1.4.98.9 $ PATCH_10.20 (PHKL_14321) /usr/conf/lib/libhp-ux.a(vfs.o): vfs.c $Date: 98/09/10 10:29:53 $ $Revision: 1.25.98. 16 $ PATCH_10.20 (PHKL_16387) /usr/conf/lib/libhp-ux.a(vfs_bio.o): vfs_bio.c $Date: 98/10/08 10:01:41 $ $Revision: 1.26 .98.28 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libhp-ux.a(vfs_dnlc.o): vfs_dnlc.c $Date: 98/01/13 00:22:28 $ $Revision: 1.1 8.98.4 $ PATCH_10.20 (PHKL_13795) /usr/conf/lib/libhp-ux.a(vfs_scalls.o): vfs_scalls.c $Date: 98/02/09 14:29:54 $ $Revision: 1.18.98.18 $ PATCH_10.20 (PHKL_14126) /usr/conf/lib/libhp-ux.a(vfs_vm.o): vfs_vm.c $Date: 97/10/15 14:57:20 $ $Revision: 1.17. 98.18 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libhp-ux.a(vfs_vnode.o): vfs_vnode.c $Date: 98/09/10 10:31:01 $ $Revision: 1. 14.98.9 $ PATCH_10.20 (PHKL_16387) /usr/conf/lib/libhp-ux.a(vm_fault.o): vm_fault.c $Date: 98/02/02 14:05:21 $ $Revision: 1.22.98.15 $ PATCH_10.20 (PHKL_14012) /usr/conf/lib/libhp-ux.a(vm_kern.o): vm_kern.c $Date: 97/05/20 15:19:14 $ $Revision: 1. 9.98.5 $ PATCH_10.20 (PHKL_11164) /usr/conf/lib/libhp-ux.a(vm_machdep.o): vm_machdep.c $Date: 98/04/28 15:06:18 $ $Revision: 1.157.98.35 $ PATCH_10.20 (PHKL_14955) /usr/conf/lib/libhp-ux.a(vm_machreg.o): vm_machreg.c $Date: 97/11/19 12:38:57 $ $Revision: 1 .17.98.22 $ PATCH_10.20 (PHKL_13260) /usr/conf/lib/libhp-ux.a(vm_mmap.o): vm_mmap.c $Date: 98/06/29 10:37:29 $ $Revision: 1.17.98.18 $ PATCH_10.20 (PHKL_15766) /usr/conf/lib/libhp-ux.a(vm_page.o): vm_page.c $Date: 98/02/02 14:05:23 $ $Revision: 1. 91.98.14 $ PATCH_10.20 (PHKL_14012) /usr/conf/lib/libhp-ux.a(vm_pdir1_1.o): vm_pdir1_1.c $Date: 97/05/02 02:00:37 $ $Revision: 1.3.98.14 $ PATCH_10.20 (PHKL_10757) /usr/conf/lib/libhp-ux.a(vm_pdir2_0.o): vm_pdir2_0.c $Date: 97/06/18 13:12:17 $ $Revision: 1 .3.98.11 $ PATCH_10.20 (PHKL_11408) /usr/conf/lib/libhp-ux.a(vm_pregion.o): vm_pregion.c $Date: 97/04/07 13:34:27 $ $Revision: 1.16.98.13 $ PATCH_10.20 (PHKL_10643) /usr/conf/lib/libhp-ux.a(vm_region.o): vm_region.c $Date: 96/11/20 11:01:58 $ $Revision: 1.20.98.4 $ PATCH_10.20 (PHKL_9075) /usr/conf/lib/libhp-ux.a(vm_sched.o): vm_sched.c $Date: 98/02/02 14:05:25 $ $Revision: 1.58.98.12 $ PATCH_10.20 (PHKL_14012) /usr/conf/lib/libhp-ux.a(vm_superpage.o): vm_superpage.c $Date: 98/03/18 17:20:25 $ $Revisi on: 1.2.98.7 $ PATCH_10.20 (PHKL_14490) /usr/conf/lib/libhp-ux.a(vm_text.o): vm_text.c $Date: 97/03/03 12:25:55 $ $Revision: 1 .56.98.9 $ PATCH_10.20 (PHKL_10257) /usr/conf/lib/libhp-ux.a(vm_vas.o): vm_vas.c $Date: 98/06/29 10:33:30 $ $Revision: 1.18.98.18 $ PATCH_10.20 (PHKL_15766) /usr/conf/lib/libhp-ux.a(vm_vhand.o): vm_vhand.c $Date: 98/02/02 14:05:27 $ $Revision: 1.20.98.7 $ PATCH_10.20 (PHKL_14012) /usr/conf/lib/libhp-ux.a(wsio_scsi.o): wsio_scsi.c $Date: 97/10/28 14:33:01 $ $Revision: 1.4.98.11 $ PATCH_10.20 (PHKL_13014) /usr/conf/lib/libhp-ux.a(wsio_util.o): wsio_util.c $Date: 96/11/25 13:25:20 $ $Revision: 1.7.98.3 $ PATCH_10.20 (PHKL_8908) /usr/conf/lib/liblvm.a(lv_block.o): lv_block.c $Date: 97/10/15 15:27:22 $ $Revision: 1.1 3.98.5 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_cluster_lock.o): lv_cluster_lock.c $Date: 97/10/15 15:27:47 $ $Revisi on: 1.10.98.5 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_defect.o): lv_defect.c $Date: 97/10/15 15:28:20 $ $Revision: 1. 16.98.6 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_hp.o): lv_hp.c $Date: 98/09/17 17:31:33 $ $Revision: 1.18.9 8.29 $ PATCH_10.20 (PHKL_16455) /usr/conf/lib/liblvm.a(lv_ioctls.o): lv_ioctls.c $Date: 98/04/07 15:45:30 $ $Revision: 1. 18.98.23 $ PATCH_10.20 (PHKL_14740) /usr/conf/lib/liblvm.a(lv_kdb.o): lv_kdb.c $Date: 97/10/15 17:16:54 $ $Revision: 1.9.9 8.4 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_lvsubr.o): lv_lvsubr.c $Date: 98/07/15 14:26:38 $ $Revision: 1. 15.98.18 $ PATCH_10.20 (PHKL_15942) /usr/conf/lib/liblvm.a(lv_malloc.o): lv_malloc.c $Date: 98/10/06 17:11:55 $ $Revision: 1. 11.98.7 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/liblvm.a(lv_mircons.o): lv_mircons.c $Date: 97/10/15 15:32:02 $ $Revision: 1 .14.98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_pbuf.o): lv_pbuf.c $Date: 97/10/15 15:32:20 $ $Revision: 1.11 .98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_phys.o): lv_phys.c $Date: 98/05/12 23:01:56 $ $Revision: 1.14 .98.14 $ PATCH_10.20 (PHKL_15199) /usr/conf/lib/liblvm.a(lv_schedule.o): lv_schedule.c $Date: 98/04/15 10:15:35 $ $Revision: 1.18.98.12 $ PATCH_10.20 (PHKL_14803) /usr/conf/lib/liblvm.a(lv_spare.o): lv_spare.c $Date: 98/05/12 23:02:00 $ $Revision: 1.3 .98.8 $ PATCH_10.20 (PHKL_15199) /usr/conf/lib/liblvm.a(lv_strategy.o): lv_strategy.c $Date: 98/08/19 10:42:51 $ $Revision: 1.14.98.11 $ PATCH_10.20 (PHKL_16207) /usr/conf/lib/liblvm.a(lv_stub.o): lv_stub.c $Date: 96/10/25 20:54:05 $ $Revision: 1.13 .98.2 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(lv_subr.o): lv_subr.c $Date: 97/10/15 15:33:47 $ $Revision: 1.18 .98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_syscalls.o): lv_syscalls.c $Date: 97/12/16 16:36:09 $ $Revision: 1.14.98.9 $ PATCH_10.20 (PHKL_13247) /usr/conf/lib/liblvm.a(lv_vgda.o): lv_vgda.c $Date: 97/10/15 15:34:41 $ $Revision: 1.18 .98.4 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(lv_vgsa.o): lv_vgsa.c $Date: 97/10/15 15:35:07 $ $Revision: 1.14 .98.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/liblvm.a(sh_vgsa.o): sh_vgsa.c $Date: 97/06/26 12:07:10 $ $Revision: 1.3 .98.9 $ PATCH_10.20 (PHKL_11561) /usr/conf/lib/liblvm.a(slvm_comm.o): slvm_comm.c $Date: 96/10/25 17:03:40 $ $Revision: 1. 3.98.4 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/liblvm.a(slvm_schedule.o): slvm_schedule.c $Date: 96/10/25 17:03:49 $ $Revision : 1.3.98.6 $ PATCH_10.20 (PHKL_8999) /usr/conf/lib/libpci.a(dino3.o): dino3.c $Date: 98/09/23 08:37:20 $ $Revision: 1.2.98.8 $ PATCH_10.20 (PHKL_16448) /usr/conf/lib/libpci.a(dino_cdio.o): dino_cdio.c $Date: 98/09/23 08:41:00 $ $Revision: 1.2.98.24 $ PATCH_10.20 (PHKL_16448) /usr/conf/lib/libpci.a(h2p_iface.o): h2p_iface.c $Date: 98/09/23 08:44:40 $ $Revision: 1.2.98.16 $ PATCH_10.20 (PHKL_16448) /usr/conf/lib/libpci.a(pci.o): pci.c $Date: 97/08/18 18:14:05 $ $Revision: 1.2.98.15 $ PATCH_10.20 (PHKL_11351) /usr/conf/lib/libpci.a(pci_cdio.o): pci_cdio.c $Date: 97/08/18 18:14:07 $ $Revision: 1.2.98.13 $ PATCH_10.20 (PHKL_11351) /usr/conf/lib/libpci.a(pci_wsio.o): pci_wsio.c $Date: 97/08/18 18:14:08 $ $Revision: 1.2.98.8 $ PATCH_10.20 (PHKL_11351) /usr/conf/lib/libprm.a(kern_fss.o): kern_fss.c $Date: 98/08/19 10:37:30 $ $Revision: 1.11.98.5 $ PATCH_10.20 (PHKL_16207) /usr/conf/lib/libufs.a(ufs_alloc.o): ufs_alloc.c $Date: 97/10/15 16:50:46 $ $Revision: 1. 38.98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libufs.a(ufs_inode.o): ufs_inode.c $Date: 98/10/07 07:39:41 $ $Revision: 1. 48.98.18 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libufs.a(ufs_vfsops.o): ufs_vfsops.c $Date: 98/05/27 18:03:49 $ $Revision: 1 .20.98.20 $ PATCH_10.20 (PHKL_15456) /usr/conf/lib/libufs.a(ufs_vnops.o): ufs_vnops.c $Date: 98/10/07 07:23:45 $ $Revision: 1. 30.98.25 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libvxfs_adv.a(vx_dio.o): vx_dio.c $Date: 98/09/09 13:30:33 $ $Revision: 1.7.98.14 $ PATCH_10.20 (PHKL_16387) /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o): vx_dmattr.c $Date: 97/10/15 15:06:19 $ $Revision: 1. 2.98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_adv.a(vx_full.o): vx_full.c $Date: 98/05/12 14:17:21 $ $Revision: 1.6. 98.9 $ PATCH_10.20 (PHKL_15244) /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o): vx_kdmi.c $Date: 98/06/03 07:17:24 $ $Revision: 1.2. 98.16 $ PATCH_10.20 (PHKL_15504) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o): vx_reorg.c $Date: 98/05/29 11:22:01 $ $Revision: 1.6 .98.16 $ PATCH_10.20 (PHKL_15321) /usr/conf/lib/libvxfs_adv.a(vx_sample_dmattr.o): vx_sample_dmattr.c $Date: 97/10/15 15:25:55 $ $Revis ion: 1.2.98.9 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_alloc.o): vx_alloc.c $Date: 97/10/15 14:58:22 $ $Revision: 1.5 .98.15 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_attr.o): vx_attr.c $Date: 98/06/25 15:59:57 $ $Revision: 1.7. 98.13 $ PATCH_10.20 (PHKL_15742) /usr/conf/lib/libvxfs_base.a(vx_bio.o): vx_bio.c $Date: 98/10/08 11:47:14 $ $Revision: 1.7.9 8.13 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libvxfs_base.a(vx_bio1.o): vx_bio1.c $Date: 98/10/08 11:43:19 $ $Revision: 1.7.98.10 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o): vx_bmapext4.c $Date: 98/05/29 11:21:29 $ $Revision: 1.2.98.14 $ PATCH_10.20 (PHKL_15321) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o): vx_bmaptyped.c $Date: 98/06/16 13:14:06 $ $Revision: 1.2.98.19 $ PATCH_10.20 (PHKL_15619) /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o): vx_bsdquota.c $Date: 98/01/06 13:13:40 $ $Revision: 1.7.98.15 $ PATCH_10.20 (PHKL_13713) /usr/conf/lib/libvxfs_base.a(vx_chain.o): vx_chain.c $Date: 98/10/08 11:51:22 $ $Revision: 1.7 .98.6 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libvxfs_base.a(vx_dirl.o): vx_dirl.c $Date: 98/06/25 16:02:08 $ $Revision: 1.7. 98.8 $ PATCH_10.20 (PHKL_15742) /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o): vx_dmstubs.c $Date: 98/06/03 07:02:57 $ $Revision: 1 .2.98.9 $ PATCH_10.20 (PHKL_15504) /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o): vx_fsetsubr.c $Date: 97/10/15 15:07:36 $ $Revision: 1.2.98.14 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o): vx_hpuxsubr.c $Date: 97/10/15 15:20:24 $ $Revision: 1.7.98.14 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_iflush.o): vx_iflush.c $Date: 97/10/15 15:19:38 $ $Revision: 1. 6.98.15 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_inode.o): vx_inode.c $Date: 97/10/15 15:20:59 $ $Revision: 1.7 .98.20 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_itrunc.o): vx_itrunc.c $Date: 97/10/15 15:22:10 $ $Revision: 1. 7.98.19 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_lite.o): vx_lite.c $Date: 97/10/15 15:23:00 $ $Revision: 1.4. 98.8 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_log.o): vx_log.c $Date: 97/10/15 15:24:16 $ $Revision: 1.6.9 8.7 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_mount.o): vx_mount.c $Date: 98/06/17 08:49:14 $ $Revision: 1.7 .98.21 $ PATCH_10.20 (PHKL_15619) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o): vx_rdwri.c $Date: 98/10/08 11:52:12 $ $Revision: 1.7 .98.27 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libvxfs_base.a(vx_replay.o): vx_replay.c $Date: 97/10/15 15:25:29 $ $Revision: 1. 2.98.14 $ PATCH_10.20 (PHKL_12901) /usr/conf/lib/libvxfs_base.a(vx_vfsops.o): vx_vfsops.c $Date: 97/12/11 01:03:47 $ $Revision: 1. 7.98.16 $ PATCH_10.20 (PHKL_13508) /usr/conf/lib/libvxfs_base.a(vx_vm.o): vx_vm.c $Date: 98/10/08 09:07:14 $ $Revision: 1.7.98 .18 $ PATCH_10.20 (PHKL_16592) /usr/conf/lib/libvxfs_base.a(vx_vnops.o): vx_vnops.c $Date: 98/06/25 15:56:40 $ $Revision: 1.8 .98.29 $ PATCH_10.20 (PHKL_15742) /usr/conf/machine/cpu.h: cpu.h $Date: 97/05/08 19:11:58 $ $Revision: 1.63.98. 5 $ PATCH_10.20 (PHKL_11002) /usr/conf/machine/reg.h: $Revision: 1.16.98.3 $ */ reg.h $Date: 97/11/18 12:00:25 $ $Revision: 1.16.98. 3 $ PATCH_10.20 (PHKL_13260) /usr/conf/master.d/core-hpux: core-hpux $Date: 98/06/29 10:28:11 $ $Revision: 1. 6.98.17 $ PATCH_10.20 (PHKL_15767) core-hpux $Date: 98/06/29 10:28:11 $ $Revision: 1. 6.98.17 $ PATCH_10.20 (PHKL_15766) /usr/conf/master.d/flkmgr: flkmgr $Date: 98/04/03 08:42:38 $ $Revision: 1 .1.98.5 $ PATCH_10.20 (PHKL_14685) /usr/conf/space.h.d/core-hpux.h: core-hpux.h $Date: 98/03/17 10:03:30 $ $Revision: 1.6.98.15 $ PATCH_10.20 (PHKL_14490) /usr/conf/space.h.d/flkmgr_globals.h: flkmgr_globals.h $Date: 98/02/02 14:03:23 $ $Revisio n: 1.1.98.3 $ PATCH_10.20 (PHKL_14012) /usr/conf/wsio/pci.h: pci.h $Date: 98/09/23 08:46:00 $ $Revision: 1.2.98.12 $ PATCH_10.20 (PHKL_16448) /usr/include/dmapi.h: dmapi.h: $Revision: 1.2.98.7 $ $Date: 97/09/02 13:03 :46 $ dmapi.h $Date: 97/09/02 13:03:46 $ $Revision: 1. 2.98.7 $ PATCH_10.20 (PHKL_12088) src/kernel/dmapi/dmapi.h 2.12 14 Aug 1996 18:51:12 - */ /usr/include/machine/cpu.h: cpu.h $Date: 97/05/08 19:11:58 $ $Revision: 1.63.98. 5 $ PATCH_10.20 (PHKL_11002) /usr/include/machine/reg.h: $Revision: 1.16.98.3 $ */ reg.h $Date: 97/11/18 12:00:25 $ $Revision: 1.16.98. 3 $ PATCH_10.20 (PHKL_13260) /usr/include/sys/audit.h: audit.h $Date: 97/04/21 13:54:38 $ $Revision: 1.10.98.5 $ PATCH_10.20 (PHKL_10800) /usr/include/sys/dma.h: dma.h $Date: 97/05/06 19:10:56 $ $Revision: 1.5.98.3 $ PATCH_10.20 (PHKL_11002) /usr/include/sys/dnlc.h: dnlc.h $Date: 97/09/02 15:03:34 $ $Revision: 1.4.98 .3 $ PATCH_10.20 (PHKL_12378) /usr/include/sys/fs/vx_hpux.h: vx_hpux.h: $Revision: 1.7.98.14 $ $Date: 97/09/03 09 :28:45 $ PATCH_10.20 (PHKL_12088) src/kernel/vxfs/vx_hpux.h 2.14.4.3 30 Jul 1996 17:05 :11 - */ fshp:src/kernel/vxfs/vx_hpux.h 2.14.4.3 /usr/include/sys/fss.h: fss.h $Date: 98/01/08 14:50:28 $ $Revision: 1.5.9 8.4 $ PATCH_10.20 (PHKL_12963) fss.h: $Revision: 1.5.98.4 $ $Date: 98/01/08 14:50:2 8 $ /usr/include/sys/mtio.h: mtio.h $Date: 98/08/06 14:02:42 $ $Revision: 1.24.98 .9 $ PATCH_10.20 (PHKL_15958) /usr/include/sys/pci.h: pci.h $Date: 98/09/23 08:46:00 $ $Revision: 1.2.98.12 $ PATCH_10.20 (PHKL_16448) cksum(1) Output: 1849128454 8068 /usr/conf/h/_flkmgr.h 309306691 13103 /usr/conf/h/audit.h 2131780918 1777 /usr/conf/h/dnlc.h 2593525881 3565 /usr/conf/h/fss.h 3190212322 27613 /usr/conf/h/mtio.h 3566042905 12864 /usr/conf/io/dma.h 1451119476 48724 /usr/conf/lib/libdmapi.a(kdm_core.o) 3851147702 1784 /usr/conf/lib/libdmapi.a(vx_dmattr_table.o) 2511412796 4964 /usr/conf/lib/libhp-ux.a(asm_rdb.o) 538984117 20076 /usr/conf/lib/libhp-ux.a(asm_rv.o) 3109290296 7640 /usr/conf/lib/libhp-ux.a(asm_scall.o) 1231112847 18512 /usr/conf/lib/libhp-ux.a(asm_utl.o) 1918067463 19548 /usr/conf/lib/libhp-ux.a(asm_vm.o) 1650397953 4584 /usr/conf/lib/libhp-ux.a(asm_vm_pdir.o) 1908120037 11228 /usr/conf/lib/libhp-ux.a(audctl.o) 3455675956 4668 /usr/conf/lib/libhp-ux.a(bcopy.o) 4158269677 10276 /usr/conf/lib/libhp-ux.a(btlb.o) 4124458617 2432 /usr/conf/lib/libhp-ux.a(bzero.o) 1633864303 19912 /usr/conf/lib/libhp-ux.a(clock.o) 4114346575 11604 /usr/conf/lib/libhp-ux.a(cpd.o) 2951764362 12648 /usr/conf/lib/libhp-ux.a(dma_A.o) 323304034 7068 /usr/conf/lib/libhp-ux.a(dma_s700.o) 797819625 12752 /usr/conf/lib/libhp-ux.a(dump.o) 2563226503 9368 /usr/conf/lib/libhp-ux.a(dump_conf.o) 1042418826 31496 /usr/conf/lib/libhp-ux.a(eisa.o) 1084924137 8028 /usr/conf/lib/libhp-ux.a(flipper.o) 3521987937 75560 /usr/conf/lib/libhp-ux.a(flkmgr.o) 1503982196 3176 /usr/conf/lib/libhp-ux.a(flkmgr_dom.o) 3192008703 7148 /usr/conf/lib/libhp-ux.a(flkmgr_flk.o) 3027257443 3240 /usr/conf/lib/libhp-ux.a(flkmgr_hp.o) 3675135296 8552 /usr/conf/lib/libhp-ux.a(flkmgr_main.o) 2389894881 3120 /usr/conf/lib/libhp-ux.a(flkmgr_mm.o) 185498796 4696 /usr/conf/lib/libhp-ux.a(flkmgr_pm.o) 4241057848 1128 /usr/conf/lib/libhp-ux.a(fssdefault.o) 1212432086 12488 /usr/conf/lib/libhp-ux.a(gio_node.o) 293557175 13616 /usr/conf/lib/libhp-ux.a(hdl_fault.o) 555026448 6348 /usr/conf/lib/libhp-ux.a(hdl_init.o) 4283888750 15772 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 3413061668 12268 /usr/conf/lib/libhp-ux.a(hdl_policy.o) 367858484 10748 /usr/conf/lib/libhp-ux.a(hdl_trans.o) 4071729428 18580 /usr/conf/lib/libhp-ux.a(init_main.o) 3476683986 6584 /usr/conf/lib/libhp-ux.a(interrupt.o) 166564594 161448 /usr/conf/lib/libhp-ux.a(io.o) 2235177246 7356 /usr/conf/lib/libhp-ux.a(ios_int.o) 4020459163 6044 /usr/conf/lib/libhp-ux.a(ios_mem.o) 1062453135 5180 /usr/conf/lib/libhp-ux.a(kern_acct.o) 188265620 16884 /usr/conf/lib/libhp-ux.a(kern_exec.o) 2229502215 17528 /usr/conf/lib/libhp-ux.a(kern_exit.o) 3691736042 16348 /usr/conf/lib/libhp-ux.a(kern_fork.o) 50317043 6492 /usr/conf/lib/libhp-ux.a(kern_kload.o) 4163060998 3948 /usr/conf/lib/libhp-ux.a(kern_mman.o) 2216617969 10284 /usr/conf/lib/libhp-ux.a(kern_sig.o) 3276898957 6160 /usr/conf/lib/libhp-ux.a(lbcopy.o) 300166288 2428 /usr/conf/lib/libhp-ux.a(lbzero.o) 836431959 5384 /usr/conf/lib/libhp-ux.a(lo_subr.o) 467807125 3232 /usr/conf/lib/libhp-ux.a(lo_vfsops.o) 3349625708 6328 /usr/conf/lib/libhp-ux.a(lo_vnops.o) 375116173 27576 /usr/conf/lib/libhp-ux.a(lv_config.o) 1237596189 156552 /usr/conf/lib/libhp-ux.a(lv_lvm.o) 228543399 7008 /usr/conf/lib/libhp-ux.a(lw_scall.o) 2111739438 30444 /usr/conf/lib/libhp-ux.a(machdep.o) 2457463992 3348 /usr/conf/lib/libhp-ux.a(outlaw.o) 2313204930 13612 /usr/conf/lib/libhp-ux.a(pa_ccio.o) 2349558433 13896 /usr/conf/lib/libhp-ux.a(pa_cdio.o) 696264367 27604 /usr/conf/lib/libhp-ux.a(pa_lvl1.o) 281897050 3996 /usr/conf/lib/libhp-ux.a(pa_map.o) 2162951061 41216 /usr/conf/lib/libhp-ux.a(pci_debug.o) 3029803182 2988 /usr/conf/lib/libhp-ux.a(pgcopy.o) 807433184 6308 /usr/conf/lib/libhp-ux.a(pm_clockint.o) 1701549902 5388 /usr/conf/lib/libhp-ux.a(pm_config.o) 2056113258 2288 /usr/conf/lib/libhp-ux.a(pm_context.o) 3785773729 6872 /usr/conf/lib/libhp-ux.a(pm_core.o) 2304745347 2580 /usr/conf/lib/libhp-ux.a(pm_getpid.o) 1855111803 16844 /usr/conf/lib/libhp-ux.a(pm_policy.o) 3933929381 17908 /usr/conf/lib/libhp-ux.a(pm_proc.o) 2742363982 6684 /usr/conf/lib/libhp-ux.a(pm_procdup.o) 3682830469 15732 /usr/conf/lib/libhp-ux.a(pm_ptrace.o) 775863340 7076 /usr/conf/lib/libhp-ux.a(pm_resource.o) 4277200061 8728 /usr/conf/lib/libhp-ux.a(pm_rtsched.o) 1066734922 16212 /usr/conf/lib/libhp-ux.a(pm_sendsig.o) 4157339108 11544 /usr/conf/lib/libhp-ux.a(pm_signal.o) 595786367 20532 /usr/conf/lib/libhp-ux.a(pm_swtch.o) 3233056101 12032 /usr/conf/lib/libhp-ux.a(pm_threads.o) 2471577768 6504 /usr/conf/lib/libhp-ux.a(pm_timers.o) 18384036 11264 /usr/conf/lib/libhp-ux.a(protection.o) 2330409141 24000 /usr/conf/lib/libhp-ux.a(pstat.o) 2850536296 14180 /usr/conf/lib/libhp-ux.a(rdb.o) 2324711003 9800 /usr/conf/lib/libhp-ux.a(rdb_boot.o) 663993736 21760 /usr/conf/lib/libhp-ux.a(rdb_com.o) 2940774876 5092 /usr/conf/lib/libhp-ux.a(rdb_com_lan.o) 3321754238 27220 /usr/conf/lib/libhp-ux.a(rdb_lan.o) 451010056 7204 /usr/conf/lib/libhp-ux.a(rdb_mp.o) 3840625382 7680 /usr/conf/lib/libhp-ux.a(rdb_rs232.o) 2317800830 3876 /usr/conf/lib/libhp-ux.a(resume.o) 3058948610 94732 /usr/conf/lib/libhp-ux.a(scsi_c720.o) 2684729118 68168 /usr/conf/lib/libhp-ux.a(scsi_ctl.o) 682760257 18416 /usr/conf/lib/libhp-ux.a(scsi_disk.o) 577714161 68604 /usr/conf/lib/libhp-ux.a(scsi_tape.o) 3665684469 9532 /usr/conf/lib/libhp-ux.a(sem_alpha.o) 4260670581 16992 /usr/conf/lib/libhp-ux.a(spec_vnops.o) 1179856871 18256 /usr/conf/lib/libhp-ux.a(spinlock.o) 3306390220 10616 /usr/conf/lib/libhp-ux.a(subr_ksleep.o) 720343113 4780 /usr/conf/lib/libhp-ux.a(subr_rmap.o) 1319709682 10572 /usr/conf/lib/libhp-ux.a(subr_timers.o) 925297696 8712 /usr/conf/lib/libhp-ux.a(sysV_shm.o) 1671896846 23616 /usr/conf/lib/libhp-ux.a(trap.o) 3152086064 9324 /usr/conf/lib/libhp-ux.a(ufs_dsort.o) 3864695637 10412 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) 3495714284 6340 /usr/conf/lib/libhp-ux.a(ulbcopy.o) 828983413 20444 /usr/conf/lib/libhp-ux.a(vfs.o) 3195824475 29208 /usr/conf/lib/libhp-ux.a(vfs_bio.o) 3897607434 8616 /usr/conf/lib/libhp-ux.a(vfs_dnlc.o) 2911854326 31728 /usr/conf/lib/libhp-ux.a(vfs_scalls.o) 1439345029 29828 /usr/conf/lib/libhp-ux.a(vfs_vm.o) 542412519 8916 /usr/conf/lib/libhp-ux.a(vfs_vnode.o) 482152261 13384 /usr/conf/lib/libhp-ux.a(vm_fault.o) 1473182150 10480 /usr/conf/lib/libhp-ux.a(vm_kern.o) 3414221232 92520 /usr/conf/lib/libhp-ux.a(vm_machdep.o) 2851321488 15524 /usr/conf/lib/libhp-ux.a(vm_machreg.o) 3464223822 21772 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 2208932717 21312 /usr/conf/lib/libhp-ux.a(vm_page.o) 290807052 30900 /usr/conf/lib/libhp-ux.a(vm_pdir1_1.o) 1469266556 53368 /usr/conf/lib/libhp-ux.a(vm_pdir2_0.o) 1265397058 12324 /usr/conf/lib/libhp-ux.a(vm_pregion.o) 1266053234 11316 /usr/conf/lib/libhp-ux.a(vm_region.o) 692138061 25108 /usr/conf/lib/libhp-ux.a(vm_sched.o) 1800879851 10040 /usr/conf/lib/libhp-ux.a(vm_superpage.o) 2800961341 14444 /usr/conf/lib/libhp-ux.a(vm_text.o) 1082360142 13360 /usr/conf/lib/libhp-ux.a(vm_vas.o) 1688897665 14904 /usr/conf/lib/libhp-ux.a(vm_vhand.o) 3695121161 155156 /usr/conf/lib/libhp-ux.a(wsio_scsi.o) 4161920378 13056 /usr/conf/lib/libhp-ux.a(wsio_util.o) 2971522811 2632 /usr/conf/lib/liblvm.a(lv_block.o) 303437109 9964 /usr/conf/lib/liblvm.a(lv_cluster_lock.o) 1367795889 12596 /usr/conf/lib/liblvm.a(lv_defect.o) 1061125469 86696 /usr/conf/lib/liblvm.a(lv_hp.o) 1045412530 32344 /usr/conf/lib/liblvm.a(lv_ioctls.o) 872237003 720 /usr/conf/lib/liblvm.a(lv_kdb.o) 1195416235 36256 /usr/conf/lib/liblvm.a(lv_lvsubr.o) 2586929976 2556 /usr/conf/lib/liblvm.a(lv_malloc.o) 4288668251 17420 /usr/conf/lib/liblvm.a(lv_mircons.o) 2331070456 6576 /usr/conf/lib/liblvm.a(lv_pbuf.o) 935944161 7736 /usr/conf/lib/liblvm.a(lv_phys.o) 3075337331 26432 /usr/conf/lib/liblvm.a(lv_schedule.o) 2177231832 36452 /usr/conf/lib/liblvm.a(lv_spare.o) 3311834588 7492 /usr/conf/lib/liblvm.a(lv_strategy.o) 4115391771 732 /usr/conf/lib/liblvm.a(lv_stub.o) 2518086102 10064 /usr/conf/lib/liblvm.a(lv_subr.o) 1101210836 13616 /usr/conf/lib/liblvm.a(lv_syscalls.o) 1382667354 9108 /usr/conf/lib/liblvm.a(lv_vgda.o) 3655615117 12600 /usr/conf/lib/liblvm.a(lv_vgsa.o) 58167558 42028 /usr/conf/lib/liblvm.a(sh_vgsa.o) 2159002800 27264 /usr/conf/lib/liblvm.a(slvm_comm.o) 4188283521 6724 /usr/conf/lib/liblvm.a(slvm_schedule.o) 1533599182 8604 /usr/conf/lib/libpci.a(dino3.o) 208772585 16236 /usr/conf/lib/libpci.a(dino_cdio.o) 4190077333 8244 /usr/conf/lib/libpci.a(h2p_iface.o) 2851050442 1768 /usr/conf/lib/libpci.a(pci.o) 1073337950 6604 /usr/conf/lib/libpci.a(pci_cdio.o) 2702080507 3820 /usr/conf/lib/libpci.a(pci_wsio.o) 1586356643 13712 /usr/conf/lib/libprm.a(kern_fss.o) 2981279314 17624 /usr/conf/lib/libufs.a(ufs_alloc.o) 4139364884 26036 /usr/conf/lib/libufs.a(ufs_inode.o) 406046960 20668 /usr/conf/lib/libufs.a(ufs_vfsops.o) 2352076973 35712 /usr/conf/lib/libufs.a(ufs_vnops.o) 1972749739 12676 /usr/conf/lib/libvxfs_adv.a(vx_dio.o) 760609908 2964 /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o) 4053300385 14556 /usr/conf/lib/libvxfs_adv.a(vx_full.o) 3426082237 25552 /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o) 436037388 20648 /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) 3582414206 4592 /usr/conf/lib/ libvxfs_adv.a(vx_sample_dmattr.o) 3334723579 28228 /usr/conf/lib/libvxfs_base.a(vx_alloc.o) 4153949569 37176 /usr/conf/lib/libvxfs_base.a(vx_attr.o) 1386352101 10676 /usr/conf/lib/libvxfs_base.a(vx_bio.o) 1893615244 6964 /usr/conf/lib/libvxfs_base.a(vx_bio1.o) 872249187 10900 /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o) 2360343670 18344 /usr/conf/lib/ libvxfs_base.a(vx_bmaptyped.o) 3341046136 29164 /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o) 3735105051 5208 /usr/conf/lib/libvxfs_base.a(vx_chain.o) 1109698200 11932 /usr/conf/lib/libvxfs_base.a(vx_dirl.o) 2896780437 5032 /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o) 2357795855 21168 /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) 1502964316 16292 /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o) 3531998086 29724 /usr/conf/lib/libvxfs_base.a(vx_iflush.o) 347435613 44852 /usr/conf/lib/libvxfs_base.a(vx_inode.o) 1839120165 14412 /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) 1857910709 3600 /usr/conf/lib/libvxfs_base.a(vx_lite.o) 945378166 9620 /usr/conf/lib/libvxfs_base.a(vx_log.o) 1261948937 28356 /usr/conf/lib/libvxfs_base.a(vx_mount.o) 3973202090 35496 /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) 1686960615 7052 /usr/conf/lib/libvxfs_base.a(vx_replay.o) 2409040095 15220 /usr/conf/lib/libvxfs_base.a(vx_vfsops.o) 2653780402 12720 /usr/conf/lib/libvxfs_base.a(vx_vm.o) 2307326129 26876 /usr/conf/lib/libvxfs_base.a(vx_vnops.o) 929303060 25859 /usr/conf/machine/cpu.h 2426350973 5075 /usr/conf/machine/reg.h 983896488 17246 /usr/conf/master.d/core-hpux 425791205 5474 /usr/conf/master.d/flkmgr 2799878239 19242 /usr/conf/space.h.d/core-hpux.h 1447084439 1119 /usr/conf/space.h.d/flkmgr_globals.h 872104067 24895 /usr/conf/wsio/pci.h 1315928410 16548 /usr/include/dmapi.h 929303060 25859 /usr/include/machine/cpu.h 2426350973 5075 /usr/include/machine/reg.h 309306691 13103 /usr/include/sys/audit.h 3566042905 12864 /usr/include/sys/dma.h 2131780918 1777 /usr/include/sys/dnlc.h 1556434298 9724 /usr/include/sys/fs/vx_hpux.h 2593525881 3565 /usr/include/sys/fss.h 3190212322 27613 /usr/include/sys/mtio.h 872104067 24895 /usr/include/sys/pci.h Patch Conflicts: None Patch Dependencies: s700: 10.20: PHCO_12922 PHCO_8871 PHNE_13245 Hardware Dependencies: None Other Dependencies: A3308A FC-SCSI muxes connected to the system must have at least firmware revision 3810. Please be advised that a savecore(1M) patch (PHCO_12822) may be needed to enable savecore to correctly handle a dump area that extends beyond the 2GB offset on the disk. Supersedes: PHKL_7763 PHKL_7776 PHKL_7870 PHKL_7899 PHKL_7951 PHKL_7967 PHKL_7987 PHKL_8028 PHKL_8084 PHKL_8128 PHKL_8187 PHKL_8203 PHKL_8294 PHKL_8331 PHKL_8346 PHKL_8388 PHKL_8481 PHKL_8506 PHKL_8532 PHKL_8683 PHKL_8716 PHKL_8735 PHKL_8755 PHKL_8908 PHKL_8953 PHKL_8999 PHKL_9075 PHKL_9151 PHKL_9153 PHKL_9273 PHKL_9361 PHKL_9365 PHKL_9370 PHKL_9372 PHKL_9415 PHKL_9517 PHKL_9529 PHKL_9569 PHKL_9711 PHKL_9909 PHKL_9919 PHKL_9931 PHKL_9965 PHKL_10064 PHKL_10176 PHKL_10199 PHKL_10234 PHKL_10257 PHKL_10288 PHKL_10316 PHKL_10421 PHKL_10452 PHKL_10554 PHKL_10643 PHKL_10675 PHKL_10689 PHKL_10755 PHKL_10756 PHKL_10757 PHKL_10769 PHKL_10800 PHKL_10821 PHKL_10930 PHKL_10932 PHKL_10953 PHKL_10966 PHKL_11002 PHKL_11006 PHKL_11013 PHKL_11039 PHKL_11055 PHKL_11085 PHKL_11164 PHKL_11238 PHKL_11244 PHKL_11247 PHKL_11316 PHKL_11321 PHKL_11332 PHKL_11339 PHKL_11351 PHKL_11358 PHKL_11406 PHKL_11408 PHKL_11471 PHKL_11519 PHKL_11545 PHKL_11561 PHKL_11607 PHKL_11614 PHKL_11632 PHKL_11637 PHKL_11696 PHKL_11730 PHKL_11733 PHKL_11766 PHKL_11860 PHKL_11902 PHKL_12042 PHKL_12073 PHKL_12088 PHKL_12100 PHKL_12110 PHKL_12217 PHKL_12306 PHKL_12378 PHKL_12397 PHKL_12409 PHKL_12601 PHKL_12633 PHKL_12660 PHKL_12662 PHKL_12669 PHKL_12901 PHKL_12945 PHKL_12963 PHKL_12997 PHKL_13014 PHKL_13155 PHKL_13206 PHKL_13237 PHKL_13247 PHKL_13260 PHKL_13305 PHKL_13452 PHKL_13508 PHKL_13514 PHKL_13572 PHKL_13680 PHKL_13684 PHKL_13713 PHKL_13744 PHKL_13761 PHKL_13768 PHKL_13795 PHKL_13868 PHKL_13874 PHKL_13911 PHKL_13986 PHKL_14009 PHKL_14012 PHKL_14049 PHKL_14126 PHKL_14183 PHKL_14225 PHKL_14321 PHKL_14323 PHKL_14490 PHKL_14568 PHKL_14613 PHKL_14685 PHKL_14740 PHKL_14803 PHKL_14856 PHKL_14917 PHKL_14953 PHKL_14955 PHKL_15057 PHKL_15081 PHKL_15085 PHKL_15145 PHKL_15199 PHKL_15244 PHKL_15321 PHKL_15456 PHKL_15478 PHKL_15492 PHKL_15495 PHKL_15504 PHKL_15598 PHKL_15619 PHKL_15742 PHKL_15766 PHKL_15787 PHKL_15800 PHKL_15915 PHKL_15942 PHKL_15958 PHKL_16207 PHKL_16387 PHKL_16448 PHKL_16455 PHKL_16592 Equivalent Patches: None Patch Package Size: 3880 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_16730 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_16730.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_16730.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_16730. 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_16730.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_16730.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: - SR: 5003387407, DDTS: JAGaa00919 introduces two global variables: vx_enospace_factor vx_nwriters These variables control when DMAPI ENOSPACE events are generated. 'vx_enospace_factor' is the fraction of the filesystem below which we start checking write requests to see if they exceed available space. So a 'vx_enospace_factor' of 20 (default) means that no pessimistic ENOSPACE events will be checked until less than 1/20th of the filesystem is free. So, the smaller 'vx_enospace_factor', the earlier checking is done on a filesystem. Note that if 'vx_enospace_factor' is set to less than or equal to zero, the default value of 20 will be used. 'vx_nwriters' is the fraction of space left that a write must exceed to trigger a pessimistic ENOSPACE. If 'vx_nwriters' is 8, which is the default, then the size of a write must be greater than 1/8th the blocks free to trigger an ENOSPACE. So, the larger 'vx_nwriters' is, the more space will be left on the filesystem when we get the ENOSPACE event. Note that if 'vx_nwriters' is set to less than or equal to zero, the default value of 8 will be used. You can use 'adb' to set and check the values of these variables. For example, to set 'vx_nwriters' to 32 decimal: echo 'vx_nwriters/W 20'|adb -w /stand/vmunix /dev/kmem To read the value of the variable in decimal: echo 'vx_nwriters/D'|adb /stand/vmunix /dev/kmem ----- The global variable (flag) `use_bestfit' determines what allocation policy will be used. The default setting of this flag is 0, resulting in first-fit being used for all allocations for shared virtual addresses. To enable the system to use best-fit, this flag (use_bestfit) must be set to a non-zero value (say 1) using `adb.' The value can be set/reset at any time during system operation. The policy that will be used is based on the current value of this flag. ---- The patch is applied to the kernel being debugged on the target machine, not the host machine where the debugger is run. ---- - SR: 4701382564, DTS: DSDe441726 Two tunable variables have been defined for this patch. They are: kern_vm_pct - the threshold percentage. When the free sysmap space as a percentage of 1 GB falls below the value of kern_vm_pct, warning message is printed to notify the user of this condition. kern_vm_scan_rate - the time interval in seconds between subsequent checks that statdaemon makes to determine if the free kernel sysmap space as a percentage of 1GB is below the threshold percentage (kern_vm_pct) value or not; if below the threshold value print the warning message about the condition. By default both kern_vm_pct and kern_vm_scan_rate are set to 0 ie. by default the monitoring of the free kernel sysmap space is turned off. To turn on the feature you need to set kern_vm_scan_rate and kern_vm_pct variables to non zero value. eg. In file /stand/system * Tunable parameters kern_vm_pct 10 kern_vm_scan_rate 10 Threshold percentage is 10%; scan rate is 10 seconds. ---- CAUTION: Failure to follow the instructions in this section could result in undesired system behavior up to and including data corruption or a system panic! This kernel patch need to work with the command patch PHCO_12922; please install PHCO_12922 with this patch. Installed alone, this kernel patch will not solve the fsck problem. --- If you are planning to install the advanced VxFS product (AdvJournalFS.VXFS-ADV-KRN), it is imperative that this patch, and all listed superseded patches, be removed from the system via swremove(1M) before the actual product installation. After the installation of the advanced VxFS product has completed, this patch can be re-installed. (It is not necessary to re-install superseded patches.) All patches listed in the Supersedes field are subject to this behavior and need to be removed before installing the advanced VxFS product. After running swremove(1M), use the swlist(1M) command to insure that none of the previous patches were restored during the removal process. If one was, remove it using swremove(1M). --- When this patch is installed the default environment size is 20478 bytes. To enable the system to use the larger environment size of 2048000 bytes, the following steps must be followed. 1. A new tunable called `large_ncargs_enabled' must be defined in the sytem file in the following manner large_ncargs_enabled 1 2. A new kernel must be built (using this system file) and the system rebooted. To return to the default environment size, the new tunable needs to be either removed from the system file, or its value set to zero. A new kernel should then be built (using the modified system file) and the machine rebooted. --- Due to the number of objects in this patch, the customization phase of the update may take more than 10 minutes. During that time the system will not appear to make forward progress, but it will actually be installing the objects.