NOTE: This is a MANDATORY patch. PROBLEM: (HPXQ43C4D, TKTR52185, QAR 46016) (Patch ID: OSF410-039) ******** 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: OSF410-034) ******** 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: OSF410-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: OSF410-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: (HPAQ92E5E, TKTR90455, QAR 49011) (Patch ID: OSF410-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: OSF410-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: OSF410-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: OSF410-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, USG-04543) (Patch ID: OSF410-052) ******** 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, QAR 51700) (Patch ID: OSF410-059) ******** 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: OSF410-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: OSF410-062) ******** 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: (QAR 49818) (Patch ID: OSF410-400127) ******** System panics with message: "vm_map_swapout: negative resident count". The crash will most likely occur on a multiprocessor system during a heavy paging load. panic("vm_map_swapout: negative resident count") vm_map_swapout() task_swapout() task_swapout_thread() PROBLEM: (MCPMB7DEJ, QAR 50938) (Patch ID: OSF410-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_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: (QAR 51161, 51813) (Patch ID: OSF410-063) ******** This patch corrects problems encountered when using signals with multithreaded programs. Specifcally, three problem may be encountered, all of them usually resulting in an application hang: 1. Missed thread-specific signals. These are signal sent via the pthread_kill() function. Under extremely intensive use, a signal sent by pthread_kill() can be lost. This will usually manifest itself as an application hang, as expected signal goes unreceived. 2. Inconsistent compute-bound hangs in the libpthreads.so. Typically, a stack trace for such a hang would have the following mutex-related frames at the top of its stack: 0 pthread_mutex_unblock() 1 __pthread_mutex_unlock() 2 (unknown)() 3 free() . . . The frames below the mutex frames could be any routine that calls pthead_mutex_unlock(). 3. Unexpected error return from system calls. When using process-level signals, certain system calls may return unexpectedly with an EINTR error without a signal actually having been delivered. Typcial victims of this problem are are the sigwait() and read() functions. Particularly in the case of read(), an application is likely to reissue the system call without noticiing the error, resulting in a compute-bound loop. PROBLEM: (EVT101963, QAR 52024) (Patch ID: OSF410-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: (QAR 50693, 49421) (Patch ID: OSF410-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: (EVT101664) (Patch ID: OSF410-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: (HPAQC07YV) (Patch ID: OSF410-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: OSF410-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: (MCPMA986D) (Patch ID: OSF410-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. Refer to the man page for dbx for guidelines when using the dbx command. PROBLEM: (ZUO101015, QAR 49750) (Patch ID: OSF410-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: (MCPMB04E3) (Patch ID: OSF410-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: OSF410-049) ******** 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: OSF410-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: (MCPMB04E3) (Patch ID: OSF410-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: (MCPM3028N) (Patch ID: OSF410-400250) ******** 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: (MCPMC07S7) (Patch ID: OSF410-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: (HPXQ87202, QAR 49448, 49474, 49475) (Patch ID: OSF410-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: (HGOBB0043, HGOBB0597) (Patch ID: OSF410-405045) ******** Intermittently, the probe of an isp will fail during a boot. This happens maybe once in 20 system boots, so a workaround is to try the boot again. A typical console listing looks like this when it fails: . . . Created FRU table configuration errorlog packet tiop0 at tlsb0 node 8 tiop0: cpu interrupt mask being set as 1. pci0 at tiop0 slot 0 isp0 at pci0 slot 0 isp0: QLOGIC ISP1020 - Differential Mode cam_logger: CAM_ERROR packet cam_logger: bus 0 isp_mailbox complete Timeout on mailbox command completion scheduling chip reinit cam_logger: CAM_ERROR packet cam_logger: bus 0 isp_init Mailbox operations not functional for common init cam_logger: CAM_ERROR packet cam_logger: bus 0 isp_probe Common init failure - Failing probe isp0: Not probed. isp in slot 0 not configured. . . . PROBLEM: (Patch ID: OSF410-068) ******** 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 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 needed 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: (QAR 50363) (Patch ID: OSF410-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: (QAR 46424) (Patch ID: OSF410-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. B 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: (TKTB68852) (Patch ID: OSF410-405068) ******** This patch fixes a performance regression that may occur as a result of v4.0b patch 62.00 (OSF410-405045). To date this performance regression has been reported only on the AlphaServer 1000A platform and on the single-ended KZPBA adapter used on the AlphaServer 4100 platform. PROBLEM: (MCPM11KK6) (Patch ID: OSF410-405058-1) ******** 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: (QAR 50695) (Patch ID: OSF410-070) ******** 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: OSF410-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: OSF410-074) ******** 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, 52525) (Patch ID: OSF410-085, OSF410-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: OSF410-085) ******** 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: (ZPOB91873, HGOBB0092) (Patch ID: OSF410-405067) ******** 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: (EVT102039) (Patch ID: OSF410-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: (QAR 51581) (Patch ID: OSF410-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] PROBLEM: (FNO100138) (Patch ID: OSF410-400266) ******** This patch fixes a 'recursion count overflow' panic that occurs on DIGITAL 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: (FNO100139) (Patch ID: OSF410-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: (MCPM403TL, QAR 48048) (Patch ID: OSF410-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: OSF410-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: OSF410-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: (UTO101199, HPAQ30ETE, QAR 51485, 52365) (Patch ID: OSF410-087) ******** 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: (HPAQ400UX) (Patch ID: OSF410-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: (MCPM60B7T, MCPM60PGZ, MCPM60Y69) (Patch ID: OSF410-095 ) ******** Add TCP/IP support for third party drivers. PROBLEM: (SSRT0482U) (Patch ID: OSF410-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: OSF410-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: OSF410-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: (ISO100331) (Patch ID: OSF410-400354) ******** A multithreaded 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: (QAR 53003, 55150, MCPM40EQC) (Patch ID: OSF410-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: (STLB51417) (Patch ID: OSF410-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 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 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(128 by 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: (EVT102273, VNO100100, QAR 55615) (Patch ID: OSF410-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: OSF410-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: (MCPMA7154, MCPMB1B9V, MCPM41683, MCPM70JFF, QAR 49696,52727,51574) ******** (Patch ID: OSF410-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: (MCPM905D0, QAR 56258) (Patch ID: OSF410-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 There is a potential memory leak bug associated with the KMEM_DEBUG_PROTECT option of kmem_debug that occurs when the number of elmements in the protected bucket goes above the configured high-water mark. Since the default high-water mark is 2000, this overflow condition may never occur. However, if it does, the overflow pages are not properly returned to the system free list, resulting in the memory leak. Depending upon how many pages are lost, the problem may not even be noticed, or could eventually cause other problems. The problem can be easily worked around, by setting the high-water mark to a custom value based upon the bucket size usage and the manner in which the target system is utilized. The idea is to avoid ever going over the high water mark -- and as it turns out, the work-around actually serves to make the KMEM_DEBUG_PROTECT option more effective in catching memory corruption. The high-water mark kernel variable "kmem_protected_hiwat" can be modified dynamically using "dbx", or its associated tuneable "kmem-protected-hiwat" can be set in "/etc/sysconfigtab". For example, suppose the 32-byte bucket is being targeted by the KMEM_DEBUG_PROTECT option. After the system is up and running a "normal" load, execute "vmstat -M" to find out the typical usage of that bucket size: $ vmstat -M bucket# element_size elements_in_use elements_free bytes_in_use fail_count 0 16 4859 1266 77744 0 1 32 1916 900 61312 0 ... Add the "elements_in_use" (1916) and "elements_free" (900) values. Then use dbx to make its high-water mark equal to or greater than that value. Since 1916 + 900 equals 2816, it would be advisable to set the "kmem_protected_hiwat" variable to 3000: $ dbx -k /vmunix ... (dbx) assign kmem_protected_hiwat=3000 3000 (dbx) q $ Alternatively, the "kmem-protected-hiwat" tuneable can be hard-wired to any desired value in /etc/sysconfigtab: generic: kmem-protected-hiwat=3000 In either case, since the system has been shown to be using that many bucket elements at any point in time, there's no problem in bumping the high-water mark up to (and beyond) that level. It actually will help the debugging effort since the bucket elements will be on the free list much longer, and would never be given back to the system's free list. PROBLEM: (MCPM81FWD) (Patch ID: OSF410-400407) ******** This patch is MANDATORY. This patch resolves an inode locking problem in the UFS iupdat() and itimes() functions. PROBLEM: (QAR 49683, 47674) (Patch ID: OSF410-405103) ******** 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 51268) (Patch ID: OSF410-405116) ******** 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: (ZPOB54022) (Patch ID: OSF410-102) ******** 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 52810, 40239, 53048) (Patch ID: OSF410-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: (QAR 51274, HPAQC0X4J) (Patch ID: OSF410-112) ******** 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, 55110, 54413) (Patch ID: OSF410-113) ******** 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: (TKTR91730) (Patch ID: OSF410-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") trap() _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: (QAR 49540) (Patch ID: OSF410-405065) ******** Infrequently, under heavy disk I/O loads, user data can be written to the wrong disk, resulting in data corruption. PROBLEM: (Patch ID: OSF410-405114) ******** This patch provides the following: o Support the HSZ70 Raid controller on the Fast10 Wide Differential KZPSA adapter in cluster environments under DIGITAL UNIX V4.0B. Support of the HSZ70 Raid controller also requires the KZPSA firmware to be upgraded to at least the version distributed on the Version 5.0 AlphaServer Console Firmware CDrom. o Latent support for the HSZ50 and HSZ70 Raid controller on the Fast20 Wide Differential KZPBA-CB adapter in cluster environments under DIGITAL UNIX V4.0B. Support of the HSZ70 Raid controller also requires the KZPBA-CB firmware to be upgraded to at least the version distributed on the Version 5.1 AlphaServer Console Firmware CDrom. o Performance regression fix for Qlogic isp1020/isp1040 chips. o Provide SCSI target mode fixes for ASE/TCR support on QLogic, primarily for HSZ70 support. o All modifications included in this patch are compatible with existing versions of KZPSA and Qlogic firmware. PROBLEM: (QAR 55112,55110,54413) (Patch ID: OSF410-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: (Patch ID: OSF410-400369) ********* This patch provides general support for Version A11 KZPSA firmware. PROBLEM: (BRO101068/TKTR90901/QAR 55619) (Patch ID: OSF410-122) ******** 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 48878, QAR 36473, QAR 44706, QAR 49895) (Patch ID: OSF410-123) ******** This patch corrects problems with AdvFS performance regression, and two AdvFS race condition situations between multiple routines that can cause panics. One AdvFS race condition is between the ubc routines that call putpage and AdvFS invalidate. If this condition arises an ensuing panic may occur. Output from the panic might look like: lock_read: hierarchy violation pc of caller: 0xfffffc0000397728 lock address: 0xffffffff8031a200 lock info addr: 0xfffffc0000722200 lock class name: bfAccessT.xtntMap_lk class already locked: bfAccessT.putpage_lk current spl level: 0 panic (cpu 0): lock_read: hierarchy violation syncing disks... lock_read: simple lock owned pc of caller: 0xfffffc00003c6f80 lock address: 0xffffffff8031a2b0 lock info addr: 0xfffffc0000722210 lock class name: bfAccessT.putpage_lk pcb slock count: 2 current spl level: 2 The other AdvFS race condition is between msfs_putpage and bs_real_invalidate_pages. If this condition were to arise, it too might cause a panic to occur. Output from the panic might look like: panic "bs_real_invalidate_pages: buf refd or pinned" PROBLEM: (QAR 54983, QAR 49607) (Patch ID: OSF410-128) ******** This patch fixes a problem that occurs on an AdvFS file system. The system may panic with the following error message: ADVFS INTERNAL ERROR: dealloc_bits_page: can't clear a bit twice The following is an example of a stack trace: (dbx) t > 0 stop_secondary_cpu(do_lwc = 0x0) 1 panic(s = 0xfffffc0000556528) 2 event_timeout(func = 0xfffffc0000276738, arg = 0xfffffc000059a2c0, timeout = 0x5) 3 xcpu_puts(s = 0xfffffc00005798d0, prfbufp = 0xfffffc000059a2c0) 4 printf(fmt = 0xfffffc000051fd68) 5 panic(s = 0xffffffff88cb71d0) 6 advfs_sad(0xfffffc000030a7c8, 0x0, 0xe, 0x1f500, 0xfffffc0005952000) 7 CANT_CLEAR_TWICE(0x7b, 0xe, 0xffffffffffffff00, 0xc27f, 0x612) 8 dealloc_bits_page(0x38, 0xfffffc00005311a0, 0xfffffc00075d2008, 0xfffffc00057ba000, 0x301001a) 9 bitmap_undo_opx(0x3, 0xfffffc00005b9df8, 0xfffffc00075d2298, 0x0, 0xfffffc00075d3578) 10 ftx_fail_2(ftxH = struct { hndl = 0x1a level = 0x2 dmnh = 0x1 } 11 ftx_fail(ftxH = struct { hndl = 0x0 level = 0x0 dmnh = 0x0 } 12 fs_write_add_stg(0x1, 0xffffffff80287530, 0x7, 0xfffffc00020986e0, 0x0) 13 fs_write(0xc884, 0x14, 0x45f4f, 0x200000002, 0x0) 14 msfs_write(vp = 0xfffffc0002098600, uio = 0xffffffff88cb7848, cred = 0xfffffc0001e0be00) 15 vn_write(0xfffffc00002839ec, 0xffffffff88cb78e0, 0xfffffc000783bfc0, 0xf888, 0x1) 16 rwuio(0xfffffc0001fb6220, 0xfffffc0005431b80, 0xfffffc0000575ab0, 0xfffffc0001fb6000, 0xfffffc0 00783bfc0) 17 write(0xc884, 0xffffffff88cb7838, 0x28000, 0xc88400000001, 0x100000000) 18 syscall(0xf888, 0x1, 0xfffffc000045f7fc, 0x3ffc01877c0, 0x4) 19 _Xsyscall(0x8, 0x3ff800d2ed8, 0x14000c2c0, 0x3, 0x140059000) (dbx) PROBLEM: (QAR 56152, QAR 55813) (Patch ID: OSF410-129) ******** This patch fixes two problems that occur on AdvFS systems: o The system may panic with the following error message: simple_lock: hierarchy violation o A locking problem in the AdvFS log data structures may cause the following to occur: - System panics - Kernel memory faults - Memory corruption PROBLEM: (QAR 51348) (Patch ID: OSF410-130) ******** 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: (CLD MCPM911C6, CLD MCPM911CF, CLD USG-05807) (Patch ID: OSF410-135) ******** This Patch provides two new procfs ioctls (PIOCUSAGE and PIOCTUSAGE) to collect task and thread wait time statistics. PROBLEM: (QAR 54532, QAR 55448) (Patch ID: OSF410-405121) ******** This patch fixes a problem in which a file-on-file system mount of either an NFS or a /proc file system will panic the system. PROBLEM: (QAR 55760, QAR 52224) (Patch ID: OSF410-405134) ******** This patch fixes an AdvFS problem in which the system may panic with the following error message: thread_block: simple lock owned PROBLEM: (HPAQ81XSG HPAQA0S4S) (Patch ID: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-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 52608) (Patch ID: OSF410-400458) ******** 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 57707) (Patch ID: OSF410-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 task's minimum virtual address incorrectly left set to 0, the kernel 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: OSF410-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: (QAR 56794, QAR 56787) (Patch ID: OSF410-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: (SSRT0521U) (Patch ID: OSF410-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: (Patch ID: OSF410-143) ******** This patch provides a set of workarounds for Qlogic firmware bugs. These bugs were encountered when using the HSZ70 Raid Array Controller on the KZPBA-CB wide differential UltraSCSI adapter in a dual-node cluster environment. o Better handle sensitive error recovery sequences during HSZ70 controller failover o Handles Command Error (a mailbox error code 0x4005) without resorting to chip reinit/bus reset. o Additional workarounds for version 5.53 target-mode firmware bugs. Complete support for cluster environments also requires that the Qlogic adapter firmware version and HSZ70 Raid Array controller firmware version is at least at the level as documented in the HSZ70 Raid Controller Platform Kit. All modifications included in this patch are compatible with existing versions of Qlogic firmware. PROBLEM: (QAR 57454, QAR 53780, QAR 54825) (Patch ID: OSF410-145) ******** This patch improves performance on low-memory (32MB) systems. PROBLEM: (QAR 56327, QAR 59459) (Patch ID: OSF410-155) ******** 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: (QAR 36464,47097,47168,50937,60304) (Patch ID: OSF410-158) ******** 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: (CLD MGO103458) (Patch ID: OSF410-157) ******** This patch fixes a kernel memory fault panic. This patch is mandatory for multiprocessor machines. The patch fixes a potential memory corruption of the akl_pagelist. PROBLEM: (QAR 57867, QAR 57643) (Patch ID: OSF410-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: OSF410-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: OSF410-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 56165) (Patch ID: OSF410-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: 0 panic() ["../../../../src/kernel/bsd/subr_prf.c":707, 0xfffffc000027c08c] 1 simple_lock_fault() ["../../../../src/kernel/kern/lock.c":2065, 0xfffffc00002a3198] 2 simple_lock_hierarchy_violation() ["../../../../src/kernel/kern/lock.c":2065, 0xfffffc00002a3198] 3 mntflushbuf() ["../../../../src/kernel/vfs/vfs_bio.c":1479, 0xfffffc0000442624] 4 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2416, 0xfffffc000049753c] 5 panic() ["../../../../src/kernel/bsd/subr_prf.c":791, 0xfffffc000027c22c] 6 simple_lock_fault() ["../../../../src/kernel/kern/lock.c":2065, 0xfffffc00002a3198] 7 simple_lock_state_violation() ["../../../../src/kernel/kern/lock.c":2101, 0xfffffc00002a3274] 8 vm_anon_page_alloc() ["../../../../src/kernel/vm/vm_anonpage.c":131, 0xfffffc000046e4d0] 9 anon_getpage() ["../../../../src/kernel/vm/vm_anon.c":417, 0xfffffc000046dbf4] 10 u_anon_fault() ["../../../../src/kernel/vm/u_mape_anon.c":850, 0xfffffc000045d884] 11 vl_wire() ["../../../../src/kernel/vm/vm_vlock.c":122, 0xfffffc0000480b34] 12 u_map_wire() ["../../../../src/kernel/vm/vm_umap.c":1029, 0xfffffc000047d350] 13 vm_map_pageable_orig() ["../../../../src/kernel/vm/vm_map.c":1321, 0xfffffc0000472b98] 14 vm_map_pageable() ["../../../../src/kernel/vm/vm_map.c":1293, 0xfffffc0000472b04] 15 physio() ["../../../../src/kernel/ufs/ufs_physio.c":316, 0xfffffc0000429844] 16 ctape_read() ["../../../../src/kernel/io/cam/cam_tape.c":3658, 0xfffffc00004e1730] 17 spec_read() ["../../../../src/kernel/vfs/spec_vnops.c":1880, 0xfffffc0000439198] 18 ufsspec_read() ["../../../../src/kernel/ufs/ufs_vnops.c":3628,0xfffffc0000432e70] 19 vn_read() ["../../../../src/kernel/vfs/vfs_vnops.c":876, 0xfffffc000045a2bc] 20 rwuio() ["../../../../src/kernel/bsd/sys_generic.c":1501, 0xfffffc000028b9b0] 21 read() ["../../../../src/kernel/bsd/sys_generic.c":1451, 0xfffffc000028b8c0] 22 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":540, 0xfffffc000049d360] 23 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1209, 0xfffffc00004933e4] PROBLEM: (QAR 58257,48719,49229,52020) (Patch ID: OSF410-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: OSF410-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: OSF410-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: OSF410-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: (QAR 57552, QAR 53693, QAR 53727) (Patch ID: OSF410-405204) ******** 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: (MCGM91LZQ, UVO105302, EVT102394) (Patch ID: OSF410-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: OSF410-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: OSF410-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: OSF410-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: (QAR 55387, QAR 51401) (Patch ID: OSF410-405216) ******** 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 58740) (Patch ID: OSF410-156) ******** 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: (TKTR20675) (Patch ID: OSF410-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: (UVO105930/QAR 59429) (Patch ID: OSF410-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 59319) (Patch ID: OSF410-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: OSF410-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: OSF410-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 the potential vulnerability. PROBLEM: (QAR 58007,59236) (Patch ID: OSF410-405187) ******** 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: (MGO103468) (Patch ID: OSF410-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 59562, QAR 60399) (Patch ID: OSF410-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: OSF410-405268) ******** This patch corrects a problem where a flag, TF_PSUSP, was not being cleared. PROBLEM: (BCPM419F2) (Patch ID: OSF410-405276) ******** This corrects a problem that causes a "pmap_ssm_destroy: wired pages" crash. PROBLEM: (MGO103472) (Patch ID: OSF410-405277) ******** This corrects a performace problem with posix timers. PROBLEM: (HPAQ41QK2) (Patch ID: OSF410-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: OSF410-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: OSF410-405289) ******** This patch fixes a networking problem that occurs when the kernel variable ipport_userreserved is set to 65535. PROBLEM: (HPAQ81XSG) (Patch ID: OSF410-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: (CLD DEKB10974) (Patch ID: OSF410-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 59878, QAR 53422) (Patch ID: OSF410-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 59255) (Patch ID: OSF410-405330) ******** This patch corrects a problem that would randomly cause kloadsrv(8) to crash and improperly load/unload modules. PROBLEM: (HPAQ60SQH) (Patch ID: OSF410-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: OSF410-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: OSF410-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: OSF410-405356) ******** This patch removes extraneous debug code. PROBLEM: (QAR 62045) (Patch ID: OSF410-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: OSF410-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 61938, QAR 58566) (Patch ID: OSF410-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 57579) (Patch ID: OSF410-405368) ******** Asynchronous I/O can fail when the number of aio requests is allowed to exceed 64K. PROBLEM: (QAR 59863, QAR 59323) (Patch ID: OSF410-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 62531) (Patch ID: OSF410-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: OSF410-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: (MGO103468) (Patch ID: OSF410-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: (BCGM70W61, UVO105916) (Patch ID: OSF410-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: (QAR 59849, QAR 58696) (Patch ID: OSF410-167) ******** This patch fixes a problem when a processor is commanded to stop during a heavy load but does not actually halt. PROBLEM: (QAR 56793) (Patch ID: OSF410-176) ******** 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: OSF410-178) ******** 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: (TKTR61501/QAR 60709) (Patch ID: OSF410-187) ******** 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 58232, QAR 51839) (Patch ID: OSF410-193) ******** 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: (HGOQ40195) (Patch ID: OSF410-196) ******** 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: (SSRT0559U) (Patch ID: OSF410-206) ******** 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: OSF410-208) ******** 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: (QAR 55126, QAR 52313) (Patch ID: OSF410-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 59773, QAR 55941, QAR 56416) (Patch ID: OSF410-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: (HPAQ205WQ/QAR 58962) (Patch ID: OSF410-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: OSF410-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: (QAR 60378) (Patch ID: OSF410-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 47111 QAR 58034 QAR 60575) (Patch ID: OSF410-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: OSF410-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: OSF410-405345) ******** This patch fixes a problem that caused the system to panic with the string "kernel memory fault". PROBLEM: (QAR 58800, QAR 59115, QAR 58440) (Patch ID: OSF410-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 60865) (Patch ID: OSF410-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 62353, QAR 61253) (Patch ID: OSF410-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: OSF410-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: OSF410-405384) ******** This patch corrects a potential boot panic problem by limiting the size of the bufcache. PROBLEM: (QAR 55421, QAR 55783) (Patch ID: OSF410-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: OSF410-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":757, 0xfffffc000041ce84] 2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1243, 0xfffffc000046d934] 3 _XentMM(0x0, 0xfffffc0000366380, 0xfffffc0000888740, 0x0, 0x190) ["../../../../src/kernel/arch/alpha/locore.s":1307, 0xfffffc000045be24] 4 u_dev_protect(0xfffffc000b3a4b40, 0xfffffc0000000000, 0xfffffc0000000001, 0xffffffff00000003, 0xffffffff00000020) ["../../../../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, 0xfffffc000040d050) ["../../../../src/kernel/vm/vm_user.c":206, 0xfffffc000037d020] 8 mprotect(0xfffffc000304e210, 0xffffffff8bd17758, 0xffffffff8bd178b8, 0x1, 0x0) ["../../../../srccrash-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 63231) (Patch ID: OSF410-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: OSF410-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: OSF410-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: (QAR 62104) (Patch ID: OSF410-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 54309) (Patch ID: OSF410-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: (BCPM80CMQ) (Patch ID: OSF410-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 49649) (Patch ID: OSF410-164) ******** 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 strace 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 57323) (Patch ID: OSF410-170) ******** 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: (SQO100495) (Patch ID: OSF410-182) ******** This corrects a simple lock timeout problem in several vm_page routines. PROBLEM: (QAR 59847) (Patch ID: OSF410-189) ******** This patch prevents a kernel malloc leak when changing the protection of a System V shared memory region that uses gh-chunks. PROBLEM: (QAR 60725) (Patch ID: OSF410-194) ******** This patch fixes a problem in the AdvFS logging code. The way locking was implemented was causing degraded performance. PROBLEM: (QAR 59621) (Patch ID: OSF410-195) ******** This patch fixes a problem with the vmstat -P command, which was incorrectly formatting output. PROBLEM: (QAR 56172, QAR 55808, QAR 66453) (Patch ID: OSF410-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 will not 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 a 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: (HPAQ5152N) (Patch ID: OSF410-405445) ******** This patch fixes a routing corruption that could been seen as a kernel memory fault or a corruption within the 128 byte kernel memory bucket. An example stack trace is as follows: 10 panic src/kernel/bsd/subr_prf.c : 834 11 afault_trap src/kernel/arch/alpha/trap.c : 2408 12 _XentUna src/kernel/arch/alpha/locore.s : 1767 13 free_trim src/kernel/bsd/kern_malloc.c : 1501 14 free src/kernel/bsd/kern_malloc.c : 1554 15 direct_map_dealloc src/kernel/arch/alpha/hal/dma_direct_map.c : 587 16 dma_map_dealloc src/kernel/io/dec/pci/pcia.c : 4886 17 dma_map_unload src/kernel/io/dec/pci/pcia.c : 4839 18 spo_map_unload_ccb src/kernel/io/cam/spo/simport_dme.c : 1456 19 spo_remove_queue_entry src/kernel/io/cam/spo/simport.c : 2870 20 spo_process_rsp src/kernel/io/cam/spo/simport.c : 3707 21 pzaintr src/kernel/io/cam/spo/sim_pza.c : 1274 22 intr_dispatch_post src/kernel/arch/alpha/hal/shared_intr.c : 247 23 _XentInt src/kernel/arch/alpha/locore.s : 1220 24 vm_page_tester src/kernel/vm/vm_resident.c : 2011 PROBLEM: (QAR 56378) (Patch ID: OSF410-405442) ******** This patch corrects a potential problem in the handling of a write() system call to a routing socket. PROBLEM: (QAR 62959, QAR 62942) (Patch ID: OSF410-203) ******** This patch fixes a problem with user stack pointers not being saved properly in kernel crash dumps for running threads. PROBLEM: (CLD MGO103598 QAR 53616) (Patch ID: OSF410-213) ******** 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 60888, QAR 61768, QAR 58064) (Patch ID: OSF410-180) ******** This patch fixes a problem in the AdvFS system. The log file corruption caused panics during recovery and failures displaying one of the following messages: ftx_fail: lgr_read failure -or- ftx_fail: dirty page not allowed Sample stack traces are listed below: 28 panic() 29 advfs_sad() 30 ftx_fail_2() 31 ftx_fail() 6 advfs_sad() 7 _ms_free() 8 ftx_fail_2() 9 ftx_recovery_pass() PROBLEM: (QAR 59953, QAR 59419) (Patch ID: OSF410-159) ******** 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 62299, QAR 51568, HPAQ60W1F, QAR 62617, QAR 62610, UVO106018, QAR 6118 5, QAR 63686, QAR 63703, QAR 54276, QAR 60262) (Patch ID: OSF410-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 61665) (Patch ID: OSF410-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 45730, 46647) (Patch ID: OSF410-400066) ******** DDR partially builds some device records. This problem is extremely hard to detect, as the creation of device records usually happens silently in the kernel as it encounters new devices. Symptoms of this error may be slight oddities in device behavior. Unfortunately, the extent to which behavior is affected cannot be predicted. The problem can be seen most easily by executing the following : Invoke "ddr_config -s disk DEC RZ28B". The (failing) output should look as follows: Building Device Information for: Type = disk Vendor ID: "DEC" Product ID: "RZ28B" Applying Modifications from Device Record for: Vendor ID: "DEC" Product ID: "RZ28" TagQueueDepth = 0x4a The (correct) output should look as follows: Building Device Information for: Type = disk Vendor ID: "DEC" Product ID: "RZ28B" Applying Modifications from Device Record for: Vendor ID: "DEC" Product ID: "RZ28" TagQueueDepth = 0x4a Applying Modifications from Device Record for: Vendor ID: "DEC" Product ID: "RZ28B" TagQueueDepth = 0x40 PROBLEM: (QAR 45730, 46647) (Patch ID: OSF410-400066) ******** The "ddr_config -x" option fails to compile a cam_data.c file from a version prior to DIGITAL UNIX v4.0. The following error messages will be reported: ddr_config.ORIG: Line 3233: Syntax Error ddr_config.ORIG: Line 3233: Failed parsing DENSITY_TBL entry Conversion of /sys/data/cam_data.c failed. Line numbers are relative to the temporary file /tmp/cam_data.tmp Looking at the /tmp/cam_data.tmp file, the error occurs between two records separated by a comma. For example: TYPE Record_A = { .... }, <----- fails here Record_B = { ... }; PROBLEM: (HPAQB16E6) (Patch ID: OSF410-400218) ******** The DDR subsystem did not appropriately handle SCSI devices that return non-standard device types. The standard device types range from 0 (disk device) to 9 (Communications Device). For example, a custom SCSI device that returns a device type of UNKNOWN (0x1f) "trap: invalid memory read access from kernel mode" A device with a non-standard device type would ordinarily not be shown as present on the system as it would require a custom SCSI device driver to access it (one which does not come with the base operating system). Note: Non-standard device types are supported by CAM in pre-v4.0 releases. PROBLEM: (Patch ID: OSF410-058B) ******** Boot capability for new hardware support requires a new genvmunix. This patch delivers an updated genvmunix for that purpose. PROBLEM: (Patch ID: OSF410-058) ******** Support for the DE500-BA requires recognition of a new PCI device ID and also require specific code to operation the device. PROBLEM: (Patch ID: OSF410-405097) ******** This provides device recognition for TZS2. See the DIGITAL UNIX and TruCluster "Patch Summary and Release Notes" for further information. PROBLEM: (QAR 52217, QAR 54680) (Patch ID: OSF410-405376) ******** The maximum block size (MaxTransferSize) for "unknown" tape devices specified in the /etc/ddr.dbase file was previously limited to 64 kilobytes. This would cause applications, such as back-up utilities, to fail if a block size of greater than 64 kilobytes was specified. This patch modifies the value of MaxTransferSize to 16 megabytes to support devices and applications that can support larger block sizes. PROBLEM: (QAR 55766 QAR 60909) (Patch ID: OSF410-205) ******** This patch fixes the following problems that may occur on some DE500 adapters: o The hardware setup operation may interrupt a pending ARP packet transmission. o If the cable to the adapter is not connected, the hardware setup operation will not execute. PROBLEM: (QAR 62832) (Patch ID: OSF410-405455) ******** This patch is a re-fix of the NFS loopoback mounted file system hang problem that was fixed two years ago. The tunable parameter ubc_nfsloopback has been removed and the code restructured to eliminate any problems with NFS loopback mounted file systems as well as increase NFS performance. This patch also fixes performance and hang/panic problems with the UBC when filling the UBC with a small number of large files. The panic problems usually look like simple lock timeouts which results from a task waiting on the UBC LRU lock while ubc_page_alloc() excessively scans the LRU list for a usable page. PROBLEM: (QAR 63216, QAR 61054, MGO103457) (Patch ID: OSF410-405456) ******** This patch fixes a problem with the ddr_config command, where the -x option would intermittently fail. PROBLEM: (QAR 63897, QAR 63678) (Patch ID: OSF410-405459) ******** This patch fixes a problem with the memory file system (mfs) that caused systems to hang when they attempted to dynamically allocate a cdfs file system. The problem first seemed to be an issue with systems that had been update installed. PROBLEM: (QAR 62827) (Patch ID: OSF410-405464) ******** This patch adds code to save a copy of the requested mode bits in vattr before umask is applied. PROBLEM: (BCPM9124T) (Patch ID: OSF410-405466) ******** This patch fixes a problem that can cause an NFS client application to hang, or causes a "lock already owned by thread" panic when lockmode=4. The problem occurs when the application tries to rename a sub-directory to it's parent. A stack trace of a hung NFS client application, or the panicing process, may look like: 0 thread_block() 1 lock_write() 0 thread_block() 1 lock_write() 2 nfs3_rename() 3 rename() 4 syscall() 5 _Xsyscall() PROBLEM: (BCGM80NCB, QAR 64024) (Patch ID: OSF410-405471) ******** This patch fixes a problem in the cam driver. A disk failure can cause the driver to spend too much time retrying interleaved Test Unit Ready and Start Unit commands. As a result, the logging of the hard error caused by the disk failure is delayed. PROBLEM: (QAR 63741, BCSM80FG6) (Patch ID: OSF410-405472) ******** This patch fixes a problem where a file system is busy when trying to unmount it. PROBLEM: (qar 64377) (Patch ID: OSF410-405473) ******** This patch fixes the erroneous "SAR Stats" implementation of CAM statistics. The original CAM stat's macros calculated inappropriate time deltas because they were not measured on a per-io basis, and the times did not account for overlapping i/o. PROBLEM: (GOZ100546, GOZ100949, QAR 51038, QAR 64034) (Patch ID: OSF410-405490) ******** This patch fixes a problem where NFS does not update mtime and atime for special files and named pipes. PROBLEM: (EW9B92660) (Patch ID: OSF410-405491) ******** This patch fixes a route problem when you apply different subnet masks to the same Internet Class network address. PROBLEM: (QAR 56716, QAR 64562) (Patch ID: OSF410-405492) ******** This patch fixes a panic that occurs when KZPSA resources aren't available to re-enable a channel or a device after a bus reset. The panic string is listed below: panic("(spo_process_rsp) ran out of memory!") PROBLEM: (BCPMA0ZMC) (Patch ID: OSF410-405495) ******** This patch fixes a problem seen with very large user stack sizes. This can only happen when the sysconfigtab attribute "max-per-proc-stack-size" is set to greater than 2 GB, and certain other conditions are met. The panic would show up as a kernel memory fault with the following stack trace: 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 simple_lock_D src/kernel/arch/alpha/lockprim.s : 760 9 lk_plock_try src/kernel/vm/u_mape_anon.c : 2832 10 u_anon_oop_lock_try src/kernel/vm/u_mape_anon.c : 2928 11 vm_pageout_scan src/kernel/vm/vm_pagelru.c : 828 12 vm_pageout_loop src/kernel/vm/vm_pagelru.c : 706 13 vm_pageout src/kernel/vm/vm_pagelru.c : 1265 With this patch, the 2 GB stack restriction is now removed, and the maximum stack size is now 4 GB. PROBLEM: (QAR 54441,QAR 60576) (Patch ID: OSF410-405501) ******** This patch fixes a problem in which a kernel client rpc has a socket leak when an error is encountered and binding fails. The problem may manifest itself if there is heavy traffic over a transport such as NFS. PROBLEM: (CLD CA8B91177) (Patch ID: OSF410-405502) ******** This patch fixes a system hang. The system hang is a result of an infinite loop when out-of-band networking data is followed by any number of bytes and a process is doing a MESSAGE PEEK with a user buffer larger than the number of out-of-band bytes. PROBLEM: (MCGM305SB, QAR 65113) (Patch ID: OSF410-405519) ******** This patch fixes a problem where init hangs due to multiple downgrades of a write lock. PROBLEM: (QAR 65396) (Patch ID: OSF410-405527) ******** The output from the "vmstat -M" command does not correctly match the bucket numbers with the bucket indices. PROBLEM: (QAR 66747) (Patch ID: OSF410-405535) ******** 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. Compaq has corrected this potential vulnerability. PROBLEM: (CLD MGO103853, CLD MGO103295, CLD MGO103959) (Patch ID: OSF410-405546) ******** This patch fixes a kmf problem when the type of SCSI device dynamically changes. A typical stack trace: panic trap _XentMM malloc(size = 64) falloc accept1 oaccept syscall _Xsyscall PROBLEM: (BCGM20L71) (Patch ID: OSF410-405560) ******** This patch fixes a dealock that can occur when a thread is in sigwaitprim(), and a second signal in the sigwait set is being delievered. An example stack from of the sigwait thread is: simple_lock_time_violation() mpsleep() sigwaitprim() syscall() _Xsyscall() And the delievering threads stack would be: psignal_internal() kill() syscall() _Xsyscall() PROBLEM: (QAR 61679, QAR 60438) (Patch ID: OSF410-405563) ******** This patch fixes a problem when using the mt rewind command on the TZ89 tape drive. The tape subsystem returns an I/O error if there is not a 120 sec delay between the mt offline and the dump command. This patch also adds support for the following devices: - DLT - SDT - TSL - SDX - C5xxxA PROBLEM: (FNO100208) (Patch ID: OSF410-405570) ******** This patch fixes a problem with poor performance of NFS/UDP over a GigaBit Ethernet network interface (DEGPA). It allows client side RPC freeing of client handles with busy buffers. PROBLEM: (CLD JHB100057 CLD BCGM10237 QAR 63908) (Patch ID: OSF410-405578) ******** This patch fixes the cause of the spurious spo_misc_errors errlog entry on 4100 class systems. PROBLEM: (CLDs HPAQ200SX, MCPM415SF, HPAQ914NT QAR 45528) (Patch ID: OSF410-405579) ******** This patch corrects an NFS client problem where a KMF panic can result from incorrect locking. A typical stack trace would be: 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1889 1 panic(s = 0xfffffc00005fcf68 = "kernel memory fault") 2 trap 3 _XentMM 4 atomic_decl 5 clntktcp_freesock 6 clfree 7 rfscall 8 rfs3call 9 nfs3_getattr_otw 10 nfs3getattr 11 nfs3_getattr . . . PROBLEM: (SSRT0583Q) (Patch ID: OSF410-405583) ******** 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. Compaq has corrected this potential vulnerability. PROBLEM: (CLD ALC-08248, QAR 69130, QAR 69348) (Patch ID: OSF410-405584) ******** This patch fixes resolves a performance problem associated with page coloring for real time applications (rt_preempt_opt=1). There is a new tuneable, "vm_page_color_private", which is modified in the "vm" section of the sysconfigtab file. The default value for this variable is "0", so to enable this feature the variable must be set to "1". PROBLEM: (BCGMC1JRS) (Patch ID: OSF410-405589) ******** This patch fixes a problem where process accounting data was not written to the accounting file when it was on an NFS-mounted file system. This problem occured on Dataless Management Services (DMS) client systems. To correct this problem, this patch must be installed on the DMS clients. It does not need to be installed on the DMS server. PROBLEM: (CLDs BCGM40VQ6, MGO104026, QAR 51061) (Patch ID: OSF410-405590) ******** This patch fixes a problem where an NFS client process may hang in the uninterruptable state. Specifically, compilation builds may hang during the ld phase (linking). PROBLEM: (QAR 63667, QAR 63892) (Patch ID: OSF410-214) ******** This patch corrects a problem in the Qlogic driver that could eventually result in unexpected errors or panics. This patch also corrects the following simple QLogic problems: o Fixes "simple_lock: time limit exceeded" panics. o Fixes a problem in which adapter errors are reported as disk errors. o Fixes a problem in which a processor may appear to hang for long periods of time when doing large, non-aligned, non-block, multiple I/O transfers. o Fixes a problem in which random memory corruption problems may occur when a device error is encountered and the device does not have an entry in the DDR database. PROBLEM: (ZPOB92577) (Patch ID: OSF410-215) ******** This patch fixes a kernel memory fault from ip_forward() and has the following stack trace; panic trap _XentMM ip_forward gw_forwardscreen ip_forwardscreen ip_dooptions ipintr netisr_thread PROBLEM: (QAR 64191 QAR 52226) (Patch ID: OSF410-216) ******** Older revisions of the 21140 DECchip do not support over 14 multicast addresses. Attempting to filter more than 14 addresses caused the following error message: "tu0: address filter table is full, sorry". PROBLEM: (QAR 62917 QAR 62920) (Patch ID: OSF410-218) ******** This patch fixes the problem where in the dump of a forced crash, the trace of the thread that was active at the time of the crash contains incorrect information. PROBLEM: (QAR 63936, QAR 65766, QAR 65767) (Patch ID: OSF410-224) ******** This patch fixes several problems in the kernel. 1) A panic with the message vm_unwire: page is not wired 2) A panic with the message kernel_object_bad: bad operation 3) A system hang due to deadlock between the swapin thread and ps both PROBLEM: (QAR 65232, BCSMA1H45) (Patch ID: OSF410-227) ******** This patch fixes a panic which has the following error message: tb_shoot ack timeout This panic seems to occur only on multi-processor 4100 machines. PROBLEM: (QAR 59329) (Patch ID: OSF410-228) ******** This patch fixes a problem in which The fork() system call failed to save the floating point state in forking multithreaded programs. The new behavior saves the floating point state to the pcb and then calls copyout() to copy it to the forking thread's out-of-line state. PROBLEM: (QAR 64405) (Patch ID: OSF410-232) ******** This patch fixes a sleeping sickness problem seen in Sitp tests.  The pager and swapper have been enhanced as follows: * The pager is now more aggressive in low memory situations when many eligible pages are referenced, and runs every 250ms instead of every second. * The outswapper's timeout interval has been changed to lower the time requirements on idle tasks, and aggressive swap is enabled only when low memory conditions exist. PROBLEM: (QAR 68123, QAR 67795) (Patch ID: OSF410-237) ******** This patch fixes a problem where the system crashes with the following error message: lw_remove: light weight wiring(s) found PROBLEM: (CLD UVO106265 QAR 67541>) (Patch ID: OSF410-242) ******** This corrects a "simple_lock: time limit exceeded" panic. An example of a partial stack trace showing the relevant enties: panic() simple_lock_fault() simple_lock_time_violation() . . . softclock_scan() hardclock() _XentInt() . . . syscall() _Xsyscall() PROBLEM: (QAR 68542) (Patch ID: OSF410-245) ******** This patch fixes a panic which has the following error message: simple_lock: time limit exceeded A sample stack traces are listed below: 0 thread_block 1 voliod_loop 2 volkiostart 3 volstrategy 4 spec_strategy 5 call_disk 6 bs_startio 7 bs_q_blocking 8 bs_q_list 9 logflush_cont 10 bs_logflush_start 11 lgr_flush_start 12 msfs_mntflushbuf 13 mntflushbuf 14 boot 15 panic 16 simple_lock_fault 17 simple_lock_time_violation 18 pmap_dup 19 vm_dup_va 20 volkiomem_iter 21 volkiocopyout 22 volsio_unstabilize 23 vol_mv_wrback_done 24 voliod_iohandle 25 voliod_loop 0 boot 1 panic 2 event_timeout 3 pmap_begin_mutex_region_wait1 4 pmap_remove_all 5 pmap_page_protect 6 k_mem_free_anon 7 k_mem_unmap 8 k_map_delete 9 kmem_stack_free 10 stack_free 11 thread_deallocate 12 reaper_thread 0 stop_secondary_cpu 1 panic 2 cpu_ip_intr 3 _XentInt 4 lwc_schedule 5 stop_secondary_cpu 6 panic 7 event_timeout 8 xcpu_puts 9 printf 10 simple_lock_fault 11 simple_lock_time_violation 12 pmap_clear_reference 13 vm_page_deactivate 14 vm_pagelru_approximation 15 vm_pageout PROBLEM: (67968) (Patch ID: OSF410-247) ******** This patch is for AOL systems running Inktomi code. It provides enabling hooks for Inktomi caching server code. PROBLEM: (CLD MGO103899) (Patch ID: OSF410-250) ******** This patch fixed a problem where a process hangs due to recursive page faults. PROBLEM: (CLD HPAQA024N, CLD BCSM21XNM, QAR 65702, QAR 58547, QAR 64794, QAR 60919) (Patch ID: OSF410-252) ******** This patch fixes a problem in which a system may panic with the following panic string "lock_pvh timeout". Representative stacktraces are shown below: Stacktrace 1: panic("lock_pvh timeout") src/kernel/bsd/subr_prf.c":796 lock_pvh_wait() src/kernel/arch/alpha/atomic_ops.s":698 pmap_zero_page() src/kernel/arch/alpha/pmap.c":4417 vm_page_zeroer() src/kernel/vm/vm_resident.c":1982 idle_thread() src/kernel/kern/sched_prim.c":3467 Stacktrace 2: panic("lock_pvh timeout") src/kernel/bsd/subr_prf.c":796 lock_pvh_wait src/kernel/arch/alpha/atomic_ops.s : 698 pmap_zero_page src/kernel/arch/alpha/pmap.c : 4417 vm_zeroed_pg_alloc src/kernel/vm/vm_resident.c : 1374 vm_anon_page_alloc src/kernel/vm/vm_anonpage.c : 129 anon_pagezero_alloc src/kernel/vm/vm_anon.c : 462 u_anon_faultpage src/kernel/vm/u_mape_anon.c : 1087 u_anon_fault src/kernel/vm/u_mape_anon.c : 980 u_anon_lockop src/kernel/vm/u_mape_anon.c : 2184 u_map_lockvas src/kernel/vm/vm_umap.c : 1324 c_map_wire src/kernel/vm/vm_cmap.c : 145 vm_map_pageable_orig src/kernel/vm/vm_map.c : 1549 vm_map_pageable src/kernel/vm/vm_map.c : 1521 task_threads src/kernel/kern/task.c : 1112 _Xtask_threads mach/mach_server.c : 292 mach_server mach/mach_server.c : 6451 mach_msg src/kernel/kern/ipc_basics.c : 442 msg_rpc_trap src/kernel/kern/ipc_basics.c : 1437 _Xsyscall src/kernel/arch/alpha/locore.s : 1582 PROBLEM: (QAR 60967, QAR 53146) (Patch ID: OSF410-405468) ******** This patch fixes a problem in the AdvFS system. A domain panic message was not being written to the binary error log file. Note: This patch only works with versions of DECEvent 2.6 and higher. PROBLEM (QAR 64688) (Patch ID: OSF410-239) This patch fixes kernel memory fault system panic in routine spec_relcaim. A sample stack trace is as follows: 0 stop_secondary_cpu() 1 panic() 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic() 6 trap() 7 _XentMM() 8 spec_reclaim() 9 vgone() PROBLEM (QAR 66544) (Patch ID: OSF410-239) This patch fixes a problem with executing the "file" command against a lat (BSD) special device in which the "file" process will hang. The system needs to be rebooted in order to remove the hung process. PROBLEM (QAR 67757) (Patch ID: OSF410-239) This patch fixes a problem on multiCPU systems where hangs can occur in the revoke system call when multiple threads attempt to call "revoke" at the same time. A sample stack trace is as follows: 0 thread_block() 1 clearalias() 2 revoke() 3 syscall() 4 _Xsyscall() PROBLEM: (QAR 54840, QAR 60476, QAR 58938) (Patch ID: OSF410-241) ******** This patch fixes a problem in AdvFS where a complex lock in the ddl_wait_for_active_entry() routine would cause the thread to hang and possibly blocking other threads. If the system is set with lockmode = 4, a system panic would occur. PROBLEM: (BCGM703PQ,BCPM70WFJ,HPAQ920JJ,BCGMC0NZ8,HPAQA225S,BCGM210JL, HPAQ20Z8V) (Patch ID: OSF410-253) ******** This patch fixes a problem where several processes accessing the same AdvFS file can hang with the following stack trace: thread_block ubc_lookup page_lookup bs_refpg_int bs_refpg fs_read msfs_read vn_read rwuio read syscall _Xsyscall PROBLEM: (HPAQ41J00, QAR 64037) (Patch ID: OSF410-219) ******** This patch fixes a problem where a system panic will occur when accessing an ISO9660 format CDROM when the CDROM was mounted using the command: mount -r -t cdfs -o noversion /dev/rz4c /cdrom The panic string is "Unaligned kernel space access from kernel mode". A typical stack trace of the crash is: 6 panic(s = "Unaligned kernel space access from kernel mode") 7 afault_trap 8 _XentUna 9 cdfs_isodir_to_idir 10 cdfs_readisodir_int 11 cdfs_readisodir 12 cdnodeget 13 cdfs_lookup 14 namei 15 stat1 16 stat 17 syscall 18 _Xsyscall PROBLEM: (TKTRB0985) (Patch ID: OSF410-246) ******** This patch fixes a kernel problem, where proper locking/reference count management was not being performed. This could result in a panic with the stack trace: 5 panic(s = 0xfffffc0000777888 = "lock_terminate: lock held") 6 lock_terminate 7 pgdelete 8 pgrp_unref 9 pgrm 10 proc_teardown 11 waitf 12 wait4 13 syscall 14 _Xsyscall PROBLEM: (QAR 48449) (Patch ID: OSF410-405023) ******** When reading a streams pipe, if more than one message is in the pipe, a read with a message length greater than the first message will result in reading all of the messages in the pipe concatenated. PROBLEM: (QAR 49942, 49814) (Patch ID: OSF410-400146) ******** This patch fixes a problem that causes the system to panic with a kernel memory fault or "malloc_audit: guard space corruption" with osr_run as an entry in the stack. At this time no additional stack information is available. PROBLEM: (QAR 52041) (Patch ID: OSF410-400236) ******** 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 is a racing close() and fdetach() of a System V fifo. In the dump the thread that did the racing close can often be found with the traceback: thread_block() vfs_busy() dounmount() sth_update_times() osr_close_subr() pse_close() speclose() spec_close() vn_close() closef() close() syscall() _Xsyscall() PROBLEM: (TKTQ42309) (Patch ID: OSF410-400324) ******** This patch fixes a problem that occurs when running STREAMS. The system panics with a kernel memory fault in osr_run(). The kernel memory fault is a result of a non_cloned STREAMS device closing and not being removed from the hash table. A sample stack trace is shown as follows: 0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1923,] 1 thread_preempt() 2 boot() 3 panic(s 0xfffffc000074a020 = "kernel memory fault") 4 trap() ["../../../../src/kernel/arch/alpha/trap.c":1243,] 5 _XentMM() 6 osr_run() ["../../../../src/kernel/streams/str_synch.c":161,] 7 pse_open() ["../../../../src/kernel/streams/str_scalls.c":660,] 8 spec_open() ["../../../../src/kernel/vfs/spec_vnops.c":1249,] 9 vn_open() ["../../../../src/kernel/vfs/vfs_vnops.c":568,] 10 copen() ["../../../../src/kernel/vfs/vfs_syscalls.c":1824,] 11 open() ["../../../../src/kernel/vfs/vfs_syscalls.c":1781,] PROBLEM: (TKTB37284) (Patch ID: OSF410-400324) ******** This patch fixes a problem that occurs when running STREAMS. The system panics with a kernel memory fault in osr_reopen(). The kernel memory fault is a result of a non_cloned STREAMS device closing and not being removed from the hash table. A sample stack trace is shown as follows: 0 boot() 1 panic() 2 trap() 3 _XentMM() 4 osr_reopen() 5 osr_run() 6 pse_open() 7 spec_open() 8 vn_open() 9 copen() 10 open() PROBLEM: (MGO102730) (Patch ID: OSF410-400368) ******** This patch fixes the problem of a system hang due to corruption of a STREAM synchronization queue's forward pointer. The system hangs in the csq_cleanup() function. A sample stack trace is as follows: csq_cleanup osr_pop_subr osr_close_subr pse_close speclose spec_close vn_close closef close syscall PROBLEM: (HPAQ2157C) (Patch ID: OSF410-405184) ******** This patch fixes a problem in the streams code which could have resulted in data corruption. PROBLEM: (QAR 50783) (Patch ID: OSF410-048) ******** Under some circumstances type ahead characters are not processed if a new line is not entered. This is prevalently seen on screen tools which switch from canonical mode (line process mode) to raw mode. PROBLEM: (HPAQ41AAX STLQ23067 UVO105389 HPAQ116QT HPAQ50RP5 HPAQ400K4 ******** ZPOBA0391 ZPOB60233) (Patch ID: OSF410-090) This is a mandatory patch for all systems. This patch fixes a wide variety of system panics and other problems caused by random memory corruption. The problem has typically shown up at universities, or Internet service providers hosting a lot of streams activity. The following symptoms have appeared in a variety of places throughout the kernel. Corrupted memory buckets are usually the 256-byte size, although they could be any other size. o Lock timeouts o Kernel memory faults o Unaligned kernel accesses A typical stack trace is shown in the following example: 3 panic("pmap_activate lock timeout") 4 pmap_activate() [/src/kernel/arch/alpha/pmap.c":2710] 5 thread_run() [src/kernel/kern/sched_prim.c":2295] 6 idle_thread() [src/kernel/kern/sched_prim.c":3105] In the stack trace above, the lock timed out because the lock structure (at 0xfffffc0067fefe00) appeared to be locked when it really was not. This was due to corruption of the structure by user data that had overflowed from an mblk structure preceding this memory block. To identify whether you have this memory corruption problem you have to look beyond the stack trace. The stack traces will vary considerably, even on the same system, so the only way to identify this problem is to find the corrupted memory bucket and look at the contents. This is a typical 512-byte corrupted memory bucket. The first 17 bytes of data have been overwritten by data that belongs to another thread. The 17 bytes have overflowed from an mblk structure preceding this memory bucket, and have corrupted this memory bucket, overwriting pointers or locks or whatever the first 3 quadwords used to contain. (kdbx) 0xfffffc0067fefe00/32X fffffc0067fefe00: 6918a5e6f04e78d3 cf7814aca7a32d6f fffffc0067fefe10: 0000000000000043 0000000000000000 fffffc0067fefe20: 0000000000000000 fffffffffffffff8 fffffc0067fefe30: 0000000000000000 0000000000000001 fffffc0067fefe40: 000000000044a5cc 000000000000001a ... If you display the block of memory immediately preceding the corrupted memory, you may see an mblk structure there, if it is still around by the time the crash dump takes place. Sometimes the data that has corrupted the memory bucket is readable ASCII, but more often it is unreadable binary data. The number of bytes of data can be anywhere from 1 byte to several quadwords of data. PROBLEM: (CLD MGO103100) (Patch ID: OSF410-136) ******** This patch fixes a problem when printing to slow printers using DIGITAL UNIX LAT through a terminal server. The end of a large file fails to print and no error is reported. Before the line discipline streams module (ldtty) closes, it sleeps for 30 seconds, waiting for the write queue to drain. In this situation, the sleep time needs to be longer. There is a kernel global variable, ldtty_drain_tmo, that specifies this time. This variable can now be patched using dbx. # dbx -k /vmunix (dbx) print ldtty_drain_tmo 30 (dbx) patch ldtty_drain_tmo=60 60 (dbx) quit # Some experimentation may be necessary to find the correct value for a specific customer environment. PROBLEM: (QAR 52115) (Patch ID: OSF410-405080) ******** An application running System V using psuedoterminals may hang if it opens the slave side before the master is open. If the slave side of a System V master psuedoterminal is opened before it is unlocked on the master side via unlockpt(), the calling process will block forever on the open() even after the unlockpt() has been issued and the lock flag lifted from the device. Once the out of sequence race condition occurs, the slave device cannot be opened again by any process until the original hung process is terminated. PROBLEM: (SSRT0476U, QAR53372) (Patch ID: OSF410-405128) ******** A potential security vulnerability has been discovered, where under certain circumstances, a kernel memory fault panic may occur. Digital has corrected this potential vulnerability. The kernel memory fault panic will have a stack trace of the panic'ing process as follows: 1 panic(s = 0xfffffc00006a13e0 = "kernel memory fault") 2 trap() 3 _XentMM() 4 putq_owned 5 putq 6 pts_wput 7 csq_lateral 8 puthere 9 ldtty_wput 10 csq_turnover 11 osr_pop_subr 12 osr_close_subr 13 pse_close 14 speclose 15 clearalias 16 exit 17 rexit 18 syscall 19 _Xsyscall PROBLEM: (CLD ADP-05797) (Patch ID: OSF410-147) ******** A call to the select() system call may hang or incorrectly indicate that there is a message waiting from a terminal when there is nothing there. PROBLEM: (QAR 59061) (Patch ID: OSF410-151) ******** The ASDU netbeui server (nbelink) will not close a connection. It will hang in dlcb_close awaiting a STREAMS event. Subsequently, new connections will not be able to connect to nbelink. This fix corrects a problem introduced by the STREAMS fix to CLD MCGM80LHH/QAR 55462. PROBLEM: (QAR 60582 QAR 62161) (Patch ID: OSF410-405432) ******** This patch fixes a problem in which the system panics with one of the following error messages: simple_lock: uninitialized lock simple_lock_terminate: lock busy The stack traces will look similar to the following: simple_lock: uninitialized lock pc of caller: 0xfffffc00004deecc lock address: 0xfffffc0009d83ca8 lock class name: unknown_simple_lock current lock state: 0x0000000000000000 (cpu=0,pc=0x0,free) simple locks held lock fffffc00008c3980, data c400014d004deec5 panic (cpu 0): simple_lock: uninitialized lock simple_lock_terminate: lock busy pc of caller: 0xfffffc0000489034 lock address: 0xfffffc000a6e9cb8 lock info addr: 0xfffffc00009db370 lock class name: sqh_s.sqh_lock current lock state: 0xc40301370048ae75 (cpu=3,pc=0xfffffc000048ae74,busy) panic (cpu 0): simple_lock_terminate: lock busy PROBLEM: (QAR 63014, QAR 62791) (Patch ID: OSF410-405436) ******** This patch fixes a problem in which the system may panic with the following error message "kernel memory fault". An example panic stack trace might look like: > 0 boot 1 panic 2 trap 3 _XentMM 4 rmvq 5 pts_wput 6 csq_lateral 7 puthere 8 ldtty_bsd43_ioctl 9 ldtty_ioctl 10 ldtty_wput 11 csq_lateral 12 puthere 13 osr_str 14 osr_run 15 pse_ioctl 16 spec_ioctl 17 vn_ioctl 18 ioctl_base 19 ioctl 20 syscall 21 _Xsyscall PROBLEM: (ISO100472) (Patch ID: OSF410-235) ******** This fixes a panic with the following panic string: "pgmv: session leader attempted setpgrp" PROBLEM: (HPAQC032X/QAR 66952) (Patch ID: OSF410-244) ******** This patch fixes an kernel memory fault caused by a streams SMP race condition. This kernel memory fault will have stack traces that may include STREAMS components or kmembucket corruption.