PROBLEM: (MCPM55057 QAR 46617) (Patch ID: OSF375-370033) ******** This patch is an upgrade/replacement for the FAA FDDI driver and fixes a halt/restart problem found in the old driver. The old driver could panic a system with a "simple_lock_fault violation" during a re-initialization. Typical error messages from the old driver will include the following: faa0: Network Adapter halted for re-initialization lock_write: simple lock owned pc of caller: 0xfffffc0000366ca0 lock address: 0xfffffc007fdf6030 lock info addr: 0xfffffc00006542b0 lock class name: vm_kmap.vm_lock pcb slock count: 2 panic (cpu x): lock_write: simple lock owned simple_lock: hierarchy violation pc of caller: 0xfffffc00004227ec lock address: 0xfffffc0079e49200 lock info addr: 0xfffffc00006547a0 class already locked: ifqueue.ifq_slock Typical stack traces from a panic caused by the old driver will include the following: panic lock_fault lock_write vm_map_remove kmem_free faa_free_buff faa_reinitialize faa_error_recovery or panic simple_lock_fault simple_lock_hierarchy_violation xnaintr . . . faa_service_rcv_q faaintr faaintr_2 PROBLEM: (Patch ID: OSF375-370044) ******** Replace Manual Installation Edit Instructions for OSF375-370033 patch in setld patch kit. PROBLEM: (QAR 46828) (Patch ID: OSF375-350252) ******** When a customer-written device driver attempts to return a customer-defined error value that is out of the defined range (0-128), the value EINVAL is returned instead. PROBLEM: (QAR 47488) (Patch ID: OSF375-350252) ******** Fixes a situation in which the SVR4 STREAMS documentation could be violated. It allows a device number to be pushed on the stream. The current patch will set the device number to zero or the actual value. PROBLEM: (HPAQ95241, QAR 50022) (Patch ID: OSF375-350316) ******** This patch fixes a problem that causes the system to panic with "assert_wait" as the message with streams code on the stack. A representative stack trace is: panic(s = "assert_wait") assert_wait_mesg sched_prim.c pts_close pty.c close_wrapper str_subr.c csq_protect str_synch.c osr_pop_subr str_osr.c osr_close_subr str_scalls.c pse_close str_scalls.c speclose spec_vnops.c clearalias spec_vnops.c exit kern_exit.c psig kern_sig.c trap trap.c PROBLEM: (HPAQ41AAX STLQ23067 UVO105389 HPAQ116QT HPAQ50RP5 HPAQ400K4 ******** ZPOBA0391 ZPOB60233) (Patch ID: OSF375-350411) 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: (QAR 52115) (Patch ID: OSF375-350422) ******** 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: (CLD MGO102730) (Patch ID: OSF375-350440) ******** 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: (HPAQ68777) (Patch ID: OSF375-053) ******** This patch fixes a kernel memory fault panic. This panic occurs on systems running System V applications or any user process compiled with the System V environment, even if System V is not loaded on the system. A representative stack trace is: 5 panic("kernel memory fault")subr_prf.c:719 6 trap()trap.c:1243 7 _XentMM()locore.s:1307 8 malloc()kern_malloc.c:743 9 osr_alloc()str_scalls.c:232 10 pse_ioctl()str_scalls.c:1498 11 spec_ioctl()spec_vnops.c:1987 12 syioctl()tty_tty.c:210 13 spec_ioctl()spec_vnops.c:1987 14 vn_ioctl()vfs_vnops.c:1109 15 ioctl_base()sys_generic.c:465 16 ioctl()sys_generic.c:344 17 syscall()syscall_trap.c:519 PROBLEM: (QARs 49942 & 49814) (Patch ID: OSF375-062) ******** 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: (CLD TKTQ42309) (Patch ID: OSF375-082) ******** 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: (CLD TKTB37284) (Patch ID: OSF375-082) ******** 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: (SSRT0476U, QAR53372,QAR 55041) (Patch ID: OSF375-113) ******** 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 MGO103100) (Patch ID: OSF375-134) ******** 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. NOTE: 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 specfic customer environment. PROBLEM: (HPAQ2157C) (Patch ID: OSF375-146) ******** This patch fixes a problem in the streams code which could have resulted in data corruption. PROBLEM: (QAR 57417,CLD MCGM80LHH,CLD MCGM91B24) (Patch ID: OSF375-159) ******** This patch fixes a problem that occurs on an SMP system when running STREAMS. The system panics with the following error message: "kernel memory fault" A sample stack trace is shown as follows: 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2484,] 1 panic(s = 0xfffffc0000687e40 = "kernel memory fault") 2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1525,] 3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1424,] 4 simple_lock_D() ["../../../../src/kernel/arch/alpha/lockprim.s":749,] 5 ptm_wsrv() ["../../../../src/kernel/tty/pty.c":2569,] 6 sq_wrapper() ["../../../../src/kernel/streams/str_runq.c":138,] 7 csq_lateral() ["../../../../src/kernel/streams/str_synch.c":992,] 8 runq_run() ["../../../../src/kernel/streams/str_runq.c":109,] 9 netisr_thread() ["../../../../src/kernel/net/netisr.c":863,] PROBLEM: (QAR 57417,CLD MCGM91B24) (Patch ID: OSF375-159) ******** This patch fixes a problem that occurs on an SMP system when running STREAMS. The system panics with the following error message: "kernel memory fault" A sample stack trace is shown as follows: 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1763,] 1 panic(s = 0xfffffc0000586480 = "kernel memory fault") 2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1243, 0xfffffc000047c614] 3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307,] 4 ldtty_wsrv() ["../../../../src/kernel/tty/ldtty.c":749,] 5 sq_wrapper() ["../../../../src/kernel/streams/str_runq.c":] 6 csq_lateral() ["../../../../src/kernel/streams/str_synch.c":977,] 7 runq_run() ["../../../../src/kernel/streams/str_runq.c":108,] 8 netisr_thread() ["../../../../src/kernel/net/netisr.c"] PROBLEM: (QAR 59061,QAR 60044) (Patch ID: OSF375-159) ******** 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 63014, QAR 62791) (Patch ID: OSF375-240) ******** 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