PROBLEM: (HPXQ43C4D, TKTR52185, QAR 46016) (Patch ID: OSF415-410039) ******* This patch fixes some hangs that may occur after the message "syncing disks..." is printed when the system panics. When these hangs occur, the completion of the "syncing disks..." message - the word "failed" or "done" does not get printed, and the system does not take a dump. In addition to fixing these known hangs, a timout mechanism is added to the "syncing disks" logic that will improve the reliability of getting a dump by using the system clock to break out of the "syncing disks" path and take a dump if no progress is being made on reducing the number of buffers to be flushed. The numbers printed periodically between the "syncing disks..." and "done" messages are the number of buffers left to flush. This patch also makes it more likely that AdvFS buffers will be flushed to disk during the "syncing disks..." processing after a system panic. There is still no guarantee that writes in progress at the time of a panic will be completed. PROBLEM: (QAR 49523) (Patch ID: OSF415-410034) ******** The vmstat(1) command may display negative numbers when run with the '-P' option. To reproduce the problem type: vmstat -P NOTE: The problem may not exist on all platforms / configurations because it is dependent on how the kernel build various internal data structures. PROBLEM: (QAR 49556) (Patch ID: OSF415-405037) ******** A "kernel memory fault" panic will be seen originating from the malloc() routine. The top stack entries will be as follows. Many different kernel routines may appear in the stack below malloc(). panic("kernel memory fault") trap() _XentMM() malloc() This problem is due to malloc() bucket corruption that occurs when there are racing fdetach()/ file-on-file unmounts. File-on-file mounting is most often used with the fattach() library call and System V Environment pipes. PROBLEM: (QAR 49556) (Patch ID: OSF415-405037) ******** Racing fdetach() or file-on-file unmounts can also cause threads to hang in the kernel with the following stack trace. 0 thread_block() 1 vfs_busy() 2 dounmount() 3 unmount() 4 syscall() 5 _Xsyscall() PROBLEM: (CLDs HPAQ92E5E,TKTR90455/QAR 49011) (Patch ID: OSF415-400100) ******** This patch prevents a "kernel memory fault" in the bread() routine while performing sync operations. The stack trace will look similar to the following: 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c"] 1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c"] 2 trap() ["../../../../src/kernel/arch/alpha/trap.c"] 3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s"] 4 bread() ["../../../../src/kernel/vfs/vfs_bio.c"] 5 iupdat() ["../../../../src/kernel/ufs/ufs_inode.c"] 6 ufs_sync() ["../../../../src/kernel/ufs/ufs_vfsops.c"; 7 sync() ["../../../../src/kernel/vfs/vfs_syscalls.c"] 8 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c"] 9 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"] PROBLEM: (QAR 47666) (Patch ID: OSF415-405036) ******** Sometimes the system cannot contact a device when it should be able to. The problem is that if a device got a selection timeout, the EDT structure is released. The next time the system tries to access that device, it fails if the device does not respond within the timeout period. PROBLEM: (HPXQB6189/QAR 49949) (Patch ID: OSF415-400141) ******** This patch fixes a network socket problem with select() missing state changes on clients from non-write to writable. PROBLEM: (MCPM94D74, QAR 49067) (Patch ID: OSF415-400165) ******** Fixes system crash when setting the date for SMP systems. A representative stack trace follows: panic("resettodr: cpu not master") ["../../../../src/kernel/bsd/subr_prf.c":753,] resettodr() ["../../../../src/kernel/arch/alpha/clock.c":322,] setthetime() ["../../../../src/kernel/bsd/kern_time.c":543,] settimeofday() ["../../../../src/kernel/bsd/kern_time.c":499,] PROBLEM: (QAR 51688, CLD USG-04543) (Patch ID: OSF415-410052) ******** The ObjectStore application from Object Design, Inc. fails with the following error: "Fatal error Invalid argument(errno = 22) munmap failed: cl_mmap:" PROBLEM: (USG-04536,51700) (Patch ID: OSF415-410059) ******** Idle processes display poor interactive responsiveness. this patch prevents idle processes from being outswapped too soon. This patch allows tuneability for two level task swapping scheme that exists. Currently all idle tasks are outswapped when the free list remains below vm_page_free_target for 5 seconds. This patch changes the logic so that you can tune the threshold for swapping idle tasks. Idle tasks will not be outswapped until the free lists falls below vm_page_free_swap(default is 74 pages) and vm_page_free_swap is controlled by the vm-page-free-swap sysconfigtab tunable parameter. PROBLEM: (QAR 36779) (Patch ID: OSF415-405054) ******** This patch fixes a problem that occurs when running the NetWorker Version 4.2c application. The NetWorker application is unable to reset the atime (access time) attribute on files being accessed. No errors or warnings are displayed. Without this patch, NetWorker Version 4.2c will not perform well. PROBLEM: (HPXQB6BA4) (Patch ID: OSF415-410062) ******** This patch fixes a problem in which the user or system setting of UAC_NOPRINT is ignored when an unaligned access trap is taken on a user address while in kernel mode. When this is a common event due to a customer application, the console and "messages" file can be flooded with error messages of the sort show below: Oct 19 03:20:18 dekalb vmunix: Unaligned kernel access va=0x140018554 pc=0xfffff c00004f5f24 ra=0xfffffc000025bc80 inst=0xffffffff PROBLEM: (MCPMA986D) (Patch ID: OSF415-405044) ******** This patch is a kernel fix for network sockets left in FIN_WAIT_1 state forever. This patch contains a "tunable" kernel parameter. It is recommended that only experienced system administrators attempt to set this parameter from the default value. How to recognize this problem. This is an example of the problem with tcpdump running in the background listening on the destination ip address shown in the netstat output. # netstat -An | grep 203.232.10.221 Active Internet connections PCB Proto Recv-Q Send-Q Local Address Foreign Address (state) 94276c00 tcp 0 759 192.86.154.82.80 203.232.10.221.162 FIN_WAIT_1 9418ef00 tcp 0 759 192.86.154.82.80 203.232.10.221.162 FIN_WAIT_1 13:28:03.472384 www-2.us.oracle.com.80 > 203.232.10.221.1626: . 0:1(1) ack 1 win 33232 13:28:12.973072 www-2.us.oracle.com.80 > 203.232.10.221.1623: . 0:1(1) ack 1 win 33232 What is observed here is the destination is clearly dead. The source is sending an ACK to the destination looking for his ACK of our FIN. This is commonly refered to as "persist mode". A socket in this state will never timeout and system resources associated with it will not be released. The new kernel modification to tcp_timer.o can be "tuned" by dbx'ing the tcp_keepidle parameter on the system. By default, this is set to 14400 1/2 seconds (2 hours). It can be easily set to any value appropriate for the system to "balance" the number of sockets in FIN_WAIT_1 state at any time. The system may always have some sockets in FIN_WAIT_1 as well as CLOSE_WAIT, this is NORMAL. What you don't want is a large number of sockets in FIN_WAIT_1 forever. It is not recommended that tcp_keepidle be set to less than 5 minutes on the system. Reference the man page to dbx for guidelines when using the dbx command. PROBLEM: (ZUO101015/QAR 49750) (Patch ID: OSF415-405053) ******** This patch fixes ICMP REDIRECTS. When an ICMP REDIRECT is received, the routing table was updated properly, but the IP layer didn't use the new route information. PROBLEM: (CLD MCPMB04E3) (Patch ID: OSF415-405059) ******** This patch resolves a TCP/IP network hang due to an IP Q ACK deadlock. When this condition occurs the IP Q becomes full due to saturation. Representative console messages indicating this condition are shown below: SIS00-00-root: IP q full, 315617 packets dropped in the last 5 mins. PROBLEM: (CA7Q10994) (Patch ID: OSF415-410049) ******** This patch fixes a problem that occurs on all systems that use networking services. The problem can be seen when a system attempts to ping a Digital UNIX Alpha system connected to a token ring network and the ping uses a message size that requires fragmentation. The Digital UNIX Alpha system receiving the ping cannot respond. The token ring driver displays the following error message to the console and resets the token ring adapter: List Error in transmit PROBLEM: (HPXQB4C4B) (Patch ID: OSF415-400186) ******** This patch fixes a problem in which the system can panic with "lock already owned by thread". A typical stack trace shows: boot panic lock_fault lock_write solock socket_send ip_mforward ip_output rip_output raw_usrreq rip_usrreq sosend sendit sendto syscall PROBLEM: (MCPMC07S7) (Patch ID: OSF415-400201) ******** This patch fixes a kernel memory fault in ether_output packet filter, when running tcpdump. A representative stack trace of the 'tcpdump' process following: read_io_port() src/kernel/io/dec/pci/pcia.c : 707 fta_poll_cmd_req() src/kernel/io/dec/netif/if_fta.c : 3065 ftaioctl() src/kernel/io/dec/netif/if_fta.c : 1831 enetSetIfflags() src/kernel/net/pfilt.c : 3311 decCopyAllCount() src/kernel/net/pfilt.c : 3367 Pfilt_close() src/kernel/net/pfilt.c : 1376 speclose() src/kernel/vfs/spec_vnops.c : 2486 spec_close() src/kernel/vfs/spec_vnops.c : 2616 ufsspec_close() src/kernel/ufs/ufs_vnops.c : 3632 vn_close() src/kernel/vfs/vfs_vnops.c : 1280 closef() src/kernel/bsd/kern_descrip.c : 1539 close() src/kernel/bsd/kern_descrip.c : 1217 PROBLEM: (49818) (Patch ID: OSF415-400127) ******** System panics with messgae: "vm_map_swapout: negative resident count". The crash will most likely occur on a multiprocessor system during a heavy paging load. A typical stack trace for the panic will be as follows: panic("vm_map_swapout: negative resident count") vm_map_swapout() task_swapout() task_swapout_thread() PROBLEM: (CLD MCPMB7DEJ, QAR 50938) (Patch ID: OSF415-400197) ******** This patch resolves a kernel memory fault. A representative stack trace follows: panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":753, ] trap() ["../../../../src/kernel/arch/alpha/trap.c":1457, ] _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1392, ] simple_lock_D() ["../../../../src/kernel/arch/alpha/lockprim.s":730, ] u_anon_dupmcopy() ["../../../../src/kernel/vm/u_mape_anon.c":1603, ] u_anon_dup() ["../../../../src/kernel/vm/u_mape_anon.c":1321, ] u_map_copyin() ["../../../../src/kernel/vm/vm_umap.c":2085, ] vm_map_copyin() ["../../../../src/kernel/vm/vm_map.c":1691, ] procfs_psinfo() ["../../../../src/kernel/procfs/procfs_subrs.c":2425, ] procfs_ioctl() ["../../../../src/kernel/procfs/procfs_ioctl.c":301, ] vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1165, ] procfs_ioctl_interface() ["../../../../src/kernel/procfs/procfs_ioctl.c":1716, ] ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":426, ] ioctl() ["../../../../src/kernel/bsd/sys_generic.c":374, ] PROBLEM: (Patch ID: OSF415-410068) ******** This network patch, which greatly improves Digital UNIX networking performance, is targeted at high traffic Web server systems or any system which handles a large number of TCP connections simultaneously, ie. more than several thousand at one time. The summary of improvements include: Network kernel SMP locking improvements increased throughput due to reduced lock contention throughout the network stack on multiprocessor (SMP) systems. Socket code improvements improved performance in socket listen queue handling somaxconn, sominconn listen backlog support was increased from 32K to 64K maximum. TCP code improvements fully dynamic TCP hash table, can change size on the fly without having to reboot (tcbhashsize) support for TCP hash table size larger than 1024 (tcbhashsize) improved TCP timer algorithm eliminates a large percentage of the processing overhead to handle the tcp timer task more efficient port allocation code decreases outgoing connection overhead (ipport_userreserved) randomized TCP initial sequence number. IP reassembly fix for >12Gb memory systems and other minor TCP/IP bug fixes. Kernel malloc improvements improved kernel malloc pool performance on SMP platforms Kernel select improvements improved kernel select performance on SMP platforms when many open file descriptors are selected simultaneously. Additional kernel network tunable variables (using sysconfig): sobacklog_drops sobacklog_hiwat somaxconn_drops ipport_userreserved tcp_rexmit_interval_min tcp_cwnd_segments tcp_keepalive_default PROBLEM: (EVT101963, QAR 52024) (Patch ID: OSF415-405062) ******** The kernel panics with a "kernel memory fault". Typical stack traces will panic in either vm_zeroed_pg_alloc() or vm_pg_alloc() as shown below: > 0 boot src/kernel/arch/alpha/machdep.c : 2361 1 panic src/kernel/bsd/subr_prf.c : 791 2 trap src/kernel/arch/alpha/trap.c : 1457 3 _XentMM src/kernel/arch/alpha/locore.s : 1388 4 vm_zeroed_pg_alloc src/kernel/vm/vm_resident.c : 1289 5 vm_anon_page_alloc src/kernel/vm/vm_anonpage.c : 119 6 anon_pagezero_alloc src/kernel/vm/vm_anon.c : 448 7 u_anon_faultpage src/kernel/vm/u_mape_anon.c : 968 8 u_anon_fault src/kernel/vm/u_mape_anon.c : 861 9 u_map_fault src/kernel/vm/vm_umap.c : 501 10 vm_fault src/kernel/vm/vm_fault.c : 134 11 trap src/kernel/arch/alpha/trap.c : 1467 12 _XentMM src/kernel/arch/alpha/locore.s : 1388 > 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 414 1 panic src/kernel/bsd/subr_prf.c : 703 2 event_timeout src/kernel/arch/alpha/cpu.c : 811 3 xcpu_puts src/kernel/bsd/subr_prf.c : 844 4 printf src/kernel/bsd/subr_prf.c : 379 5 panic src/kernel/bsd/subr_prf.c : 753 6 trap src/kernel/arch/alpha/trap.c : 1457 7 _XentMM src/kernel/arch/alpha/locore.s : 1388 8 vm_pg_alloc src/kernel/vm/vm_resident.c : 1162 9 ubc_alloc src/kernel/vfs/vfs_ubc.c : 3278 10 ubc_page_alloc src/kernel/vfs/vfs_ubc.c : 2240 11 ubc_lookup src/kernel/vfs/vfs_ubc.c : 1779 12 page_lookup src/kernel/msfs/bs/bs_buffer2.c : 1041 13 seq_ahead src/kernel/msfs/bs/bs_buffer2.c : 5258 14 seq_ahead_cont src/kernel/msfs/bs/bs_buffer2.c : 5013 15 bs_refpg_int src/kernel/msfs/bs/bs_buffer2.c : 1867 16 bs_refpg src/kernel/msfs/bs/bs_buffer2.c : 1596 17 fs_read src/kernel/msfs/fs/fs_read_write.c : 1549 18 msfs_read src/kernel/msfs/osf/msfs_vnops.c : 1883 19 vn_read src/kernel/vfs/vfs_vnops.c : 864 20 rwuio src/kernel/bsd/sys_generic.c : 1217 21 read src/kernel/bsd/sys_generic.c : 1167 22 syscall src/kernel/arch/alpha/syscall_trap.c : 540 23 _Xsyscall src/kernel/arch/alpha/locore.s : 1173 PROBLEM: (HPAQC07YV) (Patch ID: OSF415-400208) ******** This patch fixes a problem that occurs when the system panics with the following error message: kernel memory fault The following is a typical stack trace of the system panic: 0 boot() [../../../../src/kernel/arch/alpha/machdep.c] 1 panic("kernel memory fault") [../../../../src/kernel/bsd/subr_prf.c] 2 trap() [../../../../src/kernel/arch/alpha/trap.c] 3 _XentMM() [../../../../src/kernel/arch/alpha/locore.s] 4 _svcauth_unix() [../../../../src/kernel/rpc/svc_auth_unix.c] 5 _authenticate() [../../../../src/kernel/rpc/svc_auth.c] 6 nfs_rpc_recv() [../../../../src/kernel/rpc/svc.c] 7 nfs_rpc_input() [../../../../src/kernel/rpc/svc.c] 8 nfs_input() [../../../../src/kernel/nfs/nfs_server.c] 9 nfs_thread() [../../../../src/kernel/nfs/nfs_server.c] PROBLEM: (QAR 50697, MGO102332, FNO100130 ) (Patch ID: OSF415-400198) ******** This patch fixes a number of problems relating to signals and POSIX 1003.1b timers in multithreaded programs running on multiprocessor systems. These problems can result in missed timer-expiration signals and system crashes. These issues involve synchronizing timer creation, timer deletion, and timer reset within multithreaded programs. Two distinct crashes are typical of the problems. Here's a sample of the first crash, a signal panic: panic (cpu 0): psig: catch not set With the following stack trace: > 0 boot 1 panic 2 psig 3 syscall 4 _Xsyscall A sample of the second crash is shown in the following example: from vmcore.3 : . . . simple_lock: time limit exceeded . . . pc of caller: 0xfffffc000024a5a4 lock address: 0xfffffc003d93b210 current lock state: 0x000000000043af85 (cpu=0,pc=0xfffffc000043af84,busy) . . . panic (cpu 2): simple_lock: time limit exceeded While a stack trace would show: kernel stack of CPU 0 > 0 boot 1 panic 2 event_timeout 3 simple_lock_miss 4 netisr_timeout 5 softclock_scan 6 lwc_schedule 7 thread_preempt 8 boot 9 panic 10 cpu_ip_intr 11 _XentInt 12 swap_ipl_preempt_check 13 wanTimerSysTick . . . kernel stack of CPU 1 > 0 stop_secondary_cpu ... 1 panic : 2 cpu_ip_intr : THIS PART OF THE KERNEL STACK 3 _XentInt : IS VERY TYPICAL FOR THIS CLASS 4 sigq_enqueue_tail : OF CRASHES. 5 psignal_internal : 6 psx4_tod_expire_sig ..: 7 psignal_lwc 8 lwc_schedule 9 do_preemption 10 simple_unlock_preempt 11 sigwaitprim 12 syscall 13 _Xsyscall . . . kernel stack of CPU 2 > 0 stop_secondary_cpu 1 panic 2 event_timeout 3 xcpu_puts 4 printf 5 panic 6 simple_lock_fault 7 simple_lock_time_violation 8 psx4_set_todtimer 9 syscall 10 _Xsyscall . . . kernel stack of CPU 3 > 0 stop_secondary_cpu 1 panic 2 cpu_ip_intr 3 _XentInt 4 swap_ipl_preempt_check 5 netisr_thread 6 wanTimerTick . . . This patch closes MP race conditions for multithreaded use of POSIX timers and signals. PROBLEM: (QARs 50693,49421) (Patch ID: OSF415-400216) ******** This patch corrects a problem with the exec() system function. A shell script that has "#! " as the first line of the script, invokes the program but does not set the effective user id for the execution of the program. For example: $ cat myprog.c #include main() { printf("geteuid() return effective user ID of the calling process=%d\n",geteuid()); } $ cat test.sh #!./myprog echo "done with myprog" As root: # chmod 4755 myprog # chown root myprog As user ww $ ./myprog geteuid() return effective user ID of the calling process=0 $ ./test.sh geteuid() return effective user ID of the calling process=7301 In this case ./test.sh should return an euid of 0. PROBLEM: (QAR 46424) (Patch ID: OSF415-400221) ******** This patch fixes a problem in which the UFS property list can become corrupted. To reproduce this problem, complete the following steps: 1. Create a relatively large property value on a file. 2. Create another property value on the same file. 3. Change the property value created in Step 1 to a smaller value. 4. Run fsck with the -o flag. The fsck command reports that the file system is corrupted and displays the following error message: ** Phase 1 - Check Blocks and Sizes PROPERTY LIST BLOCK CORRUPTED I=3 CLEAR? [yn] PROBLEM: (CLD EVT101664) (Patch ID: OSF415-400232) ******** This patch fixes a performance problem that occurs with UFS file systems. Data written to a file greater than 32 GB in length will be slower than data written to the file when it is less than 32 GB in length. PROBLEM: (CLD MCPMB04E3) (Patch ID: OSF415-400233) ******** This patch resolves a TCP/IP network hang due to an IP Q ACK deadlock. When this condition occurs the IP Q becomes full due to saturation. Representative console messages indicating this condition are shown below: SIS00-00-root: IP q full, 315617 packets dropped in the last 5 mins. PROBLEM: (QAR 50363) (Patch ID: OSF415-400235) ******** This patch fixes a problem with the fsck command. When fsck is run on a non-existent file system or on a currently mounted file system, it returns a success status of zero. It should return a non-zero status. An example where this problem is exhibited is shown here: # fsck /dev/rz2a /sbin/ufs_fsck /dev/rz2a ** /dev/rrz2a Error: /dev/rrz2a or an overlapping partition is open. FSCK CANNOT BE RUN ON AN ACTIVE FILESYSTEM. # echo $? 0 ALSO: # fsck /mnt /sbin/ufs_fsck /mnt Can't make sense out of name /mnt # echo $? 0 PROBLEM: (CLD HPXQ87202, QARs 49448,49474,49475) (Patch ID:OSF415-400242) ******** This patch fixes a problem in which the the lastcomm accounting command doesn't print the "S" flag at appropriate times. This patch also improves the performance of lastcomm. The problem was that the kernel did not properly update the accounting field that prints the "S" flag. The "S" flag should be printed for each command that is run with an effective user id of 0. Commands that are set-user-id to root, will print the "S" flag. Also, commands that are executed by root, but are not set-user-id, will print the "S" flag. Therefore, when "S" is printed from lastcomm for a certain command, it means that the user had root privileges at some time during the execution of the command. The algorithm used by lastcomm has been enhanced to improve its performance. PROBLEM: (MCPM11KK6) (Patch ID: OSF415-405058) ******** This patch provides support for the fuser utility. This utility displays a list of processes that are holding references to a file on the file system that cannot be unmounted. This utility can also be used to terminate a process so the file system can be unmounted. PROBLEM: (CLD: MCPM3028N) (Patch ID: OSF415-400250-1) ******** This patch fixes a problem in which network applications communicating to one of the host's own addresses, may hang, or receive the error message: no buffer space available The problem occurs due to a queue full condition on the interface. In an Available Server (ASE) or TruCluster environment, the daemons will no longer be able to communicate with each other, and the asemgr utility will appear to hang. PROBLEM: (QAR 50695) (Patch ID: OSF415-410070) ******** This patch fixes a problem that prevents an "options DCEDFS" line from being added to the kernel configuration file. Without the fix, the kernel build will fail with the error "ld: dcedfs.mod: setjmp: multiply defined". PROBLEM: (QAR 49023) (Patch ID: OSF415-400130) ******** A "panic: lock_read: hierarchy violation in del_dealloc_stg" error occurs when a socket lock is held by a UNIX domain while calling vrele(). PROBLEM: (MGO102810/QAR 49847) (Patch ID: OSF415-410074) ******** This patch is an enhanced fix to the solockpair() routine. This fix was needed because the routine was freeing a socket lock structure that was concurrently spun upon in lock_write(). Typical problem symptoms include kernel memory faults with sockets, mbufs and mblocks as well as hangs. Applications using sockets in a multithreaded, multicpu environment can experience a number of lock violations with the socket structures. This patch is MANDATORY to install on all systems. It will be effective on Uniprocessor systems when lockmode debugging is invoked. PROBLEM: (EVT102135, HPAQ50J6Z, SQO100374, MCPM50UKH, EVT102245, KAOB6KRMX, ******** QAR 52779, QAR 52525 ) (Patch ID: OSF415-410085) This is a mandatory patch for the following systems and conditions: . Systems that use program debuggers such as TotalView, Ladebug, dbx, or gdb. . Systems that use the /proc file system in any other way (for example, the System V Environment ps command). . Systems that experience panics and hangs in the /proc file system. The most common panic string is "kernel memory fault"; also seen are "simple_lock time limit exceeded" panics. In all cases, a routine with the string "procfs_" will appear in the kernel stack trace. - Systems that panic when running multithreaded programs that call an exec() function. Hangs usually involve either the debugger or debugged process or both entering the unkillable "U" state, as seen from the ps command. The hangs may be either quiescent or compute bound. Other symptoms involve "" processes be left behind after a debugging session is terminated. This patch is particularly important for debugging in a multithreaded enviroment on multiprocessor systems. The greater the concurrency of the program being debugged, and the greater the number of processors, the more likely problems are to occur. PROBLEM: ( ISO100331 ) (Patch ID: OSF415-410085) ******** A muli-threaded program that calls an exec() function can panic the system with a kernel memory fault. A typical stack trace looks like this: 0 boot() 1 panic("kernel memory fault") 2 trap() 3 _XentMM() 4 nxm_upcall() 5 trap() 6 _Xsyscall() The critical feature of the stack trace is the presence of the nxm_upcall() function prior to the kernel memory fault. The crash dump will show that the thread is in process of processing an thread-block notification system trap. PROBLEM: (CLD UTO101199,HPAQ30ETE, QAR 51485,52365) (Patch ID: OSF415-410087) ******** This patch corrects a problem with an NFS V3 mounted AdvFS file system where under heavy I/O load, data being written to a file may be lost. Additionally, because file stats are not being saved, the file modification time may revert to a previous value. PROBLEM: (QAR 51581) (Patch ID: OSF415-400245) ******** Fixes a panic that prints "kernel memory fault". A typical stack trace is: 1 panic("kernel memory fault") 2 trap() [src/kernel/arch/alpha/trap.c] 3 _XentMM() [src/kernel/arch/alpha/locore.s] 4 bcopy() [src/kernel/arch/alpha/fastcopy.s] 5 volkiocopyin() [src/kernel/lsm/dec/kiosubr.c] 6 volsio_stabilize() [src/kernel/lsm/common/stable.c] 7 vol_mv_write_start() [src/kernel/lsm/common/mvio.c] 8 volkiostart() [src/kernel/lsm/common/kiostart.c] 9 volstrategy() [src/kernel/lsm/dec/voldev.c] 10 physio() [src/kernel/ufs/ufs_physio.c] 11 physiock() [src/kernel/lsm/dec/Space.c] 12 volrdwr() [src/kernel/lsm/dec/voldev.c] 13 volwrite() [src/kernel/lsm/dec/voldev.c] 14 spec_write() [src/kernel/vfs/spec_vnops.c] 15 msfsspec_write() [src/kernel/msfs/osf/msfs_vnops.c] 16 vn_write() [src/kernel/vfs/vfs_vnops.c] 17 rwuio() [src/kernel/bsd/sys_generic.c] 18 write() [src/kernel/bsd/sys_generic.c] 19 syscall() [src/kernel/arch/alpha/syscall_trap.c] 20 _Xsyscall() [src/kernel/arch/alpha/locore.s] This patch is MANDATORY to install. PROBLEM: (CLD FNO100138) (Patch ID: OSF415-400266) ******** This patch fixes a 'recursion count overflow' panic that occurs on Digial UNIX. Representative Stack trace: panic ("lock_set_recursive: recursion count overflow") src/kernel/bsd/\ subr_prf.c : 791 lock_fault() src/kernel/kern/lock.c : 2003 lock_set_recursive() src/kernel/kern/lock.c : 1444 makenfs3node() src/kernel/nfs/nfs_subr.c : 1722 nfs3_lookup() src/kernel/nfs/nfs3_vnodeops.c : 2157 namei() src/kernel/vfs/vfs_lookup.c : 593 stat1() src/kernel/vfs/vfs_syscalls.c : 2801 stat() src/kernel/vfs/vfs_syscalls.c : 2769 PROBLEM: (CLD HPXQ9722E) (Patch ID: OSF415-400240) ******** This patch allows some third-party NFS v2 clients to experience a performance improvement. Candidate applications are ones that perform read/write operations to a memory mapped file over NFS. NOTES: 1) This patch must be enabled _BEFORE_ NFS is started because it needs to perform some configuration operations before client requests start arriving. This why the dbx patch is to the /vmunix file and not to memory. If the patch is applied to memory, it will be ignored, since the initialization routine only runs when NFS is started. 2) Affects NFS V2 only. NFS v3 connections are unaffected. 3) Files that are only read or only written will not be affected. 4) The NFS Dup cache and NFS Write Gathering are disabled by this patch. To enable the patch, perform the following steps: % dbx -k /vmunix (dbx) patch stall_write_patch_enabled=1 (dbx) quit % reboot PROBLEM: (CLD FNO100139) (Patch ID: OSF415-400289) ******** When a directory path on an NFS server is deleted, any process attempting to access the missing path will cause NFS stale file handle messages to be printed on the server's console. This patch will greatly reduce the number of these messages. PROBLEM: (CLD MCPM403TL, QAR 48048) (Patch ID: OSF415-400296) ******** This patch fixes a problem with the "ifconfig -a" command. At times, the command will not display all of the network interfaces. PROBLEM: (QAR - 49164) (Patch ID: OSF415-400298) ******** This patch adds a mechanism to the poll() system call to allow it to be used as a timer by passing in a null argument for the number of file descriptors. Currently the poll() system call will return immediately when passed a null argument for the number of file descriptors. PROBLEM: (Patch ID: OSF415-400351) ******** This patch fixes a problem in which panics will occur if an attempt is made to run a shell script residing on any filesystem mounted with the "noexec" option. The panic message is "kernel memory fault" and the kernel stack trace obtained from the resulting dump is of the following form: 0 boot 1 panic ("kernel memory fault") 2 trap 3 exec_setuid 4 common_exec 5 execve 6 syscall 7 _Xsyscall PROBLEM: (EVT102039) (Patch ID: OSF415-405098) ******** This patch fixes a problem that occurs when using real-time applications. When writing large (sequential) files to a UFS file system, time constraints associated with the application may be violated. This problem can occur due to draining a large number of sequential pages associated with the file. This draining occurs when the application requests a new page AND the number of sequential pages exceeds a prescribed limit (which is user-tuneable). The time limit constraint of the application may be violated when the VM subsystem frees these excess pages. PROBLEM: (CLD HPAQ400UX) (Patch ID: OSF415-400281) ********* On large memory, multicpu systems that have a high demand on virtual memory, a simple lock fault can occur on the lru. On large memory, multicpu systems, when free memory is exhausted, a simple lock timeout can occur in vm routines. The stack trace could look like one of the following: 5 panic(s = 0xfffffc0000583a08 = "simple_lock: time limit exceeded") 6 simple_lock_fault() 7 simple_lock_time_violation() 8 vm_page_stealer() 9 vm_pg_alloc() 10 malloc_thread() or 5 panic(s = 0xfffffc0000583a08 = "simple_lock: time limit exceeded") 6 simple_lock_fault() 7 simple_lock_time_violation() 8 vm_ops_reference_def() 9 vm_map_clip_start() 10 k_mem_entry_adjust() 11 k_mem_lockop() 12 k_map_wire() 13 vm_map_pageable_orig() 14 vm_map_pageable() 15 thread_swapout() 16 task_swapout() 17 task_swapout_thread() PROBLEM: (SSRT0482U) (Patch ID: OSF415-400283) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file or privilege management. Digital has corrected this potential vulnerability. PROBLEM: (UVO105527) (Patch ID: OSF415-400346) ******** This patch fixes a problem that causes systems to panic with a "kernel memory fault" from u_dev_lockop(). This has happened when a database tried to memory map a file. A typical stack trace follows: 5 panic("kernel memory fault") [src/kernel/bsd/subr_prf.c:753] 6 trap() [src/kernel/arch/alpha/trap.c:1512] 7 _XentMM() [src/kernel/arch/alpha/locore.s:1424] 8 u_dev_lockop() [src/kernel/vm/u_mape_dev.c:535] 9 u_dev_unmap() [src/kernel/vm/u_mape_dev.c:481] 10 u_map_delete() [src/kernel/vm/vm_umap.c:1321] 11 u_dev_create() [src/kernel/vm/u_mape_dev.c:202] 12 spec_mmap() [src/kernel/vfs/spec_vnops.c:2962] 13 smmap() [src/kernel/bsd/kern_mman.c:831] 14 syscall() [src/kernel/arch/alpha/syscall_trap.c:540] 15 _Xsyscall() [src/kernel/arch/alpha/locore.s:1209] kernel_memory_fault_data: faulting virtual address: 0x001ffc003568af9c pc of faulting instruction: 0xfffffc000042dd4c ra contents at time of fault: 0xfffffc000042dcb8 sp contents at time of fault: 0xffffffffa9243600 PROBLEM: (QAR 47473) (Patch ID: OSF415-400353) ******** This patch fixes the problem of audit_tool terminating prematurely the reading of a complete large log file via zcat. This usually occurs under gui control. To reproduce error from the command line: /usr/sbin/audit_tool large_audit_file.Z The file must be big enough to enter the following so zcat can be suspended and restarted. Be carefull of other zcat proc's. kill -17 $( echo $( ps -ef | grep zcat | grep -v grep | awk '{print $2}' ) ) kill -19 $( echo $( ps -ef | grep zcat | grep -v grep | awk '{print $2}' ) ) The repaired binary will continue after kill -19, CONT. PROBLEM: (EVT102135, HPAQ50J6Z, SQO100374, MCPM50UKH, EVT102245, ******** KAOB6KRMX, QAR 52779, QAR 52525 ) (Patch ID: OSF415-400354) This is a mandatory patch for the following systems and conditions: - Systems that use program debuggers such as TotalView, Ladebug, dbx, or gdb. - Systems that use the /proc file system in any other way (for example, the System V Environment ps command). - Systems that experience panics and hangs in the /proc file system. The most common panic string is "kernel memory fault"; also seen are "simple_lock time limit exceeded" panics. In all cases, a routine with the string "procfs_" will appear in the kernel stack trace. - Systems that panic when running multithreaded programs that call an exec() function. Hangs usually involve either the debugger or debugged process or both entering the unkillable "U" state, as seen from the ps command. The hangs may be either quiescent or compute bound. Other symptoms involve "" processes be left behind after a debugging session is terminated. This patch is particularly important for debugging in a multithreaded enviroment on multiprocessor systems. The greater the concurrency of the program being debugged, and the greater the number of processors, the more likely problems are to occur. PROBLEM: (ISO100331) (Patch ID: OSF415-400354) ******** A mulithreaded program that calls an exec() function can panic the system with a kernel memory fault. A typical stack trace looks like this: 0 boot() 1 panic("kernel memory fault") 2 trap() 3 _XentMM() 4 nxm_upcall() 5 trap() 6 _Xsyscall() The critical feature of the stack trace is the presence of the nxm_upcall() function prior to the kernel memory fault. The crash dump will show that the thread is in process of processing an thread-block notification system trap. PROBLEM: (STLB51417) (Patch ID: OSF415-400367) ******** This patch improves the performance of applications that map tens or even hundreds of thousands of files into the virtual address space. This is accomplished by creating an index into the list of map entries or data structures that describe the mapping of a file. This index is used to significantly shorten the time it takes to locate a file mapped within a process address space. There are 5 additional tunable parameters associated with this patch: vm-map-index-enabled: This parameter controls whether or not the entire indexing of the vm_map_entries. If this is non-zero, the map entries will be indexed in all processes. The default is 1(non-zero). vm-map-index-count: This is the size of the map entry index. A larger index will create a faster lookup time but a potentially more costly rebalancing operation. The default is 64, in other words you can expect the lookups to be at least 64 times faster than without this fix. vm-map-index-rebalance: This parameter controls how frequently the index gets rebalanced, if the difference between the longest map entry list and the shortest map entry list is greater than this parameter, the system rebalances the index. Setting this parameter to a lower value will cause more rebalancing but will result in faster lookups. Setting this parameter to a higher value will result in less rebalancing but will result in slower lookups. vm-map-index-hiwat: This parameter controls when the index will be created. The default is 4. When a process allocates vm-map-index-count * vm-map-index-hiwat(256 by default) the system allocates a map entry index and begins using it for faster lookups. vm-map-index-lowat: This parameter controls when the index will be deleted. The default is 2. Then a process deletes enough map entries so that there are fewer than vm-map-index-count * vm-map-index-lowat(128by default) the system frees the map entry index and no longer uses it for faster lookups. The symptom of a customer needing this patch is: Very high percentage of system time and vm-mapentries set very high(greater than 2000) in the /etc/sysconfigtab file and running an application that mmap()'s thousands of files. PROBLEM: ( ZPOB91873, HGOBB0092 ) (Patch ID: OSF415-021) ******** This patch provides additional details for hard errors logged after unsuccessful I/O recovery attempts, and provides informational messages on the progress of recovery events. PROBLEM: (Patch ID: OSF415-400369) ******** This patch provides general support for Version A11 KZPSA firmware. PROBLEM: (CLD EVT102273,SPR VNO100100,QAR 55615 ) (Patch ID: OSF415-400373) ******** This patch fixes a problem in which a filesystem cannot be unmounted. The system displays a "Device busy" error message. PROBLEM: (MCSM80GC5) (Patch ID: OSF415-400378) ******** This patch fixes a problem that occurs when starting up a system that is running the auditing subsystem and the performance manager. The system panics with the following error message: kernel memory fault A sample stack trace is shown in the following example: 0 thread_block() 1 thread_preempt() 2 boot() 3 panic(s = 0xfffffc000060b280 = "kernel memory fault") 4 trap() 5 _XentMM() 6 syscall() 7 _Xsyscall() PROBLEM: (CLD MCPMA7154,MCPMB1B9V,MCPM41683,MCPM70JFF,QAR 49696,52727,51574) ******** (Patch ID: OSF415-400384) This patch is MANDATORY. This patch contains two vm fixes in both the UFS and NFS code that collectively resolve a multitude of nfs and nfsd hangs. PROBLEM: (QAR 52810, QAR 40239, QAR 53048) (Patch ID: OSF415-400284) ******** This patch is mandatory for JAVA applications. This patch fixes a problem where conversion from double-precision floating point numbers to single-precision floating point numbers may not round properly in IEEE mode when the result should be the smallest denormal. More specifically, software completion of the Alpha CVTTSSU instruction does not properly round the result when the input double value is between the smallest S-float denormal and 1/2 the smallest S-float. For example: double d = 1.5E-45; double f; f = d; The result should be:1.40129846E-45 The result before the patch is 0.0. PROBLEM: (CLD TKTR91730) (Patch ID: OSF415-400397) ******** While sendsig() is prepairing a SIGFPE signal, the system panics with a kernel memory fault. The ieee_get_fp_control() routine uses the macros NXM_IEEE_STATE_COPYIN() and NXM_IEEE_STATE_COPYOUT(). These macros inadvertantly corrupt pcb->pcb_nofault. This patch solves the problem by saving and restoring the pcb nofault handler. The stack trace will be: panic("kernel memory fault") _XentMM() sendsig() psig() trap() _XentIF() The faulting VA will contain an address simular to: 0x000000011ffff??? And the instructions leading to the faulting pc will be: bsr ra, ieee_get_fp_control(line 61) lda a0, 16383(zero) stq v0, 560(s5) PROBLEM: (MCPM905D0, QAR 56258) (Patch ID: OSF415-400401) ******** The current kmem_debug capability has significant shortcomings due to the fact that is an all-or-nothing entity: 1. It consists of several distinct debugging capabilities, all of which are imposed when kmem_debug is turned on. 2. It imposes all of the debugging capabilities on all of the 32 bucket sizes. Therefore, when turned on, it imposes a huge performance degradation that make its use impossible in many customer runtime environments. The following solutions have been put into place by this patch: 1. The capability of selection one or more kmem_debug options. 2. The capability of selecting one or more specific bucket sizes for debugging. 3. The addition of two popular debugging options that until now have only been available through the use of two "unofficial" patches: - The "kmem_debug_lite" patch has been incorporated as KMEM_DEBUG_LINKS - The "bear-trap" patch has been incorporated as KMEM_DEBUG_PROTECT PROBLEM: (CLD MCPM81FWD) (Patch ID: OSF415-400407) ******** This patch is MANDATORY. This patch resolves an inode locking problem is the UFS iupdat() and itimes() functions. PROBLEM: (ZPOB54022 ) (Patch ID: OSF415-410102) ******** This patch fixes a problem that may occur after a system panics. The system may hang when trying to do a crash dump. The problem is due to the system getting into a boot/panic loop. The following is an example of a typical stack trace: 1 panic("event_timeout: panic request") 2 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005] 3 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244] 4 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":1220"] 5 drvr_flush()["/src/kernel/io/common/driver_support.c":2115"] 6 boot()["/src/kernel/arch/alpha/machdep.c":2525] 7 panic("event_timeout: panic request") 8 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005"] 9 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244] 10 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":2115] 11 drvr_flush()[/src/kernel/io/common/driver_support.c":2115"] 12 boot()["/src/kernel/arch/alpha/machdep.c":2525] 13 panic("event_timeout: panic request") 14 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005"] 15 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244] 16 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":2115] 17 drvr_flush()[/src/kernel/io/common/driver_support.c":2115"] 18 boot()["/src/kernel/arch/alpha/machdep.c":2525] PROBLEM: (QAR 51274, SPR HPAQC0X4J) (Patch ID: OSF415-410112) ******** The multiplication of 2 single precision floating point numbers in ieee mode when the result prior to rounding is the largest denormal will cause the IEEE emulator to fail with the message: FATAL IEEE FLOATING POINT EMULATION ERROR: unf: "UNEXPECTED 2nd execution calls underflow" Compile the following program with the command: "cc -float -ieee emerror.c -o emerror": #include /* This code causes the IEEE emulator to fail with the * message indicated below: FATAL IEEE FLOATING POINT EMULATION ERROR: floating_underflow: "UNEXPECTED 2nd execution calls underflow" * The -ieee and either (-float or -std1 ) switch is imperative. * cc -ieee -float emerror.c -o emerror */ main(){ float fr,fi,gi,gr,ci; sscanf("0 80020c18 bf7fffff 80800000", "%x%x%x%x", &fr, &gi, &fi, &gr); printf("%s=%18.9e (%08x)\n","fr",fr,*(int*)&fr); printf("%s=%18.9e (%08x)\n","gi",gi,*(int*)&gi); printf("%s=%18.9e (%08x)\n","fi",fi,*(int*)&fi); printf("%s=%18.9e (%08x)\n","gr",gr,*(int*)&gr); ci = fr*gi + fi*gr; printf("%s=%18.9e (%08x)\n","ci",ci,*(int*)&ci); } Results before applying the patch: fr= 0.000000000e+00 (00000000) gi= -1.880094124e-40 (80020c18) fi= -9.999999404e-01 (bf7fffff) gr= -1.175494351e-38 (80800000) FATAL IEEE FLOATING POINT EMULATION ERROR: unf: "UNEXPECTED 2nd execution calls underflow" pc: 0xfffffc000060e368 ins: 0x20001274 op1: 0x5ad9b01a op2: 0x800000000Killed Results after applying the patch: (a kernel reboot is necessary) fr= 0.000000000e+00 (00000000) gi= -1.880094124e-40 (80020c18) fi= -9.999999404e-01 (bf7fffff) gr= -1.175494351e-38 (80800000) ci= 1.175494351e-38 (00800000) PROBLEM: (QAR 55112, QAR 55110, QAR 54413) (Patch ID: OSF415-410113) ******** This patch is in reference to BLITZ TD# 2278. This patch corrects a raw I/O data corruption problem that occurs when using database applications. The problem is seen when the new-wire-method is active. PROBLEM: (QAR 49683 QAR 47674) (Patch ID: OSF415-023) ******** This patch fixes a problem in which a system may crash if multiple bad blocks on a SCSI device are encountered simultaneously. The stack trace is as follows: 0 boot() 1 panic() 2 trap() 3 _XentMM() 4 cdisk_bbr_done() 5 cdisk_bbr_write() 6 cdisk_bbr_reassign_done() 7 cdisk_bbr_work() 8 cdisk_bbr_comp() 9 as_finish() 10 xpt_callback_thread() PROBLEM: (QAR 53003,MCPM40EQC,QAR 55150) (Patch ID: OSF415-400356) ******** This is a mandatory patch for SMP systems with AdvFS file systems. This patch fixes a performance degration problem that may occur. The problem occurs when processors try to get internal AdvFS locks. PROBLEM: (QAR 55112, QAR 55110, QAR 54413) (Patch ID: OSF415-405123) ******** This patch is in reference to BLITZ TD# 2278. This patch corrects a raw I/O data corruption problem that occurs when using database applications. The problem is seen when the new-wire-method is active. PROBLEM: (QAR 51268) (Patch ID: OSF415-029) ******** After a disk error occurs, mirror set switching may not happen soon enough to ensure high availability, or in some cases may not happen at all. The problem is that the timeout and retry mechanisms that go into action after a disk failure prevent prompt notification of LSM that there was an error. PROBLEM: (HPAQ81XSG HPAQA0S4S) (Patch ID: OSF415-400414) ******** When using msgsnd(), and sending a message with a size of zero to an invalid queue, kernel memory is corrupted. This will result in a panic with one of the two following stack traces: panic("kernel memory fault") trap() _XentMM() free() msgsnd() syscall() _Xsyscall() or panic("syscall: unexpected syscall arguments") syscall() _Xsyscall() PROBLEM: (QAR 54894, QAR 50056) (Patch ID: OSF415-400418) ******** This patch fixes a UFS file system problem. The system may panic with the following error message: panic spec_badop called The following is an example of a stack trace: Begin Trace for machine_slot[paniccpu].cpu_panic_thread: thread 0xfffffc0005a96b00 stopped at [boot:2412 ,0xfffffc000045fdd0] Source not available > 0 boot(0x0, 0xfffffc0005a96b00, 0x2c0000002c, 0x31, 0xfffffc0000000001) 1 panic(s = 0xfffffc00006dcfb0 = "spec_badop called") 2 spec_badop(0x800, 0xfffffc0004b9afb8, 0xfffffc00006dcfb0, 0xfffffc0000000000, 0xfffffc000066ad20) 3 dfs_writeop(vp = 0xfffffc0004b9ae00, uio = 0xffffffff85f5b5d0, ioflag = 0x0, cred = 0xfffffc0005998d00) 4 itrunc(oip = 0xfffffc0004b9ae00, length = 0x40000) 5 ufs_setattr(vp = 0xfffffc0004b9ae00, vap = 0xffffffff85f5b808, cred = 0xfffffc0005998d00) 6 rfs_setattr(args = 0xfffffc0002501400, ns = 0xfffffc000586c780, xprt = (nil), xpd = 0xfffffc0001013580) 7 rfs_dispatch(req = (nil), xprt = 0xfffffc0005514800) 8 nfs_rpc_recv(0x3ee219bc00000002, 0xfffffc0000000001, 0xfffffc0004fdda40, 0xfffffc0000000028, 0xfffffc0004fddd60) 9 nfs_rpc_input(0xfffffc0004fdda40, 0xfffffc0000000028, 0xfffffc0000000000, 0xfffffc0004fddbd0, 0xfffffc0000000000) 10 nfs_input(m = 0xfffffc0001094100) 11 nfs_thread() End Trace for machine_slot[paniccpu].cpu_panic_thread: PROBLEM: (QAR 56163) (Patch ID: OSF415-400420) ******** When debugging programs using Ladebug, a message having the following form may be displayed: "Stack overflow: pid ". This patch guarantees that this will not occur when a process is being traced since this problem was interfering with the Ladebug watchpoint support. PROBLEM: (MCPM905D0, QAR 56258) (Patch ID: OSF415-400421) ******** This patch fixes a potential memory leak problem that occurs when using the KMEM_DEBUG_PROTECT option of the kmem_debug tuneable attribute. PROBLEM: (IPMT 51611) (Patch ID: OSF415-400441) ******** Any multi-threaded application running on V4.0 through V4.0C of Digital UNIX can lose floating point state across calls to fork(). In instances in which this problem occurs, the floating point registers $f0-$f31 will all contain zero in the child process. To reproduce this problem, write a simple program that calls pthread_create(), have the newly created thread cause floating point state to change (e.g., just load the floating point registers with some seed values or do some floating point operations), call fork() from this thread, and look at the contents of the floating point registers (e.g., store them to an array and print them). Note that the problem manifests itself inconsistently such that the loss of floating point register contents does not occur in every instance that fork() is called from a multi-threaded program. PROBLEM: (MGO103109, QAR 55570) (Patch ID: OSF415-400442) ******** This patch fixes a problem in which core() system call would try to dump from a memory region that has no permission, cause an access violation in core() and and the core file would be unusable. An example of the problem. % file core core: core dump, core file is incomplete % dbx program core . . . . can't attach to loader: I/O error Exiting due to error during startup PROBLEM: (QAR 45510,QAR 52698) (Patch ID: OSF415-400451) ******** This patch fixes a problem with the ufs_fsck. ufs_fsck would mishandle certain dir corruptions,recursively asking the user if they want to fix it. For example: Corrupt the filesystem using fsdb. #fsdb -w /dev/rz3g >4:dir=45 >:q # Note: 4:dir=45 will change the inode number of the fourth directory entry to 45. Run ufs_fsck with -o option. #ufs_fsck -o /dev/rz3g ** /dev/rrz3g ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames DIRECTORY CORRUPTED I=2 OWNER=root MODE=40755 SIZE=512 MTIME=Dec 10 11:21 1997 DIR= SALVAGE? [yn] n Directory corruption not fixed, cannot not handle multiple errors. DIRECTORY SCAN CONTINUE? [yn] PROBLEM: (CLD MCPM60HH7) (Patch ID: OSF415-400456) ******** This patch fixes a problem of memory corruption. A TCP control structure is illegally accessed after it is released. The corrupted memory buckets are the 256-byte size. If the crash tool command "kmem -v" is run on the dump to verify the integrity of the kernel buckets, the following message is printed indicating the memory corruption: kmembuckets[4]: invalid checksum in bucket element The symptom for this problem can take many forms. In one case, threads hung in wait_for_vxlock() with the following stack trace. 0 thread_block() 1 wait_for_vxlock() ["../../../../src/kernel/vfs/vfs_subr.c":802] 2 vgetm() ["../../../../src/kernel/vfs/vfs_subr.c":2142] 3 iget() ["../../../../src/kernel/ufs/ufs_inode.c":735] 4 scandir() ["../../../../src/kernel/ufs/ufs_lookup.c"] 5 ufs_lookup() ["../../../../src/kernel/ufs/ufs_lookup.c":386] 6 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":593] 7 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":2824] 8 lstat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2808] 9 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":555] 10 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1209] PROBLEM: (QAR 57707) (Patch ID: OSF415-400461) ******** This patch fixes a problem in which the uswitch(2) system call does not work when an application tries to reset the USW_NULLP option. When this option is set, /dev/zero is mapped for read-only references at address 0, allowing subsequent user NULL pointer read references to return a zero. If the option is reset (turned off), however, the mapping is not removed, and the task's VM map's minimum virtual address is left at zero, rather than at VM_MIN_ADDRESS (0x10000). The problem may manifest itself in failures of the libaio library code. The libaio libary code maps a page in low memory, which it expects to be, at a minimum, VM_MIN_ADDRESS. However, with the returns an aio mapping address of 0. The libaio code, however, considers an address of 0 as an indication that the mapping has failed. PROBLEM: (QAR 46500,QAR 57146) (Patch ID: OSF415-400466) ******** This patch fixes a problem with the nfsd daemon. Although the maximum number of threads that nfsd can run is 128, the nfsd daemon will not start when the sum of UDP threads and TCP threads equals 128. PROBLEM: (SSRT0521U) (Patch ID: OSF415-400469) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file or privilege management. Digital has corrected this potential vulnerability. PROBLEM: (QAR 52608) (Patch ID: OSF415-405133) ******** This patch fixes a problem that occurs on AlphaServer 4100 systems. If no devices are attached to the KZPSA disk controller, the system may panic when attempting to perform I/O. This patch provides a workaround to the problem by suppressing the sending of the "verify-adapter-sanity" command until a device has been attached to the disk controller. PROBLEM: (QAR 55760, QAR 52224) (Patch ID: OSF415-405134) ******** This patch fixes an AdvFS problem in which the system may panic with the following error message: thread_block: simple lock owned PROBLEM: (QAR 56794, QAR 56787) (Patch ID: OSF415-405136) ******** This patch fixes a problem that causes the system to panic with the following error message: u_anon_free: page busy A sample stack trace is as follows: panic(s = 0xfffffc000068e158 = "u_anon_free: page busy") u_anon_free() u_anon_unmap() u_map_delete() vm_map_exit() exit() rexit() syscall() This is a MANDATORY patch if you installed the following patch from each of the following BL8 v4.0 family patch kit: v4.0 (BL8, kit #5) patch 408.00 v4.0a (BL8, kit #5) patch 370.00 v4.0b (BL8, kit #6) patch 269.00 v4.0c (BL8, kit #4) patch 228.00 PROBLEM: (Patch ID: OSF415-405145) ******** This patch provides a bugfix to avoid a panic that might result when running a mixed filesystem behind the HSZ70 Raid controller on the KZPSA-BB Fast10 Wide Differential adapter in cluster environments under Digital UNIX V4.0B, in conjunction with Version A11 KZPSA firmware or greater. PROBLEM: ( CLD MCPM911C6,MCPM911CF,USG-05807) (Patch ID: OSF415-410135) ******** This Patch provides two new procfs ioctls (PIOCUSAGE and PIOCTUSAGE) to collect task and thread wait time statistics. PROBLEM: (BRO101068/TKTR90901/QAR 55619) (Patch ID: OSF415-410122) ******** This patch fixes two kernel memory faults in networking code with the following stack traces: panic panic trap trap _XentMM _XentMM ip_output ip_output tcp_respond ip_forward tcp_timers gw_forwardscreen tcp_usrreq ip_forwardscreen tcp_slowtimo ipintr pfslowtimo netisr_thread pftimeout_thread PROBLEM: (QAR 51348) (Patch ID: OSF415-410130) ******** This patch fixes a panic that occurs when the system's message buffer size is increased to beyond the default size of 4096. During the subsequent reboot, the syslogd daemon fails with a "Segmentation fault (core dumped)" message, and creates a core file in the "/" directory. PROBLEM: (QAR 58007, QAR 59236) (Patch ID: OSF415-034) ******** This patch fixes a panic with the following error message: trap: invalid memory write access from kernel mode A sample stack trace is as follows: 1 panic() 2 trap() 3 _XentMM() 4 enqueue_tail() 5 ccmn_send_ccb3() 6 cdisk_send_ccb() 7 cdisk_strategy() 8 hwc_iomap_strategy() 9 spec_strategy() 10 call_disk() 11 bs_startio() 12 bs_q_blocking() 13 bs_q_list() 14 logflush_cont() PROBLEM: (QAR 57552, QAR 53693, QAR 53727) (Patch ID: OSF415-035) ******** This patch fixes a hang of an ASE AGENT and problems with the error recovery of the HSZ family of storage arrays. A sample of the stack trace is as follows: 0 thread_block() 1 mpsleep() 2 cdisk_op_spin() 3 cdisk_online() 4 cdisk_open() 5 spec_open() 6 vn_open() 7 copen() 8 open() 9 syscall() 10 _Xsyscall() PROBLEM: (QAR 55387, QAR 51401) (Patch ID: OSF415-036) ******** This patch fixes a problem in which the host crashes when a user tries to delete a logical unit using hszterm. The following error message can be displayed: trap: invalid memory read access from kernel mode A sample stack trace is as follows: 1 panic() 2 trap() 3 _XentMM() 4 lock_write() 5 cdisk_raid_config() 6 cdisk_raid_srvc() 7 cdisk_srvc_req() 8 cdisk_ioctl 9 spec_ioctl() 10 vn_ioctl() 11 ioctl_base() 12 ioctl() 13 syscall() 14 _Xsyscall PROBLEM: (QAR 57867, QAR 57643) (Patch ID: OSF415-405153) ******** This patch fixes a race condition whereby the pid_block() system call does not properly synchronize with signals. This problem could cause the system call to block and not take a signal when it is supposed to. PROBLEM: (QAR 56189) (Patch ID: OSF415-405155) ******** This patch fixes a data corruption problem that occurs on systems using Prestoserve. The problem may cause system panics. For example, an AdvFS system may panic with: "bad v1 frag free list". A UFS file system may panic with: "ialloc: dup alloc". PROBLEM: (QAR 57617, QAR 56924) (Patch ID: OSF415-405162) ******** This patch fixes read/write problem for buffers larger than 4GB. The read/write request would truncate to a maximum of 4GB, but return success, causing data corruption. PROBLEM: (QAR 57454, QAR 53780, QAR 54825) (Patch ID: OSF415-405177) ******** This patch improves performance on low-memory (32MB) systems. PROBLEM: (QAR 58257, QAR 48719, QAR 49229, QAR 52020) (Patch ID: OSF415-405185) ******** This patch fixes a problem with the ufs_fsck program in which filesystem corruption may occur on a running system when the root filesystem is mounted writable. PROBLEM: (QAR 56156) (Patch ID: OSF415-405198) ******** This patch corrects a problem where the NXM_IEEE_STATE_COPYIN/OUT macros need to save/restore the pcb nofault state. This was not happening. They were being called from sigsend() to capture state for a SIGFPE and wiped out sigsend()'s nofault handler. PROBLEM: (QAR 56154) (Patch ID: OSF415-405199) ******** This patch corrects a synchronization problem by blocking out hardclock before touching the state visible to the clock interrupt routine. The problem occurs when the compiler reorders the clear of the NXM_SCHED flag and then nulls out the thread's nxm_sptr and hardclock interrupts between the two reordered lines, then tries to access a NULL nxm_sptr. PROBLEM: (QAR 56153, QAR 51408) (Patch ID: OSF415-405200) ******** This patch corrects a problem in how the ps command reports its accumulated CPU time of all exited threads. The problem occurs when the u.u notation is used to retrieve these stats, not utaskp-> notation. PROBLEM: ( MCGM91LZQ, UVO105302, EVT102394 ) (Patch ID: OSF415-405206) ******** This patch fixes a problem where the umount of a filesystem will fail with "mount device busy", but no processes are accessing files in the filesystem. PROBLEM: (MCGMC1645) (Patch ID: OSF415-405207) ******** This patch fixes a kernel memory fault panic in purge_fs_locks. This problem is normally only seen on ASE or TruCluster systems. A sample stack trace may look like: 0 stop_secondary_cpu() 1 panic("event_timeout: panic request") 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic("kernel memory fault") 6 trap() 7 _XentMM() 8 purge_fs_locks() 9 fcntl() 10 syscall() 11 _Xsyscall() PROBLEM: (MXOB30447 QAR 60006) (Patch ID: OSF415-405209) ******** As an aide to debugging kernel memory corruption, this fix extends the KMEM_DEBUG_PROTECT option of kmem_debug to allow the protection of 8192-byte bucket elements while they are on the kmembucket free list. PROBLEM: (QAR 59059) (Patch ID: OSF415-405210) ******** This patch fixes a problem that occurs when KZPSA and KZTSA hardware resources needed to do I/O are unavailable causing a large number of events to be logged. The system can become sluggish and sometimes crash. This problem is seen on 8400 and 4100 systems with limited hardware scatter-gather memory resources. PROBLEM: (TKTR20675) (Patch ID: OSF415-405221) ******** This patch prevents a "kernel memory fault" in the bread() routine while performing sync operations. The stack trace will look similar to the following: 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c"] 1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c"] 2 trap() ["../../../../src/kernel/arch/alpha/trap.c"] 3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s"] 4 bread() ["../../../../src/kernel/vfs/vfs_bio.c"] 5 iupdat() ["../../../../src/kernel/ufs/ufs_inode.c"] 6 ufs_sync() ["../../../../src/kernel/ufs/ufs_vfsops.c"; 7 sync() ["../../../../src/kernel/vfs/vfs_syscalls.c"] 8 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c"] 9 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"] PROBLEM: (QAR 59319) (Patch ID: OSF415-405238) ******** This patch fixed several problems with vfs file locking that could cause a crash including the file lock adjust logic, delete sleep lock logic, dead file lock logic, check/change granted logic, and insert file lock logic. PROBLEM: (QAR 58558, QAR 60143) (Patch ID: OSF415-405243) ********* This patch fixes a problem that produces a core dump when running the quotacheck -a command. The following panic string is displayed: Segmentation fault at strcmp PROBLEM: (QAR 58388) (Patch ID: OSF415-405281) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file or privilege management. Digital has corrected this potential vulnerability. PROBLEM: (MGO103468) (Patch ID: OSF415-405292) ******** This patch fixes a "mount device busy" problem that occurs when a user cannot overwrite the file "core". This prevents the filesystem from being umount'ed. PROBLEM: (QAR 57454, QAR 53780, QAR 54825) (Patch ID: OSF415-410145) ******** This patch improves performance on low-memory (32MB) systems. PROBLEM: (QAR 56327, QAR 59459) (Patch ID: OSF415-410155) ******** This patch fixes a panic in the virtual memory management system. The system displays the following error message: trap: invalid memory read access from kernel mode The stack trace is as follows: 0 boot 1 panic 2 trap 3 _XentMM 4 vm_pageout_scan 5 vm_pageout_loop PROBLEM: (CLD MGO103458) (Patch ID: OSF415-410157) ******** This patch fixes a kernel memory fault panic. This patch is mandatory for all multiprocessor machines. The patch fixes a potential memory corruption of the akl_pagelist. PROBLEM: (QAR 36464, QAR 47097, QAR 47168, QAR 50937, QAR 60304) (Patch ID: OSF415-410158) ******** This patch fixes a problem where programs that do multiplications or divisions using or producing denormalized values would experience incorrectly rounded results. The following program (compiled with the -ieee option) demonstrates the rounding problem: ------------- test_denorm_mul.c -------------- /* compile with cc -ieee test_denorm_mul.c */ main () { long xval = 0x1e7ee00000000000; long yval = 0x2180101010101010; long zval = 0x000f7f7f7f7f7f7f; double x = *(double *)&xval; double y = *(double *)&yval; double z = *(double *)&zval; double result = x * y; if (result != z) { printf ("Denormalized rounding failed:\n"); printf(" result is %25.15lg\t%16.16lx\n", result, *(long *)&result); printf(" should be %25.15lg\t%16.16lx\n", z, *(long *)&z); } else { printf ("Passed.\n"); } } ---------- end of test_denorm_mul.c ------------ When compiled: $ cc -ieee test_denorm_mul.c and run: $ a.out a system without the patch will display: Denormalized rounding failed: result is 2.15526761980894e-308 000f7f7f7f7f7f80 should be 2.15526761980894e-308 000f7f7f7f7f7f7f After patching the system, re-running the program should display the message "Passed". Note that the accuracy degradation in the failing case can be so slight that the decimal display of the result looks like the expected value. The hexadecimal display, however, shows that the last bit was rounded incorrectly. PROBLEM: (QAR 56165) (Patch ID: OSF415-405176) ******** This patch fixes a problem in which the system may panic with the following message: simple_lock: lock already owned by cpu The stack trace is as follows: panic() ["../../../../src/kernel/bsd/subr_prf.c":707, 0xfffffc000027c08c] simple_lock_fault() ["../../../../src/kernel/kern/lock.c":2065, 0xfffffc00002a3198] simple_lock_hierarchy_violation() ["../../../../src/kernel/kern/lock.c":2124, 0xfffffc00002a32ec] mntflushbuf() ["../../../../src/kernel/vfs/vfs_bio.c":1479, 0xfffffc0000442624] boot() ["../../../../src/kernel/arch/alpha/machdep.c":2416, 0xfffffc000049753c] panic() ["../../../../src/kernel/bsd/subr_prf.c":791, 0xfffffc000027c22c] simple_lock_fault() ["../../../../src/kernel/kern/lock.c":2065, 0xfffffc00002a3198] simple_lock_state_violation() ["../../../../src/kernel/kern/lock.c":2101, 0xfffffc00002a3274] vm_anon_page_alloc() ["../../../../src/kernel/vm/vm_anonpage.c":131, 0xfffffc000046e4d0] anon_getpage() ["../../../../src/kernel/vm/vm_anon.c":417, 0xfffffc000046dbf4] u_anon_fault() ["../../../../src/kernel/vm/u_mape_anon.c":850, 0xfffffc000045d884] vl_wire() ["../../../../src/kernel/vm/vm_vlock.c":122, 0xfffffc0000480b34] u_map_wire() ["../../../../src/kernel/vm/vm_umap.c":1029, 0xfffffc000047d350] vm_map_pageable_orig() ["../../../../src/kernel/vm/vm_map.c":1321, 0xfffffc0000472b98] vm_map_pageable() ["../../../../src/kernel/vm/vm_map.c":1293, 0xfffffc0000472b04] physio() ["../../../../src/kernel/ufs/ufs_physio.c":316, 0xfffffc0000429844] ctape_read() ["../../../../src/kernel/io/cam/cam_tape.c":3658, 0xfffffc00004e1730] spec_read()["../../../../src/kernel/vfs/spec_vnops.c":1880, 0xfffffc0000439198] ufsspec_read() ["../../../../src/kernel/ufs/ufs_vnops.c":3628, 0xfffffc0000432e70] vn_read() ["../../../../src/kernel/vfs/vfs_vnops.c":876, 0xfffffc000045a2bc] rwuio() ["../../../../src/kernel/bsd/sys_generic.c":1501, 0xfffffc000028b9b0] read() ["../../../../src/kernel/bsd/sys_generic.c":1451, 0xfffffc000028b8c0] syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":540, 0xfffffc000049d360] _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1209, 0xfffffc00004933e4] PROBLEM: (UVO105930/QAR 59429) (Patch ID: OSF415-405229) ******** This patch fixes a kernel memory fault in the networking code with the following stack trace: panic trap _XentMM ip_output ip_forward gw_forwardscreen ip_forwardscreen ip_dooptions ipintr netisr_thread PROBLEM: (QAR 58740) (Patch ID: OSF415-410156) ******** This patch fixes an AdvFS response time problem that occurred when an application with many random access reads of many files was being slowed down by the resulting number of writes to disk. To fix the problem, there are three new features: o atimes and noatimes options are added to the mount -o option list for AdvFS file systems o the read system call has additional code to perform the operation requested by the noatimes option o a configurable parameter, AdvfsPreallocAccess, for tuning the number of access structures in the freelist at startup The AdvFS mount option noatimes changes AdvFS behavior for regular files in the specified fileset. AdvFS updates the file access time in memory on a read system call from a regular file, but does not write the stat structure for the file with the new access time out to disk until some other file modification is made. After a file is closed (and when the fileset is unmounted), the in memory updated access time can be lost. Therefore, this mount noatimes option should not be used in conjunction with utilities or applications which gather statistics or make decisions based on file access times, such as migrating unaccessed files to slower backing storage. PROBLEM: (QAR 56151) (Patch ID: OSF415-032) ******** This patch fixes a problem where during tape operations, the SPACE commands can not be interrupted. PROBLEM: (QAR 55173, QAR 57577 ) (Patch ID: OSF415-037) ******** This patch fixes a problem in which a system panics with a "kernel memory fault" error message. The problem occurs when a tape drive is plugged into the slot previously occupied by a disk. 0 boot(0x0, 0xfffffc00029bb080, 0x2c0000002c, 0x2d, 0x1) ["../../../../src/kernel/arch/alpha/machdep.c":2530, 0xfffffc000046ecd4] 1 panic(s = 0xfffffc00007ca420 = "kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":791, 0xfffffc000028608c] 2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1492, 0xfffffc0000476520] 3 _XentMM(0x4, 0xfffffc0000517280, 0xfffffc0000854ec0, 0x88, 0x35) ["../../../../src/kernel/arch/alpha/locore.s":1392, 0xfffffc000046b294] 4 ctape_open(devt = 0x0, flags = 0x0, fmt = 0x0) ["../../../../src/kernel/io/cam/cam_tape.c":1496, 0xfffffc000051727c] 5 spec_open(0x15, 0xffffffff80808001, 0x0, 0xfffffc0000904403, 0xfffffc0000904403) ["../../../../src/kernel/vfs/spec_vnops.c":1406, 0xfffffc000041095c] 6 vn_open(0xffffffff854538e0, 0xffffffff854538f0, 0x0, 0xffffffff85453d48, 0x100000003) ["../../../../src/kernel/vfs/vfs_vnops.c":613, 0xfffffc00004321dc] 7 copen(0xfffffc00008524d0, 0xfffffc000119ca80, 0x1, 0x100000003, 0xfffffc0002a40280) ["../../../../src/kernel/vfs/vfs_syscalls.c":2328, 0xfffffc000042583c] 8 open(0x1, 0x100000003, 0xfffffc0002a40280, 0x21, 0xfffffc0000474374) ["../../../../src/kernel/vfs/vfs_syscalls.c":2267, 0xfffffc0000425720] 9 syscall(0x1, 0x1260, 0x27ef35266c31, 0x3ff800d2e88, 0x2d) ["../../../../src/kernel/arch/alpha/syscall_trap.c":549, 0xfffffc0000474370] 10 _Xsyscall(0x8, 0x3ff800d1a48, 0x140009030, 0x11ffff556, 0x8000) ["../../../../src/kernel/arch/alpha/locore.s":1177, 0xfffffc000046b084] End Trace for machine_slot[paniccpu].cpu_panic_thread: PROBLEM: (QAR 60251, QAR 59705) (Patch ID: OSF415-039) ******** This patch corrects a problem where the code around referencing a tape device pointer is not synchronized and a kernel memory fault results. PROBLEM: (QAR 59840) (Patch ID: OSF415-048) ******** Under certain conditions, the message "ctape_strategy: READ case and density info not valid." was being printed for every read from tape. This change will print the message only once. PROBLEM: (QAR 55126, QAR 52313) (Patch ID: OSF415-405189) ******** This patch corrects a problem in memory allocation where a tasks resident count could become inconsistent, causing a panic. A sample output from a panic would look like: 5 panic(s = 0xfffffc0000583a08 = "simple_lock: time limit exceeded") 6 simple_lock_fault() 7 simple_lock_time_violation() 8 vm_page_stealer() 9 vm_pg_alloc() 10 malloc_thread() or 5 panic(s = 0xfffffc0000583a08 = "simple_lock: time limit exceeded") 6 simple_lock_fault() 7 simple_lock_time_violation() 8 vm_ops_reference_def() 9 vm_map_clip_start() 10 k_mem_entry_adjust() 11 k_mem_lockop() 12 k_map_wire() 13 vm_map_pageable_orig() 14 vm_map_pageable() 15 thread_swapout() 16 task_swapout() 17 task_swapout_thread() PROBLEM: (QAR 56172, QAR 55808, QAR 66453) (Patch ID: OSF415-405190) ******** This patch fixes the following problems: 1. Process hangs caused by file references on raw devices accesses not being held. The patch uses locks on references and the unreferences so the file won't be prematurely closed. 2. A "kernel memory fault" system panic caused by AIO not cleaning up test headers when processes exit. This can cause signals to be sent to incorrect processes and/or system crashes. An example of system panic stack trace is as follows: 1 panic() 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic() 6 trap() 7 _XentMM() 8 sigq_enqueue_tail() 9 psignal_internal() 11 aio_transfer_done() 12 syscall() 13 _Xsyscall() PROBLEM: (QAR 59562, QAR 60399) (Patch ID: OSF415-405259) ******** This patch fixes a problem with the vmstat -M command. vmstat -M shows an invalid byte count associated with the FREE malloc type. PROBLEM: (QAR 60175) (Patch ID: OSF415-405268) ******** This patch corrects a problem where a flag, TF_PSUSP, was not being cleared. PROBLEM: (QAR 59773, QAR 55941, QAR 56416) (Patch ID: OSF415-405269) ******** This patch fixes a problem that produced a deadlock betweeen process threads. Typically, the deadlock caused the msfs_getpage routine to wait forever for a lock to be released. Here are examples of stack traces: 0 thread_block() 1 lock_read() 2 msfs_getpage() 3 u_vp_fault() 4 u_map_fault() 5 vm_fault() 6 trap() 7 _XentMM() Stack trace of a thread: 0 thread_block() 1 lock_read() 2 ufs_fsync_int() 3 ufs_fsync() 4 fsync() 5 syscall() 6 _Xsyscall() Stack trace where the thread is servicing a ufs_write request that calls ufs_rwip and requests a page that needs to be faulted in: 0 thread_block() 1 lock_read() 2 u_map_fault() 3 vm_fault() 4 trap() 5 _XentMM() Stack trace of a thread: 0 thread_block() 1 ubc_clean_free() 2 ubc_msync() 3 u_vp_msync() 4 u_map_control() 5 msync() 6 syscall() 7 _Xsyscall() PROBLEM: (BCPM419F2) (Patch ID: OSF415-405276) ******** This corrects a problem that causes a "pmap_ssm_destroy: wired pages" crash. PROBLEM: (MGO103472) (Patch ID: OSF415-405277) ******** This corrects a performace problem with posix timers. PROBLEM: (HPAQ41QK2) (Patch ID: OSF415-405278) ******** A problem in the msgsnd() routine can result in a kernel memory fault panic if the message size is zero. The following is a representative stack trace: 0 boot 1 panic(s = 0xfffffc000059c960 = "kernel memory fault") 2 trap() 3 _XentMM 4 free_common 5 free 6 msgsnd 7 syscall 8 _Xsyscall PROBLEM: (SSRT0536U) (Patch ID: OSF415-405287) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file or privilege management. Digital has corrected this potential vulnerability. PROBLEM: (ISO100398, STLB35453) (Patch ID: OSF415-405289) ******** This patch fixes a networking problem that occurs when the kernel variable ipport_userreserved is set to 65535. PROBLEM: (HPAQ81XSG) (Patch ID: OSF415-405293) ******** A problem in the msgsnd() routine can result in a kernel memory fault panic if the message size is zero. Or could corrupt the sysent entry for msgsnd() resulting in a "syscall: unexpected syscall arguments" panic the next time msgsnd() is called. A representative stack trace might contain: 0 boot(0x0, 0xfffffc0000c10840, 0x2c0000002c, 0x2c, 0x1) 1 panic(s = 0xfffffc000059c960 = "kernel memory fault") 2 trap() 3 _XentMM(0x5, 0xfffffc0000261458, 0xfffffc00005bfbc0, 0x0, 0xfffffc000075636) 4 free_common(va = 0xfffffc0000566208, size = 0xfffffc0000756360, p = 0xfffffc00006e3a00, caller = (nil)) 5 free(addr = 0xfffffc0000566208) 6 msgsnd(0x1, 0xfffffc0001e28ca0, 0xffffffff8352b8e0, 0x0, 0x100000000) 7 syscall(0x0, 0x0, 0x81630354633a0, 0x3ff800f66a0, 0xcb) 8 _Xsyscall(0x8, 0x3ff8010c7d8, 0x140008340, 0x0, 0x140002000) or 0 stop_secondary_cpu(do_lwc = 0x0) ["../../../../src/kernel/arch/alpha/cpu.c" 1 panic(s = 0xfffffc00005b5508 = "event_timeout: panic request") ["../../../. 2 event_timeout(func = 0xfffffc00002801a0, arg = 0xfffffc0000615b00, timeout 3 xcpu_puts(s = 0xfffffc00005eb760, prfbufp = 0xfffffc0000615b00) ["../../../ 4 printf(va_alist = 0xfffffc0000585fc8) ["../../../../src/kernel/bsd/subr_prf 5 panic(s = 0xfffffc00005b7fa0 = "syscall: unexpected syscall arguments") [". 6 syscall(0x1000, 0x0, 0xe0681343e506e, 0x3ff800d2f04, 0xcb) ["../../../../sr 7 _Xsyscall(0x8, 0x3ff8010c710, 0x1400084c0, 0x100000, 0x11fffece0) ["../../. PROBLEM: (HPAQ205WQ/QAR 58962) (Patch ID: OSF415-405299) ******** This patch prevents a system panic from m_copym(). A priviledged program or user that uses raw ip sockets can crash the system by passing an invalid ip header from ip_output(). The stack trace looks like this: panic() m_copym() ip_output() rip_output() raw_usrreq() rip_usrreq() sosend() PROBLEM: (QAR 56252,QAR 52796) (Patch ID: OSF415-405302) ******** This patch fixes a problem in which a a cluster member panics, when the Production Server or Available Server software attempts to relocate a tape service. This panic originates from CAM function cam_strategy(). PROBLEM: (CLD DEKB10974) (Patch ID: OSF415-405305) ******** This patch avoids a "kernel memory fault" panic from sigsgdisp(). The problem has only been seen when shutting down an Oracle database. A sample stack trace is shown in the following example: 5 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":753] 6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1539] 7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1424] 8 sigsgdisp() ["../../../../src/kernel/bsd/kern_sig.c":1471] 9 sigaction() ["../../../../src/kernel/bsd/kern_sig.c":1706] PROBLEM: (QAR 60378) (Patch ID: OSF415-405307) ******** This patch fixes a problem with memory being wasted by Mach IPC kernel message routines because they were assigned fixed sizes of memory (large or small, depending on the routine). Now, the memory allocation for the IPC routines has been changed to allocate only the memory each routine requires. PROBLEM: (QAR 59878, QAR 53422) (Patch ID: OSF415-405325) ******** This patch fixes a problem within LMF. The LMF user license list (OSF-BASE or OSF-USR) was not being decremented when a logout occurred. This occurs on systems with C2 security enabled and the system setup as a DCE Security server. PROBLEM: (QAR 61665) (Patch ID: OSF415-405328) ******** This patch corrects a small accounting problem where the measured time for a process was an integral rather than mean value. The calculation was changed to reflect this discrepency. This change also had to be reflected in the acctcom and acctcms commands. PROBLEM: (QAR 59255) (Patch ID: OSF415-405330) ******** This patch corrects a problem that would randomly cause kloadsrv(8) to crash and improperly load/unload modules. PROBLEM: (QAR 47111 QAR 58034 QAR 60575) (Patch ID: OSF415-405335) ******** The first problem occurs when a failed (hardware or driver failure) KZPSA adapter panics the kernel. You will observe this problem when the failed adapter generates a miscellaneous error continuously, eventually causing a kernel panic with messages similar to the following: KZPSA adapter misc error, asr=0x4, afar=0x4a03f158, afpr=0x20311 pzaintr: KZPSA adapter misc error, asr=0x4, afar=0x4a03f158, afpr=0x20311 This patch causes the system to check for a failed device before allocating dma resources, preventing the panic. The second problem is that the SIMPORT code returns I/O with a CAM status of "NO HBA" when a miscellaneous adapter error occurs. This CAM status is incorrect since the adapter is re-initialized. The correct CAM status for such as condition is "CAM BUSY". The "NO HBA" status is only returned when the adapter can not recover from the error (The re-initialization failed). PROBLEM: (QAR 59418) (Patch ID: OSF415-405340) ******** This patch changed the sbcompress_threshold type to unsigned from signed since you could not set the sysconfig value for this flag correctly. PROBLEM: (QAR 61738) (Patch ID: OSF415-405345) ******** This patch fixes a problem that caused the system to panic with the string "kernel memory fault". PROBLEM: (HPAQ60SQH) (Patch ID: OSF415-405348) ******** This patch fixes a problem in which the system can panic with "kernel memory fault". A typical stack trace shows: boot panic trap _XentMM lock_holder socket_send ip_mforward ipintr netisr_thread This patch fixes a problem in which the system can panic with "lock_write: lock already owned by thread". A typical stack trace shows: boot panic lock_fault lock_write solock socket_send ip_mforward ip_output rip_output raw_usrreq rip_usrreq sosend sendit sendto syscall _Xsyscall PROBLEM: (SSRT0537U) (Patch ID: OSF415-405352) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file or privilege management. Digital has corrected this potential vulnerability. PROBLEM: (UVO105982/MGO103521/QAR 60902) (Patch ID: OSF415-405355) ******** This patch fixes a TCP/IP performance problem in the tcp_reass() function. How to recognize this problem: Profiling the kernel indicates that the tcp_reass() function is consuming all the CPU time. Here is an example using the prof(1) utility sorted in descending order by total time spent in each procedure. Each sample covers 16.00 byte(s) for 4.1e-05% of 547.8574 seconds. %time seconds cum % cum sec procedure (file) 41.8 228.7463 41.8 228.75 tcp_reass () 6.2 33.8050 47.9 262.55 simple_lock () 4.1 22.3743 52.0 284.93 seq_search () 2.9 15.8696 54.9 300.80 pmap_copy_page () 2.2 12.0934 57.1 312.89 nofault_bcopy () 2.1 11.4539 59.2 324.34 simple_unlock () 1.7 9.4755 60.9 333.82 pmap_zero_page () 1.4 7.6839 62.3 341.50 cache_lookup () 1.3 6.8637 63.6 348.37 syscall () 0.8 4.2692 64.4 352.63 hardclock () 0.7 4.0988 65.1 356.73 _XentInt () 0.7 3.6025 65.8 360.34 _OtsMove () 0.6 3.4876 66.4 363.82 malloc () 0.6 3.4701 67.0 367.29 free () 0.6 3.0403 67.6 370.33 tcp_input () PROBLEM: (QAR 59926) (Patch ID: OSF415-405356) ******** This patch removes extraneous debug code. PROBLEM: (QAR 62045) (Patch ID: OSF415-405357) ******** This patch fixes a problem in which the system can panic with the message "kernel memory fault". The stack trace is as follows: 5 panic src/kernel/bsd/subr_prf.c : 753 6 trap src/kernel/arch/alpha/trap.c : 1539 7 _XentMM src/kernel/arch/alpha/locore.s : 1424 8 pmap_seg_tbsync src/kernel/arch/alpha/pmap.c : 4996 9 pmap_clear_reference src/kernel/arch/alpha/pmap.c : 3873 10 ubc_page_stealer src/kernel/vfs/vfs_ubc.c : 1681 11 vm_pageout_loop src/kernel/vm/vm_pagelru.c : 680 12 vm_pageout src/kernel/vm/vm_pagelru.c : 1265 PROBLEM: (TKTR61501) (Patch ID: OSF415-405362) ******** This patch fixes a system panic "rtfree 2". This problem can be encountered on multi-cpu systems and has the following stack trace: boot panic rtfree ip_output tcp_respond tcp_timers tcp_usrreq tcp_slowtimo pfslowtimo pftimeout_thread PROBLEM: (QAR 58800, QAR 59115, QAR 58440) (Patch ID: OSF415-405363) ******** This patch fixes a problem with the "vmstat -M" command. This command displays negative values for memory usage by type and AdvFS buffer usage. PROBLEM: (QAR 61938, QAR 58566) (Patch ID: OSF415-405364) ******** This patch fixes a problem in which a recursive panic occurs during certain lockmode violations. The stack trace is listed below: 1 lock_write() 2 handler_id_verify() 3 handler_disable() 4 mchan_disable_interrupts() 5 Mchan_shutdown() 6 drvr_shutdown() PROBLEM: (QAR 60865) (Patch ID: OSF415-405366) ******** The bufpages calculation fails to take granularity hints into account. On systems that pre-allocate large percentages of physical memory to granularity hints, the bufcache calculation allocates an inordinately large amount of physical memory for the buffer cache in relation to the actual memory being used by the operating system. PROBLEM: (QAR 57579) (Patch ID: OSF415-405368) ******** Asynchronous I/O can fail when the number of aio requests is allowed to exceed 64K. PROBLEM: (QAR 59863, QAR 59323) (Patch ID: OSF415-405371) ******** This patch fixes a problem that was caused by both floating point and integer overflow exceptions setting the si_code member in the siginfo structure to FPE_FLTOVF. Integer overflow exceptions should set the si_code member to FPE_INTOVF, as documented in siginfo(5). PROBLEM: (QAR 62353, QAR 61253) (Patch ID: OSF415-405378) ******** This patch fixes a problem with NFS conversion of a file's vnode number to a file handle number. When a SUN client accessed files on a DIGITAL UNIX server, the file id was truncated immproperly during the conversion, generating EOVERFLOW errors. As a result, a NFS client was receiving EOVERFLOW errors. PROBLEM: (QAR 52898) (Patch ID: OSF415-405383) ******** If a system has more than 2 gigabytes of memory, and full dumps are enabled, savecore may incorrectly report that a negative number of bytes was written to the crash dump. For example: The system is coming up. Please wait... Checking for crash dumps System went down at Tue May 6 08:20:30 1997 Saving -532480 bytes of image in vmcore.2 Only the report text is incorrect, and the correct number of bytes are saved in the crash dump. PROBLEM: (QAR 62611) (Patch ID: OSF415-405384) ******** This patch corrects a potential boot panic problem by limiting the size of the bufcache. PROBLEM: (QAR 55421, QAR 55783) (Patch ID: OSF415-405392) ******** This patch fixes the following two problems that occur on an NFS file server using a Network Appliance server: o New files may not be listed in directory reads. For example, when the ls command is used not all the files may be listed. o When a directory listing is requested from a Network Appliance server, more data than was requested may be returned and the extra data is lost by the Digital UNIX client. The problem can be seen when using the ls command; not all the files on the server are listed. PROBLEM: (QAR 62831,QAR 62627) (Patch ID: OSF415-405394) ******** This patch fixes a virtual memory problem in which an uninitialized pointer in u_dev_protect() causes a kernel memory fault to occur. Here's the stack trace: ---------------------- > 0 boot(0x0, 0x0, 0xfffffc0000777ab0, 0xd, 0x0) ["../../../../src/kernel/arch/alpha/machdep.c":1795 , 0xfffffc000045ed5c] 1 panic(s = 0xfffffc0000777ab0 = "kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":7 57, 0xfffffc000041ce84] 2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1243, 0xfffffc000046d934] 3 _XentMM(0x0, 0xfffffc0000366380, 0xfffffc0000888740, 0x0, 0x190) ["../../../../src/kernel/arch/a lpha/locore.s":1307, 0xfffffc000045be24] 4 u_dev_protect(0xfffffc000b3a4b40, 0xfffffc0000000000, 0xfffffc0000000001, 0xffffffff00000003, 0x ffffffff00000020) ["../../../../src/kernel/vm/u_mape_dev.c":602, 0xfffffc000036637c] 5 u_map_protect(0xfffffc000b3a4b40, 0xfffffc000bf30900, 0x38000, 0x3, 0xffffffff8bd178b8) ["../../ ../../src/kernel/vm/vm_umap.c":1378, 0xfffffc000037a35c] 6 vm_map_protect(0x38000, 0x3, 0xffffffff8bd178b8, 0xffffffff8bd17768, 0xfffffc000037d024) ["../.. /../../src/kernel/vm/vm_map.c":1295, 0xfffffc000036f3f4] 7 vm_protect(0xffffffff8bd178b8, 0xffffffff8bd17768, 0xfffffc000037d024, 0xfffffc000bf30900, 0xfff ffc000040d050) ["../../../../src/kernel/vm/vm_user.c":206, 0xfffffc000037d020] 8 mprotect(0xfffffc000304e210, 0xffffffff8bd17758, 0xffffffff8bd178b8, 0x1, 0x0) ["../../../../src crash-data.1 (61%) /kernel/bsd/kern_mman.c":879, 0xfffffc000040d04c] 9 syscall(0x3ffc0093530, 0x1, 0x1, 0x0, 0x4a) ["../../../../src/kernel/arch/alpha/syscall_trap.c": 527, 0xfffffc000046c72c] 10 _Xsyscall(0x8, 0x3ff801588d8, 0x140008120, 0x24000, 0x14000) ["../../../../src/kernel/arch/alpha /locore.s":1094, 0xfffffc000045bc14] End Trace for machine_slot[paniccpu].cpu_panic_thread: PROBLEM: (QAR 62531) (Patch ID: OSF415-405397) ******** This patch fixes a virtual memory problem that may cause a system to panic with one of the following messages: "pmap_begin_mutex_region timeout" or "simple_lock timeout". PROBLEM: (QAR 62356) (Patch ID: OSF415-405404) ******** This patch fixes a problem in the kernel that caused dynamically loaded PCI/ISA drivers to crash the syttem with the following panic: kernel memory fault The problem would occur only when a device was loaded after it had been previously (and successfully)loaded and unloaded. A sample stack trace for an ISA driver is: 0 boot 1 panic 2 trap 3 _XentMM 4 strcmp 5 get device 6 isa_driver_configure 7 configure_driver ...and the trap: trap: invalid memory read access from kernel mode faulting virtual address: 0xfffffffffffffffe pc of faulting instruction: 0xfffffc00003bdf54 ra contents at time of fault: 0xfffffc00003dbad0 sp contents at time of fault: 0xffffffff881764e0 A sample stack trace for a PCI driver is: 0 boot 1 panic 2 trap 3 _XentMM 4 strcmp 5 get_device 6 pci_driver_configure 7 configure_driver ...and the trap: trap: invalid memory read access from kernel mode faulting virtual address: 0xfffffffffffffffc pc of faulting instruction: 0xfffffc00003af944 ra contents at time of fault: 0xfffffc00003cd4c0 sp contents at time of fault: 0xffffffff821f2870 PROBLEM: (QAR 63231) (Patch ID: OSF415-405416) ******** This patch resolves systems from hanging during boot. Disabling CRD interrupts during boot caused PAL to NOT deliver the interrupt to the OS and therefore NOT clear the error, so a infinite recursion interrupt hang results. This patch is MANDATORY for all hardware platforms. PROBLEM: (QAR 59246, QAR 59884) (Patch ID: OSF415-405426) ******** This patch fixes a problem in which the sysconfig command produces an error when a subsystem name of 15 characters is used. The following error message is displayed: framework error : copying memory to / from kernel PROBLEM: (CLDs BRO101153, BCGM40N88, QAR 59145 (Patch ID: OSF415-405429) ******** A flaw in NFS client operation can result in a KMF panic with a stack trace such as: 1 panic(s = 0xfffffc00005d5420 = "kernel memory fault" 2 trap() 3 _XentMM 4 ubc_flush_dirty 5 mntflushbuf 6 nfs_sync 7 sync 8 syscall 9 _Xsyscall PROBLEM: (MGO103468) (Patch ID: OSF415-405430) ******** This patch fixes various problems caused when a set UID/GID program dumped core. The problems included system panics and "mount device busy" errors when trying to umount the filesystem. A typical stack trace for the panic thread would have the routine core() in it. PROBLEM: (QAR 62104) (Patch ID: OSF415-405431) ******** This patch corrects a problem that can result in a kernel memory fault during heavy SCSI I/O, particularly on a small-memory system. The crash dump stack may look similar to the following: 0 boot src/kernel/arch/alpha/machdep.c : 2294 1 panic src/kernel/bsd/subr_prf.c : 1225 2 trap src/kernel/arch/alpha/trap.c : 1824 3 _XentMM src/kernel/arch/alpha/locore.s : 2074 4 malloc_internal src/kernel/bsd/kern_malloc.c : 1452 5 malloc src/kernel/bsd/kern_malloc.c : 1235 6 pmap_create src/kernel/arch/alpha/pmap.c : 2107 7 vm_map_fork src/kernel/vm/vm_map.c : 2510 8 task_create src/kernel/kern/task.c : 545 9 procdup src/kernel/vm/vm_unix.c : 764 10 newproc src/kernel/bsd/kern_fork.c : 812 11 fork1 src/kernel/bsd/kern_fork.c : 642 12 fork src/kernel/bsd/kern_fork.c : 567 13 syscall src/kernel/arch/alpha/syscall_trap.c : 670 14 _Xsyscall src/kernel/arch/alpha/locore.s : 1779 PROBLEM: (QAR 62299, QAR 51568, HPAQ60W1F, QAR 62617, QAR 62610, UVO106018, QAR 61185, QAR 63686, QAR 63703, QAR 54276, QAR 60262) (Patch ID: OSF415-405434) ******** This patch fixes the following problems in AdvFS: 1. A operating system hang condition. The hang condition exists due to processes deadlocking in the AdvFS code. 2. AdvFS does not return an error when a user opens a file in O_SYNC mode and power is lost on the disk drive. 3. A locking error in the AdvFS fs_write() routine. PROBLEM: (QAR 54309) (Patch ID: OSF415-405443) ******** This patch fixes a problem with the KZPSA and KZTSA SCSI adapters. The adapters will hang if the SCSI cable is disconnected from them. PROBLEM: (BCGM70W61, UVO105916) (Patch ID: OSF415-405448) ******** This patch fixes a problem when a setuid program exec's and the message "privileges disabled because of outstanding IPC access to task". PROBLEM: (BCPM80CMQ) (Patch ID: OSF415-405450) ******** This fixes a kernel memory fault panic in cansignal(). An example stack trace follows: panic() trap() _XentMM() cansignal() sigsend1() sigsend1() sigsendset() syscall() _Xsyscall() PROBLEM: (QAR 59953, QAR 59419) (Patch ID: OSF415-410159) ******** This patch fixes a problem that occurs on AdvFS systems. The system will panic with the following error message: malloc_overflow: guard space corruption A sample stack trace is as follows: 6 panic() 7 malloc_debug() 8 free() 9 _ms_free() 10 free_dmntbl_setname() 11 msfs_real_syscall() 12 msfs_syscall() 13 syscall() 14 _Xsyscall() PROBLEM: (QAR 49649) (Patch ID: OSF415-410164) ******** This patch fixes the problem in which a DIGITAL UNIX system can randomly panic when more than 255 network interfaces are configured. The network interfaces may be ATM LIS's (classical IP), Internet tunnels, and other "software interfaces", as well as hardware interfaces. A typical stack trace looks as follows. 1 panic("kernel memory fault") 2 trap() 3 _XentMM() 4 if_attach() 5 itnopen() 6 spec_open() 7 vn_open() 8 copen() 9 open() 10 syscall() 11 _Xsyscall() PROBLEM: (QAR 59849, QAR 58696) (Patch ID: OSF415-410167) ******** This patch fixes a problem when a processor is commanded to stop during a heavy load but does not actually halt. PROBLEM: (QAR 57323) (Patch ID: OSF415-410170) ******** This patch corrects a problem seen with DECthreads tests that use fork(2). The problem is a race condition in the anonymous memory code that handles COW but releases the anon lock before calling pmap_enter(). PROBLEM: (QAR 56793) (Patch ID: OSF415-410176) ******** This patch corrects a potential problem in the handling of a ieee_get_state_at_signal(3) C-library call. PROBLEM: (EVT102538, EVT102513, QAR 60321) (Patch ID: OSF415-410178) ******** This patch fixes a problem that occurs with applications based on POSIX message queues. During certain high activity periods, processes may hang when trying to access the message queue. A sample stack trace is as follows: 0 thread_block 1 mpsleep 2 psx4_csem_sleep_wakeup 3 syscall 4 _Xsyscall PROBLEM: (SQO100495) (Patch ID: OSF415-410182) ******** This corrects a simple lock timeout problem in several vm_page routines. PROBLEM: (TKTR61501/QAR 60709) (Patch ID: OSF415-410187) ******** This patch fixes two Kernel Memory Faults in Digital Unix Path MTU discovery code. A typical stack trace will look like this: 0 thread_block 1 thread_preempt 2 boot 3 panic 4 rtfree 5 ip_forward 6 gw_forwardscreen 7 ip_forwardscreen 8 ip_dooptions 9 ipintr 10 netisr_thread PROBLEM: (QAR 59847) (Patch ID: OSF415-410189) ******** This patch prevents a kernel malloc leak when changing the protection of a System V shared memory region that uses gh-chunks. PROBLEM: (QAR 58232, QAR 51839) (Patch ID: OSF415-410193) ******** This patch fixes a problem with the CPU auto_action console environment variable. If the auto_action console environment variable is set to BOOT or RESTART, when the CPU is to be stopped, the processor immediately boots and the user can not observe that the CPU had halted. PROBLEM: (QAR 60725) (Patch ID: OSF415-410194) ******** This patch fixes a problem in the AdvFS logging code. The way locking was implemented was causing degraded performance. PROBLEM: (QAR 59621) (Patch ID: OSF415-410195) ******** This patch fixes a problem with the vmstat -P command, which was incorrectly formatting output. PROBLEM: (HGOQ40195) (Patch ID: OSF415-410196) ******** This patch fixes a system panic caused by a multithreaded process with profiling turned on. The system panics with the following message: "lock_terminate: lock held" An example stack trace is: 5 panic src/kernel/bsd/subr_prf.c : 796 6 lock_terminate src/kernel/kern/lock.c : 544 7 proc_delete src/kernel/bsd/kern_exit.c : 1955 8 task_deallocate src/kernel/kern/task.c : 598 9 waitf src/kernel/bsd/kern_exit.c : 1668 10 wait4 src/kernel/bsd/kern_exit.c : 1456 11 syscall src/kernel/arch/alpha/syscall_trap.c : 615 12 _Xsyscall src/kernel/arch/alpha/locore.s : 1409 PROBLEM: (QAR 62959, QAR 62942) (Patch ID: OSF415-410203) ******** This patch fixes a problem with user stack pointers not being saved properly in kernel crash dumps for running threads. PROBLEM: (SSRT0559U) (Patch ID: OSF415-410206) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file or privilege management. Digital has corrected this potential vulnerability. PROBLEM: (QAR 61638) (Patch ID: OSF415-410208) ******** This patch fixes a problem with the way the ps utility collected CPU usage information. One effect of the problem was that processes run with nice values of 18 or greater had contention problems based on the incorrect CPU values. PROBLEM: (CLD MGO103598 QAR 53616) (Patch ID: OSF415-410213) ******** Fixes a bug in which the contiguous memory allocator uses physmem to calculate percentage of memory to reserve. On a system with memory holes, this results in reserving non-existent pages for contiguous memory. Although they will never be used the incorrect accounting results in the bogus available memory message. PROBLEM: (QAR 61716,QAR 56648) (Patch ID: OSF415-044) ******** This patch fixes an ASE NFS problem that occurs on ASE systems with KZPBA disk controllers. The system crashes with a "simple_lock timeout" panic. ASE NFS services send the aseagents for most or all nodes into an uninterruptable state: root@scully:/ > ps -elf |grep aseagent 8001 U < 0 318 1 0.0 39 -5 1.7M 3abf3580 16:02:21 0:00.58 /usr/sbin/aseagent -b -p hsm 80808001 S + 0 7566 6128 0.0 44 0 136K 3fe83894 08:04:42 0:00.0 0 A sample stack trace is as follows: > 0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":2113,] 1 mpsleep() ["../../../../src/kernel/bsd] 2 cdisk_online(type_open = 0) ["../../../../src/kernel/io/cam/cam_disk.c":6769] 3 cdisk_open() ["../../../../src/kernel/io/cam/cam_disk.c":6269] 4 spec_open() ["../../../../src/kernel/vfs/spec_vnops.c":14] 5 vn_open() ["../../../../src/ker] 6 copen() ["../../] 7 open() ["../../../../src/kerne] 8 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":] 9 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1209,]