Patch Name: PHKL_29760 Patch Description: s700_800 11.04 (VVOS) PM,PA-8700,AIO,T600,FS,PDC,CLK Creation Date: 03/09/16 Post Date: 03/11/05 Hardware Platforms - OS Releases: s700: 11.04 s800: 11.04 Products: N/A Filesets: OS-Core.CORE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP ProgSupport.C-INC,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP VirtualVaultOS.VVOS-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP VirtualVaultOS.VVOS-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_29760: PANIC HANG Based on HP-UX Patch PHKL_28766: PANIC Based on HP-UX Patch PHKL_27994: HANG Intermittent system hangs for several minutes. Based on HP-UX Patch PHKL_27919: PANIC Based on HP-UX Patch PHKL_27759: PANIC PHKL_27710: ABORT PANIC CORRUPTION HANG Based on HP-UX Patch PHKL_27157: ABORT CORRUPTION Based on HP-UX Patch PHKL_26800: HANG Hang - Filesystem or Process Hang Based on HP-UX Patch PHKL_25906: PANIC Based on HP-UX Patch PHKL_25525: HANG PHKL_25044: ABORT OTHER PANIC CORRUPTION HANG Based on HP-UX Patch PHKL_25210: PANIC CORRUPTION Based on HP-UX Patch PHKL_25188: PANIC Based on HP-UX Patch PHKL_25164: PANIC Based on HP-UX Patch PHKL_24612: ABORT Based on HP-UX Patch PHKL_24457: PANIC Based on HP-UX Patch PHKL_24273: PANIC The system panics when r_refcnt overflows Based on HP-UX Patch PHKL_24116: OTHER Hung, Unkillable Process Based on HP-UX Patch PHKL_24015: PANIC Based on HP-UX Patch PHKL_23857: CORRUPTION Based on HP-UX Patch PHKL_23813: PANIC Based on HP-UX Patch PHKL_23812: HANG PHKL_23886: OTHER Based on HP-UX Patch PHKL_23406: OTHER Hung, Unkillable Process Based on HP-UX Patch PHKL_23183: OTHER A program that uses probe instruction will cause signal handler to be removed. It will cause a non-access reference to an invalid virtual memory address causing SIGSEGV handler to be removed. So, the application's signal handler is not invoked and it does not know what to do. PHKL_23166: PANIC Based on HP-UX Patch PHKL_22744: PANIC Based on HP-UX Patch PHKL_22549: PANIC PHKL_22891: PANIC CORRUPTION HANG Based on HP-UX Patch PHKL_22380: PANIC HANG Based on HP-UX Patch PHKL_22126: PANIC Based on HP-UX Patch PHKL_21781: PANIC CORRUPTION Based on HP-UX Patch PHKL_21624: HANG Based on HP-UX Patch PHKL_21600: PANIC Based on HP-UX Patch PHKL_20647: HANG Based on HP-UX Patch PHKL_20449: PANIC Based on HP-UX Patch PHKL_20223: PANIC PHKL_22717: PANIC MEMORY_LEAK HANG Based on HP-UX Patch PHKL_22493: PANIC Based on HP-UX Patch PHKL_21775: HANG Based on HP-UX Patch PHKL_21507: PANIC Based on HP-UX Patch PHKL_20439: PANIC MEMORY_LEAK PHKL_21306: OTHER PANIC MEMORY_LEAK CORRUPTION HANG Based on HP-UX Patch PHKL_21354: PANIC Based on HP-UX Patch PHKL_20335: CORRUPTION Based on HP-UX Patch PHKL_20222: MEMORY_LEAK Based on HP-UX Patch PHKL_20017: OTHER Causing degradation in I/O performance of the system. Based on HP-UX Patch PHKL_19314: HANG Based on HP-UX Patch PHKL_19201: HANG PHKL_19440: PANIC Based on HP-UX Patch PHKL_20836: PANIC Based on HP-UX Patch PHKL_20515: PANIC Category Tags: defect_repair hardware_enablement enhancement general_release critical panic halts_system corruption memory_leak Path Name: /hp-ux_patches/s700_800/11.X/PHKL_29760 Symptoms: PHKL_29760: Ported HP-UX patch PHKL_28766 to VVOS Based on HP-UX patch PHKL_28766: ( SR:8606279968 CR:JAGae43943 ) System panics with the panic string, mp_b_sema_sleep: blocking on owned semaphore or panics with a data page fault when unmapping a shared library that uses large pages. Only users using shared libraries with large pages should see this problem. The stack trace is similar to either of the following 2 traces: panic+0x14 _mp_b_sema_sleep+0x88 superpage_lock+0x54 vm_vfdcheck+0x234 for_val3+0x88 for_val2+0x2d0 foreach_valid+0x54 vm_find_next_range+0x58 vx_do_pageout+0x108 vx_pageout+0xdc unmapvnode+0xf8 do_munmap+0xf8 foreach_pregion+0xc8 munmap+0x78 syscall+0x480 $syscallrtn+0x0 panic+0x14 report_trap_or_int_and_panic+0x84 trap+0xe04 nokgdb+0x8 pdv_protaccset2_0+0x3f8 do_all_aliases_protaccset+0x88 pdprotaccset+0x90 hdl_user_protect+0x664 vm_protect_pageout+0x48 vx_do_pageout+0x1a4 vx_pageout+0xe0 unmapvnode+0xd0 do_munmap+0xf0 foreach_pregion+0xc8 munmap+0x78 syscall+0x28c $syscallrtn+0x0 Based on HP-UX patch PHKL_28180: ( SR:8606272341 CR:JAGae36480 ) During heavy load, the following message is logged in the message buffer, "vmunix: Clock_int: tick arrived early". This is observed on a 32-bit HP-UX kernel only. Based on HP-UX patch PHKL_28053: ( SR:8606271497 CR:JAGae35704 ) After the system is up for more than 248 continuous days, paging performance decreases dramatically. Based on HP-UX patch PHKL_27994: ( SR:8606254033 CR:JAGae18365 ) This problem is limited to customers who have enabled the kernel preemption point feature. Whenever preemption is turned on, the system hangs intermittently for several minutes. Based on HP-UX patch PHKL_27919: ( SR:8606265366 CR:JAGae29684 ) System panic early in the boot process with "alloc_pdc_pages: real_page_alloc_addr() fails, status = -1" Based on HP-UX patch PHKL_27759: ( SR:8606268349 CR:JAGae32588 ) When the tunable maxswapchunks is manually set to a value higher than 16384, the system may panic with a stack trace similar to: mp_b_sema_sleep: blocking on owned semaphore panic+0x14 _mp_b_sema_sleep+0x88 hash_insert+0x144 addtocache+0x50 swapchunk+0x1ec devswap_pageout+0x1c0 stealpages+0x6c vhand+0x2a8 main+0xa04 $vstart+0x48 $locore+0x94 PHKL_27710: Ported HP-UX patch PHKL_27364 to VVOS Based on HP-UX patch PHKL_27364: ( SR:8606256133 CR:JAGae20448 ) In a multi-threaded process, if one thread is doing raw or character device I/O, other threads in the process may fail to make forward progress until the I/O completes. Based on HP-UX patch PHKL_27238: ( SR:8606237263 CR:JAGae06308 ) Requests for an exclusive mapping of a file in the 3rd quadrant fail for all executables with a private 3rd quadrant. Such executables are usually obtained through a chatr command with the parameter "+q3p enabled". Based on HP-UX patch PHKL_27157: ( SR:8606244346 CR:JAGae10833 ) A 32 bit process with the 3rd quadrant private (obtained with the command chattr +q3 enable) can obtain an incorrect address when requesting a large (~1 GB) mapping with the mmap(2) call. Observed symptoms are : -process aborted because of a memory fault (signals SIGBUS or SIGSEGV). -corruption of the memory for the calling process, including files that are mapped in memory by the process. System memory and memory from other processes are not impacted. Based on HP-UX patch PHKL_26800: ( SR:8606241742 CR:JAGae09000 ) Processes may hang uninterruptibly during filesystem access. The type of filesystem is irrelevant - the hang may occur on any block filesystem access. Once this process hang occurs, no other processes will be able to access the file system. Based on HP-UX patch PHKL_25906: ( SR:8606226665 CR:JAGad95728 ) On systems with large pages, the kernel can panic during the remapping of buffers from kernel to user (or vice versa). The panic stack trace may be similar to one of the following : panic+0x14 hdl_remap_bp+0x130 nfs_strat_map+0x84 nfs_strategy+0x3ac nfs3_strategy+0x18 ... copyin+0xac uiomove+0x3dc rw3vp+0x29c nfs3_write+0xf8 nfs3_rdwr+0xd8 vno_rw+0xb0 write+0x28c syscall+0x550 syscallrtn+0x0 or possibly panic+0x14 report_trap_or_int_and_panic+0x4c trap+0xa08 call_trap+0x38 div2I+0x15c hdl_remap_bp+0x29c ... nfs_biodone+0x3c async_daemon+0x38c coerce_scall_args+0x9c syscall+0x1c8 syscallrtn+0x0 Based on HP-UX patch PHKL_25525: ( SR:8606186963 CR:JAGad56173 ) On systems using NFS in loopback mode, there exists the possibility of the system hanging due to a deadlock between NFS daemons and inode locks held at the filesystem (VxFS) level. PHKL_26815: If alarm notification is enabled for Insufficient Privilege events (EPERM), an incomplete audit record for Insufficient Privilege can be reported in the logs. PHKL_25044: Ported HP-UX patch PHKL_25210 to VVOS Based on HP-UX patch PHKL_25210: ( SR:8606216082 CR:JAGad85253 ) During normal operation, the system may experience a "freevas: vas cnt 0, but still pointing to pregions" panic. The panic stack trace may be similar to: panic+0x14 freevas+0x140 freeproc+0x204 wait1+0x21c waitpid+0x34 syscall+0x1c8 $syscallrtn+0x0 ( SR:8606188767 CR:JAGad57983 ) When mmap is used with both the MAP_ANONYMOUS and MAP_GLOBAL flags, addresses allocated are in the 3rd quadrant instead of being in the 4th quadrant (shared quadrant) as requested by the MAP_GLOBAL flag. Based on HP-UX patch PHKL_25188: ( SR:8606194618 CR:JAGad63826 ) On K-Class and slower systems, Service Guard may TOC the system when a process that uses more than a gigabyte of memory exits. The stack trace of the TOC may look similar to the following: pdc_call+0x174 hversion_pdc_call+0xa4 diag2_ioctl+0x170c spec_ioctl+0xac vno_ioctl+0x90 ioctl+0x1e4 syscall+0x394 syscallinit+0x54c or pdc_call+0x198 pa_generic_psm_pdc_rtc+0x34 psi_rtc+0xb4 checkclock+0x24 invoke_callouts_for_self+0xc0 sw_service+0xb0 mp_ext_interrupt+0x150 ihandler+0x904 splnopreempt+0x8 idle+0x504 swidle+0x20 ( SR:8606137149 CR:JAGad06267 ) The system panics with a data memory protection fault when mmap(2) is used. The stack trace would look similar to the following: panic+0x14 report_trap_or_int_and_panic+0x84 trap+0x4b8 nokgdb+0x8 b_sema_enqueue+0x38 <... various other entries ...> hdl_changerange+0x238 hdl_mprotect+0x150 smmap_hole_anonymous+0x26c smmap_common+0x3bc smmap+0x1c0 syscall+0x9fc $syscallrtn+0x0 Based on HP-UX patch PHKL_25164: ( SR:8606204721 CR:JAGad73900 ) A HPMC may occur on T600 (9000/893) systems when cache flush code is executing. A stack trace may looks similar to the following: fdc_one_page_2_0+0x180 fdcache_conditionally+0x90 pdd_large_page2_0+0x1f0 pddpage+0x2d4 hdl_deletetrans+0xbc do_deltransc+0x118 for_val2+0xb4 foreach_chunk+0x3c hdl_detach+0x210 detachreg+0x80 kissofdeath+0x64 freethread+0x14c thread_deallocate+0x94 thread_free+0x94 wait1+0x244 waitpid+0x38 syscall+0x200 syscallinit+0x54c Based on HP-UX patch PHKL_24971: ( SR:8606195331 CR:JAGad64535 ) Doing memory management activities on a large memory segment which was registered using asynchronous I/O driver, would take higher number of CPU cycles. Based on HP-UX patch PHKL_24826: ( SR: 8606185728 CR: JAGad54930 ) Narrow mode (32bit) HP-UX 11.00 programs cannot mmap64() any part of a large file beyond the first 2GB. Based on HP-UX patch PHKL_24612: ( SR: 8606198933 CR: JAGad68122 ) Random process core dumps. Based on HP-UX patch PHKL_24457: ( SR: 8606180059, CR: JAGad49281 ) When using the asyncio driver, applications may exhibit slow startup time. ( SR: 8606179580, CR: JAGad48804 ) A system panic occurs on process termination, if the process had registered private memory segment with asyncio driver. The stack trace will appear as follows: crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x84 trap+0xd9c nokgdb+0x8 asyncdsk_close+0x94 call_open_close+0x1f8 closed+0xb0 spec_close+0x54 vn_close+0x48 vno_close+0x20 closef+0x64 exit+0x1108 psig+0x244 syscall+0x810 $syscallrtn+0x0 ( SR: 8606195629, CR: JAGad64833 ) Slow application startup when using asyncio driver ( SR: 8606199485, CR: JAGad68671 ) On systems experiencing low memory conditions, applications registering memory segments with asyncio driver may get "Not owner" (EPERM) error. Based on HP-UX patch PHKL_24273: ( SR:8606199847 CR:JAGad69033 ) A user creates a 64-bit program which mmaps a file 65536 times, then exists. It caused data page fault in freereg() when referencing the region whose r_refcnt overflowed since it's already freed and its fields are not valid any more. Stack trace looks like: panic+0x14 report_trap_or_int_and_panic+0x84 trap+0xd9c nokgdb+0x8 hdl_vfault+0x50 vfault+0xf8 trap+0x2a0 nokgdb+0x8 Based on HP-UX patch PHKL_24116: ( SR: 8606192498 DTS: JAGad61711 ) When the debugger is killed or sent a signal when trying to attach to a process, that process will be left in a hung state. Based on HP-UX patch PHKL_24015: ( SR: 8606192072 DTS: JAGad61280 ) When using memory windows and shared memory (IPC_SHARE32) between 32 and 64bit processes, the system may panic with an "hdl_pfault: invalid DBD for intransit page" panic. The stack trace may look like: panic+0x14 hdl_pfault+0x638 pfault+0x104 trap+0x724 thandler+0xd20 Based on HP-UX patch PHKL_23857: ( SR: 8606178349 DTS: JAGad47576 ) Data corruption can occur when Hyperfabric networking interface or async I/O driver is being used in the system. Based on HP-UX patch PHKL_23813: ( SR: 8606188675 DTS: JAGad57891 ) When booting 11.00 on a PA-8700 system, the system panics with the following message : panic: set_machine_parameters_64: Unidentified cpu type returned from PDC_MODEL Panic stack trace: PC-Offset Stack Trace (read down, top of stack is 1st): panic+0x54 set_machine_parameters_64+0x1f8 rm_setmachineparams_64+0x40 DoCalllist+0x50 RDB_patch_int_trap+0xb0 End Of Stack WARNING: Space ID hashing is disabled Based on HP-UX patch PHKL_23812: (SR: 8606183443 CR: JAGad52656) A multi-threaded process hangs and cannot be killed. This process will have been repeatedly mmap()ing parts of the same file, while at the same time reading or writing to it with the read(), write(), readv(), or writev() system calls from a different thread. That file must also be on a JFS file system. The Netscape Messaging Server's smtpd process is the only application we've seen do the particular combination of operations required to get into this state. PHKL_23886: Ported HP-UX patch PHKL_23628 to VVOS Based on HP-UX patch PHKL_23628: (SR: 8606146888 CR: JAGad16231) If the process core file's size limit has been set to 0 in setrlimit(), when the process aborts, the core processing is incorrect. Based on HP-UX patch PHKL_23406: (SR: 8606103740 CR: JAGab70789) (SR: 8606159451 CR: JAGad28779) A multi-threaded process being executed over NFS can become hung and unkillable while performing either a fork, core, setrlimit, SIGSTOP, or debugger operations. Based on HP-UX patch PHKL_23183: (SR: 8606169539 CR: JAGad38814) An application trying to do a PROBE instruction results in non-access reference to an invalid virtual memory address that causes the SIGSEGV handler to be removed. This makes an application program's own error-recovery useless and results in database crashes. Based on HP-UX patch PHKL_22843: (SR: 8606162188 CR: JAGad31504) The output of "ps -f" shows the name of the script being runs instead of the name of the '#!' interpreter. (SR: 8606168950 CR: JAGad38228) When the user exec a script w/o providing the arguments, the kernel does not exec the shell as it should be expected to do. For example, execve("./t.sh", 0) will not work. t.sh: ~~ #!/bin/ksh echo t.sh script executed OK. PHKL_23252: System panic while using audwrite on a MP system. Stack trace looks like: panic+0x14 report_trap_or_int_and_panic+0x4c trap+0xfbc $call_trap+0x38 audstub_getf+0xb4 getf+0x3c getf_no_ue+0x10 audprocinfo+0x134 audwrite+0x160 spec_rdwr+0x210 vno_rw+0x1d4 write+0x10c syscall+0x228 $syscallrtn+0x0 PHKL_22717: Ported HP-UX patch PHKL_22493 to VVOS Based on HP-UX patch PHKL_22493: (SR: 8606141875 CR: JAGad11229) When not running as root, adb will panic the system when an attempt is made to debug a kernel-threaded application in which the first thread is in a ZOMBIE state. panic: Data page fault stack trace for event 0 crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 handle_ooc_requests+0x2bc perform_trace_request+0x260 ttrace1+0x13c ptrace+0x78 syscall+0x480 $syscallrtn+0x0 Based on HP-UX patch PHKL_22032: (SR: 8606146888 CR: JAGad16231) Once-setuid/setgid processes could create corefiles or be attached to with a debugger. (SR: 8606146889 CR: JAGad16232) IDDS generated incorrect records in certain cases Based on HP-UX patch PHKL_21775: Some processes (eg . created by Shared LVM) never get reaped leading to proc table being filled and leading to a system hang. Based on HP-UX patch PHKL_21507: ( SR: 8606113684 CR: JAGac07198 ) system panics when doing crfree panic: crfree: freeing free credential struct Stack trace for crash event was : q4> trace event 0 stack trace for event 0 crash event was a panic panic+0x14 crfree+0xc4 kthread_shared_objects_update+0x30 syscall+0x594 $syscallrtn+0x0 Based on HP-UX patch PHKL_21358: ( SR: 8606132621 CR: JAGad01770 ) The Praesidium IDS/9000 product requires this patch in order to run. This patch has no impact on systems without the Praesidium IDS/9000 product installed and enabled. Based on HP-UX patch PHKL_21350: ( SR: 8606132613 CR: JAGad01762 ) The Praesidium IDS/9000 product requires this patch in order to run. This patch has no impact on systems without the Praesidium IDS/9000 product installed and enabled. Based on HP-UX patch PHKL_20439: ( SR: 8606109770 DTS: JAGaa45170 ) While running an MPI-based program, the system panics with a "Data page fault" or other memory-related fault. Based on HP-UX patch PHKL_20226: ( SR: 8606107525 DTS: JAGab77768 ) This patch is one of 8 patches necessary to add support for the 3 Gb private address space feature. Based on HP-UX patch PHKL_21535: ( SR: 8606100830 CR: JAGab39185 ) Application core files do not include the process' attached shared memory segments. Based on HP-UX patch PHKL_21357: ( SR: 8606132620 CR: JAGad01769 ) The Praesidium IDS/9000 product requires this patch in order to run. This patch has no impact on systems without the Praesidium IDS/9000 product installed and enabled. PHKL_23166: Ported HP-UX patch PHKL_22744 to VVOS Based on HP-UX patch PHKL_22744: ( SR: 8606161365 CR: JAGad30681 ) A system may experience a data page fault panic with the following stack trace: panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 thread_pcb_reinit+0x30 thread_alloc+0xe8 thread_create+0x2ac _lwp_create+0xdc syscall+0x480 $syscallrtn+0x0 Based on HP-UX patch PHKL_22549: ( SR: 8606128066 DTS: JAGab24436 ) Data page fault when trying to flush buffers which have already been invalidated: bwrite+0x44 bxwrite+0x44 syncip_flush_cache+01x1dc vx_flushdev+0x14 vx_fsync+0x248 spec_fsync+0x254. PHKL_22891: Ported HP-UX patch PHKL_22440 to VVOS Based on HP-UX patch PHKL_22440: ( SR: 8606154274 CR: JAGad23592 ) When trying to attach to a process that has been swapped out, both the tracing process and traced process hang and remain in an unkillable state. Based on HP-UX patch PHKL_22380: (SR: 8606130240 DTS: JAGac95111) Kernel paniced with data memory protection fault. This could happen when using direct I/O on JFS version 3.3 or in other situations. (SR:8606139945 DTS: JAGad09268) MP System hang under heavy I/O load. Based on HP-UX patch PHKL_22126: ( SR: 8606155209 DTS: JAGad24526 ) This patch is a replacement for the recalled patch PHKL_21624 which addressed a system hang caused by memory scrubber operating on shared memory segment used by the async I/O driver. The following problems were introduced by PHKL_21624 and are resolved by this patch. 1. System panic when both Hyperfabric networking interface and async I/O driver are used on the same system with PHKL_21624 installed. 2. Applications fail when trying to register shared segments with async I/O driver. On failure errno is set to EPERM. ( SR: 8606143996 DTS: JAGad13329 ) Excessive delay in database connect time for database user processes. Based on HP-UX patch PHKL_21781: (SR: 8606137220 DTS: JAGad06338) when a user application makes a large number (over 65535) of mprotect(2) calls, it fails with ENOSPC - No space left on device. (SR: 8606136222 DTS: JAGad05348) When sendfile_max is configured to be > 0, and when using ftp or rcp to transfer data, we encounter a spinlock deadlock panic in sendfile_hold(). A stack trace will look similar to: panic spin_deadlock_failure deadlock_check sl_pre_check spinlock sendfile_hold sosendfile sendfile syscall Based on HP-UX patch PHKL_21624: (SR: 8606124290 DTS: JAGac39673) Memory scrubber (memlogd) causes system hang while scrubbing pages locked by async driver. The async driver is typically used by database applications. ( SR: CR: JAGab16247 ) HP-UX does not support an interface that allows a driver to lock user space memory on behalf of a user process in such a way that prevents the user process from unlocking the memory. Such a mechanism is required to enable DMA to user space memory by the operating system (a driver). Based on HP-UX patch PHKL_21600: (SR: 8606134430 DTS: JAGad03565) When using mmap with a negative offset or an offset greater than 243, the system panics. Based on HP-UX patch PHKL_20647: (SR: 8606107024 DTS: JAGab76631) System hang in b_sema_get_queue() when doing an munmap(). Based on HP-UX patch PHKL_20449: (SR: 8606106816 DTS: JAGab76230) Incorrect implementation of mmap(2) can cause system panics. Based on HP-UX patch PHKL_20223: ( SR: 8606103245 DTS: JAGab69733) The system will panic with the following message: panic: Returning ID that is already free. ( SR: 8606107525 DTS: JAGab77768) This patch is one of 8 patches necessary to add support for the 3 Gb private address space feature. PHKL_21306: Ported HP-UX patch PHKL_21532 to VVOS Based on HP-UX patch PHKL_21532: ( SR: 8606131990 CR: JAGad01139 ) Approximately every 22 minutes, the system, or one cpu of a multi-processor system, appears to hang for several minutes. Then the problem goes away. This primarily affects larger memory systems. Based on HP-UX patch PHKL_21354: ( SR: 8606132598 CR: JAGad01747 ) After PHKL_21003 is installed on a V2500 or V2600 with at least 24 CPUs and at least 24 GB of memory, the system fails to boot. One symptom that has been observed is the following message displayed during the boot process: Error found : - mem_toc zero error encountered. ( SR: 8606132617 CR: JAGad01766 ) The Praesidium IDS/9000 product requires this patch in order to run. This change has no impact on systems without the Praesidium IDS/9000 product installed and enabled. Based on HP-UX patch PHKL_21024: ( SR: 8606112164 DTS: JAGab84450 ) Enhancement: Performance changes for corner case in RTSCHED scheduling. This patch has no impact on most systems. Based on HP-UX patch PHKL_21003: ( SR: 8606112473 CR: JAGab84822 ) V2500 with more than 24GB of memory and more than 24 processors takes a long time (>30min) to boot. Based on HP-UX patch PHKL_20335: ( SR: 8606106466 DTS: JAGab75600) Unlinked files within NFS filesystems sometimes leave behind .nfsXXX files which are unremovable until after the system is rebooted. ( SR: 8606107384 DTS: JAGab77587) Panic or data corruption due to buffer cache buffers being released multiple times. ( SR: 8606108724 DTS: JAGab78191) Memory corruption after copying growing files over the network multiple times. Based on HP-UX patch PHKL_20222: ( SR: 8606107507 DTS: JAGab77743) This patch adds support for the PA-8600 processor. ( SR: 8606107525 DTS: JAGab77768) This patch is one of 8 patches necessary to add support for the 3 Gb private address space feature. Based on HP-UX patch PHKL_20102: ( SR: 8606106969 DTS: JAGaa45096 ) On systems with 5GB of memory or more, the system will allocate memory for a static table that it does not use. This affects 64-bit systems only. Based on HP-UX patch PHKL_20017: ( SR: 8606104415 DTS: JAGab71916) After installing PHKL_19314, I/O performance of the system drops substantially. ( SR: 8606103778 CR: JAGab70853 ) 64bit systems with large amount of memory (e.g. 32Gb) and having large buffer cache (e.g. 8Gb) configured find the syslog is flooded with the following error message: vmunix : bufmap : rmap : ovflo, lost [xx..)(xx..] Based on HP-UX patch PHKL_19314: ( SR: 4701426775 DTS: JAGab17440 ) On a system with a large number of processors (more than 14) a hang can occur during boot and after displaying the following messages: Starting the STREAMS daemons-phase1 Checking root filesystem log replay in progress replay complete - marking super-block clean Root check done Create STCP device files ( SR: 8606101604 DTS: JAGab15954) Attempting to resume from a breakpoint when running a program under a debugger will cause the program to get a segmentation violation. This has been seen on G-class systems but it can occur on any system with block-tlb. Based on HP-UX patch PHKL_19201: SR: 8606100898 DTS: JAGab39707 A user sees a hang while using snapshot file systems. Stack trace: _swtch+0xd4 _sleep_one+0x538 vx_sleep_lock+0xd0 vx_snap_bpcopy+0xf4 vx_snap_copyblk+0x144 vx_snap_copy+0x50 vx_snap_strategy+0x280 vx_buf_strategy+0x24 bwrite+0xe0 getnewbuf+0x918 allocbuf1+0x234 brealloc1+0x5c getblk1+0x2fc vx_snap_getblk+0x2c vx_snap_getblkbp+0x140 vx_snap_lookup+0x1c vx_snap_bpcopy+0x110 vx_snap_copyblk+0x144 vx_snap_copy+0x50 vx_snap_strategy+0x280 vx_buf_strategy+0x24 bwrite+0xe0 getnewbuf+0x918 ogetblk+0x110 getblk1+0x290 vx_getblk+0x50 vx_bread+0x68 vx_iread+0x88 vx_real_iget+0x398 vx_iget+0x3c vx_dirlook+0x23c vx_lookup+0x120 locallookuppn+0xd4 lookuppn+0xf8 lookupname+0x40 vn_open+0x68 copen+0xd0 open+0x3c syscall+0x480 $syscallrtn+0x0 PHKL_20559: The command 'auditcmd -e' never returns to the prompt. PHKL_20127: Poor performance. PHKL_19440: Ported HP-UX patch PHKL_17038 to VVOS Based on HP-UX patch PHKL_17038: The system will trap 15 data page fault when tracing for leaks without also tracing for corruption. Based on HP-UX patch PHKL_20945: ( SR: 8606112164 DTS: JAGab84450 ) Enhancement: Performance changes for corner case in RTSCHED scheduling. This patch has no impact on most systems. Based on HP-UX patch PHKL_20995: ( SR: 8606127692 CR: JAGac78494 ) Programs using "memory windows" (started via setmemwindow) will not be able to allocate more than 1 Gb of shared memory (1 Gb total for all memory windows processes, i.e. this is not a per process limit). This patch is a replacement for PHKL_20227, which introduced the bug that this patch fixes. Based on HP-UX patch PHKL_20836: ( SR: 8606106781 CR: JAGab76169 ) Application issuing large amount of mmap calls to map multiple virtual addresses to the same physical page (using flags MAP_SHARED|MAP_FILE|MAP_FIXED) may cause system panic with the follow stack trace: panic: hdl_zero_page: page not mapped panic+0x14 hdl_zero_page+0xc8 virtual_fault+0x418 vfault+0x118 trap+0x280 nokgdb+0x8 Trace on other processor shows: panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xde8 nokgdb+0x8 allocpfd_from_pond+0x134 allocate_page+0x68 lgpg_vfdfill+0x4c virtual_fault+0xc3c vfault+0x118 trap+0x280 nokgdb+0x8 Based on HP-UX patch PHKL_20227: ( SR: 8606107525 CR: JAGab77768 ) This patch is one of 8 patches necessary to add support for the 3 Gb private address space feature. Based on HP-UX patch PHKL_20224: ( SR: 8606107525 CR: JAGab77768 ) This patch is one of 8 patches necessary to add support for the 3 Gb private address space feature. Based on HP-UX patch PHKL_20515: (SR: 8606101315, CR: JAGab46368) System hang while using async I/O module through database applications with new large block I/O feature when system is low on memory resources. (SR: 8606100970, CR: JAGab39977) Data pagefault during async I/O operations when an I/O is being done to an unregistered (private) memory. (SR:8606103126, CR: JAGab69473) System hang can occur during async I/O operations when an IO is being done to an unregistered (private) memory segment designated by the user's IO buffer. (SR: 8606102862, CR: JAGab68892) Async driver can hang during async IO with requests larger than MAXPHYS (allowing async I/O larger than MAXPHYS is a new feature available in this patch, where MAXPHYS = 256KB). (SR: 8606108814, CR: JAGab81517) Async driver I/O completion notifications don't work when used in conjunction with select(2) system call. Based on HP-UX patch PHKL_20426: When a multithreaded process does file I/O concurrently with mmap() or munmap() on the same file, it can result in a single process deadlock. This process is not killable. Defect Description: PHKL_29760: Ported HP-UX patch PHKL_28766 to VVOS Based on HP-UX patch PHKL_28766: ( SR:8606279968 CR:JAGae43943 ) A rare race condition can occur while unmapping a shared libraries using large pages. Another mmap of the same file can sneak in the time window and get large pages left over from the original mapping. If the address obtained by the second mapper is not aligned with the large page, that breaks an assumption regarding large page alignment, and various system panics can occur. The problem is the second mapper should not get the left over large pages from the first mapping. A panic can occur when the second mapper takes a page fault and tries to add a translation or when someone tries to do munmaps later on. Resolution: The fix detects the panic'ing condition in the fault path and demotes the large page as necessary. This alleviates the large page alignment issues. Based on HP-UX patch PHKL_28180: ( SR:8606272341 CR:JAGae36480 ) This defect occurs only on a 32-bit HP-UX kernel. The message "vmunix: Clock_int: tick arrived early" is logged when : 1) Clock interrupt arrives early (due to hardware fault). 2) If a certain number of processor ticks are missed before the next clock interrupt is handled. To be precise, if more than 0x7FFFFFFF processor ticks are missed, this message is logged. Resolution: For the first case, no change is required. The message should be logged in case of a hardware fault. For the second case, a proper comparision of current clock interrupt arrival time and expected clock interrupt arrival time is performed. Based on HP-UX patch PHKL_28053: ( SR:8606271497 CR:JAGae35704 ) After 248 days, one of the data types used in the paging calculations overflows, resulting in decreased paging performance. Resolution: Modified the paging calculations to accommodate overflow. Based on HP-UX patch PHKL_27994: ( SR:8606254033 CR:JAGae18365 ) Preemption feature does not scale well with large memory objects. So, vhand is affected when working on those objects and may slow down significantly. This leads to the system being unresponsive for several minutes. Resolution: Remove some unnecessary checking for preemption, thus improving the performance of vhand for large objects. This does not take away the effectiveness of the preemption feature. Based on HP-UX patch PHKL_27919: ( SR:8606265366 CR:JAGae29684 ) If relocating PDC from ROM to main memory fails due to bad physical memory, the system panics. The panic message does not adequately describe the reason for the panic. Resolution: Made alloc_pdc_pages more flexible. If an allocation attempt fails, the requested memory range will be shifted to a lower range of address. This will continue until a successful allocation, or if 16 attempts are made the system will panic. The panic message is improved by providing additional information. Based on HP-UX patch PHKL_27759: ( SR:8606268349 CR:JAGae32588 ) The internal swap table is sized on the value of the maxswapchunks tunable. However, the maximum value of the index used to access the swap table is 16384. If SAM is used to build a kernel, the maximum value of 16384 for maxswapchunks is enforced, but if the system file is edited and a new kernel built manually, there were no checks on the size of maxswapchunks. If the value was above 16384, the swap table would be sized too large for the index and multiple virtual pages could be allocated to the same swap block, resulting in the panic. Resolution: We now check the value of maxswapchunks at boot time and limit it to the maximum value of 16384. PHKL_27710: Ported HP-UX patch PHKL_27364 to VVOS Based on HP-UX patch PHKL_27364: ( SR:8606256133 CR:JAGae20448 ) The raw I/O routine was holding the process' virtual address space (vas) lock for the duration of the I/O, even though it was not needed for the normal case and only rarely needed for an exception case. This effectively blocked any other thread in the process which needed access to the vas lock, such as for another I/O, thread creation, mmap, thread exit, etc., for the duration of the I/O. When the I/O was to a slow device, such as a tape drive, this could be a considerable delay. Resolution: Eliminated use of the vas lock in the normal raw or character device I/O path, retaining its usage only for the rare exception case. Based on HP-UX patch PHKL_27238: ( SR:8606237263 CR:JAGae06308 ) The parameter checking code in mmap incorrectly rejects requests with the MAP_EXCLUSIVE flag, for the 3rd quadrant regardless if this quadrant is private or not. Resolution: The mmap code has been modified to accept exclusive mappings in the 3rd quadrant when it is private. Based on HP-UX patch PHKL_27157: ( SR:8606244346 CR:JAGae10833 ) On 64 bit systems, calls to mmap(2) by 32 bit processes with sizes in the range of 1 GB or greater cause the allocation algorithm to allocate a segment in the 64 bit address space instead of the 32 bit address space. The 64 bit address is truncated to 32 bits on return to the 32 bit calling process. The cause of this error is an incorrect boundaries checking in the allocation algorithm. When using a debugger, one can observe a 64 bit segment in the process address space. Resolution: The allocation algorithm now checks boundary conditions correctly, producing a correct memory address. Based on HP-UX patch PHKL_26800: ( SR:8606241742 CR:JAGae09000 ) The problem is caused by a thread/process waiting on a buffer that it incorrectly believes is still owned by another process. The previous process failed to update the internal data structure used to show that the buffer is no longer in use. The new process sees this stale information, goes to sleep believing that the buffer is still in use, and never wakes up, which results in a filesystem hang. This was seen with a process accessing a VxFS 3.3 filessytem with Veritas NetBackup running. However, this defect is not specific to any one filesystem; it applies to all block filesystem access. Resolution: Changed the code to modify the internal data to indicate the buffer is no longer in use before releasing the buffer and doing the wakeup. Based on HP-UX patch PHKL_25906: ( SR:8606226665 CR:JAGad95728 ) When the remapping of a large page based buffer occurs, its boundaries are adjusted to match the large page. The round up of the boundaries was incorrect causing the kernel to fault during the remapping. Resolution: The adjustment of large pages aligned boundaries is modified to ensure the correct remapping of large page based buffers. Based on HP-UX patch PHKL_25525: ( SR:8606186963 CR:JAGad56173 ) An NFS daemon (nfsd) grabs a directory inode lock and then tries to acquire a free buffer from the buffer-cache. For this new buffer, a reference release (vn_rele) must first be performed for the old vnode associated with the buffer. This vn_rele causes a .nfsXXX file removal to occur. A second nfsd attempts to perform the file removal, but in order to do so it must acquire the same directory inode lock that the first nfsd is holding. This deadlock ultimately effects other processes that start getting blocked behind the directory inode until the system gradually grinds to a halt. Resolution: The buffer-cache code will change to ensure that no invalid NFS buffers remain in the cache with associated vnodes thereby eliminating the potential of a locking deadlock occurring. PHKL_26815: A condition exists in the audit subsystem where the getluid() system call returns an EPERM error code in a nonerror situation (when the luid is not set for the process). This event is not reported properly in the reduce output. Resolution: The audit subsystem will not generate a record in the case of a getluid() call when the luid is not set. PHKL_25044: Ported HP-UX patch PHKL_25210 to VVOS Based on HP-UX patch PHKL_25210: ( SR:8606216082 CR:JAGad85253 ) The vas was corrupted due to unprotected modifications of the vas reference count on a vfork. Resolution: Lock the vas during modification of the vas reference count. ( SR:8606188767 CR:JAGad57983 ) The mmap system call does not take the MAP_GLOBAL flag into account when used in combination with the MAP_ANONYMOUS flag. Resolution: Check for the MAP_GLOBAL flag in mmap when the MAP_ANONYMOUS flag is used, and allocate the address in the proper quadrant (4th). Based on HP-UX patch PHKL_25188: ( SR:8606194618 CR:JAGad63826 ) The problem is caused by an exiting process flooding the bus with cache flush instructions. This in turn may cause processes executing firmware code to wait until the exiting process is finished before continuing. If the Service Guard process is scheduled behind the process executing the firmware code, the Service Guard process may not have the chance to run for many seconds, causing it to TOC the system when it does eventually run. Resolution: The exiting process now does its cache flushing less aggressively and allows processes executing firmware code to run at the same time. If such processes are allowed to run, the Service Guard process scheduled after those processes will be able to maintain contact with the other Service Guard nodes in the cluster and it will not TOC the system. ( SR:8606137149 CR:JAGad06267 ) There is an invalid boundary check in the mmap(2) system call that allows protections to be set outside a valid range of pages. This causes a panic when subsequent mmap(2), mprotect(2), or munmap(2) calls are made on the same range of adresses. Resolution: The mmap(2) system call now correctly checks the boundaries of the range of adresses before applying a mprotect operation on them. Based on HP-UX patch PHKL_25164: ( SR:8606204721 CR:JAGad73900 ) This defect is caused by JAVA chip arbitration bug. This bug favors the sequential cache flush code over memory access requests and outstanding I/O requests (from FWSCSI) will time out and cause an HPMC. Resolution: The sequential cache flush code was modified to periodically provide a time slot for the I/O requests to finish. Based on HP-UX patch PHKL_24971: ( SR:8606195331 CR:JAGad64535 ) Upon removing the last process reference to a shared memory segment on a memory unlock, the segment is demoted from 64MB pages to 4K pages. Any subsequent attempts to manage this segment take considerable amount of time as the number of page management structures has now been increased by 16K times. Resolution: Do not demote the largepages on doing a memory unlock. Based on HP-UX patch PHKL_24826: ( SR: 8606185728 CR: JAGad54930 ) The kernel code was limited by design to allow narrow mode mmap64() to 2GB or less only. Resolution: The kernel was enhanced to remove this limitation. Narrow mode mmap64() can now map up to 4GB. Based on HP-UX patch PHKL_24612: ( SR: 8606198933 CR: JAGad68122 ) The VM subsystem was not correctly handling self-modifying code pages that were not initially mapped with execute access. There was a possibility that execute access could be removed, leaving stale data in the instruction cache. When the page was subsequently reused by another process, it would fault on the stale instruction cache data. Resolution: If a page has execute access, retain the execute access when adding a new translation. This ensures the data is flushed from the instruction cache upon page deallocation. Based on HP-UX patch PHKL_24457: ( SR: 8606180059, CR: JAGad49281 ) Before starting I/O's through the asyncio driver, applications must register shared memory segments with the driver. As part of the registration, the driver locks the memory. If this operation needs to be done for a very large memory segment, the locking may take a significant amount of time, resulting in slow application startup. Resolution: The async driver now supports a new device file minor number 256. If an application uses the async device file with this new minor number, the driver will defer locking the memory until I/O's are issued. This avoids the overhead of memory setup time and thus reduces the application startup time. Note: This minor number should only be used on systems that have enough physical memory so that paging is avoided. Paging can cause serious performance degradation with this new enhancement. On systems where paging is an issue, this minor number should not be used. ( SR: 8606179580, CR: JAGad48804 ) When process that registered private memory with asyncio driver terminates, the memory management subsystem cleans the associated data structure. The asyncio driver tries to dereference a pointer to one of these data structures that has already been freed causing the system to panic. Resolution: The driver returns bad address (EFAULT) if any application tries to register a private memory segment. ( SR: 8606195629, CR: JAGad64833 ) The asyncio driver checks for the user access rights twice. This duplication of access rights check contributes to slow application startup. Resolution: The redundant access rights check is removed. ( SR: 8606199485, CR: JAGad68671 ) The asyncio driver propagates the wrong error code to the application when a memory locking function fails due to low memory conditions. Resolution The appropriate error code is returned to the application. Based on HP-UX patch PHKL_24273: ( SR:8606199847 CR:JAGad69033 ) The system panic's while trying to mmap() more than the maximum allowed limit of pregions to a shared region. (limited by r_refcnt, which is of type ushort). This was caused by r_refcnt overflow which caused it to reset. If a program mmap's more than this limit, the counter r_refcnt overflow which causes the system to panic. Resolution: The fix is to check for the overflow and return ENOMEM. Based on HP-UX patch PHKL_24116: ( SR: 8606192498 DTS: JAGad61711 ) If the debugger is interrupted while trying to attach to a single threaded process that is sleeping uninterruptibly, it will return to the user without unsuspending the debuggee so the debuggee's suspend count is not decremented and the debuggee will be suspended forever. Resolution: ttrace_prepare_attach() now checks the return from the sleep of the debugger. If the sleep returns an error, we know that the debugger has been interrupted by someone else other than the debuggee so we decrement the suspend count of the debuggee. Based on HP-UX patch PHKL_24015: ( SR: 8606192072 DTS: JAGad61280 ) A 64bit process cannot map into a private memory window - it can only map into the global memory window of the 32bit virtual space. A 32bit process needing to share with a 64bit process must either be mapped into the global memory window or the object to be shared must be marked IPC_GLOBAL. These rules were not being enforced, resulting in incorrect space id assignment for shared memory (IPC_SHARE32) allocated in a private memory window. Resolution: Shared memory (IPC_SHARE32) allocated in a private memory window is now remapped into the global memory window when sharing with a 64bit process. Based on HP-UX patch PHKL_23857: ( SR: 8606178349 DTS: JAGad47576 ) Kernel sub-systems such as Hyperfabric networking interface and async I/O expect to be notified when a translation for a page changes that they are using for DMA. The virtual memory system uses the cluster-interconnect flag to determine if such sub-systems should be notified when the translation changes. If there are two different kernel-locked ranges in the same largepage, the unlocking of first locked range causes the cluster-interconnect flag for that page to be cleared, even though there is another locked range in the same page. This could cause a DMA operation to occur on the wrong page, resulting in data corruption, if sub-systems continued to do DMA on that page. Resolution: A check is added to see if there are other kernel-locked ranges in the same largepage before clearing the cluster-interconnect flag. Based on HP-UX patch PHKL_23813: ( SR: 8606188675 DTS: JAGad57891 ) 11.00 does not recognize the PA-8700 processor. Additionally, the PA-8700 processor is not IO-PDIR coherent. Resolution: This patch, PHKL_23813, is one of three 11.00 PA-8700 enablement patches. The other 11.00 PA-8700 enablement patches are PHKL_23814 & PHKL_23815. To support 11.00 on PA-8700, the following changes were made : - Added code to recognize the PA-8700 processor. - Added code to check if non-coherent IO-PDIR is set and performed flushes and syncs whenever IO-PDIR is changed. - Fixed inverted space hash mask to enable the PA-8700 processor. Based on HP-UX patch PHKL_23812: (SR: 8606183443 CR: JAGad52656) This problem was caused by a lock ordering problem between VM and JFS. JFS can call VM while holding an inode lock; the routines called may require a vas lock. VM can call JFS while holding a vas lock; the routines called may require an inode lock. If we get unlucky, we hit the same vas/inode lock combination from both directions, and the threads deadlock. Because the vas lock potentially held by VM is a per process resource, this situation can only be encountered by a multithreaded process. Resolution: The fix is to have the VM routine drop the vas lock before calling the file system code; fortunately, the VM routine can safely drop and reacquire the lock around the call ... it was mostly holding it to avoid dropping and reacquiring it repeatedly in a loop. PHKL_23886: Ported HP-UX patch PHKL_23628 to VVOS Based on HP-UX patch PHKL_23628: (SR: 8606146888 CR: JAGad16231) If the process core file's size limit has been set to 0 in setrlimit(), when the process aborts, the core processing is incorrect. Resolution: If the process core file size limit has been set to zero, don't create a core file. Based on HP-UX patch PHKL_23406: (SR: 8606103740 CR: JAGab70789) (SR: 8606159451 CR: JAGad28779) A thread acquires a lock and then sleeps interruptibly. The interruptible sleep permits the thread to be stopped. Any other thread attempting to acquire this lock will sleep uninterruptably until the lock is available. This uninterruptable thread is also unkillable. This introduces a deadlock potential in multi-threaded processes: when a thread holding the lock, a thread desiring the lock, and a third thread doing one of fork, setrlimit, core, SIGSTOP, or debugger optionations, all occur at the same time in the same process, the deadlock is reached. The only way to resolve the deadlock is to reboot the system. This patch is part of a set of four patches (PHKL_23406, PHKL_23407,PHKL_23408,PHKL_23409) that enable P_NOSTOP, a new feature that prevents a process from being unkillable. Each patch is independantly installable. Without all four installed, P_NOSTOP will be unavailable. In order to prevent the process executed over NFS from becoming unkillable, NFS must use the P_NOSTOP feature. An NFS patch using P_NOSTOP, PHNE_23249, will be released in Spring of 2001. Resolution: If a thread acquires a lock and then sleeps interruptably, it is not permitted to be stopped if P_NOSTOP is set. This prevents this thread from becoming unkillable and prevents the deadlock. Based on HP-UX patch PHKL_23183: (SR: 8606169539 CR: JAGad38814) The check to unblock the signal handler was being done too early inside grow(). This resulted in removal of the signal handler specified by the application program. Resolution: The fix is to move the unblock signal out of grow() into hdl_vfault() which then calls grow() at a later stage. Based on HP-UX patch PHKL_22843: (SR: 8606162188 CR: JAGad31504) When an interpreter is invoked via a shell script, the script name is mistakenly passed to the kernel as the first argument (argv[0) instead of the interpreter name. Resolution: When an interpreter was being invoked via a shell script, we passed the interpreter to the kernel as the first argument instead of passing user's argv[0], which is the script name. (SR: 8606168950 CR: JAGad38228) When user exec a shell script w/o supplying arguments at all, the kernel failed to account for the extra argument for the name of the script into the number of arguments to be passed to the kernel. Also, it failed to pass the interpreter to the kernel as the first argument to be executed. Resolution: When user exec a shell script w/o supplying arguments at all, the kernel bumps up argc by 1, to account for the extra argument that we will be adding later via via the function setup_shell_argv(). It also passes the shell name to the kernel as the first argument, instead of the script name. PHKL_23252: During the generation of the audit record, audprocinfo walks all the process' file descriptors to see if it can get any info on them. Some fd's are not completely closed or open, specially when the process has many threads creating and opening sockets. The panic occurs because the audstub_getf function finds a valid fp that has no f_data yet, but the function assumes that f_data is always valid. Resolution: Checking for non null values of fp and f_data before use. PHKL_22717: Ported HP-UX patch PHKL_22493 to VVOS Based on HP-UX patch PHKL_22493: (SR: 8606141875 CR: JAGad11229) When the debugged process initializes each thread's data pointer, if the thread is in a ZOMBIE state, that thead is not initialized, leaving the data pointer NULL. Later, adb attempts to dereference the NULL pointer, causing a data page fault panic. Resolution: Initialize the data pointer for all debugged threads, including those in a ZOMBIE state. Based on HP-UX patch PHKL_22032: (SR: 8606146888 CR: JAGad16231) If a setuid/setgid process completely dropped privileges, it could create a core file on a subsequent error, and could be attached to with a debugger. (SR: 8606146889 CR: JAGad16232) Some process management system calls generated incorrect IDDS records. Resolution: (SR: 8606146888 CR: JAGad16231) Remember that the process was once setuid/setgid, and disallow corefiles and debugger attaches. (SR: 8606146889 CR: JAGad16232) Fix the generated records. Based on HP-UX patch PHKL_21775: Resolution :PM internal function prepare_to_reap_proc in kern_exit.c changed to reap system processes correctly . Based on HP-UX patch PHKL_21507: ( SR: 8606113684 CR: JAGac07198 ) Analysis of dump showed that we are attempting to free a credential structure but credential refrence count is already 0 indicating it was already freed. Resolution: Locking of credentials operations were protected by sched_lock so that credential operations are done properly. Based on HP-UX patch PHKL_21358: ( SR: 8606132621 CR: JAGad01770 ) This patch is one of 16 patches (PHKL_21348-PHKL_21363) required by the Praesidium IDS/9000 product. These patches enable the collection and tracking of information from various system calls. Unless all of the enabling patches (or their successors) and the product are installed, and the product is enabled, this patch has no impact on the system. Resolution: This patch enables the gathering of information from the various uid and gid related system calls. Based on HP-UX patch PHKL_21350: ( SR: 8606132613 CR: JAGad01762 ) This patch is one of 16 patches (PHKL_21348-PHKL_21363) required by the Praesidium IDS/9000 product. These patches enable the collection and tracking of information from various system calls. Unless all of the enabling patches (or their successors) and the product are installed, and the product is enabled, this patch has no impact on the system. Resolution: This patch enables the gathering of information from the exec*() and exit() system calls. Based on HP-UX patch PHKL_20439: ( SR: 8606109770 DTS: JAGaa45170 ) In the process to process memory copy routines, there were a number of race conditions and memory leaks. These led to system panics. Resolution: Made structural changes to locking logic to avoid these race conditions and fixed the memory leaks. Based on HP-UX patch PHKL_20226: ( SR: 8606107525 DTS: JAGab77768 ) This is one of 8 patches necessary to add support for the 3 Gb private address space feature. This feature allows a process to have a private 3rd quadrant (normally the 3rd quadrant, which is a 1 Gb range of address space from 0x80000000 to 0xC0000000, is used for shared objects). The chatr command must be used to enable this feature for an executable (chatr +q3p enable ). Note that this feature is only enabled for 32 bit processes running on the 64 bit version of HP-UX. The other 7 patches necessary to enable this feature are PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20227, PHKL_20228 and PHKL_20229. Each patch may be installed independently of the others - if enabling the 3 Gb private address space feature is not desired. If fewer than all 8 patches are installed, the 3 Gb private address space feature will not be enabled. The code in this patch that is part of this feature will not have any impact on the system until all 8 patches are installed. Resolution: A subset of the code to support the 3 Gb private address space feature was added. When all 8 patches are installed the following code changes to support this feature will have been added: 1) Code to recognize the request for a private 3rd quadrant (Q3) during exec() of an executable. An executable that requests a private 3rd quadrant will be referred to as a q3p process below. 2) Code to prevent allocation of shared objects in q3p processes. 3) Code to allow data to extend over the 2nd/3rd quadrant boundary for q3p processes. 4) Code to put the stack for the primary thread in the 3rd quadrant for q3p processes. 5) Code to map a shared library into the private address space if there is no more room in the 4th shared quadrant for q3p processes. Based on HP-UX patch PHKL_21535: ( SR: 8606100830 CR: JAGab39185 ) This patch corrects application core dump behavior by allowing dumping of a process' attached shared memory segments to the application core file. This patch has no impact on the system unless shared memory dumping is enabled. See the Special Installation Instructions section for details on how to enable shared memory dumping after installing this patch. A word of caution: After shared memory dumping is enabled, the new system-wide core dump behavior for applications will be to include attached shared memory segments to application core files. This may not be the desired behavior if you have applications that use large shared memory segments running on the system. (eg database applications). If those applications core dump, the core files will include their attached shared memory segments. Thus, they can be very large files. Do not enable shared memory dumping after installing this patch if you do not want this behavior. Resolution: This patch enables shared memory dumping in the coredump generation code when kernel global variables core_addshmem_read and/or core_addshmem_write are set to 1. If both of these variables are set to 0, their default value, this patch has no impact on the system. Based on HP-UX patch PHKL_21357: ( SR: 8606132620 CR: JAGad01769 ) This patch is one of 16 patches (PHKL_21348-PHKL_21363) required by the Praesidium IDS/9000 product. These patches enable the collection and tracking of information from various system calls. Unless all of the enabling patches (or their successors) and the product are installed, and the product is enabled, this patch has no impact on the system. Resolution: This patch enables the gathering of information from the corefile generation code. PHKL_23166: Ported HP-UX patch PHKL_22744 to VVOS Based on HP-UX patch PHKL_22744: ( SR: 8606161365 CR: JAGad30681 ) A pregion lookup is done based on the thread id. Thread id's are cached, so on systems with many threads configured and running, the thread id may be stale, i.e. reused by another thread. In this case, the wrong pregion is returned. Resolution: Use the thread pregion pointer to access the pregion instead of the thread id. Based on HP-UX patch PHKL_22549: ( SR: 8606128066 DTS: JAGab24436 ) When syncing buffers for a particular device the routine that scans the cache for dirty buffers was not checking whether the buffers were valid. Those buffers that were invalid would no longer have a vnode pointer associated with them which in turn would cause a data page fault when they were passed to bwrite(). Resolution: The routine responsible for flushing buffers corresponding to an individual inode will now ensure that only valid buffers are attempted to be flushed. PHKL_22891: Ported HP-UX patch PHKL_22440 to VVOS Based on HP-UX patch PHKL_22440: ( SR: 8606154274 CR: JAGad23592 ) The kernel debug thread is responsible for receiving and executing the debugger commands. This is a daemon thread which is invisible to the user application and is not part of the thread list of the proc stucuture. Hence while the process is being swapped this thread is not put on the run queue even if it were in run state. Since the debug thread is not reactivated when the procces it is attached to is swapped back in, both it and the attached process hang. Resolution: Explicitly start the debug thread (if it has been created) when the process is swapped in. Based on HP-UX patch PHKL_22380: (SR: 8606130240 CR: JAGac95111) The kernel driver creates an anonymous private mapping with read-only protection and calls mprotect() to change the access right to 'read-write'. Before the dirver tries to write, it calls vaslockpages to lock those pages down. vaslockpages did not set the correct access right for the mprotected pages. Resolution: Changed kernel to set up the translation with corrent access right. (SR:8606139945 DTS: JAGad09268) In the original design, when allocating/freeing a buffer, it only does a sleep/wakeup on the list for the current CPU. Processes sleeping from another CPU will not be awakened. The result, seen in the dump of a hang, is dozens of processes sleeping on an empty per-processor queue. Resolution: The design has been changed as follows: When allocating a buffer, first try to allocate from the cpu's own list, if fail, allocate from global list, if still fail, steal from each processor's list back to global list, then try allocate from global list; if still fail, sleep on global list. When freeing the buffer, if my cpu list's number of free buffers is smaller than global list's, free it to my list, else free it to global list, and wakes up sleepers on the global list. Based on HP-UX patch PHKL_22126: ( SR: 8606155209 DTS: JAGad24526 ) 1. The problem was tied to the use of the global variables used by legacy HyperFabric driver, the driver assumed that they are kernel global function pointers owned by HyperFabric and were initialized to NULL in the driver init routine. PHKL_21624 initializes (at compile time) the same function pointers to the address of a new set of kernel funtions that VM uses for calling all registered callback functions. Resolution: Replace the references to the global function pointers in VM code with new symbol names, thus leaving the original symbols initialized to NULL as the legacy HyperFabric driver expects. 2. PHKL_21624 addressed a problem of system hang caused by memory scrubber working on shared memory segments used by the async I/O driver. To fix this problem, the change required applications using async I/O driver to have MLOCK privilege. This fact was not documented in PHKL_21624 and caused application using async I/O driver to fail. Resolution: Applications that use the async I/O driver must belong to a group having MLOCK privilege. Refer to the section "Special Installation Instructions" for details on how to check and set MLOCK privilege. ( SR: 8606143996 DTS: JAGad13329 During internal testing with PHKL_21624 using 8GB shared memory segment and 300 user processes that were tyring to connect to the database at the same time, we found that the database user processes had an excessive database connect delay. Each user process that connects to the database registers memory with the async I/O driver which in turn locks the memory so that if the address translation for that memory is ever changed by VM, the async I/O driver would be notified. To achieve this VM had to operate on each 4K page that backs-up the memory being locked. If there are many users trying to register large memory segments almost at the same time the registration process would take a long time. Resolution: The VM code was modified to manage locking using superpages rather than 4K pages. Based on HP-UX patch PHKL_21781: (SR: 8606137220 CR: JAGad06338) The problem is due to the limitation of the protection ranges for memory mapped regions. The counter for the number of pregions that can be mprotected is defined as a u_short. When an application uses a very large data segment and makes more than 64K-1 mprotect(2) calls, the system returns an ENOSPC. Resolution: Change the definition of mprotect range counters from u_short to long. (SR: 8606136222 CR: JAGad05348) The major lock order for sendfile_lock was incorrect. Resolution: Correct the lock ordering for sendfile_lock. Based on HP-UX patch PHKL_21624: (SR: 8606124290 DTS: JAGac39673) The following scenario would cause a deadlock (resulting in a system hang): memlogd (using the dmem driver) was scrubbing the 4kB physical pages of a superpage locked by the async driver. Prior to scrubbing, dmem invalidated the address translations for all the 4kB pages in the superpage. Before dmem finished processing the superpage, it was interrupted by an async I/O request. The I/O transaction required accessing one of the 4kB pages in the superpage being scrubbed by dmem. The interrupt handler would wait for the page to be marked valid; dmem could not mark it valid until the interrupt returned and it finished scrubbing the superpage. Resolution: Callback registration support has been added to enable the async driver to register a callback requirement against memory it has locked. Whenever the address translation of a locked page is to be invalidated, the callback feature is invoked if the memory is registered as locked by async. Thus, the async driver is able to prevent dmem from scrubbing pages for which async I/Os are either active or pending. ( SR: CR: JAGab16247 ) The mlock allows a user process to unlock memory locked by the operating system. It does not allow for a persistant lock of user space memory by the operating system. Resolution: A new interface was added to the VM subsystem to allow persistant locking of user space memory by an operating system driver in such a way that a user can not unlock it. Both the persistant locking mechanism and the callback registration support are required to support DMA to user space by the operating system. Based on HP-UX patch PHKL_21600: (SR: 8606134430 DTS: JAGad03565) No check for overflow when casting mmap offset from 64 bits to 32 bits. And no check to prevent a negative value, from user space. Resolution: After casting from 64 to 32 bits, the offset is tested and if negative, mmap returns EINVAL. Based on HP-UX patch PHKL_20647: (SR: 8606107024 DTS: JAGab76631) When calling munmap() to unmap an area that ends within a superpage, the superpage lock was not properly released, resulting in a system hang upon a subsequent attempt to lock the superpage. Resolution: When calling munmap() to unmap an area that ends within a superpage, demote the end points before attempting to lock the superpage. Based on HP-UX patch PHKL_20449: (SR: 8606106816 DTS: JAGab76230) The kernel behaves incorrectly during some mmap(2) operations. Resolution: mmap(2) now returns an error if it can't honor the request. Based on HP-UX patch PHKL_20223: ( SR: 8606103245 DTS: JAGab69733) This bug is caused by a race condition in the mmap(2) code which was using a recursive algorithm to map all of the file. A lock was being dropped and reacquired each time the algorithm recursed. Resolution: The mmap bug was fixed by changing the algorithm so that is no longer was recursive. This allowed the lock to be held for the whole time. ( SR: 8606107525 DTS: JAGab77768) This is one of 8 patches necessary to add support for the 3 Gb private address space feature. This feature allows a process to have a private 3rd quadrant (normally the 3rd quadrant, which is a 1 Gb range of address space from 0x80000000 to 0xC0000000, is used for shared objects). The chatr command must be used to enable this feature for an executable (chatr +q3p enable ). Note that this feature is only enabled for 32 bit processes running on the 64 bit version of HP-UX. The other 7 patches necessary to enable this feature are PHKL_20222, PHKL_20224, PHKL_20225, PHKL_20226, PHKL_20227, PHKL_20228 and PHKL_20229. Each patch may be installed independently of the others - if enabling the 3 Gb private address space feature is not desired. If fewer than all 8 patches are installed, the 3 Gb private address space feature will not be enabled. The code in this patch that is part of this feature will not have any impact on the system until all 8 patches are installed. Resolution: A subset of the code to support the 3 Gb private address space feature was added. When all 8 patches are installed the following code changes to support this feature will have been added: 1) Code to recognize the request for a private 3rd quadrant (Q3) during exec() of an executable. An executable that requests a private 3rd quadrant will be referred to as a q3p process below. 2) Code to prevent allocation of shared objects in q3p processes. 3) Code to allow data to extend over the 2nd/3rd quadrant boundary for q3p processes. 4) Code to put the stack for the primary thread in the 3rd quadrant for q3p processes. 5) Code to map a shared library into the private address space if there is no more room in the 4th shared quadrant for q3p processes. PHKL_21306: Ported HP-UX patch PHKL_21532 to VVOS Based on HP-UX patch PHKL_21532: ( SR: 8606131990 CR: JAGad01139 ) Approximately every 22 minutes, vhand monopolizes one cpu for a long period of time. Every 22 minutes, vhand calls a routine which tries to free up kernel memory. It tries to free up each memory bucket for all cpus on the system each time it is called. As memory is freed up, chunks of memory are coalesced into larger chunks of (contiguous) memory. Each 4k page freed is added back into the superpage pool. Another related problem is that the superpage pool chain becomes long and fragmented (especially on large memory systems), which implies inefficiency in managing the pool. Resolution: The routine called by vhand to free up kernel memory will now work on one cpu at a time, and on only a few memory buckets at a time. It will do less for each call, and be called more often, spreading the workload out in time. Use a better coalescing algorithm for the superpage pool list. Based on HP-UX patch PHKL_21354: ( SR: 8606132598 CR: JAGad01747 ) When mapping kernel pages to real memory, if the address falls beyond 1GB and cannot be found in the 32bit sysmap, we fail to check the return code and allocate it from the 64bit sysmap. Without PHKL_21003, which moved the 64bit sysmap to start at 1GB instead of 4GB to cover an undefined 3GB gap, this has no effect since the address is not defined. However, when the address is included in the 64bit sysmap and we do not remove it properly when the virtual address is being used, we end up using the same virtual address again because it is still available in the sysmap. The init process fails when the vhand daemon starts paging. Resolution: Allocate the address from the 64bit sysmap when it is not found in the 32bit sysmap. ( SR: 8606132617 CR: JAGad01766 ) This patch is one of 16 patches (PHKL_21348-PHKL_21363) required by the Praesidium IDS/9000 product. These patches enable the collection and tracking of information from various system calls. Unless all of the enabling patches (or their successors) and the product are installed, and the product is enabled, this change has no impact on the system. Resolution: This patch causes the IDS/9000 pseudo-driver to be initialized at the right place during system boot. Based on HP-UX patch PHKL_21024: ( SR: 8606112164 DTS: JAGab84450 ) This is an enhancement for a corner case in RTSCHED scheduling. Resolution: Code added to fine tune RTSCHED thread scheduling code path. Based on HP-UX patch PHKL_21003: ( SR: 8606112473 CR: JAGab84822 ) In 11.00, the 32bit sysmap contains pages from 0 to 1GB and the 64bit sysmap contains pages from 4GB to 4TB, leaving a 3GB gap between them. Due to memory interleaving on V2500, there may not be enough physical memory below 1GB to satisfy the system initialization. Therefore, memory above 1GB is used. During system boot, the init process will try to allocate equivalently mapped virtual addresses from a sysmap for physical pages between 1GB to 4GB. When it fails because none of these pages can be found in either sysmap, it loops through all pages sequentially until it exhausts all the memory within the 1-4GB range. This may take a long time depending on the number of physical pages in the range. Resolution: Extend 64bit sysmap to start from 1GB to cover the 3GB gap. Based on HP-UX patch PHKL_20335: ( SR: 8606106466 DTS: JAGab75600) The buffer cache was never releasing references it had on NFS files which had the side-effect of never allowing these files to be removed. Resolution: The buffer cache now ensures that it correctly releases all holds on vnodes after data is removed from the cache. This ensures that NFS files become inactive and are therefore are removable. ( SR: 8606107384 DTS: JAGab77587) The buffer cache has the potential to release buffers multiple times, which could lead to system panics or memory corruption. Resolution: The routine that was writing out dirty buffers then releasing the buffer will now write and return thereby ensuring that the buffer is released only once. ( SR: 8606108724 DTS: JAGab78191) Files that grow in size and are copied over the network multiple times -- via rcp or ftp commands -- during this period may cause memory corruption to occur. This happens because stale checksum data pointers within the buffer header are reused after the buffer increases in size. Resolution: The buffer cache routine responsible for increasing the size of buffers will now check whether a buffer contains a pointer to checksum data -- which is used by the networking code -- in which case it will free the data and clear the pointer. Based on HP-UX patch PHKL_20222: ( SR: 8606107507 DTS: JAGab77743) This patch adds support for new machines that contain the PA-8600 processor. Resolution: Code to support the PA-8600 processor was added. ( SR: 8606107525 DTS: JAGab77768) This is one of 8 patches necessary to add support for the 3 Gb private address space feature. This feature allows a process to have a private 3rd quadrant (normally the 3rd quadrant, which is a 1 Gb range of address space from 0x80000000 to 0xC0000000, is used for shared objects). The chatr command must be used to enable this feature for an executable (chatr +q3p enable ). Note that this feature is only enabled for 32 bit processes running on the 64 bit version of HP-UX. The other 7 patches necessary to enable this feature are PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20226, PHKL_20227, PHKL_20228 and PHKL_20229. Each patch may be installed independently of the others - if enabling the 3 Gb private address space feature is not desired. If fewer than all 8 patches are installed, the 3 Gb private address space feature will not be enabled. The code in this patch that is part of this feature will not have any impact on the system until all 8 patches are installed. Resolution: A subset of the code to support the 3 Gb private address space feature was added. When all 8 patches are installed the following code changes to support this feature will have been added: 1) Code to recognize the request for a private 3rd quadrant (Q3) during exec() of an executable. An executable that requests a private 3rd quadrant will be referred to as a q3p process below. 2) Code to prevent allocation of shared objects in q3p processes. 3) Code to allow data to extend over the 2nd/3rd quadrant boundary for q3p processes. 4) Code to put the stack for the primary thread in the 3rd quadrant for q3p processes. 5) Code to map a shared library into the private address space if there is no more room in the 4th shared quadrant for q3p processes. Based on HP-UX patch PHKL_20102: ( SR: 8606106969 DTS: JAGaa45096 ) On systems with 5GB of memory or more, the system allocates too much memory for the pdir hash table (32-224MB). This additional memory is wasted. Resolution: Fixed boot time memory allocation algorithm to only allocate memory that is actually used. Based on HP-UX patch PHKL_20017: ( SR: 8606104415 DTS: JAGab71916) The fix in PHKL_19314 for the "14-way boot hang" breaks the interrupt distribution code. This results in all I/O interrupts being assigned to the monarch CPU, causing I/O performance degradation. Resolution: Add a new spu state SPU_INTR_ENABLED, so that pa_next_cpu will designate a spu to be an interrupt handler if its status is either SPU_INTR_ENABLED or SPU_ENABLED. Each non-monarch CPU sets its state to be SPU_INTR_ENABLED at the point where it used to set SPU_ENABLED. ( SR: 4701426775 DTS: JAGab17440 ) Historically on a 32bit system, the maximum size in one quadrant is limited to 1Gb. To handle more than 1Gb of buffer caches, we use two buffer cache resource maps, bufmap and bufmap2. For 64bit systems, the maximum size of a quadrant is not limited to 1Gb anymore and we don't need a second bufmap to fulfill the buffer cache needs. Therefore, bufmap2 is not used. However, on 11.00, we still initialize two resource maps with the size of bufmap limited to 0.9Gb/2 entries regardless of whether we have a 32bit or a 64bit system. So for 64bit systems with large memory and large buffer cache defined the system can still run out of bufmap entries if the virtual address space for the buffer cache gets fragmented. Resolution: For 64bit systems, initialize bufmap to contain phys_mem_pages/2 entries. Based on HP-UX patch PHKL_19314: ( SR: 4701426775 DTS: JAGab17440 ) While the monarch processor is in MPCONFIG_PHASE2 during boot and before it gets a chance to tell all non-monarch processors to continue execution (set mp_sync_after_rendez to CONTINUE_EXECUTION), a clock interrupt comes in. The clock interrupt handler will erroneously attempt an m_itmr_sync with all the processors (which are still waiting to continue). This m_itmr_sync can take up to 13 msecs per processor. When the number of processor is high enough, which is 14 in this case, another clock interrupt arrives before the current clock handler completes, causing the boot to hang in an infinite continuous series of servicing clock interrupts. Resolution: In the clock interrupt handling routine, we now make sure that no m_itmr_sync is attempted by the monarch processor until after the non-monarch processors are actually ready. As for the non-monarch processors, in the non_monarch_init routine, we now make sure that each non-monarch processor does not signal the monarch processor that it is ready for an m_itmr_sync until after the monarch sets mp_sync_after_rendez to CONTINUE_EXECUTION. ( SR: 8606101604 DTS: JAGab15954) The root cause seems to be a double mapping of the break_page by both a block TLB entry and an ordinary one, which causes undefined results in the hardware. Resolution: Code has been added to main so that during initialization it looks at the machine being booted to see whether or not this machine has a block-tlb. If the machine does not have one, then the page in the kernel is used for the break-page. If the machine has a block-tlb, then instead of using the page in the kernel, a new page is allocated for the break-page. Based on HP-UX patch PHKL_19201: SR: 8606100898 DTS: JAGab39707 The system hang is caused by jfs snap code trying to lock the same resource again when it already owns it. A buffer that partially satisfies a request needs to be marked invalid when it can't be grown to fit the request. This will prevent another thread from getting a hit on it and trying to grow it, which can cause a hang. Resolution: SR: 8606100898 DTS: JAGab39707 Mark buffers invalid when the buffer can't be grown to fit the size of the request. PHKL_20559: System could hang when enabling audit on heavily loaded system. There is a race condition between the audit daemon and system call auditing right between enabling audit with the ioctl and when the daemon opens the read device. We end up with a hung system because all the system calls end up sleeping, waiting to get free space on the audit kernel buffer. The sleeping threads are never awaken because the audit daemon, which would free space in the kernel buffer when reading records out, is also sleeping on the opening of the audit read device, waiting for the system calls to finish writing their records before it updates the configuration data structure. Resolution: Added an extra check in the audit() subroutine. In addition to checking that audit is enabled, it also checks that the audit daemon has successfully opened the read device. PHKL_20127: Several VVOS specific routines are being called unconditionally from syscall() and trap(), which slows down the syscall() subroutine by a measurable amount. Resolution: Move checks done in several subroutines into syscall() so that the actual code is only called when it's needed. In addition, this helps the linker to position the seldomly called subroutines on different areas, freeing space around syscall() for those that are called much more often. PHKL_19440: Ported HP-UX patch PHKL_17038 to VVOS Based on HP-UX patch PHKL_17038: An uninitialized variable may cause this data page fault when tracing for memory leaks. The workaround is to also trace for corruption which will initialize the variable. The workaround isn't always feasible because tracing for corruption uses a lot more memory in some environments while tracing for leaks does not. Based on HP-UX patch PHKL_20945: ( SR: 8606112164 DTS: JAGab84450 ) This is an enhancement for a corner case in RTSCHED scheduling. Resolution: Code added to fine tune RTSCHED thread scheduling code path. Based on HP-UX patch PHKL_20995: ( SR: 8606127692 CR: JAGac78494 ) Code that initialized the space maps for the second and third quadrant for memory windows processes is not being run. This means that a memory windows process cannot allocate shared memory in the second (for SHMEM_MAGIC processes) or third quadrant, leaving only the fourth quadrant available, which is shared across all processes. This defect is only present if all 8 of the Large Data space patches are installed. Resolution: Code was changed to allow the space maps to be properly initialized for all configured memory windows. Based on HP-UX patch PHKL_20836: ( SR: 8606106781 CR: JAGab76169 ) HP-UX handles multiple virtual addresses mapping to the same physical page by using virtual address aliasing. Large number of overlapping exclusive mapping calls (mmap with MAP_SHARED|MAP_FIXED|MAP_FILE) create excessive number of virtual address aliases and can exhaust the alias entries for physical pages. The exhaustion of alias entries results in failed attempts to add a page translation. Improper handling of the translation failure results in corruption in the free memory list, thus causing an unmapped page to be returned from the free memory pond. Resolution: Handle application requested overlapping exclusive mapping without using aliases. Based on HP-UX patch PHKL_20227: ( SR: 8606107525 CR: JAGab77768 ) This is one of 8 patches necessary to add support for the 3 Gb private address space feature. This feature allows a process to have a private 3rd quadrant (normally the 3rd quadrant, which is a 1 Gb range of address space from 0x80000000 to 0xC0000000, is used for shared objects). The chatr command must be used to enable this feature for an executable (chatr +q3p enable ). Note that this feature is only enabled for 32 bit processes running on the 64 bit version of HP-UX. The other 7 patches necessary to enable this feature are PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20226, PHKL_20228 and PHKL_20229. Each patch may be installed independently of the others - if enabling the 3 Gb private address space feature is not desired. If fewer than all 8 patches are installed, the 3 Gb private address space feature will not be enabled. The code in this patch that is part of this feature will not have any impact on the system until all 8 patches are installed. Resolution: A subset of the code to support the 3 Gb private address space feature was added. When all 8 patches are installed the following code changes to support this feature will have been added: 1) Code to recognize the request for a private 3rd quadrant (Q3) during exec() of an executable. An executable that requests a private 3rd quadrant will be referred to as a q3p process below. 2) Code to prevent allocation of shared objects in q3p processes. 3) Code to allow data to extend over the 2nd/3rd quadrant boundary for q3p processes. 4) Code to put the stack for the primary thread in the 3rd quadrant for q3p processes. 5) Code to map a shared library into the private address space if there is no more room in the 4th shared quadrant for q3p processes. Based on HP-UX patch PHKL_20224: ( SR: 8606107525 CR: JAGab77768 ) This is one of 8 patches necessary to add support for the 3 Gb private address space feature. This feature allows a process to have a private 3rd quadrant (normally the 3rd quadrant, which is a 1 Gb range of address space from 0x80000000 to 0xC0000000, is used for shared objects). The chatr command must be used to enable this feature for an executable (chatr +q3p enable ). Note that this feature is only enabled for 32 bit processes running on the 64 bit version of HP-UX. The other 7 patches necessary to enable this feature are PHKL_20222, PHKL_20223, PHKL_20225, PHKL_20226, PHKL_20227, PHKL_20228 and PHKL_20229. Each patch may be installed independently of the others - if enabling the 3 Gb private address space feature is not desired. If fewer than all 8 patches are installed, the 3 Gb private address space feature will not be enabled. The code in this patch that is part of this feature will not have any impact on the system until all 8 patches are installed. Resolution: A subset of the code to support the 3 Gb private address space feature was added. When all 8 patches are installed the following code changes to support this feature will have been added: 1) Code to recognize the request for a private 3rd quadrant (Q3) during exec() of an executable. An executable that requests a private 3rd quadrant will be referred to as a q3p process below. 2) Code to prevent allocation of shared objects in q3p processes. 3) Code to allow data to extend over the 2nd/3rd quadrant boundary for q3p processes. 4) Code to put the stack for the primary thread in the 3rd quadrant for q3p processes. 5) Code to map a shared library into the private address space if there is no more room in the 4th shared quadrant for q3p processes. Based on HP-UX patch PHKL_20515: (SR: 8606101315, CR: JAGab46368) Assertion failure occurs in 'kmalloc' someone called 'kmalloc' holding the 'spinlock' which should not be done. Async driver allocated kernel memory while holding spinlock which causes driver to sleep until memory is available. Resolution: Added No-Wait flag to memory allocation call when spinlock is held. (SR: 8606100970, CR: JAGab39977) Async driver called subroutine with uninitialized variable. In the asyncdsk_dorequest() routine, the 1st argument to luseracc is tempseg.space -- however, tempseg.space doesn't get populated until & unless luseracc returns successfully. Resolution: Initialize variable before using in subroutine call. (SR:8606103126, CR: JAGab69473) Spinlock was held in async driver during call to routine that did not need spinlock held, and which could take too long before returning. Resolution: Released spinlock before call to the routine, then reacquired after routine returned. (SR: 8606102862, CR: JAGab68892) Async driver should unmap buffers of same size as was originally mapped for the IO request, but instead it was unmapping the size based on the number of bytes transferred successfully in the async IO request. Resolution: Unmapped IO request buffer size same as was mapped. (SR: 8606108814, CR: JAGab81517) Async driver's IO completion flag notification was checked in wrong sequence, when used in conjunction with select. Resolution: Changed sequence to check for IO notification flag before checking other types of IO completions. Based on HP-UX patch PHKL_20426: Violation of lock ordering by filesystem code. The lock ordering that is safe from deadlock is: vaslock, vnodelock, inodelock but filesystems are attempting the order: (vnodelock), inodelock, vaslock Resolution: The VM system will drop the vaslock around filesystem operations, and reacquire it afterwards. This completes PHKL_18531 that was partially solving the problem. Enhancement: No (superseded patches contained enhancements) PHKL_29760: Based on HP-UX patch PHKL_21024: This patch provides enhancements for a corner case in RTSCHED scheduling. Based on HP-UX patch PHKL_20945: This patch provides enhancements for a corner case in RTSCHED scheduling. PHKL_22717: Ported HP-UX patch PHKL_22493 to VVOS 11.04 Based on HP-UX patch PHKL_22493: PHKL_25044: Ported HP-UX patch PHKL_21352 and PHKL_25210 to VVOS 11.04 Based on HP-UX patch PHKL_21352 and PHKL_25210: PHKL_26815: If alarm notification is enabled for Insufficient Privilege events (EPERM), an incomplete audit record for Insufficient Privilege can be reported in the logs. PHKL_27710: Ported HP-UX patch PHKL_27364 to VVOS 11.04 Based on HP-UX patch PHKL_27364: PHKL_21306: Ported HP-UX patch PHKL_21532 to VVOS 11.04 Based on HP-UX patch PHKL_21532: PHKL_23886: Ported HP-UX patch PHKL_23628 to VVOS 11.04 Based on HP-UX patch PHKL_23628: PHKL_22891: Ported HP-UX patch PHKL_22440 to VVOS 11.04 Based on HP-UX patch PHKL_22440: SR: 1653301614 4701402461 4701426775 8606100830 8606100898 8606100970 8606101315 8606101604 8606102862 8606103126 8606103245 8606103740 8606103778 8606104415 8606106466 8606106781 8606106816 8606106969 8606107024 8606107384 8606107507 8606107525 8606108724 8606108814 8606109770 8606112164 8606112473 8606113684 8606124290 8606127692 8606128066 8606130240 8606131318 8606132598 8606132613 8606132617 8606132620 8606132621 8606134430 8606134995 8606136222 8606137149 8606137220 8606139945 8606141875 8606143996 8606146888 8606146889 8606154274 8606155209 8606161365 8606162188 8606168950 8606169539 8606178349 8606179580 8606180059 8606183443 8606185728 8606186963 8606188675 8606188767 8606192072 8606192498 8606194618 8606195331 8606195629 8606198933 8606199485 8606199847 8606204721 8606216082 8606226665 8606237263 8606241742 8606244346 8606254033 8606256133 8606265366 8606268349 8606271497 8606272341 8606279968 8606108119 8606112387 8606131990 8606132615 8606159451 8606177871 8606238384 Patch Files: OS-Core.CORE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/conf/h/map.h /usr/conf/h/vm_mlock.h /usr/conf/machine/hdl_preg.h /usr/conf/machine/pdc_rqsts.h /usr/conf/sio/async.h ProgSupport.C-INC,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/include/machine/hdl_preg.h /usr/include/machine/pdc_rqsts.h /usr/include/sio/async.h /usr/include/sys/map.h /usr/include/sys/vm_mlock.h OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: /usr/conf/lib/libhp-ux.a(asm_vm.o) /usr/conf/lib/libhp-ux.a(async.o) /usr/conf/lib/libhp-ux.a(clic_stubs.o) /usr/conf/lib/libhp-ux.a(clock.o) /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o) /usr/conf/lib/libhp-ux.a(dmem.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(kern_exec.o) /usr/conf/lib/libhp-ux.a(kern_exit.o) /usr/conf/lib/libhp-ux.a(kern_mallo.o) /usr/conf/lib/libhp-ux.a(kern_mman.o) /usr/conf/lib/libhp-ux.a(kgdb_machine.o) /usr/conf/lib/libhp-ux.a(kmall_trace.o) /usr/conf/lib/libhp-ux.a(onyxe.o) /usr/conf/lib/libhp-ux.a(pa_generic_psm.o) /usr/conf/lib/libhp-ux.a(pm_core.o) /usr/conf/lib/libhp-ux.a(pm_cred.o) /usr/conf/lib/libhp-ux.a(pm_prot.o) /usr/conf/lib/libhp-ux.a(pm_ptrace.o) /usr/conf/lib/libhp-ux.a(syscall.o) /usr/conf/lib/libhp-ux.a(trap.o) /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) /usr/conf/lib/libhp-ux.a(vfs_bio.o) /usr/conf/lib/libhp-ux.a(vm_clic.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_memlock.o) /usr/conf/lib/libhp-ux.a(vm_mlock.o) /usr/conf/lib/libhp-ux.a(vm_mmap.o) /usr/conf/lib/libhp-ux.a(vm_pgalloc.o) /usr/conf/lib/libhp-ux.a(vm_pregion.o) /usr/conf/lib/libhp-ux.a(vm_realmain.o) /usr/conf/lib/libhp-ux.a(vm_remap.o) /usr/conf/lib/libhp-ux.a(vm_sched.o) /usr/conf/lib/libhp-ux.a(vm_vas.o) /usr/conf/lib/libhp-ux.a(vm_vfd.o) /usr/conf/lib/libhp-ux.a(vm_vhand.o) OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: /usr/conf/lib/libhp-ux.a(asm_vm.o) /usr/conf/lib/libhp-ux.a(async.o) /usr/conf/lib/libhp-ux.a(clic_stubs.o) /usr/conf/lib/libhp-ux.a(clock.o) /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o) /usr/conf/lib/libhp-ux.a(dmem.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(kern_exec.o) /usr/conf/lib/libhp-ux.a(kern_exit.o) /usr/conf/lib/libhp-ux.a(kern_mallo.o) /usr/conf/lib/libhp-ux.a(kern_mman.o) /usr/conf/lib/libhp-ux.a(kgdb_machine.o) /usr/conf/lib/libhp-ux.a(kmall_trace.o) /usr/conf/lib/libhp-ux.a(onyxe.o) /usr/conf/lib/libhp-ux.a(pa_generic_psm.o) /usr/conf/lib/libhp-ux.a(pm_core.o) /usr/conf/lib/libhp-ux.a(pm_cred.o) /usr/conf/lib/libhp-ux.a(pm_prot.o) /usr/conf/lib/libhp-ux.a(pm_ptrace.o) /usr/conf/lib/libhp-ux.a(syscall.o) /usr/conf/lib/libhp-ux.a(trap.o) /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) /usr/conf/lib/libhp-ux.a(vfs_bio.o) /usr/conf/lib/libhp-ux.a(vm_clic.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_memlock.o) /usr/conf/lib/libhp-ux.a(vm_mlock.o) /usr/conf/lib/libhp-ux.a(vm_mmap.o) /usr/conf/lib/libhp-ux.a(vm_pgalloc.o) /usr/conf/lib/libhp-ux.a(vm_pregion.o) /usr/conf/lib/libhp-ux.a(vm_realmain.o) /usr/conf/lib/libhp-ux.a(vm_remap.o) /usr/conf/lib/libhp-ux.a(vm_sched.o) /usr/conf/lib/libhp-ux.a(vm_vas.o) /usr/conf/lib/libhp-ux.a(vm_vfd.o) /usr/conf/lib/libhp-ux.a(vm_vhand.o) VirtualVaultOS.VVOS-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: /usr/conf/lib/libsec.a(audit_stub.o) /usr/conf/lib/libsec.a(sec_audit.o) /usr/conf/lib/libsec.a(sec_subrs.o) VirtualVaultOS.VVOS-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: /usr/conf/lib/libsec.a(audit_stub.o) /usr/conf/lib/libsec.a(sec_audit.o) /usr/conf/lib/libsec.a(sec_subrs.o) what(1) Output: OS-Core.CORE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/conf/h/map.h: map.h $Date: 2000/02/02 11:49:37 $Revision: r11ros/2 PATCH_11.00 (PHKL_21003) /usr/conf/h/vm_mlock.h: vm_mlock.h $Date: 2001/04/23 13:03:40 $Revision: r11 ros/2 PATCH_11.00 (PHKL_23857) /usr/conf/machine/hdl_preg.h: hdl_preg.h $Date: 2000/05/31 14:27:02 $Revision: r11 ros/1 PATCH_11.00 (PHKL_21781) /usr/conf/machine/pdc_rqsts.h: pdc_rqsts.h $Date: 1999/10/28 05:09:19 $Revision: r1 1ros/3 PATCH_11.00 (PHKL_20222) /usr/conf/sio/async.h: async.h $Date: 2001/06/26 14:43:30 $Revision: r11ros /5 PATCH_11.00 (PHKL_24457) ProgSupport.C-INC,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/include/machine/hdl_preg.h: hdl_preg.h $Date: 2000/05/31 14:27:02 $Revision: r11 ros/1 PATCH_11.00 (PHKL_21781) /usr/include/machine/pdc_rqsts.h: pdc_rqsts.h $Date: 1999/10/28 05:09:19 $Revision: r1 1ros/3 PATCH_11.00 (PHKL_20222) /usr/include/sio/async.h: async.h $Date: 2001/06/26 14:43:30 $Revision: r11ros /5 PATCH_11.00 (PHKL_24457) /usr/include/sys/map.h: map.h $Date: 2000/02/02 11:49:37 $Revision: r11ros/2 PATCH_11.00 (PHKL_21003) /usr/include/sys/vm_mlock.h: vm_mlock.h $Date: 2001/04/23 13:03:40 $Revision: r11 ros/2 PATCH_11.00 (PHKL_23857) OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: /usr/conf/lib/libhp-ux.a(asm_vm.o): asm_vm.s $Date: 2001/09/05 08:39:29 $Revision: r11ro s/6 PATCH_11.00 (PHKL_25164) /usr/conf/lib/libhp-ux.a(async.o): async.c $Date: 2001/06/26 12:54:22 $Revision: r11ros /16 PATCH_11.00 (PHKL_24457) /usr/conf/lib/libhp-ux.a(clic_stubs.o): clic_stubs.c $Date: 2000/08/14 11:40:53 $Revision: r 11ros/3 PATCH_11.00 (PHKL_22126) /usr/conf/lib/libhp-ux.a(clock.o): $Source: kern/machine/clock.c, hpuxsysmach, vvos_ros e, rose0323 $ $Date: 03/09/22 06:07:06 $ $Re vision: 1.11 PATCH_11.04 (PHKL_29760) $ /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o): cnx_p2p_bcopy.c $Date: 1999/11/09 15:03:19 $Revision : r11ros/7 PATCH_11.00 (PHKL_20439) /usr/conf/lib/libhp-ux.a(dmem.o): dmem.c $Date: 2000/08/14 11:40:53 $Revision: r11ros/ 6 PATCH_11.00 (PHKL_22126) /usr/conf/lib/libhp-ux.a(hdl_fault.o): hdl_fault.c $Date: 2003/02/24 17:53:53 $Revision: r1 1ros/15 PATCH_11.00 (PHKL_28766) /usr/conf/lib/libhp-ux.a(hdl_init.o): hdl_init.c $Date: 1999/10/31 21:44:19 $Revision: r11 ros/7 PATCH_11.00 (PHKL_20223) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o): hdl_mprotect.c $Date: 2000/05/31 14:25:46 $Revision: r11ros/9 PATCH_11.00 (PHKL_21781) /usr/conf/lib/libhp-ux.a(hdl_policy.o): hdl_policy.c $Date: 2002/05/22 13:51:22 $Revision: r 11ros/16 PATCH_11.00 (PHKL_27157) /usr/conf/lib/libhp-ux.a(hdl_trans.o): hdl_trans.c $Date: 2001/07/12 15:49:36 $Revision: r1 1ros/18 PATCH_11.00 (PHKL_24612) /usr/conf/lib/libhp-ux.a(init_main.o): $Source: kern/sys/init_main.c, hpuxsysinit, vvos_ros e, rose0323 $ $Date: 03/09/22 06:07:26 $ $Re vision: 1.25.1.14 PATCH_11.04 (PHKL_29760) $ /usr/conf/lib/libhp-ux.a(kern_exec.o): $Source: kern/sys/kern_exec.c, hpuxsysmisc, vvos_ros e, rose0323 $ $Date: 03/09/22 06:07:46 $ $Re vision: 1.17.3.11 PATCH_11.04 (PHKL_29760) $ /usr/conf/lib/libhp-ux.a(kern_exit.o): $Source: kern/sys/kern_exit.c, hpuxsysproc, vvos_ros e, rose0321 $ $Date: 01/04/25 09:31:25 $ $Re vision: 1.30 PATCH_11.04 (PHKL_23886) $ /usr/conf/lib/libhp-ux.a(kern_mallo.o): kern_mallo.c $Date: 2000/04/12 03:18:15 $Revision: r 11ros/7 PATCH_11.00 (PHKL_21532) /usr/conf/lib/libhp-ux.a(kern_mman.o): kern_mman.c $Date: 2001/01/25 16:58:55 $Revision: r1 1ros/4 PATCH_11.00 (PHKL_23183) /usr/conf/lib/libhp-ux.a(kgdb_machine.o): kgdb_machine.c $Date: 1999/10/28 05:09:19 $Revision: r11ros/4 PATCH_11.00 (PHKL_20222) /usr/conf/lib/libhp-ux.a(kmall_trace.o): kmall_trace.c $Date: 2000/02/02 11:47:27 $Revision: r11ros/7 PATCH_11.00 (PHKL_21003) /usr/conf/lib/libhp-ux.a(onyxe.o): onyxe.c $Date: 1999/10/28 05:09:19 $Revision: r11ros /2 PATCH_11.00 (PHKL_20222) onyxe 1.0 (unsupported) /usr/conf/lib/libhp-ux.a(pa_generic_psm.o): pa_generic_psm.c $Date: 1999/09/24 17:23:06 $Revisio n: r11ros/2 PATCH_11.00 (PHKL_20017) /usr/conf/lib/libhp-ux.a(pm_core.o): $Source: kern/sys/pm_core.c, hpuxsysproc, vvos_rose, rose0321 $ $Date: 01/04/24 18:59:46 $ $Revi sion: 1.9.1.10 PATCH_11.04 (PHKL_23886) $ /usr/conf/lib/libhp-ux.a(pm_cred.o): $Source: kern/sys/pm_cred.c, hpuxsysmisc, vvos_rose, rose0321 $ $Date: 00/11/30 17:41:46 $ $Revi sion: 1.13 PATCH_11.04 (PHKL_22717) $ /usr/conf/lib/libhp-ux.a(pm_prot.o): $Source: kern/sys/pm_prot.c, hpuxsysproc, vvos_rose, rose0321 $ $Date: 00/11/30 17:48:51 $ $Revi sion: 1.21 PATCH_11.04 (PHKL_22717) $ /usr/conf/lib/libhp-ux.a(pm_ptrace.o): ttrace_private.h $Date: 1998/12/15 09:21:36 $Revisio n: r11ros/cup_ros_ep1_pb/3 PATCH_11.00 (PHKL _17205) $Source: kern/sys/pm_ptrace.c, hpuxsysproc, vvos_ros e, rose0321 $ $Date: 01/09/12 05:42:07 $ $Re vision: 1.13.1.15 PATCH_11.04 (PHKL_25044) $ /usr/conf/lib/libhp-ux.a(syscall.o): $Source: kern/machine/syscall.c, hpuxsysmach, vvos_r ose, rose0321 $ $Date: 01/09/26 02:21:22 $ $ Revision: 1.17 PATCH_11.04 (PHKL_25044) $ /usr/conf/lib/libhp-ux.a(trap.o): $Source: kern/machine/trap.c, hpuxsysmach, vvos_rose , rose0321 $ $Date: 99/10/26 11:07:22 $ $Rev ision: 1.8 PATCH_11.04 (PHKL_20127) $ /usr/conf/lib/libhp-ux.a(ufs_mchdep.o): ufs_mchdep.c $Date: 2000/06/05 17:05:33 $Revision: r 11ros/6 PATCH_11.00 (PHKL_21781) /usr/conf/lib/libhp-ux.a(vfs_bio.o): $Source: kern/sys/vfs_bio.c, hpuxsysvfs, vvos_rose, rose0323 $ $Date: 03/09/22 06:08:00 $ $Revis ion: 1.12.1.14 PATCH_11.04 (PHKL_29760) $ /usr/conf/lib/libhp-ux.a(vm_clic.o): vm_clic.c $Date: 2001/04/23 13:03:40 $Revision: r11r os/4 PATCH_11.00 (PHKL_23857) /usr/conf/lib/libhp-ux.a(vm_kern.o): vm_kern.c $Date: 2000/04/12 03:18:15 $Revision: r11r os/4 PATCH_11.00 (PHKL_21532) /usr/conf/lib/libhp-ux.a(vm_machdep.o): $Source: kern/machine/vm_machdep.c, hpuxsysmach, vvo s_rose, rose0321 $ $Date: 01/09/12 04:52:50 $ $Revision: 1.17.1.16 PATCH_11.04 (PHKL_250 44) $ /usr/conf/lib/libhp-ux.a(vm_machreg.o): vm_machreg.c $Date: 2002/06/25 08:41:53 $Revision: r 11ros/12 PATCH_11.00 (PHKL_27364) /usr/conf/lib/libhp-ux.a(vm_memlock.o): vm_memlock.c $Date: 2001/08/17 14:43:30 $Revision: r 11ros/5 PATCH_11.00 (PHKL_24971) /usr/conf/lib/libhp-ux.a(vm_mlock.o): $Source: kern/sys/vm_mlock.c, hpuxsysvm, vvos_rose, rose0321 $ $Date: 02/08/13 07:39:07 $ $Revis ion: 1.13 PATCH_11.04 (PHKL_27710) $ /usr/conf/lib/libhp-ux.a(vm_mmap.o): vm_mmap.c $Date: 2002/06/04 17:07:42 $Revision: r11r os/25 PATCH_11.00 (PHKL_27238) /usr/conf/lib/libhp-ux.a(vm_pgalloc.o): vm_pgalloc.c $Date: 2000/05/03 15:11:15 $Revision: r 11ros/4 PATCH_11.00 (PHKL_21624) /usr/conf/lib/libhp-ux.a(vm_pregion.o): vm_pregion.c $Date: 2001/05/29 15:16:13 $Revision: r 11ros/11 PATCH_11.00 (PHKL_24273) /usr/conf/lib/libhp-ux.a(vm_realmain.o): vm_realmain32.c $Date: 1999/10/28 05:09:19 $Revision : r11ros/5 PATCH_11.00 (PHKL_20222) /usr/conf/lib/libhp-ux.a(vm_remap.o): vm_remap.c $Date: 2000/08/14 11:40:53 $Revision: r11 ros/4 PATCH_11.00 (PHKL_22126) /usr/conf/lib/libhp-ux.a(vm_sched.o): $Source: kern/sys/vm_sched.c, hpuxsysvm, vvos_rose, rose0321 $ $Date: 01/01/26 10:03:55 $ $Revis ion: 1.6.1.12 PATCH_11.04 (PHKL_23166) $ /usr/conf/lib/libhp-ux.a(vm_vas.o): vm_vas.c $Date: 2001/09/11 13:56:29 $Revision: r11ro s/13 PATCH_11.00 (PHKL_25210) /usr/conf/lib/libhp-ux.a(vm_vfd.o): vm_vfd.c $Date: 2002/10/16 15:44:52 $Revision: r11ro s/9 PATCH_11.00 (PHKL_27994) /usr/conf/lib/libhp-ux.a(vm_vhand.o): vm_vhand.c $Date: 2002/10/09 13:05:56 $Revision: r11 ros/7 PATCH_11.00 (PHKL_28053) OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: /usr/conf/lib/libhp-ux.a(asm_vm.o): asm_vm.s $Date: 2001/09/05 08:39:29 $Revision: r11ro s/6 PATCH_11.00 (PHKL_25164) /usr/conf/lib/libhp-ux.a(async.o): async.c $Date: 2001/06/26 12:54:22 $Revision: r11ros /16 PATCH_11.00 (PHKL_24457) /usr/conf/lib/libhp-ux.a(clic_stubs.o): clic_stubs.c $Date: 2000/08/14 11:40:53 $Revision: r 11ros/3 PATCH_11.00 (PHKL_22126) /usr/conf/lib/libhp-ux.a(clock.o): $Source: kern/machine/clock.c, hpuxsysmach, vvos_ros e, rose0323 $ $Date: 03/09/22 06:07:06 $ $Re vision: 1.11 PATCH_11.04 (PHKL_29760) $ /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o): cnx_p2p_bcopy.c $Date: 1999/11/09 15:03:19 $Revision : r11ros/7 PATCH_11.00 (PHKL_20439) /usr/conf/lib/libhp-ux.a(dmem.o): dmem.c $Date: 2000/08/14 11:40:53 $Revision: r11ros/ 6 PATCH_11.00 (PHKL_22126) /usr/conf/lib/libhp-ux.a(hdl_fault.o): hdl_fault.c $Date: 2003/02/24 17:53:53 $Revision: r1 1ros/15 PATCH_11.00 (PHKL_28766) /usr/conf/lib/libhp-ux.a(hdl_init.o): hdl_init.c $Date: 1999/10/31 21:44:19 $Revision: r11 ros/7 PATCH_11.00 (PHKL_20223) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o): hdl_mprotect.c $Date: 2000/05/31 14:25:46 $Revision: r11ros/9 PATCH_11.00 (PHKL_21781) /usr/conf/lib/libhp-ux.a(hdl_policy.o): hdl_policy.c $Date: 2002/05/22 13:51:22 $Revision: r 11ros/16 PATCH_11.00 (PHKL_27157) /usr/conf/lib/libhp-ux.a(hdl_trans.o): hdl_trans.c $Date: 2001/07/12 15:49:36 $Revision: r1 1ros/18 PATCH_11.00 (PHKL_24612) /usr/conf/lib/libhp-ux.a(init_main.o): $Source: kern/sys/init_main.c, hpuxsysinit, vvos_ros e, rose0323 $ $Date: 03/09/22 06:07:26 $ $Re vision: 1.25.1.14 PATCH_11.04 (PHKL_29760) $ /usr/conf/lib/libhp-ux.a(kern_exec.o): $Source: kern/sys/kern_exec.c, hpuxsysmisc, vvos_ros e, rose0323 $ $Date: 03/09/22 06:07:46 $ $Re vision: 1.17.3.11 PATCH_11.04 (PHKL_29760) $ /usr/conf/lib/libhp-ux.a(kern_exit.o): $Source: kern/sys/kern_exit.c, hpuxsysproc, vvos_ros e, rose0321 $ $Date: 01/04/25 09:31:25 $ $Re vision: 1.30 PATCH_11.04 (PHKL_23886) $ /usr/conf/lib/libhp-ux.a(kern_mallo.o): kern_mallo.c $Date: 2000/04/12 03:18:15 $Revision: r 11ros/7 PATCH_11.00 (PHKL_21532) /usr/conf/lib/libhp-ux.a(kern_mman.o): kern_mman.c $Date: 2001/01/25 16:58:55 $Revision: r1 1ros/4 PATCH_11.00 (PHKL_23183) /usr/conf/lib/libhp-ux.a(kgdb_machine.o): kgdb_machine.c $Date: 1999/10/28 05:09:19 $Revision: r11ros/4 PATCH_11.00 (PHKL_20222) /usr/conf/lib/libhp-ux.a(kmall_trace.o): kmall_trace.c $Date: 2000/02/02 11:47:27 $Revision: r11ros/7 PATCH_11.00 (PHKL_21003) /usr/conf/lib/libhp-ux.a(onyxe.o): onyxe 1.0 (unsupported) onyxe.c $Date: 1999/10/28 05:09:19 $Revision: r11ros /2 PATCH_11.00 (PHKL_20222) /usr/conf/lib/libhp-ux.a(pa_generic_psm.o): pa_generic_psm.c $Date: 1999/09/24 17:23:06 $Revisio n: r11ros/2 PATCH_11.00 (PHKL_20017) /usr/conf/lib/libhp-ux.a(pm_core.o): $Source: kern/sys/pm_core.c, hpuxsysproc, vvos_rose, rose0321 $ $Date: 01/04/24 18:59:46 $ $Revi sion: 1.9.1.10 PATCH_11.04 (PHKL_23886) $ /usr/conf/lib/libhp-ux.a(pm_cred.o): $Source: kern/sys/pm_cred.c, hpuxsysmisc, vvos_rose, rose0321 $ $Date: 00/11/30 17:41:46 $ $Revi sion: 1.13 PATCH_11.04 (PHKL_22717) $ /usr/conf/lib/libhp-ux.a(pm_prot.o): $Source: kern/sys/pm_prot.c, hpuxsysproc, vvos_rose, rose0321 $ $Date: 00/11/30 17:48:51 $ $Revi sion: 1.21 PATCH_11.04 (PHKL_22717) $ /usr/conf/lib/libhp-ux.a(pm_ptrace.o): $Source: kern/sys/pm_ptrace.c, hpuxsysproc, vvos_ros e, rose0321 $ $Date: 01/09/12 05:42:07 $ $Re vision: 1.13.1.15 PATCH_11.04 (PHKL_25044) $ ttrace_private.h $Date: 1998/12/15 09:21:36 $Revisio n: r11ros/cup_ros_ep1_pb/3 PATCH_11.00 (PHKL _17205) /usr/conf/lib/libhp-ux.a(syscall.o): $Source: kern/machine/syscall.c, hpuxsysmach, vvos_r ose, rose0321 $ $Date: 01/09/26 02:21:22 $ $ Revision: 1.17 PATCH_11.04 (PHKL_25044) $ /usr/conf/lib/libhp-ux.a(trap.o): $Source: kern/machine/trap.c, hpuxsysmach, vvos_rose , rose0321 $ $Date: 99/10/26 11:07:22 $ $Rev ision: 1.8 PATCH_11.04 (PHKL_20127) $ /usr/conf/lib/libhp-ux.a(ufs_mchdep.o): ufs_mchdep.c $Date: 2000/06/05 17:05:33 $Revision: r 11ros/6 PATCH_11.00 (PHKL_21781) /usr/conf/lib/libhp-ux.a(vfs_bio.o): $Source: kern/sys/vfs_bio.c, hpuxsysvfs, vvos_rose, rose0323 $ $Date: 03/09/22 06:08:00 $ $Revis ion: 1.12.1.14 PATCH_11.04 (PHKL_29760) $ /usr/conf/lib/libhp-ux.a(vm_clic.o): vm_clic.c $Date: 2001/04/23 13:03:40 $Revision: r11r os/4 PATCH_11.00 (PHKL_23857) /usr/conf/lib/libhp-ux.a(vm_kern.o): vm_kern.c $Date: 2000/04/12 03:18:15 $Revision: r11r os/4 PATCH_11.00 (PHKL_21532) /usr/conf/lib/libhp-ux.a(vm_machdep.o): $Source: kern/machine/vm_machdep.c, hpuxsysmach, vvo s_rose, rose0321 $ $Date: 01/09/12 04:52:50 $ $Revision: 1.17.1.16 PATCH_11.04 (PHKL_250 44) $ /usr/conf/lib/libhp-ux.a(vm_machreg.o): vm_machreg.c $Date: 2002/06/25 08:41:53 $Revision: r 11ros/12 PATCH_11.00 (PHKL_27364) /usr/conf/lib/libhp-ux.a(vm_memlock.o): vm_memlock.c $Date: 2001/08/17 14:43:30 $Revision: r 11ros/5 PATCH_11.00 (PHKL_24971) /usr/conf/lib/libhp-ux.a(vm_mlock.o): $Source: kern/sys/vm_mlock.c, hpuxsysvm, vvos_rose, rose0321 $ $Date: 02/08/13 07:39:07 $ $Revis ion: 1.13 PATCH_11.04 (PHKL_27710) $ /usr/conf/lib/libhp-ux.a(vm_mmap.o): vm_mmap.c $Date: 2002/06/04 17:07:42 $Revision: r11r os/25 PATCH_11.00 (PHKL_27238) /usr/conf/lib/libhp-ux.a(vm_pgalloc.o): vm_pgalloc.c $Date: 2000/05/03 15:11:15 $Revision: r 11ros/4 PATCH_11.00 (PHKL_21624) /usr/conf/lib/libhp-ux.a(vm_pregion.o): vm_pregion.c $Date: 2001/05/29 15:16:13 $Revision: r 11ros/11 PATCH_11.00 (PHKL_24273) /usr/conf/lib/libhp-ux.a(vm_realmain.o): vm_realmain64.c $Date: 2002/09/19 16:26:16 $Revision : r11ros/10 PATCH_11.00 (PHKL_27919) /usr/conf/lib/libhp-ux.a(vm_remap.o): vm_remap.c $Date: 2000/08/14 11:40:53 $Revision: r11 ros/4 PATCH_11.00 (PHKL_22126) /usr/conf/lib/libhp-ux.a(vm_sched.o): $Source: kern/sys/vm_sched.c, hpuxsysvm, vvos_rose, rose0321 $ $Date: 01/01/26 10:03:55 $ $Revis ion: 1.6.1.12 PATCH_11.04 (PHKL_23166) $ /usr/conf/lib/libhp-ux.a(vm_vas.o): vm_vas.c $Date: 2001/09/11 13:56:29 $Revision: r11ro s/13 PATCH_11.00 (PHKL_25210) /usr/conf/lib/libhp-ux.a(vm_vfd.o): vm_vfd.c $Date: 2002/10/16 15:44:52 $Revision: r11ro s/9 PATCH_11.00 (PHKL_27994) /usr/conf/lib/libhp-ux.a(vm_vhand.o): vm_vhand.c $Date: 2002/10/09 13:05:56 $Revision: r11 ros/7 PATCH_11.00 (PHKL_28053) VirtualVaultOS.VVOS-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: /usr/conf/lib/libsec.a(audit_stub.o): $Source: kern/sec/audit_stub.c, sysaudit, vvos_rose, rose0321 $ $Date: 01/01/30 09:17:26 $ $Revi sion: 1.21.1.5 PATCH_11.04 (PHKL_23252) $ /usr/conf/lib/libsec.a(sec_audit.o): $Source: kern/sec/sec_audit.c, sysaudit, vvos_rose, rose0321 $ $Date: 02/04/15 17:17:14 $ $Revis ion: 1.35.1.14 PATCH_11.04 (PHKL_26815) $ /usr/conf/lib/libsec.a(sec_subrs.o): $Source: kern/sec/sec_subrs.c, sysmisc, vvos_rose, r ose0321 $ $Date: 99/10/26 14:15:32 $ $Revisi on: 1.13.4.18 PATCH_11.04 (PHKL_20127) $ VirtualVaultOS.VVOS-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: /usr/conf/lib/libsec.a(audit_stub.o): $Source: kern/sec/audit_stub.c, sysaudit, vvos_rose, rose0321 $ $Date: 01/01/30 09:17:26 $ $Revi sion: 1.21.1.5 PATCH_11.04 (PHKL_23252) $ /usr/conf/lib/libsec.a(sec_audit.o): $Source: kern/sec/sec_audit.c, sysaudit, vvos_rose, rose0321 $ $Date: 02/04/15 17:17:14 $ $Revis ion: 1.35.1.14 PATCH_11.04 (PHKL_26815) $ /usr/conf/lib/libsec.a(sec_subrs.o): $Source: kern/sec/sec_subrs.c, sysmisc, vvos_rose, r ose0321 $ $Date: 99/10/26 14:15:32 $ $Revisi on: 1.13.4.18 PATCH_11.04 (PHKL_20127) $ cksum(1) Output: OS-Core.CORE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: 1807138169 5655 /usr/conf/h/map.h 143359630 10831 /usr/conf/h/vm_mlock.h 2017539801 2705 /usr/conf/machine/hdl_preg.h 2704551415 54554 /usr/conf/machine/pdc_rqsts.h 2001644049 11365 /usr/conf/sio/async.h ProgSupport.C-INC,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: 2017539801 2705 /usr/include/machine/hdl_preg.h 2704551415 54554 /usr/include/machine/pdc_rqsts.h 2001644049 11365 /usr/include/sio/async.h 1807138169 5655 /usr/include/sys/map.h 143359630 10831 /usr/include/sys/vm_mlock.h OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: 29807307 21280 /usr/conf/lib/libhp-ux.a(asm_vm.o) 3713700621 22752 /usr/conf/lib/libhp-ux.a(async.o) 3790616828 4160 /usr/conf/lib/libhp-ux.a(clic_stubs.o) 3967819794 29232 /usr/conf/lib/libhp-ux.a(clock.o) 2470537683 12468 /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o) 3724721128 14204 /usr/conf/lib/libhp-ux.a(dmem.o) 4040248248 20840 /usr/conf/lib/libhp-ux.a(hdl_fault.o) 880505537 8144 /usr/conf/lib/libhp-ux.a(hdl_init.o) 3842346212 19896 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 2062130604 17072 /usr/conf/lib/libhp-ux.a(hdl_policy.o) 1885412788 13328 /usr/conf/lib/libhp-ux.a(hdl_trans.o) 3766619657 22160 /usr/conf/lib/libhp-ux.a(init_main.o) 3549314119 29744 /usr/conf/lib/libhp-ux.a(kern_exec.o) 3967297092 23648 /usr/conf/lib/libhp-ux.a(kern_exit.o) 625972594 16416 /usr/conf/lib/libhp-ux.a(kern_mallo.o) 3942834790 3896 /usr/conf/lib/libhp-ux.a(kern_mman.o) 4190000939 23428 /usr/conf/lib/libhp-ux.a(kgdb_machine.o) 1583541414 12052 /usr/conf/lib/libhp-ux.a(kmall_trace.o) 1731597603 6640 /usr/conf/lib/libhp-ux.a(onyxe.o) 344302764 24400 /usr/conf/lib/libhp-ux.a(pa_generic_psm.o) 3852171966 6816 /usr/conf/lib/libhp-ux.a(pm_core.o) 677321210 3600 /usr/conf/lib/libhp-ux.a(pm_cred.o) 2624831666 11668 /usr/conf/lib/libhp-ux.a(pm_prot.o) 1610063172 55992 /usr/conf/lib/libhp-ux.a(pm_ptrace.o) 3344747827 15676 /usr/conf/lib/libhp-ux.a(syscall.o) 511026540 30040 /usr/conf/lib/libhp-ux.a(trap.o) 2101655554 11444 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) 586276797 38620 /usr/conf/lib/libhp-ux.a(vfs_bio.o) 1070638536 4616 /usr/conf/lib/libhp-ux.a(vm_clic.o) 436809756 14280 /usr/conf/lib/libhp-ux.a(vm_kern.o) 1109291827 91708 /usr/conf/lib/libhp-ux.a(vm_machdep.o) 2710028189 23488 /usr/conf/lib/libhp-ux.a(vm_machreg.o) 3993691161 13228 /usr/conf/lib/libhp-ux.a(vm_memlock.o) 3052794803 5616 /usr/conf/lib/libhp-ux.a(vm_mlock.o) 477980323 30416 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 2601518897 18040 /usr/conf/lib/libhp-ux.a(vm_pgalloc.o) 64407676 16028 /usr/conf/lib/libhp-ux.a(vm_pregion.o) 1966779141 16188 /usr/conf/lib/libhp-ux.a(vm_realmain.o) 1087680335 9864 /usr/conf/lib/libhp-ux.a(vm_remap.o) 381852835 27976 /usr/conf/lib/libhp-ux.a(vm_sched.o) 3527523256 14988 /usr/conf/lib/libhp-ux.a(vm_vas.o) 625860242 15460 /usr/conf/lib/libhp-ux.a(vm_vfd.o) 3340079971 18316 /usr/conf/lib/libhp-ux.a(vm_vhand.o) OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: 3906462109 20624 /usr/conf/lib/libhp-ux.a(asm_vm.o) 2243581565 45472 /usr/conf/lib/libhp-ux.a(async.o) 3875020813 11024 /usr/conf/lib/libhp-ux.a(clic_stubs.o) 1787911438 70368 /usr/conf/lib/libhp-ux.a(clock.o) 2713782662 27976 /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o) 1160796224 32552 /usr/conf/lib/libhp-ux.a(dmem.o) 4129622016 40392 /usr/conf/lib/libhp-ux.a(hdl_fault.o) 3072983974 23464 /usr/conf/lib/libhp-ux.a(hdl_init.o) 3418289233 41088 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 3907024264 35664 /usr/conf/lib/libhp-ux.a(hdl_policy.o) 3938641046 30184 /usr/conf/lib/libhp-ux.a(hdl_trans.o) 4215043029 43736 /usr/conf/lib/libhp-ux.a(init_main.o) 2677937850 68480 /usr/conf/lib/libhp-ux.a(kern_exec.o) 2285317626 53616 /usr/conf/lib/libhp-ux.a(kern_exit.o) 10964779 41568 /usr/conf/lib/libhp-ux.a(kern_mallo.o) 4022565417 8456 /usr/conf/lib/libhp-ux.a(kern_mman.o) 3013996500 49288 /usr/conf/lib/libhp-ux.a(kgdb_machine.o) 3636871310 28136 /usr/conf/lib/libhp-ux.a(kmall_trace.o) 1282512851 16032 /usr/conf/lib/libhp-ux.a(onyxe.o) 1567905490 55752 /usr/conf/lib/libhp-ux.a(pa_generic_psm.o) 175160530 14040 /usr/conf/lib/libhp-ux.a(pm_core.o) 3997259958 9352 /usr/conf/lib/libhp-ux.a(pm_cred.o) 3540625849 29040 /usr/conf/lib/libhp-ux.a(pm_prot.o) 740679120 129336 /usr/conf/lib/libhp-ux.a(pm_ptrace.o) 836190093 39920 /usr/conf/lib/libhp-ux.a(syscall.o) 4199278745 56168 /usr/conf/lib/libhp-ux.a(trap.o) 2395390304 26864 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) 120762887 88024 /usr/conf/lib/libhp-ux.a(vfs_bio.o) 3690125124 9736 /usr/conf/lib/libhp-ux.a(vm_clic.o) 3036582984 62480 /usr/conf/lib/libhp-ux.a(vm_kern.o) 861168835 183360 /usr/conf/lib/libhp-ux.a(vm_machdep.o) 3807096739 51928 /usr/conf/lib/libhp-ux.a(vm_machreg.o) 681570977 32024 /usr/conf/lib/libhp-ux.a(vm_memlock.o) 535896014 12784 /usr/conf/lib/libhp-ux.a(vm_mlock.o) 1783079112 68136 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 3064558150 40856 /usr/conf/lib/libhp-ux.a(vm_pgalloc.o) 3809101619 32216 /usr/conf/lib/libhp-ux.a(vm_pregion.o) 866510408 23584 /usr/conf/lib/libhp-ux.a(vm_realmain.o) 2884444143 18504 /usr/conf/lib/libhp-ux.a(vm_remap.o) 1219047674 74528 /usr/conf/lib/libhp-ux.a(vm_sched.o) 1767516630 35632 /usr/conf/lib/libhp-ux.a(vm_vas.o) 3839794169 37680 /usr/conf/lib/libhp-ux.a(vm_vfd.o) 1674346107 45624 /usr/conf/lib/libhp-ux.a(vm_vhand.o) VirtualVaultOS.VVOS-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: 4033965152 7908 /usr/conf/lib/libsec.a(audit_stub.o) 98673373 22600 /usr/conf/lib/libsec.a(sec_audit.o) 1076729091 14524 /usr/conf/lib/libsec.a(sec_subrs.o) VirtualVaultOS.VVOS-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: 4041159678 23736 /usr/conf/lib/libsec.a(audit_stub.o) 3467010931 45696 /usr/conf/lib/libsec.a(sec_audit.o) 3818742496 42304 /usr/conf/lib/libsec.a(sec_subrs.o) Patch Conflicts: None Patch Dependencies: s700: 11.04: PHKL_19142 s800: 11.04: PHKL_19142 Hardware Dependencies: None Other Dependencies: PHKL_21685 is required when using the gang scheduler. Without PHKL_21685, the gang scheduler exhibits unacceptable performance after this patch is installed. Note: NFS functionality is not supported on VVOS. PHKL_29760: This patch is part of a set of three patches PHKL_27710, PHKL_29192,PHKL_29497 that enable P_NOSTOP, a new feature that prevents a process from being unkillable. Each patch is independantly installable Without all three installed, P_NOSTOP will be unavailable. PHKL_29760: Two other patches work in conjuction with this patch to enable PA-8700 support. These other two patches are PHKL_25154 and PHKL_25045. Supersedes: PHKL_20559 PHKL_22717 PHKL_20127 PHKL_19440 PHKL_23252 PHKL_27710 PHKL_26815 PHKL_25044 PHKL_23886 PHKL_23166 PHKL_22891 PHKL_21306 Equivalent Patches: PHKL_28766: s700: 11.00 s800: 11.00 PHKL_28765: s700: 11.11 s800: 11.11 Patch Package Size: 1330 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_29760 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_29760.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_29760. If you do not wish to retain a copy of the original software, include the patch_save_files option in the swinstall command above: -x patch_save_files=false WARNING: If patch_save_files is false when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. For future reference, the contents of the PHKL_29760.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_29760.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_29760.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: To enable the asyncio enhancement that defers memory locking to improve application startup times, create the async device file with minor number 256 using the following commands. The user must have super-user rights to execute these commands. Delete the old device file. # rmsf -v /dev/async Create the new device file # mknod /dev/async c 101 256 Note: This minor number should only be used on systems that have enough physical memory so that paging is avoided. Paging can cause serious performance degradation with this new enhancement. On systems where paging is an issue, this minor number should not be used. PHKL_29760 : This patch, PHKL_29760 , is one of the three 11.04 PA-8700 enablement patches. The other 11.04 PA-8700 enablement patches are PHKL_25154 & PHKL_25045 . Installation of each patch individually will have no effect on the system. PHKL_29760: This patch is part of a set of three patches PHKL_27710, PHKL_29192,PHKL_29497 that enable P_NOSTOP, a new feature that prevents a process from being unkillable. Each patch is independantly installable Without all three installed, P_NOSTOP will be unavailable. PHKL_27710: This patch contains part of the enhancement to enable the 3 Gb private address space feature. It is one of 4 patches. The 8 patches necessary to enable this feature are PHKL_27710, PHKL_29497, PHKL_22786 and PHKL_29730. Each patch may be installed independently of the others - if enabling the 3 Gb private address space feature is not desired. If fewer than all 8 patches are installed, the 3 Gb private address space feature will not be enabled. The code in this patch that is part of this feature will not have any impact on the system until all 8 patches are installed. In order to be able to use this feature you will need to reconfigure the kernel with a larger value for the kernel configurable variable "maxdsiz". In order to do this with SAM, you will also need to install patch PHKL_23741. Without PHKL_23741 installed SAM will not allow maxdsiz to exceed ~1.9 Gb. Note that if PHKL_23741 is not installed it is still possible to manually configure a kernel with a larger value of maxdsiz (up to 3 Gb) using config(1M). PHKL_29760: To enable shared memory dumping to application core files, you must first install this patch. After the new vmunix has been built by the patch process you need to set some kernel variables in the new vmunix using adb. To do this, first invoke adb with write capabilities on the vmunix file (typically /stand/vmunix): adb -w /stand/vmunix You may get some error output "Not an Elf file: No Elf header". ignore those errors. Setting core_addshmem_read to 1 enables dumping of read-protected shared memory segments. To set core_addshmem_read to 1, the command in adb is: core_addshmem_read?W1 adb should output: core_addshmem_read: 0 = 1 Setting core_addshmem_write to 1 enables dumping of write-protected shared memory segments. To set core_addshmem_write to 1, the command in adb is: core_addshmem_write?W1 adb should output: core_addshmem_write: 0 = 1 exit adb by typing $q Now the vmunix file should be enabled for shared memory dumping. You must reboot in order for the change to take effect. Note: if a new vmunix is generated in the future, such as after installing another kernel patch, you will need to repeat this procedure. This mechanism is typically used in troubleshooting applications. The effective user ID of the process calling async driver, typically called by a process for database applications such as Oracle and Sybase, must be a superuser or the user must be a member of a group that has the MLOCK privilege. To check the privilege capabilities for a group, issue the command: /usr/bin/getprivgrp If the output of getprivgrp(1) does not indicate that the group has the MLOCK privilege, it can be set by issuing the following command as root: /usr/bin/setprivgrp MLOCK