DUV32FAS00003-19980714 DIGITAL UNIX V3.2F Aggregate ECO Summary

TITLE: DUV32FAS00003-19980714 DIGITAL UNIX V3.2F Aggregate ECO Summary
 
Copyright (c) Compaq Computer Corporation 1998.  All rights reserved.

PRODUCT:    DIGITAL UNIX [R] 3.2F
SOURCE:     Compaq Computer Corporation

ECO INFORMATION:

     ECO Kit Name:  DUV32FAS00003-19980714
     ECO Kit Approximate Size:  39MB 
     Kit Applies To:  DIGITAL UNIX 3.2F


ECO KIT SUMMARY:

An update ECO kit exists for DIGITAL UNIX 3.2F.  This is the aggregate,
setld-based, patch kit for DIGITAL UNIX 3.2F.  It is a cumulative patch kit
that contains all patches that are currently available for distribution.  
The patch kit provides the ability to selectively install patches.

The Release Notes and Installation Instructions document provides patch kit 
installation and removal instructions and a summary of each patch. Please read 
through the document prior to installing patches on your system.

Note:
At this time, the release note/installation document is only available in 
postscript form. It will be available in text and HTML formats in the future.  


INSTALLATION NOTES:

1. Install this kit with the dupatch utility that is included in the patch kit. 
   The Release Notes and Installation Instructions document provides detailed 
   patch installation, patch removal, and a summary of each patch.  You may
   need to baseline your system if you have manually changed system files on 
   your system.  The dupatch utility provides the baselining capability. 

2. The setld-based patch kits DO NOT know about any of the patches provided in 
   previous manual-install official or test patch kits.  A baseline must be set 
   for systems that have been manually patched.  This can be accomplished by 
   selecting option 5 "Patch Baseline Analysis/Adjustment" from the dupatch 
   menu.


SUPERSEDED PATCH LIST:
This patch kit supersedes the following DIGITAL UNIX patches:
   
   DUV32FAS00002-19971001		! Previous Aggregate Patch Kit


KNOWN PROBLEMS WITH THIS PATCH KIT:
   None.


[R] UNIX is a registered trademark in the United States and other countries 
licensed exclusively through X/Open Company Limited.


Copyright Compaq Computer Corporation 1998.  All Rights reserved.

  This software is proprietary to and embodies the confidential technology
  of Compaq Computer Corporation.  Possession, use, or copying of this
  software and media is authorized only pursuant to a valid written license
  from Compaq or an authorized sublicensor.

       This ECO has not been through an exhaustive field test process.
       Due to the experimental stage of this ECO/workaround, Compaq
       makes no representations regarding its use or performance.  The
       customer shall have the sole responsibility for adequate protection
       and back-up data used in conjunction with this ECO/workaround.

===============================================================================

The system panics with kernel memory fault, and the fault_pc is in the 
u_anon_free() routine.
PROBLEM:        (QAR 43968)                 (Patch ID: OSF370-004)
********
The system panics with kernel memory fault, and the fault_pc is in the
u_anon_free() routine.

>  0 stop_secondary_cpu() [arch/alpha/cpu.c":357, 0xfffffc00004d97a8]
   1 panic() [bsd/subr_prf.c":669, 0xfffffc000043d5ac]
   2 event_timeout() [arch/alpha/cpu.c":706, 0xfffffc00004da258]
   3 xcpu_puts() [bsd/subr_prf.c":810, 0xfffffc000043d864]
   4 printf() [bsd/subr_prf.c":355, 0xfffffc000043cbb4]
   5 panic() [bsd/subr_prf.c":719, 0xfffffc000043d71c]
   6 trap() [arch/alpha/trap.c":1213, 0xfffffc00004edbd0]
   7 _XentMM() [arch/alpha/locore.s":1307, 0xfffffc00004dce74]
   8 u_anon_free() [vm/u_mape_anon.c":2261, 0xfffffc00003840e4]
   9 u_anon_unmap() [vm/u_mape_anon.c":1617, 0xfffffc0000382970]
  10 u_map_delete() [vm/vm_umap.c":1188, 0xfffffc000039c650]
  11 u_map_deallocate() [vm/vm_umap.c":436, 0xfffffc000039af80]
  12 vm_map_deallocate() [vm/vm_map.c":611, 0xfffffc0000391698]
  13 task_deallocate() [kern/task.c":472, 0xfffffc00002d6b0c]
  14 waitf() [bsd/kern_exit.c":1497, 0xfffffc0000243b94]
  15 wait4() [bsd/kern_exit.c":1220, 0xfffffc0000243738]
  16 syscall() [arch/alpha/syscall_trap.c":519, 0xfffffc00004eca44]
  17 _Xsyscall() [arch/alpha/locore.s":1094, 0xfffffc00004dcc64]

The crash can be reproduced by running the following sample program:

/*
 * compile as follows:
 *      cc vm_deallocate_tail.c -lmach
 */
main(int argc, char **argv)
{
        long    addr;
        int     ret;

        /*
         * Create a >4G region
         * The system must have >4G swap or must be running in lazy mode
         * (/sbin/swapdefault is not present).
         */
        addr = 0;
        if (ret = vm_allocate(task_self(), &addr, 0x100000000UL, 1)) {
                mach_error("vm_allocate:", ret);
                exit(1);
        }
        /*
         * deallocate the last page
         */
        if (ret = vm_deallocate(task_self(),
                                addr+0x100000000UL-0x2000, 0x2000)) {
                mach_error("vm_deallocate:", ret);
                exit(1);
        }
        exit(0);
}
                   

FILE(s):

/usr/sys/BINARY/vm_anon.o	subset OSFBIN370
CHECKSUM: 18602     73	RCSfile: vm_anon.c  RCS: 1.1.45.2

===============================================================================

This patch fixes a problem where a system with more than one PCI bus will fail 
to configure the loadable device drivers.
PROBLEM:	(42593)			(Patch ID: OSF370-010)
********
This patch fixes a problem where a system with more than one PCI bus will fail 
to configure the loadable device drivers.

You can see that the device drivers are loaded, but they cannot be configured 
or unloaded.


FILE(s):

/usr/sys/BINARY/ldbl_controller_support.o        subset OSFHWBIN350
CHECKSUM: 05453      8  RCSfile: ldbl_controller_support.c  RCS: 1.1.14.3
/usr/sys/BINARY/pci.o                    subset OSFHWBIN370
CHECKSUM: 19277     29  RCSfile: pci.c	RCS: 1.1.111.2
/usr/sys/BINARY/stanza_resolver.o        subset OSFHWBIN350
CHECKSUM: 15866     16  RCSfile: stanza_resolver.c	RCS: 1.1.15.3

===============================================================================

Fixes a problem where a system, with a RAID set for a dump device, will not 
save the crash dump to the RAID set after a panic.
PROBLEM:	(MCPMA0101) 		(Patch ID: OSF370-015)
********
Fixes a problem where a system, with a RAID set for a dump device, will not 
save the crash dump to the RAID set after a panic.

This results in crash dumps not being performed and errors not being logged 
to the error log files.


FILE(s):

/usr/sys/BINARY/ruby_common.o   subset OSFHWBIN370
CHECKSUM: 27962     15  RCSfile: ruby_common.c	RCS: 1.1.34.2

===============================================================================

An ioctl() system call within a user application will fail if the TIOCM_RI flag 
is passed as an argument to this system call.
PROBLEM:	(HPAQ248A7)	(Patch ID: OSF370-365030)
********
An ioctl() system call within a user application will fail if the TIOCM_RI flag
is passed as an argument to this system call.

There are no stack traces associated with this failure, the ioctl() system call 
within an application will fail.

FILE(s):

/usr/sys/BINARY/ace.o           subset OSFHWBIN370
CHECKSUM: 52334     28	RCSfile: ace.c   1.1.80.2

===============================================================================

This patch prevents duplicate namecache entries on SMP systems.  Under heavy 
filesystem lookup operations this can eventually result in a simple lock 
timeout and a system panic.
PROBLEM:  (MCPM750D6, HPXQ36ADF)	 (Patch ID: OSF370-036)
********
A flaw exists in Digital UNIX SMP systems that results in duplicate namecache 
entries being created.  Under heavy file system lookup operations this can 
eventually result in a simple lock timeout and a system panic.

The typical crash data file stack trace will look like the following:

>  0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c"
   1 panic(s = 0xfffffc0000607a98 = "event_timeout: panic request") 
     ["../../../../src/kernel/bsd/subr_prf.c"() 
     ["../../../../src/kernel/arch/alpha/cpu.c"
   3 xcpu_puts() ["../../../ ../src/kernel/bsd/subr_prf.c"
   5 panic(s = "simple_lock: time limit exceeded") 
     ["../../../../src/kernel/bsd/subr_prf.c"
   6 simple_lock_fault(slp = "simple_lock : time limit exceeded") 
     ["../../../../src/kernel/kern/lock.c"
   7 simple_lock_time_violation(slp = caller = (nil)) 
     ["../../../../src/kernel/kern/lock.c "
   8 cache_lookup() ["../../../../src/kernel/vfs/vfs_cache.c"
   9 ufs_lookup() ["../../../../src/kernel/ufs/ufs_lookup.c"
  10 namei() ["../../../../src/kernel/vfs/vfs_lookup.c"
  11 unp_connect() ["../../../../src/kernel/bsd/uipc_usrreq.c"
  12 uipc_usrreq() ["../../../../src/kernel/bsd/uipc_usrreq.c"
  13 sosend() ["../../../../src/kernel/bsd/uipc_s ocket.c"
  14 sendit() ["../../../../src/kernel/bsd/uipc_s yscalls.c"
  15 sendto() ["../../../../src/kernel/bsd/uipc_syscalls.c"
  16 syscall() ["../../../../src/kernel/arch/alpha/syscall_tra
  17 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"


FILE(s):

/usr/sys/BINARY/vfs_cache.o             subset OSFBIN370
CHECKSUM: 56092     56     RCSfile: vfs_cache.c      RCS: 4.2.49.2

===============================================================================

SUPERSEDES PATCHES:	OSF370-008 (8.00), OSF370-009 (9.00),
			OSF370-027 (27.00)

This patch corrects the following:

- A problem that occurs with the NCR 53C8XX driver (psiop) in which the device 
  may not appear to be on the SCSI bus.

- Data corruption due to change in DNAD register behavior on Symbios
  810A/825A/860/875 chips.

- At boot, when probing the psiop driver, the system may continuously loop
  generating the following error message:

    "siopintr: interrupt for non-initialized controller"
PROBLEM:        (QAR 36371)		(Patch ID: OSF370-008, OSF370-009)
********
At boot, when probing the psiop driver, the system may continuously loop
generating the following error message:

    "siopintr: interrupt for non-initialized controller"

This error rarely occurs. Our test cases only encountered it when continuously
rebooting for 18+ hours. To cause the machine to reboot, the system usually
started a "shutdown -r now" as part of the bootup sequence

PROBLEM:	(QAR 46878)		(Patch ID: OSF370-027)
********
Data corruption due to change in DNAD register behavior on Symbios 
810A/825A/860/875 chips.

This data corruption problem is difficult to detect as no error report, etc.
is given when it occurs. The data corruption can be identified by the pattern 
in the corrupted data. Commonly, at the point of corruption, there will be 3 
bytes of unknown data inserted into the valid data stream.

This problem is induced by a chip register behavior change between the 810 and 
810a. The register (DNAD) is used to calculate the next dma address whenever a 
dma transfer is interrupted by a phase change by the scsi device.

This problem can be reproduced using the UEG engineering test script 
"dt_tag_rotate_sh" which tests unaligned data accesses.

PROBLEM:	(49240)	 		(Patch ID: OSF370-040)
********
This patch fixes a problem that occurs with the NCR 53C8XX driver (psiop).

In rare cases when negotiating sync xfr rates, the driver may reject the 
target's Synchronous Transfer Negotiation, even if the target replied with a 
synchronous offset equal to zero, thereby implying asynchronous transfers.

A device not expecting this behavior may not appear to be connected to the 
system.

The RW531 Optical Jukebox, with Rev 0.37 firmware or later, does not expect 
this behavior and will exhibit the symptoms of the optical disk devices 
appearing on the SCSI bus, but not the changer devices.


FILE(s):

/usr/sys/BINARY/psiop.o 	    subset OSFHWBIN370
CHECKSUM: 21323    176     RCSfile: psiop.c           RCS: 1.1.65.5
/usr/sys/BINARY/psiop_pci.o 	    subset OSFHWBIN370
CHECKSUM: 29754     27	   RCSfile: psiop_pci.c       RCS: 1.1.49.3
/usr/sys/include/io/cam/siop/pci_scripthost.h 	subset OSFBINCOM370
CHECKSUM: 00415     17	   RCSfile: pci_scripthost.h  RCS: 1.1.37.2

===============================================================================

SUPERSEDES PATCHES:	OSF370-039 (39.00)

This patch corrects the following:

- Fixes problem on AlphaServer 2100A system; when the system is shut
  down using the "shutdown -r" command, the system will not reboot.

- Alphaserver 2100A system crashes during boot with greater than 1GB of 
  memory installed.
PROBLEM:  (EMZB83716, QAR 48019)	 (Patch ID: OSF370-039)
********
The Unix kernel crashes during installation if the memory in the system exceeds 
1GB.  This has only been seen on AlphaServer 2100A class systems with greater 
than 1GB of memory.

During driver initialization, a machine check 660 such as the following occurs:

Alpha boot: available memory from 0x29be000 to 0x7fffe000
Digital UNIX V4.0 (Rev. 386); Mon May 20 04:41:58 EDT 1996
physical memory = 2048.00 megabytes.
available memory = 2006.31 megabytes.
using 2618 buffers containing 20.45 megabytes of memory
Master cpu at slot 0.
Firmware revision: 4.5
PALcode: OSF version 1.21
ibus0 at nexus
AlphaServer 2100 5/250
cpu 0 EV-5 4mb b-cache
cpu 1 EV-5 4mb b-cache
gpc0 at ibus0
pci0 at ibus0 slot 0
tu0: DECchip 21040-AA: Revision: 2.3
Machine Check SYSTEM Fatal Abort
 pal temp[0-1]           = d02cadc77bdecdf9 0000000000000006
 pal temp[2-3]           = fffffc00004042a0 0000000000004200
 pal temp[4-5]           = 0000008180000000 0000000380000000
 pal temp[6-7]           = 0000000198000000 fffffc0000403cf0
 pal temp[8-9]           = 1f1e161514020100 fffffc0000404010
 pal temp[10-11]         = fffffc0000407704 fffffc0000403e70
 pal temp[12-13]         = fffffc0000404210 000ic (cpu 0): System Uncorrectable
Machine Check 660
...


PROBLEM:        (MCSM715R1)     (Patch ID: OSF370-058)
********
When the system is shut down using the "shutdown -r" command,
the system will not reboot.


FILE(s):

/usr/sys/BINARY/cbus2_pci.o         		subset OSFHWBIN370
CHECKSUM: 14634     53	RCSfile: cbus2_pci.c	RCS: 1.1.40.3
/usr/sys/include/arch/alpha/hal/cbus2_pci.h	subset OSFHWBINCOM370
CHECKSUM: 38001     36	RCSfile: cbus2_pci.h	RCS: 1.1.16.2

===============================================================================

Fixes a problem in which the io_zero() system call returns
an incorrect value on an AlphaServer 1000.
PROBLEM:        (QAR  51566 QAR 49877)  (Patch ID: OSF370-059)
********
This patch fixes a problem in which the io_zero() system call returns
an incorrect value on an AlphaServer 1000.

The io_zero() system call now returns "IOA_OKAY".


FILE(s):

/usr/sys/BINARY/apecs.o         	subset OSFHWBIN370
CHECKSUM: 18215     20  RCSfile: apecs.c        RCS: 1.1.50.2
/usr/sys/BINARY/lca.o           	subset OSFHWBIN370
CHECKSUM: 06954     21  RCSfile: lca.c          RCS: 1.1.53.2

===============================================================================

Crash-dumps to non-re0 RAID devices broken on all PCI & EISA machines.
PROBLEM:	(QAR 46654)		(Patch ID: OSF370-365025)
********
When a system crash is attempted to a RAID disk that is anything but device
"re0", the crash dump will fail.

The typical (console) error message will look something like this:
 (this is a dump to re3):
DUMP: 8482815 blocks available for dumping.
DUMP: 524273 required for a full dump.
DUMP: Our last 524272 goes in the 8220671 on 0xb00082, starting at 0
DUMP.prom: dev RAID 1 3 0 3 3 0 0, block 131072
DUMP.prom: I/O error on RAID 1 3 0 3 3 0 0: bn = 262143, status = -1
                                   ^.............
the error is that the 5th field should be zero -'
This problem can be reproduced on a PCI or EISA machine with a RAID controller 
(SWXCR-xx) by forcing a system crash when the swap device is anything but re0.  
To force a system crash, refer to the Guide to Kernel Debugging, section 4.7.


FILE(s):

/usr/sys/BINARY/console.o		 subset OSFHWBIN370
CHECKSUM: 47029     12	RCSfile: console.c   RCS:  1.1.76.2

===============================================================================

SUPERSEDES PATCHES: 	OSF370-350104 (105.00)

This patch corrects the following:

- Fixes a problem where processes will hang in an uninterruptable state while 
  using NFS loopback mounts.

- Kernel memory fault in ubc_sync_iodone().
PROBLEM:	(MCPMC8AC6) 		(Patch ID: OSF370-350104)
********
The panic was seen when a large number (~150) of "fastdd" is run using seperate
LSM raw volumes and writing to UFS files.  UBC must be constrained as follows:

	ubc-minpercent=1
	ubc-maxpercent=20
  ...
  13 boot() [arch/alpha/machdep.c":1679, 0xfffffc000045a674]
  14 panic() [bsd/subr_prf.c":757, 0xfffffc0000419d54]
  15 trap() [arch/alpha/trap.c":1213, 0xfffffc0000468600]
  16 _XentMM() [arch/alpha/locore.s":1307, 0xfffffc00004578a4]
  17 ubc_sync_iodone() [vfs/vfs_ubc.c":1022, 0xfffffc0000298ddc]
  18 ufs_rwblk() [ufs/ufs_vnops.c":4427, 0xfffffc000027a488]
  19 ufs_writepages() [ufs/ufs_vnops.c":5385, 0xfffffc000027c15c]
  20 ufs_putpage() [ufs/ufs_vnops.c":5187, 0xfffffc000027bc38]
  21 ubc_page_alloc() [vfs/vfs_ubc.c":2144, 0xfffffc000029ba00]
  22 ubc_lookup() [vfs/vfs_ubc.c":1789, 0xfffffc000029aa70]
  23 ufs_getapage() [ufs/ufs_vnops.c":4797, 0xfffffc000027afbc]
  24 ufs_getpage() [ufs/ufs_vnops.c":5112, 0xfffffc000027ba5c]
  25 ufs_rwip() [ufs/ufs_vnops.c":5859, 0xfffffc000027cd44]
  26 ufs_write() [ufs/ufs_vnops.c":1771, 0xfffffc0000276b00]
  27 vn_write() [vfs/vfs_vnops.c":932, 0xfffffc00002973a0]
  28 rwuio() [bsd/sys_generic.c":1071, 0xfffffc0000250bec]
  29 write() [bsd/sys_generic.c":996, 0xfffffc0000250a78]
  30 syscall() [arch/alpha/syscall_trap.c":519, 0xfffffc0000467474]
  31 _Xsyscall() [arch/alpha/locore.s":1094, 0xfffffc0000457694]

PROBLEM:	(HPAQC3A71)	(Patch ID: OSF370-360024)
********
This patch fixes a problem where processes on a system may block in an 
uninterruptible state and never run again.

This problem occurs when using NFS loopback mounts.  The stack trace of the 
current running processes on the system will not display a problem.  Although, 
if the stack trace of the blocked processes is displayed and the trace for some
of the kernel's NFS server threads is displayed - it may look similar to the 
following:

THIS IS THE STACK TRACE FOR THE CLIENT:

>  0 thread_block() [kern/sched_prim.c":1903]
   1 mpsleep() [bsd/kern_synch.c":441]
   2 clntkudp_callit_addr() [rpc/clnt_kudp.c":631]
   3 clntkudp_callit() [rpc/clnt_kudp.c":1008]
   4 rfscall() [nfs/nfs_subr.c":837]
   5 rfs3call() [nfs/nfs_subr.c":974]
   6 nfs3commit() [nfs/nfs3_vnodeops.c":3754]
   7 nfs3_putpage() [nfs/nfs3_vnodeops.c":3528]
   8 ubc_page_alloc() [vfs/vfs_ubc.c":2145]
   9 ubc_lookup() [vfs/vfs_ubc.c":1789]
  10 page_lookup() [msfs/bs/bs_buffer2.c":872]
  11 bs_pinpg_one_int() [msfs/bs/bs_buffer2.c":3218]
  12 bs_pinpg_clone() [msfs/bs/bs_buffer2.c":2877]
  13 bs_pinpg() [msfs/bs/bs_buffer2.c":2371]
  14 fs_write() [msfs/fs/fs_read_write.c":515]
  15 msfs_write() [msfs/osf/msfs_vnops.c":1547]
  16 vn_write() [vfs/vfs_vnops.c":932]
  17 rwuio() [bsd/sys_generic.c":1071]
  18 write() [bsd/sys_generic.c":996]
  19 syscall() [arch/alpha/syscall_trap.c":519]
  20 _Xsyscall() [arch/alpha/locore.s":1094]

THIS IS THE STACK TRACE FOR THE SERVER THREAD WHICH WOKE UP TO HANDLE THE ABOVE
CLIENT's REQUEST:

>  0 thread_block() [kern/sched_prim.c":1891]
   1 mpsleep() [bsd/kern_synch.c":441]
   2 clntkudp_callit_addr() [rpc/clnt_kudp.c":631]
   3 clntkudp_callit() [rpc/clnt_kudp.c":1008]
   4 rfscall() [nfs/nfs_subr.c":837]
   5 rfs3call() [nfs/nfs_subr.c":974]
   6 nfs3commit() [nfs/nfs3_vnodeops.c":3754]
   7 nfs3_putpage() [nfs/nfs3_vnodeops.c":3528]
   8 ubc_page_alloc() [vfs/vfs_ubc.c":2145]
   9 ubc_lookup() [vfs/vfs_ubc.c":1789]
  10 page_lookup() [msfs/bs/bs_buffer2.c":872]
  11 bs_pinpg_one_int() [msfs/bs/bs_buffer2.c":3218]
  12 bs_pinpg_clone() [msfs/bs/bs_buffer2.c":2877]
  13 bs_pinpg() [msfs/bs/bs_buffer2.c":2371]
  14 get_clean_pg() [msfs/bs/ms_logger.c":1495]
  15 lgr_writev_ftx() [msfs/bs/ms_logger.c":1258]
  16 log_donerec_nunpin() [msfs/bs/ftx_routines.c":2719]
  17 ftx_done_urdr() [msfs/bs/ftx_routines.c":1215]
  18 ftx_done_n() [msfs/bs/ftx_routines.c":968]
  19 msfs_fsync() [msfs/osf/msfs_vnops.c":1650]
  20 rfs3_commit() [nfs/nfs3_server.c":5671]
  21 rfs_dispatch() [nfs/nfs_server.c":6333]
  22 nfs_rpc_input() [rpc/svc.c":717]
  23 nfs_input() [nfs/nfs_server.c":5492]
  24 nfs_thread() [nfs/nfs_server.c":5277]

THIS IS THE STACK TRACE FOR A SERVER THREAD WHICH WOKE UP TO HANDLE THE ABOVE 
SERVER's REQUEST:

>  0 thread_block() [kern/sched_prim.c":1891]
   1 thread_sleep() [kern/sched_prim.c":1581]
   2 _cond_wait() [msfs/bs/ms_generic_locks.c":592]
   3 _lk_lock() [msfs/bs/ms_generic_locks.c":931]
   4 lgr_writev_ftx() [msfs/bs/ms_logger.c":1236]
   5 log_donerec_nunpin() [msfs/bs/ftx_routines.c":2719]
   6 ftx_done_urdr() [msfs/bs/ftx_routines.c":1215]
   7 ftx_done_n() [msfs/bs/ftx_routines.c":968]
   8 bs_sync_bf_flush() [msfs/bs/bs_qio.c":2402]
   9 msfs_fsync() [msfs/osf/msfs_vnops.c":1608]
  10 rfs3_commit() [nfs/nfs3_server.c":5665]
  11 rfs_dispatch() [nfs/nfs_server.c":6333]
  12 nfs_rpc_input() [rpc/svc.c":717]
  13 nfs_input() [nfs/nfs_server.c":5492]
  14 nfs_thread() [nfs/nfs_server.c":5277]


FILE(s):

/usr/sys/BINARY/vm_cfg.o         subset OSFBIN370
CHECKSUM: 58472      7  RCSfile: vm_cfg.c  RCS: 1.1.31.2
/usr/sys/BINARY/vfs_ubc.o	 subset OSFBIN350
CHECKSUM: 59465     54  RCSfile: vfs_ubc.c  RCS: 1.1.118.3

===============================================================================

SUPERSEDES PATCHES:	OSF370-360037 (71.00)

This patch corrects the following:

- A problem in which PATHWORKS client does not see all the files in a directory 
  when the directory is an NFS mounted OpenVMS UCX exported directory.

- Fixes a problem in which mmap activity to a file that is NFS mounted may 
  cause the client process to hang after the file is deleted.
PROBLEM:	(QAR 33924)	(Patch ID: OSF370-360037)
********
This patch fixes a problem in which mmap activity to a file that is NFS mounted
may cause the client process to hang after the file is deleted.

PROBLEM:  (MGO101779, QAR 46334) (Patch ID: OSF370-360050)
********
This patch fixes a problem in which PATHWORKS client does not see all the files
in a directory when the directory is an NFS mounted OpenVMS UCX exported 
directory.

On an Digital UNIX system a nfs mount to a VMS-UCX system exists.  For this 
mount point a share is setup in Pathworks.

PCs connect to this share and don't see all files of this VMS directory, some 
files and subdirectories are missing.  But on the pc it is possible to type the
files which are not seen or it is possible to do a cd to the directory which is
not seen.  In Pathworks the user has all permissions for that share so he can 
read all files, he can delete the file but it is not possible to write a file 
to this directory.

The same files which are seen on DOS are shown in
  PWADMIN - Shared Resources - Permit!

Examples:
1. It is not possible to see the file x.txt.
   If x.txt is renamed to a.txt then the file is seen in the directory listing.

2. It is not possible to copy a file to this share (drive X)
   COPY C:\CONFIG.SYS X: returns the error
   File not found - X:CONFIG.SYS
   0 Files copied
   ---------------
There is no problem in the directory listing if ls command is executed
on Digital UNIX.  Besides ls -al displays root as owner for every file.


FILE(s):

/usr/sys/BINARY/nfs_vnodeops.o   subset OSFBIN370
CHECKSUM: 32783     42  RCSfile: nfs_vnodeops.c   RCS: 1.1.104.7
/usr/sys/BINARY/nfs3_vnodeops.o  subset OSFBIN370
CHECKSUM: 37658     50  RCSfile: nfs3_vnodeops.c  RCS: 1.1.56.3

===============================================================================

The ar command's -x option, which extracts archive files, may, in error, return 
a message stating that the file was not found.
PROBLEM:  (DJOB3K133, QAR 46595)	 (Patch ID: OSF370-360062)
********
The ar command's -x option, which extracts archive files, may in error, return 
a message stating that the specified archive file was not found.

To duplicate the problem, create a library with the command
  'ar r /tmp/foo.a /tmp/bar.o'.

Issuing the command 'ar -x /tmp/foo.a /tmp/bar.o' will generate the message
  "ar: Error: /tmp/bar.o not found"
even though the file exists in the archive.

With the fix, the same command extracts /tmp/bar.o from /tmp/foo.a without 
generating an error message.

 
FILE(s):

/usr/ccs/lib/cmplrs/cc/ar           subset OSFBASE370
CHECKSUM: 25220    376     RCSfile: ar.c       RCS: 4.2.33.2
			   RCSfile: bsearch.c  RCS: 4.2.6.3

===============================================================================


This patch corrects the following:

- This patch allows system managers to both set and obtain quotas for users 
  and groups which are numeric when using the edquota, vedquota, quota and 
  vquota programs.  It also provides new options to allow them to specify 
  userids and groupids.
PROBLEM:  (HPXQ87072, QAR 46521)	 (Patch ID: OSF370-360064-1)
********
This patch allows system managers to both set and obtain quotas for users and 
groups which are numeric when using the edquota, vedquota, quota and vquota 
programs. It also provides new options to allow them to specify userids and 
groupids.

In the past, when the input to these commands was a numeric username or
groupname, the commands would either report that the name couldn't be found,
or would interpret it as the wrong user or group (when the name coincidentally 
matched a valid userid or groupid).

For circumstances where the user wishes to specify userid or groupid the -U and
-G options have been added.

This correction also extends the edquota and vedquota prototype option to allow 
convenient use of names and ids. In the past a numeric argument to the "-p" 
option was incorrectly considered an id, not a name.  Now, the argument to "-p"
will always refer to a name while the argument to the new option "-P" will 
refer to an id.

Examples

To apply the quotas of user1 to user2, specifying both by their names:
    edquota -p user1name user2name

To apply the quotas of user1 (specified by id), to user2 (specified by id):
    edquota -P user1id -U user2id

Also, note that new versions of the message catalogue files are issued for each
of the programs. These must be updated only if they are on the system.
 

FILE(s):

/usr/lib/nls/msg/en_US.ISO8859-1/edquota.cat          subset OSFBASE350
CHECKSUM: 26567      2
/usr/lib/nls/msg/en_US.ISO8859-1/quota.cat            subset OSFBASE350
CHECKSUM: 60092      1
/usr/sbin/edquota                   subset OSFBASE370
CHECKSUM: 30231    112     RCSfile: edquota.c      RCS: 4.2.29.2
/usr/sbin/quota                     subset OSFBASE370
CHECKSUM: 61455    112     RCSfile: quota.c        RCS: 4.2.39.2
			   RCSfile: rquotaxdr.c    RCS: 4.2.4.2
/usr/sbin/vedquota                  subset OSFADVFS370
CHECKSUM: 38644    568     RCSfile: vedquota.c     RCS: 1.1.28.2
/usr/sbin/vquota                    subset OSFADVFS370
CHECKSUM: 02462    512     RCSfile: vquota.c       RCS: 1.1.25.2

===============================================================================

SUPERSEDES PATCHES:	OSF370-360052 (280.00)

This patch corrects the following:
                                    
- Fixes a "simple_lock: time limit exceeded" panic originating from either:
    o ctape_close() routine
    o ctape_strategy() routine
                                 
- This patch fixes "simple_lock: time limit exceeded" panics coming from 
  ctape_close() or ctape_strategy() routines.
PROBLEM:	(MCPM36085)	(Patch ID: OSF370-360052)
********
A "simple_lock: time limit exceeded" panic will be seen originating from the 
ctape_close() routine.  The stack trace is as follows:

   6 panic("simple_lock: time limit exceeded")
   7 simple_lock_fault()
   8 simple_lock_time_violation()
   9 ctape_close()
  10 speclose()
  11 spec_close()
  12 ufsspec_close()
  13 vn_close()
  14 closef()
  15 close()
  16 syscall()
  17 _Xsyscall()

PROBLEM:	(UVO104133)	(Patch ID: OSF370-360052)
********
A "simple_lock: time limit exceeded" panic will be seen originating from the 
ctape_strategy() routine.  The stack trace is as follows:

   9 panic("simple_lock: time limit exceeded")
  10 simple_lock_fault()
  11 simple_lock_time_violation()
  12 ccmn_rsq_ccb_bld()
  13 ctape_strategy()
  14 physio()
  15 ctape_write()
  16 spec_write()
  17 ufsspec_write()
  18 vn_write()
  19 rwuio()
  20 write()
  21 syscall()
  22 _Xsyscall()


PROBLEM:        (MCPMB61A4)     (Patch ID: OSF370-360078)
********
This patch fixes a "simple_lock: time limit exceeded".

The following is a list of the typical error messages displayed in the
preserved message buffer when the panic occurs:

  simple_lock: time limit exceeded

    pc of caller:         0xfffffc00005265ec
    lock address:         0xfffffc007f5f3ad0
    current lock state:   0x00000000005264c5
(cpu=0,pc=0xfffffc00005264c4,busy)

  panic (cpu 12): simple_lock: time limit exceeded

simple lock timeout pc?5i and lock address?5i

(dbx) 0xfffffc00005265ec?5i
  [ctape_close:2669, 0xfffffc00005265ec]        addq    r31, 0x4, r16
  [ctape_close:2669, 0xfffffc00005265f0]        bsr     r26, swap_ipl(line 131)
  [ctape_close:2669, 0xfffffc00005265f4]        stl     r0, 176(sp)
  [ctape_close:2669, 0xfffffc00005265f8]        bis     r9, r9, r16
  [ctape_close:2669, 0xfffffc00005265fc]        bsr     r26, simple_lock(line 26
6)
(dbx) 0xfffffc00005264c4?5i
  [ctape_close:2601, 0xfffffc00005264c4]        addq    r31, 0x4, r16
  [ctape_close:2601, 0xfffffc00005264c8]        bsr     r26, swap_ipl(line 131)
  [ctape_close:2601, 0xfffffc00005264cc]        stl     r0, 176(sp)
  [ctape_close:2601, 0xfffffc00005264d0]        bis     r9, r9, r16
  [ctape_close:2601, 0xfffffc00005264d4]        bsr     r26, simple_lock(line 26
6)

This indicates the code that was improperly holding the lock.

Stack Trace for this problem:

   panic("simple_lock: time limit exceeded") ["../../../../src/kernel/bsd/subr_p
rf.c":757]
   simple_lock_fault() ["../../../../src/kernel/kern/lock.c":1794]
   simple_lock_time_violation() ["../../../../src/kernel/kern/lock.c":1863]
   ctape_close() ["../../../../src/kernel/io/cam/ cam_tape.c":2669]
   speclose() ["../../../../src/kernel/vfs/spec_vnops.c":2306]
   spec_close() ["../../../../src/kernel/vfs/spec_vnops.c":2459] 
   msfsspec_close() ["../../../../src/kernel/msfs/osf/msfs_vnops.c":3869]
   vn_close() ["../../../../src/kernel/vfs/vfs_vnops.c":1220]
   closef() ["../../../../src/kernel/bsd /kern_descrip.c":1393]
   close() ["../../../../src/kernel/bsd/kern_descrip.c":1071]


FILE(s):

/usr/sys/BINARY/cam_tape.o          subset OSFHWBIN370
CHECKSUM: 50865    146	RCSfile: cam_tape.c   RCS: 1.1.73.2

===============================================================================

A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
PROBLEM:	(SSRT0329U, USG-01683)	      (Patch ID: OSF370-350061)
********
A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.


FILE(s):

/usr/bin/rdist  		 subset OSFINET350
CHECKSUM: 23263     88  RCSfile: server.c  RCS: 4.2.21.2

===============================================================================

The bootp daemon appends a null character to file names in its responses.
PROBLEM:	(BRO100554)	      (Patch ID: OSF370-350073)
********
The bootp server daemon, /usr/sbin/bootpd, appends a null byte to filenames
in its responses.  Some BOOTP clients will fail to boot when they receive
these responses.  The response packets will contain the null byte appended to
any filenames and the cooresponding length fields will count the null byte.


FILE(s):

/usr/sbin/bootpd                 subset OSFINET350
CHECKSUM: 19997     72  RCSfile: bootpd.c	RCS: 4.2.25.2
			RCSfile: dovend.c	RCS: 1.1.8.2
			RCSfile: readfile.c	RCS: 4.2.12.2

===============================================================================

Corrections to tftpd when using interface aliases, bind() uses the client's 
address received rather than INADDR_ANY.  This fix accomodates bootpd when
used with ASE for failover purposes.
PROBLEM:	(HPAQA69B2,QAR40362)		(Patch ID: OSF370-350089)
********
Attempting to tftpd to an aliased interface will give "ICMP Destination 
unreachable" messages when multiple read requests are required to transfer data.

Typical Error Messages are "ICMP Destination unreachable" or "Port unreachable".

To reproduce the problem, tftp to an aliased interface and transfer a file
larger than 512 bytes.  The transfer will require multiple read requests
and will return an error on the second read request.


FILE(s):

/usr/sbin/tftpd        		 subset OSFINET350
CHECKSUM: 55861     32	RCSfile: tftpd.c  RCS: 4.2.11.2

===============================================================================

Fix acctcms hash table overflow error.
PROBLEM:        (TKTQ22355) 		(Patch ID: OSF370-350096)
********
When there are more than 1000 different commands in the accounting
source files, acctcms gives the error "Hash table overflow. Increase
CSIZE" and ignores the command accounting records of those commands
in excess of 1000.  This problem can also be seen when running
runacct, the daily accounting procedure, because it uses acctcms


FILE(s):

/usr/sbin/acct/acctcms 		 subset OSFACCT350
CHECKSUM: 37955     32  RCSfile: acctcms.c  RCS: 4.2.18.2

===============================================================================

Program using libexc.a suffer corrupted signal masks.
PROBLEM:	(EVT101544) 		(Patch ID: OSF370-350102)
********
Programs linked with the libexc.a library can have their process signal masks 
corrupted while handling exceptions at runtime. The problem shows up when the 
process stops responding to signals.  The ps -s command shows a mask of random 
signals blocked, including the one required to make the program function 
correctly.

Ada and C++ programs seems to the most likely to experience the program.


FILE(s):

/usr/ccs/lib/cmplrs/cc/libexc.a	  subset OSFCMPLRSEXT350
CHECKSUM: 21801     23

===============================================================================

Correct nfs server duplicate request problem, by adding timestamps.
PROBLEM:	(MGO101612)		(Patch ID: OSF370-350109)
********
Fixes file corruption on a Digital UNIX NFS fileserver serving a sole single 
non-Digital NFS client. Problem originally encountered when the only client 
was an OS/2 client.

This patch should be installed if you observe server corruption and can bypass 
that corruption by setting the kernel global variable 'kudp_usedrc' to zero.

Do not consider turning off duplicate record checking (drc) as a solution.
Instead, please use this patch to correctly fix the problem.
	

FILE(s):

/usr/sys/BINARY/svc_kudp.o	 subset OSFBIN350
CHECKSUM: 49986     86  RCSfile: svc_kudp.c	RCS: 1.1.23.2

===============================================================================

Running tip(1) consumes about 45% of cpu time, resulting in no idle time, even
if tip is about the only thing running on the system.
PROBLEM:	(SOO100598)		(Patch ID: OSF370-350111)
********
Running tip will use approximately 45% of CPU time.  

Use "ps -Ocpu" to see CPU usage.  Also, running vmstat will show 0% IDle time.

# vmstat 5
Virtual Memory Statistics: (pagesize = 8192)
procs    memory        intr        cpu      
r  w  u  act  free wire   in  sy  cs  us  sy  id
3 73 16  1805  129  802    36 70K 245  10  90   0
3 73 16  1805  129  802     3 71K 239  10  90   0
3 73 16  1806  128  802   102 67K 306  10  90   0

#  ps -Opcpu | grep tip
PID   %CPU S    TT           TIME    COMMAND
14058 46.0 U  + ttyp4        0:09.64 tip
14092  0.0 U  + ttyp1        0.01    grep tip


FILE(s):

/usr/bin/tip            	 subset OSFCLINET350
CHECKSUM: 56943    120	RCSfile: tip.c	RCS: 4.2.21.2
			RCSfile: tipout.c RCS: 4.2.4.3

===============================================================================

A potential security vulnerability has been discovered where under certain 
circumstances users may gain unauthorized access.  Digital has corrected this 
potential vulnerability.
PROBLEM:	(QAR 41986) 		(Patch ID: OSF370-350112)
********
A potential security vulnerability has been discovered where under certain 
circumstances users may gain unauthorized access.  Digital has corrected this 
potential vulnerability.


FILE(s):

/usr/sbin/lattelnet     	 subset OSFLAT350
CHECKSUM: 33705     24  RCSfile: lattelnet.c  RCS: 1.1.16.2

===============================================================================

This patch fixes a problem with assembler which was causing the following
error message while trying to assemble a valid program:

      as1: Internal: filename, line ###: st_pdn_idn: idn (huge_integer) 
      less than 0 or greater than max (111)
PROBLEM:        (QAR 43009, 41198)              (Patch ID: OSF350-114)
********
Fix problem with assembler which was causing the following error
message while trying to assemble a valid program:

 as1: Internal: filename, line ###: st_pdn_idn: idn (huge_integer)
      less than 0 or greater than max (111)

This may be encountered by customers writing assembly language programs
which make use of the .edata directive.

Removal/replacement of the .edata directives can make this behavior
appear and disappear.


FILE(s):

/usr/ccs/lib/cmplrs/cc/as0      subset OSFCMPLRS350
CHECKSUM: 50428    488

===============================================================================

Card lockup problem using the ATM IP convergence module.
PROBLEM:	(HPXQC2E60,QAR 42749)	 	(Patch ID: OSF370-350115)
********	
Card lockup problem using the ATM IP convergence module.

How to recognize the problem:

 In the kern.log file you can see messages similar to:

  Dec 19 11:06:47 bcaryf03 vmunix: received 144 bytes for non-existent VC 50

 and if you have set up a simple test between two systems using a ping over
 the ATM interface, you will see that the signalling between VC's which have
 been sending and receiving throughout the test will suddenly stop receiving
 packets.  The VC's will continue to be able to send packets.

How to reproduce the problem:

 Setup two nodes A and B connected through a FORE switch and an ATM IP
 PVC between the two.

 From node B, issue the ping command over ATM IP. (leave the ping command
 running)

 On node A, remove the ATM IP PVC which is receiving the ping using the command
   "atmconfig -pvc driver=lta0 vpi=0 vci=50"

 In the kern.log file you will see a message like:

   Dec 19 11:06:47 bcaryf03 vmunix: received 144 bytes for non-existent VC 50

 and the output of an atmconfig vclist long will show you that the signalling
 between VC's sending and receiving throughout the test will suddenly stop
 receiving packets.


FILE(s):

/usr/sys/BINARY/if_otto.o        subset OSFATMBIN350
CHECKSUM: 30182     40  RCSfile: if_otto.c	RCS: 1.1.19.2

===============================================================================

When using the command /usr/sbin/strace to get STREAMS event trace messages
from STREAMS drivers and modules via the STREAMS log driver (strlog), this
patch fixes a STRLOG bug which causes concatenation of sequential outputs.
PROBLEM:        (QAR 38773)		(Patch ID: OSF370-350130)
********
The strace command gets STREAMS event trace messages from STREAMS drivers
and modules via the STREAMS log driver (strlog).  STRLOG had a bug that
caused concatenation of sequential outputs.


FILE(s):

/usr/sys/BINARY/log.o            subset OSFBIN350
CHECKSUM: 09250      8  RCSfile: log.c  RCS: 4.2.18.2

===============================================================================

When a user changes virtual memory (vm) tuning parameters due to slow 
performance and reboots the machine, the system panics. 
PROBLEM:	(ISO100191,42778)	(Patch ID: OSF370-350138)
********
When a user changes virtual memory (vm) tuning parameters due to slow
performance and reboots the machine, the system panics.  This can occur when
setting vm tuning parameters to improve X Windows performance in systems under
heavy memory loads.  This problem is commonly referred to as "window freeze"
and was first discovered on Alphastation 500/600's. Note, the problem is not
exclusive to 500/600's.

The following is an example of a system panic:

Digital UNIX boot - Tue Jan 30 21:31:11 EST 1996

Loading vmunix ...
Loading at fffffc0000230000
Current PAL Revision <0x1000000010111>
Switching to OSF PALcode Succeeded
New PAL Revision <0x1000000020115>

Sizes:
text = 4149488
data = 777600
bss  = 2298896
Starting at 0xfffffc00004cb8f0


trap: invalid memory read access from kernel mode

    faulting virtual address:     0x0000000000000040
    pc of faulting instruction:   0xfffffc00004b2080
    ra contents at time of fault: 0xfffffc00004b207c
    sp contents at time of fault: 0xffffffffffff78c0

panic (cpu 0): kernel memory fault

DUMP: No primary swap, no explicit dumpdev.
          Nowhere to put header, giving up.

halted CPU 0

halt code = 5
HALT instruction executed
PC = fffffc00004cd350
>>>

WORKAROUND:

Apply this patch and determine whether the vm tuning parameters should be
adjusted.  The guidelines for changing vm tuning parameters are listed below.

VERIFICATION / VM TUNING PARAMETER ADJUSTMENTS:

The windowing system on AlphaStation 500/600's may experience poor window 
response in a heavy paging environment.  Although this problem occurs 
on all platforms, it is most pronounced on AlphaStation 500/600's.

Mouse movement on the system is uneffected, but windowing operations such as 
exposing a window, dragging a window, and so on, are degraded.  When this 
condition occurs, you may not be able to telnet or rlogin to the system.  These
symptoms can occur for some period of time (greater than 2 minutes), or may 
subside after a few seconds. The cause of these symptoms is due to a memory 
intensive application(s) depleting the number of pages on the free list to an 
absolute minimum.  When this occurs, only privileged tasks are able to get 
memory (for example, free pages) and all others tasks are blocked (in this 
case the window manager).

Check to see if your system is experiencing this problem by running "vmstat 2"
in a separate xterm while your application(s) are running. Your system will
display output similar to the following:

#
  vmstat 2
Virtual Memory Statistics: (pagesize = 8192)
  procs    memory         pages                          intr	     cpu
  r  w  u  act  free wire fault cow zero react pin pout  in  sy  cs  us sy  id
  2 37 15  5832 4021 1108  20K 5975 4575  285 4761    0  62 196 266   1 1  98
  2 37 15  5851 4002 1108   99   13   50    0    8    0   4  13 239   0 1  99
  3 37 15  7039 2788 1134   26    0   26    0    0    0  17  51 255   1 9  90
  3 37 15  9791   10 1140 7291   17 7258    0   13   48 288  12 422   1 68  31
  3 37 15  9790    9 1149 1049    0 1048   39    1  146 472  15 527   0 32  68
  3 36 15  9784    9 1116  743    0  741    0    2  106 446  12 466   0 22  78
  3 36 15  9811    9 1096  460    0  459    0    1  107 434  12 459   0 20  79

Note the amount of free pages available under the column "free".  If this
number falls below the reserved amount (vm-page-free-reserved), your system
has hit this condition.

In the previous example, "vm-page-free-reserved" is set to its default value
of ten pages.  The previous example shows that the VM subsystem has been
overwhelmed.  If this is the case on your system, you will most likely
experience degraded window performance along with other performance
degradations. If the vmstat output on your system does not exhibit these
results (or similar ones), DO NOT tune your system per the recommendations
in this note.

GUIDELINES FOR CHANGING VM TUNING PARAMETERS:

1. Run "vmstat 2" to determine if vm tuning parameters should be changed.  
   (See previous section, "PROBLEM VERIFICATION").

2. Update the vm-page-free-target, vm-page-free-optimal, and vm-page-free-min
   tuning parameters in the /etc/sysconfigtab file.  If your system has less
   than 128 MB of memory, try doubling from the default values until you reach
   a happy medium between application performance and user interactivity.  Note,
   the default values are 128, 74, and 20, respectively.  Refer to the "System
   Tuning and Performance Management Manual" for more information on system 
   tuning.  The following parameter values provide fairly good interactivity 
   with moderate performance degradation on a Alphastation 6000 with 128M of 
   physical memory:

vm:
 vm-page-free-target=4096
 vm-page-free-optimal=4096
 vm-page-free-min=2048

The numbers provided in the previous example are designed to keep a larger
than normal number of pages on the free list (as a buffer) by starting to page
earlier than normal (via a larger vm-page-free-min) and by stopping paging
later than usual (via a larger vm-page-free-target).  In addition, swapping
of tasks is enhanced to force the memory crunching task to be swapped out
occasionally (via a larger vm-page-free-optimal). You may find that your
system behaves fine with some manipulation of these parameters.  Note
that these tuning parameters were devised to provide some level of user
interactivity in a heavy paging/swapping environment.  They may not be the
best solution for your particular needs, but may provide a reasonable starting
place. Note, if your system does not have 128M of memory, pare down these
numbers. The units for these values are pages (which are 8KB) resulting in
some hefty chunks of memory (for example, 32MB).  Again, try doubling the
default values until you reach some happy medium. You can check the default
values using dbx as follows:

# dbx -k /vmunix

(dbx) p vm_page_free_target
2048
(dbx) p vm_page_free_optimal
1029
(dbx) p vm_page_free_min
20
(dbx) p vm_page_free_reserved
10

3. Reboot the system.

4. Raise the priority of the window manager (mwm or dtwn).
   a. Open a DECterm and kill the currently running manager.  For example:

      kill -9 pid

      Note that the pid is the process ID of the window manager found using
      the ps ax command.

   b. Restart the window manager using the system utility "nice".  For example:

      nice -2 mwm &

      or

      nice -2 dtwm &

If the system is tuned correctly, what you should see happen is a small
latency when the memory intensive application starts which will balance as
the memory subsystem recovers.  You should be able to expose
windows and drag them around, and so on.  If you expose a window that
has not been used for some time, expect some latency.  Remember, you are now
working in a heavy paging/swapping environment and those pages are not yet
available.

You will need to kill and restart the window manager each time you terminate
your X session.  Remember, you will need to be a privileged user (for example,
root).

After performing the previous steps, you should see marked improvement in user
interactivity when the system experiences heavy memory loads.


FILE(s):

/usr/sys/BINARY/vm_pagelru.o     subset OSFBIN370
CHECKSUM: 27175     77  RCSfile: vm_pagelru.c  RCS: 1.1.63.2

===============================================================================

SUPERSEDES PATCHES:     OSF370-350054 (90.00)

This patch corrects the following:

- "ufs_getapage: allocation failed" panic.

- Applications that continuously map and unmap large data files hang in 
  uninterruptable state.
PROBLEM:	(uvo103444)		(Patch ID: OSF370-350054)
********
The user's large data base application would hang in an uninterruptible state
after running for a while.  The process could not be terminated by any user
action except to reboot the system.

The user's program was memory mapping large data files, and was continually
unmapping and remapping pages of the file.  Eventually the process would hang
in an uninterruptible state when it tried to write to a part of the mapped file
that was swapped out.  

Here is a typical stack trace of a thread hung in this condition:

	thread_block
	lock_read
	ufs_getpage
	u_vp_fault
	vm_fault
	trap
	_XentMM
	bcopy
	uiomove
	ufs_rwip
	ufs_write
	vn_write
	rwuio
	write
	syscall

Running in lockmode=4 produced a panic with the message:

	"lock_read: lock already owned by thread"

instead of a hung process.

PROBLEM:				(Patch ID: OSF370-350139)
********
The system panics with "ufs_getapage: allocation failed" message.

A typical stack trace is as follows:
        panic()
        ufs_getapage()
        ufs_getpage()
        u_vp_fault()
        u_map_fault()
        vm_fault()
        trap()
        _XentMM()


FILE(s):

/usr/sys/BINARY/ufs_vnops.o	 subset OSFBIN350
CHECKSUM: 46211    133  RCSfile: ufs_vnops.c	RCS: 4.2.118.3

===============================================================================

A call-share executable with a text, data or bss region greater than 4 gbytes,
the application will segment fault.
PROBLEM:	(QAR 43033)		 (Patch ID: OSF370-350143)
********
A call-share executable with a text, data or bss region 
greater than 4 gbyte application will segment fault.  

As a work around you can build your application non-share.

This test demonstrates the problem:

csh> cat test.c
 #define ARRAY_SIZE (1024*1024*512) - 1
 long buf1[ARRAY_SIZE];
 main()
  {
   printf("sizeof(buf1) = 0x%lx\n", sizeof(buf1));
   buf1[1] = 42;
   buf1[ARRAY_SIZE-2] = 169;
  }

csh> cc test.c
csh>
csh> a.out
 Segmentation fault (core dumped)
csh>


FILE(s):

/sbin/loader		subset OSFBASE350
CHECKSUM: 18200    112

===============================================================================

Using Peer Server 1.3 ECO1 and token ring network interface(s), source routing
discovery is not working as expected.  Additional interfaces will not 
initialize and links between remote stations cannot be established.
PROBLEM:        (MCPM26D74/QAR 43974)	(Patch ID: OSF370-350144)
********
After installing and configuring Digital Peer Server version 1.3, EC01, token 
ring source routing tables may not be built correctly.  If you have multiple 
token ring interfaces, additional interfaces will not initialize and links 
between remote stations cannot be established.

How to recognize the problem:

Typical error messages will appear with multiple interfaces indicating 
unreliable connections.  You may observe console messages similar to the 
following:

        Event: Link Halted
        from: Node 0:. LLC2 SAP sna-1 Link msamss-1
        at  : 1996-02-12-12:35:28.984-05:00I-----
        Link Halted Reason = Implementation Specific

Check source routing module level:

        "srconfig -rc" command displays several failures with no responses for 
	ARE packets. One may  not notice these errors if source routing was 
        not enabled

Check at Applications level:

        The applications like Peer server may not be able establish links with
        remote SNA nodes. This can be verified with NCL command:

        ncl> show sna cp serv t g * all

        The above command displays status of the Transmission Groups as either 
	"Idle" or "On-connecting".

FILE(s):

/usr/sys/BINARY/trn_sr.o	 subset OSFHWBIN350
CHECKSUM: 02248     92  RCSfile: trn_sr.c  RCS: 1.1.19.2

===============================================================================

A potential security vulnerability has been discovered, where under certain
circumstances users may "gain unauthorized access" to the system.  Digital
has corrected this potential vulnerability.
PROBLEM:        (SSRT0376X)		(Patch ID: OSF370-350152)
********
A potential security vulnerability has been discovered, where under certain
circumstances users may "gain unauthorized access" to the system.  Digital
has corrected this potential vulnerability.


FILE(s):

/etc/sia/OSFC2_matrix.conf	 subset OSFC2SEC350
CHECKSUM: 51764      3  RCSfile: OSFC2_matrix.conf  RCS: 1.1.17.2

===============================================================================

The mold daemon component of the Common Agent leaks memory when running with the
DEC SNA PeerServer product.
PROBLEM:	(CFS.27284)	(Patch ID: OSF370-350169)
********
The DEC SNA PeerServer product instantiates a new (protocol engine) daemon that
connects to the mold daemon component of the Common Agent each time an incoming
request is received by the DEC SNA PeerServer product from the network.

The PeerServer product can handle hundreds of requests per minute, each time
starting and then stopping its protocol engine daemon that connects to the mold
daemon.  The mold daemon does not clean up the socket connection that gets
created each time the PeerServer creates a new connection to the mold, leaking
several thousand bytes of virtual memory per connection, plus leaves the socket
connection dangling.

Over time, the mold component can consume all available virtual memory, causing
unpredictable results and system performance degradation.  Ultimately, the
customer is forced to stop and restart the PeerServer product, which is not
acceptable to the customer, as this process is very resource intensive and
can take many minutes to complete.

Errors may get logged in the /var/adm/syslog.dated//daemon.log file,
including messages similar to these (t21mcd and t21mad are DEC SNA PeerServer
daemon components; mold is a Common Agent daemon component):

 t21mcd[1184]: Daemon process t21mad(1188)
                terminated, signal=6
 t21mcd[1184]:
                Started daemon process t21mad (3617)
 mold[324]: S011 - mold_*() call failed -
                (MAN_C_OBJECT_ALREADY_EXISTS)
 last message repeated 6 times
 t21mcd[1184]: Daemon process t21mad(3617)
                terminated, signal=6
 t21mcd[1184]:
                Started daemon process t21mad (3892)
 mold[324]: S011 - mold_*() call failed -
                (MAN_C_OBJECT_ALREADY_EXISTS)
 last message repeated 6 times
 t21mcd[1184]: Daemon process t21mad(3892)
                terminated, signal=6
 t21mcd[1184]: Started daemon process -
                t21mad (3910)
 mold[324]: S011 - mold_*() call failed -
                (MAN_C_OBJECT_ALREADY_EXISTS)
etc., etc.

none.

FILE(s):

/usr/sbin/mold          subset OSFCOMAGENT350
CHECKSUM: 36591    176   RCSfile: mold.c          RCS: 1.1.2.8
			 dd RCSfile: mold_agent.  RCS: 1.1.2.2
			 RCSfile: mold_mo.c	  RCS: 1.1.2.2
			 RCSfile: mold_msg_text.c RCS: 1.1.2.3
			 RCSfile: sck_mold_sstb.c RCS: 1.1.6.2

===============================================================================

This patch fixes a problem where the find command returns a invalid status
code upon encountering a file in an "ffm" set.
PROBLEM:	(MCPM269A8)	(Patch ID: OSF370-350176)
********
Fixes a problem where the find command returns a invalid status code upon 
encountering a file in an "ffm" set.

The find command will return a code of 2 (EINVAL) upon encountering a file
in an "ffm" set, generally associated when System V environment is being used.
When this happens, the user's application receives an invalid status code;
the system does not crash or hang.


FILE(s):

/usr/sys/BINARY/ffm_vfsops.o     subset OSFBIN350
CHECKSUM: 63529     12  RCSfile: ffm_vfsops.c  RCS: 1.1.27.2

===============================================================================

After yppasswd has been run, NIS passwd dbm files will have read and write
permissions for other users.
PROBLEM:	(HPAQB5F05)	(Patch ID: OSF370-350185)
********
After yppasswd has been run, NIS passwd dbm files will have read and write 
permissions for other users:

-rw-rw-rw- 1 root system 0 Nov 30 11:17 passwd.byname.dir
-rw-rw-rw- 1 root system 1024 Nov 30 11:17 passwd.byname.pag
-rw-rw-rw- 1 root system 0 Nov 30 11:17 passwd.byuid.dir
-rw-rw-rw- 1 root system 1024 Nov 30 11:17 passwd.byuid.pag


FILE(s):

/usr/sbin/rpc.yppasswdd 	 subset OSFINET350
CHECKSUM: 01460     32	RCSfile: rpc.yppasswdd.c  RCS: 4.2.15.2

===============================================================================

This patch resolves a problem with "strsetup -i -f" creating duplicate major 
and minor numbers.
PROBLEM:	(MCPM41A3D)	(Patch ID: OSF370-350186)
********
After running "strsetup -i -f" /dev/streams/kinfo and /dev/streams/strkinfo
can have the same major and minor numbers. This causes "netsetup" to report
"ioctl: invalid argument" errors.


FILE(s):

/usr/sbin/strsetup 	         subset OSFCLINET350
CHECKSUM: 12759     32	RCSfile: strsetup.c  RCS: 4.2.29.2

===============================================================================

This patch adds support for file system ids ffm and nfsv3. 
PROBLEM:  ( MCPM4AD1A ) (Patch ID: OSF370-350190)

This patch adds support for file system ids ffm and nfsv3. Previous to this
patch, the sysfs system calls would give the following error message:

	"sysfs: Function not implemented"


FILE(s):

/usr/sys/BINARY/kern_sysfs.o        subset OSFBIN350
CHECKSUM: 63656      5     RCSfile: kern_sysfs.c  RCS: 1.1.16.2
/usr/sys/include/sys/fsid.h         subset OSFBINCOM350
CHECKSUM: 37787      3     RCSfile: fsid.h        RCS: 1.1.8.2

===============================================================================

This patch resolves the condition that results when there is no default shell 
in the password file causing rexecd to fail.
PROBLEM:	(UVO103915)	(Patch ID: OSF370-350191)
********
If a user uses chsh(1) to change their shell to /bin/sh then the shell 
definition in the password file for that user is removed.  

This is standard BSD behavior and the system defaults all such password entries 
to /bin/sh at login time.

rexecd(8) however has a problem with accounts like this and fails to run 
commands issued from programs using the rexec(3) library function.


FILE(s):

/usr/sbin/rexecd 	  	 subset OSFCLINET350
CHECKSUM: 23848     24	RCSfile: rexecd.c  RCS: 4.2.12.2

===============================================================================

This patch fixes a problem in which the rcp program fails when the file being 
copied is greater than 2 Gigabytes in size. The error message from rcp is: 
"connection closed".
PROBLEM:	(QAR 36912, QAR 45643)	(Patch ID: OSF370-350198)
********
This patch fixes a problem in which the rcp program fails when the file being 
copied is greater than 2 Gigabytes in size.  The error message from rcp is: 
"connection closed".


FILE(s):

/usr/bin/rcp 			 subset OSFCLINET350
CHECKSUM: 37159     32	RCSfile: rcp.c	RCS: 4.2.20.2

===============================================================================

This patch fixes a problem in which the output from the df command displays 
incorrectly formatted columns.
PROBLEM:	(29818)		(Patch ID: OSF370-350200-1)
********
This patch fixes a problem in which the output from the df command displays 
incorrectly formatted columns.

The problem occurs because the number of inodes in Digital UNIX is quite large.
This causes the columns displayed by the df command to run together.

Run /usr/bin/df -i and examine the output.


FILE(s):

/usr/bin/df 			subset OSFBASE350
CHECKSUM: 63429     24	RCSfile: df.c	RCS: 4.3.29.2
/sbin/df			subset OSFBASE350
CHECKSUM: 58056    128	RCSfile: df.c   RCS: 4.3.29.2

===============================================================================

SUPERSEDES PATCHES:	OSF370-350062 (94.00), 	OSF370-350065 (95.00), 
			OSF370-350243 (188.00), OSF370-350244 (189.00),
			OSF370-350244-1 (189.01)

This patch corrects the following:

- Fixes a problem on ASE systems where LSM volumes remain in SYNC state
  when no volume resync or volplex att command is running.
  This results in performance degradation.

- A problem in which an LSM configuration database becomes corrupted when it 
  grows beyond 128 KB. The LSM daemon displays an error message similar to
  the following when it starts up: bad magic number

- A problem with vold not detaching a disk when the kernel fails a plex.

- A problem where vold core dumps in ASE. Happens when there is a SCSI 
  reservation conflict. 

- Fixes several problems that occur during certain LSM operations involving 
  disklabel changes.
PROBLEM:      (HPXQ943DC)		(Patch ID: OSF370-350062)
********
A system using LSM, AdvFS, and ASE will crash with AdvFS I/O error
messages on the console when one volulme of a two-plex LSM mirrored
volume is failed out, then recovered, and the other plex is failed out.

PROBLEM:      (QAR 36808)		(Patch ID: OSF370-350065)
********
In systems where LSM is used with ASE, when there is a SCSI reservation
conflict, the LSM configuration daemon, vold, dumps core during an
ASE service start and stop.

PROBLEM:	(QAR28740)		(Patch ID: OSF370-350243)
********
When voldisk is used to init/define simple disks, the disklabel is modified 
to add LSMsimp disklabel tag for the partition. 

This is currently being done in vold.  On failure to update the disklabel 
vold does not return proper messages.

PROBLEM:	(QAR31374)		(Patch ID: OSF370-350243)
********
When a sliced LSM disk is removed from LSM, the disklabel is not updated 
to show that LSM is no longer using the disk.

PROBLEM:	(QAR42417)		(Patch ID: OSF370-350243)
********
The voldisk command fails when attempting to 'init' a disk that has been 
previously initialized but is no longer in use by LSM.

The voldisk command will update the disk label but will not add the disk 
into LSM.

PROBLEM:	(QAR 44567, QAR 46976)	(Patch ID: OSF370-350244-1)
********
This patch fixes a problem in which an LSM configuration database
becomes corrupted when it grows beyond 128 KB. 

The LSM daemon displays an error message similar to the following 
when it starts up:

	bad magic number

Attempting to create 1019 LSM volumes also corrupts the LSM configuration 
database (since the size grows beyond 128KB).

Once the LSM configuration database is corrupted, it will have to be re-created.


PROBLEM:        (QAR 39624)             (Patch ID: OSF370-350213)
********
This patch fixes a problem on ASE systems where LSM volumes remain
in SYNC state when no volume resync or volplex att command is running.
This results in performance degradation.

The volprint command shows that the state of the volume is SYNC, as in:

 # volprint -g oracledg -vl oracle
    Volume:     oracle
    info:       len=8379551
    type:       usetype=fsgen
    state:      state=SYNC kernel=ENABLED
    assoc:      plexes=oracle-01,oracle-02
    policies:   read=ROUND exceptions=GEN_DET_SPARSE
    flags:      open rwback (offset=0) writecopy writeback
    logging:    type=BLKNO loglen=1 serial=0/5 (enabled)
    device:     minor=8 bdev=40/8 cdev=40/8 path=/dev/vol/oracledg/oracle
    perms:      user=root group=system mode=0600

However, ps shows no volresync or volplex att command executing, as:

    # ps -e -o command | egrep 'volume|volplex'
    #

The problem can be reproduced with the following scenario:

    1) Create a volume by giving the two plexes in the same volmake.
       Thus the volume will contain the two plexes before it is started

    2) Ensure the volume uses plexes having a log sub-disk, even if the
      volume log_type is not using the log sub-disks.

    3) Once the volume is started by the 'volume start' command,
       abort the copy process by either:

                a) Shutting down the system.
                b) Deporting the disk group.
                c) Killing the volume start process.
                d) Restarting the ASE service utilizing that volume.
                e) Relocating the ASE service utilizing that volume.

    Now the volume will stay in SYNC state across reboots
    and ASE restart and stop/start sequences.


FILE(s):

/sbin/gen/volume        	subset OSFLSMBASE350
CHECKSUM: 14718    264  RCSfile: comstart.c     RCS: 1.1.8.3
/sbin/vold			subset OSFLSMBASE370
CHECKSUM: 42693    584	RCSfile: dbcopy.c   RCS: 1.1.13.2 
/sbin/voldisk			subset OSFLSMBASE350
CHECKSUM: 35986    328	RCSfile: syslog.c   RCS: 4.2.18.4 

===============================================================================

This patch corrects the problem where "ping -p ff" results in a segmentation 
fault and core dump.
PROBLEM:	(QAR-45312)	(Patch ID: OSF370-350206)
********
"ping -p ff" results in a segmentation fault and core dump.


FILE(s):

/usr/sbin/ping 			 subset OSFCLINET350
CHECKSUM: 64503     32	RCSfile: ping.c  RCS: 4.2.23.2

===============================================================================

NIS slaveservers will not accept a push from the master server of a new map.
PROBLEM:	(qar 46193)	(Patch ID: OSF370-350210)
********
NIS slaveservers will not accept a push from the master server of a new map.

On the master server a push is generally done automatically when a map 
is built (cd /var/yp; make 

Files on this server are as follows:

»duv32fas00003-19980714.README
»duv32fas00003-19980714.CHKSUM
»duv32fas00003-19980714.tar
»duv32fas00003-19980714.ps