Patch Name: PHKL_31867 Patch Description: s700_800 11.00 Probe,IDDS,PM,VM,PA-8700,AIO,T600,FS,PDC,CLK Creation Date: 04/08/06 Post Date: 04/08/17 Hardware Platforms - OS Releases: s700: 11.00 s800: 11.00 Products: N/A Filesets: OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_31867: ABORT PANIC PHKL_30190: HANG PHKL_29648: PANIC PHKL_29345: HANG PHKL_28766: PANIC PHKL_27994: HANG Intermittent system hangs for several minutes. PHKL_27919: PANIC PHKL_27759: PANIC PHKL_27157: ABORT CORRUPTION PHKL_26800: HANG Hang - Filesystem or Process Hang PHKL_25906: PANIC PHKL_25525: HANG PHKL_25210: PANIC CORRUPTION PHKL_25188: PANIC PHKL_25164: PANIC PHKL_24612: ABORT PHKL_24457: PANIC PHKL_24273: PANIC The system panics when r_refcnt overflows PHKL_24116: OTHER Hung, Unkillable Process PHKL_24015: PANIC PHKL_23857: CORRUPTION PHKL_23813: PANIC PHKL_23812: HANG PHKL_23406: OTHER Hung, Unkillable Process 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_22493: PANIC PHKL_21775: HANG PHKL_21507: PANIC PHKL_20439: PANIC MEMORY_LEAK PHKL_22744: PANIC PHKL_22549: PANIC PHKL_22380: PANIC HANG PHKL_22126: PANIC PHKL_21781: PANIC CORRUPTION PHKL_21624: HANG PHKL_21600: PANIC PHKL_20647: HANG PHKL_20449: PANIC PHKL_20223: PANIC PHKL_21354: PANIC PHKL_20335: CORRUPTION PHKL_20222: MEMORY_LEAK PHKL_20017: OTHER Causing degradation in I/O performance of the system. PHKL_19314: HANG PHKL_19201: HANG PHKL_20836: PANIC 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_31867 Symptoms: PHKL_31867: ( SR:8606368448 CR:JAGaf29010 ) When loading DLKM software modules on large memory systems (>8GB) running 64-bit kernels, the kernel may panic with the following panic string: kalloc: out of kernel virtual address space An example stack trace is: panic+0x14 kalloc_4K+0x2a4 kalloc_from_superpage+0x170 kmalloc+0x3fc mod_obj_docommon+0x48 mod_obj_load+0x298 mod_load_helper+0x60 modld+0x200 modload+0x108 syscall+0x28c syscallinit+0x54c ( SR:8606349352 CR:JAGaf10173 ) When an application which has installed a signal handler for SIGSEGV tries to lock memory in possible stack address range above the RLIMIT_STACK limit using mlock(2), it may lose the ability to handle the SIGSEGV any longer and may be terminated when a SIGSEGV is delivered to the application at a later time. PHKL_30709: ( SR:8606353772 CR:JAGaf14566 ) After experiencing heavy memory usage, the Dynamic Buffer Cache was reduced from dbc_max_pct down to the dbc_min_pct. However, after memory was freed up, the Dynamic Buffer Cache would not grow back to dbc_max_pct and remained at dbc_min_pct, causing filesystem performance problems. PHKL_30190: ( SR:8606292921 CR:JAGae56671 ) An activity like burst of networking traffic, involving allocation of huge amount of memory from the kernel memory allocator and later release back, leaves the system low on available free memory. This leaves the system in a state of perceived hang. PHKL_29648: ( SR:8606301348 CR:JAGae64793 ) The kernel panics with the following stack trace.This occurred while tuning the block size of a database. panic+0x14 report_trap_or_int_and_panic+0x84 trap+0xd9c nokgdb+0x8 do_vm_mem_unlock+0xf8 mlock_region+0x504 mlock_pregion+0x21c foreach_mapped_range+0xac mlock_do_range+0x20c vm_mem_do_range+0xb8 vm_mem_lock+0x1c asyncdsk_lock_memory+0x14 asyncdsk_config+0x4a8 asyncdsk_ioctl+0xcbc spec_ioctl+0xac vno_ioctl+0x90 ioctl+0x1f4 syscall+0x8fc syscallrtn+0x0 PHKL_29345: ( SR:8606259056 CR:JAGae23374 ) A uniprocessor machine will hang. If a TOC is taken, vhand's stack trace will look similar to this: csuperpage_lock vhand_vfdcheck for_val3 for_val2 for_val2 for_val2 foreach_valid agepages vhand_core vhand im_vhand DoCalllist main $vstart istackatbase On a multiprocessor system, vhand will consume 100% of a cpu in system mode as seen using a performance monitoring tool. This has been observed in a system under high memory pressure while starting up a large database application. 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 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. PHKL_28053: ( SR:8606271497 CR:JAGae35704 ) After the system is up for more than 248 continuous days, paging performance decreases dramatically. 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. PHKL_27919: ( SR:8606265366 CR:JAGae29684 ) System panic early in the boot process with "alloc_pdc_pages: real_page_alloc_addr() fails, status = -1" 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_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. 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". 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. 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. 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 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_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. 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 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 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. 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. PHKL_24612: ( SR: 8606198933 CR: JAGad68122 ) Random process core dumps. 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. 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 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. 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 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. 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 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_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. 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. 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. 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_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 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 PHKL_21775: Some processes (eg . created by Shared LVM) never get reaped leading to proc table being filled and leading to a system hang. 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 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. 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. 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. 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. PHKL_21535: ( SR: 8606100830 CR: JAGab39185 ) Application core files do not include the process' attached shared memory segments. 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_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 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_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. 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. 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. 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 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). PHKL_21600: (SR: 8606134430 DTS: JAGad03565) When using mmap with a negative offset or an offset greater than 2^43, the system panics. PHKL_20647: (SR: 8606107024 DTS: JAGab76631) System hang in b_sema_get_queue() when doing an munmap(). PHKL_20449: (SR: 8606106816 DTS: JAGab76230) Incorrect implementation of mmap(2) can cause system panics. 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_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. 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. PHKL_21024: ( SR: 8606112164 DTS: JAGab84450 ) Enhancement: Performance changes for corner case in RTSCHED scheduling. This patch has no impact on most systems. 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. 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. 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. 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. 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..] 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. 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_17038: The system will trap 15 data page fault when tracing for leaks without also tracing for corruption. PHKL_20945: ( SR: 8606112164 DTS: JAGab84450 ) Enhancement: Performance changes for corner case in RTSCHED scheduling. This patch has no impact on most systems. 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. 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 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. 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. 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. 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_31867: ( SR:8606368448 CR:JAGaf29010 ) This happens on large memory systems due to unavailability of 32-bit kernel virtual addresses. DLKM needs 32-bit kernel virtual addresses to load the module, but these addresses are already taken by kernel data structures. Resolution: Now a significant amount of 32-bit kernel virtual addresses are left unallocated for later use by other kernel modules such as DLKMs. ( SR:8606349352 CR:JAGaf10173 ) In kernel mode, accessing user stack addresses by using non access instructions like "PROBE" beyond RLIMIT_STACK will result in stack growth failure through a non-access fault. In such a case kernel incorrectly resets the SIGSEGV handler installed by the application. Resolution: In the stack growth failure case, if the fault is from kernel mode and is a non-access fault, SIGSEGV handler will not be reset. PHKL_30709: ( SR:8606353772 CR:JAGaf14566 ) The buffer cache routines are unable to reuse the buffer headers on the empty queue when they try to obtain a new buffer. Hence, expansion of the buffer cache fails, and an existing buffer is reused. Resolution: The buffers on the empty queue are now properly reused so that the buffer cache can be expanded. PHKL_30190: ( SR:8606292921 CR:JAGae56671 ) The kernel memory garbage collector is not aggressive enough to return all the freed memory back to the system. Resolution: The garbage collection is made more aggressive based on the adjustment of adb'able variable, "kmem_gc_fraction" in the range of 1 to 16. The garbage collector is most aggressive when the variable is set to 1. It is least aggressive when the variable is set to the default value of 16. This variable has been added to avoid unnecessary performance side effects for customers not needing aggressive garbage collection. PHKL_29648: ( SR:8606301348 CR:JAGae64793 ) An uninitialized argument was passed to the unlocking function do_vm_mem_unlock() in the error path, resulting in the panic. Resolution: Initialize the uninitialized argument to the correct value. PHKL_29345: ( SR:8606259056 CR:JAGae23374 ) Vhand uses an incorrect algorithm to lock all the sub-pages of a very large superpage (i.e. 256MB). If it fails to lock the first sub-page, it will try to relock and unlock all the sub-pages for each sub-page in the superpage. This is consuming the entire cpu resource for the cpu vhand is running on. Vhand will ultimately recover, but only after a long time (>20 minutes). Resolution: Detect when vhand can not lock the first sub-page, and skip the entire superpage, proceeding to the next. 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. 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. 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. 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. 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. 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_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. 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. 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. 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. 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. 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_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). 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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_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. 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. 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. 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_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. 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. PHKL_21775: Resolution :PM internal function prepare_to_reap_proc in kern_exit.c changed to reap system processes correctly . 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. 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. 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. 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. 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. 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. 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_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. 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_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. 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. 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. 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. 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. 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. 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. 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. 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_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. 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. 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. 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. 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. 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. 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. 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. 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. 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_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. 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. 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. 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. 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. 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. 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. 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_28180: Enhancements were delivered in a patch this one has superseded. Please review the Defect Description text for more information. 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 8606259056 8606265366 8606268349 8606271497 8606272341 8606279968 8606292921 8606301348 8606349352 8606353772 8606368448 Patch Files: OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_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.00,fa=HP-UX_B.11.00_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.00,fa=HP-UX_B.11.00_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(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.00,fa=HP-UX_B.11.00_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(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) what(1) Output: OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_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.00,fa=HP-UX_B.11.00_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.00,fa=HP-UX_B.11.00_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): clock.c $Date: 2002/11/10 22:33:25 $Revision: r11ros /9 PATCH_11.00 (PHKL_28180) /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: 2004/08/04 22:51:11 $Revision: r1 1ros/16 PATCH_11.00 (PHKL_31867) /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): init_main.c $Date: 2002/08/28 14:53:39 $Revision: r1 1ros/12 PATCH_11.00 (PHKL_27759) /usr/conf/lib/libhp-ux.a(kern_exec.o): kern_exec.c $Date: 2001/04/25 13:09:32 $Revision: r1 1ros/22 PATCH_11.00 (PHKL_24015) /usr/conf/lib/libhp-ux.a(kern_exit.o): kern_exit.c $Date: 2001/02/15 11:36:33 $Revision: r1 1ros/18 PATCH_11.00 (PHKL_23406) /usr/conf/lib/libhp-ux.a(kern_mallo.o): kern_mallo.c $Date: 2003/12/16 22:25:09 $Revision: r 11ros/9 PATCH_11.00 (PHKL_30190) /usr/conf/lib/libhp-ux.a(kern_mman.o): kern_mman.c $Date: 2004/08/04 22:51:11 $Revision: r1 1ros/5 PATCH_11.00 (PHKL_31867) /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): pm_core.c $Date: 2001/03/13 13:32:21 $Revision: r11r os/7 PATCH_11.00 (PHKL_23628) /usr/conf/lib/libhp-ux.a(pm_cred.o): pm_cred.c $Date: 2000/04/06 11:41:10 $Revision: r11r os/1 PATCH_11.00 (PHKL_21507) /usr/conf/lib/libhp-ux.a(pm_prot.o): pm_prot.c $Date: 2000/07/14 09:34:52 $Revision: r11r os/6 PATCH_11.00 (PHKL_22032) /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) pm_ptrace.c $Date: 2001/05/14 14:45:15 $Revision: r1 1ros/15 PATCH_11.00 (PHKL_24116) /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): vfs_bio.c $Date: 2004/04/16 02:23:31 $Revision: r11r os/26 PATCH_11.00 (PHKL_30709) /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): vm_machdep.c $Date: 2004/08/04 22:51:11 $Revision: r 11ros/37 PATCH_11.00 (PHKL_31867) /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: 2003/08/25 02:59:42 $Revision: r 11ros/6 PATCH_11.00 (PHKL_29648) /usr/conf/lib/libhp-ux.a(vm_mlock.o): vm_mlock.c $Date: 2000/05/03 15:11:15 $Revision: r11 ros/4 PATCH_11.00 (PHKL_21624) /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): vm_sched.c $Date: 2000/09/20 14:54:13 $Revision: r11 ros/8 PATCH_11.00 (PHKL_22440) /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: 2003/07/15 04:01:36 $Revision: r11 ros/8 PATCH_11.00 (PHKL_29345) OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_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): clock.c $Date: 2002/11/10 22:33:25 $Revision: r11ros /9 PATCH_11.00 (PHKL_28180) /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: 2004/08/04 22:51:11 $Revision: r1 1ros/16 PATCH_11.00 (PHKL_31867) /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): init_main.c $Date: 2002/08/28 14:53:39 $Revision: r1 1ros/12 PATCH_11.00 (PHKL_27759) /usr/conf/lib/libhp-ux.a(kern_exec.o): kern_exec.c $Date: 2001/04/25 13:09:32 $Revision: r1 1ros/22 PATCH_11.00 (PHKL_24015) /usr/conf/lib/libhp-ux.a(kern_exit.o): kern_exit.c $Date: 2001/02/15 11:36:33 $Revision: r1 1ros/18 PATCH_11.00 (PHKL_23406) /usr/conf/lib/libhp-ux.a(kern_mallo.o): kern_mallo.c $Date: 2003/12/16 22:25:09 $Revision: r 11ros/9 PATCH_11.00 (PHKL_30190) /usr/conf/lib/libhp-ux.a(kern_mman.o): kern_mman.c $Date: 2004/08/04 22:51:11 $Revision: r1 1ros/5 PATCH_11.00 (PHKL_31867) /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): pm_core.c $Date: 2001/03/13 13:32:21 $Revision: r11r os/7 PATCH_11.00 (PHKL_23628) /usr/conf/lib/libhp-ux.a(pm_cred.o): pm_cred.c $Date: 2000/04/06 11:41:10 $Revision: r11r os/1 PATCH_11.00 (PHKL_21507) /usr/conf/lib/libhp-ux.a(pm_prot.o): pm_prot.c $Date: 2000/07/14 09:34:52 $Revision: r11r os/6 PATCH_11.00 (PHKL_22032) /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) pm_ptrace.c $Date: 2001/05/14 14:45:15 $Revision: r1 1ros/15 PATCH_11.00 (PHKL_24116) /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): vfs_bio.c $Date: 2004/04/16 02:23:31 $Revision: r11r os/26 PATCH_11.00 (PHKL_30709) /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): vm_machdep.c $Date: 2004/08/04 22:51:11 $Revision: r 11ros/37 PATCH_11.00 (PHKL_31867) /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: 2003/08/25 02:59:42 $Revision: r 11ros/6 PATCH_11.00 (PHKL_29648) /usr/conf/lib/libhp-ux.a(vm_mlock.o): vm_mlock.c $Date: 2000/05/03 15:11:15 $Revision: r11 ros/4 PATCH_11.00 (PHKL_21624) /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): vm_sched.c $Date: 2000/09/20 14:54:13 $Revision: r11 ros/8 PATCH_11.00 (PHKL_22440) /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: 2003/07/15 04:01:36 $Revision: r11 ros/8 PATCH_11.00 (PHKL_29345) cksum(1) Output: OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_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.00,fa=HP-UX_B.11.00_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.00,fa=HP-UX_B.11.00_32,v=HP: 819253140 21280 /usr/conf/lib/libhp-ux.a(asm_vm.o) 2017025314 22604 /usr/conf/lib/libhp-ux.a(async.o) 82917887 4184 /usr/conf/lib/libhp-ux.a(clic_stubs.o) 1826960 29008 /usr/conf/lib/libhp-ux.a(clock.o) 3729849144 12468 /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o) 3295236450 14204 /usr/conf/lib/libhp-ux.a(dmem.o) 1533650307 21392 /usr/conf/lib/libhp-ux.a(hdl_fault.o) 1102221990 8208 /usr/conf/lib/libhp-ux.a(hdl_init.o) 84976403 19544 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 705263916 16900 /usr/conf/lib/libhp-ux.a(hdl_policy.o) 2792191408 13352 /usr/conf/lib/libhp-ux.a(hdl_trans.o) 3176532689 24136 /usr/conf/lib/libhp-ux.a(init_main.o) 878513045 32016 /usr/conf/lib/libhp-ux.a(kern_exec.o) 1930819842 27244 /usr/conf/lib/libhp-ux.a(kern_exit.o) 3709035394 17192 /usr/conf/lib/libhp-ux.a(kern_mallo.o) 3688871015 3908 /usr/conf/lib/libhp-ux.a(kern_mman.o) 1258550027 23508 /usr/conf/lib/libhp-ux.a(kgdb_machine.o) 2965341838 12052 /usr/conf/lib/libhp-ux.a(kmall_trace.o) 1876419709 6688 /usr/conf/lib/libhp-ux.a(onyxe.o) 3061039034 24204 /usr/conf/lib/libhp-ux.a(pa_generic_psm.o) 3765304630 8424 /usr/conf/lib/libhp-ux.a(pm_core.o) 1931492030 3940 /usr/conf/lib/libhp-ux.a(pm_cred.o) 3764152189 17348 /usr/conf/lib/libhp-ux.a(pm_prot.o) 1767454221 55296 /usr/conf/lib/libhp-ux.a(pm_ptrace.o) 45105471 11480 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) 4261964983 38492 /usr/conf/lib/libhp-ux.a(vfs_bio.o) 2692106019 4616 /usr/conf/lib/libhp-ux.a(vm_clic.o) 1294729504 14300 /usr/conf/lib/libhp-ux.a(vm_kern.o) 3012355630 91568 /usr/conf/lib/libhp-ux.a(vm_machdep.o) 3710681386 23688 /usr/conf/lib/libhp-ux.a(vm_machreg.o) 22614421 13228 /usr/conf/lib/libhp-ux.a(vm_memlock.o) 4253005978 5508 /usr/conf/lib/libhp-ux.a(vm_mlock.o) 2878009369 30512 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 4075874153 18108 /usr/conf/lib/libhp-ux.a(vm_pgalloc.o) 3111573900 16056 /usr/conf/lib/libhp-ux.a(vm_pregion.o) 2925631355 16212 /usr/conf/lib/libhp-ux.a(vm_realmain.o) 4268662544 9864 /usr/conf/lib/libhp-ux.a(vm_remap.o) 2104562799 27896 /usr/conf/lib/libhp-ux.a(vm_sched.o) 2424010232 14996 /usr/conf/lib/libhp-ux.a(vm_vas.o) 529178592 15688 /usr/conf/lib/libhp-ux.a(vm_vfd.o) 613065830 18664 /usr/conf/lib/libhp-ux.a(vm_vhand.o) OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP: 3906462109 20624 /usr/conf/lib/libhp-ux.a(asm_vm.o) 2387347729 47088 /usr/conf/lib/libhp-ux.a(async.o) 1522619762 11064 /usr/conf/lib/libhp-ux.a(clic_stubs.o) 3587661554 69880 /usr/conf/lib/libhp-ux.a(clock.o) 867340842 27976 /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o) 4179883992 32600 /usr/conf/lib/libhp-ux.a(dmem.o) 2501340687 41432 /usr/conf/lib/libhp-ux.a(hdl_fault.o) 647205245 23664 /usr/conf/lib/libhp-ux.a(hdl_init.o) 3803636533 40584 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 3458366998 35712 /usr/conf/lib/libhp-ux.a(hdl_policy.o) 2397291949 30128 /usr/conf/lib/libhp-ux.a(hdl_trans.o) 4025324992 45600 /usr/conf/lib/libhp-ux.a(init_main.o) 3910748425 73064 /usr/conf/lib/libhp-ux.a(kern_exec.o) 1446147842 58008 /usr/conf/lib/libhp-ux.a(kern_exit.o) 539022173 42256 /usr/conf/lib/libhp-ux.a(kern_mallo.o) 3500342877 9568 /usr/conf/lib/libhp-ux.a(kern_mman.o) 1251457818 49456 /usr/conf/lib/libhp-ux.a(kgdb_machine.o) 2315482884 28136 /usr/conf/lib/libhp-ux.a(kmall_trace.o) 2377445656 16120 /usr/conf/lib/libhp-ux.a(onyxe.o) 3129906000 56256 /usr/conf/lib/libhp-ux.a(pa_generic_psm.o) 3497115895 15600 /usr/conf/lib/libhp-ux.a(pm_core.o) 1935319995 11120 /usr/conf/lib/libhp-ux.a(pm_cred.o) 1706233712 38488 /usr/conf/lib/libhp-ux.a(pm_prot.o) 1298300107 128424 /usr/conf/lib/libhp-ux.a(pm_ptrace.o) 1778500772 26936 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o) 3164564886 87024 /usr/conf/lib/libhp-ux.a(vfs_bio.o) 3690125124 9736 /usr/conf/lib/libhp-ux.a(vm_clic.o) 2977196837 62544 /usr/conf/lib/libhp-ux.a(vm_kern.o) 1087050760 190568 /usr/conf/lib/libhp-ux.a(vm_machdep.o) 3593328716 51592 /usr/conf/lib/libhp-ux.a(vm_machreg.o) 454929313 32040 /usr/conf/lib/libhp-ux.a(vm_memlock.o) 4276086089 12768 /usr/conf/lib/libhp-ux.a(vm_mlock.o) 3607499471 69080 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 2937271311 40984 /usr/conf/lib/libhp-ux.a(vm_pgalloc.o) 257973753 32224 /usr/conf/lib/libhp-ux.a(vm_pregion.o) 1270365069 23344 /usr/conf/lib/libhp-ux.a(vm_realmain.o) 163951282 18552 /usr/conf/lib/libhp-ux.a(vm_remap.o) 803693801 75072 /usr/conf/lib/libhp-ux.a(vm_sched.o) 2059058945 35600 /usr/conf/lib/libhp-ux.a(vm_vas.o) 532300028 37520 /usr/conf/lib/libhp-ux.a(vm_vfd.o) 2776738613 46440 /usr/conf/lib/libhp-ux.a(vm_vhand.o) Patch Conflicts: None Patch Dependencies: s700: 11.00: PHKL_18543 s800: 11.00: PHKL_18543 Hardware Dependencies: None Other Dependencies: PHKL_21549 is required when using the gang scheduler. Without PHKL_21549, the gang scheduler exhibits unacceptable performance after this patch is installed. PHKL_23406: If NFS is installed on the system, all five patches (PHNE_23249, PHKL_23406, PHKL_23407, PHKL_23408, PHKL_23409) are required to resolve the process hang/deadlock due to unkillable processes executed over NFS. However, if NFS is not in use, none of these patches are required. PHKL_23813: Two other patches work in conjuction with this patch to enable PA-8700 support. These other two patches are PHKL_23814 and PHKL_23815. Supersedes: PHKL_22843 PHKL_22493 PHKL_22032 PHKL_21775 PHKL_21600 PHKL_21535 PHKL_21507 PHKL_21358 PHKL_21357 PHKL_21350 PHKL_20995 PHKL_20945 PHKL_20836 PHKL_20647 PHKL_20515 PHKL_20449 PHKL_20439 PHKL_20426 PHKL_20227 PHKL_20226 PHKL_20224 PHKL_20223 PHKL_20102 PHKL_20017 PHKL_19314 PHKL_19201 PHKL_17038 PHKL_30709 PHKL_30190 PHKL_29648 PHKL_29345 PHKL_28766 PHKL_28180 PHKL_28053 PHKL_27994 PHKL_27919 PHKL_27759 PHKL_27364 PHKL_27238 PHKL_27157 PHKL_26800 PHKL_25906 PHKL_25525 PHKL_25210 PHKL_25188 PHKL_25164 PHKL_24971 PHKL_24826 PHKL_24612 PHKL_24457 PHKL_24273 PHKL_24116 PHKL_24015 PHKL_23857 PHKL_23813 PHKL_23812 PHKL_23628 PHKL_23406 PHKL_23183 PHKL_22744 PHKL_22549 PHKL_22440 PHKL_22380 PHKL_22126 PHKL_21781 PHKL_21624 PHKL_21532 PHKL_21354 PHKL_21024 PHKL_21003 PHKL_20335 PHKL_20222 Equivalent Patches: None Patch Package Size: 1230 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_31867 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_31867.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_31867. 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_31867.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_31867.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_31867.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: When the patch is installed, kmem_gc_fraction is set to a default value of 16. The variable can be tuned to a different value as described below. Tuning the adb variable can be done by either patching the vmunix file and rebooting, or patching the kernel image in memory. Only user with superuser privilege can do either of this. Please note that in the example below, kmem_gc_fraction is being set to 1. To set it to some other value, replace '0d1' by '0dx', where x is between 1 and 16. (like 0d2, 0d16, etc) To patch the vmunix file (survives a reboot), use the following command: echo 'kmem_gc_fraction?W 0d1' | adb -k -w /stand/vmunix /dev/mem To patch the in-memory kernel (does not survive a reboot), use the following command: echo 'kmem_gc_fraction/W 0d1' | adb -k -w /stand/vmunix /dev/mem 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_23813: This patch, PHKL_23813, is one of the three 11.00 PA-8700 enablement patches. The other 11.00 PA-8700 enablement patches are PHKL_23814 & PHKL_23815. Installation of each patch individually will have no effect on the system. PHKL_23406: If NFS is installed on the system, all five patches (PHNE_23249, PHKL_23406, PHKL_23407, PHKL_23408, PHKL_23409) are required to resolve the process hang/deadlock due to unkillable processes executed over NFS. However, if NFS is not in use, none of these patches are required. All five of these patches may be installed independently. If fewer than four out of the four PHKL patches are installed, the P_NOSTOP feature will not be enabled. PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20226, PHKL_20227: This patch contains part of the enhancement to enable the 3 Gb private address space feature. It is one of 8 patches. The 8 patches necessary to enable this feature are PHKL_20222, 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. 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_20174. Without PHKL_20174 installed SAM will not allow maxdsiz to exceed ~1.9 Gb. Note that if PHKL_20174 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_21535: 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