PROBLEM: (QAR 48449) (Patch ID: OSF405-023) ******** 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: (QARs 49942 & 49814) (Patch ID: OSF405-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: OSF405-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: (CLD TKTQ42309) (Patch ID: OSF405-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: (CLD TKTB37284) (Patch ID: OSF405-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: (CLD MGO102730) (Patch ID: OSF405-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 4closef close syscall PROBLEM: (HPAQ2157C) (Patch ID: OSF405-184) ******** This patch fixes a problem in the streams code which could have resulted in data corruption. PROBLEM: (QAR 50783) (Patch ID: OSF405-051) ******** 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:OSF405-100) 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: OSF405-143) ******** 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. PROBLEM: (USG-03878) (Patch ID: OSF405-028) ******** This patch allows user control messages to be passed between a STREAMS pty pair. This capability was not available in the original released software. PROBLEM: (QAR 52115) (Patch ID: OSF405-080) ******** An application running System V using pseudoterminals may hang if it opens the slave side before the master is open. If the slave side of a System V master pseudoterminal 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: OSF405-128) ******** 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: (QAR 59061) (Patch ID: OSF405-202) ******** 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: (ADP-05797) (Patch ID: OSF405-423) ******** 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 60582 QAR 62161) (Patch ID: OSF405-432) ******** 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: OSF405-436) ******** 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