Patch Name: PHKL_29192 Patch Description: s700_800 11.04 (VVOS) POSIX AIO;getdirentries;MVFS;mmap/IDS Creation Date: 03/05/23 Post Date: 03/07/22 Hardware Platforms - OS Releases: s700: 11.04 s800: 11.04 Products: N/A Filesets: OS-Core.CORE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP ProgSupport.C-INC,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP OS-Core.KERN2-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP OS-Core.KERN2-RUN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_29192: PANIC CORRUPTION Based on HP-UX Patch PHKL_28202: PANIC Based on HP-UX Patch PHKL_27770: CORRUPTION PHKL_25056: PANIC CORRUPTION HANG Based on HP-UX Patch PHKL_25475: PANIC CORRUPTION HANG PHKL_25040: OTHER PANIC CORRUPTION HANG Based on HP-UX Patch PHKL_24943: HANG Based on HP-UX Patch PHKL_24753: PANIC HANG Based on HP-UX Patch PHKL_23955: OTHER Poor performance due to mutex contention on large multi-threaded applications. Based on HP-UX Patch PHKL_23002: CORRUPTION PANIC HANG Based on HP-UX Patch PHKL_22940: HANG thread hang PHKL_25035: PANIC Based on HP-UX Patch PHKL_22796: PANIC PHKL_23124: PANIC HANG Based on HP-UX Patch PHKL_22517: PANIC Based on HP-UX Patch PHKL_21608: PANIC Based on HP-UX Patch PHKL_20315: PANIC HANG PHKL_23054: ABORT OTHER PANIC CORRUPTION MEMORY_LEAK HANG Based on HP-UX Patch PHKL_22097: MEMORY_LEAK Based on HP-UX Patch PHKL_22022: HANG Based on HP-UX Patch PHKL_21885: CORRUPTION A clean file on VxFS can be marked bad. Based on HP-UX Patch PHKL_19311: OTHER Loss of coherency between IO and mmap Based on HP-UX Patch PHKL_17543: PANIC Based on HP-UX Patch PHKL_16983: CORRUPTION Based on HP-UX Patch PHKL_27089: ABORT PANIC HANG Based on HP-UX Patch PHKL_26059: ABORT Based on HP-UX Patch PHKL_25999: PANIC HANG PHKL_23020: PANIC HANG Based on HP-UX Patch PHKL_20883: HANG Based on HP-UX Patch PHKL_20659: PANIC Based on HP-UX Patch PHKL_20399: HANG PHKL_22988: OTHER PANIC Based on HP-UX Patch PHKL_20625: PANIC Based on HP-UX Patch PHKL_23617: OTHER False ServiceGuard failovers due to long dispatch latency. Based on HP-UX Patch PHKL_23408: OTHER Hung, unkillable process Based on HP-UX Patch PHKL_23180: PANIC PHKL_22562: PANIC Based on HP-UX Patch PHKL_20202: PANIC This patch must be applied for nfs/tcp to function. PHKL_18753: OTHER HANG Based on HP-UX Patch PHKL_24733: HANG Based on HP-UX Patch PHKL_23842: OTHER False ServiceGuard failovers after long dispatch latency in the kernel. Based on HP-UX Patch PHKL_23407: OTHER Hung, Unkillable process PHKL_18547: OTHER Based on HP-UX Patch PHKL_14119: OTHER Binary compatibility was not maintained for 32 bit applications running on 64 bit systems. 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_29192 Symptoms: PHKL_29192: Ported HP-UX patch PHKL_28202 to VVOS Based on HP-UX patch PHKL_28202: ( SR:8606242881 CR:JAGae10116 ) System panic when attempting to free an inactive lnode. It may appear as a Data Page Fault in freelonode(), with a stack trace similar to the first trace shown below, or as a call to panic() from lo_realvfs(), with a stack trace similar to the second. first stack trace: ------------------ freelonode+0x90 lo_inactive+0x124 locallookuppn+0x508 lookuppn+0x104 lookupname+0x40 vn_open+0x68 copen+0xd0 open+0x3c syscall+0x6f8 open+0x3c syscall+0x6f8 syscallinit+0x54c second stack trace: ------------------- panic+0x14 lo_realvfs+0x9c freelonode+0xdc lo_inactive+0x124 locallookuppn+0x508 lookuppn+0x104 vn_create+0x94 vn_open+0x1a0 copen+0xd0 open+0x3c syscall+0x6f8 syscallrtn+0x0 ( SR:8606270370 CR:JAGae34608 ) System panic appears as a Data Page Fault in real_unselect(), with a stack trace shown below. panic+0x14 report_trap_or_int_and_panic+0x84 interrupt+0x1d4 ihandler+0x928 real_unselect+0x20 unselect+0x3c invoke_callouts_for_self+0xc0 sw_service+0xb0 mp_ext_interrupt+0x150 ihandler+0x904 Based on HP-UX patch PHKL_28152: ( SR:8606269677 CR:JAGae33912 ) Enhancement: This product update modifies the Process Resource Manager (PRM) code to make use of new kernel internal interfaces to the LVM subsystem that are delivered by PHKL_28150. These interface changes are intended to separate LVM from other kernel subsystems in order to make it easier to maintain high quality LVM code. The use of these new interfaces will have no functional impact on your system. Based on HP-UX patch PHKL_27770: ( SR:8606263473 CR:JAGae27799 ) This problem occurs on systems running MC/ServiceGuard and either of the unsupported performance tools 'cyclemeter' or 'vsar'. Because of this defect, an MC/ServiceGuard system did not TOC after cmcld failfast. Data corruption results from the continued operation of the system that was supposed to stop running with a TOC. Based on HP-UX patch PHKL_27813: ( SR:8606233059 CR:JAGae02283 ) Posix Asynchronous I/O uses Direct I/O instead of buffered I/O after installing JFS 3.3. Applications that rely on data buffering may experience some performance degradation. PHKL_23054: Ported HP-UX patch PHKL_22677 to VVOS Based on HP-UX patch PHKL_22677: ( SR: 8606166417 CR: JAGad35704 ) When getdents() is incorrectly called with a regular file in a VxFS(JFS) file system, the following message will be reported and the clean file can be marked bad: "vxfs: mesg 008: vx_direrr- file system inode \ X block Y error 6" or "vxfs: mesg 017: vx_dirbread - file system inode \ X marked bad" or "vxfs: mesg 016: vx_ilisterr - file system error \ reading inode X" Based on HP-UX patch PHKL_22097: ( SR: 8606141023 CR: JAGad10384 ) The stat() routine does not return a valid inode when used on a MVFS filesystem with a 64-bit executable. Based on HP-UX patch PHKL_22022: ( SR: 8606143417 CR: JAGad12747 ) rcp(1) command hangs on 11.00 while copying sparse file from local HFS file system to remote node. Based on HP-UX patch PHKL_21885: ( SR: 8606140236 CR: JAGad09558 ) When getdirentries() is incorrectly called with a regular file in a VxFS(JFS) file system, the following message will be reported and the clean file can be marked bad: "vxfs: mesg 008: vx_direrr - file system inode X block Y error 6" or "vxfs: mesg 017: vx_dirbread - file system inode X marked bad" or "vxfs: mesg 016: vx_ilisterr - file system error reading inode X" Based on HP-UX patch PHKL_21349: ( SR: 8606132612 CR: JAGad01761 ) The Praesidium IDS/9000 product requires this patch in order to run. This patch has no impact on systems without the Praesidium IDS/9000 product installed and enabled. Based on HP-UX patch PHKL_19991: SR: 5003448100 CR: JAGaa72900 The HP-UX 11.00 base kernel does not have full support for JFS ACLs. Based on HP-UX patch PHKL_19311: When a user mmap's a file and also does reads/writes to it, under rare conditions the contents written through "normal I/O" will not be seen by mmap, thus losing coherency. (It should be noted that HP-UX provides *limited* support for coherency.) Based on HP-UX patch PHKL_18797: SR: 1653138164 DTS: DSDe425274 Setting a negative timestamp with utime(2) fails. Based on HP-UX patch PHKL_17543: Data page fault Panic caused from lbcopy_gr_method Whole disc configuration of 11.00 hp-ux crashed with datapage fault several minutes after installation/running. Based on HP-UX patch PHKL_16983: The open system call() when done on an NFS mount occasionally returns errno=0 and r_val1 = 0. Subsequent use of the FD will return EBADF or unintentionally send data to the stdin FD...ie 0. Based on HP-UX patch PHKL_27510: ( SR:8606241982 CR:JAGae09237 ) autofs and other applications that depend on device ids in /etc/mnttab may fail because the device ids have the sign bit on. Based on HP-UX patch PHKL_27351: ( SR:8606204668 CR:JAGad73849 ) The creat(2) system call fails with ENOENT. Based on HP-UX patch PHKL_27089: ( SR:8606242231 CR:JAGae09484 ) Processes which call vfork(2) can sometimes hang and become unkillable. Further, executing a setpriority(2) operation (e.g. via renice(1M)) on such a process may cause a kernel panic due to a Data Page Fault, with the stack trace: is_realtime+0x0 get_pregionnice+0x34 update_preg_nice+0x44 donice+0xc8 setpriority+0x6c syscall+0x750 syscallinit+0x5b0 ( SR:8606250250 CR:JAGae16625 ) The 64bit Java Virtual Machine (JVM) aborts due to "unexpected signal" or "illegal instruction" or "segmentation violation" or due to other non-deterministic error. ( SR:8606226008 CR:JAGad95080 ) System may panic with data page fault in clock interrupt path. The stack trace is as follows: panic+0x14 report_trap_or_int_and_panic+0x84 interrupt+0x1d4 $ihndlr_rtn+0x0 determine_processor_state+0xbc per_spu_hardclock+0xc8 clock_int+0x58 mp_ext_interrupt+0x150 ivti_patch_to_nop3+0x0 idle+0x108 swidle_exit+0x0 ( SR:8606255992 CR:JAGae20309 ) The system panics due to a data page fault in the signal routines for multi-threaded processes. This panic is quite rare, occuring only under extreme loading conditions, such as those existing during HP internal kernel stress testing. To date, this problem has not been reported by any customer. The stack trace of the faulting thread will be similar to the following: crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 pm_signalx+0x25c pm_psignalx+0x54 psignalx+0x74 kill1+0x228 kill+0x58 syscall+0x8f0 ( SR:8606259456 CR:JAGae23774 ) Applications may hang with threads in the accept(2) system call. The problem occurs only when multiple threads are issuing accept(2) on the same socket, and when no thread calls accept(2) again after a thread is interrupted by a signal. ( SR:8606245322 CR:JAGae11795 ) This enhancement improves performance for multithreaded applications which make heavy use of synchronization objects such as mutexes, reader-writer locks, and POSIX semaphores, including some Java applications. ( SR:8606259600 CR:JAGae23918 ) The performance improvement for non-contended PTHREAD_PROCESS_SHARED mutexes provided by PHKL_25999 is not realized for 32-bit kernels. Based on HP-UX patch PHKL_26059: ( SR:8606227016 CR:JAGad96078 ) The signal function sigtimedwait() incorrectly returns EINVAL when the value of the timespec structure field tv_sec is 0 and field tv_nsec lies in the range 990,000,001 to 999,999,999, inclusive. This may cause an application to abort. Based on HP-UX patch PHKL_25999: ( SR:8606230577 CR:JAGad99627 ) Under extreme loads, like those used during HP internal kernel stress testing, and even then very infrequently, the kernel may panic with a data page fault in the signal routines for multi-threaded processes. The stack of the faulting thread ends with: pm_signalx() pm_psignalx() psignalx() kill1() kill() syscall() ( SR:8606186056 CR:JAGad55261 ) Software providers may observe performance deficiencies in applications which heavily use shared mutexes. Performance of a PTHREAD_PROCESS_SHARED mutex unlock operation is slower than that of a PTHREAD_PROCESS_PRIVATE mutex, even in the non-contended (i.e., no waiters) case. ( SR:8606230581 CR:JAGad99631 ) Thread cancellation sometimes, but rarely, will fail to make the target thread exit. Applications which use thread cancellation may misbehave when this happens. Sometimes they may hang waiting for the target thread to exit. ( SR:8606221319 CR:JAGad90453 ) While running iCOD and PRM on the same system, PRM groups are incorrectly allowed to exceed their CPU entitlement. This is a problem when using the PRM capping feature. ( SR:8606228779 CR:JAGad97833 ) Enhancement to increase the size of the process command line stored in the kernel. PHKL_25035: Ported HP-UX patch PHKL_23226 to VVOS Based on HP-UX patch PHKL_23226: ( SR: 8606175710 CR: JAGad44950 ) umask(1) may incorrectly set file permission bits. Based on HP-UX patch PHKL_22796: (SR:8606170084 CR:JAGad39348) The following lightweight system calls will cause the system to crash if a badly written user level program tries to branch beyond the allowed address space. lw_lwp_setprivate, lw_lwp_getprivate, lw_get_thread_times, lw_lf_send, lw_lf_next_scn, cnx_lw_pmon_read, lw_mcas_util, and lw_nosys. Based on HP-UX patch PHKL_20245: ( SR: 8606102049 CR: JAGab67439 ) Desc: msem_lock() call occasionally fails w/EINVAL One customer finds that msem_lock() occasionally fails and errno is set to EFAULT. If the exactly same msem_lock() call is executed again, it works. Based on HP-UX patch PHKL_20236: ( SR: 4701409169 DTS: JAGaa12229 ) __lw_get_thread_times reports incorrect times on V-Class systems. Most of the time it reports correctly but on occasion it will return an erroneous system time value. PHKL_25056: Ported HP-UX patch PHKL_25475 to VVOS Based on HP-UX patch PHKL_25475: ( SR:8606221043 CR:JAGad90179 ) The kernel build may fail during, or after, installation of patch PHKL_23002 or a superseding patch with the error: cpp: "/usr/conf/space.h.d/core-hpux.h", line 27: error 4036: Can't open include file 'sys/spinlock.h'. *** Error exit code 1 ( SR:8606220050 CR:JAGad89191 ) With PHKL_23955 or a superseding patch installed, an interruptible system hang on a uniprocessor system or a thread hang and/or performance degradation on a multiprocessor system may occur. ( SR:8606199334 CR:JAGad68521 ) When the system is running an application with many threads sleeping with short timer expirations, it may panic with a Data Page fault. Following is a typical stack trace footprint that exhibits the problem: 0) panic+0x14 1) report_trap_or_int_and_panic+0x84 2) interrupt+0x1d4 3) ihandler+0x928 +------------- TRAP ---------------------------- | Trap type 15 in KERNEL at 0x185ce0 (pm_setrun+0x140) | p struct save_state 0.0xd4dd8e0 +------------- TRAP ---------------------------- 4) pm_setrun+0x140 5) chanq_timer_expire+0x17c 6) invoke_callouts_for_self+0xc0 7) sw_service+0xb0 8) mp_ext_interrupt+0x150 9) ihandler+0x904 +------------- TRAP ---------------------------- | Trap type 4 in USER mode at 0xc45f000.0x35e58 | p struct save_state 0.0xd4dd000 +------------- TRAP ---------------------------- PHKL_25040: Ported HP-UX patch PHKL_24943 to VVOS Based on HP-UX patch PHKL_24943: ( SR:8606182941 CR:JAGad5215 ) Application thread hangs when restarted after using _lwp_setstate to change its PC (program counter). Based on HP-UX patch PHKL_24734: ( SR:8606196287 CR:JAGad65490 ) Select(2) when called with zero file descriptors and a zero timeout value, does not return immediately as it is supposed to, according to the man page. Based on HP-UX patch PHKL_24753: ( SR: 8606223152 CR: JAGad92255 ) Application threads using select() can miss calls to unselect(), essentially missing an event that occurs over a short duration. As a result of missing the event, the application and thread will become either hung or unkillable. Based on HP-UX patch PHKL_24752: ( SR:8606196546 CR:JAGad65749 ) When threads are waiting on libpthread spinlocks, an application may not be able to take advantage of idle CPU cycles. Based on HP-UX patch PHKL_23955: ( SR:8606185652 CR:JAGad54854 ) When a multi-threaded program contends on a mutex or a set of mutexes, the time spent in system calls (i.e. sched_yield, ksleep, and kwakeup), with non-realtime workload, causes severe performance degradation. The symptoms of the problem are the extremely high ratio of system to user CPU time and a high call frequency to sched_yield(), ksleep() and kwakeup(). Based on HP-UX patch PHKL_23002: ( SR:8606164923 CR:JAGad34221 ) The kernel may crash or hang in ksleep(), kwakeup(), or chanq_*() routines after the value of the tunable "chanq_hash_locks" is changed to something greater 256. Alternatively, these functions may corrupt other kernel global data, causing other modules to crash, hang, or misbehave. In the case that a panic occurs, the stack trace might look similar to to the one below: stack trace for event 0 crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 chanq_lookup+0x4c ksleep_one+0xc4 ksleep+0xd4 syscall+0x200 $syscallrtn+0x0 Based on HP-UX patch PHKL_22940: ( SR: 8606167399 CR: JAGad36685 ) Occasionally a thread would miss a timeout interrupt and sleep forever or until it was sent a signal. The sleeping thread could cause an application hang. PHKL_22562: Ported HP-UX patch PHKL_20202 to VVOS Based on HP-UX patch PHKL_20202: ( SR: 8606128857 CR: JAGab14278 ) System panics while using nfs/tcp, ksleep_one() appears in the panic stack trace. PHKL_18753: Ported HP-UX patch PHKL_14750 to VVOS Based on HP-UX patch PHKL_14750: The previous patch has been recut to include compile-based performance tuning. There is no functional change in this patch. Based on HP-UX patch PHKL_14493: pthread_cond_timedwait(3T) intermittently returns EINVAL though the arguments are all valid. Based on HP-UX patch PHKL_24733: ( SR: 8606198999 CR: JAGad68186 ) The system hangs due to the searching of long thread lists to deliver a signal when that signal is masked by all threads in the process. Based on HP-UX patch PHKL_23842: ( SR: 8606185342 CR: JAGad54537 ) Runnable threads may trigger false ServiceGuard failovers after long dispatch latency in the kernel. Based on HP-UX patch PHKL_23407: (SR: 8606103740 CR: JAGab70789) (SR: 8606159451 CR: JAGad28779) A multi-threaded process being executed over NFS can become hung and unkillable while performing either a fork, core, setrlimit, SIGSTOP, or debugger operations. Based on HP-UX patch PHKL_23001: ( SR: 8606161075 CR: JAGad30393 ) A multithreaded process may not always perform the desired signal handler action if the system V signal(2) interface is used or if the SA_RESETHAND flag is set with the other signalling interfaces. This could occur when the process must handle more than one instance of the same signal in parallel. Similar problems with signal handling could occur if the user calls sigaction() while the signal is being processed. The most likely results of handling the action incorrectly would be for the process to be terminated or for a user specified action to be performed more than once before the signal action is reset to SIG_DFL. PHKL_22988: Ported HP-UX patch PHKL_22568 to VVOS Based on HP-UX patch PHKL_22568: ( SR: 8606163813 CR: JAGad33117 ) A multithreaded private third quadrant process will core dump. Based on HP-UX patch PHKL_22145: ( SR: 8606141357 CR: JAGad10718 ) Multi-threaded processes may not respond to SIGKILL, SIGSTOP, or SIGCONT making the process "unkillable". Based on HP-UX patch PHKL_21830: ( SR: 8606127468 CR: JAGac77753 ) User can incorrectly create a thread and bind it to a deallocated processor. Note that this defect can only be seen when processors have been deallocated explicitly through administrator intervention. Based on HP-UX patch PHKL_21348: ( SR: 8606124297 CR: JAGac39680 ) When an application specifies signal(SIGCHLD,SIG_IGN) and forks a child, it still gets interrupted when the child exits. This premature interruption also occurs in SIGCONT/SIG_IGN. ( SR: 8606132611 CR: JAGad01760) The Praesidium IDS/9000 product requires this patch in order to run. This change has no impact on systems without the Praesidium IDS/9000 product installed and enabled. Based on HP-UX patch PHKL_20942: ( SR: 8606112164 DTS: JAGab84450 ) Enhancement: Performance changes for corner case in RTSCHED scheduling. This patch has no impact on most systems. Based on HP-UX patch PHKL_20625: ( SR: 8606110344 CR: JAGab83048 ) UP system panics with Data Page Fault: panic+0x14 report_trap_or_int_and_panic+0x4c trap+0xea8 $RDB_trap_patch+0x38 ksw_remove_from_proc+0x5c sigsuspend+0x1c0 syscall+0x1c8 $syscallrtn+0x0 Based on HP-UX patch PHKL_19930: ( SR: 8606103530 DTS: JAGab70391 ) Delivery of signals to processes with many (1000's) threads is very slow and significantly reduces system throughput. Based on HP-UX patch PHKL_19531: ( SR: 1653296996 DTS: JAGaa94126 ) Immediate return from delays with time interval requests in excess of 2^31-1 seconds. The limit is now 2^32-1 for 32-bit systems, and 2^64-1 64-bit systems. Based on HP-UX patch PHKL_24502: ( SR: 8606170321 CR: JAGad39585 ) Performance and response time degradation may be seen when the fair share scheduler is run on a lightly loaded system with 24 or more processors. Based on HP-UX patch PHKL_23617: ( SR: 8606186407 CR: JAGad55611 ) Excessive entries in the system log for events signalling override of mandatory binding can cause the system log to fill up. Syslog availability is critical to some customers. Following are the two samples of the unwanted log messages: Jan 11 15:16:00 ssfih06 vmunix: mpc_bindlwp: Overriding conflicting mandatory binding! Jan 11 15:16:00 ssfih06 vmunix: mpc_bindlwp: Migrating process 2450 from processor 1 to processor 0 ! ( SR: 8606185342 CR: JAGad54537 ) Runnable threads may trigger false ServiceGuard failovers after long dispatch latency in the kernel. Based on HP-UX patch PHKL_23408: A multi-threaded process being executed over NFS can become hung and unkillable while performing one of a fork, core, setrlimit, SIGSTOP, or debugger operations. Based on HP-UX patch PHKL_23180: ( SR:8606173973 CR:JAGad43226 ) When mpctl() is called with MPC_GETNEXTSPU and arg1 has a negative value, the system will panic with a Data Page Fault. The strack trace is as follows: panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 thandler+0xd20 mpctl+0x158 syscall+0x480 syscallinit+0x54c PHKL_23020: Ported HP-UX patch PHKL_21832 to VVOS Based on HP-UX patch PHKL_21832: (SR: 8606127468 CR: JAGac77753) System call mpctl(2) using arguments MPC_GETNUMSPUS, MPC_GETFIRSTSPU, and MPC_GETNEXTSPU, can incorrectly return information on processors that have already been deallocated. Performance degrades when processors are deallocated. The loss in performance is greater than what the inactive processors account for. Threads may be incorrectly scheduled on deallocated processors. Note that these defects can only be seen when processors have been deallocated explicitly through administrator intervention. Based on HP-UX patch PHKL_21111: (SR: 8606106739 CR: JAGab76092) The capping feature of the fair share scheduler causes severe performance problems for underloaded multi-processor systems. (SR: 8606104136 CR: JAGab71488) PHKL_20883 can potentially cause panic with floating-point underflow exception. Based on HP-UX patch PHKL_20883: (SR: 8606104136 CR: JAGab71488) System appears to hang when a realtime thread, such as midaemon, manages to starve all other threads on the same processor. The thread balancing across multiple processors does not happen. Based on HP-UX patch PHKL_20941: ( SR: 8606112164 DTS: JAGab84450 ) PHKL_20941 enhances the execution of rtsched threads by optimizing the scheduler to take into consideration the current SPU that the thread is running on. Based on HP-UX patch PHKL_20659: (SR: 8606114252 CR: JAGac23971) Panic in pm_setrun() due to sleeping thread not on sleepq. Following is the stack trace footprint that exhibits the problem: 0) panic+0x14 1) report_trap_or_int_and_panic+0x80 2) interrupt+0x1d4 3) $ihndlr_rtn+0x0 4) pm_setrun+0x140 5) pm_signalx+0x288 6) pm_psignalx+0x54 7) ktimer_expire+0x204 8) invoke_callouts_for_self+0xc0 9) sw_service+0xb0 10) mp_ext_interrupt+0x144 11) ivti_patch_to_nop3+0x0 12) idle+0x43c 13) swidle_exit+0x0 Based on HP-UX patch PHKL_20399: (SR: 8606105735 CR: JAGab73995) On multi processor systems, after a reboot, the system may hang due to a defect in idle() loop. Based on HP-UX patch PHKL_19873: With FSS enabled on an MP system and where process groups have fewer processes than CPUs, process performance is less than expected for the CPU resource 'share' requested. This results in a 5-20% performance hit on MP systems. PHKL_23124: Ported HP-UX patch PHKL_22589 to VVOS Based on HP-UX patch PHKL_22589: ( SR: 8606163603 CR: JAGad32907 ) After PHKL_18543 is installed, select() will incorrectly return 0 when it is interrupted after being called with no file descriptors and a timeout. According to the X/Open standard, select() should return -1 for this case. Based on HP-UX patch PHKL_22517: ( SR: 8606163287 CR:JAGad32591 ) Data Page Fault in getmount_entry() system call. The panic stack might look like, panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 vx_active_common_flush+0xb8 vx_getmount+0x4c getmount_entry+0x140 syscall+0x480 $syscallrtn+0x0 Based on HP-UX patch PHKL_22142: ( SR: 8606126449 CR:JAGac57014 ) When using select() with a large number of BSD socket file descriptors, performance degradation is observed. Based on HP-UX patch PHKL_21608: ( SR: 8606133836 CR:JAGad02977 ) Users see a PANIC with 'lo_realvfs' message. The following stack trace is seen: panic+0x14 lo_realvfs+0x9c freelonode+0xdc lo_inactive+0x124 locallookuppn+0x4fc lookuppn+0xf8 lookupname+0x40 vn_open+0x68 copen+0xd0 open+0x3c syscall+0x480 $syscallrtn+0x0 Based on HP-UX patch PHKL_21361: ( SR: 8606132624 CR: JAGad01773 ) The Praesidium IDS/9000 product requires this patch in order to run. This patch has no impact on systems without the Praesidium IDS/9000 product installed and enabled. Based on HP-UX patch PHKL_20315: ( SR: 8606109444 DTS: JAGab82146 ) A system may panic in lo_realvfs() when using LOFS file systems. ( SR: 4701423798 DTS: JAGab13874 ) The system may hang using LOFS if the directory being mounted and the mount point are the same. To reproduce the problem: # mount -F lofs /mnt /mnt # ls /mnt This process will loop in the kernel indefinitely. ( SR: 1653263962 DTS: JAGaa12500 ) There are two types of failures that may be observed with this problem. 1) A stale file handle is returned when mounting an LOFS file system over NFS 2) Loopback mounts fail for direct map pathname from AUTOFS (automount); this is an enhancement in LOFS to support AUTOFS. ( SR: 4701393884 CR: JAGaa08709 ) A directory mounted via the loop-back file system (LOFS) can be removed, thus making the mount inaccessible. Based on HP-UX patch PHKL_15689: vfs.o: 1. Cannot create AutoFS mount points. autosysgen.o: 1. 32-bit AutoFS commands fail on 64-bit OS. Based on HP-UX patch PHKL_20349: ( SR: 8606110852 CR: JAGab83602 ) Enhancement to provide support for the pread(2) and pwrite(2) system calls. PHKL_18547: Ported HP-UX patch PHKL_14119 to VVOS Based on HP-UX patch PHKL_14119: ( SR: 4701375543 DTS: DSDe440886 ) The original instance of this patch, PHKL_13290, was not marked as a critical patch. It should have been. Based on HP-UX patch PHKL_13290: ( SR: 4701375543 DTS: DSDe440886 ) System calls with signed integer arguments called from 32-bit binary programs may behave incorrectly when passed negative values, while running on 64 bit systems. This defect only impacts 64 bit systems. Defect Description: PHKL_29192: Ported HP-UX patch PHKL_28202 to VVOS Based on HP-UX patch PHKL_28202: ( SR:8606242881 CR:JAGae10116 ) These panics occurred after multiple threads were allowed to create duplicate lfsnode structures. The code intended to detect and compensate for this situation sometimes freed the "wrong" entry, leading to a subsequent panic when later attempting to free the lnode structure which referred it. Resolution: The code was modified so that duplicate lfsnode structures are no longer created. ( SR:8606270370 CR:JAGae34608 ) This problem manifests as a data page fault in real_unselect. The problem is that real_unselect is invoked via the timeout mechanism and at the point that it starts running, the thread that had been sleeping may no longer exist. Resolution: At the beginning of real_unselect, a check is made to verify that kthread pointer still points to a valid kthread. Based on HP-UX patch PHKL_28152: ( SR:8606269677 CR:JAGae33912 ) This product update contains minor enhancements to PRM code to use new LVM kernel internal interfaces. Resolution: Changes were made to PRM code so that it now uses an LVM interface to access LVM internal data. The previous implementation accessed the data directly. Based on HP-UX patch PHKL_27770: ( SR:8606263473 CR:JAGae27799 ) 'cyclemeter' and 'vsar' are unsupported tools available for HP-UX. These tools are not certified for use on customer systems. The tools cyclemeter and vsar are unaware of MC/ServiceGuard and MC/ServiceGuard is unaware of the tools. However, both MC/ServiceGuard and the tools make use of a kernel facility that provides a 'callback' on each clock tick. This facility is designed to handle only one callback function. As long as only MC/ServiceGuard or only the tools were using the callback facility, there was no conflict. However, when MC/ServiceGuard is already using the callback facility and either cyclemeter or vsar is started, the tools replace the MC/ServiceGuard callback function with their own function pointer and then very quickly replace the function pointer with NULL, turning off the callback. The result is that MC/ServiceGuard stops getting its callback at each clock tick. This disrupts the MC/ServiceGuard failfast operation and prevents the TOC. Resolution: This patch implements a new function which can be used to schedule a callback per processor on each clock tick. This new function will be called by future versions of the vsar and cyclemeter tools. Based on HP-UX patch PHKL_27813: ( SR:8606233059 CR:JAGae02283 ) The internal flag indicating Posix AIO is in conflict with the direct I/O flag. Resolution: Changed the Posix AIO flag to be a unique value. PHKL_23054: Ported HP-UX patch PHKL_22677 to VVOS Based on HP-UX patch PHKL_22677: ( SR: 8606166417 CR: JAGad35704 ) getdents() system call did not check if the argument is a directory file or a regular file. When it is called on a VxFS(JFS) file systems with a regular file, VxFS reports an error such as "vxfs: mesg 008:..." and the clean file can be marked bad. Resolution: VNODE type check codes have been added in getdents() to verify the argument passed is a directory or a regular file. Based on HP-UX patch PHKL_22097: ( SR: 8606141023 CR: JAGad10384 ) The casting of a variable is not correct for MVFS with a 64-bit executable. Resolution: A mandatory casting is added before assignment to stat from vnode attributes. Based on HP-UX patch PHKL_22022: ( SR: 8606143417 CR: JAGad12747 ) In HFS when there is a hole in a file, ufs_bread() returns a buffer filled with 0's and the b_flags field is incorrectly set to B_INVAL. The caller checks this flag before using the buffer and considers the buffer to be invalid. Resolution: To resolve this we reset the B_INVAL flag for this buffer so that the caller will use this buffer with 0's instead of thinking it is invalid. Based on HP-UX patch PHKL_21885: ( SR: 8606140236 CR: JAGad09558 ) getdirentries() and getdents() system calls did not check if the argument is a directory file. When either were called on a VxFS(JFS) file systems with a regular file, VxFS reports an error such as "vxfs: mesg 008:..." and the clean file can be marked bad. Resolution: VNODE type check codes have been added in getdirentries() and getdents(). Based on HP-UX patch PHKL_21349: ( SR: 8606132612 CR: JAGad01761 ) 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 filesystem system calls. Based on HP-UX patch PHKL_19991: SR: 5003448100 CR: JAGaa72900 Support for the 'acl()' system call (for JFS ACLs) was not complete in the VFS layer of the filesystem. Add the support so that JFS ACLs can be fully enabled in a new JFS product. Based on HP-UX patch PHKL_19311: When doing writes in vno_rw(), changes were introduced to provide at least some limited support for coherency. When vno_rw() is called during writes, if the vnode is mmap'ed, the page cache is flushed, the I/O is completed, and the page cache is purged. The purge is necessary since somebody could bring in a stale copy from disk while I/O is not yet complete. But the VOP_RDWR is advancing the uio_offset that is used in the purge operation. This results in incorrect purge, and thus a loss of coherency. Resolution: Save the uio_offset before performing the VOP_RDWR and use it during the purge. Based on HP-UX patch PHKL_18797: SR: 1653138164 DTS: DSDe425274 Negative time values for file modtimes are not defined in standards. Release 10.0 opted to make such values invalid. Unfortunately, some vendors were using negative times as flags rather than timestamps, and disallowing such values broke the application. Resolution: Allow negative timestamps again. Based on HP-UX patch PHKL_17543: The panic is caused by passing a NULL pointer to lbcopy(). The stack trace looks like: Stack trace from the first crash event: stack trace for event 0 crash event was a panic FMP SSP panic+0x14 n/a report_trap_or_int_and_panic+0x4c trap+0xe8c $RDB_trap_patch+0x20 lbcopy_gr_method+0x36c uiomove+0x220 ufs_readdir+0x17c generic_readdir2+0xc8 ufs_readdir2+0x14 rfs_readdir+0x184 rfsexp_dispatch+0x5b4 svc_getreq+0x1f8 svc_run+0x664 nfsexp_svc+0x3f8 nfs_stub_svc+0x1c4 coerce_scall_args+0x9c syscall+0x1c8 $syscallrtn+0x0 Actually, there was a change done in 'generic_readdir2' in 11.00 to make a variable 'count' a multiple of 8 to avoid trap 18. But, a mismatch between count and uio_resid was created when the above change was made. That mismatch resulted in this defect. There is no easy way of re-producing this defect. Based on HP-UX patch PHKL_16983: The return value for the system call (the file descriptor) is kept in u.u_r.r_val1. This variable sometimes gets changed if the file is on NFS. Now the value is saved and restored in u.u_r.r_val1 before returning from copen(). Based on HP-UX patch PHKL_27510: ( SR:8606241982 CR:JAGae09237 ) The device numbers that are generated for autofs, nfs and cache file systems always have the sign bit on. Resolution: The device numbers that are generated for autofs, nfs and cache file systems never have the sign bit on. Based on HP-UX patch PHKL_27351: ( SR:8606204668 CR:JAGad73849 ) creat(2) races with unlink(2) allowing an ENOENT failure. Resolution: The function that creates a file, vn_create(), was modified to return a referenced vnode to the open function, vn_open(), thereby eliminating the original race with unlink(2). Based on HP-UX patch PHKL_27089: ( SR:8606242231 CR:JAGae09484 ) A race condition in vfork(2) causes a wakeup to be missed. As the parent is left in an incoherent state, a subsequent priority setting operation encounters a stale pointer, causing the Data Page Fault. Resolution: Fixed operation sequence to close the race, so that the wakeup is not missed. ( SR:8606250250 CR:JAGae16625 ) A kernel interface used to initialize register values takes either a direct or indirect pointer address parameter. For 64-bit programs, the address is always interpreted as an indirect pointer address, which is incorrect for the 64-bit Java Virtual Machine (JVM). This defect only occurs on 64-bit systems. Resolution: Extended the interface so that the 64-bit JVM can specify whether the pointer address parameter is to be interpreted as direct or indirect. ( SR:8606226008 CR:JAGad95080 ) A clock interrupt occuring as soon as the idle loop enables interrupts may attempt to dereference a null thread pointer if the cpu state is stale, causing the panic. Resolution: Set the processor state information earlier in the idle loop, before interrupts are enabled. ( SR:8606255992 CR:JAGae20309 ) A problem in managing lists of signalable threads causes a double unlink of a thread from the list. This corrupts the list, and sometimes can later lead to the panic. Resolution: Reset the list fields so that a second unlink is prevented. ( SR:8606259456 CR:JAGae23774 ) A thread receiving an event wakeup and a signal simultaneously will handle the signal. The event will not be handled even though there may be other threads waiting for that event. They will wait forever, unless another duplicate event occurs. Resolution: A signaled thread will now determine if it also received an event wakeup. If so, it will wake up the next waiting thread to handle the event. ( SR:8606245322 CR:JAGae11795 ) Threads which were waiting for a synchronization object may not run immediately after getting it due to the presence of other higher-priority threads. This execution latency causes "idle time" on the mutex, during which other threads may queue up for that mutex. Resolution: Temporarily boost the thread priority so that the execution latency is reduced. Queueing of other threads for the synchronization object is reduced. ( SR:8606259600 CR:JAGae23918 ) A minor assembly-coding error causes the 32-bit kernel to always execute the long path needed only for locks under contention. The mutex is handled correctly. The 32-bit kernel just does not take advantage of the short path in the non-contended mutex case. Resolution: Fixed incorrect 32-bit branching. Based on HP-UX patch PHKL_26059: ( SR:8606227016 CR:JAGad96078 ) tv_nsec values in the range 990,000,001 to 999,999,999 cause an overflow into the tv_sec field when internally rounded up to whole scheduler ticks (10,000,000 nsec). This causes code in sigtimedwait() to produce an unexpected negative value for tv_sec on a subsequent subtraction and return EINVAL. Resolution: Change conditional code to handle internal tv_sec if less than zero. Based on HP-UX patch PHKL_25999: ( SR:8606230577 CR:JAGad99627 ) Debug threads were incorrectly left on the signalable threads list for a process. This defect was found at HP during product testing of the shared mutex performance improvement. To our knowledge, no customer system has experienced this defect. Resolution: Ensure the debug thread is not on the signalable threads list at the time of its creation. ( SR:8606186056 CR:JAGad55261 ) In the PTHREAD_PROCESS_SHARED mutex case, the unlock operation always makes a system call to synchronize with threads in other processes which may be waiting for the mutex. This makes the code path significantly longer. Resolution: To increase shared mutex performance in the non-contended (i.e., no waiters) case, this change adds a new light weight system call to be used in place of the regular system call in the unlock operation. This is entirely transparent to the applications. It greatly reduces the transition time between kernel and user space. If waiters are detected, the light weight call will transfer into the regular system call path for proper handling. Thus, this performance enhancement is effective only for shared mutexes which do not experience heavy contention. (Patch PHKL_25998, also required for this enhancement, adapts the existing system call which handles waiters of shared mutexes to coordinate with the light weight call. Patch PHCO_26000, also required for this enhancement, adapts the libpthread library to use the new light weight system call.) ( SR:8606230581 CR:JAGad99631 ) A signal used by the pthreads library to terminate system calls can be lost if it is received within a small window of instructions in the libpthread or libc libraries. If the thread happens to be handling a trap (e.g., page fault) within that window, the signal is lost. Thus, it is not consumed in the subsequent system call for which it was intended. This can result in the thread failing to be properly cancelled. Resolution: Detect that the thread is handling a trap, and if so, leave the signal pending rather than consume it. It will then be available to be consumed in, and thus terminate, the subsequent system call. ( SR:8606221319 CR:JAGad90453 ) PRM is being used to create and manage PRM groups for which we want to set a given CPU entitlement with CPU capping enabled. If all CPUs are enabled, the PRM CPU entitlements are being enforced (capped) for each of the PRM groups. When iCOD is used to disable CPUs, PRM reports the correct number of CPUs (available), but the PRM CPU entitlements are not being enforced (capped) correctly and PRM groups are allowed to exceed their CPU entitlement. The problem is that the iCOD dynamic change in the number of active CPUs on the system is not being reported to the PRM scheduler. Resolution: In the clock tick handler, check whether the CPU is enabled. If not enabled, do not update PRM group data. ( SR:8606228779 CR:JAGad97833 ) Currently, only 60 characters of the process command line is stored in the kernel. Some environments require more characters be stored. Resolution: This change handles deallocation of the dynamically allocated kernel memory used to store up to 1020 characters of the command line. (Patch PHKL_26008, also needed for this enhancement, performs allocations and value assignments of the command line data.) PHKL_25035: Ported HP-UX patch PHKL_23226 to VVOS Based on HP-UX patch PHKL_23226: ( SR: 8606175710 CR: JAGad44950 ) The lightweight version of the umask(2) system call was incorrectly manipulating 12 of the file permission bits instead of the correct number of 9. Resolution: Modify the lightweight version of the umask(2) system call to manipulate only 9 file permission bits instead of 12. Based on HP-UX patch PHKL_22796: (SR:8606170084 CR:JAGad39348) Add a check just after entering the system call to check if we are allowed to come into the specified address space. Resolution: Add an additional check. Based on HP-UX patch PHKL_20245: ( SR: 8606102049 CR: JAGab67439 ) Desc: msem_lock() call occasionally fails w/EINVAL In one customer instance, the protections in the TLB entry lose 'write' access and so a msem_lock() call to _mcas() will occasionally fail. This results in errno 14 EINVAL rather than a re-try. However, an immediate second call to msem_lock() does not fail. Resolution: Two lines of code, added to the lw_mcas_pageok() function, pre-read the page. A pre-read page fault will trap and cause a re-try instead of returning a fault. Based on HP-UX patch PHKL_20236: ( SR: 4701409169 DTS: JAGaa12229 ) __lw_get_thread_times sometimes resets the W-bit when returning to user-space. This causes incorrect calculation of system time. This does not happen frequently, but if __lw_get_thread_times() is called repeatedly, sometimes it will return an incorrect system time. Resolution: The __lw_get_thread_times() routine was corrected to not reset the wide-mode bit in the PSW when returning to the user. PHKL_25056: Ported HP-UX patch PHKL_25475 to VVOS Based on HP-UX patch PHKL_25475: ( SR:8606221043 CR:JAGad90179 ) The kernel build fails with PHKL_23002 and superseding patches because the header file /usr/conf/space.h.d/core-hpux.h delivered in the patches attempts to include spinlock.h from the location where it is installed for the optional product ProgSupport.C-INC fileset. Thus, in a minimal operating environment that does not have this fileset installed, /usr/include/sys/spinlock.h may not exist on the system and the above error occurs. Resolution: /usr/conf/space.h.d/core-hpux.h now includes spinlock.h from the location where it is installed for the required kernel fileset (/usr/conf/h/spinlock.h). ( SR:8606220050 CR:JAGad89191 ) There are several outstanding issues with the priority inversion implementation as introduced in PHKL_23955. With priority inversion turned off, these symptoms are not observed. Resolution: This patch disables priority inversion. A future patch will re-enable it as a tunable once the outstanding implementation issues have been addressed. ( SR:8606199334 CR:JAGad68521 ) To prevent a thread from going to sleep, PHKL_22940 set the kt_wchan to NULL. This caused the thread to wake up, but keft it on the sleep queue. Later execution of this thread could corrupt all sleep queues on the system. Resolution: Rather than setting kt_wchan to NULL, call unsleep, which will set kt_wchan to NULL and remove the thread from the sleep queue. PHKL_25040: Ported HP-UX patch PHKL_24943 to VVOS Based on HP-UX patch PHKL_24943: ( SR:8606182941 CR:JAGad5215 ) W-bit of IPSW (interrupt processor status word) and lower bits of GR31 (general register 31) are incorrectly set in _lwp_setstate and _lwp_getstate. Resolution: In _lwp_getstate, save the IPSW from the target thread so that the IPSW can be restored in _lwp_setstate. In _lwp_setstate, put the IPSW bits in the target space id if the user specifies LWP_SET_CONTROL. Otherwise clean up the IPSW inherited from the thread. Based on HP-UX patch PHKL_24734: ( SR:8606196287 CR:JAGad65490 ) When calling select(2) with zero file descriptors, select(2) behaves as a sleep routine, returning back to the user after the specified timeout. Currently, when a timeout of zero is specified, select(2) sleeps for one clock tick before realizing the timout has been exceeded. Resolution: Select(2) now detects when the user application requests a zero timeout value and acts appropriately. Based on HP-UX patch PHKL_24753: ( SR: 8606223152 CR: JAGad92255 ) When the thread lock is acquired for a sleeping thread, and the sleep lock has not yet been obtained, the thread lock must be released before obtaining the sleep lock, and then reacquired. While the thread lock is released, a race condition exists where the thread could change state. The thread hang occurs due to a missed unsleep() (or permanently missed wakeup). Resolution: Acquire the sleep lock prior to acquiring the thread lock and calling unsleep(). Based on HP-UX patch PHKL_24752: ( SR:8606196546 CR:JAGad65749 ) The kernel routine managing a thread that is releasing a spinlock does not check to see if other threads are waiting for it. These threads could minimize their wait time if woken up earlier. Currently they may wait from 10 to 20ms before one is assigned the spinlock. For the case where many threads are serialized on the spinlock, the cumulative delay per thread may yield a noticeable performance degradation. Resolution: In the above kernel routine, after the spinlock becomes available, it now checks for and wakes up the threads waiting for the spinlock. Based on HP-UX patch PHKL_23955: ( SR:8606185652 CR:JAGad54854 ) This issue affects applications with many threads where there is contention on a mutex or a set of mutexes. A non-realtime thread in user space is vulnerable to preemption by the kernel if a higher priority thread becomes runnable in the kernel. This is very likely since threads sleeping on resources in the kernel wake up at higher priority. This causes a user thread holding a mutex to be blocked waiting to run while other threads are either spinning or blocked on the same mutex. The overall throughput of a multi-threaded application with synchronization is reduced noticeably. Resolution: When a timeshare thread returns from ksleep() having acquired the resource (e.g. mutex), the operating system gives the thread a temporary priority boost. The new priority is high enough that its probability of getting preempted by kernel space threads becoming runnable is reduced. The thread will now have enough time and priority to complete its job in user space such that it can release the mutex. Since the timeshare scheduler recomputes the thread priority at regular intervals, the original priority for the thread will be restored in the near future. Based on HP-UX patch PHKL_23002: ( SR:8606164923 CR:JAGad34221 ) The tunable chanq_hash_locks was never implemented properly. Changing the tunable changed the size of the spinlock pool for channel queues, but not the size of the two hashtables that were assosciated with the spinlock pool. The hashtables actual upper bound was left at 256, but functions CHANQ_KERNEL_HASH_MACRO() and CHANQ_USER_HASH_MACRO() would be using the size of the spinlock pool as the upper bound to the hash table size. If the tunable had been set to larger than 256, this would eventually lead to creating a hashtable entry outside of the memory allocated to the hashtables when user programs attempted to create threads. Resolution: The tunable chanq_hash_locks was implemented so that it was used to set the size of the chanq_h_sl_pool and also the two associated hashtables. Additionally, a lower bound of 64 and an upper bound of 4096 were set for this tunable. Based on HP-UX patch PHKL_22940: ( SR: 8606167399 CR: JAGad36685 ) A timing window existed in the sleep routines such that if the timeout interrupt occurred before the thread had gone to sleep, the thread would miss the timeout and sleep forever, or until it was sent a signal. Resolution: Modified the timeout interrupt routine to correctly handle the case where the thread is not yet asleep when the timeout interrupt occurs. PHKL_22562: Ported HP-UX patch PHKL_20202 to VVOS Based on HP-UX patch PHKL_20202: ( SR: 8606128857 CR: JAGab14278 ) Calling the kwakup_one() function from ICS panics the system. The immediate problem is that chanq_setkey() dereferences the uarea to get at the vas via the proc structure. Resolution: By rearranging the code so the vas pointer is not initialized until after the KERNEL_ADDRESS-specific code is executed, we'll avoid dereferencing the uarea on the ICS. PHKL_18753: Ported HP-UX patch PHKL_14750 to VVOS Based on HP-UX patch PHKL_14750: None Based on HP-UX patch PHKL_14493: Under normal circumstances, if the third argument "struct timespec *abstime" to pthread_cond_timedwait() contains the time it has already passed, it will return error ETIMEDOUT. However, pthread_cond_timedwait(3T) intermittently returns EINVAL instead. This happens in the following scenario: - pthread_cond_timedwait() gets called with a future time. - pthread_cond_timedwait() calls ksleep() - ksleep() calls ksleep_one() - ksleep() calls chang_timeout() If by the time we call chang_timeout(), the time value is already in the past, chang_timeout() returns EINVAL. This return value is propagated and eventually returned by pthread_cond_timedwait(). The fix was to make sure that this scenario now returns ETIMEDOUT instead. Based on HP-UX patch PHKL_24733: ( SR: 8606198999 CR: JAGad68186 ) In order to find a thread that can handle a signal directed at the process, all non-running threads are examined to see if they will handle that signal. However, if the signal is blocked by all the threads of a process, the signal cannot be delivered to a thread and must be left pending at the process level. This then causes the system to continually try to deliver the signal whenever the system is switching from kernel mode to user mode. With a large number of threads, these searches can consume all the CPU resources. Resolution: The number of times the entire list of threads is searched is reduced greatly by keeping track that a previous search has found that all the non-running threads have that signal masked and then not searching that list of threads if the search has already been done. Based on HP-UX patch PHKL_23842: ( SR: 8606185342 CR: JAGad54537 ) The application and database level heartbeat technology requires reasonable responsiveness in the 50 to 100 ms range to assure application availability. Long running paths in the kernel can lead to threads running for a long time in an uninterruptible state. This patch enables the preemption mechanism by turning on a variable which is checked at every possible preemption point. If this variable is enabled, and if we have spent too much time in the kernel, then we will preempt the currently running kernel thread in favor of the higher priority thread. If the variable is not turned on (because this patch, or a successor, is not installed), preemption will not occur regardless of time spent in the kernel. Resolution: This patch, along with 5 other patches, helps alleviate this problem by improving the dispatch latency for higher priority runnable threads. This is done by improving the preemption functionality along the long running kernel code paths. This set of patches will not necessarily benefit all application mixes since some application mixes may not execute the modified code paths. The other 5 patches which work in conjunction with this patch are PHKL_23617, PHKL_20943, PHKL_20944, PHKL_20945, and PHKL_21024. Installation of each patch alone will have no effect on the system. A minimal set of patches to achieve this thread scheduling fix must include PHKL_23617, PHKL_23842 and PHKL_20944. However, all patches should be installed to achieve the full effect. Based on HP-UX patch PHKL_23407: (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, the P_NOSTOP feature will be unavailable. In order to prevent the process executed over NFS from becoming unkillable, NFS must use the P_NOSTOP feature. An NFS patch using P_NOSTOP, PHNE_23249, will be released in Spring of 2001. Resolution: If a thread acquires a lock and then sleeps interruptably, it is not permitted to be stopped if P_NOSTOP is set. This prevents this thread from becoming unkillable and prevents the deadlock. Based on HP-UX patch PHKL_23001: ( SR: 8606161075 CR: JAGad30393 ) The possibility of the wrong signal action being executed results from a race condition that occurs between issig() and psig(). This race condition is caused by checking the signal's action in issig(), using that value to determine if the signal needs to be processed by psig(), and then releasing the thread and scheduler locks before issig() returns. Upon returning from issig(), psig() is called and checks the signal's action again, while holding no locks. This leaves a window of time that allows for the signal's action to be changed between when issig() determines the signal should be handled by psig() and when psig() checks what action should be performed. This results in two possible error cases: that the action will be SIG_DFL, but psig() won't know how to perform the default action for that signal, or that a user specified action will be used when the action should have been reset to SIG_DFL. Resolution: When the system V signal(2) interface or the standard interface with the SA_RESETHAND flag set are used, the signal action was checked a second time in psig() after the scheduler lock is obtained. After this check is made, if the action is SIG_DFL, then we know the race condition has occured and psig() will then perform the default action for that signal. psig() was also modified so that it would be able to handle SIGIO in addition to the six signals that have a default action of ignore. PHKL_22988: Ported HP-UX patch PHKL_22568 to VVOS Based on HP-UX patch PHKL_22568: ( SR: 8606163813 CR: JAGad33117 ) If a private third quadrant process creates another thread, the kernel does not initialize sr6 (the space register that controls the third quadrant address space) to the proper value for that thread. Any access by that thread to an address in the third quadrant will lead to a segmentation violation. Resolution: The kernel procedure which initializes registers for new threads has been modified to set sr6 properly (i.e. the same value that is in sr5, which is the users private address space). Based on HP-UX patch PHKL_22145: ( SR: 8606141357 CR: JAGad10781 ) The process does not respond to the signals SIGKILL, SIGSTOP, and SIGCONT as these will be directed to the first thread of the process without checking to see if that thread is a zombie thread. This selection is made in the find_first_eligible_thread function. If it's a zombie it does nothing to handle the signal. Note that this does not affect other signals as the threads they are passed to are selected in a different manner. Resolution: Change find_first_eligible_thread so that it passes the signals noted above to the first non-zombie thread rather than automatically choosing the first thread. Based on HP-UX patch PHKL_21830: ( SR: 8606127468 CR: JAGac77753 ) Procedure thread_create() does not check if the processor is currently deallocated. Resolution: Change thread_create() to fail and set errno to EINVAL if a thread is set to bound to a deallocated processor. Based on HP-UX patch PHKL_21348: ( SR: 8606124297 CR: JAGac39680 ) Parent issues a signal(SIGCHLD,SIG_IGN) to prevent exiting children from creating zombie processes. Before 11.00, when the child exits, the parent is woken up by the signal. If SIGCHLD/SIG_IGN is set, it reaps the zombies, discards the child, ignores the signal and goes back to sleep. In 11.00, thread house cleaning is added in the sigsuspend() and sigpause() paths such that the parent is not put back to sleep after waking up, resulting in the premature interruption of the parent. Resolution: In 11.00, since the reaping of zombies is done by the child during exit, there is no need for the parent to be woken up when a child exits. Therefore SIGCHLD/SIG_IGN can be handled as SIGCHLD/SIG_DFL by not posting the signal when a child exits. Similar fix applies to SIGCONT/SIG_IGN. ( SR: 8606132611 CR: JAGad01760 ) 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 provides the interface required by IDS/9000 for thread and process creation and teardown. Based on HP-UX patch PHKL_20942: ( SR: 8606112164 DTS: JAGab84450 ) This is an enhancement for a corner case in RTSCHED scheduling. Resolution: Code added to fine tune RTSCHED thread scheduling code path. Based on HP-UX patch PHKL_20625: ( SR: 8606110344 CR: JAGab83048 ) Before calling ksw_remove_from_proc(), only MP locking of the sched lock takes place and no UP locking is done. During the execution of ksw_remove_from_proc(), if the system services an I/O or timer interrupt on the interrupt control stack without the lock protection, the ksigwait structure is removed before the completion of ksw_remove_from_proc(). Data page fault happens when this structure is accessed. Resolution: Use spinlock() instead of MP_SPINLOCK() to protect the sched lock for both UP and MP. Based on HP-UX patch PHKL_19930: ( SR: 8606103530 DTS: JAGab70391 ) Signal delivery searched a single per-process linked list for a candidate thread to deliver the signal to. If the process is using AIO, it may have many threads that are not candidates. These extra threads can significantly slow the search. Resolution: Create a second per-process list populated only by threads that can possibly handle signals. Based on HP-UX patch PHKL_19531: ( SR: 1653296996 DTS: JAGaa94126 ) Specifying "sleep 99999999" will terminate immediately. Any request in excess of 2^31-1 seconds will fail and return immediately. Resolution: The sigtimedwait algorthim has been corrected to accomodate delays of 2^32-1 for 32-bit systems, and 2^64-1 64-bit systems by itteratively handling the requested time using one or more pre-defined delays plus a residual. Based on HP-UX patch PHKL_24502: ( SR: 8606170321 CR: JAGad39585 ) When running the fair share scheduler on a lightly loaded system with 24 or more processors, too much time was spent in the fair share scheduler's idle loop searching other processors' run queues for fair share scheduled threads to steal. Resolution: This patch streamlines the fair share scheduler's idle loop, reducing the amount of time we spend searching other processors' run queues for fair share scheduled threads to steal. This allows better overall system performance and response time. Based on HP-UX patch PHKL_23617: ( SR: 8606186407 CR: JAGad55611 ) When a user space mandatory binding request is found to be in conflict with the actual spu it is running on, a syslog message on the application'system daemons issues a warning that the mpc_bindlwp() routine overrides the conflict mandatory binding request. The extraneous message fills up the log file making syslog unusable for the third party product. Resolution: Add conditional flag enable_mpc_bindlwp_printf to mpc_bindlwp() to skip printing "Overriding conflicting mandatory binding!" message for a user space mandatory binding request that is running on a processor different from the requested processor and is also not gang scheduled. ( SR: 8606185342 CR: JAGad54537 ) The application and database level heartbeat technology requires reasonable responsiveness in the 50 to 100 ms range to assure application availability. Long running paths in the kernel can lead to threads running for a long time in an uninterruptible state. Resolution: This patch, along with 5 other patches, helps alleviate this problem by improving the dispatch latency for higher priority runnable threads. This is done by improving the preemption functionality along the long running kernel code paths. This set of patches will not necessarily benefit all application mixes since some applications mixes may not execute the modified code paths. The other 5 patches which work in conjunction with this patch are PHKL_23842, PHKL_20943, PHKL_20944, PHKL_20945, and PHKL_21024. Installation of each patch alone will have no effect on the system. A minimal set of patches to achieve this thread scheduling fix must include PHKL_23617, PHKL_23842 and PHKL_20944. However, all patches should be installed to achieve the full effect. Based on HP-UX patch PHKL_23408: (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 a fork, setrlimit, core, SIGSTOP, or debugger operations, 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, and PHKL_23409) that enable P_NOSTOP, a new feature that prevents a process from becoming unkillable. Each patch is independently 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 the thread from becoming unkillable and prevents the deadlock. Based on HP-UX patch PHKL_23180: ( SR:8606173973 CR:JAGad43226 ) The negative SPU value represented by arg1 is not valid, but there aren't any checks for this before that value is used. The usage of the invalid SPU results in the Data Page Fault. Resolution: A check was added to cause mpctl() to return with an error if it is called with MPC_GETNEXTSPU and a negative value for arg1. PHKL_23020: Ported HP-UX patch PHKL_21832 to VVOS Based on HP-UX patch PHKL_21832: (SR: 8606127468 CR: JAGac77753) Threads can be seen running on deallocated processors. Performance does not scale well when processors deallocated. mpctl() returns deallocated processors in MPC_GETFIRSTSPU and MPC_GETNEXTSPU and count deallocated processors in MPC_GETNUMSPUS. Resolution: Code was changed to check for spu_status before placing a thread on its run queue and also to migrate threads to the monarch when a processor is deallocated. Code was changed in idle loop so that it does not hold sched_lock at every iteration. Code was changed in mpctl() so that it is aware of deallocated processors. Based on HP-UX patch PHKL_21111: (SR: 8606106739 CR: JAGab76092) When FSS capping feature is enabled and when a minority group is the only job running on the system on a mostly idle system, the minority group doesn't achieve its entitlement. Resolution: Modify existing FSS algorithm to allow admin defined groups to steal a 'horse' from SYSTEM group when a group doesn't achieve its entitlement. Advance the carousel in idle loop when there is no SYSTEM processes, which allows non-SYSTEM groups to run. (SR: 8606104136 CR: JAGab71488) Patch PHKL_20883 can cause floating-point underflow exception which can panic the system. Resolution: This is corrected by setting 'D-bit' in floating-point status register. Based on HP-UX patch PHKL_20883: (SR: 8606104136 CR: JAGab71488) When a CPU is being monopolized by a realtime thread, the high level load balancer (mp_spu_balance) failed to migrate threads from this CPU to other less busy ones. Resolution: To alleviate the thread starvation caused by a realtime thread, the balancer has been changed to run on the Interrupt Control Stack. This enables the balancer code to run on a regular preset interval despite the system load. In addition, the load balancing algorithm has been enhanced to proactively detect and prevent starvation through its balancing score. Based on HP-UX patch PHKL_20941: ( SR: 8606112164 DTS: JAGab84450 ) This patch optimizes RTSCHED thread scheduling along some kernel code paths. The scheduler now optimizes which processor to place the RTSCHED thread on. 1) only RTSCHED threads are affected. Threads scheduled via the rtprio() command will not see any changes from this patch. 2) SCHED_TIMSHARE threads may see some delay in response time as RTSCHED threads will receive more system resources. 3) This patch will not necessarily benefit all application mixes which utilize RTSCHED capabilities since all applications mixes may not execute the modified code paths. Resolution: The scheduler will allow the rtsched thread to continue execution on the current SPU if context switching is deemed too expensive. Otherwise, it would choose the SPU most appropriate, usually the one with the lightest load. Based on HP-UX patch PHKL_20659: (SR: 8606114252 CR: JAGac23971) Kernel routine that inserts thread into the priority sleep queue neglects to update the pointer to the tail of the sleep queue triggering the effect of a ghosted thread. This lead to system panics when trying to wake up the sleeping threads. The panic is caused by pm_setrun() not being able to find the sleeping thread on slpque_1. The inquired thread is still asleep with a valid kt_wchan and kt_stat state. Resolution: As inserted thread is appended to the end of the sleep queue, the tail pointer of the queue is also updated. Based on HP-UX patch PHKL_20399: (SR: 8606105735 CR: JAGab73995) When an MP system is rebooted and executed in the idle() path, comparison check between nready_free and nready_free_alpha was inadequate thus preventing the reboot processor from handling threads locked to other specific processor. Resolution: We now account properly for threads locked to other specific processor in addition to active, not locked threads. The reboot processor can now find and process active runnable threads on other processor's run queue. Based on HP-UX patch PHKL_19873: Due to a misbehavior in 11.00 FSS, a resource 'share' is incorrectly allocated on MP systems when the number of processes in the group is less than the number of CPUs in the system. The shares are allocated on a per CPU not per system thus a group configured for 50% with just a single process will get only 12.5% on a 4-way system. Note that if the system has been tuned to compensate for the problem fixed by this patch, it might be necessary for the system to be re-tuned since system performance may change. Resolution: The fss_balance() algorithm which continually checks how often the processes in each process group want to run now ensures that even the minority group gets its fair share of system resources even for 'minority' group processes. PHKL_23124: Ported HP-UX patch PHKL_22589 to VVOS Based on HP-UX patch PHKL_22589: ( SR: 8606163603 CR: JAGad32907 ) The performance update made to select() by PHKL_18543 did not correctly handle the case of select() being interrupted after being called with no file descriptors and a timeout. Resolution: The routine select_as_nanosleep() was updated to cause select to return -1 with the error of type EINTR when the above case occurred. This conforms to the X/Open standard. Based on HP-UX patch PHKL_22517: ( SR: 8606163287 CR:JAGad32591 ) This is due to a race between two threads, one accessing the details of a mounted file system and another unmounting the same file system. getmount_entry() is holding an alpha semaphore while retrieving the details of the mounted file system. This semaphore may be released, if the filesystem specific getmount_entry routine sleeps. Due to this another thread doing an unmount of the file system would be able to get the semaphore and thus could unmount the file system and free the related data structures. Later the getmount_entry() thread accesses the freed data structures and panics. Resolution: Instead of relying only on the semaphore, get a hold on the file system so that unmount will fail when getmount_entry() is in progress. Based on HP-UX patch PHKL_22142: ( SR: 8606126449 CR:JAGac57014 ) In order to improve the network performance, one more piece of information is needed to pass from select(2) to its lower functions in order to tell the lower functions if the select(2) system call is going to sleep. Resolution: One more argument has been added to its lower function for passing sleeping information, which enables performance improvements in future Transport and STREAMS patches. This patch alone will have no performance improvement if there are no such Transport and STREAMS patches installed. Based on HP-UX patch PHKL_21608: ( SR: 8606133836 CR:JAGad02977 ) This PANIC with 'lo_realvfs' message is because of a race condition. A race condition is created when one thread tries to create an an lfs node and another thread tries to release the same 'lfs' node. Thread 1 tries to free an 'lfs' node while holding a lock. Thread 2 tries to make an 'lfs' node. But, due to the time gap in holding and releasing the lock, a race condition is created between Thread 1 and Thread 2. This can lead to the PANIC with 'lo_realvfs' PANIC. Resolution: The fix is to increase and decrease the lfs_refct without giving up the lock. Also the lfs_refct value checking has been changed to refect the new change. Based on HP-UX patch PHKL_21361: ( SR: 8606132624 CR: JAGad01773 ) 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 filesystem system calls. Based on HP-UX patch PHKL_20315: ( SR: 8606109444 DTS: JAGab82146 ) The problem is a race condition caused by not properly protecting an entry in a lofs data structure. The lock that is supposed to protect this structure was not held when an update was made, and thus simultaneous changes resulted in an inconsistency in the data structure, causing the panic. Resolution: The lock is now held when this entry is updated; this is actually just obtaining the lock one line earlier in the code. ( SR: 4701423798 DTS: JAGab13874 ) The problem is that the system will loop in the routine trying to find the root of the file system. Resolution: The mount of a directory to itself is really an error. The resolution is to change the code so the mount will fail with EINVAL, thus avoiding the case where the hang will occur. ( SR: 1653263962 CR: JAGaa12500 ) The problem is that LOFS does not implement the VFS_VGET operation, and thus does not properly call the underlying file system functions. This functionality is needed for AUTOFS to support overlaying of file systems. Resolution: The solution is to implement the VFS_VGET routine in LOFS, so a new function lo_vget() has been added. This resolves both symptoms of the problem. ( SR: 4701393884 CR: JAGaa08709 ) The problem is that LOFS does not properly add a reference to the vnode of mount point. This allows 'rmdir' to remove the directory because there appear to be no references to it any more. Resolution: Add a new LOFS vnode which will add a reference to the mount point vnode preventing the removal of the directory. Based on HP-UX patch PHKL_15689: vfs.o: 1. smount2() fails when vnode is of type AutoFS. autosysgen.o: 1. Data alignment is incorrect between the 32-bit automount command and the 64-bit AutoFS system calls. Based on HP-UX patch PHKL_20349: ( SR: 8606110852 CR: JAGab83602 ) Enhancement to add new pread(2), pwrite(2), pread64(2) and pwrite64(2) system calls. These calls perform the same action as read(2) and write(2) except that they read/write from a given position in the file (specified in the fourth argument) without changing the file pointer. Resolution: Added new system calls. PHKL_18547: Ported HP-UX patch PHKL_14119 to VVOS Based on HP-UX patch PHKL_14119: ( SR: 4701375543 DTS: DSDe440886 ) In order to set the critical tag on this file, a new patch was required. This patch makes no other change, and is technically equivalent to PHKL_13290. Based on HP-UX patch PHKL_13290: ( SR: 4701375543 DTS: DSDe440886 ) Extract unsigned instruction used where signed extract should have been used. Enhancement: Yes PHKL_29192: This 11.04 (VVOS) update makes use of a new LVM interfaces. PHKL_23054: This enhancement improves performance for multithreaded applications which make heavy use of synchronization objects such as mutexes, reader-writer locks, and POSIX semaphores, including some Java applications. PHKL_22988: Performance changes for corner case in RTSCHED scheduling. This patch has no impact on most systems. PHKL_23124: Enhancement to provide support for the pread(2) and pwrite(2) system calls. SR: 1653138164 1653253237 1653263962 1653296996 4701375543 4701393884 4701409169 4701413302 4701423798 5003424044 5003425678 5003448100 5003461889 8606100288 8606102049 8606103530 8606103740 8606104136 8606105735 8606106739 8606109444 8606110344 8606110852 8606112164 8606114252 8606124297 8606126449 8606127468 8606128857 8606132611 8606132612 8606132624 8606133836 8606140236 8606141023 8606141357 8606143417 8606159451 8606161075 8606163287 8606163603 8606163813 8606164923 8606166417 8606167399 8606170084 8606170321 8606173973 8606175710 8606182941 8606185342 8606185652 8606186056 8606186407 8606196287 8606196546 8606198999 8606199334 8606204668 8606220050 8606221043 8606221319 8606226008 8606227016 8606228779 8606230577 8606230581 8606233059 8606241982 8606242231 8606242881 8606245322 8606250250 8606255992 8606259456 8606259600 8606263473 8606269677 8606270370 8606223152 Patch Files: OS-Core.CORE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/conf/h/file.h /usr/conf/h/fss.h /usr/conf/h/unistd.h ProgSupport.C-INC,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/include/sys/file.h /usr/include/sys/fss.h /usr/include/sys/ksleep.h /usr/include/sys/unistd.h OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: /usr/conf/lib/libhp-ux.a(autosysgen.o) /usr/conf/lib/libhp-ux.a(fssdefault.o) /usr/conf/lib/libhp-ux.a(gateway.o) /usr/conf/lib/libhp-ux.a(init_sent.o) /usr/conf/lib/libhp-ux.a(ivt_intercept.o) /usr/conf/lib/libhp-ux.a(kern_fork.o) /usr/conf/lib/libhp-ux.a(kern_sig.o) /usr/conf/lib/libhp-ux.a(lo_subr.o) /usr/conf/lib/libhp-ux.a(lo_vfsops.o) /usr/conf/lib/libhp-ux.a(lo_vnops.o) /usr/conf/lib/libhp-ux.a(lw_scall.o) /usr/conf/lib/libhp-ux.a(pm_clockint.o) /usr/conf/lib/libhp-ux.a(pm_policy.o) /usr/conf/lib/libhp-ux.a(pm_proc.o) /usr/conf/lib/libhp-ux.a(pm_signal.o) /usr/conf/lib/libhp-ux.a(pm_swtch.o) /usr/conf/lib/libhp-ux.a(pm_threads.o) /usr/conf/lib/libhp-ux.a(qmml.o) /usr/conf/lib/libhp-ux.a(scall_stubs.o) /usr/conf/lib/libhp-ux.a(subr_ksleep.o) /usr/conf/lib/libhp-ux.a(subr_threads.o) /usr/conf/lib/libhp-ux.a(sys_gen.o) /usr/conf/lib/libhp-ux.a(vfs.o) /usr/conf/lib/libhp-ux.a(vfs_io.o) /usr/conf/lib/libhp-ux.a(vfs_scalls.o) /usr/conf/lib/libhp-ux.a(vfs_vnode.o) /usr/conf/lib/libprm.a(kern_fss.o) /usr/conf/lib/libufs.a(ufs_vnops.o) OS-Core.KERN2-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: /usr/conf/space.h.d/core-hpux.h OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: /usr/conf/lib/libhp-ux.a(autosysgen.o) /usr/conf/lib/libhp-ux.a(fssdefault.o) /usr/conf/lib/libhp-ux.a(gateway.o) /usr/conf/lib/libhp-ux.a(init_sent.o) /usr/conf/lib/libhp-ux.a(ivt_intercept.o) /usr/conf/lib/libhp-ux.a(kern_fork.o) /usr/conf/lib/libhp-ux.a(kern_sig.o) /usr/conf/lib/libhp-ux.a(lo_subr.o) /usr/conf/lib/libhp-ux.a(lo_vfsops.o) /usr/conf/lib/libhp-ux.a(lo_vnops.o) /usr/conf/lib/libhp-ux.a(lw_scall.o) /usr/conf/lib/libhp-ux.a(pm_clockint.o) /usr/conf/lib/libhp-ux.a(pm_policy.o) /usr/conf/lib/libhp-ux.a(pm_proc.o) /usr/conf/lib/libhp-ux.a(pm_signal.o) /usr/conf/lib/libhp-ux.a(pm_swtch.o) /usr/conf/lib/libhp-ux.a(pm_threads.o) /usr/conf/lib/libhp-ux.a(qmml.o) /usr/conf/lib/libhp-ux.a(scall_stubs.o) /usr/conf/lib/libhp-ux.a(subr_ksleep.o) /usr/conf/lib/libhp-ux.a(subr_threads.o) /usr/conf/lib/libhp-ux.a(sys_gen.o) /usr/conf/lib/libhp-ux.a(vfs.o) /usr/conf/lib/libhp-ux.a(vfs_io.o) /usr/conf/lib/libhp-ux.a(vfs_scalls.o) /usr/conf/lib/libhp-ux.a(vfs_vnode.o) /usr/conf/lib/libprm.a(kern_fss.o) /usr/conf/lib/libufs.a(ufs_vnops.o) OS-Core.KERN2-RUN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: /usr/conf/space.h.d/core-hpux.h what(1) Output: OS-Core.CORE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/conf/h/file.h: file.h $Date: 2002/08/30 08:56:35 $Revision: r11ros/ 6 PATCH_11.00 (PHKL_27813) */ $Revision: Hewlett-Packard ISSL 1.19 kern/h/file.h, hpuxsysinc, vvos_rose, rose0308 $ $Date: 03/ 05/28 05:23:56 $ */ $Source: kern/h/file.h, hpuxsysinc, vvos_rose, rose0 308 $ $Date: 03/05/28 05:23:56 $ $Revision: 1.19 PATCH_11.04 (PHKL_29192) $ */ /usr/conf/h/fss.h: fss.h $Date: 1999/09/14 09:27:43 $Revision: r11ros/3 PATCH_11.00 (PHKL_19873) */ /usr/conf/h/unistd.h: $Revision: Hewlett-Packard ISSL 1.13 kern/h/unistd.h , hpuxsysinc, vvos_rose, rose0306 $ $Date: 0 1/02/08 09:59:31 $ */ $Source: kern/h/unistd.h, hpuxsysinc, vvos_rose, ros e0306 $ $Date: 01/02/08 09:59:31 $ $Revision : 1.13 PATCH_11.04 (PHKL_23124) $ */ unistd.h $Date: 1999/12/06 12:15:20 $Revision: r11ro s/6 PATCH_11.00 (PHKL_20349) ProgSupport.C-INC,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/include/sys/file.h: file.h $Date: 2002/08/30 08:56:35 $Revision: r11ros/ 6 PATCH_11.00 (PHKL_27813) */ $Revision: Hewlett-Packard ISSL 1.19 kern/h/file.h, hpuxsysinc, vvos_rose, rose0308 $ $Date: 03/ 05/28 05:23:56 $ */ $Source: kern/h/file.h, hpuxsysinc, vvos_rose, rose0 308 $ $Date: 03/05/28 05:23:56 $ $Revision: 1.19 PATCH_11.04 (PHKL_29192) $ */ /usr/include/sys/fss.h: fss.h $Date: 1999/09/14 09:27:43 $Revision: r11ros/3 PATCH_11.00 (PHKL_19873) */ /usr/include/sys/ksleep.h: ksleep.h $Date: 2000/12/19 17:06:00 $Revision: r11ro s/1 PATCH_11.00 (PHKL_23002) $Revision: 1.4.105.5 $ */ /usr/include/sys/unistd.h: $Revision: Hewlett-Packard ISSL 1.13 kern/h/unistd.h , hpuxsysinc, vvos_rose, rose0306 $ $Date: 0 1/02/08 09:59:31 $ */ $Source: kern/h/unistd.h, hpuxsysinc, vvos_rose, ros e0306 $ $Date: 01/02/08 09:59:31 $ $Revision : 1.13 PATCH_11.04 (PHKL_23124) $ */ unistd.h $Date: 1999/12/06 12:15:20 $Revision: r11ro s/6 PATCH_11.00 (PHKL_20349) OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: /usr/conf/lib/libhp-ux.a(autosysgen.o): None /usr/conf/lib/libhp-ux.a(fssdefault.o): fssdefault.c $Date: 2002/11/20 12:59:20 $Revision: r 11ros/2 PATCH_11.00 (PHKL_28152) /usr/conf/lib/libhp-ux.a(gateway.o): gateway.s $Date: 2002/01/01 19:16:18 $Revision: r11r os/3 PATCH_11.00 (PHKL_25999) /usr/conf/lib/libhp-ux.a(init_sent.o): init_sent.c $Date: 2002/01/01 19:18:12 $Revision: r1 1ros/2 PATCH_11.00 (PHKL_25999) /usr/conf/lib/libhp-ux.a(ivt_intercept.o): ivt_intercept.c $Date: 2002/09/19 10:02:20 $Revision : r11ros/2 PATCH_11.00 (PHKL_27770) /usr/conf/lib/libhp-ux.a(kern_fork.o): $Source: kern/sys/kern_fork.c, hpuxsysproc, vvos_ros e, rose0306 $ $Date: 01/11/15 09:10:59 $ $Re vision: 1.20.1.12 PATCH_11.04 (PHKL_25056) $ /usr/conf/lib/libhp-ux.a(kern_sig.o): $Source: kern/sys/kern_sig.c, hpuxsysproc, vvos_rose , rose0308 $ $Date: 03/05/28 05:43:37 $ $Rev ision: 1.12.1.9 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(lo_subr.o): $Source: kern/lofs/lo_subr.c, hpuxsyslofs, vvos_rose , rose0308 $ $Date: 03/05/28 05:33:13 $ $Rev ision: 1.7 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(lo_vfsops.o): $Source: kern/lofs/lo_vfsops.c, hpuxsyslofs, vvos_ro se, rose0306 $ $Date: 01/01/10 08:40:58 $ $R evision: 1.4 PATCH_11.04 (PHKL_23124) $ /usr/conf/lib/libhp-ux.a(lo_vnops.o): lo_vnops.c $Date: 1999/12/02 07:19:10 $Revision: r11 ros/1 PATCH_11.00 (PHKL_20315) /usr/conf/lib/libhp-ux.a(lw_scall.o): lw_scall.s $Date: 2002/05/22 16:04:48 $Revision: r11 ros/16 PATCH_11.00 (PHKL_27089) /usr/conf/lib/libhp-ux.a(pm_clockint.o): pm_clockint.c $Date: 2002/09/19 10:02:20 $Revision: r11ros/10 PATCH_11.00 (PHKL_27770) /usr/conf/lib/libhp-ux.a(pm_policy.o): $Source: kern/sys/pm_policy.c, hpuxsysproc, vvos_ros e, rose0306 $ $Date: 01/11/15 09:11:01 $ $Re vision: 1.12.1.12 PATCH_11.04 (PHKL_25056) $ /usr/conf/lib/libhp-ux.a(pm_proc.o): pm_proc.c $Date: 2002/01/01 19:09:09 $Revision: r11r os/16 PATCH_11.00 (PHKL_25999) /usr/conf/lib/libhp-ux.a(pm_signal.o): pm_signal.c $Date: 2002/05/22 16:05:44 $Revision: r1 1ros/20 PATCH_11.00 (PHKL_27089) /usr/conf/lib/libhp-ux.a(pm_swtch.o): pm_swtch.c $Date: 2002/05/22 16:07:08 $Revision: r11 ros/30 PATCH_11.00 (PHKL_27089) /usr/conf/lib/libhp-ux.a(pm_threads.o): $Source: kern/sys/pm_threads.c, hpuxsysproc, vvos_ro se, rose0308 $ $Date: 03/05/28 05:47:38 $ $R evision: 1.13 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(qmml.o): qmml.s $Date: 2000/11/21 12:30:35 $Revision: r11ros/ 1 PATCH_11.00 (PHKL_22796) /usr/conf/lib/libhp-ux.a(scall_stubs.o): scall_stubs.s $Date: 2002/01/01 19:17:27 $Revision: r11ros/4 PATCH_11.00 (PHKL_25999) /usr/conf/lib/libhp-ux.a(subr_ksleep.o): subr_ksleep.c $Date: 2002/05/22 16:06:30 $Revision: r11ros/12 PATCH_11.00 (PHKL_27089) /usr/conf/lib/libhp-ux.a(subr_threads.o): $Source: kern/sys/subr_threads.c, hpuxsysproc, vvos_ rose, rose0306 $ $Date: 01/11/15 09:11:06 $ $Revision: 1.12 PATCH_11.04 (PHKL_25056) $ /usr/conf/lib/libhp-ux.a(sys_gen.o): $Source: kern/sys/sys_gen.c, hpuxsysio, vvos_rose, r ose0308 $ $Date: 03/05/28 05:51:59 $ $Revisi on: 1.23 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(vfs.o): $Source: kern/sys/vfs.c, hpuxsysvfs, vvos_rose, rose 0308 $ $Date: 03/05/28 05:55:47 $ $Revision: 1.21 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(vfs_io.o): $Source: kern/sys/vfs_io.c, hpuxsysvfs, vvos_rose, r ose0308 $ $Date: 03/05/28 06:00:38 $ $Revisi on: 1.20 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(vfs_scalls.o): $Source: kern/sys/vfs_scalls.c, hpuxsysvfs, vvos_ros e, rose0306 $ $Date: 01/01/29 08:37:58 $ $Re vision: 1.27.3.3 PATCH_11.04 (PHKL_23054) $ /usr/conf/lib/libhp-ux.a(vfs_vnode.o): $Source: kern/sys/vfs_vnode.c, hpuxsysvfs, vvos_rose , rose0308 $ $Date: 03/05/28 06:14:02 $ $Rev ision: 1.25 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libprm.a(kern_fss.o): $Source: kern/sys/kern_fss.c, hpuxsysproc, vvos_rose , rose0308 $ $Date: 03/05/28 05:38:24 $ $Rev ision: 1.17 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libufs.a(ufs_vnops.o): $Source: kern/ufs/ufs_vnops.c, hpuxsysufs, vvos_rose , rose0306 $ $Date: 01/01/25 07:11:54 $ $Rev ision: 1.47 PATCH_11.04 (PHKL_23054) $ OS-Core.KERN2-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: /usr/conf/space.h.d/core-hpux.h: $Revision: Hewlett-Packard ISSL 1.10.3.5 kern/space/ core-hpux.h, hpuxsysmisc, vvos_rose, rose030 6 $ $Date: 01/11/08 10:52:47 $ */ $Source: kern/space/core-hpux.h, hpuxsysmisc, vvos_r ose, rose0306 $ $Date: 01/11/08 10:52:47 $ $ Revision: 1.10.3.5 PATCH_11.04 (PHKL_25056) $ OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: /usr/conf/lib/libhp-ux.a(autosysgen.o): None /usr/conf/lib/libhp-ux.a(fssdefault.o): fssdefault.c $Date: 2002/11/20 12:59:20 $Revision: r 11ros/2 PATCH_11.00 (PHKL_28152) /usr/conf/lib/libhp-ux.a(gateway.o): gateway.s $Date: 2002/01/01 19:16:18 $Revision: r11r os/3 PATCH_11.00 (PHKL_25999) /usr/conf/lib/libhp-ux.a(init_sent.o): init_sent.c $Date: 2002/01/01 19:18:12 $Revision: r1 1ros/2 PATCH_11.00 (PHKL_25999) /usr/conf/lib/libhp-ux.a(ivt_intercept.o): ivt_intercept.c $Date: 2002/09/19 10:02:20 $Revision : r11ros/2 PATCH_11.00 (PHKL_27770) /usr/conf/lib/libhp-ux.a(kern_fork.o): $Source: kern/sys/kern_fork.c, hpuxsysproc, vvos_ros e, rose0306 $ $Date: 01/11/15 09:10:59 $ $Re vision: 1.20.1.12 PATCH_11.04 (PHKL_25056) $ /usr/conf/lib/libhp-ux.a(kern_sig.o): $Source: kern/sys/kern_sig.c, hpuxsysproc, vvos_rose , rose0308 $ $Date: 03/05/28 05:43:37 $ $Rev ision: 1.12.1.9 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(lo_subr.o): $Source: kern/lofs/lo_subr.c, hpuxsyslofs, vvos_rose , rose0308 $ $Date: 03/05/28 05:33:13 $ $Rev ision: 1.7 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(lo_vfsops.o): $Source: kern/lofs/lo_vfsops.c, hpuxsyslofs, vvos_ro se, rose0306 $ $Date: 01/01/10 08:40:58 $ $R evision: 1.4 PATCH_11.04 (PHKL_23124) $ /usr/conf/lib/libhp-ux.a(lo_vnops.o): lo_vnops.c $Date: 1999/12/02 07:19:10 $Revision: r11 ros/1 PATCH_11.00 (PHKL_20315) /usr/conf/lib/libhp-ux.a(lw_scall.o): lw_scall.s $Date: 2002/05/22 16:04:48 $Revision: r11 ros/16 PATCH_11.00 (PHKL_27089) /usr/conf/lib/libhp-ux.a(pm_clockint.o): pm_clockint.c $Date: 2002/09/19 10:02:20 $Revision: r11ros/10 PATCH_11.00 (PHKL_27770) /usr/conf/lib/libhp-ux.a(pm_policy.o): $Source: kern/sys/pm_policy.c, hpuxsysproc, vvos_ros e, rose0306 $ $Date: 01/11/15 09:11:01 $ $Re vision: 1.12.1.12 PATCH_11.04 (PHKL_25056) $ /usr/conf/lib/libhp-ux.a(pm_proc.o): pm_proc.c $Date: 2002/01/01 19:09:09 $Revision: r11r os/16 PATCH_11.00 (PHKL_25999) /usr/conf/lib/libhp-ux.a(pm_signal.o): pm_signal.c $Date: 2002/05/22 16:05:44 $Revision: r1 1ros/20 PATCH_11.00 (PHKL_27089) /usr/conf/lib/libhp-ux.a(pm_swtch.o): pm_swtch.c $Date: 2002/05/22 16:07:08 $Revision: r11 ros/30 PATCH_11.00 (PHKL_27089) /usr/conf/lib/libhp-ux.a(pm_threads.o): $Source: kern/sys/pm_threads.c, hpuxsysproc, vvos_ro se, rose0308 $ $Date: 03/05/28 05:47:38 $ $R evision: 1.13 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(qmml.o): qmml.s $Date: 2000/11/21 12:30:35 $Revision: r11ros/ 1 PATCH_11.00 (PHKL_22796) /usr/conf/lib/libhp-ux.a(scall_stubs.o): scall_stubs.s $Date: 2002/01/01 19:17:27 $Revision: r11ros/4 PATCH_11.00 (PHKL_25999) /usr/conf/lib/libhp-ux.a(subr_ksleep.o): subr_ksleep.c $Date: 2002/05/22 16:06:30 $Revision: r11ros/12 PATCH_11.00 (PHKL_27089) /usr/conf/lib/libhp-ux.a(subr_threads.o): $Source: kern/sys/subr_threads.c, hpuxsysproc, vvos_ rose, rose0306 $ $Date: 01/11/15 09:11:06 $ $Revision: 1.12 PATCH_11.04 (PHKL_25056) $ /usr/conf/lib/libhp-ux.a(sys_gen.o): $Source: kern/sys/sys_gen.c, hpuxsysio, vvos_rose, r ose0308 $ $Date: 03/05/28 05:51:59 $ $Revisi on: 1.23 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(vfs.o): $Source: kern/sys/vfs.c, hpuxsysvfs, vvos_rose, rose 0308 $ $Date: 03/05/28 05:55:47 $ $Revision: 1.21 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(vfs_io.o): $Source: kern/sys/vfs_io.c, hpuxsysvfs, vvos_rose, r ose0308 $ $Date: 03/05/28 06:00:38 $ $Revisi on: 1.20 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libhp-ux.a(vfs_scalls.o): $Source: kern/sys/vfs_scalls.c, hpuxsysvfs, vvos_ros e, rose0306 $ $Date: 01/01/29 08:37:58 $ $Re vision: 1.27.3.3 PATCH_11.04 (PHKL_23054) $ /usr/conf/lib/libhp-ux.a(vfs_vnode.o): $Source: kern/sys/vfs_vnode.c, hpuxsysvfs, vvos_rose , rose0308 $ $Date: 03/05/28 06:14:02 $ $Rev ision: 1.25 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libprm.a(kern_fss.o): $Source: kern/sys/kern_fss.c, hpuxsysproc, vvos_rose , rose0308 $ $Date: 03/05/28 05:38:24 $ $Rev ision: 1.17 PATCH_11.04 (PHKL_29192) $ /usr/conf/lib/libufs.a(ufs_vnops.o): $Source: kern/ufs/ufs_vnops.c, hpuxsysufs, vvos_rose , rose0306 $ $Date: 01/01/25 07:11:54 $ $Rev ision: 1.47 PATCH_11.04 (PHKL_23054) $ OS-Core.KERN2-RUN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: /usr/conf/space.h.d/core-hpux.h: $Revision: Hewlett-Packard ISSL 1.5.1.5 kern/space_L P64/core-hpux.h, hpuxsysmisc, vvos_rose, ros e0306 $ $Date: 01/11/15 15:02:53 $ */ $Source: kern/space_LP64/core-hpux.h, hpuxsysmisc, v vos_rose, rose0306 $ $Date: 01/11/15 15:02:5 3 $ $Revision: 1.5.1.5 PATCH_11.04 (PHKL_250 56) $ */ cksum(1) Output: OS-Core.CORE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: 1137087442 7146 /usr/conf/h/file.h 1964822114 5550 /usr/conf/h/fss.h 1160245956 40853 /usr/conf/h/unistd.h ProgSupport.C-INC,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: 1137087442 7146 /usr/include/sys/file.h 1964822114 5550 /usr/include/sys/fss.h 179451922 5533 /usr/include/sys/ksleep.h 1160245956 40853 /usr/include/sys/unistd.h OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: 2066783413 26248 /usr/conf/lib/libhp-ux.a(autosysgen.o) 2009376334 1320 /usr/conf/lib/libhp-ux.a(fssdefault.o) 2207132246 7356 /usr/conf/lib/libhp-ux.a(gateway.o) 1740885562 33956 /usr/conf/lib/libhp-ux.a(init_sent.o) 3604443646 8400 /usr/conf/lib/libhp-ux.a(ivt_intercept.o) 3267233543 17524 /usr/conf/lib/libhp-ux.a(kern_fork.o) 2718658816 18872 /usr/conf/lib/libhp-ux.a(kern_sig.o) 1610519037 5824 /usr/conf/lib/libhp-ux.a(lo_subr.o) 2292634432 4176 /usr/conf/lib/libhp-ux.a(lo_vfsops.o) 3648042226 6712 /usr/conf/lib/libhp-ux.a(lo_vnops.o) 2953454855 10172 /usr/conf/lib/libhp-ux.a(lw_scall.o) 3490741984 6872 /usr/conf/lib/libhp-ux.a(pm_clockint.o) 1405532681 28604 /usr/conf/lib/libhp-ux.a(pm_policy.o) 2069097304 23840 /usr/conf/lib/libhp-ux.a(pm_proc.o) 324635980 30568 /usr/conf/lib/libhp-ux.a(pm_signal.o) 3418342225 37068 /usr/conf/lib/libhp-ux.a(pm_swtch.o) 1599765726 25016 /usr/conf/lib/libhp-ux.a(pm_threads.o) 4078630773 4096 /usr/conf/lib/libhp-ux.a(qmml.o) 13446639 1500 /usr/conf/lib/libhp-ux.a(scall_stubs.o) 749605891 12728 /usr/conf/lib/libhp-ux.a(subr_ksleep.o) 3966187265 27172 /usr/conf/lib/libhp-ux.a(subr_threads.o) 2622477559 16644 /usr/conf/lib/libhp-ux.a(sys_gen.o) 1335112 21400 /usr/conf/lib/libhp-ux.a(vfs.o) 1944437957 6264 /usr/conf/lib/libhp-ux.a(vfs_io.o) 4102386841 32368 /usr/conf/lib/libhp-ux.a(vfs_scalls.o) 3802647880 9064 /usr/conf/lib/libhp-ux.a(vfs_vnode.o) 3729644375 16088 /usr/conf/lib/libprm.a(kern_fss.o) 1501761962 33472 /usr/conf/lib/libufs.a(ufs_vnops.o) OS-Core.KERN2-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP: 136109306 22745 /usr/conf/space.h.d/core-hpux.h OS-Core.CORE2-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: 246932924 171792 /usr/conf/lib/libhp-ux.a(autosysgen.o) 2662421260 2536 /usr/conf/lib/libhp-ux.a(fssdefault.o) 1781791867 45968 /usr/conf/lib/libhp-ux.a(gateway.o) 2980481955 132960 /usr/conf/lib/libhp-ux.a(init_sent.o) 1138016068 20072 /usr/conf/lib/libhp-ux.a(ivt_intercept.o) 1877259917 40936 /usr/conf/lib/libhp-ux.a(kern_fork.o) 2805882810 50264 /usr/conf/lib/libhp-ux.a(kern_sig.o) 1477565286 15320 /usr/conf/lib/libhp-ux.a(lo_subr.o) 3955005457 9280 /usr/conf/lib/libhp-ux.a(lo_vfsops.o) 606797889 19184 /usr/conf/lib/libhp-ux.a(lo_vnops.o) 3830981077 15632 /usr/conf/lib/libhp-ux.a(lw_scall.o) 1979812915 15680 /usr/conf/lib/libhp-ux.a(pm_clockint.o) 1680884367 70272 /usr/conf/lib/libhp-ux.a(pm_policy.o) 3716749992 63376 /usr/conf/lib/libhp-ux.a(pm_proc.o) 912004136 68784 /usr/conf/lib/libhp-ux.a(pm_signal.o) 1330729855 73600 /usr/conf/lib/libhp-ux.a(pm_swtch.o) 3219670638 59584 /usr/conf/lib/libhp-ux.a(pm_threads.o) 3832579934 5880 /usr/conf/lib/libhp-ux.a(qmml.o) 2498426998 130760 /usr/conf/lib/libhp-ux.a(scall_stubs.o) 1146916382 31424 /usr/conf/lib/libhp-ux.a(subr_ksleep.o) 3478507083 67952 /usr/conf/lib/libhp-ux.a(subr_threads.o) 3923602112 37320 /usr/conf/lib/libhp-ux.a(sys_gen.o) 4265580084 61552 /usr/conf/lib/libhp-ux.a(vfs.o) 3072791588 13296 /usr/conf/lib/libhp-ux.a(vfs_io.o) 3828233473 79376 /usr/conf/lib/libhp-ux.a(vfs_scalls.o) 2078032980 20904 /usr/conf/lib/libhp-ux.a(vfs_vnode.o) 1020859965 37360 /usr/conf/lib/libprm.a(kern_fss.o) 2500720503 68216 /usr/conf/lib/libufs.a(ufs_vnops.o) OS-Core.KERN2-RUN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP: 571575076 23370 /usr/conf/space.h.d/core-hpux.h Patch Conflicts: None Patch Dependencies: s700: 11.04: PHKL_19142 PHKL_29215 s800: 11.04: PHKL_19142 PHKL_29215 Hardware Dependencies: None Other Dependencies: PHKL_21752, PHKL_27710: Three patches work together to implement this change (PHKL_29192, PHKL_21752, PHKL_27710) to reduce dispatch latency for higher priority runnable threads. These patches may be installed in any order or combination, or not at all (if the reduced dispatch latency feature is not desired). Supersedes: PHKL_25035 PHKL_23054 PHKL_22988 PHKL_22562 PHKL_18753 PHKL_18547 PHKL_25056 PHKL_25040 PHKL_23124 PHKL_23020 Equivalent Patches: PHKL_28202: s700: 11.00 s800: 11.00 Patch Package Size: 840 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_29192 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_29192.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_29192. 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_29192.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_29192.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_29192.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None