Patch Name: PHKL_9148 Patch Description: s700 9.01 SCSI, NFS, DUX, VM, graphics, HIL megapatch Creation Date: 96/11/06 Post Date: 96/11/06 Hardware Platforms - OS Releases: s700: 9.01 Products: N/A Filesets: KERN-BLD NFS-INC NFS-RUN Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_9148: PANIC PHKL_5357: HANG PHKL_4968: PANIC PHKL_4942: PANIC PHKL_4935: PANIC PHKL_4776: HANG PHKL_4728: PANIC PHKL_4506: PANIC PHKL_4246: PANIC PHKL_4222: HANG PHKL_4193: MEMORY_LEAK PHKL_4184: CORRUPTION PHKL_4157: PANIC PHKL_4046: PANIC PHKL_3551: PANIC PHKL_3477: PANIC PHKL_3468: PANIC PHKL_3418: PANIC PHKL_3386: PANIC PHKL_3358: PANIC PHKL_3343: CORRUPTION PHKL_3286: PANIC PHKL_3216: PANIC PHKL_3155: CORRUPTION PHKL_3117: CORRUPTION PHKL_3087: PANIC PHKL_2853: CORRUPTION PHKL_2828: PANIC PHKL_2762: HANG PHKL_2584: PANIC PHKL_2393: PANIC Path Name: /hp-ux_patches/s700/9.X/PHKL_9148 Symptoms: PHKL_9148: panic "bread: size 0" when using MMAP files on DUX. PHKL_6759: Several types of symptoms may occur: - logins on NFS clients may receive incorrect access on NFS servers - files from NFS servers may appear to be owned by the wrong logins on NFS clients - setuid and setgid binaries available on NFS servers may allow client logins to run with incorrect access PHKL_6049: rpc.lockd timers are too agressive, causing NFS lock timeouts on busy networks PHKL_5993: Going over disk quota on an NFS-mounted filesystem causes erroneous "file system full" messages on the client console PHKL_5357: System hangs. The SRUN process kernel stack will have release_buffer, brelse, bmap, rwip, ufs_rdwr, vno_rw, rwuio. PHKL_5077: None. PHKL_4968: vfork_transfer entered in bad state panic PHKL_4942: panic: "bread: size 0" when using named pipes on DUX PHKL_4935: panic: Data segmentation fault, in function openforwrite() PHKL_4932: writing to full file system succeeds incorrectly PHKL_4776: system hangs when running xdb on an NFS file PHKL_4728: panic: DMEM protection fault in ki_data() or ki_accum_push_TOS() PHKL_4607: access(2) system call takes too long when executed over NFS PHKL_4506: panic: virtual_fault: on DBD_None page while running xdb PHKL_4246: panic when debugging an NFS mounted file and another process modifies the text PHKL_4222: vslock() fails when it is interrupted by signals PHKL_4193: NFS has a memory leak PHKL_4184: disk buffers are lost if process doing I/O from disk to shm is signalled PHKL_4165: complete solution started in PHKL_2283 PHKL_4157: backing out the fix for PHKL_4031 PHKL_4046: panic on systems with automount & PHKL_3974 PHKL_4031: supersede PHKL_3985 PHKL_3985: increase HOSTNAMESZ to 256 to allow domain names greater than 32 characters PHKL_3974: problems for readdir and seekdir library calls over NFS PHKL_3569: mmap can't fix address in private data space with MAP_SHARED PHKL_3551: "panic: freeing free inode" on DUX servers. PHKL_3550: Force hpux_aes_override to always be on. PHKL_3477: panic: data segmentation fault in pdprotget(). PHKL_3468: panic "findentry: idx beyond region size" PHKL_3446: Binaries not updated on UFS/NFS. PHKL_3418: panic: csysmemreserve: reservation overrun PHKL_3386: panic: csysmemreserve: reservation overrun PHKL_3358: panic: crfree: credential reference overflow PHKL_3352: syncer performance problems with huge buffer caches PHKL_3343: spontaneous data corruption on 2K executables PHKL_3286: panics in sync_indirect with PHKL_3155 PHKL_3216: Data segmentation fault if vfork() while the proc table full PHKL_3209: changes to support page disclaim using the madvise() call PHKL_3205: Read failures on NFS file when server disk is full PHKL_3155: fsync(2) followed by crash showed data loss PHKL_3149: misleading message printed when comparing function pointers PHKL_3117: NFS data loss with duplicate CREATE requests PHKL_3087: panic cmemreserve: reservation overrun PHKL_3028: Memory Mapped File Tuning to improve performance PHKL_2853: NFS data corruption or premature/incorrect EOF PHKL_2847: Memory Mapped File Tuning to improve performance PHKL_2844: Error writing file from PC-NFS client to HP-UX server PHKL_2836: EACCES when two processes are using the same file over NFS PHKL_2828: fixes various bugs in memory-mapped files panic: DBD_HOLE in non-MMF region "panic: trap type 15" using mprotect() PHKL_2788: slow performance throughput on NFS PHKL_2762: system hang with AFS and low free memory PHKL_2584: data segmentation fault panic in dircheckwithsdo() when using PC-NFS clients PHKL_2476: intermittent EACCES errors across NFS PHKL_2462: Two new PTRACE requests added. PHKL_2393: 2K-aligned executables could cause process hangs and "grow: no stack region" panics. PHKL_2283: swap text on local swap device if sticky bit is set PHKL_1989: NFS megapatch Defect Description: PHKL_9148: System doesn't correctly handle resized MMAP regions accessed over DUX. The test for changed file size was modified to correctly handle this case. PHKL_6759: A future HP-UX release will increase the value of MAXUID, providing for a greater range of valid UIDs and GIDs. It will also introduce problems in mixed-mode NFS environments. Let "LUID" specify a machine running a version of HP-UX with large-UID capability. Let "SUID" specify a machine with current small-UID capability. The following problems may occur: LUID client, SUID server - A previous patch (PHKL_5079) makes client logins with UIDs outside the server's range appear as the anonymous user. However, the anonymous user UID is configurable, and is sometimes configured as the root user (in order to "trust" all client root logins without large-scale modifications to the /etc/exports file). Thus, all logins with large UIDs on the client could be mapped to root on the server. - If this previous patch has not been applied, files created by logins with large UIDs on the client will have the wrong UID on the server. This could be exploited by particular UIDs to gain root access on the server. - Files owned by the nobody user on the server will appear to be owned by the wrong user on the client. SUID client, LUID server - Files owned by large-UID logins on the server will appear to be owned by the wrong user on the client. - Executables with the setuid or setgid mode turned on will allow logins on the client to run as the wrong users. PHKL_6049: The timers used by the client side portion of rpc.lockd are too aggressive. These timers control the amount of time the client rpc.lockd will wait before retrying locks that are still in progress (i.e., blocked). The timers were originally made more aggressive in response to concerns about slow NFS lock performance; since that time, rpc.lockd has been changed to address the same performance concerns, but in a different fashion. Thus, this patch should be installed with PHNE_5460 or any of its successors to maintain NFS lock performance. PHKL_5993: Filesystem full messages are displayed on the console and in /etc/dmesg output when the filesystem is not full. The filesystem in question is NFS mounted from another system and has quotas enabled on the server. The message occurs when a user reaches the hard limit on the mounted directory. This is caused by HP-UX mapping the EDQUOT error returned by the server to the error ENOSPC. This is later interpreted as a file system full condition, and gets printed to the client's console. The fix was to remove the mapping. With this patch installed, the user will see no console errors when they exceed their quota, and the error on their terminal will be "Disk quota exceeded". PHKL_5357: In alloc_more_headers and getnewbuf, toppriority was being incremented without checking to see if MAXPRIORITY was exceeded. This was causing hangs in the while loop in release_buffer because the buf field access_cnt is calculated from toppriority which could get up over 0x10000000. See SR or DTS for reproduction method. PHKL_5077: Check nfs uid against MAXUID. PHKL_4968: Reset p_vforkbuf before we could sleep in copytopreg. Else, we could sleep, the vforked child could exit, the parent would resume with a non-zero p_vforkbuf with VFORK_BAD. And then we'd panic with vfork_transfer entered in bad state PHKL_4942: This patch fixes a panic when using named pipes on DUX. This happens due to a race condition between the close and the open of a named pipe. This race condition leaves the inode size as zero but the fifosize as non-zero. So the process which does a read thinks that there is data in the pipe to read but the inode size is zero and so the bread panics with the message "bread: size 0". PHKL_4935: Under certain circumstances, the kernel would panic with a data segmentation fault, in the function openforwrite(). Openforwrite() was not locking the vnode associated with the file it was checking, which led to inconsistencies between the vnode flags and internal fields. There were no obvious reproduction methods. PHKL_4932: Return u.u_error when writing to full file system. PHKL_4776: Fix for PHKL_4506. Release the region lock in fault_each() for the case when we fail to bring_in_pages(). In PHKL_4506, we were returning without releasing the region lock acquired earlier. Strange things can happen (including system hangs) in the special situation when a user does xdb on an NFS file (this ensures that the path ptrace()->pre_demand_load() is taken) in a heavily loaded (heavy load means bring_in_pages will fail) system. PHKL_4728: When running Glance/UX or other performance monitoring products, the system can panic after a failed vfork() system call, with a DMEM protection fault in the function ki_data() or ki_accum_push_TOS(). Having the vfork() system call fail while running system instrumentation software, such as Glance/UX, could cause the kernel to leave stale data in a process slot (ie, the proc table). When that process slot is reused, the stale data is misinterpreted, causing a kernel instrumentation data structure to go out of range, leading to data corruption and eventual panic. The fix removes the stale data from the process slot, even if the vfork() system call failed. PHKL_4607: This patch fixes a performance problem with the access(2) system call when executed across NFS. Without the patch, access does not make proper use of the client's caches; therefore, it generates unnecessary requests to the server. This is very obvious when running access(2) in a tight loop using a single file as the argument. One would expect the first call to generate a request to the server and any subsequent calls to use the client's cache, but this would not be the case. The patch fixes this problem and allows the client to use its cache and avoid the unnecessary requests. PHKL_4506: panic: virtual_fault: on DBD_None page while running xdb The failure was caused due to an error in fault_each() while bringing pages into memory. However, because fault_each() was not reporting this error, the error was not getting propagated to the caller(s) of fault_each() and up the call chain. The fix involves getting fault_each() to return an error value upon failure and to have the callers of fault_each() check for the return value and do likewise upon an error. In particular, pre_demand_load() (which calls fault_each()), and which is responsible for fetching file text and data across NFS mount points, needs to check for failure and report an error return value to its caller so that the calling process can terminate itself with a SIGKILL. PHKL_4246: When debugging an NFS mounted file and another process modifies the text, the system can panic. The customer is actually running Andrew File System, but the same behavior occurs under NFS as well. PHKL_4222: Fixes a problem with vslock() when it is interrupted by signals. The async driver calls vslock() but when vslock() receives a signal it merely longjmps leaving a few pages locked. This can lead to a bad state. So vslock() now sleeps at a priority which blocks off all signals. This prevents the kernel from getting into a bad state. PHKL_4193: Fixes a memory leak in NFS. This patch fixes a memory leak in NFS. NFS code clfree() does not FREE all its MALLOCed structures. This causes a slow memory leak because the structure not FREE'd is 64 bytes. PHKL_4184: disk buffers are lost if process doing I/O from disk to shm is signalled PHKL_4165: To swap text on local swap device if sticky bit is set. This is to complete the solution started in PHKL_2283. PHKL_2283 does not completely fix the problem. PHKL_4157: HOSTNAMESZ is back to 32 and will stay that way until 10.0 because of problems with DUX code. PHKL_4046: This patch backs out the fix made for PHKL_3974. The original fix for the NFS readdir problem can cause a panic on systems with automount. So until a better solution is found for the NFS problem the changes are backed out. PHKL_4031: Increase HOSTNAMESZ to 256 as per RFC 1123. Earlier PHKL_3985 did not include a couple of .o's that were needed. PHKL_3985: Increase HOSTNAMESZ to 256 to allow domain names greater than 32 characters. PHKL_3974: This patch fixes a problem with NFS when customers use the library calls readdir and seekdir. NFS normally compacts the directory entries. The UFS and other filesystems return the directory entries as it is laid out in the disk. This can cause problems in readdir and seekdir in NFS because of the difference in format returned to the library call. So this NFS fix is to expand the directory entries and include blank entries in the buffer returned to user through the system call getdirentries. This is consistent with how the buffer is returned across all filesystems. PHKL_3569: Allows caller of mmap() to fix address in private data space with MAP_SHARED as long as no other process has the file mapped. The mmap becomes "exclusive" and only that process is allowed to access the file. With HP's global address space, it is impossible to guarantee the availability of an address. There existing (and new) applications that hard code in pointer values into file data, requiring the subsequent mmap to be at a specific location. To alleviate this problem, this patch allows a caller of mmap to map a file shared into the process's private data space. Previously all MAP_SHARED mmap() calls had to return an address in the global address space (quadrant 3/4). The caller "fixes" the address by specifying an address to mmap() and includes the MAP_FIXED flag. If there are no other users in the system mapping that file, mmap() will create an "exclusive" mmap, where only that process is allowed to access that file in MAP_SHARED mode. Only MAP_PRIVATE calls can be made on exclusive mmaps. The exclusive mmap is kept until the user removes all references to that file and the pseudo-address space is removed. During the exclusive mapping, only that process can mmap the file MAP_SHARED. Children will be rejected. Since only the parent can access the file, any children created do not contain the exclusive mappings. PHKL_3551: Fixes a "panic: freeing free inode" on DUX servers. This patch fixes a "panic: freeing free inode" on DUX servers when a DUX client is using memory mapped files. The patch also fixes a hang related to the use of msems (memory mapped file semaphores) on DUX as well as non-DUX systems. The server panics with "freeing free inode" because it thinks that the mmap'ed file has already been removed or unlinked for good; there should not be any more requests against that file coming from the client. However, a write request comes in, which eventually tries to free the inode again, and causes the panic. The write request is generated by the client when the last process with the file mmap'ed exits. At that time, the file is unmapped and any dirty pages are scheduled for I/O; one of those I/O requests causes the server to panic. The fix for this problem was to wait for the I/Os to complete before doing the final remove/unlink of the file. In addition, the original msem_lock() call allowed a process to sleep forever if it tried to grab a semaphore that it already owned. This in itself was not catastrophic because the process could be killed and everything would be cleaned up properly. However, if a second process attempted a lock on that same semaphore, while the first process was waiting on itself, then the system would hang. The best way to diagnose this problem is to get a TOC dump and look for the kernel stack of the running process. The routine msleep() should appear at the top. The fix for this problem was to return an error (EDEADLK) whenever a process attempts to grab a semaphore that it already holds. PHKL_3550: Force hpux_aes_override to always be on. PHKL_3477: Fixes panic with data segmentation fault in pdprotget(). This is a problem introduced by PHKL_2487 and all patches which supersede it. The problem happens in process_ra_pages() when it calls pdprotget() for a page which has the valid bit on in its vfd but does not have a translation. Since it does not have a translation pdprotget() panics. This is a corner case and should not happen very often. This has been fixed by checking if the page corresponding to the vfd has a translation before calling pdprotget(). The typical stacktrace for this problem looks like: panic+0x2c ( arguments not stored ) trap+0xa74 ( arguments not stored ) pdprotget+0x74 ( arguments not stored ) process_ra_pages+0x14c ( arguments not stored ) checkprotid+0x9c ( arguments not stored ) hdl_pfault+0x210 ( arguments not stored ) pfault+0x174 ( arguments not stored ) trap+0x75c ( arguments not stored ) PHKL_3468: Fix for panic "findentry: idx beyond region size" The system panics during raw I/O between a shared memory segment and a disk or tape if the size of the I/O extends past the end of the shared memory segment. The user process requesting the I/O must have one or more shared memory segments contiguous to the first segment which together encompass all the data requested to be input/output. The panic will either be "Data segmentation fault" or "findentry: idx beyond region size". physio and vsunlock will be on the stack trace. PHKL_3446: UFS/NFS problem where updates to binaries are not recognized by system. Problem can be seen by running a binary that displays a string, running a second binary that modifies the first binary changing the string, and running the first binary again. Instead of displaying the new string it displays the original string. This can be seen over NFS as well as locally on a server. This problem will not show up on regular updates through recompiling the application but only on binaries which are opened without truncation and written to it. The problem on the UFS was introduced by the patch PHKL_2847 and patches which superseded that. The NFS problem has always existed. This problem is fixed by this patch for both NFS and UFS. PHKL_3418: Fix for "panic: csysmemreserve: reservation overrun" The problem was in the interaction between vhand and the swapper. PHKL_3418 fixes this problem by making sure that vhand does not page out some pages that the swapper is trying to bring in. PHKL_3386: Fix for "panic: csysmemreserve: reservation overrun" This patch is a new and improved version of PHKL_3087. If PHKL_3087 is not installed, the panic would have "cmemreserve" instead of "csysmemreserve". This version fixes a problem in the interface between the swapper and the dynamic buffer cache (DBC). The DBC was (unexpectedly) stealing a page that had been reserved by the swapper, thus resulting in the panic. PHKL_3358: Fix for a "panic: crfree: credential reference overflow" which happens on an NFS client with a large inode table. The panic message should look something like this: crfree(0x04129900) : bad cr_ref -32768 panic: crfree: credential reference overflow The problem is well described in the message, namely the cr_ref field is a signed short and has been overflowed because there are too many pointers to the same credentials structure. (See struct ucred in user.h) This is most likely to happen: o when the system has been configured with a large numbers of inodes, say 10,000 or more, and o when the system is accessing lots of files across NFS. The problem has occurred when running a large ls or a large find across NFS; it has also occurred while running fbackup across NFS. The fix is more of a workaround because we cannot redefine the size of the cr_ref field at this time. The patch simply forces the system to bypass the directory name lookup cache (dnlc), which is the root cause of many of the references, once the cr_ref fields goes beyond 0x4000. PHKL_3352: Fix syncer performance problems on systems with huge buffer caches. Modified tflush() to only walk once through the buffer cache, keeping track of which buffers to write, then writing them at the end of the walk through. PHKL_3343: This fixes spontaneous data corruption on 2K executables. This problem will happen only on a 2K executable (probably compiled earlier than 8.0). If NULL dereferencing is allowed then the kernel zeroes out the first half of the first page and the other half contains text. When the executable is run the first time, the kernel reads in the first page and inserts into the pagecache. It then zeroes out the first half. Now, this is a bug. Since the page is modified, it should be copied into another page and then zeroed out. So, when the executable is executed a second time (or opened through regular file system) the kernel finds the page in the pagecache and thinks that this is the latest copy. It finds the SOM headers trashed and it returns an error to the ksh. This bug is exposed with the memory mapped file tuning patch because the patch copies the data from the pagecache if it finds a disk page. It assumes that what is in the pagecache is what it should find in the disk. Since this rule is violated for the 2K compatible executable we run into this problem. The fix has been to break the copy on write when bringing in the first page. Now this preserves the disk image in the pagecache. PHKL_3286: Fixes problems with sync_indirects panics. Fixes vi file then !!date "hang". sync_indirects() needed to be changed to just return if not called with a regular file. fsync'ing pipes caused problems. this fixes two known problems: 1) sync_indirect panics going through dux; and, 2) vi file !!date "hang" PHKL_3216: This is the 9.01 port of PHKL_3211 (8.07) which fixes a Data Segmentation Fault that occurrs when a system call to vfork() is performed when the proc table is full. (i.e. another process entry could not be added). The error path of the "traditional" vfork semantics created in PHKL_0743 did not take this into account correctly and upon exit the parent inappropriately accessed a data structure that had not been initialized. PHKL_3209: PAGE DISCLAIM USING MADVISE() CALL In order to perform the page disclaim function, a patch has been made for 9.01 that uses the madvise() call. At 9.01, madvise() was provided as a stub routine for compatibility, the call did some type checking and exited. For simplicity sake, madvise() has been changed to perform page disclaim until a true disclaim() call is added to HP-UX. To use madvise() to perform a page disclaim, do the following: #include ret = madvise(addr, length, MADV_DONTNEED); caddr_t addr; /* page aligned address */ int length; /* length in bytes */ addr - is the starting address of the portion of memory to be disclaimed. It must be page aligned. length - is the number of bytes of memory to disclaim. If the length is less than 1 page, it will be rounded to 1 page. [the algorithm will round "up" to the next page] MADV_DONTNEED - This is the flag to the patched version of madvise to do a disclaim call. The flag field must always be set to MADV_DONTNEED to disclaim. The physical pages specified are returned to the system pool and the virtual pages are marked demand zero-fill. The next time the process accesses one of these pages, it will receive a zero-filled page. NOTE The patch version of disclaim using madvise() will not require the address range indicated by addr+len be created by a call to mmap(). The caller must have write access to the address range. RETURN VALUE madvise() returns 0 upon success; otherwise, it returns -1 and sets errno to indicate the error. ERRORS madvise() fails if any of the following conditions are encountered: [EFAULT] The range specified by (addr, addr+len) is invalid for a process' address space. [EFAULT] process does not have write access to memory it is trying to disclaim [EINVAL] addr is not a multiple of the page size as returned by sysconf(_SC_PAGE_SIZE), or flag contains invalid values or incompatible combinations of flags. [EINVAL] addr is not part of the processes DATA region or part of a shared memory segment mapped to the process. PHKL_3205: A file that was being written to and had filled up the server's disk could not be read: All reads and writes to that file would fail and return ENOSPC (disk full) until all processes had closed the file. This would make it look like the file was empty even though the ll(1) showed it had a size greater than 0. This patch allows reads to succeed even if a write had failed. Writes will still fail with ENOSPC because the of the asynchronous writes of NFS don't allow the kernel to know which process or which write actually failed. PHKL_3155: fsync(2) followed by crash showed data loss. Indirect blocks were not being written out to disk. Indirect blocks were not being written out to disk on an fsync(2). New routine sync_indirects(ip) is called from ufs_fsync(). PHKL_3149: Misleading message printed when comparing function pointers. When comparing two function pointers and the value of the function pointer is garbage, the system prints the following message: Pid 5868 received a SIGSEGV for stack growth failure. Possible causes: insufficient memory or swap space, or stack size exceeded maxssiz. This is erroneous and should not be printed even when comparing a garbage function pointer. This has been fixed and as usual no core is dumped. PHKL_3117: This patch fixes a data loss/corruption problem across NFS. The data loss is caused by a duplicate CREATE request which incorrectly truncates the file after some write requests have been processed. This patch needs to be installed only on the NFS server, but it will not do any harm if you also install it on the clients. DETAIL: ====== A duplicate create request coming through NFS ends up in the UFS code which truncates the file even if it already exists. The customer is seeing data loss because in between the first and second creates, some write requests were completed and then wiped out. THE FIX: ======= The NFS server code in rfs_create() needs to check for existence of the file and for duplicate requests before invoking the UFS layer. PHKL_3087: Fix for panic cmemreserve: reservation overrun. Memory reservation routines (memreserve, cmemreserve, ciomemreserve, and memunreserve) have been replaced by new functions that take an extra parameter. This problem occurs because the memory reserved by the swapper in order to swap a process in (UAREA + vfds of the process being swapped in) is being exhausted. When the swapper is attempting to swap in a process, it must first reserve enough memory to bring in the process' UAREA and vfds. Swapper calculates the number of pages needed for bringing in these data structures and reserves sufficient memory. When attempting to bring in pages from UAREA, CAM will handle the I/O request, but before returning it will attempt to also handle a request for an incoming LAN packet. To handle the incoming packet, the LAN driver needs memory and will eventually end up calling cmemreserve(). Unfortunately, cmemreserve() has no way of knowing that this call is not on behalf of the swapper, so some of the memory that swapper had reserved to swap in the process gets exhausted in handling the LAN package. When the swapper finally finds out that it has run out of memory, it panics. In summary, the logic for handling memory reservation for the swapper when attempting to swap in a process is flawed. The implicit assumtion that no one except the swapper will call cmemreserve() in the context of the swapper is false. PHKL_3028: Memory Mapped File Tuning to improve performance. This patch replaces PHKL_2847 entirely because of a collision with another patch. PHKL_2853: NFS data corruption or premature/incorrect EOF This patch fixes data corruption and/or premature end-of-file conditions across NFS. The problem has been experienced by two customers in two different ways: 1: The customer was using the -async option on the NFS server. The client was doing sequential writes using the O_APPEND flag. The client was also running multiple biods. The O_APPEND forces the client to lseek to the end-of-file before processing the write. Therefore, if the end-of-file is incorrect, the client will overwrite sections of the file and the file will end up shorter than expected. The root cause for this case was simply that the client was processing NFS write replies out-of-order. This was caused by the fact that the server was sending the replies too close to each other due to the use of -async. A good workaround to this problem is to run with 0 biods or to run with 1 biod. Not so good workarounds include using O_SYNC along with O_APPEND and not using the -async option on the server. 2: The customer was using a Sun server running NFS version 4.2. The client was doing sequential writes with a random read executed once-in-a-while to verify the last 512 bytes written. The read was sometimes failing with 0 bytes returned, indicating end-of-file. (That is called a premature end-of-file.) The root cause for this case was in the behavior of the Sun NFS 4.2 server. The Sun 4.2 server code returns stale file attributes whenever a duplicate write request is made. The HP client was receiving incorrect information from the server, specifically, the location of the end-of-file (i.e. the file size was too small). Note that this would happen only on the reply to a duplicate write request. Since the read was happening on the last 512 bytes, the HP client would believe the end-of-file coming back from the Sun server (as a result of a duplicate write) and return 0 bytes to the user program. The fix for these two problems was to force the HP client code to double check with the server BEFORE truncating the file size. Essentially, if a write reply comes back with a file size that is smaller than expected, the client will go across-the-wire with a getattr call to double check. If the getattr returns the smaller file size again, then the HP client assumes the file has honestly been truncated. PHKL_2847: Memory Mapped File Tuning to improve performance. Implemented read ahead algorithm and added other enhancements to improve the performance of writes to sparse files. With the in-house benchmark, the performance was improved by a factor of 2 for non-sparse files using this patch. The performance of a sparse file was improved by a factor of 6 when writing to a sparse file. In addition this patch has two bug fixes. This patch should be installed for any customer who complains about memory mapped file performance. PHKL_2844: Error writing or saving file from PC-NFS client to HP-UX server. PC-NFS client of HP-UX server sees apparent error trying to save a writable file or trying to update the file's timestamp. PHKL_2836: This change fixes an EACCES problem that appears when two processes are alternately reading and writing the same file over an NFS mount. The error occurs when delayed writes are involved. This is because the read process over-writes the credentials for the file in the rnode and when the delayed write finally occurrs, it tries to use the wrong credentials to perform it, thus resulting in the EACCES error. The problem is created by an "enhancement" in the HP NFS code from the original Sun NFS code. The Sun code only overwrites the rnode file credentials when the existing rnode credentials are NULL. This creates the possibility for all users (including the owner) to not be able to read the file if root was the first one to read from the file (and set the credential). The problem being that prior to 9.0 it was not possible to configure the NFS server to allow root access by clients. Effectively if the root credentials fail on the NFS I/O, no one can access the file again. This is what the HP NFS change fixed: by updating the credentials for reads when the existing credential in the rnode does not match the current read process. This solved the "read deadlock problem" but it also introduced the possibility for another problem, namely that of SR 5000685800! The scenario of the current problem is as follows: There are two processes: P1 and P2 P1 is uid user1 P2 is uid user2 P1 and P2 are both gid sys P1 owns and opens a file for O_WRONLY and begins writing it with permissions 640. P2 starts doing a tail -f on the file. Within a few writes of P1 and reads of P2, P1 receives an error (Permission denied - EACCES) and continues to do so for each successive write. The problem is caused by the fact that P2 performing reads overwrites the credentials in the rnode of the file. Since the write buffers are still in memory (i.e. they are delayed writes) once they go to be posted accross the lan, they fail with EACCES because they attempted to use the credentials of P2 (the read process) instead of the credentials for P1. This patch breaks the field in the rnode (r_cred) into two fields (r_rcred and r_wcred), one for read credentials and one for write credentials. By doing this, the delayed writes will occurr correctly without EACCES errors because they will always be performed with the last WRITE credential to be used on the file. PHKL_2828: Fix for panics involving holes in files that are memory mapped. This change eliminates the cause of the panic "DBD_HOLE in non-MMF region". Fix for problem with using mprotect(2) in applications that also use vfork(). This could cause a "trap type 15" on systems that run applications that use mprotect() in combination with vfork(). Fix for bug in mprotect() that could cause it to improperly change the access permissions on pages of a memory mapped file. Fix for a problem that can prevent a file system from being unmounted due to "device busy" errors when there are no users of the file system. Fix for "text busy" problems with memory mapped files. Some error cases of mmap() fail to decrement the "text" use count on files, leaving those files marked "text busy" until the next reboot. Fix for an mmap() data coherency problem for cnodes in a diskless cluster. This problem can lead to inconsistent views of data in a memory mapped file even after the required msync() call to synchronize the data among the cnodes in the cluster. PHKL_2788: Hard code the NFS client block transfer size to the maximum 8K block size. This change is identical to the sun NFS v4.2 code which unconditionally sets the NFS client block transfer size to 8K. This was in response to HP clients using a smaller block size (4K) when it was not necessary. This in turn resulted in slower performance throughput on the NFS file system. PHKL_2762: Fix for a hang; system w/AFS and low free memory This patch alleviates a system hang caused by interactions between the VM system, the DBC (dynamic buffer cache), and AFS. In particular, when the system experiences heavy memory pressure, many processes will end up sleeping on bfreelist waiting for file system buffers. These processes could only become runnable as a result of another process releasing an existing buffer. This patch allows them to become runnable when the memory pressure has eased and more buffers can be allocated dynamically. The symptoms are fairly straightforward - the system hangs. A TOC dump would show a good number of processes sleeping on bfreelist and very low free memory. The problem has been seen only on system running AFS (Andrew File System from Transarc Corporation). However, it is theoretically possible to see it on a system without AFS. NOTE: This patch alleviates the problem, but does not fix it completely. If you are certain to have experienced the problem, you should also use the dfile to fix bufpages at 10% of memory, instead of using the DBC. That is absolutely essential if you are using AFS. PHKL_2584: This patch fixes a "panic: data segmentation fault" in dircheckwithsdo(). The panic occurs because a PC-NFS client sends a creat(2) request across the network to the 700 server, but the request contains a null pathname. The HP-NFS client code detects conditions like null pathnames and returns an error. Unfortunately, not all the NFS client implementations perform these checks. In particular, we have seen PC-NFS clients that send a creat(2) request across the network with a null pathname. This clearly does not make any sense to the server. The HP-NFS server code could panic in dircheckwithsdo(). This patch fixes the problem; the HP-NFS server code, with this patch, will detect the condition and return an error to the client. PHKL_2476: This patch fixes a bug that occurs in an NFS server when it receives a duplicate CREATE request. The bug is that this duplicate request may fail with EACCES even though the original request succeeded. This patch allows the NFS server to properly process the duplicate CREATE request. A typical scenario where this problem may occur is a number of NFS clients working very heavily (over 100 NFS requests per second; see nfsstat(1M)) on a single server. One customer experienced the problem when running lots of rm/cp/mv commands; once in a while a cp or mv command would fail with "permission denied" which translates into an EACCES returned from a creat() system call. The problem is caused by the following sequence of events: ========================================================= o Client generates a CREATE request with 0000 permissions. o Server performs the CREATE operation and sends a reply. o The reply is dropped and never received by client. o Client generates a second/duplicate CREATE request. o Server attempts to do a second CREATE which sets the u.u_error flag to EACCES. o Server identifies second CREATE as a duplicate request. o Server does not reset u.u_error flag to 0; this is key! o Server performs a LOOKUP operation to return the file id. o The entry is not in the directory name lookup cache (dnlc) which causes server to invoke native file system code. o The native file system code sees the EACCES in u.u_error and returns immediately. The fix was simply to clear the u.u_error flag after detecting a duplicate request and before performing the LOOKUP operation. PHKL_2462: Two new PTRACE requests added. A request came in for a new ptrace request that would function just as PT_CONTIN did but would not clear p_sig for the traced process. As a result, 2 new ptrace requests, PT_CONTIN1 and PT_SINGLE1 were added and were assigned request numbers 1000 and 1001 respectively. PHKL_2393: 2K-aligned executables could cause process hangs and "grow: no stack region" panics. If 2K-aligned executables are run on a 4K page size system, there is a chance that the process can hang. When doing a control-C to attempt to kill the process, a signal is generated and stack growth is attempted, but the process may not be completely built yet and the system panics since there is not a stack yet for this process. PHKL_2283: If ia file is executed on a remote filesystem and the sticky bit is set on that executable, try to use local swap device instead of using the executable image as the swap. At HP-UX 8.0x, HP revised the Virtual Memory System (VM) to include changes to support shared libraries, copy on write... We also made changes so that when text(code) segments are paged out, they are no longer written to the swap area. This is an improvement for applications on a local disk drive, reducing I/O and swap requirements. However, for applications utilizing a "program" server, the retrieval comes from the network via NFS, with a potentially slower access time. For certain large applications, this can be a problem. We have created the enhancement patch PHKL_2283 so that if a file is executed on a remote file system and the sticky bit is set on that executable, we will try to use the local swap device for the text instead of using the executable image as the swap. PHKL_1989: This patch is a combination of all kernel patches that should be used with NFS. These include patches for the automounter and NFS/diskless interactions. It is designed to make it easier for customers get all the patches at once, and should be installed on any diskless cluster that uses NFS. There are five problems fixed with this patch. This patch allows the automounter to work correctly on diskless clusters. Without this patch the clients can not access the automounted file systems which are configured as direct-mapped mounts. This patch fixes a problem where some writes to an NFS file can be lost if another process is stat(2)'ing the file. The process writing the file has to be also doing a lseek(2) to the end of the file between writes. This combination is likely to cause the problem. It is also possible that multiple processes stat()'ing the file while one is writing it could cause the problem. This patch also fixes a problem where a process that opens a NFS file and then reads and writes to it in a loop runs slowly. The problem was that every read after a write on the same file was causing a flush of the to the server. This patch fixes a problem where the NFS mount parameters: acregmin, acregmax, acdirmin, and acdirmax will not be correctly set when NFS mounts are done on a diskless cluster. See mount(1m) for a description of these parameters. Usually these parameters will get set to 0 which will be unnoticable, but it is possible they will get set to very large numbers causing stale data to be kept on NFS clients. This patch should be installed on all diskless clusters that will use NFS. The patch lowers some timeout values that are used to control how often the lock manager retries remote locks. Without this patch, retries will take 15 seconds which can be very painful. SR: 1653064147 1653070219 1653073775 1653075028 1653085423 1653088518 1653089763 1653098715 1653101337 1653108472 1653108951 1653112870 1653125401 4701159665 4701162008 4701227165 4701229757 4701248039 4701314302 5000685800 5000688234 5000695783 5000700849 5003094326 5003096388 5003129650 5003144683 5003148973 5003150847 5003153403 5003154153 5003162172 5003162313 5003163493 5003172734 5003195370 5003224915 5003282087 5003338384 Patch Files: /etc/conf/libdskless.a(dux_exec.o) /etc/conf/libdskless.a(dux_lookup.o) /etc/conf/libdskless.a(dux_mount.o) /etc/conf/libdskless.a(dux_vnops.o) /etc/conf/libhp-ux.a(hdl_fault.o) /etc/conf/libhp-ux.a(hdl_init.o) /etc/conf/libhp-ux.a(hdl_mprotect.o) /etc/conf/libhp-ux.a(hdl_policy.o) /etc/conf/libhp-ux.a(kern_exec.o) /etc/conf/libhp-ux.a(kern_fork.o) /etc/conf/libhp-ux.a(pm_procdup.o) /etc/conf/libhp-ux.a(sys_ki.o) /etc/conf/libhp-ux.a(sys_proc.o) /etc/conf/libhp-ux.a(vfs_bio.o) /etc/conf/libhp-ux.a(vfs_dnlc.o) /etc/conf/libhp-ux.a(vfs_scalls.o) /etc/conf/libhp-ux.a(vfs_vm.o) /etc/conf/libhp-ux.a(vfs_vnode.o) /etc/conf/libhp-ux.a(vm_devswap.o) /etc/conf/libhp-ux.a(vm_fault.o) /etc/conf/libhp-ux.a(vm_kern.o) /etc/conf/libhp-ux.a(vm_machreg.o) /etc/conf/libhp-ux.a(vm_misc.o) /etc/conf/libhp-ux.a(vm_mmap.o) /etc/conf/libhp-ux.a(vm_msem.o) /etc/conf/libhp-ux.a(vm_page.o) /etc/conf/libhp-ux.a(vm_pgcache.o) /etc/conf/libhp-ux.a(vm_region.o) /etc/conf/libhp-ux.a(vm_sched.o) /etc/conf/libhp-ux.a(vm_swp.o) /etc/conf/libhp-ux.a(vm_text.o) /etc/conf/libhp-ux.a(vm_vas.o) /etc/conf/libnfs.a(klm_lckmgr.o) /etc/conf/libnfs.a(nfs_server.o) /etc/conf/libnfs.a(nfs_subr.o) /etc/conf/libnfs.a(nfs_vfsops.o) /etc/conf/libnfs.a(nfs_vnops.o) /etc/conf/libnfs.a(nfs_xdr.o) /etc/conf/libnfs.a(nfstest.o) /etc/conf/libufs.a(ufs_bmap.o) /etc/conf/libufs.a(ufs_dir.o) /etc/conf/libufs.a(ufs_subr.o) /etc/conf/libufs.a(ufs_vnops.o) /etc/conf/nfs/nfs_clnt.h /etc/conf/nfs/rnode.h /usr/include/nfs/nfs_clnt.h /usr/include/nfs/rnode.h /usr/contrib/bin/analyze what(1) Output: /etc/conf/libdskless.a(dux_exec.o): dux_exec.c $Revision: 1.7.81.4 $ $Date: 94/04/28 10:13:20 $ PATCH_9.01 (PHKL_4157) /etc/conf/libdskless.a(dux_lookup.o): dux_lookup.c $Revision: 1.8.81.8 $ $Date: 94/11/01 09:50:14 $ PATCH_9.01 (PHKL_4942) /etc/conf/libdskless.a(dux_mount.o): dux_mount.c $Revision: 1.13.81.8 $ $Date: 94/04/28 10:12:32 $ PATCH_9.01 (PHKL_4157) /etc/conf/libdskless.a(dux_vnops.o): dux_vnops.o $Revision: 1.13.81.4 $ $Date: 94/11/0 1 09:47:37 $ PATCH_9.01 (PHKL_4942) /etc/conf/libhp-ux.a(hdl_fault.o): hdl_fault.c $Revision: 1.9.81.4 $ $Date: 93/09/22 1 1:55:41 $ PATCH_9.01 (PHKL_3149) /etc/conf/libhp-ux.a(hdl_init.o): hdl_init.c $Revision: 1.7.81.5 $ $Date: 94/05/06 14:46:09 $ PATCH_9.01 (PHKL_4165) /etc/conf/libhp-ux.a(hdl_mprotect.o): hdl_mprotect.c $Revision: 1.2.81.3 $ $Date: 93/07/09 10:18:00 $ PATCH_9.01 (PHKL_2828) /etc/conf/libhp-ux.a(hdl_policy.o): hdl_policy.c $Revision: 1.9.81.4 $ $Date: 94/05 /06 14:47:49 $ PATCH_9.01 (PHKL_4165) /etc/conf/libhp-ux.a(kern_exec.o): kern_exec.c $Revision: 1.88.81.6 $ $Date: 96/02 /16 13:32:24 $ PATCH_9.01 (PHKL_6759) /etc/conf/libhp-ux.a(kern_fork.o): kern_fork.c $Revision: 1.66.81.6 $ $Date: 94/11/0 9 10:45:32 $ PATCH_9.01 (PHKL_4968) /etc/conf/libhp-ux.a(pm_procdup.o): pm_procdup.c $Revision: 1.7.81.3 $ $Date: 93/07/09 09:48:33 $ PATCH_9.01 (PHKL_2828) /etc/conf/libhp-ux.a(sys_ki.o): sys_ki.c $Revision: 1.13.81.5 $ $Date: 94/04/28 10:11:49 $ PATCH_9.01 (PHKL_4157) /etc/conf/libhp-ux.a(sys_proc.o): sys_proc.c $Date: 95/09/08 12:13:25 $ $Revision: 1.47.81.9 $ PATCH_9.01 (PHKL_4506) /etc/conf/libhp-ux.a(vfs_bio.o): vfs_bio.c $Revision: 1.20.81.7 $ $Date: 95/03/1 4 14:01:46 $ PATCH_9.01 (PHKL_5357) /etc/conf/libhp-ux.a(vfs_dnlc.o): vfs_dnlc.c $Revision: 1.13.81.7 $ $Date: 94/07/29 17:16:29 $ PATCH_9.01 (PHKL_4607) /etc/conf/libhp-ux.a(vfs_scalls.o): vfs_scalls.c $Revision: 1.13.81.6 $ $Date: 94/07/29 17:17:13 $ PATCH_9.01 (PHKL_4607) /etc/conf/libhp-ux.a(vfs_vm.o): vfs_vm.c $Revision: 1.11.81.13 $ $Date: 96/11/06 08:56:59 $ PATCH_9.01 (PHKL_9148) /etc/conf/libhp-ux.a(vfs_vnode.o): vfs_vnode.c $Revision: 1.10.81.3 $ $Date: 93/12/22 15:54:51 $ PATCH_9.01 (PHKL_3550) /etc/conf/libhp-ux.a(vm_devswap.o): vm_devswap.c $Revision: 1.14.81.4 $ $Date: 94/04/28 15:33:19 $ PATCH_9.01 (PHKL_4165) /etc/conf/libhp-ux.a(vm_fault.o): vm_fault.c $Revision: 1.16.81.3 $ $Date: 93/09/21 17:19:54 $ PATCH_9.01 (PHKL_3087) /etc/conf/libhp-ux.a(vm_kern.o): vm_kern.c $Revision: 1.6.81.4 $ $Date: 93/11/22 1 3:30:30 $ PATCH_9.01 (PHKL_3386) /etc/conf/libhp-ux.a(vm_machreg.o): vm_machreg.c $Revision: 1.10.81.7 $ $Date: 94/07/01 13:19:31 $ PATCH_9.01 (PHKL_4184) /etc/conf/libhp-ux.a(vm_misc.o): vm_misc.c $Revision: 1.8.81.4 $ $Date: 94/07/01 13:1 6:09 $ PATCH_9.01 (PHKL_4184) /etc/conf/libhp-ux.a(vm_mmap.o): vm_mmap.c $Revision: 1.12.81.11 $ $Date: 94/04/ 28 15:31:53 $ PATCH_9.01 (PHKL_4165) /etc/conf/libhp-ux.a(vm_msem.o): vm_msem.c $Revision: 1.2.81.3 $ $Date: 94/01/05 09:0 1:30 $ PATCH_9.01 (PHKL_3551) /etc/conf/libhp-ux.a(vm_page.o): vm_page.c $Revision: 1.85.81.4 $ $Date: 93/10/11 15:01:36 $ PATCH_9.01 (PHKL_3209) /etc/conf/libhp-ux.a(vm_pgcache.o): vm_pgcache.c $Revision: 1.7.81.3 $ $Date: 93/07/09 10:16:40 $ PATCH_9.01 (PHKL_2828) /etc/conf/libhp-ux.a(vm_region.o): vm_region.c $Revision: 1.16.81.3 $ $Date: 93/10/11 15:01:33 $ PATCH_9.01 (PHKL_3209) /etc/conf/libhp-ux.a(vm_sched.o): vm_sched.c $Revision: 1.53.81.4 $ $Date: 93/12/01 10:57:31 $ PATCH_9.01 (PHKL_3418) /etc/conf/libhp-ux.a(vm_swp.o): vm_swp.c $Revision: 1.44.81.5 $ $Date: 94/04/28 10:10:38 $ PATCH_9.01 (PHKL_4157) /etc/conf/libhp-ux.a(vm_text.o): vm_text.c $Revision: 1.50.81.8 $ $Date: 94/10/2 7 13:41:59 $ PATCH_9.01 (PHKL_4935) /etc/conf/libhp-ux.a(vm_vas.o): vm_vas.c $Revision: 1.13.81.3 $ $Date: 94/01/07 10:15:00 $ PATCH_9.01 (PHKL_3569) /etc/conf/libnfs.a(klm_lckmgr.o): klm_lckmgr.c $Revision: 1.5.81.9 $ $Date: 95/09/08 11:48:00 $ PATCH_9.01 (PHKL_6049) /etc/conf/libnfs.a(nfs_server.o): nfs_server.c $Date: 96/02/16 13:30:59 $ $Revision: 1.17.81.8 $ PATCH_9.01 (PHKL_6759) /etc/conf/libnfs.a(nfs_subr.o): nfs_subr.c $Date: 96/02/16 13:31:52 $ $Revision: 1.1 5.81.10 $ PATCH_9.01 (PHKL_6759) /etc/conf/libnfs.a(nfs_vfsops.o): nfs_vfsops.c $Revision: 1.8.81.7 $ $Date: 94/04/28 1 0:14:57 $ PATCH_9.01 (PHKL_4157) /etc/conf/libnfs.a(nfs_vnops.o): nfs_vnops.c $Revision: 1.17.81.15 $ $Date: 94/07/2 9 17:17:30 $ PATCH_9.01 (PHKL_4607) /etc/conf/libnfs.a(nfs_xdr.o): nfs_xdr.c $Revision: 1.9.81.4 $ $Date: 94/04/11 09:05:45 $ PATCH_9.01 (PHKL_4046) /etc/conf/libnfs.a(nfstest.o): nfstest.c $Revision: 1.5.81.7 $ $Date: 94/04/28 10:14:35 $ PATCH_9.01 (PHKL_4157) /etc/conf/libufs.a(ufs_bmap.o): ufs_bmap.c $Revision: 1.22.81.4 $ $Date: 93/08/2 3 17:31:24 $ PATCH_9.01 (PHKL_3028) /etc/conf/libufs.a(ufs_dir.o): ufs_dir.c $Date: 96/02/16 13:32:41 $ $Revision: 1.15 .81.3 $ PATCH_9.01 (PHKL_6759) /etc/conf/libufs.a(ufs_subr.o): ufs_subr.c $Revision: 1.28.81.4 $ $Date: 93/10/25 12:59:14 $ PATCH_9.01 (PHKL_3286) /etc/conf/libufs.a(ufs_vnops.o): ufs_vnops.c $Revision: 1.22.81.8 $ $Date: 93/12/22 10:45:59 $ PATCH_9.01 (PHKL_3550) /etc/conf/nfs/nfs_clnt.h: nfs_clnt.h: $Revision: 1.9.81.5 $ $Date: 94/04/28 10 :13:52 $ 10.1 nfs_clnt.h $Revision: 1.9.81.5 $ $Date: 94/04/28 10:13:52 $ PATCH_9.01 (PHKL_4157) */ /etc/conf/nfs/rnode.h: rnode.h: $Revision: 1.8.81.3 $ $Date: 93/07/14 13:10 :42 $ 10.7 /usr/include/nfs/nfs_clnt.h: nfs_clnt.h: $Revision: 1.9.81.5 $ $Date: 94/04/28 10 :13:52 $ 10.1 nfs_clnt.h $Revision: 1.9.81.5 $ $Date: 94/04/28 10:13:52 $ PATCH_9.01 (PHKL_4157) */ /usr/include/nfs/rnode.h: rnode.h: $Revision: 1.8.81.3 $ $Date: 93/07/14 13:10 :42 $ 10.7 /usr/contrib/bin/analyze: dump.c $Revision: 1.74.81.4 $ $Date: 93/07/14 1 4:00:06 $ PATCH_9.01 PHKL_2836 sum(1) Output: 11919 13 /etc/conf/libdskless.a(dux_exec.o) 23792 25 /etc/conf/libdskless.a(dux_lookup.o) 48721 32 /etc/conf/libdskless.a(dux_mount.o) 38573 45 /etc/conf/libdskless.a(dux_vnops.o) 26492 19 /etc/conf/libhp-ux.a(hdl_fault.o) 58843 9 /etc/conf/libhp-ux.a(hdl_init.o) 9974 32 /etc/conf/libhp-ux.a(hdl_mprotect.o) 29552 21 /etc/conf/libhp-ux.a(hdl_policy.o) 26244 23 /etc/conf/libhp-ux.a(kern_exec.o) 11003 20 /etc/conf/libhp-ux.a(kern_fork.o) 14178 11 /etc/conf/libhp-ux.a(pm_procdup.o) 15715 48 /etc/conf/libhp-ux.a(sys_ki.o) 38980 20 /etc/conf/libhp-ux.a(sys_proc.o) 38848 57 /etc/conf/libhp-ux.a(vfs_bio.o) 48153 13 /etc/conf/libhp-ux.a(vfs_dnlc.o) 478 33 /etc/conf/libhp-ux.a(vfs_scalls.o) 46194 51 /etc/conf/libhp-ux.a(vfs_vm.o) 44961 15 /etc/conf/libhp-ux.a(vfs_vnode.o) 49783 23 /etc/conf/libhp-ux.a(vm_devswap.o) 8707 20 /etc/conf/libhp-ux.a(vm_fault.o) 10404 12 /etc/conf/libhp-ux.a(vm_kern.o) 57022 23 /etc/conf/libhp-ux.a(vm_machreg.o) 27709 16 /etc/conf/libhp-ux.a(vm_misc.o) 60241 34 /etc/conf/libhp-ux.a(vm_mmap.o) 3109 15 /etc/conf/libhp-ux.a(vm_msem.o) 28782 24 /etc/conf/libhp-ux.a(vm_page.o) 27124 12 /etc/conf/libhp-ux.a(vm_pgcache.o) 22397 16 /etc/conf/libhp-ux.a(vm_region.o) 15554 31 /etc/conf/libhp-ux.a(vm_sched.o) 43114 13 /etc/conf/libhp-ux.a(vm_swp.o) 21252 30 /etc/conf/libhp-ux.a(vm_text.o) 36882 20 /etc/conf/libhp-ux.a(vm_vas.o) 35059 11 /etc/conf/libnfs.a(klm_lckmgr.o) 18439 50 /etc/conf/libnfs.a(nfs_server.o) 11701 29 /etc/conf/libnfs.a(nfs_subr.o) 26170 16 /etc/conf/libnfs.a(nfs_vfsops.o) 17912 51 /etc/conf/libnfs.a(nfs_vnops.o) 56307 19 /etc/conf/libnfs.a(nfs_xdr.o) 12964 7 /etc/conf/libnfs.a(nfstest.o) 10471 10 /etc/conf/libufs.a(ufs_bmap.o) 33198 34 /etc/conf/libufs.a(ufs_dir.o) 35391 18 /etc/conf/libufs.a(ufs_subr.o) 23210 56 /etc/conf/libufs.a(ufs_vnops.o) 58793 7 /etc/conf/nfs/nfs_clnt.h 56094 7 /etc/conf/nfs/rnode.h 58793 7 /usr/include/nfs/nfs_clnt.h 56094 7 /usr/include/nfs/rnode.h 14075 944 /usr/contrib/bin/analyze Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_1989 PHKL_2283 PHKL_2393 PHKL_2462 PHKL_2476 PHKL_2584 PHKL_2762 PHKL_2788 PHKL_2828 PHKL_2836 PHKL_2844 PHKL_2847 PHKL_2853 PHKL_3028 PHKL_3087 PHKL_3117 PHKL_3149 PHKL_3155 PHKL_3205 PHKL_3209 PHKL_3216 PHKL_3286 PHKL_3343 PHKL_3352 PHKL_3358 PHKL_3386 PHKL_3418 PHKL_3446 PHKL_3468 PHKL_3477 PHKL_3550 PHKL_3551 PHKL_3569 PHKL_3974 PHKL_3985 PHKL_4031 PHKL_4046 PHKL_4157 PHKL_4165 PHKL_4184 PHKL_4193 PHKL_4222 PHKL_4246 PHKL_4506 PHKL_4607 PHKL_4728 PHKL_4776 PHKL_4932 PHKL_4935 PHKL_4942 PHKL_4968 PHKL_5077 PHKL_5357 PHKL_5993 PHKL_6049 PHKL_6759 Equivalent Patches: PHKL_9149: s700: 9.03 9.05 9.07 Patch Package Size: 1110 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. Copy the patch to your /tmp directory and unshar it: cd /tmp cp patch_source/PHKL_9148 . sh PHKL_9148 3. Become root and run update: /etc/update [-r [kernel_gen_file]] -s \ /tmp/PHKL_9148.updt PHKL_9148 Update moves the original software to /system/PHKL_9148/orig. Keep this file to recover from any potential problems. You should move the .text file to /system/PHKL_9148 for future reference. To put this patch on a magnetic tape and update from the tape drive, use dd: dd if=PHKL_9148.updt of=/dev/rmt/0m bs=2048 Special Installation Instructions: Due to the number of objects in this patch, the customization phase of the update may take more than 10 minutes. During that time the system will not appear to make forward progress, but it will actually be installing the objects.