Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp


more options
 
hp.com home
End of Jump to page title
HP Services Software Patches
Jump to content


» software & drivers
» ask Compaq
» reference library
» forums & communities
» support tools
» warranty information
» contact support
» parts
» give us feedback

patches by topic
» DOS
» OpenVMS
» Security
» Tru64 Unix
» Ultrix 32
» Windows
» Windows NT

associated links
» what's new
» contract access
» browse patch tree
» search patch tree
» join mailing list

connection tools
» nameserver lookup
» traceroute
» ping


Find Support Information and Customer Communities for Presario.
Content starts here
HP Services Software Patches - duv32de2as00004-19980311
 

Copyright (c) DIGITAL Equipment Corporation 1998.  All rights reserved.

PRODUCT:    DIGITAL UNIX [R] 3.2DE2
SOURCE:     DIGITAL Equipment Corporation

ECO INFORMATION:

     ECO Name:  DUV32DE2AS00004-19980311
     ECO Kit Approximate Size:  39MB 
     Kit Applies To:  DIGITAL UNIX 3.2DE2


ECO KIT SUMMARY:

An update ECO kit exists for DIGITAL UNIX 3.2DE2.  This is the aggregate, 
setld-based, patch kit for DIGITAL UNIX 3.2DE2. 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. 

SUPERSEDED PATCH LIST:

This patch kit supersedes the following DIGITAL UNIX patches:

  DUV32DE2AS00003-19971029		! Previous Aggregate Patch Kit
  duv32de2ss0000200029100-19970624      ! Early release of Patch 291.00
  

KNOWN PROBLEMS WITH THE PATCH KIT:

None.


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

Copyright DIGITAL Equipment Corporation 1998.  All Rights reserved.

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

       This ECO has not been through an exhaustive field test process.
       Due to the experimental stage of this ECO/workaround, DIGITAL
       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.

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

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: OSF365-008)
********
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: 28835      8  RCSfile: ldbl_controller_support.c	RCS: 1.1.14.3
/usr/sys/BINARY/pci.o                    subset OSFHWBIN365
CHECKSUM: 23435     29  RCSfile: pci.c	RCS: 1.1.103.2
/usr/sys/BINARY/stanza_resolver.o        subset OSFHWBIN350
CHECKSUM: 56519     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: OSF365-011)
********
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 OSFHWBIN365
CHECKSUM: 57663     16  RCSfile: ruby_common.c	RCS: 1.1.27.2
---------------------


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

Crash-dumps to non-re0 RAID devices broken on all PCI & EISA machines.
PROBLEM:	(QAR 46654)	 (Patch ID: OSF365-025)
********
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 OSFHWBIN365
CHECKSUM: 52048     12	RCSfile: console.c   RCS: 1.1.76.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: OSF365-030)
********
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 OSFHWBIN365
CHECKSUM: 12790     28     RCS: ace.c      Revision: 1.1.80.2

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

SUPERSEDES PATCHES:     OSF365-006 (6.00), OSF365-024 (24.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: OSF365-006)
********
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: OSF365-024)
********
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: OSF365-039)
********
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 OSFHWBIN365
CHECKSUM: 48036    173  RCSfile: psiop.c    RCS: 1.1.53.5
/usr/sys/BINARY/psiop_pci.o 	subset OSFHWBIN365
CHECKSUM: 43032     26	RCSfile: psiop_pci.c  RCS: 1.1.39.3
/usr/sys/include/io/cam/siop/pci_scripthost.h 	subset OSFBINCOM365
CHECKSUM: 18806     16	RCSfile: pci_scripthost.h  RCS: 1.1.36.2

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

SUPERSEDES PATCHES:	OSF365-023 (23.00)

This patch corrects the following:

- This patch fixes a Token Ring transmission timeout.  The driver can experience
  "ID 380PCI20001 (8/13/95)" as described in the TI380PCI Errata.

- The token ring driver, when storing the product_id, can cause corruption
  which can result in a kernel read access panic.
PROBLEM:	(UVO104380, HPAQ47704)	(Patch ID: OSF365-023)
********
The corruption caused by the token ring driver can result in
an invalid memory read access from kernel mode panic.

The significant indicator is the faulting virtual address,
being repeated 'ef'.  A representative example follows:

trap: invalid memory read access from kernel mode
    faulting virtual address:     0xefefefefefeff28f
    pc of faulting instruction:   0xfffffc00005675e4
    ra contents at time of fault: 0xfffffc000056b54c
    sp contents at time of fault: 0xffffffff87dc6a20


PROBLEM:	(HPAL83FE3)		(Patch ID: OSF365-042)
********
This patch fixes a Token Ring transmission timeout.  The driver can experience
"ID 380PCI20001 (8/13/95)" as described in the TI380PCI Errata.


FILE(s):

/usr/sys/BINARY/if_tra.o 	subset OSFHWBIN365
CHECKSUM: 02692     66  RCSfile: if_tra.c  RCS: 1.1.56.5

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

SUPERSEDES PATCHES: 	OSF365-350104 (108.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: OSF365-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: OSF365-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 OSFBIN365
CHECKSUM: 27273      7  RCSfile: vm_cfg.c  RCS: 1.1.31.2
/usr/sys/BINARY/vfs_ubc.o       subset OSFBIN350
CHECKSUM: 38443     54  RCSfile: vfs_ubc.c  RCS: 1.1.118.3

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

SUPERSEDES PATCHES:	OSF365-360003 (48.00),  OSF365-360037 (68.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.

- Large memory growth of ucred structures can occur.  This is especially
  prevalent if a user is using setuid programs.
PROBLEM:        (BRO100600) 		(Patch ID: OSF365-360003)
********
Large memory growth of ucred structures can occur.  This is especially
prevalent if a user is using setuid programs.


PROBLEM:        (QAR 33924)     	(Patch ID: OSF365-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: OSF365-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 OSFBIN365
CHECKSUM: 61827     42     RCS: nfs_vnodeops.c      Revision: 1.1.104.7
/usr/sys/BINARY/nfs3_vnodeops.o         subset OSFBIN365
CHECKSUM: 36031     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: OSF365-360062)
********  
The ar command's -x option, which extracts archive files, may
in error, return a message stating that the 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 OSFBASE365
CHECKSUM: 44375    376     RCS: ar.c      Revision: 4.2.33.2

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

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: OSF365-360064)
********
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     RCS: 
/usr/lib/nls/msg/en_US.ISO8859-1/quota.cat		subset OSFBASE350
CHECKSUM: 60092      1     RCS: 
/usr/sbin/edquota		subset OSFBASE365
CHECKSUM: 05679    112     RCS: edquota.c      Revision: 4.2.29.2
/usr/sbin/quota		subset OSFBASE365
CHECKSUM: 17675    112     RCS: quota.c      Revision: 4.2.39.2
rquotaxdr.c      Revision: 4.2.4.2
/usr/sbin/vedquota		subset OSFADVFS365
CHECKSUM: 41580    576     RCS: vedquota.c      Revision: 1.1.28.2
/usr/sbin/vquota		subset OSFADVFS365
CHECKSUM: 08099    504     RCS: vquota.c      Revision: 1.1.25.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: OSF365-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: 30097     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: OSF365-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: 43516     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

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

Fixes "timeout table overflow" panic on multiprocessor system.
PROBLEM:        (QAR 39990)		(Patch ID: OSF365-350079)
********
Fixes "timeout table overflow" panic on multiprocessor system.


FILE(s):

/usr/sys/BINARY/lwc.o                   subset OSFBIN350
CHECKSUM: 28630      6  RCSfile: lwc.c	RCS: 1.1.22.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: OSF365-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: 30385     32  RCSfile: tftpd.c	RCS: 4.2.11.2
---------------------


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

Fix acctcms hash table overflow error.
PROBLEM:        (TKTQ22355) 		(Patch ID: OSF365-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: 21117     32  RCSfile: acctcms.c	RCS: 4.2.18.2
---------------------


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

Program translated with FreePort Express (SunOS --> Digital UNIX)
binary translator does not run correctly.
PROBLEM:	(QAR 39134)		(Patch ID: OSF365-350097)
********
Program translated with FreePort Express (SunOS --> Digital UNIX)
binary translator does not run correctly.

The problem is due to calls to mmap() specifying /dev/zero. 
The address returned was other than the address (hint) provided. 

Compile and run the following program to verify the problem exists:

#include 
#include 
#include 
#include 

main(argc, argv)
int argc;
char **argv;
{
        int fd;
        char *addr;

        if((fd = open("/dev/zero", O_RDWR)) == -1) {
                perror("mmap: open");
                exit(1);
        }

        if((addr = mmap(0x20000000, 8192, PROT_READ|PROT_WRITE,
                        MAP_PRIVATE, fd, 0L)) == (void *)-1) {
                perror("mmap: mmap");
                exit(1);
        }
        close(fd);

        if (addr == (char *)0x20000000)
                printf("SUCCESS\n");
        else
                printf("FAILURE: mapped /dev/zero at address 0x%lx\n", addr);
        exit(0);
}


FILE(s):

/usr/sys/BINARY/devz.o                  subset OSFBIN350
CHECKSUM: 35943      6  RCSfile: devz.c	RCS: 1.1.10.2
---------------------


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

Program using libexc.a suffer corrupted signal masks.
PROBLEM:	(EVT101544) 		(Patch ID: OSF365-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: 12745     23
---------------------


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

Correct nfs server duplicate request problem, by adding timestamps.
PROBLEM:	(MGO101612)		(Patch ID: OSF365-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.

You need this patch 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 this problem.
	

FILE(s):

/usr/sys/BINARY/svc_kudp.o              subset OSFBIN350
CHECKSUM: 55255     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: OSF365-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: 20697    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: OSF365-350112)
********
Users could use lattelnet to invoke a subshell, a potential security issue in
some installations.


FILE(s):

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


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

Card lockup problem using the ATM IP convergence module.
PROBLEM:	(HPXQC2E60,QAR 42749)	 	(Patch ID: OSF365-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: 30053     40  RCSfile: if_otto.c   RCS: 1.1.19.2

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

The system panics with kernel memory fault, and the fault_pc is in the 
u_anon_free() routine.
PROBLEM:	(43968)		(Patch ID: OSF365-350136)
********
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 OSFBIN365
CHECKSUM: 16520     73     RCS: vm_anon.c      Revision: 1.1.36.2

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

SUPERSEDES PATCHES:     OSF365-350054 (93.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: OSF365-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: OSF365-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: 36046    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: OSF365-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: 56855    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: OSF365-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: 59360     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: OSF365-350152)
********
A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access to the system.	


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:	(IPMT Case CFS.27284)	(Patch ID: OSF365-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.


FILE(s):

/usr/sbin/mold 		subset OSFCOMAGENT350
CHECKSUM: 19886    176	RCSfile: sck_mold_sstb.c RCS: 1.1.6.2
			RCSfile: socket.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: OSF365-350176)
********
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: 44792     12     RCS: ffm_vfsops.c      Revision: 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: OSF365-350185-1)
********
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: 60219     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: OSF365-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: 28582     32	RCSfile:  strsetup.c	RCS: 4.2.29.2

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

This patch adds support for file system ids ffm and nfsv3. 
PROBLEM:	(MCPM4AD1A)	(Patch ID: OSF365-350190)
********
This patch adds support for file system ids ffm and nfsv3.
Previous to this patch, the sysfs system call would give 
the following error message:

"sysfs: Function not implemented"


FILE(s):

/usr/sys/BINARY/kern_sysfs.o		subset OSFBIN350
CHECKSUM: 13517      5     RCS: kern_sysfs.c      Revision: 1.1.16.2
/usr/sys/include/sys/fsid.h		subset OSFBINCOM350
CHECKSUM: 38534      3     RCS: fsid.h      Revision: 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: OSF365-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: 39000     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: OSF365-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: 48003     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: OSF365-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):

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

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

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


FILE(s):

/usr/sbin/ping 		subset OSFCLINET350
CHECKSUM: 53783     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: OSF365-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 ). Or yppush may be called interactively.

Currently, the yppush process will print 

 Transfer from  still processing ...

twice, after a delay of several minutes, and then pushed  but the map 
in fact does not get transferred to the slave.  With the patched ypserv 
running on the slave, the "transfer ..." messages do not appear, and the map 
is in fact transferred.


FILE(s):

/usr/sbin/ypserv 		subset OSFINET365
CHECKSUM: 16358     40	RCSfile: ypserv_proc.c	RCS: 4.2.11.2

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

SUPERSEDES PATCHES:	OSF365-350197 (156.00)

This patch corrects the following:

- Resolves a problem which causes kernel memory fault in ubc_sync_iodone()

- Fixes a problem in which the system panics when the routing code failed to 
  range check the destination address length.
PROBLEM:	(KAOB15145)	(Patch ID: OSF365-350197)
********
This patch fixes a problem in which the system panics when the routing
code failed to range check the destination address length. 

The following is an example of a typical stack trace:

 > 0 boot
 1 panic(s = "kernel memory fault")
 2 trap()
 3 _XentMM
 4 rn_match () net/radix.c:180
 5 rtalloc1() net/route.c:230
 6 rtalloc() net/route.c:213
 7 ip_forward() netinet/ip_input.c:1572
 8 gw_forwardscreen() data/gw_screen_data.c:56
 9 ip_forwardscreen() netinet/ip_screen.c:62
 10 ipintr() netinet/ip_input.c:642
 11 netisr_thread() net/netisr.c:806


PROBLEM:	(MGO101960)	(Patch ID: OSF365-350211)
********
This patch resolves a problem which causes kernel memory fault
in ubc_sync_iodone() due to corruption of buffer header (struct buf).


FILE(s):

/usr/sys/BINARY/route.o		subset OSFBIN365 
CHECKSUM: 09139     97	RCSfile: route.c  RCS: 4.2.24.2	  RCSfile: rtsock.c  	RCS: 4.2.21.2

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

SUPERSEDES PATCHES:	OSF365-350065 (96.00),   OSF365-350243 (188.00),
                        OSF365-350244 (189.00)

This patch corrects the following:

- 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: OSF365-350065)
********
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: OSF365-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:	(QAR 39624)		(Patch ID: OSF365-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.


PROBLEM:	(QAR28740)	(Patch ID: OSF365-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: OSF365-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: OSF365-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: OSF365-350244)
********
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.


FILE(s):

/sbin/gen/volume 	subset OSFLSMBASE350
CHECKSUM: 08749    264	RCSfile: comstart.c	RCS: 1.1.8.3
/sbin/vold              subset OSFLSMBASE365
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 fixes a problem that occurs when the -b option of the volrecover
command is used. The problem is that a background job spawned to perform the
recovery operation fails when a SIGHUP signal is received.
PROBLEM:	(QAR38631)	(Patch ID: OSF365-350216)
********
This patch fixes a problem that occurs when the -b option of
the volrecover command is used. The problem is that a background
job spawned to perform the recovery operation fails when a
SIGHUP signal is received.  This patch ensures that the background
job ignores the SIGHUP signal.


FILE(s):

/sbin/volrecover	subset OSFLSMBASE350
CHECKSUM: 08975    160	RCSfile: volrecover.c

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

Automount program has a memory leak. In some cases, this leak can cause 
applications to hang. The daemon.log file shows the following error message:

   	"Memory allocation failed: not enough space"
PROBLEM:	(HPAQ46F6F)	(Patch ID: OSF365-350218)
********
Automount can take up more memory than is necessary due to a memory leak.

In this case a 'ps -l' command showed a vsize of 64MB, and the daemon.log
file showed an entry for automount 

   "Memory allocation failed: not enough space".

In some cases this leak can cause applications to hang.


FILE(s):

/usr/sbin/automount 		subset OSFNFS350
CHECKSUM: 18631    104	RCSfile: auto_look.c  RCS: 4.2.20.2

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

This patch fixes a halt/restart problem with the mfa driver ESP self-test.
PROBLEM:	(ZPOB30186, QAR 46022)		(Patch ID: OSF365-350221-1)
********
This patch fixes a halt/restart problem with the mfa driver ESP self-test.

If the DEMFA interface halts, self-tests are performed.  The mfareset routine 
contained a bug which prevented the interface from restarting after the halt.

The DEMFA interface may also halt due to it's inability to allocate (malloc) 
memory for it's buffers.  The correction for the malloc problem is contained
in the MANDATORY PATCH.  

Typical error messages in the /var/adm/messages file will include:

	mfa: port halted (eintr): xber = 0x8a, xpst = 0xc1805,
	xpd1 = 0x183f8000, xpd2 = 0x0, xpud = 0x8c5d001c

The 'c' in the XPST indicates that the ESP special test failed.

If your system panics, your stack will look as follows:

	_XentMM()
	mfareset()
	mfainit()
	mfaioctl()
	in_ifinitia()
	in_control()
	udp_usrreq()
	ifioctl()


FILE(s):

/usr/sys/BINARY/if_mfa.o 	subset OSFHWBIN350
CHECKSUM: 33405     46	RCSfile: if_mfa.c	RCS: 1.1.49.2

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

SUPERSEDES PATCHES:	OSF365-350175 (140.00)

- A potential security vulnerability has been discovered in the rpc.pcnfsd
  program, where under certain circumstances users may gain unauthorized 
  access.  Digital has corrected this potential vulnerability. All customers
  should install this patch.

- This patch fixes problems with the rpc.pcnfsd program that can cause 
  rpc.pcnfsd to crash. This patch also fixes a problem where pcnfsd does
  not generate audit events for successful pcnfsd authorizations.
PROBLEM:	(HPAQA2303 HPAQ347D8 37411)	(Patch ID: OSF365-350175)
********
This patch fixes problems where rpc.pcnfsd may crash and consequently 
the pc nfs service disappears.
 
If either of the following circumstances exist, rpc.pcnfsd could crash:

1) When a system is running C2 security and an account is locked
   because of too many illegal login attempts.

2) When making a second attempt to mount an NFS file system
   that failed to mount during the first attempt.

This patch also fixes a problem where pcnfsd does not generate audit events 
for successful pcnfsd authorizations (auth_event "succeed" events).


PROBLEM:	(SSRT0396U, QAR 45778)		(Patch ID: OSF365-350223)
********
A potential security vulnerability has been discovered in the
rpc.pcnfsd program, where under certain circumstances users may
gain unauthorized access. Digital has corrected this potential
vulnerability. All customers should install this patch.


FILE(s):

/usr/sbin/rpc.pcnfsd 		subset OSFNFS350
CHECKSUM: 32298     56	RCSfile: pcnfsd_misc.c  RCS: 1.1.23.2	
			RCSfile: pcnfsd_print.c  RCS: 1.1.22.2
			RCSfile: pcnfsd_v1.c    RCS: 1.1.10.2
                        RCSfile: pcnfsd_v2.c    RCS: 1.1.10.2

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

savings time.
PROBLEM:        (CLD GOZ100495)         (Patch ID: OSF365-350224-1)
********
In the Fall of 1996, the member countries of the EC (European Community)
will all change timezone rules to switch to normal time from daylight
savings time on the last Sunday in October.  Most countries previously
did this in September.  Without this patch, DEC OSF/1 releases
will use the old rules.

If you operate in any of the following timezones,

 London, Belfast, Dublin, GB-Eire, Poland, WET, MET, EET, W-SU, CET

you will need this patch to effect the daylight savings time change
at the correct date/time.


FILE(s):

/etc/zoneinfo/Belfast           subset OSFBASE350
CHECKSUM: 12469      2
/etc/zoneinfo/CET               subset OSFBASE350
CHECKSUM: 53651      1
/etc/zoneinfo/Dublin            subset OSFBASE350
CHECKSUM: 38262      2
/etc/zoneinfo/EET               subset OSFBASE350
CHECKSUM: 50518      1
/etc/zoneinfo/GB-Eire           subset OSFBASE350
CHECKSUM: 30843      2
/etc/zoneinfo/London            subset OSFBASE350
CHECKSUM: 30843      2
/etc/zoneinfo/MET               subset OSFBASE350
CHECKSUM: 53651      1
/etc/zoneinfo/Poland            subset OSFBASE350
CHECKSUM: 11037      1
/etc/zoneinfo/W-SU              subset OSFBASE350
CHECKSUM: 27357      1
/etc/zoneinfo/WET               subset OSFBASE350
CHECKSUM: 46878      1
/etc/zoneinfo/sources/europe    subset OSFBASE350
CHECKSUM: 60208     36  RCSfile: europe  RCS: 7.2

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

This patch corrects a problem with the cd_defs() function of libcdrom where
cd_defs(CD_GETDEFS) returns the wrong default gid and uid for an ISSO 9660 
CD-ROM.
PROBLEM:	(QAR41743)	(Patch ID: OSF365-350230)
********
The cd_defs(CD_GETDEFS) library function returns the wrong default uid and gid
for an ISO9660 CD-ROM.


FILE(s):

/usr/ccs/lib/libcdrom.a 	subset OSFPGMR350
CHECKSUM: 50060     18	RCSfile: xcdr.c		RCS: 1.1.7.2
/usr/shlib/libcdrom.so 		subset OSFBASE350
CHECKSUM: 25296     40	RCSfile: xcdr.c		RCS: 1.1.7.2

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

System V getdirentries() system call did not correctly calculate the number
of entries in a directory inode when accessing the /dev/fd file system.
PROBLEM:	(QAR39830)	(Patch ID: OSF365-350231)
********
This patch fixes a problem where the System V getdirentries()
system call did not correctly calculate the number of entries
in a directory inode when accessing the /dev/fd file system.
The problem resulted in the readdir() function returning erroneous
directory entries when used on the /dev/fd file system and also
caused error messages to be produced by the ksh builtin dir command
when used on /dev/fd.

Error messages such as the following are typical:

stat: /dev/fd/ptyq9: No such file or directory
stat: /dev/fd/ttyq9: No such file or directory
stat: /dev/fd/ptyqa: No such file or directory
stat: /dev/fd/ttyqa: No such file or directory

The problem can be reproduced by using the System V ksh builtin
dir command on /dev/fd.


FILE(s):

/usr/sys/BINARY/fdfs_vnops.o		subset OSFBIN350
CHECKSUM: 21418     11     RCS: fdfs_vnops.c      Revision: 1.1.26.5

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

The find command will not handle more than 100 arguments.
PROBLEM:	(USG-02753)	(Patch ID: OSF365-350237)
********
The patch corrects a problem in which the find command will not handle
more than 100 arguments.  Given more tha 100 arguments, the find command
used to terminate with the following error message: "find: Too many options".


FILE(s):

/usr/bin/find		subset OSFBASE350
CHECKSUM: 04399     40	RCSfile: find.c   RCS: 4.3.35.2

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

The uux command generates error messages when input is generated from 
stdin jobs.  This occurs in many cases where uucp was used to send mail.
PROBLEM:	(HPXQ18B3A)	(Patch ID: OSF365-350238)
********
Mail sent using uucp, or output to Mail from the uux command
causes the mail message to be sent from the daemon to root
with the following error message: "remote access to path/file
denied". The error message is sent to root in a mail message.

To determine whether this problem exists on your system run the following test:

                cal | uux -r - SITE\!/bin/Mail -s test2 USER

where SITE is the name of a remote site and USER is a user on that site.


FILE(s):

/usr/bin/uux		subset OSFUUCP350
CHECKSUM: 18691    344	RCSfile: uux.c   RCS: 4.3.12.2

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

SUPERSEDES PATCHES: 	OSF365-350162 (133.00), OSF365-350171 (137.00)

This patch corrects the following:

- When editor options are set in ksh, ksh would formerly would not reset
  modes when ksh exited via a trap.

- A problem in which a system running ksh as the login shell would wipe out the
  previous contents of the history file (for example, .sh_history) and put the 
  new information in the file. This occurred after a user logged into an ULTRIX
  system from a Digital UNIX  system using the telnet or rlogin commands.

- This patch fixes a problem where an attribute had been set to "read-only",
  and it could not be set back (unset) to "read/write" status by using the
  built-in command typeset of the ksh (eg. typeset +r).
PROBLEM:	(HPAQ22AF7)	(Patch ID: OSF365-350162)
********
This patch fixes a problem where an attribute had been set to "read only"
and the built-in command typeset (eg. typeset +r ) could not set
it back (unset) to "read/write" status.

If the built-in command 'typeset +r ' is entered after an attribute has
been set to 'read-only' status (eg. typeset -r attr=val), the following message 
is displayed:
	
	ksh: : is read only.

Enter 'typeset -r ' and then enter 'typeset +r '.  As a result,
an error message will be issued.


PROBLEM:	(CLD/USG-01932)	(Patch ID: OSF365-350171)
********
This patch fixes a problem in which a system running ksh as the login shell
would wipe out the previous contents of the history file (for example, .sh_histo
ry)
and put the new information in the file.  This occurred after a user logged into
an ULTRIX system from an OSF/1 system using the telnet or rlogin commands.

On an associated Ultrix machine, an official patch for cld HPAQ6E7B needs to
be installed when it uses the NFS mounted filesystem from the UNIX machine.

Do the following to reproduce this problem:

1. Setup a new account on an OSF/1 V3.0 (also tried T3.2-2)
   with /bin/ksh as the login SHELL and with the home
   directory NFS mounted from an ULTRIX system.

2. Rlogin into the OSF/1 system from an ULTRIX system
   and issue a few commands.  Make sure "history" shows the
   commands you just issued. Cat ".sh_history" just to sanity
   check what's in there; logout.

3. Rlogin into the ULTRIX system and issue a few commands.  Then
   cat ".sh_history" file and see whether the previous commands
   get written from the OSF/1 system or the ULTRIX system.
   You can see new commands from the ULTRIX system get written into the
   .sh_history file, but the commands from the OSF/1 system get wiped out.

4. Rlogin into the OSF/1 system again from the ULTRIX
   system. Cat ".sh_history" to ensure that the ULTRIX commands still
   exist, then enter a few commands.
   Finally, cat ".sh_history" file and notice that the previous
   ULTRIX commands get wiped out.

                                 
PROBLEM:	(UVO104297)	(Patch ID: OSF365-350239)
********
This problem occurs after exiting a ksh session.  In some cases, the tty
modes have been reset.  A tty sane  is needed to restore the modes.

When this problem occurs, keyboard input is not echoed after ksh is exited.

execute the following:
        /usr/bin/ksh
        set -o emacs
        touch /tmp/foo
        trap 'rm -f /tmp/foo' EXIT
        TMOUT=1

Now wait 60 seconds.  When the ksh exits, the keyboard should echo characters.  If it does not, then this bug has occured.

 
FILE(s):

/usr/bin/ksh		subset OSFBASE350
CHECKSUM: 44536    272     

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

This patch corrects the following:

- Add the time out options -t nnn & -T to the 'showmount' command.

- "showmount -e host" command does not receive the requested export list 
  from the specified host within 25 seconds, and issues the following 
  error message:

    Can't do Exports rpc: RPC: Timed out
PROBLEM:        (HPXQ36487/QAR 45362)   (Patch ID: OSF365-350234)
********
'mountd' can die without logging the event in the daemon.log file and
without generating a core file.  This can occur if the following
conditions are true:

 o  The output from the "showmount -e host" command is greater than 4K
    bytes long.

 o  The "showmount -e host" command times out and issues the error:

        Can't do Exports rpc: RPC: Timed out

The 'showmount' command has a 25 second time out, plus the typical
showmount request returns in less than a second.  This problem has so
far only occurred when the NFS server is exporting a large number of
file systems hosted by a 3rd party product (where a large number was
greater than 100 of the 3rd party product's entries).

Another way to cause this problem is if the 'showmount' command is
aborted via Control-C before the NFS server can return the list of
exported file systems.

Other systems, such as PCs requesting a list of exported file systems,
could also cause this problem.


PROBLEM:	(HPXQ36487/QAR 46954)	(Patch ID: OSF365-350240)
********
If the "showmount -e host" command does not receive the requested export
list from the specified host within 25 seconds, it will issue the
following error message: 

    Can't do Exports rpc: RPC: Timed out

The most likely cause for receiving this error is if the specified host
system is running a 3rd party product that provides its own file system
interface _AND_ if accessing that file system is slow (perhaps on the
first reference to the file system) _AND_ if a sufficient number of such
file systems are exported so that 'mountd' takes a long time to read and
verify the list of exported file systems. 

Generally speaking, 'mountd' is able to read and verify its export list
in less than a second or a few seconds worst case for a very large list.
However, if conditions do exist that would cause 'showmount' to issue
the above error, then this version of 'showmount' provides options that
will allow the time out value to be changed. 

    -t nnn specifies the time out value in seconds.

    -T specifies an infinite time out.


FILE(s):

/usr/bin/showmount 		subset OSFNFS350
CHECKSUM: 00204     24	RCSfile: showmount.c   RCS: 4.2.10.2

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

This patch corrects the following:

- The pfm driver does not provide any profiling data on CPUs other than #0.

- The uprofile and kprofile commands, on EV4/EV5 systems, may cause the 
  system to hang or to provide incorrect data.
PROBLEM:	(QAR 42434)	(Patch ID: OSF365-350241)
********
Fixes a problem that occurs on a multiprocessor system in which the
pfm driver does not provide any profiling data on CPUs other than #0.

Specifically, when the "runon" command is used to profile on a cpu
other than #0, the uprofile command does not get any profile data from
the pfm driver when its -one switch is specified.  For example:

		% runon 1 kprofile -one ls -l


PROBLEM:	(QAR 39284 QAR 38600)	(Patch ID: OSF365-350241)
********
Fixes a problem that occurs on systems with recent CPU hardware (EV5)
in which using the kprofile command will cause the system to hang.
In rare cases the system will not hang, but the profiling data
produced will have all zero counts.


FILE(s):

/usr/sys/BINARY/pfm.o		subset OSFBIN350
CHECKSUM: 35831     16     RCS: pfm.c      Revision: 1.1.29.2
/usr/ccs/lib/cmplrs/cc/uprofile		subset OSFCMPLRSEXT350
CHECKSUM: 11748    120     RCS: uprofile.c      Revision: 1.1.16.2

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

Fixes a problem in which the size field of a process displayed by
the acctcom command is displayed incorrectly.
PROBLEM:	(TKTQ72352)	(Patch ID: OSF365-350247)
********
This patch fixes a problem in which the size field of a process
displayed by the acctcom command is displayed incorrectly.

Typically, processes that use a lot of memory will display very invalid
size values.   These sizes will either be absurdly large or negative.

Compile and run the following program.  Acctcom will display a size that
is about 8 times larger than the actual memory usage.

#include 
#include 
#include 
#include 
#include 

#define  ALLOC_SIZE  1024 * 1024 /* 1M byte */

main()
{
  int i;
  struct rusage ru;
  i = fork();
  if (i == 0) {
   child();
   }
  else {
   wait3(NULL,0,&ru);
   printf("size information %ld %ld %ld\n",ru.ru_ixrss,ru.ru_idrss,ru.ru_isrss);
        }
}
child()
{
{
  int     counter;
  int     i;
  char    *address;

  for( counter = 1 ; counter < 100 ; counter++ ) {
    address = ( char * )malloc( sizeof( char ) * ALLOC_SIZE );
    if( address == NULL ) {
      printf( "Can't allocate memory.\n" );
      sleep( 60 );
      exit( 0 );
      }

  for( i = 0 ; i < ALLOC_SIZE ; i++ ) {
    *address = ( char )( counter % 255 );

    address ++;
      }

    printf( "Allocate %5dM byte\n" , counter );
    }

  exit( 1 );
}


FILE(s):

/usr/bin/acctcom                subset OSFACCT350
CHECKSUM: 44395     40	RCSfile: acctcom.c   RCS: 4.3.20.2

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

SUPERSEDES PATCHES:	OSF365-350249 (193.00)

This patch corrects the following:

- Permits kernel components to release license units that have been 
  allocated through lmf_auth_ex().
PROBLEM:	(UV0104402 QAR 46852)	(Patch ID: OSF365-35024-19)
********
Multiple mounts of the same file system under the Optical file system
may fail with ERRNO = 169.

This occurs when a user invokes the mount system call from within
a program twice, such as Mount-unmount-mount operations on the
Optical Filesystem. The LMF license units may not be released
causing the future mounts to fail.  The mount system call will fail
the second time with ERRNO = 169.


FILE(s):

/usr/sys/BINARY/kern_lmf.o		subset OSFBIN350
CHECKSUM: 63416     12     RCS: kern_lmf.c      Revision: 1.1.30.2

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

System panics with a kernel memory fault in k_mem_fault by a user application
that passes an invalid kernel address as one of the arguments.
PROBLEM:	(CLD UVO104419)	(Patch ID: OSF365-350251)
********
This patch fixes a problem in which the system panics with a
kernel memory fault in k_mem_fault.  This is caused by a user
application that calls one of the vectored IO system calls
and passes an invalid kernel address as one of the arguments.
This invalid address is not properly validated by the kernel
and therefore causes the kernel memory fault.

The typical stack traceback is as follows:
 
         1.) panic(kernel memory fault)
         2.) trap()
         3.) _XentMM()
         4.) k_mem_fault()
         5.) k_map_fault()
         6.) vm_fault()
         7.) trap()
         8.) _XentMM
         9.) bcopy()
         10.) uiomove()
         11.) mmrw()
         12.) mmread()
         13.) spec_read()
         14.) msfsspec_read()
         15.) vn_read()
         16.) rwuio()
         17.) read()   ../src/kernel/bsd/sys_generic.c
         18.) syscall()
 

FILE(s):

/usr/sys/BINARY/k_mape_mem.o		subset OSFBIN365
CHECKSUM: 39605     16     RCS: k_mape_mem.c      Revision: 1.1.39.2

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

SUPERSEDES PATCHES:	OSF365-350204 (162.00), OSF365-350229 (176.00)

This patch corrects the following:

- This patch allows a customer-written device driver to return the customer's
  own local error value.  Without this patch, the user process will get EINVAL
  instead.  This patch also corrects the situation in which a system could hang
  after Patch OSF365-350229 is installed.
 
- Fix panic (kernel memory fault) associated with the STREAMS code when stopping
  layered products.

- This patch changes the function that pushes a module on the stream so that 
  the device pointer value is set to the value of the device number saved in
  the stream head instead of incorrectly setting it to zero.
PROBLEM:	(HPAQB5D39, MXOQ10017)	(Patch ID: OSF365-350204)
********
Fix panic (kernel memory fault) associated with the STREAMS code when
stopping layered products.

This problem occurs when unlinking STREAMS Multiplexors.  Note that there 
are no STREAMS multiplexors included in the base system but they are used 
by Layered products (e.g., DECnet, PATHworks, SNA Peer Server).  

Typically unlinking occurs when shutting down a layered product 
but PATHworks is an exception to this.

The panic has the general stack trace below:

  trap()
  _XentMM()
  sq_wrapper()
  csq_lateral()
  runq_run()
  netisr_thread()


PROBLEM:	(QAR 46691)	(Patch ID: OSF365-350229)
********
The SVR4 STREAMS interface/documentation is being violated because a valid 
device id is not being passed by the push function when a module is pushed 
on the stream.  Instead, a zero value was being set incorrectly.


PROBLEM:	(QAR 46828)	(Patch ID: OSF365-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: OSF365-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.


FILE(s):

/usr/sys/BINARY/str_osr.o	subset OSFBIN350
CHECKSUM: 51034     43	RCSfile: str_osr.c   RCS: 4.2.48.4

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

This patch fixes  two problems that occur when an application is started
from a subshell, for example, sh -c :
        o An application will hang if it receives an interrupt signal, for
          example, if the user enters Ctrl/C.

        o While an application is running, if Ctrl/C is entered, the parent
          process exits, but the child process remains.
PROBLEM:	(SOO100674)	(Patch ID: OSF365-350256)
********
This patch fixes a problem that occurs when an application is started from
a subshell, for example, sh -c .  The application will hang if it
receives an interrupt signal, for example, the user enters Ctrl/C.


PROBLEM:	(STLB81811)	(Patch ID: OSF365-350256)
********
This patch fixes a problem that occurs when running an application inside
a shell.  When the user enters Ctrl/C, the parent process exits, but the
child process remains.


FILE(s):

/usr/bin/sh		subset OSFBASE350
CHECKSUM: 06182    128     
/usr/bin/Rsh            subset OSFBASE350
CHECKSUM: 06182    128
/sbin/sh		subset OSFBASE350
CHECKSUM: 09307    224     
/sbin/Rsh               subset OSFBASE350
CHECKSUM: 09307    224

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

Mail from non-local senders appears to be from "daemon" rather than 
the person who originated the mail.
PROBLEM:	(CLD HPAQ1279F, HPXQB539D)	(Patch ID: OSF365-350263)
********
The first "From" line in an incoming non-local mail message indicates the mail
is from "daemon" rather than the actual sender. This confused programs such as
"from" and certain third-party mail handlers.


FILE(s):

/usr/bin/binmail		subset OSFBASE350
CHECKSUM: 62465     40     RCS: binmail.c      Revision: 4.3.38.2
/usr/bin/mail			subset OSFBASE350
CHECKSUM: 62465     40     RCS: binmail.c      Revision: 4.3.38.2

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

This patch fixes a problem with the mkpasswd command. Hashed password database
files (for example, /etc/passwd.pag and /etc/passwd.dir) are deleted before
new database files are created.
PROBLEM:	(HPAQ31FCB)	(Patch ID: OSF365-350268)
********                                  
This patch fixes a problem with the mkpasswd command. Hashed password
database files (for example, /etc/passwd.pag and /etc/passwd.dir) are
deleted before new database files are created.

To recreate the problem, complete the following steps:
1. Log in as root.
2. Select a very large password file and enter the following command:
      ls -l /etc/passwd*
3. Verify the byte count of the /etc/passwd.pag and /etc/passwd.dir files.
4. Enter the following command:
      mkpasswd -v /etc/password
5. While the mkpasswd command is running, open another window and
   verify the byte count of the /etc/passwd.pag and /etc/passwd.dir
   files. Note that these files will be removed before new ones
   are created.


FILE(s):

/usr/sbin/mkpasswd		subset OSFBASE350
CHECKSUM: 33478     24     RCS: mkpasswd.c      Revision: 4.2.15.2

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

Calls to flock() can hang a process on an SMP system if 2 or more processes
are attempting to obtain and release an flock() on the same file.
PROBLEM:	(CLD TKTR72070/QAR 47885)	(Patch ID: OSF365-350269)
********
A process may hang while attempting to obtain a file lock using flock() when
run on an SMP system.  

A dbx stack trace on a running system would look similar to the following:

   0 thread_block() ["../../../../src/kernel/kern/sched_prim.c"]
   1 mpsleep() ["../../../../src/kernel/bsd/kern_synch.c"]
   2 vn_flock() ["../../../../src/kernel/vfs/vfs_vnops.c"]
   3 flock() ["../../../../src/kernel/bsd/kern_descrip.c"]
   4 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c"]
   5 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"]

The hung process can be interrupted with Control/C or any other kill SIGNAL.

This situation can occur if multiple processes are locking and unlocking the
same file using the flock() system call on an SMP system.  

This problem will not occur on a single CPU system.


FILE(s):

/usr/sys/BINARY/vfs_vnops.o		subset OSFBIN350
CHECKSUM: 59705     18	RCSfile vfs_vnops.c   RCS: 4.3.79.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: OSF365-350271)
********
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"
   2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c"
   3 xcpu_puts() ["../../../ ../src/kernel/bsd/subr_prf.c"
   4 printf() ["../../../../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_trap.c"
  17 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"


FILE(s):

/usr/sys/BINARY/vfs_cache.o		subset OSFBIN350
CHECKSUM: 63774     56     RCS: vfs_cache.c      Revision: 4.2.47.2

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

The rmt program does not accept reads/writes of less than 1024 bytes
and system displays error message 'Cannot set socket receive buffer size'
PROBLEM:	(TPOQ70260)	(Patch ID: OSF365-350273
********
This patch fixes a problem that occurs when using the rmt program 
to access devices or files. The rmt program does not accept reads/writes 
of less than 1024 bytes. 

The system displays the following error message:

        Cannot set socket receive buffer size

                                              
FILE(s):

/usr/sbin/rmt		subset OSFCLINET350
CHECKSUM: 07756     24     RCS: rmt.c      Revision: 4.2.11.2

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

A potential security vulnerability has been discovered in "rlogin",
where under certain circumstances users may gain unauthorized access.
Digital has corrected this potential vulnerability.
PROBLEM:	(SSRT0416U, QAR 48450)	(Patch ID: OSF365-350275-1)
********
A potential security vulnerability has been discovered in "rlogin",
where under certain circumstances users may gain unauthorized access.

Digital has corrected this potential vulnerability.


FILE(s):

/usr/bin/rlogin		subset OSFCLINET350
CHECKSUM: 43629     32     RCS: rlogin.c      Revision: 4.2.23.2

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

When a member of the group "operator" logged into the console and dump was 
invoked with the -n option, an extraneous file (/dev/:0) was created.
PROBLEM:	(HPXQ7269D)	(Patch ID: OSF365-350278)
********
When a member of the group "operator" logged into the console and
dump was invoked with the -n option, an extraneous file (/dev/:0) was created.


FILE(s):

/usr/sbin/dump		subset OSFHWBASE350
CHECKSUM: 16409     80     RCS: dumpmain.c      Revision: 4.2.29.2
/sbin/dump		subset OSFHWBASE350
CHECKSUM: 22554    328     RCS: dumpmain.c      Revision: 4.2.29.2
/usr/sbin/rdump		subset OSFCLINET350
CHECKSUM: 45203     80     

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

SUPERSEDES PATCHES:	OSF365-360043 (71.00)

This patch corrects the following:

- The server host will have an orphaned login process and rlogind or telnetd
  process in sleep state indefinitely.  This is seen only with Asian tty (atty) 
  or any other host which is running c-list rather than STREAMS tty's.

- This patch addresses kernel memory fault panics seen in systems running
  with clist-based pseudo-ttys.  The kernel memory faults occur either during
  unrelated malloc() calls, or in calls to proc_ref() from ttymodem().
PROBLEM:	(TKTR21634)	(Patch ID: OSF365-360043)
********
A dangling "s_ttyvp" vnode pointer in a session structure can allow a reference
to the session structure after it has been freed.  This corruption eventually
causes a panic in an unrelated malloc() from kmembuckets[2], from which
session structures are allocated.  The corruption to the freed session
structure can be identified by looking at the faulting address, which
indicates that the corruption was done in ttyclose():

trap: invalid memory read access from kernel mode
    faulting virtual address:     0x0000000000437820
    pc of faulting instruction:   0xfffffc00004206b0
    ra contents at time of fault: 0xfffffc0000420644
    sp contents at time of fault: 0xffffffffa0977420
panic (cpu 10): kernel memory fault

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1727]
   1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":757]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1219]
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
   4 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":743]
   5 k_mem_grow_pageable() ["../../../../src/kernel/vm/k_mape_mem.c":660]
   6 k_map_allocate_paged() ["../../../../src/kernel/vm/vm_kmap.c":1099]
   7 kmem_alloc_pageable() ["../../../../src/kernel/vm/vm_kern.c":257]
   8 exec_args_allocate() ["../../../../src/kernel/bsd/kern_execargs.c":345]
   9 exec_args_copyin() ["../../../../src/kernel/bsd/kern_execargs.c":70]
  10 execve() ["../../../../src/kernel/bsd/kern_exec.c":261]
  11 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
  12 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]

(dbx) 0xfffffc0000437820/i
  [ttyclose:1336, 0xfffffc0000437820]   bsr     r26, simple_unlock(line 263)


PROBLEM:	(UVO104310)	(Patch ID: OSF365-360043)
********
A related problem occurs when ttymodem() uses the "s_leader" field from
the freed session structure:

trap: invalid memory read access from kernel mode
    faulting virtual address:     0x0000000000000008
    pc of faulting instruction:   0xfffffc0000426314
    ra contents at time of fault: 0xfffffc00003dbff0
    sp contents at time of fault: 0xffffffff911cf370
panic (cpu 0): kernel memory fault

>  0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1900]
   1 thread_preempt() ["../../../../src/kernel/kern/sched_prim.c":3450]
   2 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1679]
   3 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":757]
   4 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213]
   5 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
   6 simple_lock_B() ["../../../../src/kernel/arch/alpha/lockprim.s":524]
   7 proc_ref() ["../../../../src/kernel/bsd/kern_proc.c":552]
   8 ttymodem() ["../../../../src/kernel/bsd/tty.c":1379]
   9 ptcclose() ["../../../../src/kernel/bsd/tty_pty.c":606]
  10 speclose() ["../../../../src/kernel/vfs/spec_vnops.c":2193]
  11 spec_close() ["../../../../src/kernel/vfs/spec_vnops.c":2341]
  12 msfsspec_close() ["../../../../src/kernel/msfs/osf/msfs_vnops.c":3783]
  13 vn_close() ["../../../../src/kernel/vfs/vfs_vnops.c":1220]
  14 closef() ["../../../../src/kernel/bsd/kern_descrip.c":1393]
  15 close() ["../../../../src/kernel/bsd/kern_descrip.c":1071]
  16 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
  17 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]


PROBLEM:	(TKTR70408)	(Patch ID: OSF365-350284)
********
This problem affects only Digital UNIX systems using C-list-type tty's.

If a user attempts to log into such a system remotely, using either telnet 
or rlogin, and kills the remote-access application (telnet or rlogin) 
during the login procedure (at the "Password:" prompt) then the rlogind 
or telnetd process will be left in a sleep state indefinitely.  

This condition can be recognized by the presense of rlogind or telnetd 
processes in the process table with no associated remote user.


FILE(s):

/usr/sys/BINARY/str_tty.o       subset OSFBIN365
CHECKSUM: 09888      9	RCSfile: str_tty.c	RCS: 4.2.44.2
/usr/sys/BINARY/tty.o 		subset OSFBIN365
CHECKSUM: 18509     34	RCSfile: tty.c	RCS: 4.4.69.2
/usr/sys/BINARY/tty_pty.o 	subset OSFBIN350
CHECKSUM: 47453     18     RCS: tty_pty.c      Revision: 4.6.66.3

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

When typing 'more a_particular_file' there is garbage displayed on the
screen, while displaying files having lines ending with ^M character.
PROBLEM:	(STLQ73538/QAR 48009)	(Patch ID: OSF365-350285)
********
When typing 'more a_particular_file' there is garbage displayed on the
screen, while displaying files having lines ending with ^M character.


FILE(s):

/usr/bin/more		subset OSFBASE350
CHECKSUM: 06646     88    
/usr/bin/page		subset OSFBASE350
CHECKSUM: 06646     88

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

This patch fixes a system hang problem that may occur when a non-timeshared
thread running on a multi-processor system is inappropriately given a priority
boost when returning from a funneled subsystem.
PROBLEM:	(QAR44344)	(Patch ID: OSF365-350286)
********
This patch fixes the problem described in QAR44344 in which a
non-timeshared (i.e., fixed priority) thread running on a
multiprocessor system is inappropriately given a priority boost when
returning from a funnelled subystem.  Unfortunately, the symptom of
this problem is a system hang.

FILE(s):

/usr/sys/BINARY/parallel.o		subset OSFBIN350
CHECKSUM: 03085     10	RCSfile: parallel.c   RCS: 4.2.36.2

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

This patch fixes a problem that causes some valid programs compiled with ieee 
mode to receive a floating-point exception even though they should run to 
completion.
PROBLEM:	(QAR 36520, QAR 48372)	(Patch ID: OSF365-350287)
********
Some valid programs compiled with ieee mode may receive a floating-point
exception even though they should run to completion. The problem occurs
because the floating-point exception handler is too strict when attempting
to enforce trap shadow rules (SRM 4.7.6.1). The following C program fails
when executed on a system with a DECchip 21064. 

Compile the following program with the command:
cc -migrate -g -ieee_with_inexact t.c -o t

        f( int dum, ... ) {
        }

        main() {
            int ii = 50;
            f( 42,
                (float)ii / 100,
                (float)ii / 100,
                (float)ii / 100 );
        }
Results on a system with a 21046 chip before applying the patch:
quarry:ieee/48372 [4%] cc -migrate -g -ieee_with_inexact t.c -o t
quarry:ieee/48372 [5%] ./t
Floating exception(coredump)

Results after applying the patch:
sauron:ieee/48372 [2%] ./t
sauron:ieee/48372 [3%] 


FILE(s):

/usr/sys/BINARY/fp_trigger.o		subset OSFHWBIN350
CHECKSUM: 43704      6     RCS: fp_trigger.c      Revision: 1.1.18.2

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

This patch fixes the problem of producing incorrect codegen sequences when doing
stack allocation within procedure prologs in which the size of the stack was 
very large.  This problem produced a "Segmentation fault (core dumped)" error 
message.
PROBLEM:	(TKTQ51382  QAR 46989)	(Patch ID: OSF365-350289)
********
The code generator used an incorrect codegen sequence when doing
stack allocation within procedure prologs where the size of the
stack was very large (for example, when a structure is passed as an 
entity rather than as a pointer).  This led to an improper instruction
sequence where a register value was dereferenced as an address pointer,
when in fact the register was a temp and had just been corrupted
by a previous function call which generated the error message
"Segmentation fault (core dumped)".


FILE(s):

/usr/ccs/lib/cmplrs/cc/ugen		subset OSFCMPLRS350
CHECKSUM: 47814    864     

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

SUPERSEDES PATCHES:	OSF365-350233 (180.00)

This patch corrects the following:

- A problem that occurs on multi-processor machines in which the at command 
  causes extra batch jobs to be executed. Sometimes temporary files are created
  and not removed, causing the queue limit to be exceeded.

- A problem in which cron jobs will not run if there is an unfinished job in 
  another queue. This problem occurs even if the queue for the job is empty.
PROBLEM:	(HPAQ40CCC)	(Patch ID: OSF365-350233)
********
This patch fixes a problem in which cron jobs will not run if
there is an unfinished job in another queue. This problem
occurs even if the queue for the job is empty.

Typically, a long job is the only job scheduled from cron.  After that
job terminates, another cron job starts executing.  This results in
several "MAXRUN procs reached" messages getting displayed to the error
log.
The /var/adm/cron/FIFO file, which should only exist while jobs remain
queued, remains around much longer than expected.

This problem can be reproduced by running the following test.  To do
this, you need three windows running the following commands:
 truss -p     You might want to script
 tail -f /var/cron/log    the truss and batch_two.ksh
 batch_two.ksh     processes.

The batch_two.ksh file is:
#!/bin/ksh
 echo "sleep 9999" | batch
 integer COUNT=1
 while [ COUNT -lt 60 ] ; do
  echo "sleep 15" | batch
  (( COUNT = COUNT + 1 ))
 done

 (
 sleep 222
 echo "sleep 700" | at -qr now +1 minute
 echo "sleep 750" | at -qr now +1 minute
 echo "sleep 800" | at -qs now +1 minute
 echo "sleep 14" | batch
 ) &

 integer STOP=0 PS
 while [ $STOP -eq 0 ] ; do
  atq | tee /tmp/atq.out
  ps -ef|grep sleep | tee /tmp/ps.out
  ls -l /etc/cron.d/FIFO
  date
  PS=`cat /tmp/ps.out | wc -l`
  AT=`cat /tmp/atq.out`
  [ $PS -le 1 -a "$AT" = "no files in queue." ] && STOP=1 || sleep 10
 done
 echo "$0 finished."
 rm -f /tmp/atq.out /tmp/ps.out


        integer STOP=0 PS
 while [ $STOP -eq 0 ] ; do
  atq | tee /tmp/atq.out
  ps -ef|grep sleep | tee /tmp/ps.out
  ls -l /etc/cron.d/FIFO
  date
  PS=`cat /tmp/ps.out | wc -l`
  AT=`cat /tmp/atq.out`
  [ $PS -le 1 -a "$AT" = "no files in queue." ] && STOP=1 || sleep 10
 done
 echo "$0 finished."
 rm -f /tmp/atq.out /tmp/ps.out


       
The previous test shows that a long running job will prevent cron from
scheduling jobs from any queue until one of the following events occur:

 1) The long running job exits, or
 2) Cron exhausts the FIFO list of already completed jobs
    (one minute per job)

Either of these conditions may take a very long time.  For a long
running job, such as a part14 report, it may be hours.  It could
take cron a very long time to exhaust the FIFO list at one minute per
job (200 completed jobs = 3.3 hours).

The intertesting part of the test occurs when the background sleep 222
completes and places the four new jobs in queues r, s, and b. These
jobs will wait for a long time when they do not need to wait at all.


PROBLEM:	(QAR 47149, UVO104578CBR)	(Patch ID: OSF365-350291)
********
This patch fixes a problem that occurs on multi-processor machines in which the
at command causes extra batch jobs to be executed.

Sometimes temporary files are created and not removed, causing the queue limit
to be exceeded.


FILE(s):

/usr/sbin/cron			subset OSFBASE350
CHECKSUM: 21507     48	RCSfile: cron.c   RCS: 4.2.34.3

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

Processes such as wall or ntalkd, when connected to LAT terminal devices, are 
hanging when attempting to close, possibly because the LAT sessions have been 
disconnected abnormally.
PROBLEM:	(DMO100204, HPXQ974C9)	(Patch ID: OSF365-350293)
********
Processes such as wall or ntalkd, when connected to LAT terminal devices, 
are hanging when attempting to close, possibly because the LAT sessions 
have been disconnected abnormally. A tstack trace in dbx of a hung process 
should look similar to this:

   0 thread_block()
   1 mpsleep()
   2 streams_mpsleep()
   3 latsclose()
   4 close_wrapper() 
   5 csq_protect()
   6 osr_pop_subr()
   7 osr_close_subr()
   8 pse_close()
   9 speclose()
  10 clearalias()
  11 exit()
  12 rexit()
  13 syscall()
  14 _Xsyscall()


FILE(s):

/usr/sys/BINARY/latclose.o		subset OSFBIN350
CHECKSUM: 60437      7     RCS: latclose.c      Revision: 1.1.17.2

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

Fixes a problem that causes the system to panic after creating a symbolic link
to the root file system ('/') and accessing it like a normal file.
PROBLEM:	(HPAQ83C24)	(Patch ID: OSF365-350297)
********
This patch fixes a problem that causes the system to panic after creating 
a symbolic link to the root file system ('/') and accessing it like a 
normal file.

For an AdvFS file system, the system will panic with the following error 
message:

	bs_bf_htop: invalid handle

For other file systems, the system will panic with the following error message:

       vrele:bad ref count


For 'bs_bf_htop: invalid handle' (AdvFS) a typical stack trace could 
look like:

   0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1730]
   1 panic(s = 0xffffffffa10f2e30 = "N1 = 0") ["../../../..
	/src/kernel/bsd/subr_prf.c":757, 0xfffffc00004421e4]
   2 advfs_sad() ["../../../../src/kernel/msfs/bs/bs_misc.c":322, ]
   3 bs_bf_htop() ["../../../../src/kernel/msfs/bs/bs_access.c":500, ]
   4 bs_refpg() ["../../../../src/kernel/msfs/bs/bs_buffer2.c":1472, ]
   5 seq_search() ["../../../../src/kernel/msfs/fs/fs_dir_lookup.c":1457, ]
   6 msfs_lookup() ["../../../../src/kernel/msfs/osf/msfs_lookup.c":624, ]
   7 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":563, ]
   8 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":2327, ]
   9 stat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2295, ]
  10 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519, ]
  11 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094, ]


For 'vrele:bad ref count' a typical stack trace could look like:

   0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1730, ]
   1 panic(s = 0xfffffc0000628238 = "vrele: bad ref count") ["../../..
	/../src/kernel/bsd/subr_prf.c":757, 0xfffffc00004421e4]
   2 vrele() ["../../../../src/kernel/vfs/vfs_subr.c":2196, ]
   3 exit() ["../../../../src/kernel/bsd/kern_exit.c":875, ]
   4 rexit() ["../../../../src/kernel/bsd/kern_exit.c":635, ]
   5 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519, ]
   6 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094, ]


FILE(s):

/usr/sys/BINARY/vfs_lookup.o		subset OSFBIN350
CHECKSUM: 53254     10	RCSfile: vfs_lookup.c   RCS: 4.2.63.2

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

SUPERSEDES PATCHES:     OSF365-350093 (103.00), OSF365-350267 (201.00)

This patch corrects the following:

- On systems running enhanced security, the login process may fail
  with a segmentation fault.
 
- A security vulnerability has been discovered when running enhanced security
  that may facilitate unauthorized users gaining access to the system. Digital
  has corrected this vulnerability.
 
- On a system running enhanced security, a person may still login on a
  terminal that has been locked or on which a login failed due to excessive 
  attempts.
PROBLEM:	(EVT101500)	(Patch ID: OSF365-350093)
********
On a system running with enhanced security, if a terminal has been locked
or has had a login fail due to excessive attempts, the user will still be
allowed to login.


PROBLEM:	(SSRT0362U)	(Patch ID: OSF365-350267)
********
A security vulnerability has been discovered when running enhanced security
that may facilitate unauthorized users gaining access to the system.
Digital has corrected this vulnerability.

A security vulnerability has been discovered when running enhanced security
that may facilitate unauthorized users gaining access to the system.

Digital has corrected this vulnerability.

Systems running enhanced security were not correctly counting unsuccessful
login attempts under all circumstances.  This resulted in the normal account
lockout that should occur after too many unsuccessful logins attempts not
to occur.


PROBLEM:        (HPAQ17931,HPAQA353A)	(Patch ID: OSF365-350298)
********
On systems running enhanced security, if the v_users keyword has been specified
for a device in the device assignment database (/etc/auth/system/devassign)
specifying the users that are permitted to login on that device, and a user
who is not on the v_users list attempts to login on that device, the login
process (login or xdm or dtlogin) will fail with a segmentation fault.
                                                

FILE(s):

/usr/ccs/lib/libsecurity.a		subset OSFC2SEC350
CHECKSUM: 45850    367
/usr/shlib/libsecurity.so		subset OSFBASE350
CHECKSUM: 04477    320

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

This patch fixes a problem in which the ping command can time out after
invoking the "rcinet restart" command.
PROBLEM:	(HPAQ88A35)	(Patch ID: OSF365-350301)
********
This patch fixes a problem in which the ping command can time out after invoking
the "rcinet restart" command.

To reproduce the problem:

1) Run the tcpdump utility on the lan interface and filter on ICMP traffic.
2) Stop and restart internet services using the command "rcinet restart".

   You may have to restart services more than once to obtain an output
   similar to the following while invoking the ping command;

        10:25:50.802272 0.0.0.0 > 137.35.226.10: icmp: echo request
        10:25:51.802272 0.0.0.0 > 137.35.226.10: icmp: echo request
        10:25:52.802272 0.0.0.0 > 137.35.226.10: icmp: echo request
        10:25:53.802272 0.0.0.0 > 137.35.226.10: icmp: echo request

Notice the source field contains 0.0.0.0.  The destination cannot return the
ICMP echo reply to this address.  The ping command will timeout and report
100% packet loss.  The ping command can fail for a local destination as well
as a remote host.


FILE(s):

/sbin/init.d/route                  subset OSFCLINET350
CHECKSUM: 04095      3	RCSfile: route   RCS: 1.1.14.2

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

SUPERSEDES PATCHES:	OSF365-350178 (143.00)

This patch corrects the following:

- Fixes a problem that occurs in ASE/TCR environments in which the rpc.statd
  daemon does not start when using the -p option to specify a long pathname
  (> 45 characters).  When this happens, NFS locking to the NFS service fails
  causing applications like mail to hang.

- A potential security vulnerability has been discovered in 'rpc.statd', 
  where under certain circumstances users may gain unauthorized access.  
  Digital has corrected this potential vulnerability.
PROBLEM:	(SSRT0383U/QAR 45688)	(Patch ID: OSF365-350178)
********
A potential security vulnerability has been discovered in 'rpc.statd', where
under certain circumstances users may gain unauthorized access.  Digital has
corrected this potential vulnerability.


PROBLEM:        (SOO100842, QAR 45974)  (Patch ID: OSF365-350304)
********
This patch fixes a problem that occurs in ASE/TCR environments in which
the rpc.statd daemon does not start when using the -p option to specify
a long pathname (> 45 characters).  When this happens, NFS locking to the
NFS service fails causing applications like mail to hang.


FILE(s):

/usr/sbin/rpc.statd 			subset OSFNFS350
CHECKSUM: 06054     40	 RCSfile: sm_proc.c	RCS: 1.1.11.2
			 RCSfile: sm_svc.c	RCS: 1.1.18.2

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

SUPERSEDES PATCHES:	OSF365-350245 (190.00)

This patch corrects the following:

- On systems with PCXAL, LK411, and similar keyboards, sometimes the keyboard
  stops working.

- On systems with PCXAL, LK411, and similar keyboards, after logging out of
  a session on the workstation monitor, sometimes the keyboard stops working.
  A reboot is required to clear the problem.
PROBLEM:  (TKTQB1439,EVT101548,TPOBC2002,UVO103952) (Patch ID: OSF365-350245)
********
On systems with PCXAL, LK411, and similar keyboards, after logging out of
a session on the workstation monitor, sometimes the keyboard stops working.
A reboot is required to clear the problem.


PROBLEM:	(TKTB49381,GOZ100613,UTO101179)     (Patch ID: OSF365-350306)
********
On systems with PCXAL, LK411, and similar keyboards, after logging out of
a session on the workstation monitor, sometimes the keyboard stops working.
A reboot is required to clear the problem.


FILE(s):

/usr/sys/BINARY/pcxal.o         subset OSFHWBIN350
CHECKSUM: 52531     19	RCSfile: pcxal.c   RCS: 1.1.39.3
/usr/sys/BINARY/ws_device.o     subset OSFHWBIN350
CHECKSUM: 43565     53	RCSfile: ws_device.c   RCS: 1.2.46.2

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

SUPERSEDES PATCHES:	OSF365-350187 (149.00), OSF365-350226 (175.00)

This patch corrects the following:

- Prevents a panic that can occur after deleting an ATM ARP entry.  The user 
  command to delete an ATM ARP entry is "atmarp -d".  Subsequent access to the 
  ATM ARP table can cause the panic.

- Resolves the panics that occur when more than one entry is in an ATM ARP 
  cache bucket.

- Resolves a kernel mem fault in atm_arp_manager when duplicate entries exist 
  in the ARP table.
PROBLEM:	(KAOB17468)	(Patch ID: OSF365-350187)
********
A problem exists with the atmarp command when you place a duplicate
entry in the ARP table. The system panics with a "kernel memory fault".

tset machine_slot[paniccpu].cpu_panic_thread:
Begin Trace for machine_slot[paniccpu].cpu_panic_thread:
>  0 boot()["../../../../src/kernel/arch/alpha/machdep.c":1735]
   1 panic() ["../../../../src/kernel/bsd/subr_prf.c":673,]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213,] 
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
   4 ubc_flush_dirty() ["../../../../src/kernel/vfs/vfs_ubc.c":2946,]
   5 mntflushbuf() ["../../../../src/kernel/vfs/vfs_bio.c":1427,]
   6 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1664,]
   7 panic() ["../../../../src/kernel/bsd/subr_prf.c":757,]
   8 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213,]
   9 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307,]
  10 bcopy() ["../../../../src/kernel/arch/alpha/fastcopy.s":194,]
  11 atm_arp_manage() ["../../../../src/kernel/netinet/atm/atm_arp.c":2709,]
  12 atm_cmm_ioctl() ["../../../../src/kernel/io/atm/cmm/cmm_manage.c":145,]
  13 spec_ioctl() ["../../../../src/kernel/vfs/spec_vnops.c":1973,]
  14 vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1109]
  15 ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":465,]
  16 ioctl() ["../../../../src/kernel/bsd/sys_generic.c":344,]
  17 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519,]
  18 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094,]
End Trace for machine_slot[paniccpu].cpu_panic_thread:


PROBLEM:	(QAR-45351)	(Patch ID: OSF365-350226)
********
There will be a panic from atm_arp when large arp caches encountered.


PROBLEM:	(HPXQB05E6)	(Patch ID: OSF365-350308)
********
This patch prevents a panic that can occur after deleting an ATM ARP entry
with the "atmarp -d" command.

Without this patch, the ATM ARP table can be left in an inconsistent state
if the ATM ARP entry deleted is the first entry in the table.  Subsequent
access to the ATM ARP table can cause a panic.


FILE(s):

/usr/sys/BINARY/atm_arp.o		subset OSFATMBIN365
CHECKSUM: 24275    138  RCSfile: atm_arp.c      RCS: 1.1.31.5

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

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: OSF365-350114)
********
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: 36771    488

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

This patch fixes a problem that occurs when the system panics with the 
following error message: kernel memory fault.
PROBLEM:        (CLD HPAQC07YV)  (Patch ID: OSF365-350313)
********
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]


FILE(s):

/usr/sys/BINARY/svc_auth_unix.o     subset OSFBIN350
CHECKSUM: 50971      6  RCSfile: svc_auth_unix.c   RCS: 1.1.14.2

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

This patch fixes a network socket problem with select() missing state changes
on clients from non-write to writable.
PROBLEM:	(HPXQB6189/QAR 49949)	(Patch ID: OSF365-350317)
********
This patch fixes a network socket problem with select() missing state changes
on clients from non-write to writable.


FILE(s):

/usr/sys/BINARY/sys_socket.o        subset OSFBIN350
CHECKSUM: 09872      7  RCSfile: sys_socket.c   RCS: 4.3.32.2

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

SUPERSEDES PATCHES:     OSF365-350090 (102.00)

This patch corrects the following:

- This patch fixes a problem with the ftp command.  If you ftp to an IBM MVS
  system using the IP address, the IBM system will refuse the connection.
  This problem can be encountered on any system that validates TOS (Type Of
  Service) requests if the file /etc/iptos is not used on the client.
  It is recommended that this patch be installed on all OSF systems.

- ftp with .netrc file does not use ACCOUNT FIELD information.
PROBLEM:	(MGO101812,QAR27629)	(Patch ID: OSF365-350090)
********
When using automated login for ftp with the help of a .netrc file, 
the ACCOUNT FIELD information is not passed to the remote host.

How to recognize the problem; automated ftp login will fail to a server
that relies on ACCOUNT FIELD information in a users .netrc file.

Typical error messages will include "service not implemented".


PROBLEM:        (MCPMC0L3C/QAR 50410)            (Patch ID: OSF365-350318)
********
This patch fixes a problem with the ftp command.  If you ftp to an IBM MVS
system using the IP address, the IBM system will refuse the connection.  This
problem can be encountered on any system that validates TOS (Type Of Service)
requests if the file /etc/iptos is not used on the client.  It is recommended
that this patch be installed on all Digital UNIX systems.

How to recognize this problem:

If you attempt to ftp to any system that validates TOS requests, you may
see the following:

ftp> open 
Connected to 
220-FTPSERV1 IBM MVS V3R1 at SAC1, 12:08:49 on 1996/12/11
421 Service not available, remote server has closed connection

but it may work if you give the hostname of the system instead of the
ip address.

If you were running tcpdump, tracing the connection, you would see

12:26:20.076128 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: S
1419648000:1419648000(0)
win 32768  (DF)
12:26:20.176656 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: S
447244900:447244900(0)
ack 1419648001 win 65535 
12:26:20.176656 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: .
ack 1 win 33580 (DF)
12:26:20.274256 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: P
1:60(59) ack 1 win 65535
12:26:20.366000 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: .
ack 60 win 33580 (DF)
[tos 0xa6]  <<<<<----NOTICE THIS!!!
12:26:20.461648 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: R
447244960:447244960(0) win 0

In the above trace, the connection is rejected because the TOS (Type Of Service)
field contains an invalid value.  This problem can be avoided by using a
/etc/iptos file as noted in the man page.  However, the TOS field should never
have this invalid value and that is the reason for the patch.


FILE(s):

/usr/bin/ftp		subset OSFCLINET350
CHECKSUM: 59476    136  RCSfile: ftp.c  RCS: 4.2.20.3

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

SUPERSEDES PATCHES:	OSF365-350140 (121.00)

This patch corrects the following:

- A problem where telnet dumps core if the USER environment variable is the 
  last variable in the enviroment list.

- Telnet may change terminal characteristics and cause application problems if
  you have set up terminal mode emulation for 8 bits/no-parity.  Telnet will
  override this setting and give you 7 bits/no-parity as the default. This
  patch also fixes the speed table (QAR 41709) and speed definitions 
  (QAR 25953).
PROBLEM:        (HPAQ26C0B, QAR43433)	(Patch ID: OSF360-350140)
********
The terminal line characteristics for telnet with a modem were being reset
to 7-bits/no-parity from 8-bits/no-parity.

How to recognize the problem:

If you have an application that requires you to specify 8 bits/no-parity
for use with serial terminals and dial-in modems, telnet will override the
setting giving you 7 bits/no-parity.  Check the terminal settings with
the command stty -a.

You typically would see the following:

parenb -parodd cs7 -cstopb hupcl cread -clocal
when you really want:
-parenb -parodd cs8 -cstopb hupcl cread -clocal


PROBLEM:        (FNO100131, QAR 43995)   (Patch ID: OSF365-350322)
********
This patch fixes a problem where telnet dumps core if the USER environment
variable is the last variable in the enviroment list.


FILE(s):

/usr/bin/telnet                         subset OSFCLINET350
CHECKSUM: 60413    128	RCSfile: commands.c   RCS: 4.2.19.2

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

SUPERSEDES PATCHES:	OSF365-350254 (197.00)

This patch corrects the following:

- Error in Sending mail get both mail and error messages where the error 
  messages do not correctly describe problem.

- sendmail command loops endlessly trying to get a "tf" control file in 
  /var/spool/mqueue. 

- A potential security vulnerability has been discovered with the sendmail 
  command, where under certain circumstances, users may gain unauthorized 
  access.  Digital has corrected this potential vulnerability.

- Mail cannot be sent to usernames consisting of uppercase and lowercase 
  letters.

- Mail fails when a large distribution list is used.
PROBLEM:	(HPXQ36202)	(Patch ID: OSF365-350254)
********
This patch fixes a problem in which mail cannot be sent to usernames 
consisting of uppercase and lowercase letters, for example, FooBar.


PROBLEM:	(HPXQ22677)	(Patch ID: OSF365-350254)
********
This patch fixes a problem in which mail fails when either of the following
conditions occurs:

 o A Large distribution list is used.
 o A distribution list contains more than 1024 characters.


PROBLEM:        (HPAQ69EDF, QAR 29063)  (Patch ID: OSF365-350331)
********
If the user sending mail makes an error entering the address of the person
they are sending mail to, they will receive a mail message that contains both
the text of their mail and the error messages.

The error messages do not correctly describe the exact nature of the problem.

For example:

The "RCPT TO:" address line is entered as the user 
The "To:" address line is mistakenly entered as the user <"bozo>.

The error messages will be displayed as follows:

554 Unbalanced '<'
050 ... Connecting to  (local)...
554 ... Unbalanced '<'
554 ... Unbalanced '<'
050 ... Sent
554 Unbalanced '<'
554 Unbalanced '<'


PROBLEM:        (HPAQ85B98, QAR 41131)  (Patch ID: OSF365-350331)
********
Fixes a problem in which the sendmail command loops endlessly trying to get a
"tf" control file in /var/spool/mqueue.


PROBLEM:        (SSRT0421U, QAR 49337)  (Patch ID: OSF365-350331)
********
A potential security vulnerability has been discovered with the sendmail
command, where under certain circumstances, users may gain unauthorized access.
Digital has corrected this potential vulnerability.


FILE(s):

/usr/sbin/mailq                 subset OSFBASE350
CHECKSUM: 30357    208
/usr/sbin/newaliases            subset OSFBASE350
CHECKSUM: 30357    208
/usr/sbin/sendmail		subset OSFBASE350
CHECKSUM: 30357    208     
/usr/sbin/smtpd			subset OSFBASE350
CHECKSUM: 30357    208
/usr/var/adm/sendmail/.mrg..sendmail.cf  subset OSFBASE350
CHECKSUM: 46196      4
/usr/var/adm/sendmail/.new..sendmail.cf  subset OSFBASE350
CHECKSUM: 45399     21 

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

SUPERSEDES PATCHES:	OSF365-360026 (61.00), OSF365-360054 (79.00),
			OSF365-360066 (86.00), OSF365-360100 (313.00)

This patch corrects the following:

- Removes support for atTable, so that common applications
  (like NetView autodiscovery) will use the ipNetToMediaTable instead.

  The SNMP agent returns incorrect data when requested for the MIB II
  Address Translation Table (atTable).  The agent returns correct data
  for ipNetToMediaTable, which supercedes atTable in MIB II.

- Fixes memory leaks with the FDDI and Token Ring method routines
  used with Extensible SNMP subagent (ESNMP).

- The Host MIB code uses incorrect presentation names for some processors. This
  is seen when retrieving the MIB variable "hrDeviceDescr".  This patch also 
  adds presentation names for processors.

- This patch allows the extensible SNMP deamon to handle a very high volume of 
  SNMP trap requests.

- This patch is a general upgrade for eSNMP components.
PROBLEM:         (QAR's 39931 40880 41545 41620 43738 44872 44885, HPXQ34A01)
********         (Patch ID: OSF360-026)

This patch fixes bugs in both the operation of the SNMP agent (returned MIB
values) and bugs encountered when developing eSNMP subagents.

 o The MIB II value ifLastChange was incorrect

 o linkUp/Down traps were not generated consistently|o linkUp/Dpwn traps
   did not contain the ifIndex of the particular interface

 o The MIB II value of sysObjectID included the Digital UNIX version numbers,
   it now is a fixed value (enterprises.dec.ema.sysobjectids.decosf.esnmp)

 o The MIB II values in udpTable were being returned incorrectly in response
   to a GetNext request

 o snmpd did not read /etc/services for its port assignment

 o esnmp.h would not compile with C++

 o esnmp_poll() was not handling the UNDO phase of SetRequest processing 
   correctly

 o esnmp_sysuptime() returned bogus values before the protocol has initialized


PROBLEM:	(QAR 46587)	(Patch ID: OSF365-360054)
********
When the system experiences a very high volume of SNMP trap requests, 
some SNMP traps may be lost.


PROBLEM:	(QAR 46564)	(Patch ID: OSF365-360066)
********
The Host MIB code uses incorrect presentation names for some processors.  
When retrieving the MIB variable "hrDeviceDescr", some processors will return 
the internal Digital name instead of the proper processor name.  

An example of the respective strings returned from the Host MIB follow.

  without the patch:  "Cobra"
  with the patch:     "DEC 4000 Model 610"

This adds the ability to retrieve a presentation name for a processor.


PROBLEM:        (QAR 51930)     (Patch ID: OSF365-360100)
********
This patch fixes memory leaks with the FDDI and Token Ring method
routines used with Extensible SNMP subagent (ESNMP).


PROBLEM:        (GOZ100745)     (Patch ID: OSF365-360114)
********
The SNMP agent returns incorrect data when requested for the MIB II
Address Translation Table (atTable).  The agent returns correct data
for ipNetToMediaTable, which supercedes atTable in MIB II.


FILE(s):

/usr/sbin/os_mibs	subset OSFCLINET365
CHECKSUM: 36091    192	RCSfile: hrm_cpu.c   RCS: 1.1.7.4
			RCSfile: os_mibs.c   	RCS: 1.1.8.3
                        RCSfile: os_mibs_shm.c  RCS: 1.1.5.2
/usr/sbin/snmp_request	subset OSFINET365
CHECKSUM: 24822     88	RCSfile: snmp_request.c RCS: 1.1.4.2
/usr/sbin/snmp_traprcv	subset OSFINET365
CHECKSUM: 53844     80	RCSfile: snmp_traprcv.c RCS: 1.1.7.2
/usr/sbin/snmpd		subset OSFCLINET365
CHECKSUM: 50116    120	RCSfile: mstr_sr.c   RCS: 1.1.7.2
/usr/sbin/snmpi		subset OSFINET365
CHECKSUM: 03741     48	RCSfile: snmpi.c     RCS: 1.1.8.2
/usr/shlib/libesnmp.so	subset OSFCLINET365
CHECKSUM: 27831     88	RCSfile: esnmp_init.c   RCS: 1.1.11.2 
/usr/include/esnmp.h    subset OSFPGMR365
CHECKSUM: 62495     16  RCSfile: esnmp.h     RCS: 1.1.10.2

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

A system that boots and runs OK with 3 DE425s on an eisa bus may hang during
boot if a 4th DE425 is added to the bus.

If a device's EISA configuration file contains a function DISABLE keyword and 
the DISABLE option is selected, the device's driver may not be configured and 
probed at bus configuration time.
PROBLEM:        (EVT101968)              (Patch ID: OSF365-350334)
********
A system that boots and runs OK with 3 DE425s on an EISA bus may hang during
boot if a 4th DE425 is added to the bus.  The last message printed to the
screen during boot is "eisa at pci0" or something similar, and then the system
hangs.  It does not respond to the halt button.


PROBLEM:                                 (Patch ID: OSF365-350334)
********
When devices with a "disable" feature are used, the ECU table must be modified
manually when a device function is set to "disabled" because the system does
not detect the change.


FILE(s):

/usr/sys/BINARY/eisa_cnfg.o         subset OSFHWBIN350
CHECKSUM: 58340     13	RCSfile: eisa_cnfg.c   RCS: 1.1.41.2

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

SUPERSEDES PATCHES:	OSF365X-002 (240.00)

This patch corrects the following:

- Systems with an S3 Trio64 graphics card can loose time (on the order of 
  a few minutes a day).

- Fixes a situation where a system with an S3 Trio64 graphics card set at
  1280x1024 resolution does not correctly display the cursor.
PROBLEM:        (QAR 42672)             (Patch ID: OSF365X-002)
********
On a system with an S3 Trio64 graphics card set at a resolution of
1280x1024, the cursor does not display correctly.


PROBLEM:	(QAR 51230)		(Patch ID: OSF365X-003)
********
Systems with an S3 Trio64 graphics card can loose time (on the order of
a few minutes a day).


FILE(s):

/usr/shlib/X11/lib_dec_s3.so            subset OSFSERPCI365
CHECKSUM: 56700    152	RCSfile: s3curs.c  RCS: 1.1.21.2
			RCSfile: s3io.c	   RCS: 1.1.24.2
			RCSfile: s3init.c  RCS: 1.1.15.2

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

Fix swapping of ListFontsWithXInfo reply.
PROBLEM:      (HPXQA2963,ISO100156,HPXQA3243)   (Patch ID: OSF365X-350006)
********
The X font server will sometimes crash when serving fonts to a system
with big-endian byte ordering such as an NCD X terminal.

The stack traces in the resulting core files will vary, but often Xalloc()
FSalloc(), and malloc() will be at the top of the stack.


FILE(s):

/usr/bin/X11/fs		subset OSFX11350
CHECKSUM: 22675    184

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

Fix problem with X server DPS gray ramp.
PROBLEM:        (MGO101537)             (Patch ID: OSF3650X-350011)
********
There is a problem in the X server Display PostScript code that can
cause incorrect colors to be displayed when using a gray ramp with
only two cells with a visual of depth greater than 1.


FILE(s):

/usr/shlib/X11/lib_adobe_dps.so         subset OSFSER350
CHECKSUM: 36984   3376  RCSfile: xdirect.c	RCS: 1.1.6.2
			RCSfile: xwinext.c	RCS: 1.1.6.2

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

SUPERSEDES PATCHES:	OSF365X-350005 (242.00), OSF365X-350008 (245.00)

This patch corrects the following:

- A potential security vulnerability has been discovered, where under certain
  circumstances users may gain unauthorized access.  Digital has corrected
  this potential vulnerability.

- XAddPixel problem with ZPixmap and TrueColor. 

- xdm can't manage more than 8 displays on Digital UNIX V3.2F 
PROBLEM:        (MGO101734, STLBA4448)          (Patch ID: OSF365X-350005)
********
The X display manager, xdm, may get a segmentation fault when forking a
child to manage a new display or X terminal.  Often this happens when
managing the ninth concurrent display on a system.  

The /usr/lib/X11/xdm/xdm-errors file will contain messages similar to the
following:

    error (pid 2830): Unknown session exit code 2816 from process 2326


PROBLEM:        (TKTQ31025)             (Patch ID: OSF360X-350008)
********
The Xlib function XAddPixel may not work correctly when the format
of the image is ZPixmap and the visual is TrueColor.  Some pixels
may not be changed.


PROBLEM:	(SSRT0368U)		(Patch ID: OSF365X-350015)
********
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/X11/xdm 		subset OSFX11365
CHECKSUM: 48229    128
/usr/lib/libX11.a 		subset OSFXDEV365
CHECKSUM: 04107   2020
/usr/lib/libXau.a 		subset OSFXDEV365
CHECKSUM: 14686     21
/usr/shlib/X11/libXau.so 	subset OSFSER365
CHECKSUM: 59521     32
/usr/shlib/X11/libos.so 	subset OSFX11365
CHECKSUM: 54009    128
/usr/shlib/libX11.so 		subset OSFX11365
CHECKSUM: 03505   1016

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

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: OSF365-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: 65497      8  RCSfile: log.c  RCS: 4.2.18.2

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

If a new group is added with XSysAdmin and then tries to use XIsso to add the 
user into the new group, the group shows up but the user never gets added.
PROBLEM:	(MCPM5091F)	(Patch ID: OSF365X-350019)
********
If the customer adds a new group with XSysAdmin and then tries 
to use XIsso to add the user into the new group, the group shows up 
but the user never gets added. 

If you add that group to the user profile and then save it (ok or apply) 
and then pull up that user they are not part of the group.


FILE(s):

/usr/tcb/bin/XIsso		subset OSFXC2SEC350
CHECKSUM: 04113    392	RCSfile: NISutils.c   RCS: 1.1.6.2
/usr/tcb/bin/XSysAdmin		subset OSFXC2SEC350
CHECKSUM: 20759    368	RCSfile: NISutils.c   RCS: 1.1.6.2

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

X server performance is slow when an application is drawing arcs which are
outside the bounds of the drawable window.
PROBLEM:	(QAR 45015)	(Patch ID: OSF365X-350020)
********
X server performance is slow when an application is drawing arcs
which are outside the bounds of the drawable window.


FILE(s):

/usr/shlib/X11/libmi.so 	subset OSFX11350
CHECKSUM: 57638    296

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

A potential security vulnerability has been discovered in 'libXt', where under
certain circumstances users may gain unauthorized access. Digital has corrected
this potential vulnerability.
PROBLEM:	(QAR 47205)	(Patch ID: OSF365X-350021)
********
A potential security vulnerability has been discovered in 'libXt',
where under certain circumstances users may gain unauthorized access.
Digital has corrected this potential vulnerability.


FILE(s):

/usr/lib/libXt.a		subset OSFXDEV350
CHECKSUM: 00061    908
/usr/shlib/libXt.so		subset OSFX11350
CHECKSUM: 53653    504

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

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: OSF365-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 OSFBIN365
CHECKSUM: 00331     77	RCSfile: vm_pagelru.c   RCS: 1.1.63.2

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

This patch adds the new resource printOnlyPrintables to dxterm.  When this
resource is set to TRUE (the default is FALSE), dxterm will not output any
escape sequences when printing.  This is needed for some PostScript printer
(or when using a print filter) that can not handle escape sequences.
PROBLEM:	(CLD TKTQA2401)	(Patch ID: OSF365X-350023)
********
When printing to a PostScript printer (or when using a print filter) that
does not understand ANSI escape sequences, the output contains extra,
unwanted characters.  These are the actual, uninterpreted escape sequences.

This patch adds the new resource printOnlyPrintables to dxterm which can
be used to suppress ANSI escape sequences when printing.

To enable the new resource (and tell dxterm to not send escape sequences
to the printer) start dxterm as follows:

    dxterm -xrm "*printOnlyPrintables: 1"

or add the following line to the dxterm resource file:

    DXterm.main.terminal.printOnlyPrintables: 1


FILE(s):

/usr/bin/X11/dxterm		subset OSFX11350
CHECKSUM: 11695    672     

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

Fixes a problem where the AdvFS filesystem command "vquotacheck -a"
erroneously sets all quotas for users to values derived from the
last AdvFS fileset in /etc/fstab, rather than the correct values
for each individual fileset.
PROBLEM:        (HPXQB22D0, QAR 45498)  (Patch ID: OSF365-360116)
********
This patch fixes problems with the AdvFS filesystem command "vquotacheck -a".

This command erroneously set all quotas for users to values derived
from the last AdvFS fileset in /etc/fstab, rather than the correct values
for each individual fileset.


FILE(s):

/usr/sbin/vquotacheck           subset OSFADVFS365
CHECKSUM: 59343    536  RCSfile: vquotacheck.c  RCS: 1.1.22.2

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

Bookreader hangs when displaying certain pages if the required fonts are
not available.  This problem usually occurs when redirecting Bookreader's
display to another vendor's workstation (HP or Sun).
PROBLEM:  (MGO101893, HPXQ931C7) (Patch ID: OSF365X-350025)
********
Bookreader hangs when displaying certain pages if the required fonts are
not available.  This problem usually occurs when redirecting Bookreader's
display to another vendor's workstation (HP or Sun).

The correct behavior which this patch implements is to display an error
message indicating that the page may not be displayed correctly because
the required fonts are not available.


FILE(s):

/usr/bin/X11/dxbook		subset OSFX11350
CHECKSUM: 47965    816     
/usr/lib/X11/uid/DXBookreader_1_2.uid		subset OSFX11350
CHECKSUM: 01210    164    

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

Big files (>10MB) take longer to copy to and from a PW-OSF server to a WfW
client than to a WNT server (NETbeui transport only).
PROBLEM:	(ZUO100334)	(Patch ID: OSF365-350149)
********
Big files (>10MB) take longer to copy to and from a PW-OSF server
to a WfW client than to a WNT server (NETbeui transport only).


FILE(s):

/usr/sys/BINARY/dlproc.o                subset OSFBIN350
CHECKSUM: 34313     19	RCSfile: dlproc.c	RCS: 1.1.13.2

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

Fixes a problem where the LAT subsystem limits the number of remote LAT nodes
on a Digital UNIX system to a maximum of 100.
PROBLEM:        (CLD HPAQ285B1, SPR STLQB0253)  (Patch ID: OSF365-350155)
********
This patch fixes a problem where the LAT subsystem limits the number of 
remote LAT nodes on a Digital UNIX system to a maximum of 100. 

The Digital UNIX subsystem keeps information about remote nodes which have 
broadcasted service service announcement messages. On a busy local are netowrk 
with many LAT devices, this maximum limit could be reached.  Users may see 
an error message such as "insufficent node resources" when trying to connect 
to the Digital UNIX system from a terminal server or other LAT host. 

With this patch to latcp installed, the LAT subsystem sets no limit on 
the maximum number of remote nodes that it stores information about.


FILE(s):

/usr/sbin/latcp                 	subset OSFLAT350
CHECKSUM: 19037    288	RCSfile: latctl.c   RCS: 1.1.21.2

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

SUPERSEDES PATCHES:	OSF365X-350010 (247.00), OSF365X-350016 (252.00)

This patch corrects the following:

- On systems with an ATI Mach64 graphics card, sometimes the monitor will
  lose synchronization or become stuck in power-save mode.

- On an AlphaStation 400 with two ATI Mach64 CX graphics cards (dual-screen),
  the display on the second screen is corrupted at 1280x1024 resolution.

- Fix dashed lines on ATI Mach64.
PROBLEM:        (MGO101857)    (Patch ID: OSF365X-350010)
********
Dashed lines with a line style of LineOnOffDash are too short when
displayed on an ATI Mach64 graphics option.


PROBLEM:	(MGO102057)	(Patch ID: OSF365X-350016)
********
On an AlphaStation 400 with two ATI Mach64 CX graphics cards (dual-screen),
the display on the second screen is corrupted at 1280x1024 resolution.


PROBLEM:	(TKTB71151, TKTB64248)	(Patch ID: OSF365X-350032)
********
On systems with an ATI Mach64 graphics card, sometimes the monitor will
lose synchronization or become stuck in power-save mode.


FILE(s):

/usr/shlib/X11/lib_dec_ati64.so         subset OSFSERPCI365
CHECKSUM: 23961    128	RCSfile: atiprocs.c  RCS: 1.1.16.2    
			RCSfile: atiio.c     RCS: 1.1.17.2

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

SUPERSEDES PATCHES:	OSF365-360052 (77.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

- Fixes "simple_lock: time limit exceeded" panics coming from 
  ctape_close() or ctape_strategy() routines.
PROBLEM:	(MCPM36085)	(Patch ID: OSF365-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: OSF365-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: OSF365-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 266)
(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 266)

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_prf.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 OSFHWBIN365
CHECKSUM: 64760    146	RCSfile: cam_tape.c	RCS: 1.1.73.3

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

Allows getty to accept uppercase usernames.
PROBLEM:        (HPXQ86E65, QAR 49170)  (Patch ID: OSF365-360081)
********
This patch allows getty to accept uppercase usernames.  This makes getty
consistent with the login and telnet commands.

Previously, getty would convert a terminal to display and accept
only uppercase letters if a username was entered in uppercase.


FILE(s):

/usr/sbin/getty                 subset OSFBASE365
CHECKSUM: 10492    168	RCSfile: getty.c   RCS: 4.3.38.2

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

SUPERSEDES PATCHES:	OSF365-022 (22.00)

This patch corrects the following:

- Fixes system panics on an SMP system with a tu (Tulip) Ethernet interface
  with error message, "System Uncorrectable Machine Check 660 (retry set)"

- Fix bug where packet reception on the DE500-XA PCI Fast Ethernet interface
  (device mnemonic "tu") comes to a halt under heavy system and network load.
PROBLEM:	(QAR 45779)	(Patch ID: OSF365-022)
********
Under relatively rare and stressful conditions, the DE500-XA Fast Ethernet
interface (tu) will stop receiving packets. This causes the interface to
appear hung. However, there's no explicit indication of this state at the
user level. The only way out of this state is to restart the network.


PROBLEM:        (S00100882)     (Patch ID: OSF365-049)
********
This patch fixes a problem that occurs on an SMP system with a
tu (Tulip) Ethernet interface.

The system panics with the following error message:

        System Uncorrectable Machine Check 660 (retry set)


FILE(s):

/usr/sys/BINARY/if_tu.o 	subset OSFHWBIN365
CHECKSUM: 08942     36	RCSfile: if_tu.c  RCS: 1.1.72.3

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

SUPERSEDES PATCHES:     OSF365-350160 (249.00), OSF365-350300 (219.00)

This patch corrects the following:

- 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.

- ftpd core dumps when using anonymous ftp with the ls commmand.

- A security issue in which a user using anonymous ftp could be logged in to 
  the root directory.
PROBLEM:        (CLD HPXQ917BA)         (Patch ID: OSF365-350160)
********
This patch fixes a security issue in which a user using anonymous ftp could be
logged in to the root directory.

If the home directory of 'ftp' (used for anonymous ftp) does not exist, or is
otherwise inaccessible to the 'ftp' user, then a user logging in via anonymous
ftp is logged in with a home directory of '/'.

Arrange for the home directory of the 'ftp' user to be inaccessible (by
renaming it to something else, for instance), then from ftp try logging into
the system with anonymous ftp.  If the login is successful and the user has /
for their home directory, the bug exists.

PROBLEM:        (QAR 48194)             (Patch ID: OSF365-350300)
********
When doing an ls in an ftp session and when current directory is under a
directory with execute-only permissions, ftpd was core dumping while trying to
generate a syslog entry.

PROBLEM:        (SSRT0448U, QAR 51211)   (Patch ID: OSF365-350335)
********
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.


FILE(s):

/usr/sbin/ftpd                      subset OSFCLINET350
CHECKSUM: 41810     96     RCSfile: ftpd.c         RCS: 4.2.28.4
                           RCSfile: ftpd_syslog.c  RCS: 1.1.2.2

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

SUPERSEDES PATCHES:     OSF365-350105 (46.00)

This patch corrects the following:

- Corrects a problem where multi-threaded applications will experience a hang 
  on SMP systems.

- Threaded applications have a tendency to exhaust memory before non-threaded
  applications do.  This patch corrects the thread -afe memory allocator.
PROBLEM:        (MGO101698)           (Patch ID: OSF365-350105)
********
Applications linked with DECthreads will behave as if they have no more memory
available to them when they are not even close to the operating system limit.

PROBLEM:        (IPMT MGO102540)      (Patch ID: OSF365-350336)
********
Multi-threaded applications may end up hanging on SMP systems.  This will occur
when a mutex, central to the application's operation, is left locked by the
DECthreads library.  There is no work around to this problem.


FILE(s):

/usr/shlib/libpthreads.so        subset OSFBASE350
CHECKSUM: 01071    576
/usr/ccs/lib/libpthreads.a       subset OSFPGMR350
CHECKSUM: 20797    439
/usr/include/dce/exc_handling.h  subset OSFPGMR350
CHECKSUM: 52343     30  RCSfile: exc_handling.h  RCS: 4.2.16.2

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

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:        (EVT101664)     (Patch ID: OSF365-350345)
********
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.


FILE(s):

/usr/sys/BINARY/ufs_bmap.o              subset OSFBIN350
CHECKSUM: 53664     15  RCSfile: ufs_bmap.c     RCS: 4.3.34.2

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

A potential security vulnerability has been discovered in talkd,
where under certain circumstances, system integrity may be
compromised.  Digital has corrected this potential vulnerability.
PROBLEM:	(SSRT0446U)	(Patch ID: OSF365-350351)
********
A potential security vulnerability has been discovered in talkd,
where under certain circumstances, system integrity may be
compromised.  Digital has corrected this potential vulnerability.


FILE(s):

/usr/sbin/talkd			subset OSFCLINET350
CHECKSUM: 49625     32	RCSfile: talkd.c   RCS: 4.2.6.2
/usr/sbin/ntalkd                 subset OSFCLINET350
CHECKSUM: 49625     32

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


This patch corrects the following:

- NFS mounted file systems may hang.

- The rpc.lockd program may fail because it loses a message granting
  NLM approval.

- An NFS mounted file system may hang.

- The rpc.lockd daemon may crash with a core dump.

- An error occurs with NFS mounted user mail files. This error prevents
  the files from being locked and prints out the following message:

        cannot lockf

- An NFS problem may occur and the system displays the following error message:

        NFS error 48 cannot bind sockets
PROBLEM:        (QAR 51227,43271)       (Patch ID: OSF365-350352)
********
This patch fixes a problem that can cause an NFS mounted file system to hang.
The problem is caused by an incorrect FCNTL return.


PROBLEM:        (QAR 14680)     (Patch ID: OSF365-350352)
********
This patch fixes a problem that can cause the rpc.lockd program to fail
because it loses a message granting NLM approval.

The message would be:

      call unlock_res stat granted

rather than:

      call lock_res stat blocked


PROBLEM:        (QAR 45844)     (Patch ID: OSF365-350352)
********
This patch fixes a problem that can cause an NFS mounted file system to hang
during file locking.


PROBLEM:        (QAR 46298)     (Patch ID: OSF365-350352)
********
This patch fixes a problem that can cause rpc.lockd to crash with a core dump.
Multi-vendor environments are particularly susceptible to this problem.


PROBLEM:        (QAR 46630)     (Patch ID: OSF365-350352)
********
This patch fixes a problem that occurs with NFS mounted user mail files.

The error prevents the files from being locked and prints out
the following message:

        cannot lockf


PROBLEM:        (QAR 49265)     (Patch ID: OSF365-350352)
********
This patch fixes an NFS problem. The system displays the following
error message:

        NFS error 48 cannot bind sockets

Other fixes include the cleanup of some error messages and to
direct more errors to syslog.

Additionally, the signal handler (SIGALRM) was redesigned to improve
the efficiency of retranmission and to prevent possible lost transmits.


FILE(s):

/usr/sbin/rpc.lockd             subset OSFNFS350
CHECKSUM: 33423    136

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

SUPERSEDES PATCHES:	OSF365-350347 (279.00)

This patch corrects the following:

- Fixes fsck operation where if 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.

- Fixes a problem in which the UFS property list can become corrupted.
PROBLEM:	(QAR 46424)	(Patch ID: OSF365-350347)
********
This patch fixes a problem in which the UFS property list can become corrupted.

To reproduce this problem, complete the following steps:
1. Create a relatively large property value on a file.
2. Create another property value on the same file.
3. Change the property value created in Step 1 to a smaller value.
4. Run fsck with the -o flag.

The fsck command reports that the file system is corrupted and displays
the following error message:

	** Phase 1 - Check Blocks and Sizes
	PROPERTY LIST BLOCK CORRUPTED I=3
	CLEAR? [yn] 


PROBLEM:        (QAR 50363)     (Patch ID: OSF365-350357)
********
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/rrz6c
/sbin/ufs_fsck /dev/rrz6c
** /dev/rrz6c
BAD SUPER BLOCK: MAGIC NUMBER WRONG
/dev/rrz6c: NOT LABELED AS A BSD FILE SYSTEM (swap)
# echo $?
0

ALSO:

# fsck /mnt
/sbin/ufs_fsck /mnt
Can't make sense out of name /mnt
# echo $?
0


FILE(s):

/sbin/ufs_fsck				subset OSFBASE350
CHECKSUM: 31906    328	RCSfile: main.c         RCS: 4.3.36.2
                        RCSfile: setup.c        RCS: 4.3.33.2
                        RCSfile: utilities.c    RCS: 4.3.18.2
                        RCSfile: preen.c        RCS: 4.3.30.2
/usr/sbin/ufs_fsck			subset OSFBASE350
CHECKSUM: 00805    112	RCSfile: inode.c	RCS: 4.3.25.2
                        RCSfile: main.c         RCS: 4.3.36.2
                        RCSfile: setup.c        RCS: 4.3.33.2
                        RCSfile: utilities.c    RCS: 4.3.18.2
                        RCSfile: preen.c        RCS: 4.3.30.2
/usr/sys/BINARY/ufs_proplist.o		subset OSFBIN350
CHECKSUM: 11544     22	RCSfile: ufs_proplist.c  RCS: 1.1.42.2

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

Fixes a problem in which the dd command can corrupt output on very large files
(2 GB or greater) when the "conv=sparse" option is used.
PROBLEM:	(QAR 47063)	(Patch ID: OSF365-350359)
********
This patch fixes a problem in which the dd command can corrupt output on 
very large files (2 GB or greater) when the "conv=sparse" option is used.

In some cases a seek error is reported:

       dd seek error: Invalid argument

In other cases a corrupt file is created with no error reported.


FILE(s):

/sbin/dd				subset OSFBASE350
CHECKSUM: 06260    496	RCSfile: inet_addr.c  RCS: 4.2.22.2
			RCSfile: dd.c	      RCS: 4.3.29.2
/usr/bin/dd				subset OSFBASE350
CHECKSUM: 34514    496	RCSfile: inet_addr.c  RCS: 4.2.22.2
			RCSfile: dd.c	      RCS: 4.3.29.2

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

Fixes an error that occurs when replying to a message in which the "CC:" field
contains blank-separated names not enclosed in angle brackets ("<...>").
PROBLEM:	(UVO105070, QAR 50239)	(Patch ID: OSF365-350362)
********
An error occurs when replying to a message in which the "CC:" field contains
blank-separated names not enclosed in angle brackets ("<...>").

When replying to mail using lowercase "r", the "CC:" field on the reply
lists all blank-separated names after all enclosed angle bracket addresses.

The following error message is displayed:

... User unknown


FILE(s):

/usr/bin/mailx			subset OSFBASE350
CHECKSUM: 61549    208
/usr/bin/Mail                  subset OSFBASE350
CHECKSUM: 61549    208

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

Fixes a problem that could cause the system to panic displaying
the following panic string:  "Simple_lock: hierarchy_violation."
PROBLEM:        (QAR 46810)     (Patch ID: OSF365-360089)
********
This patch corrects a problem that can cause a system to panic
when performing intensive I/O.

An example of the stack trace follows:

        ...
        ...
        _XentMM()
        threads_get_rusage()
        task_get_rusage()
        fake_u()
        table()
        syscall()
        _Xsyscall()


FILE(s):

/usr/sys/BINARY/vm_unix.o               subset OSFBIN365
CHECKSUM: 61545     13  RCSfile: vm_unix.c      RCS: 4.4.102.2

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

Fixes problem where exiting from the DECwindows Session Manager (dxsession)
via the 'Close' option of the window menu results in an undesirable saving
of dxsession's scratch file in /tmp.  Use of this button also causes
a behavior inconsistent, with dxsession's 'End Session' button.
PROBLEM:        (HPAQ210HY)     (Patch ID: OSF365X-350033)
********
When exiting from the DECwindows Session Manager (dxsession) via
the 'Close' option of the window menu results in an undesirable saving
of dxsession's scratch file in /tmp.  Use of this button also causes
a behavior inconsistent, with dxsession's 'End Session' button.


FILE(s):

/usr/bin/X11/dxsession          subset OSFX11350
CHECKSUM: 23838    232

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

Corrects a "kernel memory fault" system panic in the routine dl_set_timer().
PROBLEM:	(CLD MGO101710)	(Patch ID: OSF365-350161)
********
This patch fixes a "kernel memory fault" panic in the routine dl_set_timer().

This is a representative stack trace:

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1620]
   1 panic(s = 0xfffffc00005a1060 = "kernel memory fault")
        ["../../../../src/kernel/bsd/subr_prf.c":752]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281]
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1296]
   4 dl_set_timer() ["../../../../src/kernel/streamsm/dlpi/dltimer.c":152]
   5 llc_i() ["../../../../src/kernel/streamsm/dlpi/dlproc.c":1830]
   6 dlproc() ["../../../../src/kernel/streamsm/dlpi/dl.c":1223]
   7 dllrput() ["../../../../src/kernel/streamsm/dlpi/dl.c":1300]
   8 csq_lateral() ["../../../../src/kernel/streams/str_synch.c":977]
   9 puthere() ["../../../../src/kernel/streams/str_util.c":1055]
  10 dlb_rsrv() ["../../../../src/kernel/streamsm/dlb.c":1017]
  11 sq_wrapper() ["../../../../src/kernel/streams/str_runq.c":137]
  12 csq_lateral() ["../../../../src/kernel/streams/str_synch.c":977]
  13 runq_run() ["../../../../src/kernel/streams/str_runq.c":108]
  14 netisr_thread() ["../../../../src/kernel/net/netisr.c":821]


FILE(s):

/usr/sys/BINARY/dl.o            subset OSFBIN350
CHECKSUM: 63357     84	RCSfile: dl.c	RCS: 1.1.13.2

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

SUPERSEDES PATCHES:	OSF365-350199 (158.00), OSF365-350315 (229.00),
			OSF365-350368 (300.00)

This patch corrects the following:

- Fixes a problem for TLI applications which make use of the t_accept library
  routine.  The secondary endpoint state is not being set correctly.

- Corrects a problem encountered by tli applications which do
  an abort disconnect on an endpoint which was established as an orderly
  release endpoint and leave the endpoint in an unexpected state.

- The problem of t_rcv NOT setting the error flag (t_errno) when no data is 
  retrieved.

- Applies to the tli and xti library routines t_rcvrel and t_sndrel.
  The t_rcvrel routine does not work properly in the T_DATAXFER state; it
  returns T_OUTSTATE. The t_sndrel routine incorrectly returns a T_LOOK error.
PROBLEM:	(TKTQ21539)	(Patch ID: OSF365-350199)
********
This patch applies to the tli and xti library routines t_rcvrel and
t_sndrel.  The t_rcvrel routine does not work properly in the
T_DATAXFER state; it returns T_OUTSTATE.  The t_sndrel routine
incorrectly returns a T_LOOK error.


PROBLEM:	(TKTQ80149)	(Patch ID: OSF365-350315)
********
This patch insures that t_errno is set even when trcv retrieves no data.


PROBLEM:        (TKTQ30702)     (Patch ID: OSF365-350368)
********
This patch corrects a problem encountered by tli applications
which do an abort disconnect on an endpoint which was established
as an orderly release endpoint.  Previously, such an event would leave
the endpoint in an unexpected state.


PROBLEM:        (TKTQ52004)     (Patch ID: OSF365-350374)
********
This patch fixes a problem for TLI applications which make use of
the t_accept library routine.

The state of the secondary endpoint is not set correctly.


FILE(s):

/usr/ccs/lib/libtli.a		subset OSFPGMR350
CHECKSUM: 57713     77
/usr/ccs/lib/libxti.a		subset OSFPGMR350
CHECKSUM: 39143     80    
/usr/shlib/libtli.so		subset OSFBASE350
CHECKSUM: 47425     72   
/usr/shlib/libxti.so		subset OSFBASE350
CHECKSUM: 45768     56  
/usr/sys/BINARY/xtiso.o		subset OSFBIN350
CHECKSUM: 02466    119     RCS: xtiso.c      Revision: 4.4.50.5

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

Prevents a long delay while trying to log out using telnet.
PROBLEM:        (QAR 41739 SPR UTO100828)       (Patch ID: OSF365-360095)
********
This patch prevents a long delay while trying to log out using telnet.
When logging in with telnet on a alpha 2100 5/250 (2 CPU), home directory
is advfs and using ksh and C2 security, it takes about 1 minute to logout.


FILE(s):

/usr/sbin/telnetd               subset OSFCLINET365
CHECKSUM: 27038     80	RCSfile: telnetd.c      RCS: 4.2.12.2

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

Fixes a problem in which the tparm routine in the libcurses.a library
does not support more than a three digit value for its input parameter.
PROBLEM:        (UTO100950)     (Patch ID: OSF365-350378)
********
This patch fixes a problem in which the tparm routine in the
libcurses.a library produces the wrong output value if the input parameter
has a value of more than three digits (greater than 999).

This patch fixes this problem and accepts a tparm parameter value of up to
four digits.

The following program can be run to reproduce the problem:

cat>>tparm_test.c<
#include 
#include 

main()
{
    int lval;
    char *str;
    printf("enter value: ");
    scanf("%d", &lval);
    printf("enter value:%d\n ", lval);
    str = (char *)calloc(16, sizeof(char));
    strcpy(str, "\\E\[\%p1\%dX");
    printf("string for substitution: %s\n", str);
    str = (char *)tparm(str, lval);
    printf("string after substitution  : %s\n", str);
}
EOF

#cc -o tparm_test tparm_test.c -lcurses
#./tparm_test
enter value: 123
string for substitution: \E[%p1%dX
string after substitution  : \E[123X      (%p1 replaced by 123)
#
# ./tparm_test
enter value: 1234
string for substitution: \E[%p1%dX
string after substitution  : \E[<34X      (%p1 replaced by 34)
#
The correct string after substitution should be: \E[1234X


FILE(s):

/usr/ccs/lib/libcurses.a        subset OSFPGMR350
CHECKSUM: 20003    363
/usr/shlib/libcurses.so         subset OSFBASE350
CHECKSUM: 05416    280

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

Fixes a problem in which the system crashes when attempting to NFS mount 
a text file.
PROBLEM:        (QAR 46893)     (Patch ID: OSF365-360097)
********
This patch fixes a problem in which the system crashes when
attempting to NFS mount a text file.

The panic backtrace will look similar to the following:

(kdbx) t
>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c"]
   1 panic("ubc_invalidate: NULL object")
          ["../../../../src/kernel/bsd/subr_prf.c"]
   2 ubc_invalidate() ["../../../../src/kernel/vfs/vfs_ubc.c"]
   3 nfs3_getattr_otw() ["../../../../src/kernel/nfs/nfs_client.c"]
   4 nfs3getattr() ["../../../../src/kernel/nfs/nfs_client.c"]
   5 nfs3_getattr() ["../../../../src/kernel/nfs/nfs3_vnodeops.c"]
   6 vn_stat() ["../../../../src/kernel/vfs/vfs_vnops.c"]
   7 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c"]
   8 lstat() ["../../../../src/kernel/vfs/vfs_syscalls.c"]
   9 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c"]
  10 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"]
(kdbx)


FILE(s):

/usr/sys/BINARY/nfs_client.o            subset OSFBIN365
CHECKSUM: 47979     12	RCSfile: nfs_client.c   RCS: 1.1.59.2

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

Fixes the pipe function, occurs primarily on SMP systems,
that exits prematurely causing data errors.
PROBLEM:  (QAR 46316,37041/7NSB13773/TKTB14933)   (Patch ID: OSF365-360098)
********
This patch fixes a problem with the pipe function that occurs
primarily on SMP systems.  The pipe function exits prematurely
causing data errors and does not produce the expected results.


FILE(s):

/usr/sys/BINARY/fifo_vnops.o            subset OSFBIN365
CHECKSUM: 42583     73  RCSfile: fifo_vnops.c   RCS: 4.3.80.2

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

Fixes a potential security vulnerability in BIND.
PROBLEM:        (CLD-00805)     (Patch ID: OSF365-360082B)
********
A potential security vulnerability has been discovered in BIND
 (Domain Name Service), 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.


FILE(s):

/sbin/named                             subset OSFINET365
CHECKSUM: 34332    416
/usr/sbin/named                         subset OSFINET365
CHECKSUM: 25918    192
/usr/sbin/named-xfer                    subset OSFINET350
CHECKSUM: 34966     48  RCSfile: named-xfer.c   RCS: 4.2.15.2
/usr/sbin/screend                       subset OSFINET350
CHECKSUM: 51637    312  RCSfile: screend.c      RCS: 1.1.3.2

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

Fixes a potential security vulnerability in BIND.
PROBLEM:        (CLD-00805)     (Patch ID: OSF365-360082C)
********
A potential security vulnerability has been discovered in BIND
 (Domain Name Service), 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.


FILE(s):

/usr/bin/uucp                           subset OSFUUCP350
CHECKSUM: 01477    336  RCSfile: uucp.c         RCS: 4.3.8.2
                        RCSfile: uucpdefs.c     RCS: 4.3.6.3
                        RCSfile: uucpname.c     RCS: 4.3.5.2
/usr/lib/uucp/uucico                    subset OSFUUCP350
CHECKSUM: 09516    480
/usr/lib/uucp/uucleanup                 subset OSFUUCP350
CHECKSUM: 23147    320  RCSfile: uucleanup.c    RCS: 4.3.8.3
/usr/sbin/uucpd                         subset OSFUUCP350
CHECKSUM: 29271    272  RCSfile: uucpd.c        RCS: 4.3.6.3

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

SUPERSEDES PATCHES:     OSF365-350188 (150.00)

This patch corrects the following:

- Fixes a problem where the syslogd program cannot properly forward
  large messages to remote systems.  It will either write them to
  the wrong facility (specified in /etc/syslog.conf) or write incomplete data.

- After a login session on /dev/console exits, syslogd cannot write to
  /dev/console.
PROBLEM:	(MGO101831)	(Patch ID: OSF365-350188)
********
After a login session on /dev/console exits, syslogd cannot write 
to /dev/console .


PROBLEM:        (TKTB51380)     (Patch ID: OSF365-350383)
********
This patch fixes a problem in which the syslogd program
cannot properly forward large messages to remote systems.
It will either write them to the wrong facility
 (specified in /etc/syslog.conf) or write incomplete data.


FILE(s):

/usr/sbin/syslogd 		subset OSFBASE350
CHECKSUM: 01990     40	RCSfile: syslogd.c   RCS: 4.2.25.3

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

SUPERSEDES PATCHES:	OSF365-350084 (263.00),  OSF365-350146 (125.00),
                        OSF365-350151 (127.00),  OSF365-350151-1 (127.01),
                        OSF365-350158 (131.00),  OSF365-350192 (153.00),
                        OSF365-350193 (154.00),  OSF365-350195 (155.00),
                        OSF365-350248 (192.00),  OSF365-350294 (216.00),
                        OSF365-350305 (223.00),  OSF365-350319 (233.00),
                        OSF365-350338 (276.00),  OSF365-350342 (277.00),
                        OSF365-055 (305.00),     OSF365-057 (310.00)

This patch corrects the following:

- Enhanced fix to the solockpair() routine; problem symptoms include
  kernel memory faults with sockets, mbufs and mblocks as well as hangs.
  Applications using sockets in a multi-threaded, multi-cpu environment can
  experience a number of lock violations with the socket structures.

- Fixes a problem in which packet filter programs do not receive packets
  when the source is sending multicast packets on an Ethernet network.

- 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

- Fixes situation of a Digital UNIX system connected to a token ring network
  receiving a ping, not being able to respond and the token ring driver
  displays "List Error in transmit" message.

- 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.
 
- 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.

- 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().

- Fixes a system panic caused by a Windows95 or WindowsNT system sending an 
  illegal length ping ( ICMP ) packet.  

- Fixes a kernel memory fault panic that occurs on SMP platforms when running 
  the Unicenter product from Computer Associates in conjunction with Oracle 
  software.

- Fixes a problem in which broadcast packets are received by a daemon listening
  to a port that is using both the INP_RECVDSTADDR and SO_REUSEPORT socket 
  options. The packets were not being delivered to the listening daemon.

- Under certain conditions, a user on a remote host can cause a Digital UNIX
  host to hang or panic.

- Fixes a situation where an SMP machine acting as a network web server panics.
  The system will display panic strings such as the following:
      o "Unaligned kernel space access from kernel mode"
      o "kernel memory fault"
      o "simple_lock: minimum spl violation"  (when lockmode = 4)

- Fix locking window exposed in sodequeue() when dozens of of daemons
  (typically web servers) perform accept()'s on the same head socket.

- Improves the performance of the network on a system being used as a web 
  server. There are additional tuneable parameters included to be used by 
  an experienced system administrator.

- Fixes a problem in which the system panics when an interface is deleted.

- System crashes with "Unaligned kernel space access from kernel mode"
  (Packetfilter unaligned access panic from ipintr).
PROBLEM:        (CLD HPAQ738E0)         (Patch ID: OSF365-350084)
********
System crashes with "Unaligned kernel space access from kernel mode".

The system uses the packetfilter option and "copyall" mode to receive
loopback packets sent via the packetfilter.  The crash shows an unaligned
access (longword access attempt using a non-longword address) from ipintr.
The problem occurs whenever a packet larger than 170 bytes is written through
the packetfilter and the packet is a loopback packet (destined for the local
machine) or a broadcast packet (which gets copied to the local host).

Software packages which can trigger this include Insignia "SoftWindows"
and LISP "OpenGenera" software from Symbolics, Inc.  Both of these packages
use the packetfilter subsystem with the loopback feature and the "copyall"
packetfilter flag.

The kernel stack trace looks like:

>  0 boot(0x0, 0x0, 0xfffffc00005ff260, 0xfffffc0000712000, 0x4ce) ["../../../../src/kernel/arch/alpha/machdep.c":1620, 0xfffffc00004ded70]
   1 panic(s = 0xfffffc00005ff260 = "Unaligned kernel space access from kernel mode") ["../../../../src/kernel/bsd/subr_prf.c":752, 0xfffffc000043fa24]
   2 afault_print(va = -1885323230, type = -4398039504952, regno = 16, pc = -4398039505056, ps = -1886086912, ra = -4294967285) ["../../../../src/kernel/arch/alpha/trap.c":1486, 0xfffffc00004ed97c]
   3 _XentUna(0x0, 0xfffffc0000307824, 0xfffffc00006369e0, 0xfffffc0000694618, 0xffffffff8f9a7300) ["../../../../src/kernel/arch/alpha/locore.s":1429,0xfffffc00004dc088]
   4 ipintr(0xfffffc0000307300, 0xfffffc00005c7400, 0xfffffc00006adf40, 0x1, 0xfffffc00006ae760) ["../../../../src/kernel/netinet/ip_input.c":526, 0xfffffc0000307820]
   5 netisr_thread() ["../../../../src/kernel/net/netisr.c":825, 0xfffffc0000477260]


PROBLEM:        (CLD 7AZB92029)         (Patch ID: OSF360-350084)
********
When writing packets using the packetfilter on FDDI, there are 14 bytes
of corruption in the link layer header of the packet, so the packet
appears corrupted on the FDDI ring.  This fix is to the FDDI/packet
filter code for an erroneous write-side bcopy, which has been corrected.

This problem does not occur using Ethernet.  It is included here
so that patch #1 does not get overwritten.  There is no impact (side
effects, etc.) if this patch is installed when FDDI is not being used.


PROBLEM:	(FNO100098)		(Patch ID: OSF365-350146)
********
A user on a remote host can cause a Digital UNIX host to hang or panic.  

A typical stack trace follows.

 1 panic("thread_block: interrupt level call") ["../../../../src/kernel/bsd/subr_prf.c":673]
 2 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1744]
 3 thread_preempt() ["../../../../src/kernel/kern/sched_prim.c":3456]
 4 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1671]
 5 panic("Processor Machine Check") ["../../../../src/kernel/bsd/subr_prf.c":757]
 6 kn470_machcheck() ["../../../../src/kernel/arch/alpha/hal/kn470.c":833]
 7 mach_error() ["../../../../src/kernel/arch/alpha/hal/cpusw.c":801]
 8 _XentInt() ["../../../../src/kernel/arch/alpha/locore.s":997]
 9 in_checksum() ["../../../../src/kernel/arch/alpha/in_checksum.s":103]
10 in_cksum() ["../../../../src/kernel/arch/alpha/in_cksum.c":112]
11 icmp_input() ["../../../../src/kernel/netinet/ip_icmp.c":335]
12 ipintr() ["../../../../src/kernel/netinet/ip_input.c":715]
13 netisr_thread() ["../../../../src/kernel/net/netisr.c":806]
 _dump_end: 


PROBLEM:   (MCPMC5074, MCPM12C58, MCPM18F82)	(Patch ID: OSF365-350151)
********
An SMP machine running a large number of web server daemons, for example,
"ns-httpd" or "httpd", may experience an SMP race condition that will cause the
system to panic.  These panics occur when the web server daemons all accept
incoming sockets on the same head socket.

The following are examples of potential stack traces that illustrate the
problem addressed by this CLD:

Example of "Unaligned kernel space access from kernel mode" panic:
                                                                                >  0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":368 ]
   1 panic("event_timeout: panic request") ["../../../../src/kernel/bsd/subr_prf
.c":669 ]
   2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":725 ]
   3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810 ]
   4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355 ]
   5 panic("Unaligned kernel space access from kernel mode") ["../../../../src/k
ernel/bsd/subr_prf.c":719 ]
   6 afault_print() ["../../../../src/kernel/arch/alpha/trap.c":1418 ]
   7 _XentUna() ["../../../../src/kernel/arch/alpha/locore.s":1443 ]
   8 sounlock_ext() ["../../../../src/kernel/bsd/uipc_socket.c":634 ]
   9 sodequeue() ["../../../../src/kernel/bsd/uipc_socket.c":1925 ]
  10 accept1() ["../../../../src/kernel/bsd/uipc_syscalls.c":393 ]
  11 oaccept() ["../../../../src/kernel/bsd/uipc_syscalls.c":319 ]
  12 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519 ]
  13 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094 ]

Example of "kernel memory fault" panic:

>  0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":368 ]
   1 panic("event_timeout: panic request") ["../../../../src/kernel/bsd/subr_prf
.c":669 ]
   2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":725 ]
   3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810 ]
   4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355 ]
   5 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":719 ]
   6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213 ]
   7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307 ]
   8 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":662 ]
   9 sonewsock() ["../../../../src/kernel/bsd/uipc_socket2.c":380 ]
  10 tcp_input() ["../../../../src/kernel/netinet/tcp_input.c":611 ]
  11 ipintr() ["../../../../src/kernel/netinet/ip_input.c":715 ]
  12 netisr_thread() ["../../../../src/kernel/net/netisr.c":806 ]

Example of "simple_lock: minimum spl violation" panic (when lockmode = 4):

>  0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":368 ]
   1 panic("event_timeout: panic request") ["../../../../src/kernel/bsd/subr_prf
.c":669 ]
   2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":725 ]
   3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810 ]
   4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355 ]
   5 panic("simple_lock: minimum spl violation") ["../../../../src/kernel/bsd/su
br_prf.c":719 ]
   6 simple_lock_fault() ["../../../../src/kernel/kern/lock.c":1794 ]
   7 simple_lock_minspl_violation() ["../../../../src/kernel/kern/lock.c":1841 ]
   8 lock_write() ["../../../../src/kernel/kern/lock.c":473 ]
   9 solock_ext() ["../../../../src/kernel/bsd/uipc_socket.c":616 ]
  10 sodequeue() ["../../../../src/kernel/bsd/uipc_socket.c":1922 ]
  11 accept1() ["../../../../src/kernel/bsd/uipc_syscalls.c":393 ]
  12 oaccept() ["../../../../src/kernel/bsd/uipc_syscalls.c":319 ]
  13 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":534 ]
  14 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094 ]


PROBLEM:	(QAR 45094)		(Patch ID: OSF365-350158)
********
This set of files improves the performance of the network subsystem 
on a system being used as a web server.  

There are additional tunable parameters included here, to be used 
cautiously by an informed system administrator.

CAUTION: Only experienced network system administrators should be using 
         these parameters to modify their system. Adverse effects may result.
	
PLEASE ensure that the customer receiving this patch is a knowledgeable
  network administrator.  This information cannot be understood by 
  those without in-depth knowledge of the network and it's workings.

PLEASE DO give this to major customers running big systems as web servers. 
  They will have the people who understand the features being provided.


TUNING

To tune the web server one has to take into account several parameters
the 1st being the number of simultaneous connection requests. If the 
expected number is too low for the actual number the connections will
be dropped even though the bandwidth is available. 

The two parameters used for adjusting this are:

To tune the web server, the number of simultaneous socket connection 
requests are limited by:

  somaxconnx	Sets the maximum number of pending requests allowed to wait 
		on a listening socket.  

		The default value in Digital UNIX V3.2 is 8.

		This patch kit increases the default to 1024, which matches 
		the value in Digital UNIX V4.0.

  sominconn	Sets the minimum number of pending connections allowed on 
		a listening socket.  When a user process calls listen with 
		a backlog less than sominconn, the backlog will be set to
                sominconn.  sominconn overrides somaxconn.  

		The default value is 1.


The effectiveness of tuning these parameters can be monitored by the sobacklog
variables available in the kernel

  sobacklog_hiwat  Tracks the maximum pending requests to any socket 
		through out the life of the system.  The initial value is 0.

  sobacklog_drops  Tracks the number of drops resulting from exceeding 
		the socket set backlog limit.  The initial value is 0.

  somaxconn_drops  Tracks the number of drops due to exceeding the somaxconn 
		limit.  When sominconn is larger than somaxconn, tracks the 
		number of drops exceeding sominconn.  The initial value is 0.


Tcp timer parameters also effect performance. Tuning the following require
some knowledge of the characteristics of the network.

  tcp_msl	Sets the tcp maximum segment lifetime.

                This is the maximum lifetime in half seconds that a packet 
		can be in transit on the network.  This value, when doubled,
                is the length of time a connection remains in the TIME_WAIT 
		state after a incoming close request is processed.  

		The unit is specified in 1/2 seconds, the initial value is 60.

  tcp_rexmit_interval_min	Sets the minimum TCP retransmit interval.

                For some WAN networks the default value may be too short, 
		causing unnecessary duplicate packets to be sent.  

		The unit is specified in 1/2 seconds, the initial value is 1.

  tcp_keepinit	This is the amount of time a partially established connection 
		will sit on the listen queue before timing out 
		(e.g. if a client sends a SYN but never answers our SYN/ACK).
                Partially established connections tie up slots on the listen 
		queue.  If the queue starts to fill with connections in 
		SYN_RCVD state, tcp_keepinit can be decreased to make those
                partial connects time out sooner.  This should be used with 
		caution, since there might be legitimate clients that are 
		taking a while to respond to SYN/ACK.  The unit is specified
                in 1/2 seconds, the default value is 150 (ie. 75 seconds).


The hashlist size for the TCP inpcb lookup table is regulated by:

  tcbhashsize   The number of hash buckets used for the TCP connection table 
		used in the kernel.  The initial value is 32.  

		For best results, should be specified as a power of 2.

The hashlist size for the interface alias table is regulated by:

  inifaddr_hsize  The number of hash buckets used for the interface alias 
		table used in the kernel.  

		The initial value is 32.  

		For best results, should be specified as a power of 2.


The maximum system assigned user port number is limited by:

   ipport_userreserved   The largest port number given to a user process 
		requesting a system-assigned port (INADDR_ANY).  

		The default is 5000, which allows 3975 ports to be assigned 
		in the range 1025-5000.  The maximum is value is 65535.


PROBLEM:	(QAR 37825)		(Patch ID: OSF365-350192)
********
This patch fixes a problem in which the system panics when an interface 
is deleted. 

The following is an example of a typical stack trace:

   1 panic( "in_delmulti" )
   2 in_delmulti() netinet/in.c"1409
   3 ip_freemoptions() netinet/ip_output.c":1423
   4 in_pcbfree() netinet/in_pcb.c":590
   5 in_pcbdetach() netinet/in_pcb.c":561
   6 udp_usrreq() netinet/udp_usrreq.c":1039
   7 soclose() bsd/uipc_socket.c":799
   8 soo_close() bsd/sys_socket.c":401
   9 closef() bsd/kern_descrip.c":1468
  10 close() bsd/kern_descrip.c":1146
  11 syscall()


PROBLEM:	(38134)			(Patch ID: OSF365-350193)
********
This patch provides a new tcp level socket option called TCP_NODELACK. 
This socket option allows a user to force an ack (acknowledge) after 
each received packet. 


PROBLEM:				(Patch ID: OSF365-350195)
********
This patch fixes a problem in which broadcast packets are received by
a daemon listening to a port that is using both the INP_RECVDSTADDR 
and SO_REUSEPORT socket options. The packets were not being delivered 
to the listening daemon.


PROBLEM:	(USG-03327)		(Patch ID: OSF365-350248)
********
This patch fixes a kernel memory fault panic that occurs on SMP platforms.

The problem occurs when running the Unicenter product from Computer Associates 
in conjunction with Oracle software.

This panic will show a variety of stack traces due to memory corruption
caused by the inadvertant freeing of a memory block. The panic string will
always be "kernel memory fault".


1 panic(s = "kernel memory fault") subr_prf.c:757
2 trap() trap.c:1223
3 _XentMM() locore.s:1307
4 obj_entry_find() ipc_prims.c:112
5 port_dealloc() ipc_kport.c:331
6 ipc_task_terminate() ipc_tt.c:373
7 task_terminate() task.c:648
8 exit() kern_exit.c:922
9 rexit() kern_exit.c:635
10 Enf_exit() enfk_exit.c:121
11 syscall() syscall_trap.c:519

9 panic(s = "kernel memory fault") subr_prf.c:757
10 trap() trap.c:1223
11 _XentMM()locore.s:1307
12 malloc() kern_malloc.c:747
13 msg_copyin() ipc_copyin.c:414
14 msg_rpc_trap() ipc_basics.c:1405
15 _Xsyscall() locore.s:1249

7 panic(s = "kernel memory fault") subr_prf.c:757
8 trap() trap.c:1223
9 _XentMM()locore.s:1307
10 ubc_flush_dirty() vfs_ubc.c:2978
11 ufs_fsync_int() ufs_vnops.c:2007
12 ufs_fsync() ufs_vnops.c:2105
13 ufs_sync() ufs_vfsops.c:1600
14 sync() vfs_syscalls.c:1395
15 syscall() syscall_trap.c:519


PROBLEM:	(FNO100128)	(Patch ID: OSF365-350294)
********
This patch fixes a system panic caused by a Windows95 or WindowsNT system
sending an illegal length ping (ICMP) packet.  This patch is MANDATORY.


PROBLEM:        (QAR 49023)     (Patch ID: OSF365-350305)
********
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:	(MCPMA986D)	(Patch ID: OSF365-350319)
********
This patch is a kernel fix for network sockets left in FIN_WAIT_1 state forever.

This patch contains a "tunable" kernel parameter.  It is recommended that
only experienced system administrators attempt to set this parameter from
the default value.

How to recognize this problem.

This is an example of the problem with tcpdump running in the background
listening on the destination ip address shown in the netstat output.

# netstat -An | grep 203.232.10.221
Active Internet connections
PCB      Proto Recv-Q Send-Q  Local Address      Foreign Address (state)
94276c00 tcp        0    759  192.86.154.82.80   203.232.10.221.162
FIN_WAIT_1
9418ef00 tcp        0    759  192.86.154.82.80   203.232.10.221.162
FIN_WAIT_1

13:28:03.472384 www-2.us.oracle.com.80 > 203.232.10.221.1626: . 0:1(1) ack 1
win 33232
13:28:12.973072 www-2.us.oracle.com.80 > 203.232.10.221.1623: . 0:1(1) ack 1
win 33232

What is observed here is the destination is clearly dead.  The source is
sending an ACK to the destination looking for his ACK of our FIN.
This is commonly refered to as "persist mode".  A socket in this state will
never timeout and system resources associated with it will not be released.

The new kernel modification to tcp_timer.o can be "tuned" by dbx'ing the
tcp_keepidle parameter on the system.  By default, this is set to 14400
1/2 seconds (2 hours).  It can be easily set to any value appropriate for
the system to "balance" the number of sockets in FIN_WAIT_1 state at any
time.  The system may always have some sockets in FIN_WAIT_1 as well as
CLOSE_WAIT, this is NORMAL.  What you don't want is a large number of sockets
in FIN_WAIT_1 forever.  It is not recommended that tcp_keepidle be set to
less than 5 minutes on the system.

Reference the man page to dbx for guidelines when using the dbx command.


PROBLEM:  (ZUO101015/QAR 49750)          (Patch ID: OSF365-350338)
********
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:        (CA7Q10994)             (Patch ID: OSF365-350342)
********
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 system
connected to a token ring network and the ping uses a message size that
requires fragmentation.  The Digital UNIX 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:        (CLD MCPM3028N)         (Patch ID: OSF365-055)
********
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:        (CLD UVO105250)         (Patch ID: OSF365-057)
********
This patch fixes a problem in which packet filter programs do not receive
packets when the source is sending multicast packets on an Ethernet network.


PROBLEM:        (MGO102810/QAR 49847)   (Patch ID: OSF365-350384)
********
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 multi-threaded, multi-cpu 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.


FILE(s):

/usr/sys/BINARY/if_ether.o 		subset OSFBIN365
CHECKSUM: 53056     89	RCSfile: if_ether.c	RCS: 4.3.42.2
/usr/sys/BINARY/if_ethersubr.o          subset OSFBIN365
CHECKSUM: 08991     17	RCSfile: if_ethersubr.c  RCS: 4.4.94.3
/usr/sys/BINARY/in.o	 		subset OSFBIN350
CHECKSUM: 04636     20	RCSfile: in.c		RCS: 4.3.38.3
/usr/sys/BINARY/in_pcb.o 		subset OSFBIN350
CHECKSUM: 42023     15	RCSfile: in_pcb.c	RCS: 4.3.47.3
/usr/sys/BINARY/ip_input.o 		subset OSFBIN350
CHECKSUM: 40586     23	RCSfile: ip_input.c	RCS: 4.4.49.5
/usr/sys/BINARY/ip_output.o     	subset OSFBIN350
CHECKSUM: 06837     17  RCSfile: ip_output.c 	RCS: 4.4.43.3
/usr/sys/BINARY/lockprim.o              subset OSFBIN350
CHECKSUM: 46072     15  RCSfile: lockprim.s     RCS: 1.1.40.3
/usr/sys/BINARY/tcp_input.o 		subset OSFBIN350
CHECKSUM: 43650     22	RCSfile: tcp_input.c	RCS: 4.3.54.3
/usr/sys/BINARY/tcp_subr.o 		subset OSFBIN350
CHECKSUM: 06552     11	RCSfile: tcp_subr.c	RCS: 4.3.40.3
/usr/sys/BINARY/tcp_timer.o 		subset OSFBIN350
CHECKSUM: 34873      9  RCSfile: tcp_timer.c    RCS: 4.2.15.3
/usr/sys/BINARY/tcp_usrreq.o 		subset OSFBIN350
CHECKSUM: 18216     10	RCSfile: tcp_usrreq.c	RCS: 4.3.25.3
/usr/sys/BINARY/udp_usrreq.o            subset  OSFBIN350
CHECKSUM: 16021     89  RCSfile: udp_usrreq.c   RCS: 4.3.44.4
/usr/sys/BINARY/uipc_socket.o           subset OSFBIN350
CHECKSUM: 08358     26  RCSfile: uipc_socket.c  RCS: 4.3.63.5
/usr/sys/BINARY/uipc_socket2.o          subset	OSFBIN350
CHECKSUM: 53122     15  RCSfile: uipc_socket2.c  RCS: 4.4.37.2
/usr/sys/BINARY/uipc_usrreq.o       	subset OSFBIN350
CHECKSUM: 27079     17  RCSfile: uipc_usrreq.co   RCS: 4.3.44.3
/usr/sys/include/net/proto_uipc.h       subset OSFBINCOM350
CHECKSUM: 65313     10  RCSfile: proto_uipc.h   RCS: 4.2.21.3
/usr/sys/include/sys/socket.h           subset OSFBINCOM350
CHECKSUM: 58113     12	RCSfile: socket.h	RCS: 4.2.24.3
/usr/sys/include/sys/socketvar.h        subset OSFBINCOM350
CHECKSUM: 35066     15  RCSfile: socketvar.h    RCS: 4.2.26.3
/usr/sys/io/common/.mrg..conf.c         subset OSFBINCOM365
CHECKSUM: 60650      2
/usr/sys/io/common/conf.c               subset OSFBINCOM365
CHECKSUM: 47662     47  RCSfile: conf.c         RCS: 1.2.210.2

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

Fixes a problem in which the cron command deletes non-local file system files
mounted in either the /tmp, /var/tmp, or /var/preserve directories.
PROBLEM:        (QAR 46084)     (Patch ID: OSF365-350390)
********
This patch fixes a problem in which the cron command removes
non-local file system files mounted in either
the /tmp, /var/tmp, or /var/preserve directories.


FILE(s):

/usr/var/spool/cron/crontabs/.mrg..root         subset OSFBASE365
CHECKSUM: 25699      5  RCSfile: .mrg..root     RCS: 1.1.15.2
/usr/var/spool/cron/crontabs/.new..root         subset OSFBASE365
CHECKSUM: 51745      2  RCSfile: root           RCS: 4.3.24.2

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

SUPERSEDES PATCHES:	OSF365-350172 (138.00), OSF365-350183 (145.00)

This patch corrects the following:

- Fixes a problem where the lpq command causes the program to crash
  (segmentation fault).

- Print jobs created within a short timeframe, for example within the same
  second, were not sorted by print jobs and timestamps.

- Print jobs cause existing jobs to be deleted from the queue whenever the
  number of print queue entries exceeded 1000.
PROBLEM:        (HPXQ846D7)     (Patch ID: OSF365-350172)
********
This patch corrects a problem were printjobs cause existing jobs to be deleted
from the queue whenever the number of print queue entries exceeded 1000.

Example:
           The cfA005bozo file in /usr/spool/lpxx exists.
           The next print queue tries to create cfA005bozo.
           After error message "Cannot create cfA005bozo" shows up, do
           "ls -l /usr/spoo/lpxx/cfA005bozo".  This file will be
            deleted.


PROBLEM:        (MGO101607)     (Patch ID: OSF365-350183)
********
This patch corrects a problem in which print jobs created within a short
timeframe, for example within the same second, were not sorted by job numbers
and timestamps.  This resulted in print jobs not being printed in the desired
order.

Example: Prior to the fix, examine the followings:

#ls -tr *.lis
users.lis users1.lis users2.ls users3.lis users4.lis users5.lis
        .
# foreach i (`ls -tr *.lis`)
? lpr -Pxxx $i
? end
        .
# ls -lt /var/spool/printer/xxx/cf*
-rw-rw---- 1    root    daemon  132 Jul 11 10:07 cfA005osfmbh.aui.dec.com
-rw-rw---- 1    root    daemon  132 Jul 11 10:07 cfA007osfmbh.aui.dec.com
-rw-rw---- 1    root    daemon  132 Jul 11 10:07 cfA006osfmbh.aui.dec.com
-rw-rw---- 1    root    daemon  132 Jul 11 10:07 cfA004osfmbh.aui.dec.com
-rw-rw---- 1    root    daemon  132 Jul 11 10:07 cfA003osfmbh.aui.dec.com

# lpq -Pxxx
Fri Feb 17 10:46:29 1995:
Rank  Owner        Job  Files             Total Size
1st   bozo 3       137  users.lis         23 bytes
2nd   bozo 4       138  users1.lis        23 bytes
3rd   bozo 6       139  users3.lis        23 bytes
4th   bozo 7       140  users4.lis        23 bytes
5th   bozo 5       141  users2.lis        23 bytes
6th   bozo 8       142  users5.lis        23 bytes

As you can see, the file users2.lis has Job number 5 which is the 3rd Job but
gets ranked in the 5th position and will not be printed in the desired order
after the file user1.lis despite of the fact that all files were created with
the same timestamp (eg. Jul 11 10:07).  Example: the order should be the
following after the fix

# lpq -Pxxx
Fri Feb 17 10:46:29 1995:
Rank  Pri  Owner        Job Files            Total Size
1st   0    bozo 3       users.lis               23
2nd   0    bozo 4       users1.lis              23
3rd   0    bozo 5       users2.lis              23
4th   0    bozo 6       users3.lis              23
5th   0    bozo 7       users4.lis              23
6th   0    bozo 8       users5.lis              23


PROBLEM:        (QAR 52528)     (Patch ID: OSF365-350392)
********
This patch fixes a problem where the lpq command causes the program to crash
(segmentation fault).

The problem is caused by lpq running until a print queue buffer
in memory is overwritten.

The following is an example of a core dump:

dove.zk3.dec.com: Thu May 19 18:11:54 1994:
 ps29 is ready and printing via network
 Rank   Owner      Job  Files                                 Total Size
 active achan       27   ...                                  789505 bytes
 1st    achan       28   ...                                  790831 bytes
 2nd    achan       29   ...                                  696441 bytes
 3rd    achan       30   ...                                  509919 bytes
 Unaligned access pid=2581  va=6f70732f7261762f pc=3ff80129608
 ra=3ff80129194 type=ldq
 Segmentation fault


FILE(s):

/usr/bin/lpq   		subset OSFPRINT350
CHECKSUM: 36259     48	RCSfile: lpq.c   RCS: 4.2.5.2
/usr/bin/lpr   		subset OSFPRINT350
CHECKSUM: 60620     48	RCSfile: lpr.c   RCS: 4.2.33.2
/usr/bin/lprm  		subset OSFPRINT350
CHECKSUM: 41574     40	RCSfile: lprm.c  RCS: 4.2.6.2
/usr/lbin/lpd  		subset OSFPRINT350
CHECKSUM: 34532     96	RCSfile: lpd.c   RCS: 4.2.17.2

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

The audit_tool command hangs if the audit log contains pathnames
that encounter boundary conditions.
PROBLEM:        (CLD HPAQ61BKA, CLD MCPM20F8X)  (Patch ID: OSF365-350413)
********
This patch fixes a problem in which the audit_tool command will hang
if the audit log contains pathnames that encounter boundary conditions.

An example of a boundary condition that causes the problem is a component
of the pathname ending on a 1024-byte boundary.


FILE(s):

/usr/sbin/audit_tool            subset OSFBASE350
CHECKSUM: 19749    128  RCSfile: audit_tool.c  RCS: 1.1.35.2

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

SUPERSEDES PATCHES:	OSF365-350159 (132.00), OSF365-350201 (160.00),
			OSF365-350205 (163.00), OSF365-350389 (341.00),
                        OSF365-350391 (320.00)

This patch corrects the following:

- Fixes a problem in which the vrestore command is unable
  to read data from a raw disk partition.

- Fixes a problem where the vrestore program does not report
  failed exit status appropriately on incomplete or incorrect commands,
  corrupt or invalid saved sets, or file open failures.

- Fixes a problem in which the vrestore command fails when running
  multiple iterations of the command in a script or from the command line.

- Fix incorrect vdump file count message that shows up when vdump backs up
  a filesystem containing sockets.

- User will receive the following error message if they attempt to restore a
  V4.0 dump on an older version of the OS:

        vrestore: Need vrestore V4.0 to restore contents; terminating
PROBLEM:        (QAR 44852)     (Patch ID: OSF365-350159)
********
Fix to allow you to restore a V4.0 dump on an older release.

User will recieve the following error message if they attempt
to restore a V4.0 dump on an older version of the OS:

  vrestore: Need vrestore V4.0 to restore contents; terminating


PROBLEM:	(QAR 28861)	(Patch ID: OSF365-350205)
********
After vdump completes, it may report that it backed up > 100% of the files.

 vdump: Dumped  927 of 924 files; 100.3% completed

as root, try:

# vdump -0 -f - /dev > /dev/null


PROBLEM:        (QAR 39035/53017)	(Patch ID: OSF365-350201/OSF365-350389)
********
Fix the problem of running multiple vrestores where the program might
exit prematurely.

This patch fixes a problem in which the vrestore command fails when running
multiple iterations of the command in a script or from the command line.

To reproduce this problem, create a shell script similar to the
following called vrestore.sh:

 vrestore tf vdump_file.1 &
 vrestore tf vdump_file.2 &
 vrestore tf vdump_file.3 &

Run the shell script. The system will display error messages
similar to the following:

vrestore: Date of the vdump save-set: Tue Apr 16 13:49:20 1996
vrestore: Date of the vdump save-set: Tue Apr 16 13:49:30 1996
vrestore: Date of the vdump save-set: Tue Apr 16 13:49:35 1996
logical_dir_creat() -- unimplemented
vrestore: can't create restore dir ; [17] File exists
vrestore: dir_write() error; [9] Bad file number; terminating


PROBLEM:        (UVO105368)     (Patch ID: OSF365-350391)
********
This patch fixes a problem where the vrestore program does not report
failed exit status appropriately on incomplete or incorrect commands,
corrupt or invalid saved sets, or file open failures.


PROBLEM:        (QAR 47535)     (Patch ID: OSF365-350395)
********
This patch fixes a problem in which the vrestore command is unable
to read data from a raw disk partition.

# vdump -0 -D -f /dev/rz5c -x32 /scratch
path     : /scratch
dev/fset : /dev/rz1a
type     : ufs
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: Dumping 4101 bytes, 1 directories, 1 files
vdump: Dumping regular files

vdump: Status at Tue Jun 10 07:08:33 1997
vdump: Dumped  4101 of 4101 bytes; 100.0% completed
vdump: Dumped  1 of 1 directories; 100.0% completed
vdump: Dumped  1 of 1 files; 100.0% completed
vdump: Dump completed at Tue Jun 10 07:08:33 1997

# vrestore -x -f /dev/rz5c -D /recover junk
vrestore: raw disk
vrestore: Unsupported device category 1


FILE(s):

/sbin/vdump 		subset OSFADVFS350
CHECKSUM: 13301    632	RCSfile: vdump.c	RCS: 1.1.26.2
/sbin/vrestore          subset OSFADVFS350
CHECKSUM: 60174    640	RCSfile: vrestore.c	RCS: 1.1.26.4   
                        RCSfile: dirmgt.c	RCS: 1.1.13.2

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

Adds a mechanism to the poll() system call to allow it to be used as a timer.
PROBLEM:        (TKTRA1784, QAR 49164)  (Patch ID: OSF365-350397)
********
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.


FILE(s):

/usr/sys/BINARY/sys_generic.o           subset OSFBIN350
CHECKSUM: 28225     17  RCSfile: sys_generic.c  RCS: 4.4.64.2

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

SUPERSEDES PATCHES:	OSF365-007 (7.00), OSF365-034 (34.00),
			OSF365-053 (299.00)

This patch corrects the following:

- Fix greatly reduces the number of "NFS stale file handle" messages
  logged to an NFS server system console.

- Allows ome third-party NFS v2 clients to experience a performance improvement.
  Candidate applications are ones that perform read/write operations
  to a memory mapped file over NFS.

- A problem in which nfsportmon does not allow the root directory to be mounted
  from either a Solaris system or from an ULTRIX Version 4.2A system.

- Fixes a problem where SUN NFS clients cannot write to files based on group 
  membership.  With this patch, a user who has group write permission on a file
  will be able to write to the file even when the directory containing the file
  does not have group write permission.
PROBLEM:	(UTO100843)		(Patch ID: OSF365-007)
********
NFS clients, specifically SUN NFS clients can't write files based on group
membership. Digital UNIX clients don't have this problem.

Given the following conditions:

 - A directory contained in an NFS file system with a protection code of 755.

 - A file contained in the directory with a protection code of 664.

 - The directory and the file have the same group ownership.

This corrects this problem so that users or programs with the same group code 
will have permission to modify the contents of the file.


PROBLEM:	(HPAQC854C, QAR 46335)	(Patch ID: OSF365-034)
********
This patch fixes a problem in which the nfsportmon command does not
allow the root directory to be mounted from either a Solaris system
or from an ULTRIX Version 4.2A system.

There is a program making it's way around the internet that allows
non-priviledged users to mount filesystems, even if the nfs server is
configured to only allow root users to mount (NONROOTMOUNTS=0 in
/etc/rc.config).  In order to protect against this, customers are using
nfsportmon to enhance the check mechanism.  nfsportmon checks to make sure
that file access requests were generated by the client kernel rather than a
forged application.

However, with nfsportmon turned on, Sun Solaris clients cannot mount
anything, even as root.

For example, if you have a Digital UNIX v3.2c nfs server, and
NONROOTMOUNTS=0 and nfsportmon is on, the root user on another Digital UNIX
system can mount exported directories fine, but the root user on a Solaris
system cannot.  The root user on a Solaris system gets the following error:

# mount sandpiper:/mnt /staff/ajs/mnt
nfs mount: sandpiper: NFS service not responding
nfs mount: retrying: /staff/ajs/mnt

With nfsportmon turned off, the directory mounts fine from Solaris.

In addition to Solaris clients failing, ULTRIX v4.2a clients also fail with
the same error.


PROBLEM:        (CLD HPXQ9722E)         (Patch ID: OSF365-053)
********
This patch allows some third-party NFS v2 clients to experience a
performance improvement.  Candidate applications are ones that
perform read/write operations to a memory mapped file over NFS.

NOTES:

1) This patch must be enabled _BEFORE_ NFS is started because it needs
   to perform some configuration operations before client requests start
   arriving.  This why the dbx patch is to the /vmunix file and not to memory.
   If the patch is applied to memory, it will be ignored, since the
   initialization routine only runs when NFS is started.

2) Affects NFS V2 only.  NFS v3 connections are unaffected.

3) Files that are only read or only written will not be affected.

4) The NFS Dup cache and NFS Write Gathering are disabled by this patch.

 To enable the patch, perform the following steps:

     % dbx -k /vmunix
     (dbx) patch stall_write_patch_enabled=1
     (dbx) quit
     % reboot


PROBLEM:        (CLD FNO100139) (Patch ID: OSF365-063)
********
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.


FILE(s):

/usr/sys/BINARY/nfs3_server.o           subset OSFBIN365
CHECKSUM: 40475    169	RCSfile: nfs3_server.c	RCS: 1.1.75.2
/usr/sys/BINARY/nfs_server.o            subset OSFBIN365
CHECKSUM: 16683    178	RCSfile: nfs_server.c	RCS: 1.1.118.6
/usr/sys/BINARY/vfs_syscalls.o          subset OSFBIN350
CHECKSUM: 21680     45	RCSfile: vfs_syscalls.c	RCS: 4.3.19

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

SUPERSEDES PATCHES:	OSF365-350303 (221.00),  OSF365-350333 (238.00)

This patch corrects the following:

- Fixes a problem with the tar "tv" command in reporting ownership on a file
  that had no legitimate owner at the time it was archived.  Based on the
  position of the file in the archive, tar returned the owner of a previous
  file, or the values -973 for userid and -993 for groupid.

- Fixes pax's tar and cpio archive handling to allow filesizes greater than 4GB.

- The tar(pax) command doesn't correctly handle sparse files, especially Oracle 
  database files. Pre-allocated space is not replaced on restore.
PROBLEM:        (MGO101962 QAR 43077)	(Patch ID: OSF365-350303)
********
If a database file has been created with pre-allocated but unused disk space,
the copy operation of tar does not preserve this pre-allocated space and the
restore (tar xv) operation will therefore create a file that is of the size of
the actual used blocks.


PROBLEM:        (MANBBP075 HPXQC1120)   (Patch ID: OSF365-350333)
********
The pax program (invoked as pax, tar or cpio) would incorrectly handle
files larger than 4GB in size.  The program would not complain on creation
of an archive, however it had truncated the filesize when writing it to
the archive file header. Thus on extract, it would appear to have found
a corrupt archive.  In addition it will now warn when it truncates a file
that is too large to be archived (8 GB).


PROBLEM:        (SQO100400)     (Patch ID: OSF365-350400)
********
This patch fixes a problem with the tar "tv" command in reporting ownership
on a file that had no legitimate owner at the time it was archived.
Based on the position of the file in the archive, tar returned the owner
of a previous file, or the values -973 for userid and -993 for groupid.


FILE(s):

/sbin/cpio                      subset OSFBASE365
CHECKSUM: 20086    408
/sbin/pax                       subset OSFBASE365
CHECKSUM: 20086    408  RCSfile: pax.c   RCS: 1.1.22.2
/sbin/tar                       subset OSFBASE365
CHECKSUM: 20086    408
/usr/bin/cpio                   subset OSFBASE365
CHECKSUM: 11548    120
/usr/bin/pax                    subset OSFBASE365
CHECKSUM: 11548    120  RCSfile: pax.c   RCS: 1.1.22.2
/usr/bin/tar                    subset OSFBASE365
CHECKSUM: 11548    120

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


SUPERSEDES PATCHES:	OSF365-350056-1 (94.01)

This patch corrects the following:

- awk consumes memory until the machine swaps itself and core dumps with:
   write failed, file system is full  Memory fault - core dumped

- awk (nawk) doesn't always clear the previous value of the last field.
PROBLEM:	(HPAQ282B7)		(Patch ID: OSF365-350056-1)
********
The awk utility will sometimes produce output that indicates that field values
are not being cleared between record reads.  Specifically, the value
of the last field in a record gets left in when a new record is read in
which has a null last field.

To reproduce the problem, put the following lines into a file called,
"awktest.dat".
A~~~XYZ
~~~
x~x~x~X
1~~~
~~~

Then run the following command: awk -F~ '{print $4}' test.dat

The output should be:
XYZ

X


The output will be:
XYZ
XYZ
X
X
X


PROBLEM:        (QAR 30334)     (Patch ID: OSF365-350418)
********
This patch fixes problem in which 'awk' will consume memory until
the machine swaps itself and core dumps with following error:

 write failed, file system is full
 Memory fault - core dumped


FILE(s):

/usr/bin/awk                            subset OSFBASE350
CHECKSUM: 55052    152  RCSfile: lib.c	RCS: 1.1.15.2
/usr/bin/nawk				subset OSFBASE350
CHECKSUM: 55052    152  RCSfile: lib.c  RCS: 1.1.15.2

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

SUPERSEDES PATCHES:	OSF365-350363 (286.00)

This patch corrects the following:

- Fixes a problem in which a system with an HSZ70 controller with
  a Q-Logic adapter or a KZPSA adapter may experience kernel memory faults
  during a failover and display a message similar to the following:

     panic (cpu 8): kernel memory fault
     cam_logger: CAM_ERROR entry too large to log!

- A custom SCSI driver may return the error ENOMEM from its
  ccmn_open_unit() routine.
PROBLEM:        (HPXQ10U29)     (Patch ID: OSF365-350363)
********
A custom SCSI driver may encounter the unexpected error ENOMEM returned
from the ccmn_open_unit() function in the driver's slave() routine.


PROBLEM:        (QAR 49907 QAR 48597)   (Patch ID: OSF365-350407)
********
This patch fixes a problem in which a system with an HSZ70 controller
with a Q-Logic adapter or a KZPSA adapter may experience kernel
memory faults during a failover.

A message similar to the following is displayed:

  panic (cpu 8): kernel memory fault
  cam_logger: CAM_ERROR entry too large to log!


FILE(s):

/usr/sys/BINARY/pdrv_common.o           subset OSFHWBIN365
CHECKSUM: 07180    176  RCSfile: pdrv_common.c  RCS: 1.1.93.4

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

Fixes a problem that causes an AdvFS file system encapsulated under LSM
to appear as a user type of "gen", rather than the correct type, "fsgen".
PROBLEM:        (QAR 53471, QAR 31350)  (Patch ID: OSF365-350410)
********
This patch fixes a problem that causes an AdvFS file system encapsulated
under LSM to appear as a user type of "gen", rather than the correct type,
"fsgen". The command voladvdomencap was patched to run volassist with a flag
-U fsgen, rather than -U gen.


FILE(s):

/usr/sbin/voladvdomencap                subset OSFLSMBASE350
CHECKSUM: 37900      5  RCSfile: voladvdomencap.sh  RCS: 1.1.11.2

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

SUPERSEDES PATCHES: 	OSF365-350150 (246.00),  OSF365-350209 (250.00)

This patch corrects the following:

- Fixes a wide variety of system panics and other problems caused
  by random memory corruption.  Problem noticed at sites hosting
  a lot of streams activity.

- Pause or stall conditions of up to 30 seconds when an application calls the 
  ldtty_close function in a STREAMS based implementation.  After the pause or 
  stall, the application resumes normal behavior with no other apparent side 
  affects.

- Successive reads wait for VTIME to expire regardless of VMIN setting assigned
  by ioctl.
PROBLEM:        (HPXQ968A7)     (Patch ID: OSF365-350150)
********
Successive reads wait for VTIME to expire regardless of VMIN setting


PROBLEM:        (HPXQ514E3, QAR 46310)  (Patch ID: OSF365-350209)
********
This patch fixes pause or stall conditions of up to 30 seconds when an
application calls the ldtty_close function in a STREAMS based implementation.
After the pause or stall, the application resumes normal behavior with no
other apparent side affects.

This problem typically shows when an application outputs to a streams based
device.  For example, an application "prints" data to a printer on a terminal
server using LAT protocol.  The application may expect an immediate return
but instead, experiences a pause or stall for up to 30 seconds.

Obtaining a stack trace when the stall or pause condition is occuring will show
the following footprint:

        0 thread_block()
        1 mpsleep
        2 streams_mpsleep
        3 ldtty_close
        4 close_wrapper
        5 csq_protect
        .....
        .....

After the 30 seconds expires, the application returns to normal behavior with
no other side affects noticed.  The stall condition in this example happened
with files in the size range of 4097 - 4960 bytes being queued to a printer
on a terminal server.  The size of the files by coincidence, hit the 30 sec
sleep timer just at the right time in order to uncover the bug.


PROBLEM:  (HPAQ41AAX STLQ23067 UVO105389 HPAQ116QT HPAQ50RP5 HPAQ400K4
********        ZPOBA0391 ZPOB60233)    (Patch ID: OSF365-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

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.


FILE(s):

/usr/sys/BINARY/ldtty.o         subset OSFBIN350
CHECKSUM: 10506     95  RCSfile ldtty.c  RCS: 1.1.42.4

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

Fixes a problem that occurs on SMP systems using LSM in which
the system panics with a "simple lock time limit exceeded" message.
PROBLEM:        (QAR 53134, MCPM40H5M)  (Patch ID: OSF365-360109)
********
This patch fixes a problem that occurs on SMP systems using LSM in which
the system panics with a "simple lock time limit exceeded" message.

The problem is that the running process goes to sleep waiting for an
LSM simple lock that never becomes available.

A sample stack trace is as follows:
>  0 stop_secondary_cpu(do_lwc = 0x0)
   1 panic(s = 0xfffffc00005a1568 = "event_timeout: panic request")
   2 event_timeout ()
   3 xcpu_puts()
   4 printf()
   5 panic(s = 0xfffffc0000572ea8 = "simple_lock: time limit exceeded")
  6 simple_lock_fault()
   7 simple_lock_time_violation()
   8 voliodone()
   9 biodone()
  10 cdisk_complete()
  11 xpt_callback_thread()

The thread holding the lock:
>  0 thread_block()
   1 u_anon_faultpage()
   2 u_anon_fault()
   3 u_map_fault()
   4 vm_fault()
   5 trap()
   6 _XentMM()
   7 bcopy()
   8 vols_volinfo()
   9 volsioctl_real()
  10 spec_ioctl()
  11 vn_ioctl()
  12 ioctl_base()
  13 ioctl()
  14 syscall()
  15 _Xsyscall()


FILE(s):

/usr/sys/BINARY/volspec.o               subset OSFLSMBIN365
CHECKSUM: 60008     59	RCSfile: volspec.c	RCS: 1.1.39.2

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

SUPERSEDES PATCHES:	OSF365-028 (28.00),  OSF365-038 (38.00)

This patch corrects the following:

- Fixes a problem where an AlphaServer 2100A system is shut down, 
  using the "shutdown -r" command, the system will not reboot.
 
- An AlphaServer 2100 or 2100A system with more than 1GB of memory 
  will not boot when the dma window size is set in the sysconfigtab file. 

  Typically the dma window size is set in the sysconfigtab file 
  when Memory Channel is being used.

- 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.
PROBLEM:	(QAR 43423)	(Patch ID: OSF365-028)
********
This patch fixes a problem in which an AlphaServer 2100 or 2100A system
with more than 1GB of memory will not boot when the dma window size
is set in the sysconfigtab file. Typically the dma window size is set in
the sysconfigtab file when Memory Channel is being used.

PROBLEM:	(EMZB83716, QAR 48019)	(Patch ID: OSF365-038)
********
The Unix kernel crashes during installation if the memory in the system
exceeds 1GB.  This has only been seen on Lynx-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: OSF365-066)
********
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 OSFHWBIN365
CHECKSUM: 48953     52  RCSfile: cbus2_pci.c    RCS: 1.1.39.3
/usr/sys/include/arch/alpha/hal/cbus2_pci.h     subset OSFHWBINCOM365
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: OSF365-067)
********
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 OSFHWBIN350
CHECKSUM: 38744     17  RCSfile: apecs.c        RCS: 1.1.49.2
/usr/sys/BINARY/lca.o           subset OSFHWBIN365
CHECKSUM: 12467     21  RCSfile: lca.c          RCS: 1.1.53.2

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

Fixes several I/O problems in the kernel that occur on
AlphaStation 500 and AlphaStation 600 systems. The problem 
causes these systems to hang or run with reduced performance.
PROBLEM:        (QAR 47627)     (Patch ID: OSF365-074)
********
This patch fixes several I/O problems in the kernel that occur on
AlphaStation 500 and AlphaStation 600 systems. The problem causes
these systems to hang or run with reduced performance.

This patch increases performance through data type alignment, provides
bus space to bus space data copy changes to eliminate data corruption,
and translates an I/O handle to a valid CPU address to prevent system hangs.


FILE(s):

/usr/sys/BINARY/dc21171.o               subset OSFHWBIN365
CHECKSUM: 21168     20  RCSfile: dc21171.c      RCS: 1.1.48.2

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

SUPERSEDES PATCHES:	OSF365-360010 (50.00),   OSF365-360011 (51.00),
                        OSF365-360012 (52.00),   OSF365-360014 (54.00),
                        OSF365-360015 (55.00),   OSF365-360020 (58.00),
                        OSF365-360023 (59.00),   OSF365-017 (17.00),
                        OSF365-360029 (64.00),   OSF365-019 (19.00),
                        OSF365-020-1 (20.01),    OSF365-360039 (69.00),
                        OSF365-360044 (72.00),   OSF365-029-1 (29.01),
                        OSF365-360046 (73.00),   OSF365-360055 (80.00),
                        OSF365-360056 (81.00),   OSF365-360057 (82.00),
                        OSF365-035-1 (35.01),    OSF365-350082 (262.00),
                        OSF365-360068 (88.00),   OSF365-360070-1 (89.01),
                        OSF365-360070-2 (89.02), OSF365-360076-1 (92.01),
                        OSF365-009 (9.00),       OSF365-350098 (106.00),
                        OSF365-350113 (113.00),  OSF365-010 (10.00),
                        OSF365-013 (13.00),      OSF365-015 (15.00),
                        OSF365-350184 (146.00),  OSF365-037 (37.00),
                        OSF365-360085 (287.00),  OSF365-050 (288.00),
                        OSF365-050-1 (288.01),   OSF365-360087 (289.00),
                        OSF365-054 (304.00),     OSF365-350372 (301.00),
                        OSF365-360093 (303.00),  OSF365-360101 (314.00),
			OSF365-350438 (339.00),  OSF365-036 (36.00),
                        OSF365-031 (31.00),      OSF365-043 (43.00),
                        OSF365-350309 (226.00),  OSF365-005 (5.00),
                        OSF365-027 (27.00),      OSF365-051 (291.00),
                        OSF365-350182 (144.00),  OSF365-052 (292.00),
                        OSF365-350405 (328.00),  OSF365-068 (337.00),
                        OSF365-350435 (352.00),  OSF365-350438-1 (339.01),
                        OSF365-073 (344.00),     OSF365-350448 (356.00),
                        OSF365-070 (342.00),     OSF365-071 (343.00)

This patch corrects the following:

- Fixes a system crash when setting the date on SMP systems.

- Fixes a system panic with the following panic string:

    "event_timeout: panic request"

- Fixes an I/O queue corruption problem that occurs during
   normal shut down of SMP systems with AdvFS.

- 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 error message:   kernel memory fault

- Provides general support for Version A11 KZPSA firmware.

- 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.

- 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.

- Fixes panics that may occur on SMP systems. The following error message 
  is displayed on the system:

     "simple_lock: time limit exceeded"

- Non-retryable errors from an HSZ40 are not being logged in 
  the system error log file.

- Provides the following additional event logging by the SCSI/CAM disk driver:
   Additional Unit Attention messages, additional details for hard errors
   logged after unsuccessful I/O recovery attempts, and provides informational
   messages on the progress of recovery events.

- Fixes various system problems:
   o System panic with: "xpt_callback: callback on freed CCB"
   o System panic with kernel memory fault while trying to remove
     an spo resource queue entry
   o Logging following group of 3 errors every few minutes:
     spo_verify_adap_sanity, spo_misc_errors, spo_bus_reset
     when the system was under heavy load.
   o system then panicked with "simple_lock: time limit exceeded"
     after FS quiesced the bus on the HSZ40, powered off and disconnect
     tape drive for maintenance.
   o Infrequently, under heavy disk I/O loads, user data can be written to
     the wrong disk, resulting in data corruption.

- A data corruption error which can occur on KZTSA SCSI adapters. This can 
  result in data corruption on any tape drive connected to the KZTSA when large 
  block (1 Meg or greater) transfers are performed.  This data corruption has 
  only been reported on odd block transfers.

- Fixes a problem where a system panics with the following error message:
  	"simple lock: time limit exceeded".
  This situation may occur during the creation of an Oracle database. 

- When HSZ50 hardware is installed, the system exhibits very slow performance.

- Probe of isp fails intermittently during boot.

- A number of problems have been fixed in the ISP driver. These include: 
  "minimum spl violation" panics with lockmode=4, simple lock time limit
  exceeded panics, "CAM_ERROR entry too large" messages, and "Unable to 
  restart Qlogic(LUN queue after abort)" panics.
  
- A system can hang in "ss_process_timeouts", after binary.errlog entries:

   	 sim_err_sm    Target went to command phase
   	 sim94_intr    Illegal command

  panic: "xpt_callback: callback on freed CCB"

- Eliminates panics that will occur when attempting to execute
  shell scripts on a filesystem mounted with the "noexec" option.

- Fixes the corruption of core files produced by applications
  with 15 or more threads.

- Fixes two system panics - no special situation that will cause these panics;
    o Fixes a panic that prints "kernel memory fault".
    o Fixes a panic that prints "pmap_dup: level3 PTE not valid".
    o Fixes a panic that prints "delete_pv_entry: mapping not in pv_list".

- Fixes a problem with the exec() system function where 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.

- Fixes a problem that occurs on AlphaServer 8200 and 8400 systems
  when a processor fails to restart after a user halts the system
  by entering "Control-P Control-P" and then typing "continue" on the console.

- 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.

- Ladebug sessions may hang when debugging multithreaded applications.

- Fixes system crash when setting the date for SMP systems.

- Fixes a problem in which processes can hang waiting for a system call to
  table() to complete.

- The system panics with "ipc_thread_init: reply port allocate" after an
  unsuccessful port allocation request.

- Fixes the following:
  o AlphaServer 8200 systems do not correctly log 660 machine check errors. 
  o AlphaServer 8200 systems do not provide enough information in 
    the error log files to correctly diagnose 660 machine check errors.
  o On SMP machines, correctable processor error logging is inadvertently 
    disabled at system boot up time.

- In some situations the SWXCR controller may hang and I/Os won't complete.

- Kernel panics with "zombie walks again" message.

- Fixes System panic with "xcr_que_insert list corruption"

- 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.

- Enables the latest Informix KAIO functionality. The patch should be installed 
  by Informix customers using the Informix 7.20.UC4 release.  The Informix 
  defect number 40041 regarding KAIO is fully addressed by this patch.

- Fixes some hangs that can occur during the "syncing disks..." portion of 
  panic processing, improves the reliability of getting a dump after a system 
  panic, and also makes it more likely that AdvFS buffers will be synced to 
  disk after a system panic.

- A system can crash with: panic: "pmap_remove_range: page wired"
  if certain kernel functions try to malloc more memory pages than allowed
  by the vm configuration parameter vm-vpagemax, which by default is set
  to 16384.

- Fixes Ladebug process hangs when debugging user code.

- A system will crash with " u_shm_oop_deallocate: reference count mismatch."

- Multi-processor systems using the AdvFS file system, particularly systems
  also using AdvFS for the root and usr file systems, may experience 
  intermittent freezing of interactive processes when the system has a
  moderate to heavy I/O load. The freezing of interactive processes may last 
  from a few seconds to many minutes but will eventually return to normal. 
  This problem may also occur on multi-processor systems using the NFS client
  or graphics sub-systems.

- 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.

- If a user binds a process to a processor and then halts that processor, 
  the system may panic with a "simple lock owned" panic.

- Fixes problems in tlb shootdown code:
  o Tlbshootdown requests could panic with timeouts because the
    other processor(s) do not respond to the interrupt.
  o The system may display invalid "tlb invalidate" messages.
  o There could be some memory data corruption or a memory fault.
  o Other processors in a cluster could have touched memory while
    it was being reset.
  o system panics with the error message:   "tlb_shoot ack timeout".

- Fix to allow clock to advance properly (wrap to next year) at end of year
  when system is powered down and to prevent clock from losing a day on each
  reboot during March of a leap year.

- The system may experience a data corruption problem.  This has been noted
  as causing a data corruption in the oracle system table, but the corruption
  need not be limited to oracle and could show up anywhere.

- When executing with OSF PALcode revision 1.45, or greater, 
  some floating point instructions fail.

- A problem where a system may experience a panic with the panic string
  "pmap_remove_lev2: lev3 pte not valid", or the system may experience 
  a data corruption problem.

- Fix "panic: `lock_write: interrupt level call`" in process group processing.

- Fix memory and process state output from /proc PIOCPSINFO ioctl and SVE ps
  command.

- Fixes "panic (cpu 0): kernel memory fault" from procfs_readdir()/uiomove()
  or procfs_lookup().

- Fortran programs using automatic arrays, C programs using alloca() functions,
  and other programs that allocate memory from the user's stack space, can
  experience segmentation violation errors.

- System crashes with "kernel memory fault" when accessing proc file system.

- User programs can end with a segmentation violation error when trying to
  allocate memory that grows in a downward direction.

- This patch fixes the panic "thread_depress_wait" on multi-processor machines
  running multi-threaded applications.
                                       
- Corrects an SMP/realtime-preemption race condition in the signal code that 
  can allow a process stopped in sigsuspend to miss a signal wakeup and
  remaining block indefinitely.

- Fixes a kernel crash that occurs when an asychronous I/O (aio) application
  calls the aio_suspend() function specifying the same aio control block
  multiple times.
PROBLEM:        (QAR 42141) 		(Patch ID: OSF365-360010)
********
An aio application that calls aio_suspend() with a list of control
blocks containing a duplicate address can  crash  the system if the
duplicate aio request has not completed at the time of the call.
The stack trace of the crashing thread will have at least the
following frames:

        0 panic()
        1 trap()
        2 _XentMM()
        3 aio_remove_tests()
        4 aio_wait()
        5 syscall()
        6 _Xsyscall()


PROBLEM:       			 	(Patch ID: OSF365-360011)
********
A scan of an SMP/realtime system's processes with the ps command
locates a process that is stopped with a "pause" WCHAN with an
unblocked signal pending.  This process is blocked in the sigsuspend
syscall and has missed being awakened by the pending signal. The ps
output for this process might look like this:

# ps -O sig,sigmask,sigcatch,wchan -p 1500
  PID    PENDING    BLOCKED    CAUGHT    WCHAN
 1500          1          0         1    pause

This output shows that process 1500 is blocked in sigsuspend() trying
to catch signal 1 (SIGHUP). The signal is unblocked *and* pending.
This is an incorrect state when it persists indefinitely. Sending this
process a SIGHUP signal from a terminal will clear the blocked state
temporarily, but the problem is likely to recur 


PROBLEM:	(QAR 40991)		(Patch ID: OSF365-360012)
********
This patch fixes the panic "thread_depress_wait" on multi-processor machines
running multi-threaded applications.


PROBLEM:	(TKTRA1614)		(Patch ID: OSF365-360014)
********
The system can panic when system is running a number of processes
which is greater than half the value of npid.  The panic string
is:  "kernel memory fault."

A typical stack trace is:

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1620, ...] 
   1 panic() ["../../../../src/kernel/bsd/subr_prf.c":752, ...]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281, ...]
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1296, ...]
   4 insmntque() ["../../../../src/kernel/vfs/vfs_subr.c":1897, ...]
   5 exec_procfs_trace() ["../../../../src/kernel/bsd/kern_exec.c":1183, ...]
   6 common_exec() ["../..  /../../src/kernel/bsd/kern_exec.c":434, ...]
   7 execve() ["../../../../src/kernel/bsd/kern_exec.c":263, ...]
   8 syscall() ["../../../../src/kernel/arch/ alpha/syscall_trap.c":565, ...]
   9 _Xsyscall() ["..  /../../../src/kernel/arch/alpha/locore.s":1086, ...]


PROBLEM:	(MCPMB3AE6)		(Patch ID: OSF365-360015)
********
This problem results in a kernel memory fault generating a message such as:

	trap: invalid memory read access from kernel mode
	
	    faulting virtual address:     0xffffffff80914000
	    pc of faulting instruction:   0xfffffc00004e6cbc
	    ra contents at time of fault: 0xfffffc0000444aac
	    sp contents at time of fault: 0xffffffffa95d70d0
	
	panic (cpu 0): kernel memory fault

where the pc is in uiomove(), and the faulting virtual address would be
the beginning of an unmapped page.  Because of the incorrect source
address calculation, uimove() will typically go well beyond the internal
buffer into unmapped territory.

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1717]
   1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":757]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1215]
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
   4 bcopy() ["../../../../src/kernel/arch/alpha/fastcopy.s":169]
   5 uiomove() ["../../../../src/kernel/bsd/kern_subr.c":96]
   6 procfs_readdir() ["../../../../src/kernel/procfs/procfs_vnops.c":2417]
   7 mvop_osf1axp_readdir() ["../mfs_mdep_osf1axp.c":2280]
   8 mfs_readdir() ["../mfs_vnodeops.c":4422]
   9 mvfs_osf1axp_readdir() ["../mfs_mdep_osf1axp.c":1021]
  10 getdirentries() ["../../../../src/kernel/vfs/vfs_syscalls.c":3170]
  11 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
  12 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]


PROBLEM:	(QAR 40131)		(Patch ID: OSF365-360020)
********
User programs can end with a segmentation violation error when trying to
allocate memory that grows in a downward direction.  This problem has been
seen with fortran programs that use automatic arrays, and with C programs
that use the alloca() function.


PROBLEM:	(QAR 42447)		(Patch ID: OSF365-360023)
********
The /proc PIOCPSINFO ioctl returns incorrect data for the pr_state,
pr_size, and pr_rssize fields of struct prpsinfo. The state field
may show the process running (R) when it is in fact sleeping (S).
The rss field will consistently show 0; and the size field will
usually significantly underreport the virtual address size of
the process. These symptoms may be observed directly through the
use of the PSINFO ioctl, or indirectly through the use of the
ps command from the System V Environment (SVE) layered product.
The problem can also cause the SVE gcore command to fail.


PROBLEM:	(MCPM359CA)		 (Patch ID: OSF365-017)
********
The system panics while performing a process group operation with the
following characteristics:

        panic: `lock_write: interrupt level call`

                pc of caller:         0xfffffc00003eb1e0
                lock address:         0xfffffc00005b2770
                lock info addr:       0xfffffc0000660180
                lock class name:      pgrphash_lock
                current spl level:    1
                required spl level:   0

A typical stack traces would look like this

        1 panic
        2 event_timeout
        3 xcpu_puts
        4 printf
        5 panic
        6 lock_fault (error = "lock_write: interrupt level call")
        7 lock_write
        8 pgrp_unref
        9 psignal_lwc
        10 lwc_schedule
        .
        .
        .

or this

        1 panic
        2 event_timeout
        3 simple_lock_miss
        4 lock_read
        5 pgfind
        .
        .
        .


PROBLEM:	(MCPM45EDF)	(Patch ID: OSF365-360029)
********
The system may panic with the panic string 

  "pmap_remove_lev2: lev3 pte not valid ".

The stack trace for this panic is as follows:
        1 panic("pmap_remove_lev2: lev3 pte not valid")
        2 pmap_remove_lev2()
        3 unmap_gh()
        4 u_anon_unmap()
        5 u_shm_unmap()
        6 u_map_delete()
        7 shmdt()
        8 syscall()
        9 _Xsyscall()


PROBLEM:        (MCPM45EDF)     (Patch ID: OSF365-360029)
********
The system may experience a data corruption problem.  There are no specific
stack traces associated with this problem.  We have seen this problem
causing a data corruption in the oracle system table.  But, the corruption
need not be limited to oracle and could show up anywhere.


PROBLEM:	(QAR 40124)	(Patch ID: OSF365-019)
********
When executing with OSF PALcode revision 1.45, or greater, with Digital UNIX
V3.2, V3.2B, V3.2C, V3.2D-1, V3.2E-1, V3.2D-2, or V3.2E-2 some floating
point instructions fail.

Some floating point instructions fail and cause the message on the console:

	"unknown OPDEC from ieee emulation"

There may also be user output instruction fault messages such as:

       "inst fault=4, status word=               8, pc=     3ff80128e50"
       "Illegal instruction (core dumped)"

The following table identifies the machines that may have this problem.

      Platform                Firmware Rev
      --------                ------------
      DECpc AXP 150           SRM Console V2.2
      DEC 2000 AXP            SRM Console V2.2
      DEC 3000 AXP            Console V6.5
      DEC 4000 AXP            Console V3.7
      AlphaStation 2x0/400    SRM Console V6.0
      AlphaServer 400         SRM Console X4.4
      AlphaStation 255        SRM Console V6.0
      AlphaServer 1000        SRM Console V3.1-21
      AlphaServer 2000/2100   SRM Console V4.4
      DEC 7000/10000 AXP      LFU V11
      Digital AXPvme          Console V15.0
      DECAXPPC133             SRM Console X4.3-3114


To determine if a machine has OSF PALcode version 1.45, do one of these:

  1)  Look for the following line in the output from Digital UNIX as it boots.

             PALcode: OSF version 1.45

  2)  At the console prompt prior to booting Digital UNIX, type "show config".

>>>show config

   Console V3.7-3                    VMS PALcode V5.53A, OSF PALcode V1.45A

      Note: V1.45A is the same as V1.45.

Common floating point operations will reproduce the problem.  For example:

floor.c
-------

#include 

main()
{
   double dd = (double)0.019999999552965164;
   double int_dd;

   int_dd = floor(dd);

   printf("dd = %f    int_dd = %f\n", dd, int_dd);
}

Compiling with:
---------------

  cc   floor.c  -o floor

Executing:
---------

  floor

inst fault=4, status word=               8, pc=     3ff80128e50
Illegal instruction (core dumped)


PROBLEM:        (HPXQ10B7D)             (Patch ID: OSF365-020-1)
********
Fix to allow clock to advance properly (wrap to next year) at end of year
when system is powered down and to prevent clock from losing a day on each
reboot during March of a leap year.

o Systems that are shut down and powered off prior to Jan 1 will not have the
  correct date when restarted after the New Year.

o Also, the clock on systems rebooted during the month of March of a leap year
  will loose a day for each reboot.


PROBLEM:	(QAR 44102)	(Patch ID: OSF365-360039)
********
This patch corrects problems in tlb shootdown code:

 - Tlbshootdown requests could panic with timeouts because the
   other processor(s) do not respond to the interrupt.

 - The system may display invalid "tlb invalidate" messages.

 - There could be some memory data corruption or a memory fault.

 - Other processors in a cluster could have touched memory while
   it was being reset.

There is no stack trace available.  If you see a panic with a tlb
shootdown timeout panic, where it appears that one processor has
posted a tlb shootdown, but other processors have not responded,
then this patch may fix the problem.

It is also possible to see memory data corruption or a memory fault.

The fix for clusters was made as a preemptive fix in conjunction
with fixes for the other problems here.  There are no known
instances of problems of this type.

This patch is MOST likely to fix the problem if the chip is an EV-5.
It MAY fix the problem if the chip is an EV-45.
For older slower chips, lack of this patch is probably not the problem.


PROBLEM:	(40933)		(Patch ID: OSF365-360044)
********
If a user binds a process to a processor and then halts that
processor, the system may panic with a "simple lock owned" panic.

The system may panic if a process is bound to a processor
 (e.g., runon 1 ls -lR /)  and the processor with the bound
job is then halted (e.g., psradm -f 1).

   panic: thread_block: simple lock owned.

runon 1 ls -lR / > /dev/null &
psradm -f 1


PROBLEM:        (MCPM55057, QAR 46617)  (Patch ID: OSF365-029-1)
********
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 restart 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:        (7MPBA0854, QAR 46525, QAR 38394)  (Patch ID: OSF365-360046)
*******
Multi-processor systems using the AdvFS file system, particularly
systems also using AdvFS for the root and usr file systems, may experience
intermittent freezing of interactive processes when the system has a moderate
to heavy I/O load.  The freezing of interactive processes may last from
a few seconds to many minutes but will eventually return to normal.

This problem may also occur on multi-processor systems using
the NFS client or graphics sub-systems.


PROBLEM:        (MGO102099, MGO102041)  (Patch ID: OSF365-360055)
********
The system will crash with " u_shm_oop_deallocate: reference count
mismatch."

A typical stack trace is shown below:

       boot
       panic
       u_shm_oop_deallocate
       vm_map_entry_delete
       u_map_delete
       u_map_lockvas_expand
       u_map_enter
       shmat
       syscall
       _Xsyscall

The problem is closely related to processes that use the "plock"
system call in order to lock their text and/or data segments in memory.
When such a process attaches itself to a shared memory segment, the
"shmat" system call allocates the required physical pages and "locks"
them in memory.  There may be a resource shortage in this situation
if (e.g.) there aren't enough free pages available.


PROBLEM:	(CA6Q61192)	(Patch ID: OSF365-360056)
********
The patch for CLD CA6Q61192 fixes two deadlock problems respectively in
VM and PROCFS.  The deadlocks manifest themselves as hangs in Ladebug
which often occur after proceeding from a breakpoint or when
single-stepping.  The ps listing for the process being debugged will
show one or more threads in the uninterruptible state (a 'U' in the
state column below).  Both the process being debugged and ladebug
cannot be killed even with SIGKILL.

DCCS01:/usr1/users/encina> ps mp 8663
  PID TTY      S           TIME COMMAND
 8663 ??       R     1-02:12:33 /dccs/users/weber/schd/SCHD_emergency_orders_se
               R N     02:27:40
               R N     02:16:31
               R N     02:40:37
               R N     02:05:21
               R N     02:35:35
               IWN      0:00.00
               R N     02:48:16
               U N      0:01.13
               I N      0:00.02
               I N      0:00.01
               I N      0:00.02
               I N      0:00.01
               IWN      0:00.01
               IWN      0:00.00
               IWN      0:00.00
               IWN      0:00.00
               IWN      0:00.00
               U N      0:00.39
               R N     02:46:05
               IWN      0:00.00
               IWN      0:00.11
               IWN      0:00.00
               I N      0:00.03
               I N      0:00.00
               R N     02:26:40
               I N      0:00.00
               R N     03:09:08
               I N      0:00.00
               H N      0:00.00

VM Deadlock
~~~~~~~~~~~~

Ladebug process:

>  0 thread_block() [kern/sched_prim.c":1924, 0xfffffc000046a674]
   1 u_anon_dupmcopy() [vm/u_mape_anon.c":1475, 0xfffffc000037b398]
   2 u_anon_dup() [vm/u_mape_anon.c":1214, 0xfffffc0000379ee4]
   3 u_map_copyin() [vm/vm_umap.c":1975, 0xfffffc0000397ffc]
   4 vm_map_copyin() [vm/vm_map.c":1551, 0xfffffc000038c298]
   5 procfs_tioctl() [procfs/procfs_vnops.c":5782, 0xfffffc000028861c]
   6 procfs_ioctl() [procfs/procfs_vnops.c":5311, 0xfffffc0000287c94]
   7 vn_ioctl() [vfs/vfs_vnops.c":1109, 0xfffffc000029a5b0]
   8 procfs_ioctl_interface() [procfs/procfs_vnops.c":6766, 0xfffffc0000289f24]
   9 ioctl_base() [bsd/sys_generic.c":396, 0xfffffc000024f678]
  10 ioctl() [bsd/sys_generic.c":344, 0xfffffc000024f34c]
  11 syscall() [arch/alpha/syscall_trap.c":569, 0xfffffc0000486b54]
  12 _Xsyscall() [arch/alpha/locore.s":1094, 0xfffffc0000475fc4]

Target task (debugee):

Thread 0xfffffc000e09c800:
>  0 thread_block() [kern/sched_prim.c":1912, 0xfffffc000046a604]
   1 u_anon_faultpage() [vm/u_mape_anon.c":889, 0xfffffc0000379294]
   2 u_anon_fault() [vm/u_mape_anon.c":755, 0xfffffc0000378d34]
   3 u_map_fault() [vm/vm_umap.c":435, 0xfffffc00003951f4]
   4 vm_fault() [vm/vm_fault.c":130, 0xfffffc0000387e04]
   5 trap() [arch/alpha/trap.c":1233, 0xfffffc0000487a68]
   6 _XentMM() [arch/alpha/locore.s":1307, 0xfffffc00004761d4]

Procfs deadlock
~~~~~~~~~~~~~~~

Debugee process:

>  0 thread_block() [kern/sched_prim.c":1924, 0xfffffc000046a674]
   1 thread_dowait() [kern/thread.c":2070, 0xfffffc00002da60c]
        thread = 0xfffffc000e92bc00
   2 task_dowait() [kern/task.c":804, 0xfffffc00002d7db8]
   3 task_suspend_self() [kern/task.c":1276, 0xfffffc00002d8780]
   4 procfs_stop_new_thread() [procfs/procfs_subrs.c":826, 0xfffffc0000281b14]
        locked pr_trace_lock
   5 thread_create_internal() [kern/thread.c":1038, 0xfffffc00002d95d8]
   6 thread_create() [kern/thread.c":787, 0xfffffc00002d91a4]
   7 _Xthread_create() ["mach/mach_server.c":3217, 0xfffffc00002f22e8]
   8 mach_server() ["mach/mach_server.c":6451, 0xfffffc00002f3200]
   9 mach_msg() [kern/ipc_basics.c":438, 0xfffffc00002c88d0]
  10 msg_rpc_trap() [kern/ipc_basics.c":1432, 0xfffffc00002c9c3c]
  11 _Xsyscall() [arch/alpha/locore.s":1249, 0xfffffc0000476118]

>  0 thread_block() [kern/sched_prim.c":1912, 0xfffffc000046a604]
   1 lock_write() [kern/lock.c":472, 0xfffffc0000465ab4]
   2 procfs_trace_signals() [procfs/procfs_subrs.c":457, 0xfffffc00002811f8]
   3 psig() [bsd/kern_sig.c":3798, 0xfffffc0000432aec]
        has sig_wait_lock()
   4 trap() [arch/alpha/trap.c":1366, 0xfffffc0000487d5c]
   5 _XentIF() [arch/alpha/locore.s":688, 0xfffffc0000475c90]

                                                                                
PROBLEM:	(HPAQ68777)		(Patch ID: OSF365-360057)
*******
A system can crash with:

        panic: "pmap_remove_range: page wired"

if certain kernel functions try to malloc more memory pages 
than allowed by the vm configuration parameter vm-vpagemax, 
which by default is set to 16384.

While this parameter could be set higher as a temporary workaround, the
proper fix is to install this patch.

A typical stack trace is:

0 stop_secondary_cpu() [src/kernel/arch/alpha/cpu.c:368]
1 panic("event_timeout: panic request") [src/kernel/bsd/subr_prf.c:669]
2 event_timeout() [src/kernel/arch/alpha/cpu.c:725]
3 xcpu_puts() [src/kernel/bsd/subr_prf.c:810]
4 printf() [src/kernel/bsd/subr_prf.c:355]
5 panic("pmap_remove_range: page wired") [src/kernel/bsd/subr_prf.c:719]
6 pmap_remove_range() [src/kernel/arch/alpha/pmap.c:1804]
7 pmap_remove() [src/kernel/arch/alpha/pmap.c:1946]
8 u_anon_unmap() [src/kernel/vm/u_mape_anon.c:1635]
9 u_map_delete() [src/kernel/vm/vm_umap.c:1211]
10 vm_map_delete() [src/kernel/vm/vm_map.c:1214]
11 munmap() [src/kernel/bsd/kern_mman.c:814]
12 syscall() [src/kernel/arch/alpha/syscall_trap.c:519]
13 _Xsyscall() [src/kernel/arch/alpha/locore.s:1094]


PROBLEM:  (HPXQ43C4D, TKTR52185, QAR 46016)	(Patch ID: OSF365-035-1)
********
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:	(DMO100161, QAR39130)	(Patch ID: OSF365-350082)
********
System panics with "xcr_que_insert list corruption"

Stack trace:

>  0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":352, 0xfffffc00004d9598]
   1 panic(s = 0xfffffc000063d0f8 = "event_timeout: panic request") ["../../../../src/kernel/bsd/subr_prf.c":669, 0xfffffc000044015c]
   2 event_timeout(func = 0xfffffc00004403b0, arg = 0xfffffc00006d92d8, timeout = 5754056) ["../../../../src/kernel/arch/alpha/cpu.c":698, 0xfffffc00004da038]
   3 xcpu_puts(s = 0xffffffff453cef60, prfbufp = 0xfffffc00006d92d8) ["../../../../src/kernel/bsd/subr_prf.c":810, 0xfffffc0000440414]
   4 printf(va_alist = -4398040034192) ["../../../../src/kernel/bsd/subr_prf.c": 355, 0xfffffc000043f764]
   5 panic(s = 0xfffffc0000654760 = "xcr_que_insert list corruption") ["../../../../src/kernel/bsd/subr_prf.c":719, 0xfffffc00004402cc]
   6 xcr_que_insert(0xfffffffebd491d58, 0xffffffff453cc000, 0xc, 0xffffffffc0207605, 0xfffffc0000567d28) ["../../../../src/kernel/io/dec/eisa/xcr_port.c":1222, 0xfffffc000056d3dc]
   7 xcr_action(0xfffffffebd491d58, 0xfffffffe06508a18, 0xfffffc0000569bb0, 0x0, 0xfffffffebd491c00) ["../../../../src/kernel/io/dec/eisa/xcr_port.c":1114, 0xff fffc000056d1dc]
   8 re_ioctl(0x2c00002, 0xffffffffc0207605, 0xffffffff453cf688, 0x1, 0xfffffffec079e800) ["../../../../src/kernel/io/dec/eisa/re_driver.c":2803, 0xfffffc0000569d00]
   9 spec_ioctl(0xfffffffebdda2200, 0xffffffffc0207605, 0xffffffff453cf688, 0x1, 0xfffffffe06333db0) ["../../../../src/kernel/vfs/spec_vnops.c":1986, 0xfffffc000044c254]
  10 vn_ioctl(0xffffffff453cf738, 0xffffffffc0207605, 0xffffffff453cf688, 0xfffffffe064e7180, 0xfffffc000042c6dc) ["../../../../src/kernel/vfs/vfs_vnops.c":1109, 0xfffffc000029633c]
  11 ioctl_base(0xfffffffe06508210, 0xffffffff453cf8c8, 0xffffffff453cf8b8, 0xffffffff453cf8c8, 0xfffffc00004ec858) ["../../../../src/kernel/bsd/sys_generic.c": 465, 0xfffffc000024d8a4]
  12 ioctl(0xffffffff453cf8b8, 0xffffffff453cf8c8, 0xfffffc00004ec858, 0x1, 0xfffffc00004ec33c) ["../../../../src/kernel/bsd/sys_generic.c":344, 0xfffffc000024d26c]
  13 syscall(0x120005fe4, 0x8, 0x1, 0x21, 0x36) ["../../../../src/kernel/arch/alpha/syscall_trap.c":530, 0xfffffc00004ec338]
  14 _Xsyscall(0x8, 0x3ff800d5e08, 0x1400099e0, 0x3, 0xc0207605) ["../../../../src/kernel/arch/alpha/locore.s":1086, 0xfffffc00004dca44]


PROBLEM:	(CA6Q61192A)	(Patch ID: OSF365-360068)
********
This patch is an update to patch OSF365-360057.  Patch OSF365-360057 
inadvertantly dropped changes in Patch OSF365-360056.  

Without this patch, the Ladebug process could hang when debugging 
in single user mode.

                                                                                
PROBLEM:	(QAR 48680)	(Patch ID: OSF365-360070-2)
********
This patch enables the latest Informix KAIO functionality.

The patch should be installed by Informix customers using 
the Informix 7.20.UC4 release.  The Informix defect number 40041 
regarding KAIO is fully addressed by this patch.

The patch is required when this message appears, followed by 
a core dump with the SIGABRT signal:

        Internal AIO consistency error:
                No fork for group completion. Aborting.


PROBLEM:  (HPXQ87202, QAR 49448, QAR 49474, QAR 49475, QAR 49553)
********            (Patch ID:  OSF365-360076-1)

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:	(DMO100161, QAR39130)		(Patch ID: OSF365-009)
********
Fixes a problem with systems running SWXCR utilities swxcrmon (online monitor)
and swxcrmgr (management GUI).

These systems will panic with  "xcr_que_insert list corruption"  error message:

Stack trace:

>  0 stop_secondary_cpu()
    ["../../../../src/kernel/arch/alpha/cpu.c":352, 0xfffffc00004d9598]
   1 panic()
    ["../../../../src/kernel/bsd/subr_prf.c":669, 0xfffffc000044015c]
   2 event_timeout()
    ["../../../../src/kernel/arch/alpha/cpu.c":698, 0xfffffc00004da038]
   3 xcpu_puts()
    ["../../../../src/kernel/bsd/subr_prf.c":810, 0xfffffc0000440414]
   4 printf()
    ["../../../../src/kernel/bsd/subr_prf.c":355, 0xfffffc000043f764]
   5 panic()
    ["../../../../src/kernel/bsd/subr_prf.c":719, 0xfffffc00004402cc]
   6 xcr_que_insert()
    ["../../../../src/kernel/io/dec/eisa/xcr_port.c":1222, 0xfffffc000056d3dc]
   7 xcr_action()
    ["../../../../src/kernel/io/dec/eisa/xcr_port.c":1114, 0xfffffc000056d1dc]
   8 re_ioctl()
    ["../../../../src/kernel/io/dec/eisa/re_driver.c":2803, 0xfffffc0000569d00]
   9 spec_ioctl()
    ["../../../../src/kernel/vfs/spec_vnops.c":1986, 0xfffffc000044c254]
  10 vn_ioctl()
    ["../../../../src/kernel/vfs/vfs_vnops.c":1109, 0xfffffc000029633c]
  11 ioctl_base()
    ["../../../../src/kernel/bsd/sys_generic.c":465, 0xfffffc000024d8a4]
  12 ioctl()
    ["../../../../src/kernel/bsd/sys_generic.c":344, 0xfffffc000024d26c]
  13 syscall()
    ["../../../../src/kernel/arch/alpha/syscall_trap.c":530, 0xfffffc00004ec338]
  14 _Xsyscall()
    ["../../../../src/kernel/arch/alpha/locore.s":1086, 0xfffffc00004dca44]


PROBLEM:	  (UVO103661,HPXQA4050,MGO101764,TKTRA1625,HPXQB9FCB)
********		    (Patch ID: OSF365-350098)
This bug causes panic that results in the following console messages:

trap: invalid memory read access from kernel mode
    faulting virtual address:     0x0000000000436244
    pc of faulting instruction:   0xfffffc0000431148
    ra contents at time of fault: 0xfffffc000043112c
    sp contents at time of fault: 0xffffffff9aee75b0
panic (cpu 1): kernel memory fault

The panic stack trace can originate from any number of sources, but will
pass through malloc(), which takes a memory fault leading to a panic:

>  0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":352, 0xfffffc000047ca08]
   1 panic(s = 0xfffffc00005ad8a8 = "event_timeout: panic request") ["../../../../src/kernel/bsd/subr_prf.c":669, 0xfffffc0000442eac]
   2 event_timeout(func = 0xfffffc0000443100, arg = 0xfffffc000065b850, timeout = 0xffffffff80000000) ["../../../../src/kernel/arch/alpha/cpu.c":698, 0xfffffc00 0047d4a8]
   3 xcpu_puts(s = 0xffffffff9aee70f8, prfbufp = 0xfffffc000065b850) ["../../../../src/kernel/bsd/subr_prf.c":810, 0xfffffc0000443164]
   4 printf(va_alist = 0xfffffc00005a9bb0) ["../../../../src/kernel/bsd/subr_prf.c":355, 0xfffffc00004424b4]
   5 panic(s = 0xfffffc00005b0200 = "kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":719, 0xfffffc000044301c]
   6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281, 0xfffffc00004915c8]
   7 _XentMM(0x4, 0xfffffc0000431148, 0xfffffc00005e9fc0, 0x436244, 0xfffffc000065aa68) ["../../../../src/kernel/arch/alpha/locore.s":1306, 0xfffffc00004800c4]
   8 malloc(size = 0x58, indx = 0x65cac0, type = 0x31, nowait = 0x1) ["../../../../src/kernel/bsd/kern_malloc.c":520, 0xfffffc0000431144]
   9 psignal_indirect_alloc(0xffffffff81b3eeb0, 0xfffffc000065cac0, 0xfffffc0000248adc, 0x1, 0xfffffc000042bcc8) ["../../../../src/kernel/bsd/kern_sig.c":4524, 0xfffffc000043e918]
  10 realitexpire(0xffffffff81ce8d90, 0x0, 0xfffffc000042b8ec, 0xffffffff9aee4000, 0x0) ["../../../../src/kernel/bsd/kern_time.c":722, 0xfffffc0000248ad8]
  11 softclock_scan(usermode = 0x0) ["../../../../src/kernel/bsd/kern_clock.c":989, 0xfffffc000042bcc4]
  12 hardclock(pc = 0xfffffc0000475df8 = "", ps = 0x0) ["../../../../src/kernel/bsd/kern_clock.c":813, 0xfffffc000042b8e8]
  13 _XentInt(0x0, 0xfffffc0000475df8, 0xfffffc00005e9fc0, 0x3fff, 0x1) ["../../../../src/kernel/arch/alpha/locore.s":916, 0xfffffc000047fcf8]
  14 idle_thread() ["../../../../src/kernel/kern/sched_prim.c":2811, 0xfffffc0000475df4]

Note that the important part of the trace is from frames 0 through 8; the
caller of malloc() is not relevant, and is unrelated to the problem.

This specific bug can be verified by adding the KSEG base address of
0xfffffc0000000000 to the faulting virtual address taken from the
error message above, and determining what the resulting address represents:

(dbx) (0xfffffc0000000000 + 0x0000000000436244)/i
  [pgrp_ref:584, 0xfffffc0000436244]    bsr     r26, simple_unlock(line 273)
(dbx)

If the result is in pgrp_ref() like above, then this fix is the solution.

Another relevant symptom is that the kmembucket chain containing freed
process group structures is corrupted by the faulting virtual address;
This can be verified by noting that the "kb_next" field in kmembuckets[3]
contains the same faulting address:

(dbx) p kmembuckets[3]
struct {
    kb_lock = struct {
        sl_data = 0x431129
        sl_info = 0x0
        sl_cpuid = 0x0
        sl_lifms = 0x0
    }
    kb_next = 0x436244
    kb_size = 0x80
    kb_free = 0x444
    kb_total = 0x1240
    kb_elmpercl = 0x40
    kb_highwat = 0x800
}

There is no known manner of reproducing the problem; however, on systems where
it happens, it is a fairly regular occurance.


PROBLEM:        (UVO103764)	(Patch ID: OSF365-350113)
********
Fixes system panic with "Zombie walks again" panic message.


PROBLEM:        (QAR 41490)	(Patch ID: OSF365-010)
********
In some situations the SWXCR controller may hang and I/Os won't complete.  

There is a SWXCR Driver timing issue where a rebuild in process can cause 
the controller to delay I/O completion and timeout commands.  The driver 
will start to reset the controller and eventually the controller will hang.  

This is evident by the fact that I/Os issued to that SWXCR controller 
do not complete.  This patch will correct this problem.


PROBLEM:        (QARs 33697,35428,35419)	(Patch ID: OSF365-013)
********
This patch fixes the following problems:

o AlphaServer 8200 systems do not correctly log 660 machine check errors.
  This results in unsuccessful system crashes. Instead of the system
  displaying panic messages, "kernel stack not valid" errors
  are displayed.

o AlphaServer 8200 systems do not provide enough information
  in the error log files to correctly diagnose 660 machine check errors.

o On SMP machines, correctable processor error logging
  is inadvertently disabled at system boot up time.
  These correctable errors will not appear in the error logfile.


PROBLEM:	(QAR 44102)	(Patch ID: OSF365-015)
********
Fixes a timing problem with tlb shootdown where the system panics 
with the error message:   "tlb_shoot ack timeout".


PROBLEM:	(QAR 33741)	(Patch ID: OSF365-350184)
********
The system panics with "ipc_thread_init: reply port allocate" after an
unsuccessful port allocation request.

A user wrote a program that called port_allocate() repeatedly until the
system ran out of resources.  After that the next operation anywhere on the
system that needed those same resources caused the system to panic. 

Here is a representative stack trace:

0 boot() [src/kernel/arch/alpha/machdep.c:1735]
1 panic("ipc_thread_init: reply port allocate") [src/kernel/bsd/subr_prf.c:757]
2 ipc_thread_init() [src/kernel/kern/ipc_tt.c:420]
3 thread_create_internal() [src/kernel/kern/thread.c:913]
4 procdup() [src/kernel/vm/vm_unix.c:598]
5 newproc() [src/kernel/bsd/kern_fork.c:672]
6 fork1() [src/kernel/bsd/kern_fork.c:500]
7 vfork() [src/kernel/bsd/kern_fork.c:427]
8 syscall() [src/kernel/arch/alpha/syscall_trap.c:519]
9 _Xsyscall() [src/kernel/arch/alpha/locore.s:1094]


PROBLEM:	(CA6Q61192,UVO104419)	(Patch ID: OSF365-037)
********
Processes can become hung during a system call to table().  Debuggers are
particularly prone to this problem.
                             

PROBLEM:        (MCPM94D74, QAR 49067)  (Patch ID: OSF365-360085)
********
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:        (MGO102628,MGO102687,QAR 51439) (Patch ID: OSF365-050-1)
*******
When debugging multithreaded applications with Ladebug, debugging sessions
may hang due to a bug in procfs (i.e., /proc filesystem).

A simple way to reproduce the problem is to set a breakpoint in separate
threads, run the application, change the thread focus to a thread other than
the one which took the breakpoint, and to single-step.  Under these
circumstances, the debugger does not return to the debugger prompt
and the debugging session effectively hangs.  At this point, ps output
simply indicates that the debugger and the debuggee are sleeping interruptibly.
However, when a SIGKILL is sent to the debuggee, the affected threads o
in the debugged process enter an uninterruptible sleep ('U' state in
the ps listing).  The traced process is now unkillable.


PROBLEM:	(QAR 50697,MGO102332,FNO100130)	(Patch ID: OSF365-360087)
********
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:        (GOZ100707,MCPM777CC,QAR 47889,48876)  (Patch ID: OSF365-054)
********
This patch fixes a problem that occurs on AlphaServer 8200 and 8400 systems
when a processor fails to restart after a user halts the system by entering
"Control-P Control-P" and then typing "continue" on the console.

This patch requires running firmware version 4.8-6 or later.

This patch also fixes a problem where the pset_info and psradm commands
fail to correctly report that a CPU is shut down.


PROBLEM:        (QAR 50693, QAR 49421)          (Patch ID: OSF365-350372)
********
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.


PROBLEM:        (HPAQ31FP3,MCPM40M9Q,ZPOB42573) (Patch ID: OSF365-360093)
********
Fixes a panic that prints "delete_pv_entry: mapping not in pv_list".

A typical stack trace is:

   5 panic("delete_pv_entry: mapping not in pv_list")
   6 delete_pv_entry()        [src/kernel/arch/alpha/pmap.c]
   7 pmap_enter()             [src/kernel/arch/alpha/pmap.c]
   8 kmem_stack_alloc()       [src/kernel/vm/vm_kmap.c]
   9 stack_alloc()            [src/kernel/kern/thread.c]
  10 thread_create_internal() [src/kernel/kern/thread.c]
  11 procdup()                [src/kernel/vm/vm_unix.c]
  12 newproc()                [src/kernel/bsd/kern_fork.c]
  13 fork1()                  [src/kernel/bsd/kern_fork.c]
  14 fork()                   [src/kernel/bsd/kern_fork.c]
  15 syscall()                [src/kernel/arch/alpha/syscall_trap.c]
  16 _Xsyscall()              [src/kernel/arch/alpha/locore.s]


PROBLEM:        (QAR 42473)     (Patch ID: OSF365-360093)
********
Fixes a panic that prints "pmap_dup: level3 PTE not valid".

A typical stack trace is:

   1 panic("pmap_dup: level3 PTE not valid")
   2 pmap_dup()      [src/kernel/arch/alpha/pmap.c]
   3 vm_dup_va()     [src/kernel/vm/vm_kern.c]
   4 alloc_context() [src/kernel/io/dec/ws/interg.c]
   5 interg_ioctl()  [src/kernel/io/dec/ws/interg.c]
   6 wsioctl()       [src/kernel/io/dec/ws/ws_driver.c]
   7 spec_ioctl()    [src/kernel/vfs/spec_vnops.c]
   8 vn_ioctl()      [src/kernel/vfs/vfs_vnops.c]
   9 ioctl_base()    [src/kernel/bsd/sys_generic.c]
  10 ioctl()         [src/kernel/bsd/sys_generic.c]
  11 syscall()       [src/kernel/arch/alpha/syscall_trap.c]
  12 _Xsyscall()     [src/kernel/arch/alpha/locore.s]


PROBLEM:        (QAR 51581)     (Patch ID: OSF365-360093)
********
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:        (USG-04712)     (Patch ID: OSF365-360101)
********
The patch fixes the corruption of core files produced by applications
with 15 or more threads.

The corrupted core file will show nonsensical or incomplete stack traces
beyond the fifteenth thread.  The register and local variable state of threads
can also show incorrect values.


PROBLEM:                        (Patch ID: OSF365-350438-1)
********
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:	(mgo102246)	(Patch ID: OSF365-036)
********
After the appearance of binary.errlog entries:

    sim_err_sm    Target went to command phase
    sim94_intr    Illegal command

The system can hang with the following typical stack trace:

0 ss_process_timeouts() [src/kernel/io/cam/sim_sched.c:2572]
1 softclock_scan() [src/kernel/bsd/kern_clock.c:1015]
2 hardclock("") [src/kernel/bsd/kern_clock.c:839]
3 _XentInt() [src/kernel/arch/alpha/locore.s:917]
4 idle_thread() [src/kernel/kern/sched_prim.c:3009]


PROBLEM:	( QAR 29649 )	(Patch ID: OSF365-036)
********
Fix system panic: "xpt_callback: callback on freed CCB".

The panic described in this QAR was caused by a bug in the SIM94
interrupt handler where the target mode flag for a controller
was being set before a previous non-target mode request was
completed.


PROBLEM:	(TKTB52828, QAR 42761)	(Patch ID: OSF365-031)
********
This patch fixes a situation in which a system panics, displaying the string:

        panic `Unable to restart Qlogic(LUN queue after abort)

A typical stack trace for this type of panic is:

        0 boot
        1 panic         `Unable to restart Qlogic(LUN queue after abort)`
        2 isp_termio_abort_bdr
        3 ss_perform_abort
        4 ss_sched
        5 scsiisr
        6 ss_start_sm
        7 ss_go
        8 ss_abort
        9 ss_perform_timeout
        10 ss_process_timeouts
        11 softclock_scan
        12 hardclock
        13 _XentInt
        14 idle_thread


PROBLEM:	(QAR 46071, 45122)	(Patch ID: OSF365-031)
********
This patch fixes a situation in which a system panics, displaying the text:

        simple_unlock: minimum spl violation

        pc of caller:         0xfffffc0000420b04
        lock address:         0xfffffc0077f236d0
        lock info addr:       0xfffffc00005b0b50
        lock class name:      cam_pd_device       (could also be cam_isp)
        current spl level:    0
        required spl level:   4
        panic (cpu xx): simple_unlock: minimum spl violation

where 'xx' above is the CPU number.  A sample stack trace is not available.
This panic is seen when lockmode is set to 4.


PROBLEM:	(QAR 46756)		(Patch ID: OSF365-031)
********
This patch fixes the situation where the following sequences of messages are
displayed during startup:

     cam_logger: CAM_ERROR packet
     cam_logger: bus 0
     isp_enable_lun
     Failed to enable target for selections
     cam_logger: CAM_ERROR entry too large to log!
     cam_logger: CAM_ERROR packet
     cam_logger: bus 0
     isp_enable_lun
     Failed to enable target for selections
     cam_logger: CAM_ERROR entry too large to log!
     cam_logger: CAM_ERROR packet


PROBLEM:  (ZPOB71272,46139,46757,42908,43719,44474,40361,40443,41465)
********				(Patch ID: OSF365-031)

This patch fixes a situation in which a system panics, displaying the string:

        panic `Simple lock : time limit exceeded`

One typical stack trace for this type of panic is:

        4 boot
        5 panic
        6 simple_lock_fault
        7 simple_lock_time_violation
        8 ss_finish
        9 sm_bus_free
        10 isp_process_response_queue
        11 isp_intr
        12 intr_dispatch_post
        13 _XentInt
        14 isp_mailboxcomplete
        15 isp_mailboxissue
        16 isp_abort
        17 isp_termio_abort_bdr
        18 ss_perform_abort
        19 ss_sched
        20 scsiisr
                                                                  
Another stack trace encountered is:

        12 boot
        13 panic        `Simple lock : time limit exceeded`
        14 simple_lock_fault
        15 simple_lock_time_violation
        16 ss_finish
        17 ss_abort_done
        18 sm_bus_free
        19 isp_abort_done
        20 softclock_scan
        21 hardclock
        22 _XentInt
        23 alpha_delay
        24 microdelay
        25 isp_mailboxcomplete
        26 isp_mailboxissue
        27 isp_stop_queue
        28 isp_termio_abort_bdr
        29 ss_perform_abort
        30 ss_sched
        31 scsiisr
        32 ss_start_sm
        33 ss_go
        34 ss_abort


PROBLEM:	(HGOBB0043,HGOBB0597)		(Patch ID: OSF370-043)
********
Intermittently, the probe of an isp will fail during a boot, and the system can
hang.  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.
        .
        .
        .

IMPORTANT:  This patch should be installed on ANY system that contains 
            a Qlogic chip.  If the system boot sequence displays the 
	    word "Qlogic", then install this patch.  Qlogic chips are built 
	    into many systems, and can also be found in many add-on options, 
	    such as: KFTIA, KZPBA, KZPDA, PZPSM, P1SE, P2SE, and others.


PROBLEM:        (MCPMA8909)     (Patch ID: OSF365-350309)
********
When HSZ50 hardware is installed without this patch, the system can exhibit
very slow performance.

This happens because the HSZ50 is not defined in cam_data.c and devio.h,
so the system does not take advantage of its more advanced capabilities.


PROBLEM:	(HPXQB83C7,MCPMB5B91) 		(Patch ID: OSF365-005)
********
Fixes a problem where a system panics with the following error message:

 "simple lock: time limit exceeded".

This situation may occur during the creation of an Oracle database.

A sample stack trace for the problem CPU is as follows:

   .......
   .......
   6 simple_lock_time_violation()
   7 spo_go()
   8 spo_process_resource_q()
   9 spo_pool_alloc_thread()

OR

   .......
   .......
   7 spo_immediate()
   8 spo_process_resource_q()
   9 spo_pool_alloc_thread()

This stack trace may or may not come from the panicing cpu, depending 
on if another cpu has been waiting longer on the spo resource queue lock.  

The panicing cpu may have a stack trace showing a wait in the cam/spo 
subsystem, but one of the cpus will show the stack trace listed above.


PROBLEM:        (QAR 44545)     (Patch ID: OSF365-027)
********
This patch fixes a data corruption error which can occur on KZTSA SCSI
adapters. This can result in data corruption on any tape drive connected
to the KZTSA when large block (1 Meg or greater) transfers are performed.
This data corruption has only been reported on odd block transfers.


PROBLEM:	(QAR 49540)	(Patch ID: OSF365-051)
********
Infrequently, under heavy disk I/O loads, user data can be written to
the wrong disk, resulting in data corruption.


PROBLEM:	(HPXL85F5D)	(Patch ID: OSF365-051)
********
In order to disconnect a tape drive from the bus for maintenance, Field
Service first quiesced the bus on the HSZ40, then powered off the tape
drive.  When the tape drive was powered off, the HSZ40 rebooted, and
the system then panicked with "simple_lock: time limit exceeded".

The stack trace looked like this:

One CPU timed out waiting for the spo resource queue lock:

9 panic("simple_lock: time limit exceeded") [src/kernel/bsd/subr_prf.c:757]
10 simple_lock_fault() [src/kernel/kern/lock.c:1794]
11 simple_lock_time_violation(()) [src/kernel/kern/lock.c:1863]
12 spo_add_to_resource_q() [src/kernel/io/cam/spo/simport.c:1063]
13 spo_action() [src/kernel/io/cam/spo/simport.c:624]

while another CPU continued to hold the lock:

1 panic("cpu_ip_intr: panic request") [src/kernel/bsd/subr_prf.c:727]
2 cpu_ip_intr() [src/kernel/arch/alpha/cpu.c:487]
3 _XentInt() [src/kernel/arch/alpha/locore.s:961]
4 spo_immediate() [src/kernel/io/cam/spo/simport.c:2156]
5 spo_action_immediate() [src/kernel/io/cam/spo/simport.c:1026]
6 spo_action() [src/kernel/io/cam/spo/simport.c:579]


PROBLEM:	(HPXLB76FB)	(Patch ID: OSF365-051)
********
When the system was under heavy load, the following group of 3 errors
was logged into the error logger every few minutes:

   spo_verify_adap_sanity
   spo_misc_errors
   spo_bus_reset


The entire system would pause for up to 30 seconds, and then resume
normal operation right before each group of 3 errors above were logged.


PROBLEM:	(QAR 45938, CLD HPAQ11CAJ)	(Patch ID: OSF365-051)
********
The system panicked with a kernel memory fault while trying to remove
an spo resource queue entry:

10 panic("kernel memory fault")
11 trap()
12 _XentMM
13 spo_remove_queue_entry
14 spo_process_rsp


PROBLEM:	(QAR 47247)	(Patch ID: OSF365-051)
********
The system panicked with: "xpt_callback: callback on freed CCB"

6 panic("xpt_callback: callback on freed CCB")
7 xpt_callback() [src/kernel/io/cam/xpt.c:2420]
8 spo_process_ccb() [src/kernel/io/cam/spo/simport.c:3548]
9 spo_process_rsp() [src/kernel/io/cam/spo/simport.c:3467]


PROBLEM:	(HPAL21E6A)		(Patch ID: OSF365-350182)
********
Customer's HSZ40s is not logging non-retryable errors in the errorlog.

These errors can be observed by hooking a printer to the HSZ40 port and
running the FMU utility to display the errors, and is not an acceptable
workaround.


PROBLEM:        (ZPOB91873, HGOBB0092)  (Patch ID: OSF365-052)
********
This patch provides additional event logging of Unit Attention
messages by the SCSI/CAM disk driver to the binary.errlog file.
It also provides additional details for hard errors logged after
unsuccessful I/O recovery attempts, and provides informational
messages on the progress of recovery events.

With this patch, Unit Attention messages are logged if they are
received during:

 a) Attempts to bring a drive online
 b) Sense data requests for reads and writes
 c) Recovery from a failed Test Unit Ready command


PROBLEM:        (ZPOB54023)     (Patch ID: OSF365-350405)
********
This is a mandatory patch for SMP systems.

This patch fixes panics that may occur on SMP systems.

The panics occur when one processor is exiting and the other processor
is trying to perform a pmap_tbsync.

The following error message is displayed on the systems:

        "simple_lock: time limit exceeded"

A sample stack trace for the cpu panicking with
"simple_lock: time limit exceeded" is as follows:

   panic("simple_lock: time limit exceeded")
   simple_lock_fault() ["/src/kernel/kern/lock.c":2065]
   simple_lock_time_violation() ["/src/kernel/kern/lock.c":2135]
   psignal_internal() ["/src/kernel/bsd/kern_sig.c":3183]
   psignal_inthread() [/src/kernel/bsd/kern_sig.c":4235]
   exit() ["/src/kernel/bsd/kern_exit.c":1270 ]
   rexit()["/src/kernel/bsd/kern_exit.c":755 ]
   syscall() ["/src/kernel/arch/alpha/syscall_trap.c":540]
   _Xsyscall()[/src/kernel/arch/alpha/locore.s":1209]

A sample stack trace for the cpu performing a pmap_tbsync is as follows:

  cpu_ip_intr() ["/src/kernel/arch/alpha/cpu.c":647]
  _XentInt()["/src/kernel/arch/alpha/locore.s":1076]
  mb()["/src/kernel/arch/alpha/pal_lib.s":252]
  xcpu_puts_ipir() ["/src/kernel/bsd/subr_prf.c":866]
  event_timeout()["/src/kernel/arch/alpha/cpu.c":1003]
  pmap_update_send()["/src/kernel/arch/alpha/pmap_update.c":250]
  pmap_tbsync()["/src/kernel/arch/alpha/pmap.c":4151]
  pmap_remove_range()["/src/kernel/arch/alpha/pmap.c":2175]
  pmap_remove()["/src/kernel/arch/alpha/pmap.c":2310]
  pmap_protect()["/src/kernel/arch/alpha/pmap.c":2374]
  free()["/src/kernel/bsd/kern_malloc.c":1129]
  m_free()["/src/kernel/bsd/uipc_mbuf.c":520"]
  m_freem()["/src/kernel/bsd/uipc_mbuf.c":529"]
  xnaread()["/src/kernel/io/dec/netif/if_xna.c":1372"]
  _XentInt()["/src/kernel/arch/alpha/locore.s":1049]
  issig() ["/src/kernel/bsd/kern_sig.c":4678]
  mpsleep()["/src/kernel/bsd/kern_synch.c":581]
  sigsuspend() ["/src/kernel/bsd/kern_sig.c":2228]
  syscall()["/src/kernel/arch/alpha/syscall_trap.c":540"]
  _Xsyscall()["/src/kernel/arch/alpha/locore.s":1209]


PROBLEM:        (QAR 51268)     (Patch ID: OSF365-068)
********
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:        (UVO105527)     (Patch ID: OSF365-350435)
********
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:                        (Patch ID: OSF365-073)
********
This patch provides general support for Version A11 KZPSA firmware.


PROBLEM:        (MCSM80GC5)     (Patch ID: OSF365-350448)
********
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:        (QAR 47628,QAR 45627,QAR 45069)  (Patch ID: OSF365-070)
********
This patch fixes an I/O queue corruption problem that occurs during
normal shut down of SMP systems with AdvFS.


PROBLEM:        (ZPOB54022)     (Patch ID: OSF365-071)
********
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:        (MCPM94D74, QAR 49067)  (Patch ID: OSF365-075)
********
This patch fixes a 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,]


FILE(s):

/usr/bin/lastcomm                       subset OSFBASE350 
CHECKSUM: 62398     24  RCSfile: lastcomm.c   RCS: 4.2.17.2
/usr/ccs/lib/libaio.a                   subset OSFPGMR365 
CHECKSUM: 53837     31
/usr/ccs/lib/libaio_raw.a               subset OSFPGMR365 
CHECKSUM: 08666     12
/usr/sys/BINARY/alpha_init.o 		subset OSFHWBIN365 
CHECKSUM: 48845     65	RCSfile: alpha_init.c  RCS: 1.2.94.2
/usr/sys/BINARY/cam_disk.o              subset OSFHWBIN365
CHECKSUM: 06047    193  RCSfile: cam_disk.c     RCS: 1.1.269.5
/usr/sys/BINARY/clock.o         	subset OSFHWBIN350 
CHECKSUM: 42793      6	RCSfile: clock.c	RCS: 1.2.27.3
/usr/sys/BINARY/cpu.o           	subset OSFBIN365 
CHECKSUM: 61922     62  RCSfile: cpu.c		RCS: 1.1.64.5
/usr/sys/BINARY/cpusw.o         	subset OSFHWBIN365 
CHECKSUM: 52694     12  RCSfile: cpusw.c	RCS: 1.1.75.5
/usr/sys/BINARY/ds1386clock.o   	subset OSFHWBIN365 
CHECKSUM: 11638      7  RCSfile: ds1386clock.c  RCS: 1.1.15.2
/usr/sys/BINARY/fp_ieee_handler.o 	subset OSFHWBIN350 
CHECKSUM: 56251      7	RCSfile: fp_ieee_handler.c  RCS: 1.1.22.2
/usr/sys/BINARY/host.o          	subset OSFBIN350 
CHECKSUM: 00204      7  RCSfile host.c          RCS: 4.2.16.2
/usr/sys/BINARY/if_faa.o        	subset OSFHWBIN350 
CHECKSUM: 31730     49	RCSfile: if_faa.c   RCS: 1.1.14.2   
			RCSfile: if_fxx.c   RCS: 1.1.38.4
/usr/sys/BINARY/init_main.o             subset OSFBIN365 
CHECKSUM: 15736     74	RCSfile: init_main.c	RCS: 4.3.192.2
/usr/sys/BINARY/ipc_kport.o 		subset OSFBIN350 
CHECKSUM: 31978      8	RCSfile: ipc_kport.c  RCS: 4.3.13.2
/usr/sys/BINARY/ipc_tt.o 		subset OSFBIN350 
CHECKSUM: 08508     10  RCSfile: ipc_tt.c     RCS: 4.3.29.2
/usr/sys/BINARY/isp1020.o       	subset OSFHWBIN365
CHECKSUM: 29403    103	RCSfile: isp1020.c  RCS: 1.1.89.3
/usr/sys/BINARY/kern_aio.o              subset OSFBIN365 
CHECKSUM: 40787     31  RCSfile: kern_aio.c   RCS: 1.1.67.3
/usr/sys/BINARY/kern_clock.o		subset OSFBIN350 
CHECKSUM: 27891     68  RCSfile: kern_clock.c  RCS: 4.3.88.2
/usr/sys/BINARY/kern_exec.o             subset OSFBIN350 
CHECKSUM: 22646     15  RCSfile: kern_exec.c  RCS: 4.5.105.2
/usr/sys/BINARY/kern_exit.o             subset OSFBIN350 
CHECKSUM: 33004     17  RCSfile: kern_exit.c  RCS: 4.4.108.3
/usr/sys/BINARY/kern_fork.o             subset OSFBIN350 
CHECKSUM: 09901     10  RCSfile: kern_fork.c  RCS: 4.4.73.3
/usr/sys/BINARY/kern_proc.o             subset OSFBIN365 
CHECKSUM: 10371     16  RCSfile: kern_proc.c	RCS: 4.3.60.3
/usr/sys/BINARY/kern_prot.o             subset OSFBIN370 
CHECKSUM: 02736     17  RCSfile: kern_prot.c  RCS: 4.4.60.2
/usr/sys/BINARY/kern_sig.o              subset OSFBIN365 
CHECKSUM: 06449     43  RCSfile: kern_sig.c	RCS: 4.5.123.6
/usr/sys/BINARY/kern_sigqueue.o         subset OSFBIN350
CHECKSUM: 22905      8	RCSfile: kern_sigqueue.c  RCS: 1.1.29.2
/usr/sys/BINARY/kern_sigsend.o          subset OSFBIN350 
CHECKSUM: 09197      9  RCSfile: kern_sigsend.c	RCS: 1.1.13.2
/usr/sys/BINARY/kern_synch.o            subset OSFBIN365 
CHECKSUM: 55703      9  RCSfile: kern_synch.c	RCS: 4.3.47.2
/usr/sys/BINARY/kern_time.o             subset OSFBIN365
CHECKSUM: 06393     22  RCSfile: kern_time.c   RCS: 4.4.93.2
/usr/sys/BINARY/kn15aa.o        	subset OSFHWBIN350 
CHECKSUM: 56186     39	RCSfile: kn15aa.c	RCS: 1.1.89.2
/usr/sys/BINARY/kn16aa.o        	subset OSFHWBIN365 
CHECKSUM: 09953     35	RCSfile: kn16aa.c	RCS: 1.1.72.2
/usr/sys/BINARY/kn430.o         	subset OSFHWBIN365 
CHECKSUM: 19353     65	RCSfile: kn430.c	RCS: 1.1.91.2
/usr/sys/BINARY/kn450.o         	subset OSFHWBIN365 
CHECKSUM: 03343     16  RCSfile: kn450.c        RCS: 1.1.99.6
/usr/sys/BINARY/kn470.o        		subset OSFHWBIN365 
CHECKSUM: 42812     18	RCSfile: kn470.c	RCS: 1.1.17.4
/usr/sys/BINARY/kn7aa.o        		subset OSFHWBIN365 
CHECKSUM: 64250     40	RCSfile: kn7aa.c	RCS: 1.1.64.3
/usr/sys/BINARY/kn8ae.o         	subset OSFHWBIN365 
CHECKSUM: 15578     31	RCSfile: kn8ae.c	RCS: 1.1.40.3
/usr/sys/BINARY/lsbmem.o        	subset OSFHWBIN365 
CHECKSUM: 06794      3  RCSfile: lsbmem.c	RCS: 1.2.14.2
/usr/sys/BINARY/mach_signal.o           subset OSFBIN350
CHECKSUM: 10198      5	RCSfile: mach_signal.c	RCS: 4.3.9.2
/usr/sys/BINARY/machdep.o      		subset OSFHWBIN365 
CHECKSUM: 53805     46	RCSfile: machdep.c	RCS: 1.2.245.4
/usr/sys/BINARY/machine.o       	subset OSFBIN350 
CHECKSUM: 64475     12  RCSfile: machine.c  	RCS: 4.3.40.3
/usr/sys/BINARY/mc146818clock.o  	subset OSFHWBIN350 
CHECKSUM: 59322      7	RCSfile: mc146818clock.c   RCS: 1.1.21.2
/usr/sys/BINARY/pmap.o          	subset OSFHWBIN365 
CHECKSUM: 10867    119	RCSfile: pmap.c		RCS: 1.2.164.6
/usr/sys/BINARY/pmap_update.o		subset OSFBIN350 
CHECKSUM: 18741      7  RCSfile: pmap_update.c  RCS: 1.1.29.2
/usr/sys/BINARY/pr.o            	subset OSFHWBIN365 
CHECKSUM: 12599    128	RCSfile: pr.c		RCS: 1.2.71.2
/usr/sys/BINARY/procfs_subrs.o          subset OSFBIN350 
CHECKSUM: 40435     18	RCSfile: procfs_subrs.c RCS: 1.1.20.3
/usr/sys/BINARY/procfs_vnops.o          subset OSFBIN365 
CHECKSUM: 42052    111	RCSfile: procfs_vnops.c RCS: 1.1.101.6
/usr/sys/BINARY/re_driver.o             subset OSFHWBIN365 
CHECKSUM: 15734     30  RCSfile: re_driver.c    RCS: 1.1.28.3
/usr/sys/BINARY/sched_prim.o    	subset OSFBIN365 
CHECKSUM: 50005     84  RCSfile: sched_prim.c   RCS: 4.3.112.3
/usr/sys/BINARY/sim_94.o		subset OSFHWBIN365
CHECKSUM: 10073    170	RCSfile: sim_94.c	RCS: 1.1.72.2
/usr/sys/BINARY/sim_htm.o               subset OSFHWBIN365
CHECKSUM: 22756     73	RCSfile: sim_htm.c	RCS: 1.1.3.2
/usr/sys/BINARY/sim_pza.o               subset OSFHWBIN365
CHECKSUM: 04306     17  RCSfile: sim_pza.c      RCS: 1.1.66.2
/usr/sys/BINARY/sim_sched.o             subset OSFHWBIN365
CHECKSUM: 54386     21  RCSfile: sim_sched.c    RCS: 1.1.57.3
/usr/sys/BINARY/sim_xpt.o               subset OSFHWBIN365
CHECKSUM: 18268     14  RCSfile: sim_xpt.c      RCS: 1.1.43.2
/usr/sys/BINARY/simport.o               subset OSFHWBIN365
CHECKSUM: 20706    178	RCSfile: simport.c   RCS: 1.1.59.4
/usr/sys/BINARY/softfp.o 		subset OSFHWBIN350 
CHECKSUM: 58178      8	RCSfile: softfp.c       RCS: 1.1.16.2
/usr/sys/BINARY/svc.o           	subset OSFBIN350
CHECKSUM: 27584     11	RCSfile: svc.c		RCS: 1.1.8.3
/usr/sys/BINARY/syscall_trap.o          subset OSFHWBIN365
CHECKSUM: 40593      9	RCSfile: syscall_trap.c  RCS: 1.1.50.2
/usr/sys/BINARY/task.o          	subset OSFBIN365 
CHECKSUM: 62881     64	RCSfile: task.c		RCS: 4.3.68.2
/usr/sys/BINARY/thread.o 		subset OSFBIN350 
CHECKSUM: 17696     27	RCSfile: thread.c     RCS: 4.4.89.3
/usr/sys/BINARY/tlsb_iop.o      	subset OSFHWBIN365 
CHECKSUM: 41119     18  RCSfile: tlsb_iop.c	RCS: 1.1.29.2
/usr/sys/BINARY/trap.o 			subset OSFHWBIN365 
CHECKSUM: 56250     68	RCSfile: trap.c		RCS: 1.2.70.2
/usr/sys/BINARY/u_mape_dev.o            subset OSFBIN350
CHECKSUM: 46464     11	RCSfile: u_mape_dev.c	RCS: 1.1.22.3
/usr/sys/BINARY/u_mape_anon.o		subset OSFBIN365 
CHECKSUM: 39762     46	RCSfile: u_mape_anon.c  RCS: 1.1.124.7
/usr/sys/BINARY/u_mape_shm.o		subset OSFBIN365 
CHECKSUM: 24746      7  RCSfile u_mape_shm.c    RCS: 1.1.58.2
/usr/sys/BINARY/u_mape_vp.o		subset OSFBIN350 
CHECKSUM: 39489     16	RCSfile u_mape_vp.c     RCS: 1.1.43.2
/usr/sys/BINARY/vfs_bio.o               subset OSFBIN365 
CHECKSUM: 10048     74  RCSfile: vfs_bio.c	RCS: 4.3.49.2
/usr/sys/BINARY/vm_kern.o               subset OSFBIN365 
CHECKSUM: 59985      8  RCSfile: vm_kern.c    RCS: 4.2.45.3
/usr/sys/BINARY/vm_resident.o           subset OSFBIN365 
CHECKSUM: 29100     78	RCSfile: vm_resident.c	RCS: 4.3.78.2
/usr/sys/BINARY/vm_umap.o		subset OSFBIN365 
CHECKSUM: 29888     26	RCSfile vm_umap.c	RCS: 1.1.89.4
/usr/sys/BINARY/vpage.o			subset OSFBIN350 
CHECKSUM: 13322      7	RCSfile vpage.c		RCS: 1.1.17.2
/usr/sys/BINARY/xcr_logger.o            subset OSFHWBIN350 
CHECKSUM: 21936     10  RCSfile: xcr_logger.c   RCS: 1.1.4.4
/usr/sys/BINARY/xcr_port.o              subset OSFHWBIN365 
CHECKSUM: 53781     37	RCSfile: xcr_port.c     RCS: 1.1.47.3
/usr/sys/BINARY/xpt.o           	subset OSFHWBIN365 
CHECKSUM: 11645    137  RCSfile: xpt.c		RCS: 1.1.51.2
/usr/sys/arch/alpha/hal/cpuconf.c       subset OSFHWBINCOM365 
CHECKSUM: 50730     37  RCSfile: cpuconf.c	RCS: 1.2.122.2
/usr/sys/conf/alpha/.mrg..files		subset OSFBINCOM365 
CHECKSUM: 64992      3 
/usr/sys/conf/alpha/files               subset OSFBINCOM365 
CHECKSUM: 23276     28
/usr/sys/data/cam_data.c            subset OSFBINCOM365
CHECKSUM: 52382    128	RCSfile: cam_data.c	RCS: 1.1.99.2
/usr/sys/data/if_faa_data.c    		subset OSFBINCOM350 
CHECKSUM: 64587      2	RCSfile: if_faa_data.c	RCS: 1.1.11.2
/usr/sys/data/if_fxx_data.c     	subset OSFBINCOM350 
CHECKSUM: 33123     20	RCSfile: if_fxx_data.c	RCS: 1.1.17.2
/usr/sys/include/arch/alpha/hal/cpuconf.h  subset OSFBINCOM365 
CHECKSUM: 41873     14	RCSfile: cpuconf.h	RCS: 9.6
/usr/sys/include/dec/binlog/errlog.h    subset OSFBINCOM365 
CHECKSUM: 64342    206  RCSfile: errlog.h       RCS: 1.1.73.6
/usr/sys/include/io/cam/cam_disk.h      subset OSFBINCOM350
CHECKSUM: 62467     10  RCSfile: cam_disk.h     RCS: 1.1.39.3
/usr/sys/include/io/cam/sim.h		subset OSFBINCOM365
CHECKSUM: 60074     33     RCS: sim.h      Revision: 1.1.45.2
/usr/sys/include/io/cam/qlogic/isp1020.h   subset OSFBINCOM365
CHECKSUM: 02353     43	RCSfile: isp1020.h	RCS: 1.1.59.3
/usr/sys/include/io/common/devio.h  	subset OSFBINCOM350
CHECKSUM: 63782     29	RCSfile: devio.h	RCS: 1.1.35.2
/usr/sys/include/io/dec/eisa/re.h       subset OSFBINCOM350 
CHECKSUM: 59532     13  RCSfile: re.h		RCS: 1.1.17.2
/usr/sys/include/io/dec/eisa/xcr_port.h subset OSFBINCOM350 
CHECKSUM: 03812     14  RCSfile: xcr_port.h     RCS: 1.1.21.2
/usr/sys/include/io/dec/netif/if_pdqreg.h  subset OSFHWBINCOM350 
CHECKSUM: 20392     73	RCSfile: if_pdqreg.h	RCS: 1.1.32.2
/usr/sys/include/kern/ipc_tt.h          subset OSFBINCOM350 
CHECKSUM: 49527      3  RCSfile: ipc_tt.h     	RCS: 4.2.11.2
/usr/sys/include/kern/thread.h		subset OSFBINCOM350 
CHECKSUM: 05297     12	RCSfile: thread.h	RCS: 4.3.32.2
/usr/sys/include/procfs/procfs_l.h      subset OSFBINCOM350 
CHECKSUM: 44076      6	RCSfile: procfs_l.h	RCS: 1.1.33.2 
/usr/sys/include/sys/proc.h             subset OSFBINCOM350 
CHECKSUM: 58812     29  RCSfile: proc.h 	RCS: 4.3.65.2
/usr/sys/include/sys/siginfo.h          subset OSFBINCOM350
CHECKSUM: 50592     12	RCSfile: siginfo.h	RCS: 1.1.35.2
/usr/sys/include/sys/signal.h           subset OSFBINCOM350
CHECKSUM: 30207     21	RCSfile: signal.h	RCS: 4.3.55.2
/usr/sys/include/sys/time.h         	subset  OSFBINCOM365
CHECKSUM: 31501      8	RCSfile: time.h		RCS: 4.4.50.2
/usr/sys/include/vm/vm_anon.h           subset OSFBINCOM350 
CHECKSUM: 38788     13	RCSfile: vm_anon.h	RCS: 1.1.42.2
/usr/sys/include/vm/vpage.h		subset OSFBINCOM350 
CHECKSUM: 38661      4	RCSfile vpage.h		RCS: 1.1.11.2
/usr/sys/kern/lockinfo.c        	subset OSFBINCOM365 
CHECKSUM: 01441     34	RCSfile: lockinfo.c	RCS: 1.1.286.2
/usr/sys/procfs/procfs_subrs_stubs.c    subset OSFBINCOM350 
CHECKSUM: 31818      4	RCSfile: procfs_subrs_stubs.c  RCS: 1.1.13.2
/usr/sys/vfs/vfs_conf.c         	subset OSFBINCOM350 
CHECKSUM: 33615     10	RCSfile: vfs_conf.c	RCS: 4.2.47.2

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

SUPERSEDES PATCHES:	OSF365-350145 (124.00),  OSF365-350367 (290.00)

This patch updates the FDDI driver to include these fixes:

- Fixes a problem where after a hang the system crashes with the
  panic message: apecs_read_io_port. At that time, the only way
  to reboot the system is to switch it OFF then ON.

- Upgrade/Replacement for the "FTA" FDDI driver and fixes a DMA Error
  which can occur with the older driver.

- Major re-work of fta_reinitialize to fix stuck interface after halt. 

- Add code to display source and destination address on bad incoming packets 
  (CRC, Illegal length, etc.).

- Fixed the bumping of some DECnet counters so they could latch to their 
  max values.
PROBLEM:        (7LCB21814)		(Patch ID: OSF365-350145)
********
Update FDDI driver to include these fixes :

Major re-work of fta_reinitialize to fix stuck interface after halt.

Display source and destination address on bad incoming
packets (CRC, Illegal length, etc.).

Fixed up the bumping of some DECnet counters so they could latch to
their max values.


PROBLEM:        (749B23467/QAR 52293)   (Patch ID: OSF365-350367)
********
This patch is an upgrade/replacement for the "FTA" FDDI driver and fixes
a DMA Error which can occur with the older driver.

If it became necessary to back out a partially constructed frame from
the transmit queue, the older driver was unable to properly backed out
the frame before restarting.  This resulted in the following errors
being
logged to the /var/adm/messages file:

vmunix: fta0: Halted.
vmunix: fta0: Halt Reason: DMA Error
vmunix: fta0: Link Unavailable.
vmunix: fta0: Link Available.


PROBLEM:        (ZUO101163)     (Patch ID: OSF365-350419)
********
After a hang the system crashes with the panic:  apecs_read_io_port.

At that time, the only way to reboot the system is to switch it OFF then ON.


FILE(s):

/usr/sys/data/if_fta_data.c             subset OSFBINCOM350
CHECKSUM: 14908     21  RCSfile: if_fta_data.c	RCS: 1.1.49.3
/usr/sys/BINARY/if_fta.o                subset OSFHWBIN350
CHECKSUM: 61385     53  RCSfile: if_fta.c	RCS: 1.1.93.4

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

SUPERSEDES PATCHES:	 OSF365-350124 (116.00), OSF365-350177 (142.00),
			 OSF365-350234 (181.00) 

This patch corrects the following:

- A potential security vulnerability has been discovered in 'mountd', 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.

- 'mountd' dies without logging the event in the daemon.log file and there is 
  no core file.

- Fixed a memory leak in 'mountd' which could cause 'mountd' to run out of
  virtual memory and terminate without issuing any error messages.

- A potential security vulnerability has been discovered in 'mountd', where
  under certain circumstances users may gain unauthorized access.  Digital has
  corrected this potential vulnerability.
PROBLEM:        (DEKQ60096)             (Patch ID: OSF365-350124)
********
Fixed a memory leak in 'mountd' which could cause 'mountd' to run out of
virtual memory and terminate without issuing any error messages.

'mountd' had a memory leak.  The 'mountd' process virtual memory usage would
continue to increase until 'mountd' was unable to obtain any more and then
it would terminate without issuing any error messages.

The memory leak occurred each time 'mountd' processed the /etc/exports file.
The larger the exports file, the more memory was lost each time it was 
processed.


PROBLEM:	(CLD SSRT0379U/QAR 43739)	(Patch ID: OSF365-350177)
********
A potential security vulnerability has been discovered in 'mountd',
where under certain circumstances users may gain unauthorized access.
Digital has corrected this potential vulnerability.

Also add the -a option flag to request the addresses for the hostname
and verify that the name and address correspond.  This is similar to
the behavior of the rshd and rlogind daemons.


PROBLEM:        (HPXQ36487/QAR 45362)   (Patch ID: OSF365-350234)
********
'mountd' can die without logging the event in the daemon.log file and
without generating a core file.  This can occur if the following
conditions are true:

 o  The output from the "showmount -e host" command is greater than 4K
    bytes long.

 o  The "showmount -e host" command times out and issues the error:

        Can't do Exports rpc: RPC: Timed out

The 'showmount' command has a 25 second time out, plus the typical
showmount request returns in less than a second.  This problem has so
far only occurred when the NFS server is exporting a large number of
file systems hosted by a 3rd party product (where a large number was
greater than 100 of the 3rd party product's entries).

Another way to cause this problem is if the 'showmount' command is
aborted via Control-C before the NFS server can return the list of
exported file systems.

Other systems, such as PCs requesting a list of exported file systems,
could also cause this problem.


PROBLEM:        (SSRT0496U)     (Patch ID: OSF365-350420)
********
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.


FILE(s):

/usr/sbin/mountd 		subset OSFNFS350
CHECKSUM: 30219     56	 RCSfile: mountd.c   RCS: 4.2.35.5

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

SUPERSEDES PATCHES:     OSF365-350147 (126.00), OSF365-350174 (139.00)
			OSF365-350316 (230.00)

This patch corrects the following:

- Fixes the problem where applications running System V pseudoterminal
  slave pty can hang forever on open() system call.

- Fixes a problem that causes the system to "assert_wait" panic with streams 
  code on the stack.

- Fixes a problem on a system where the ntalk daemons are hung.

- The system becomes totally unresponsive every 2-5 days, not responding to 
  terminals, the system console, or to pings. Added FIONREAD support for
  compatiblity with BSD.
PROBLEM:    (FNO100055,MXOQ10017,MXOB10972,MXOB20803)  (Patch ID: OSF365-350147)
********
The system becomes totally unresponsive every 2-5 days,
not responding to terminals, to the system console, or to pings.

It would not show any messages on the console or in any log files.
The only way to recover was to reboot the system.

Before the system hung up, vmstat showed that the wired pages list kept growing.


PROBLEM:    (FNO100055,MXOQ10017,MXOB10972,MXOB20803)  (Patch ID: OSF365-350147)
********
There was no support for FIONREAD.


PROBLEM:	(HPAQ23547)	(Patch ID: OSF365-350174)
********
This patch fixes a problem on a system where the ntalk daemons are hung.
Once the system gets into this state, where the ntalk daemons are hung,
the user will not be able to kill these processes and the only way to get
rid of this process level hang is to reboot the system.
A typical stack trace for the hung process will show a
makealias() call in it, although, the rest of the stack trace
may have any number of different routines in it.


PROBLEM:	(HPAQ95241,QAR 50022)	(Patch ID: OSF365-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:        (QAR 52115)     (Patch ID: OSF365-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.


FILE(s):

/usr/sys/BINARY/pty.o           	subset OSFBIN350
CHECKSUM: 33875     95	RCSfile: pty.c   RCS: 1.1.53.5
/usr/sys/include/tty/pty.h              subset OSFBINCOM350
CHECKSUM: 13128     12	RCSfile: pty.h   RCS: 1.1.29.3

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

Fixes a problem the doconfig program hangs after being invoked by
the uuxqt program.
PROBLEM:        (QAR 53588)     (Patch ID: OSF365-350423)
********
This patch fixes a problem that causes the doconfig program to hang
when invoked by the uuxqt program.  When uuxqt invokes doconfig,
doconfig spawns a child process that should be terminated by a
SIGTERM signal.  Instead, the process ends up waiting on a SIGCHLD
which never occurs because the child process never acts on the SIGTERM.


FILE(s):

/usr/lib/uucp/uuxqt             subset OSFUUCP350
CHECKSUM: 29977    352  RCSfile: uuxqt.c  RCS: 4.3.6.3

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

SUPERSEDES PATCHES:	OSF365-350255-1 (198.01)

This patch corrects the following:

- Fixes a problem in which the 'date' command is unable to set
  the date to January 1, 1970 00:00:00 GMT or February 29, 2000.

- Enhancements to the date command for Year 2000 support.
PROBLEM:	(TKTQ22519, UVO104025. QAR 45258)  (Patch ID: OSF365-350255-1)
********

Identifying limitations of original date command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The date command was not able to accurately set the date past the year 1999.  

For example:

Display current date:
$ date
Tue Jul 16 11:01:50 EDT 1996

Attempt to set the date to 12:55 PM, January 1, 2000
$ date 0101125500
Thu Feb  7 19:24:02 EST 2036


Enhancements to the date command for Year 2000 support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The date command has been enhanced to support setting the system date
past the year 1999, providing customers with the ability to begin
testing their software for potential century rollover problems.  The
changes are outlined in the following sections.

Syntax

The following formats are valid for setting the system date
using the date command.

o Using the XPG4-UNIX format:

  date mmddHHMM[yy]

o Using one of three Digital formats:

  date mmddHHMM[[cc]yy][.ss]
  date [[cc]yy]mmddHHMM[.ss]
  date mmddHHMM[.ss[[cc]yy]]

The following definitions apply:

mm   is the month number
dd   is the number of the day in the month
HH   is the hour in the day
MM   is the number of minutes
ss   is the number of seconds
yy   is the last two digits of the year
cc   is the first two digits of the year

Note: that the LC_TIME variable, if it is defined, controls the
      ordering of the day (dd) and month (mm) numbers in these formats.  
      The default order is the month (mm) followed by the day (dd).

o Optional Century [cc] Input

Each of the Digital formats for the date command allow the
optional input of the century (first two digits of the year).
This century field is optional to ensure that input formats
previously accepted by the date command are still supported.

Currently, the XPG4-UNIX format mmddHHMM[yy] does not have a
century field.  This is consistent with current X/Open
specifications regarding the date command.  The century field
will be added to this format in a future release of Digital
UNIX once this new field is officially supported in future
revisions of X/Open's UNIX specification.

o Handling of Two-Digit Year Input

When the year is specified by using two digits (as in the
XPG4-UNIX format or when the [cc] field is omitted from the
Digital formats), the century is determined in the following
manner: if the specified two-digit year is between 69 and 99
inclusive, the 20th century is assumed (that is, 19yy),
otherwise the 21st century is assumed (that is, 20yy).

The algorithm above is consistent with current drafts of
forthcoming X/Open UNIX specifications regarding two-digit
year handling in various system interfaces and commands,
including the date command.  This algorithm is based on the
standard UNIX epoch (12:00:00 AM Jan 1, 1970 UTC), minus one
year to account for different time zones.  Internal UNIX time
handling is based on the number of seconds since this epoch.

o Handling of Ambiguous Input

If the input string is ambiguous, that is, if the format
cannot be conclusively determined from the data, the date
command will issue a warning to STDERR and assume the
mmddHHMM[[cc]yy][.ss] format.  To avoid ambiguous input, use
one of the three Digital formats and specify the [cc] field.

Examples

To set the date to 09:34:00 AM Jan 7, 2000:

Using the mmddHHMM[yy] XPG4-UNIX format:

# date 0107093400

Using the mmddHHMM[[cc]yy][.ss] Digital format:

# date 010709342000
# date 0107093400.00
# date 010709342000.00

Using the [[cc]yy]mmddHHMM[.ss] Digital format:

# date 0001070934
# date 200001070934
# date 200001070934.00

Using the mmddHHMM[.ss[[cc]yy]] Digital format:

# date 01070934.0000
# date 01070934.002000

An example of ambiguous input:

# date 0101010000

This input could be recognized as one of the following formats:

mmddHHMM[[cc]yy][.ss]   meaning 01:00:00 AM Jan 1, 2000
[[cc]yy]mmddHHMM[.ss]   meaning 12:00:00 AM Jan 1, 2001

In this case, the date command will display a warning and
assume the mmddHHMM[[cc]yy][.ss] format, setting the date to
01:00:00 AM Jan 1, 2000.


PROBLEM:        (QAR 50276, QAR 53348)  (Patch ID: OSF365-350431)
********
This patch fixes a problem in which the 'date' command is unable to
set the date to January 1, 1970 00:00:00 GMT or February 29, 2000.

To reproduce the problem, do the following:

root# TZ=:GMT ; export TZ
root# date 01010000.0070


FILE(s):

/usr/lib/nls/msg/en_US.ISO8859-1/date.cat	subset OSFBASE350
CHECKSUM: 30685      1
/usr/bin/date			subset OSFBASE350
CHECKSUM: 17478     24	RCSfile: date.c   RCS: 4.2.33.3
/sbin/date			subset OSFBASE350
CHECKSUM: 42606    288	RCSfile: date.c   RCS: 4.2.33.3

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

SUPERSEDES PATCHES:     OSF365-360027 (62.00),   OSF365-360033 (67.00),
			OSF365-360033-1 (67.01), OSF365-350203 (161.00),  
			OSF365-033 (33.00),      OSF365-044-1 (44.01),
			OSF365-065 (334.00)

This patch corrects the following:

- 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.

- Fixes a problem that occurs when running STREAMS.  The system panics
  with a kernel memory fault in either osr_run() or osr_reopen().

- 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.

- fixes a kernel memory fault panic 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.

- Fixes panic in STREAMS code which is associated with high login/logout rates.

- Fixes panic "simple_lock_time_violation".

- The system panics with "kernel memory fault".  The crash dump will show 
  that the fault came from malloc or spec_reclaim.

- A process can hang and a "kill -9" command will not kill it.
PROBLEM:	(HGOQ80223 40742 42496 40255)	(Patch ID: OSF365-360027)
********
A process can hang and a "kill -9" command will not kill it.
The ps command will show the status of the process as "U".
This is a rare problem that is due to a file system timing problem
which occurs during an internal sync and is difficult to reproduce.
Running dbx on the hung thread will show getnewvnode and ufs_fsync
on the stack.

A typical stack trace is:

>  0 thread_block()
        ["src/kernel/kern/sched_prim.c":1911, 0xfffffc000042aad4]
   1 ufs_fsync_set_wait_flag(ip = 0xfffffc0004aef8b0, dolock = 1)
        ["src/kernel/ufs/ufs_vnops.c":6149, 0xfffffc000027f868]
   2 ufs_fsync_int(vp = 0xfffffc00029e1200, fflags = 16384, start = 0, length =
      cred = 0xfffffc00028b2400, waitfor = 1)
        ["src/kernel/ufs/ufs_vnops.c":1935, 0xfffffc0000279078]
   3 ufs_fsync(vp = (nil), fflags = 0, cred = 0xfffffc00028b2400, waitfor = 1)
     ["src/kernel/ufs/ufs_vnops.c":2083, 0xfffffc00002792e4]
   4 getnewvnode(tag = VT_NON, vops = 0xfffffc000050c500,
         vpp = 0xffffffff86eb35a8)
        ["src/kernel/vfs/vfs_subr.c":1551, 0xfffffc000040a324]
   5 vdealloc()
        ["src/kernel/vfs/vfs_subr.c":1235, 0xfffffc0000409dd4]
   6 vrele(vp = 0xfffffc000040afb0)
        ["src/kernel/vfs/vfs_subr.c":2276, 0xfffffc000040afb4]
   7 vn_close(0xfffffc0003b85210, 0xfffffc0000dfd000, 0x1, 0xfffffc0000000000,
      0x100000000)
        ["src/kernel/vfs/vfs_vnops.c":1258, 0xfffffc0000299fd0]
   8 closef(0xfffffc00003e29a8, 0xffffffff86eb0000, 0xfffffc0003d88e80,
        0xffffffff86eb3768, 0xfffffc00028b2400)
        ["src/kernel/bsd/kern_descrip.c":1393, 0xfffffc00003e34d0]
   9 close(0xfffffc0003b85210, 0xffffffff86eb38c8, 0xffffffff86eb38b8, 0x1, 0x0
     ["src/kernel/bsd/kern_descrip.c":1071, 0xfffffc00003e29a4]
  10 syscall(0x3, 0x1400009e0, 0x14016d4c0, 0x0, 0x6)
        ["src/kernel/arch/alpha/syscall_trap.c":519, 0xfffffc0000445454]
  11 _Xsyscall(0x8, 0x12002bba8, 0x140016760, 0x8, 0x4a008)
        ["src/kernel/arch/alpha/locore.s":1094, 0xfffffc0000434bd4]


PROBLEM:	(QCABLR030 TKTB27949 35661)	(Patch ID: OSF365-360027)
********
The system panics with "kernel memory fault".  The crash dump will show that
the fault came from malloc or spec_reclaim.

In the case of malloc, a message similar to the following will be printed:
trap: invalid memory read access from kernel mode

    faulting virtual address:     0x0000000000453940
    pc of faulting instruction:   0xfffffc000042ee08
    ra contents at time of fault: 0xfffffc000042edec
    sp contents at time of fault: 0xffffffffd1ed28b8

The crucial data is the faulting address with 32 high bits of zero,
and 32 low bits of non-zero.

The following is an example of a kernel memory fault panic
coming from malloc:

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1620 ]
   1 panic("kernel memory fault")
     ["../../../../src/kernel/bsd/subr_prf.c":752, ]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281, ]
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1296, ]
   4 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":520, ]
   5 _ms_malloc() ["../../../../src/kernel/msfs/bs/ms_mode.c":144, ]
   ...

The following is an example of a kernel memory fault panic
coming from malloc:

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1499, ]
   1 panic("kernel memory fault")
     ["../../../../src/kernel/bsd/subr_prf.c":752, ]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1262, ]
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1256, ]
   4 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":430, ]
   5 initnewvnode() ["../../../../src/kernel/vfs/vfs_subr.c":1117, ]
   6 getnewvnode() ["../../../../src/kernel/vfs/vfs_subr.c":1642, ]
   ...

The following is an example of a kernel memory fault panic
coming from spec_reclaim:

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2023, ]
   1 panic("kernel memory fault")
     ["../../../../src/kernel/bsd/subr_prf.c": 757, ]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1335, ]
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1311, ]
   4 spec_reclaim() ["../../../../src/kernel/vfs/spec_vnops.c":1165, ]
   5 msfsspec_reclaim() ["../../../../src/kernel/msfs/osf/msfs_vnops.c":4254, ]
 ...


PROBLEM: (HPAQ316C8 KAOB19A78 UVO104061 44625 44374) (Patch ID: OSF365-360033-1)
********
This patch fixes a system panic "simple_lock_time_violation" where the
O/S lock routine is called by event_post().  The clearalias() routine
will be part of the stack trace involved.  A stack trace might look
as follows:

   panic
   simple_lock_fault
   simple_lock_time_violation
   event_post
   select_wakeup
   pse_close
   speclose
   clearalias
   exit
   psig
   syscall
   _Xsyscall

This problem could also show up as a kernel memory fault panic.


PROBLEM:	(QAR 36390, QAR 31822)		(Patch ID: OSF365-350203)
********
Fixes panic in STREAMS code which is associated with high login/logout rates.

If running in lockmode=4, the panic typically has the following
 stack footprints. 

If not running in lockmode=4, random corruption can result.


  11 panic(s = 0xfffffc00005f6050 = "simple_lock: uninitialized lock") ["../../../../src/kernel/bsd/subr_prf.c":757, 0xfffffc000043fa04]
  12 simple_lock_fault(slp = 0xffffffffa46bf9c0, state = 18446744071591729728, caller = 0xfffffc0000353b64, arg = (nil), fmt = (nil), error = 0xfffffc00005f605 = "simple_lock: uninitialized lock") ["../../../../src/kernel/kern/lock.c":160 , 0xfffffc000046f2ec]
  13 simple_lock_valid_violation(slp = 0xfffffc0000353b64, state = 0, caller = nil)) ["../../../../src/kernel/kern/lock.c":1627, 0xfffffc000046f378]
  14 osr_free(osr = 0xffffffffa46bf8f8) ["../../../../src/kernel/streams/str_sc lls.c":227, 0xfffffc0000353b64]
  15 pse_ioctl(dev = 6291459, cmd = 536892174, data = (nil), fflag = 0, cred = xffffffff81a56e10, private = 0xffffffffa46bf800, retval = 0xffffffffb59636e0) [../../../../src/kernel/streams/str_scalls.c":2157, 0xfffffc0000357324]
  16 spec_ioctl(0xffffffffa4a5c000, 0x2000530e, 0x0, 0x0, 0xffffffff81a56e10) [../../../../src/kernel/vfs/spec_vnops.c":1871, 0xfffffc000044b7e0]
  17 stat1(0xffffffff826fa210, 0xffffffffb59638c8, 0xffffffffb59638b8, 0xffffff fb59638c8, 0xfffffc00004ebb38) ["../../../../src/kernel/vfs/vfs_syscalls.c":233, 0xfffffc0000456c50]
  18 stat(0xffffffffb59638b8, 0xffffffffb59638c8, 0xfffffc00004ebb38, 0xfffffc0004ececc, 0xfffffc00004eb61c) ["../../../../src/kernel/vfs/vfs_syscalls.c":2297 0xfffffc0000456b3c]
  19 syscall(0x3, 0x2000, 0x7af8, 0x41, 0x43) ["../../../../src/kernel/arch/alpa/syscall_trap.c":530, 0xfffffc00004eb618]
  20 _Xsyscall(0x8, 0x120022b18, 0x140011cb0, 0x1400799d4, 0x11ffffcc8) ["../../../../src/kernel/arch/alpha/locore.s":1086, 0xfffffc00004dbd64]

		____or____

   5 panic(s = 0xfffffc000061b3b0 = "simple_lock: uninitialized lock") ["../../
   6 simple_lock_fault(slp = 0xffffffff8fb89878, state = 18446739675670743232, 
   7 simple_lock_valid_violation(slp = 0xfffffc0000359888, state = 0, caller = 
   8 osr_run(osr = 0xffffffff8fb89800) ["../../../../src/kernel/streams/str_syn
   9 pse_ioctl(dev = 6291459, cmd = 536892174, data = (nil), fflag = 0, cred = 
  10 spec_ioctl(0xffffffff8fa92400, 0x2000530e, 0x0, 0x0, 0xffffffff819f1130) [
  11 stat1(0xffffffff81abe210, 0xffffffff95a3f8c8, 0xffffffff95a3f8b8, 0xffffff
  12 stat(0xffffffff95a3f8b8, 0xffffffff95a3f8c8, 0xfffffc00004ebcc8, 0x2000000
  13 syscall(0x140056000, 0x1, 0x1, 0x21, 0x43) ["../../../../src/kernel/arch/a
  14 _Xsyscall(0x8, 0x3ff800e5d38, 0x14000ba10, 0x140055934, 0x11ffffa68) ["../


PROBLEM:        (HPAQ68777)     (Patch ID: OSF365-033)
********
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: OSF365-044-1)
********
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: OSF365-065)
********
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: OSF365-065)
********
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: OSF365-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


FILE(s):

/usr/sys/BINARY/spec_vnops.o            subset OSFBIN365
CHECKSUM: 05280     36  RCSfile: spec_vnops.c  RCS: 4.4.112.4
/usr/sys/BINARY/str_runq.o              subset OSFBIN350
CHECKSUM: 04478     64  RCSfile: str_runq.c     RCS: 4.2.24.2
/usr/sys/BINARY/str_scalls.o            subset OSFBIN365
CHECKSUM: 29507     94  RCSfile: str_scalls.c   RCS: 4.2.97.4
/usr/sys/BINARY/ufs_inode.o 		subset OSFBIN365
CHECKSUM: 34306     86	RCSfile: ufs_inode.c	RCS: 4.3.75.2
/usr/sys/BINARY/vfs_subr.o 		subset OSFBIN365
CHECKSUM: 42470     81	RCSfile: vfs_subr.c	RCS: 4.3.110.3
/usr/sys/include/streams/str_stream.h   subset OSFBINCOM350
CHECKSUM: 60848     19	RCSfile: str_stream.h   RCS: 4.2.40.3

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

SUPERSEDES PATCHES:	OSF365-350086 (100.00), OSF365-350120 (244.00),
			OSF365-350168 (135.00), OSF365-360049 (74.00),
			OSF365-360073 (91.00),  OSF365-350337 (275.00)

This patch corrects the following:

- Fixes the following linker problems:
   o Hidden/export symbol wildcard problem
   o Assert getting generated with R_GPVALUE relocations
   o improper Text segment alignment processing
   o internal memory managment problem processing c++ program

- A problem where use of "ld -r" will change symbol preemption behavior.

- Changes how the linker handles permission problems with chmod(), corrects an 
  internal linker hang, and removes an unnecessary data segment boundary check 
  for OMAGIC (impure) object files.

- Linker hangs (fails to complete execution).
PROBLEM:	(Patch ID: OSF365-350086)           (CLD MGO101594/Qar 37210)
********
Putting a cobol object file in a shared library, and linking
an exe aginst that lib results in unexpected behaviour at run-time.

It will now be allowable to have _cobol_main in shared libs as well as the 
call shared  executable.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 29936 )
********
Internal check for object file consistency with a .dynrel and .text interaction
triggered a confusing assertion.
  
The ld assertion has been replaced by a more understandable error msg.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 28274)
********
Eliminated warnings about non-quickstart due to shared library mismatches.  
This warning was deemed too confusing to be emitted by default (especially 
since it is emitted for links of all Fortran, C++, Ada, and Pascal programs).


PROBLEM:        (Patch ID: OSF365-350086)           (CLD UVO103186/QAR 34454)
********
ld crashes with too many GOT entries. The problem occured when there was 
exactly 8190 symbols going into a GOT. If you have 8189 symbols--it will work.  
If you had 8191 symbols trying to be referenced through the GOT--it will also 
work.


PROBLEM:        (Patch ID: OSF365-350086)           (CLD HPXQ75BA6/QAR 35309)
********
ld would core dump when an object file had a bad auxiliary table. 

An assertion was added to ld so it will catch these files.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 33840)
********
ld would core dump -  an internal switch case entry was missing a break for 
some basic type processing.

Missing break statement added.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 28322)
********
ld would core dump when linking a large application.

The hash table scheme for internal file processing had a problem when it 
hashed more than 32K files to the same bucket.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 29272)
********
ld did not handle the case of an archive with no archive header
  
ld now issues a warning.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 37709)
********
linked program would core dump when profiling.

ld was incorrectly marking routines.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 30551)
********
Put checks in to not core dump with bad objects.

   
PROBLEM:        (Patch ID: OSF365-350086)           (QAR 33413)
********
When ld parses -static it didn't do enough error checking to insure its
meaningful to have -static.  A user used -static when they meant -non_shared


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 28452)
********
The strip utility would strip an object with relocations without diagnosing
that fact.  This was due to ld -r setting F_EXEC under certain conditions.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 29519)
********
ld core dumping.

This internal logic problem was due to a special case with an external symbol 
not getting matched up with object file (pmext with a pobj).  Special case
logic was added.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 36744)
********
ld was in an infinte loop due to a bad object file.

Logic was added to Avoid getting stuck in a loop if stBlock symbols are invalid 
in the local  symbol  table.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 37849)
********
ld was changed to allow cross mode to read compressed objects.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 30052)
********
ld outputs erroneous warning messages about exception info when linking modules
with no text region.

  
PROBLEM:        (Patch ID: OSF365-350086)           (QAR 37062)
********
ld generated an assertion in get_ext_map().

This problem appears to be the result of other problems occuring in the
linker prior to the compact relocation code.  The linker is generating
a relocatable image (preserving and updating relocation records), yet
it has not set "relocatable=1" internally.  Thus, we attempt to generate
compact relocation and also preserve regular relocations.  This causes
the problem in the compact code.

The solution was not to adjust relocation record that are relative to undefined
symbols unless we are creating a relocatable image. The compactcode expect
unadjusted relocation records

   
PROBLEM:        (Patch ID: OSF365-350086)           (QAR 30295)
********
Internal ld problem in not properly handling  multiple GPRELLOW relocations
for a single GPHIGH.


PROBLEM:        (Patch ID: OSF365-350086)           (CLD MGO101520/ QAR 37272)
********
ld should call msync before exiting.

Add msync system call in close_output() and have it called only when mmap'ing 
(ie, fix cross mode linker). This is to avoid having the data sit around in the 
ubc for an indefinite period of time.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 35624)
********
ld isnt checking return code from close().

Add code to check the return code from close(), since we cannot detect physical device
write failures when doing mmap'd output, we ought to allow for the fact close() 
may return an error code.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 21873 CL)
********
`ld -m` does not print the map for all sections.

Improved ld's output of its section mapping. 


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 26939)
********
The _edata program location is being set incorrectly.

The _edata program location, documented in the end(3) man page, was being
set incorrectly in an executable built non-shared.  It's address should
be greater than or equal to the address of _fdata and less than or equal
to the address of _fbss. 


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 27810)
********
Ld -hidden fails to hide symbol 

Problem corrected.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 29264)
********
No method to select stat libs when stat and shared libs installed on same dir.

This was added for MicroFocus Cobol  in Platinum Pre-BL7
he new ld options "-no_so" and "-so_archive" have been
added to ld in Platinum pre-bl7.  The -Bstatic and -Bdynamic
options described in the problem statement can be mapped
respectively to -no_so and -so_archive. (Fixed in pre-bl7.)


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 30520)
********
"-taso -shared" can core dump linker.

The problem is in relocate.c in the processing of R_REFLONG.
In the -taso code it dereferences an uninitialized 'pmext'when the relocation is 
local.
  
A fix for the problem has been submitted to Platinum.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 31941)
********
ld causes an initialization order problem for DEC C++ programs
linked -non_shared.  Unlike with -call_shared programs, ld calls __init...
routines in the order that they are found on the ld command line.

DEC C++ constructs static objects by generating __init routines.  The generated
__init routines in the user's code can legally reference static objects [which
have __init routines] in the C++ class library (libcxx.a).  Unfortunately,
since user's .o files appear on the command line before libcxx.a, the user's
__init routines are invoked before the class library __init routines.  Thus
the user's __init routine will reference the class library before the latter ha
been initialized.

To get around this problem, DEC C++ declares a static object in each class
library header file.  The static object's constructor calls a routine that
initializes the class library.  Unfortunately, doing this requires that a call
to the initialization routine be made by every module that includes the header
file.  For large programs, this can result in thousands of unnecessary calls an
significant performance degradation at image startup.

A better solution would be if ld could somehow ensure that the class library's
objects were constructed before the user's objects. 


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 32610)
********
(ld) shared library -init option problem on osf/1 v3.0.

Core dump occurred for external init routine when linking with -no_excpt.

init and fini routines could be located in a shared library and
invoked by the main executable's init driver.  I don't believe we
planned for this to work since the init driver must be able to
pc-relative jumps to the init routines, and a pc-relative jump has
only a 23-bit signed displacement.

Since the symbols being called are not defined in the executable, ld
satisfies the references in the init driver using stubs.  A stub is a
small code sequence that loads a symbol index and calls the loader to
resolve it.  The stub *is* local to the executable, which means that
the pc-relative jump can be made without a problem.

Since we never considered the possibility that stubs would be called
from init drivers, the init and fini drivers are invoked with the
loader's GP as its initial GP value.  As inits and finis are called,
they load their own GP value.  Stubs, on the other hand, need to have
a valid GP value from which to load a GOT(0) value, this is the
address of the loader's lazy_text_resolve() routine.  Any valid GP
will do, except for the loader's.  After the first init routine has
been called, the GP value will be valid.

In this problem test case, the first init called is a stub'ed routine.
Normally, the exception handling init routines are first, but
the -no_excpt linker switch causes them not to be linked in.

This problem has been fixed by establishing an initial GP value
for the init and fini driver routines. 


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 32881)
********
Decc++ needs to allow to build modules from last linked to 1st linked.

The customer requests this option so that software which they have
developed on a Sun which initializes in reverse module order can be
efficiently ported to Alpha/OSF.

To force init routines to run in reverse link order an option has been added - 
you can now use the "-reverse_init_order" linker option.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 33972)
********
Linker produces shared libraries with a bad gp_value entry.

On Digital UNIX (DEC OSF/1) V3.2 and T3.4-1, the linker can be made
to produce shared libraries with a bad (NULL) entry for gp_value.
Whether or not this occurs depends on the order of the link options.
This doesn't seem to effect the operation of the libraries, but
it causes ATOM to fail.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 34742)
********
Bad ld optimization at -o2 for alternate entries.

The problem is that linking -O2 will remove the load of $27
incorrectly when the destination is to an alternate entry point with
the same address as the main entry point. 


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 34923)
********
-X option in the linker strips away language information.

The -x option in the linker strips away language information,
making debugging problematic even with the symbols that remain.  There
can be considerable debugging done with -x level information, provided
the language is available. 


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 35460)
********
Ld does not relocate values of symbols.
 
ld does not relocate values of symbols whose symbol type and symbol class are 
 (stSplit,scText).


PROBLEM:        (Patch ID: OSF365-350086)           (CLD USG-02631/QAR 35475)
********
linker gives 'Internal error in /bin/ld: bad index in get_extmap()'.

Fixed in platinum.
    

PROBLEM:        (Patch ID: OSF365-350086)           (QAR 36631)
********
ld problem with _edata if linking f77 produced .o file.

The _edata program location, documented in the end(3) man page, was being
set incorrectly in an executable built non-shared.  It's address should
be greater than or equal to the address of _fdata and less than or equal
to the address of _fbss. 
duplicate of 26939


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 36793)
********
A shared library built with -check_registry so_locations may dump core
accessing .rdata symbols.  If the shared library grows too big for
it's text to fit in the slot allocated for it in an so_locations file,
ld will move the text of the library to the next available text slot.
It then corrects all the text symbol addresses by adding the
difference of the reserved text slot and the newly allocated text
slot.  The difference is also added to .rdata symbols, but .rdata
symbols are in data not text, so the resulting addresses are invalid.
(Fixed in Platinum BL8.)


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 36794)
********
Strong symbol not preempted when ref'd by weak counterpart.

A simple test case will show that when a strong symbol is referenced
via its weak counterpart the reference cannot be preempted by another
instance of the strong symbol.  This problem only occurs when the
executable and it's shared library dependencies are quickstarted.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 37003)
********
Linker produces bad symtab with -x and -r.

The problem occurs when you compile an application with either -g1 or
-g2 and then link the resulting objects with -r and -x.  The result is
that the procedure table's 'isym' and 'adr' fields are set incorrectly.
This causes problems with tools that consume these broken symbol tables.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 21873)
********
`LD -M` does not print the map for all sections.

This link fails with the error message shown above and no output file
is produced.  There is obviously an assumption in the implementation
of the -m option that the .rdata section always exists.


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 37279)
********
'ld -m fails' when output file has no .rdata section.

This link fails with the error message shown above and no output file
is produced.  There is obviously an assumption in the implementation
of the -m option that the .rdata section always exists. 

a duplicate of QAR 21873


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 38021)
********
Cannot link with stripped shared libraries.

duplicate of 38054


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 38040)
********
ld error -- bad isym in proc table.

The problem occurs when you compile an application with either -g1 or
-g2 and then link the resulting objects with -r and -x.  The result is
that the procedure table's 'isym' and 'adr' fields are set incorrectly.
This causes problems with tools that consume these broken symbol tables.
Duplicate of 37003


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 38054)
********
Cannot link with stripped shared libraries

Duplicate of 38021


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 38063)
********
proc table incorrect for simple c++ program

Duplicate of 37003


PROBLEM:        (Patch ID: OSF365-350086)           (QAR 38334)
********
cant link stripped libs

Duplicate of 38054


PROBLEM:	(QAR #44310)		(Patch ID: OSF365-350168)
********
A call-shared application which overloads a shared library procedure
with an additional implementation of the procedure in the main
executable can "Segmentation fault". The problem may be sensitive to
link order. Linking non-shared should cause the problem to go away. One
may be able to determine that the gp register is incorrectly set.

This problem results from the linker incorrectly determining
that the gp prologue can be "optimized away". You can not work
around this problem by linking debug.

The patched linker correctly determines when this optimization can
be applied. If an application does have this problem, you must install
this patch and re-link to correct the problem.

This problem has proven to be extremely rare.


PROBLEM:	(qar 42274)	(Patch ID: OSF365-360049)
********
Link times increases exponentially when using ld's -hidden option.


PROBLEM:	(qar 43546)	(Patch ID: OSF365-360049)
********
The linker is extremely slow when linking against a large number of .so
 (shared library) files.


PROBLEM:        (QAR 47588)	(Patch ID: OSF365-360073)
********
Linker executes an error exit with chmod() permission problems and certain
data-segment alignments for OMAGIC files.


PROBLEM:        (QAR 48365)	(Patch ID: OSF365-360073)
********
Linker hangs (fails to complete execution).


PROBLEM:	(UVO102899,HPXQ55AE4,qar 43081)  (Patch ID: OSF365-350120)
********
When running a link involving a large number of input objects on a small
memory system, the usability of the system may be impacted by the link
operation.  

This patch makes available the "-nommap" switch to reduce the amount of 
page faults incurred by ld.  The -nommap switch may be used on the cc 
command line, an ld command line or placed in /usr/ccs/lib/cmplrs/comp.config. 
Placing it in comp.config, of course, causes the option to be used on all 
link operations performed on a system.


PROBLEM:        (qar 49301)	(Patch ID: OSF365-350337)
********
This patch fixes a problem where use of "ld -r ..." will change symbol
preemption behavior.  Without this patch, some global relocations can be
converted to locals as an optimization. These locals cannot be preempted.

An undocumented linker option has been added in the patched linker to prevent
this conversion.  This new switch is "ld -no_local_conversion ..."


PROBLEM:        (QAR 53151)     (Patch ID: OSF365-350443)
********
At link-time the linker issues an ASSERT statement from within the
module relocate.c.  This will only be observed for very large applications
that build a final image based on previously linked  'ld -r' object files.

assertion failed: EX at ../../../../../../src/usr/ccs/bin/ld/relocate.c line 2471


PROBLEM:        (QAR 55440)     (Patch ID: OSF365-350443)
********
Hidden/Export Symbol wildcard problem:

A regression was introduced into the linker when -hidden symbol
processing was scaled up to use a hash table.  The wildcard capability
with the "exported_symbol" option was completely lost.  This fix
makes wildcards functional for hidden/export symbols.

An example of wildcard usage that was no longer functional is:

  ld -o libf.so -shared -all -hidden  -exported_symbol 'X500*'  file.o -lc

Any symbol beginning with X500 should be "GLOBAL" not "LOCAL".
To check if a symbol is global use the following odump command
on the library that is produced by  the linker:

  odump -Dt libf.so

Shows the symbol being GLOBAL or LOCAL


PROBLEM:        (QAR 54224)     (Patch ID: OSF365-350443)
********
The linker was improperly rounding -T values to 64K increments even when
linking OMAGIC files, which do not have the same rounding requirements.
It turns out that the check being made in the ld.c was already being
done in layout, so all we really need to do is to remove the bogus check
in ld.c


PROBLEM:        (QAR 55693)     (Patch ID: OSF365-350443)
********
The linker fails to link a c++ program issuing an "ld_munmap error" message.


FILE(s):

/usr/ccs/lib/cmplrs/cc/ld       subset OSFBASE365
CHECKSUM: 61501    792  RCSfile: ld.c           RCS: 4.3.74.7
                        RCSfile: uldgnum.c      RCS: 1.1.13.2
                        RCSfile: ldgetname.c    RCS: 4.3.5.2
                        RCSfile: ldr_atexit.c   RCS: 4.2.9.2
                        RCSfile: ldr_dummy2.c   RCS: 4.2.10.2
                        RCSfile: ldr_status.c   RCS: 4.2.8.3

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

SUPERSEDES PATCHES:	OSF365-350288 (212.00)

This patch corrects the following:

- Fixes a memory leak problem using the STREAMS Data Link Bridge (dlb)
  pseudodevice driver and could cause a "freeing free mbuf" panic
  when system memory is exhausted.

- This patch corrects a problem with packets out of order experienced by
  some PATHWORKS Netbuei clients.
PROBLEM:	(QAR 47254  CLD HPXQ77186)	(Patch ID: OSF365-350288)
********
Ordering is not currently guaranteed by the streams infrastructure which can 
cause some packets to be delivered out of order.  This causes a problem with 
the Netbeui streams stack, which requires that streams packets be delivered 
in order.


PROBLEM:        (QAR 48892, 49073)      (Patch ID: OSF365-350445)
********
This patch fixes a memory leak problem that occurs with the STREAMS
Data Link Bridge (dlb) pseudodevice driver.  This problem could
cause a "freeing free mbuf" panic when system memory is exhausted.


FILE(s):

/usr/sys/BINARY/dlb.o		subset OSFBIN350
CHECKSUM: 12465    116	RCSfile: dlb.c   RCS: 1.1.22.3

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

SUPERSEDES PATCHES:     OSF365-350080 (99.00),   OSF365-350108 (109.00),
                        OSF365-350128 (117.00),  OSF365-350133 (118.00),
                        OSF365-360019 (57.00),   OSF365-350153 (129.00),
                        OSF365-350154 (130.00),  OSF365-350217 (169.00),
                        OSF365-350222 (172.00),  OSF365-350236 (182.00),
                        OSF365-350253 (196.00),  OSF365-350279 (253.00),
                        OSF365-360053 (78.00),   OSF365-360082 (271.00),
			OSF365-360082-1 (340.00), OSF365-350412 (282.00)

This patch corrects the following:

- Fixes a problem where printing of a string with a specified precision
  could result in a segmentation fault.

- Fixes a TCP/IP problem that can occur with programs linked with
  the libc library. These programs may return a value of (-1)
  when calling the svc_tcp() function.

- Fixes a potential security vulnerability in BIND.

- /sbin/shutdown takes too long if there are many open LAT lines.

- 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.

- A problem that occurs after a user logs into a system with an SRV4-style LAT 
  device. When the ttyslot function is called, the system fails to find the 
  device and returns a value of zero, indicating an error in the ttyslot 
  function.

- Ensures that setlocale() does not call free() with a null pointer, which may 
  crash an application that uses a third-party malloc package.

- In some cases, sendmail generates a core dump when it receives an illegal
  command, after installing patch OSF365-350128. 

- A problem in the filename pattern-matching behavior of the find command when 
  it includes the "?" metacharacter. The bug actually resides in fnmatch(), 
  which is used by find.

- Back out sprintf "%s" performance changes to fix "%*.*f" bug. 

- Multi-threaded applications run on Digital UNIX V3.2[ABC] which use any of 
  the get*_r() functions may dump core or produce incorrect results.

- A potential security vulnerability has been discovered, where under certain 
  circumstances users may gain unauthorized access.  Digital has corrected this
  potential vulnerability.

- strncat() reads past end of source array

- Fixes multiple processes from adding duplicate ut_id lines in the utmp file
  with duplicate ut-id keys.

- Several errors in the syslog entry written by the su program.

- Fixes a problem with taso applications that set the malloc(3) __sbrk_override 
  and __taso_mode tuning parameters to true.  Under these circumstances, 
  malloc(3) can return ENOMEM before all of the taso address space is allocated.

- Fixes a memory leak problem associated with the strxfrm() and wcsxfrm() 
  functions and some incorrect behavior in __do_replacement(), which is used 
  by both strxfrm() and strcoll().
PROBLEM:	(QARs - 35249,35258,35271,3527)	    (Patch ID: OSF365-350080)
******** 	(STLN62255,HPXQ56EAD,HPAQ6151D,HPXQ64859)

sprintf() can add one extra uninitialized character after "%*.*f" format 
strings if the precision is zero.  

One can work around this problem by initializing the sprintf() "buffer" 
with the NULL (\0) character before calling sprintf().

csh> cat test.c
 main()
 {
    double val = 1.1;
    int    fw = 5;    /* Width of field */
    int    dp = 0;    /* Decimal Places */
    char   buf[20];

    strcpy(buf, "XXXXXX");
    sprintf(buf, "%*.*f", fw, dp, val);
    puts(buf);
 }
csh>
csh> cc test.c
csh>
csh> a.out
     1X
csh>


PROBLEM:      	(QAR 40685)		(Patch ID: OSF365-350080)
********
A dataless system will hang when transitioning from single to
multi-user mode.


PROBLEM:	(QAR 41702)		(Patch ID: OSF365-350108)
********
The problem will show up only in code that is linked against, or
dlopen()'s libc_r and makes calls to functions whose names match
the pattern get*_r.

A program exhibiting this problem will often core-dump with a stack
trace which shows it was in one of the get*_r functions.


PROBLEM:        (SSRT0359X)             (Patch ID: OSF365-350128)
********
A potential security vulnerability has been discovered, where under
certain circumstances users may gain unauthorized access.

Digital has corrected this potential vulnerability.


PROBLEM:        (QAR 43844)             (Patch ID: OSF365-350133)
********
If the 2nd argument (source array) to strncat() points to a location
in memory where there is no null terminator between that location and
the 'n'th (3rd argument) subsequent byte and the memory immediately
following this 'n'th byte is not mapped, then the strncat() function may
fail with a SEGV.

$ cat foo.c
#include 
#include 
#include 
main()
{
   int len, i;
   char string1[10];
   char *p;
   char *startp;

   len = getpagesize();
   p = (char *) valloc(len*2);
   mprotect(p+len, len, PROT_NONE);

   p+=(len-5);
   startp=p;
   for(i=0;i<5;i++)
     *p++='a';

   string1[0]='\0';
   strncat(string1, startp, 5);
   printf("string1 = %s\n",string1);
}
$ cc foo.c
$ a.out
Memory fault(coredump)


PROBLEM:        (QAR 41329)             (Patch ID: OSF365-360019)
********
Fix multiple processes from adding duplicate ut_id lines in the utmp file
with duplicate ut-id keys.

This can occur on multi-processor systems when two or more users use
pututline() with the same ut_id.


PROBLEM:        (ZUO100558)		(Patch ID: OSF360-350153)
********
This patch fixes three problems:

            1)  Unsuccessful attempts to su to root were not recorded in
               syslog/auth.log.

            2)  Attempts to su to nonexistent user names were being
                recorded in syslog/auth.log.

            3)  The username recorded in syslog/auth.log was recorded as
               root rather than the users username.

        This patch applies to both base level and enhanced security.
        The error will appear differently depending on whether base
        or enhanced security has been selected.

        Beginning from a non-root account (Example: lclee)
          (1) su to root using an invalid password
          (2) su to a nonexistant account
          (3) su to root with the correct password

        Examine the file /var/adm/syslog.dated//auth.log
          tail /var/adm/syslog.dated//auth.log

        If the system is running BASE security and needs the patch
          (1) Mar  1 14:21:30 industrial su: BADSU lclee on /dev/ttyp0
          (2) Mar  1 14:23:58 industrial su: BADSU lclee on /dev/ttyp0
          (3) Mar  1 14:24:06 industrial su: SU lclee on /dev/ttyp0

        If the system is running ENHANCED security and needs the patch
          (1) no message
          (2) Mar  1 14:23:58 industrial su: BADSU root on /dev/ttyp0
          (3) Mar  1 14:24:06 industrial su: SU root on /dev/ttyp0

        If the system has the patch applied (base or enhanced)
          (1) Mar  1 14:22:43 industrial su: BADSU lclee on /dev/ttyp0
          (2) no message
          (3) Mar  1 14:24:06 industrial su: SU lclee on /dev/ttyp0


PROBLEM:	(QAR 43849, QAR 45014)		(Patch ID: OSF360-350154)
********
This patch fixes a problem with taso applications that set 
the malloc(3) __sbrk_override and __taso_mode tuning parameters 
to true.  Under these circumstances, malloc(3) can return ENOMEM
before all of the taso address space is allocated.

A brief description of the taso feature can be found in the cc(3) reference 
page where the -taso switch is documented.  The malloc(3) tuning parameters 
are documented on the malloc(3) reference page.


PROBLEM:	(CLD MGO102122, QAR 45686)	(Patch ID: OSF365-350217)
********
This patch fixes a memory leak problem that occurs when strxfrm() 
or wcsxfrm() executes in a locale that allows one character to 
substitute for another during collation. 

An example is the de_DE.ISO8859-1 locale, in which "ss" is equivalent to 
and may be substituted for the German sharp s. In such a locale, 
each invocation of strxfrm() or wcsfrm() causes some amount of heap memory 
to be leaked.  When you apply this patch, the memory leak no longer occurs.


PROBLEM:	(QAR 38929)			(Patch ID: OSF365-350217)
********
This patch also fixes some incorrect behavior in the __do_replacement() 
function, which is used by both strxfrm() and strcoll(). Before the fix, 
 __do_replacement() might use the same string pointer for the source 
and destination strings in the strcpy() function.  Results were unpredictable. 
In addition, __do_replacement() did not test the output buffer size to
determine if the resulting string would indeed fit in the output buffer. 


PROBLEM:	(QAR 45694)			(Patch ID: OSF365-350222)
********
This patch fixes a problem in the fnmatch() routine's single-byte 
and multibyte versions, which incorrectly match '?' to a null character.  
As a result, a filename pattern like "???" could match not only a filename 
containing "aaa", but also one containing "a" or "aa".  Because the find 
command uses fnmatch() for filename pattern matching, there is a chance that
data files may be removed unintentionally.  An example is as follows:

 % find . -name 'data???' -exec rm {} \;

This command could inadvertently remove files named "data1", "data10",  
and so forth.

NOTE: The problem fixed by this patch occurs only when you use locales 
      other than the default C locale.


PROBLEM:  ( HPAQ46E01 ) (Patch ID: OSF365-350236)
********
After patch OSF365-350128 was installed, sendmail would generate a
core dump with a segmentation fault.  The stripped sendmail does not
contain a symbol table so the core dump is hard to interpret.  To
determine whether this problem exists on your system, run the following
test: (1) On the system being tested, telnet to port 25.  (2) Enter
illegal commands and check whether sendmail generates a core dump.

       
PROBLEM:  (QAR 46198) (Patch ID: OSF365-350253)
********
The setlocale() function included in Digital UNIX releases earlier 
than Version 4.0 may sometimes pass a null pointer to the free() function. 
This is not harmful if site applications use the memory allocation package 
(malloc() and free() functions) bundled in the Digital UNIX C Library. 
However, if site applications use a locally developed memory allocation
package or one included as part of a layered product, passing a null pointer 
to free() may cause the applications to fail. To avoid this problem, 
this patch installs a version of setlocale() that checks a pointer 
for null before passing the pointer to free().


PROBLEM:	(BRO100738)	(Patch ID: OSF365-350279)
********
When testing applications on a BSD-style device such as /dev/tty0h, the
ttyslot function returns a number matching the index into the /var/adm/utmp
file.  However, when running the same program on an SVR4-style device such
as /dev/lat/622, the ttyslot function always returns zero.  The problem can
be indentified easily by running the sample test program included here.

Copy the following program to ttyslot_test.c:

#include 
#include 
#include 
#include 

main()
{
        printf("ttyslot() = %d\n", ttyslot());
        exit(1);
}

Error messages may vary, depending on which applications are being run.
When connected to a system over an SVR4-style LAT device the application
calls the ttyslot function to locate the entry in the /var/adm/utmp file.
The ttyslot function returns zero in error because it fails to match the
control terminal.  When you connect to a system over a LAT device and make
a ttyslot function call to locate the entry in the /var/adm/utmp file for
the control terminal of the current process, ttyslot() returns zero in
error because it fails to match the control terminal.


PROBLEM:	(CLD: USG-03550, QAR: 46537)	(Patch ID: OSF365-360053)
********
The problem occurs when a machine has a large number (hundreds) of 
"getty" processes running and executes a shutdown. The machine may take
excessively long to shut down (i.e. half an hour).


PROBLEM:        (CLD-00805)     (Patch ID: OSF365-360082-1)
********
A potential security vulnerability has been discovered in BIND
 (Domain Name Service), 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 53135, QAR 44398)  (Patch ID: OSF365-350412)
********
This patch fixes a TCP/IP problem that can occur with programs linked
with the libc library.  These programs may return a value of (-1)
when calling the svc_tcp() function.

This problem occurs because a return value, EINTR, is ignored in the
readtcp() and writetcp() functions.  The patch involved checking for
this return before continuing a readtcp() and writetcp().


PROBLEM:        (QAR 54708, CLD MCSM71N73)      (Patch ID: OSF365-350449)
********
The printing of a string with a specified precision could result
in a segmentation fault.

In this case, the C Standard does NOT require a NULL terminated input.


FILE(s):

/sbin/arp                               subset OSFCLINET350
CHECKSUM: 24414    272  RCSfile: arp.c          RCS: 4.2.7.4
/sbin/cfgmgr                            subset OSFBASE350
CHECKSUM: 28045    232
/sbin/init                              subset OSFBASE350
CHECKSUM: 47094    184
/sbin/mount                             subset OSFBASE350
CHECKSUM: 44012    384  RCSfile: mount.c        RCS: 4.3.40.2
                        RCSfile: mountxcdr.c    RCS: 1.1.2.4
                        RCSfile: mountxdr.c     RCS: 4.2.7.2
                        RCSfile: mountxdr_v3.c  RCS: 1.1.2.3
/sbin/route                             subset OSFCLINET350
CHECKSUM: 47173    296  RCSfile: route.c        RCS: 4.2.7.4
/sbin/shutdown                          subset OSFBASE350
CHECKSUM: 37753    312  RCSfile: shutdown.c     RCS: 4.3.31.2
/sbin/sysconfig                         subset OSFBASE350
CHECKSUM: 03182    288  RCSfile: sysconfig.c    RCS: 4.2.12.4
/sbin/sysconfigdb                       subset OSFBASE350
CHECKSUM: 15090    272  RCSfile: sysconfigdb.c  RCS: 4.2.12.7
/sbin/umount                            subset OSFBASE350
CHECKSUM: 16350    256  RCSfile: umount.c       RCS: 4.2.15.2
/usr/bin/nslookup                       subset OSFCLINET350
CHECKSUM: 38126    128
/usr/ccs/lib/libc.a                     subset OSFCMPLRS365
CHECKSUM: 10522   1649
/usr/ccs/lib/libc_r.a                   subset OSFPGMR365
CHECKSUM: 38549    953
/usr/lib/nls/msg/en_US.ISO8859-1/libc.cat       subset OSFBASE350
CHECKSUM: 31768     12
/usr/lib/nls/msg/en_US.ISO8859-1/nslookup.cat   subset OSFCLINET350
CHECKSUM: 61457      7
/usr/include/netdb.h                    subset OSFPGMR350
CHECKSUM: 03768      8  RCSfile: netdb.h        RCS: 4.2.27.2
/usr/include/resolv.h                   subset OSFPGMR350
CHECKSUM: 08628      7
/usr/include/arpa/nameser.h             subset OSFPGMR350
CHECKSUM: 13142     11
/usr/sbin/auditd                        subset OSFBASE350
CHECKSUM: 25073    336  RCSfile: auditd.c       RCS: 1.1.6.7
/usr/sbin/shutdown                      subset OSFBASE350
CHECKSUM: 07888     32  RCSfile: shutdown.c     RCS: 4.3.31.2
/usr/sbin/ypbind                        subset OSFCLINET350
CHECKSUM: 57711    256  RCSfile: ypbind.c       RCS: 4.2.16.2
/usr/shlib/libc.so                      subset OSFBASE350
CHECKSUM: 23972   1248
/usr/shlib/libc_r.so                    subset OSFBASE350
CHECKSUM: 31614    800

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

A filesystem cannot be unmounted and the system displays a "Device busy"
error message.
PROBLEM:    (CLD EVT102273,SPR VNO100100,QAR 55615)  (Patch ID: OSF365-350454)
********
This patch fixes a problem in which a filesystem cannot be unmounted.
The system displays a "Device busy" error message.


FILE(s):

/usr/sys/BINARY/vfs_flock.o             subset OSFBIN350
CHECKSUM: 07823    121  RCSfile: vfs_flock.c  RCS: 4.2.48.2

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

When called from an application, bookreader changes the caller's effective UID
to the real UID, but then never restores it to the original effective UID,
before returning control to the calling program.
PROBLEM:        (HPAQ214QG, QAR 44630)  (Patch ID: OSF365X-350037)
********
When using the Bookreader library, which is part of the DECwindows Motif
toolkit, from within an application, bookreader changes the caller's
effective UID to the real UID, but then never restores it to the
original effective UID, before returning control to the calling program.
If an application like dxchpwd is run from a non-root account, it fails
with a privilege violation.


FILE(s):

/usr/lib/libbkr.a               subset OSFXDEV365
CHECKSUM: 50822     38
/usr/shlib/libDXm.so            subset OSFX11365
CHECKSUM: 26011   1008
/usr/shlib/libbkr.so            subset OSFX11365
CHECKSUM: 40679     40

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

SUPERSEDES PATCHES:     OSF365X-350035 (298.00)

This patch corrects the following:

- Motif Text widget is afflicted with a memory leak.  A small amount
  of dynamic memory is lost each time the background colors in the widget
  are changed.

- Motif applications may abort when you use the drag-and-drop feature.
PROBLEM:        (USG-00572, QAR 51941)  (Patch ID: OSF365X-350035)
********
Motif applications may abort when you use the drag-and-drop feature.

Motif toolkit function XmCreateDragIcon() gets a "BadMatch (invalid
parameter attributes)" error and then crashes because the code fails
to set the correct image dimensions.


PROBLEM:        (HPXQ64591 and STLQ60109)       (Patch ID: OSF365X-350038)
********
The Motif Text widget is afflicted with a memory leak.  A small
amount of dynamic memory is lost each time the background colors
in the widget are changed.


FILE(s):

/usr/lib/libXm.a                subset OSFXDEV350
CHECKSUM: 25759   4306
/usr/shlib/libXm.so             subset OSFX11350
CHECKSUM: 65396   2440

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

SUPERSEDES PATCHES: 	OSF365-360005 (49.00),  OSF365-360013 (53.00),
			OSF365-360018 (56.00),  OSF365-350123 (115.00),
			OSF365-350163 (134.00), OSF365-360028 (63.00),
			OSF365-360030 (65.00),  OSF365-360041 (70.00),  
			OSF365-360051 (76.00),  OSF365-360061 (83.00), 
			OSF365-350232 (179.00), OSF365-360067 (87.00),  
			OSF365-360324 (235.00), OSF365-360031 (66.00),  
			OSF365-360071 (90.00),  OSF365-360088 (293.00) ,
			OSF365-360090 (295.00), OSF365-360105 (315.00),
			OSF365-360112 (361.00)

This patch corrects the following:

- Fixes a system panic when shutting down to single user mode using either
  one of the following commands when AdvFS is the root or usr filesystem:
     # shutdown now
     # init s

- Fixes system panic with the following error message:

   panic (cpu 0): kernel memory fault

- Fixes a problem with an NFS V3 mounted AdvFS file system
  where under heavy I/O load, data 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.

- Fixes system panic with the following error message:

        AdvFS exception Module=26 line=1483

- Fixes to prevent the following two panics:
   o AdvFS Exception  Module = 1, line = 1891
   o kernel memory fault

- Idle time is reset on broadcast message when AdvFS is the root file system.

- System panics with "kernel memory fault" in ubc_page_alloc().

- This patch fixes a system panic with the message "simple_lock: time limit
  exceeded".

- This patch fixes a problem that occurs with the telnet and ftp commands.
  Telnet or ftp processes that are no longer in use, are left on the system
  indefinitely.  When a user tries to log in, the login process hangs after 
  displaying the last login message.

- This patch fixes a problem in which a system using AdvFS can run out of
  metadata space when the AdvFS domain still has some free space available.
  The system will display error messages such as 'no space left on device'.
  The problem may occur on a heavily fragmented system with many small files,
  such as an Internet News server or Mail server.

- System panic with ADVFS EXCEPTION Module = 4, Line = 3541 "bs_unpinpg called
  with buffer not pinned"

- Advfs mmapped file data corruption when application fails to do msync().
  The corruption is seen after rebooting the system when file changes were made
  via mmap().  Port of v32csuppportos-94-amilicia.  Sreqeust is following 
  bsubmit due to special dispensation from the gods of the build to get the 
  bsubmit in before the build.

- Fixes a situation where an application that issues large read requests
  (each larger than 64 pages) can hang AdvFS or cause poor AdvFS performance.
  This patch fixes a problem in which an AdvFS system panics with the following
   message: "clear_buf: bufCnt = 0"

- Fixes kernel memory fault panic when mounting a crashed AdvFS file system

- Fix "kernel memory fault" or "ADVFS EXCEPTION panic string: N1= -1027" 
  panics during backup operations using AdvFS.

- System panics in AdvFS code when either:
   o ls command is run in the fileset mount directory (contains the .tags file)
   o msfsck is run at least twice and then the AdvFS fileset is unmounted

- This patch fixes a problem in which a system that was upgraded to Digital
  UNIX Version 3.2d1 and is running AdvFS, may not be able to mount its AdvFS
  multi- volume domain. Error messages will be displayed about incorrect sizes,
  volumes mounted read-only, or incorrect volume information.

- Fix for system panic "simple_lock_time_violation" with clearalias in stack 
  trace.

- This patch fixes a problem in which the getrusage system call returns zero for
  the values of ru_inblock and ru_outblock on an AdvFS file system.

- Fixes NFS rpc.lockd "can't clear lock after crash of client" when AdvFS is 
  being used.

- Fixes a problem in which an AdvFS system fails when attempting to create 
  greater than 764490 files in a directory.
PROBLEM:	(MCPMB3DC3)		(Patch ID: OSF365-360005)
********
System panic with ADVFS EXCEPTION Module = 4, Line = 3541

This panic translates to "bs_unpinpg called with buffer not pinned"

The reference count is at zero and should 1 or greater.  There was a hardware
error detected just before the panic which may have been part of the cause
but the ref count should not have been zero.

Stack Trace:

(dbx) t
>  0 boot(0x0, 0x0, 0x2, 0xffffffffb82626f8, 0xfffffc00003f2d3c) ["../../../../src/kernel/arch/alpha/machdep.c":1735, 0xfffffc00004320ec]
   1 panic(s = 0xffffffffb8262990 = "") ["../../../../src/kernel/bsd/subr_prf.c":757, 0xfffffc00003f2d54]
   2 advfs_sad(0x4, 0xdd5, 0xfffffc0000583798, 0x0, 0x0) ["../../../../src/kernel/msfs/bs/bs_misc.c":322, 0xfffffc000038ba5c]
   3 bs_unpinpg(bfPageRefH = (...), wrtAhdLogAddr = (...), modeNcache = (...)) ["../../../../src/kernel/msfs/bs/bs_buffer2.c":3541, 0xfffffc0000385538]
   4 clone_tagdir(origSetp = 0xfffffc001bf688c8, cloneSetp = (nil), numDirPages = 0x3ec26008, ftxH = (...)) ["../../../../src/kernel/msfs/bs/bs_bitfile_sets.c":4068, 0xfffffc0000395d8c]
   5 bs_bfs_clone(origSetId = (...), cloneSetName = 0xfffffc00162dabc8 = "sapdata2_clone", cloneSetId = 0xfffffc003ec26020, dmnH = 0x9) ["../../../../src/kernel/msfs/bs/bs_bitfile_sets.c":4195, 0xfffffc0000396038]
   6 fs_fset_clone(0x11ffffea4, 0x11ffffeac, 0xfffffc00162dabc8, 0xfffffc003ec26020, 0xffffffffb82635b0) ["../../../../src/kernel/msfs/fs/fs_file_sets.c":578, 0xfffffc00003c0d7c]
   7 msfs_real_syscall(0x40012, 0x4e21d3065b7a0, 0x1000001001, 0xfffffc0015038440, 0xfffffc005467c688) ["../../../../src/kernel/msfs/bs/bs_misc.c":2791, 0xfffffc000038e254]
   8 msfs_syscall(0xfffffc005467c210, 0xffffffffb82638c8, 0xffffffffb82638b8, 0x1ffc00000001, 0x0) ["../../../../src/kernel/msfs/osf/msfs_syscalls.c":122, 0xfffffc0000357b24]
   9 syscall(0x140000658, 0x1, 0x0, 0x0, 0xf0) ["../../../../src/kernel/arch/alpha/syscall_trap.c":519, 0xfffffc000043edc4]
  10 _Xsyscall(0x8, 0x12000c2f8, 0x14000bd00, 0x40012, 0x11fffe7a0) ["../../../../src/kernel/arch/alpha/locore.s":1094, 0xfffffc000042efe4]

The following may appear in the pmsgbuf under dbx:

advfs I/O error: setId 0x305257af.0005d78e.fffffffe.0000  tag
0x00000005.8023u  page 2
        vd 1  blk 18324720  blkCnt 16
        read error = 5
ADVFS EXCEPTION
Module = 4, Line = 3541


PROBLEM:	(UVO103161)		(Patch ID: OSF365-360013)
********
The system panics with "dealloc_bits_page: can't clear a bit twice!"

If this problem is seen, it is necessary to fix the filesystem by backing up the
filesystem, rebuilding the domain, and restoring it from the backups.  Then,
apply the patch, rebuild the kernel, and reboot.

This patch fixes two scenarios which can cause this panic.


PROBLEM:	(TKTB71721 DJOQA0148 GOZ100393)	(Patch ID: OSF365-360013)
********
The system panics with "AdvFS Exception Module = 41, Line = 549"


PROBLEM:	(QAR 40577)		(Patch ID: OSF365-360013)
********
mkfset hangs.


PROBLEM:	(QAR 34490)		(Patch ID: OSF365-360013)
********
Symptoms:

The system will take a memory fault with following footprints:

	trap: invalid memory read access from kernel mode

    	faulting virtual address:     0x00000000000000ec
    	pc of faulting instruction:   0xfffffc0000376720
    	ra contents at time of fault: 0xfffffc0000379118
    	sp contents at time of fault: 0xffffffff867b7918

	panic (cpu 0): kernel memory fault


A somewhat typical stack trace will be:

    0 boot(0x0, 0x0, 0xfffffc0000556f80, 0x33, 0x0) ["../../../../src/kernel/arch/alpha/machdep.c":1735, 0xfffffc0000433d3c]

    1 panic(s = 0xfffffc0000556f80 = "kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":757, 0xfffffc00003f4724]
pcpu = 0xfffffc0003a76388
i = 60011264
bootopt = 0
mycpu = 59379720
spl = 0
prevcc = 18446744073702735767
nextcc = 18446744069414584320
timer = -2038729200
limit = -4398042616612

   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213,0xfffffc0000441ba0]
t = 0xfffffc0003a9e000
pcb = 0xffffffff867b7a58
task = 0xfffffc0003fc9000
p = 0xfffffc0003fc9210
syst = struct {
    tv_sec = 2097408
    tv_usec = -1024
}
nofault_save = 0
exc_type = 4148419530940443
exc_code = 0
exc_subcode = 0
s = 66884112
error = 3629220
stime_enter = struct {
    seconds = -4398044413696
    microseconds = -4390261882880
}
stime_exit = struct {
    seconds = 2404843197390870
    microseconds = -4398046511104
}
utime = struct {
    seconds = -4397985046528
    microseconds = -2038728776
}
stime_enter_valid = 18446739675729924624
ast = 8192
vp = 0xffffffff85eae908
ret = 2097408
map = 0xfffffc0000452ee4
prot = 814047187
cp = 0x54e
i = 6080552
result = 0
pexcsum = 0xfffffc00003b686c
i = 16
pexcsum = 0x4
i = 4393592
utask = 0xf8
utask = 0xfffffc00005db430
cursig = -2038743040
ticks = 4534124
secs = 2097408
usecs = 61464576
utask = 0x3
utask = 0xfffffc0000430a78

   3 _XentMM(0x0, 0xfffffc0000376720, 0xfffffc0000598b40, 0x4, 0x1) ["../../../../src/kernel/arch/alpha/locore.s":1307, 0xfffffc0000430e44]

   4 check_cont_bits(dmnh = 6139552, src = 1) ["../../../../src/kernel/msfs/bs/bs_qio.c":786, 0xfffffc000037671c]
dmnp = 0xfffffc00038a0018
s = 3641580
bfah = 1
bfap = 0xfffffc0000379118
vdi = 0
vdp = 0xfffffc0000379174

   5 bs_io_thread() ["../../../../src/kernel/msfs/bs/bs_qio.c":3152, 0xfffffc0000379114]
msg = (nil)
bfah = 0
bfap = (nil)
ftx = struct {
    hndl = 35648
    level = 89
    dmnh = 0
}
s = 3641488
vdp = (nil)

How to reproduce the problem:

    The problem appears randomly when there are various mounts/unmounts
    going on in an ADVFS file domain, with users doing reads and writes
    to the filesets from this domain.


PROBLEM:	(QAR 33735)		(Patch ID: OSF365-360013)
*********
The system panics with panic string "N1 = 0" after printing the messages:
	ADVFS EXCEPTION
	Module = 1, Line = 487

In the generated crash-data you are most likely to see the update process
was running, however any process that issues a sysnc() system call, or the
sync command may be running.  The traceback in the crash-data will show these
routines:

	panic()
	advfs_sad()
	bs_bf_htop()
	fs_update_stats()
	msfs_sync()
	sync()
	syscall()


PROBLEM: 	(QAR 35611)		(Patch ID: OSF365-360013)
********
Utilities that traverse the / mount point may not distinguish /proc as a
mount point. Example utilities include vdump, find, DECnsr, etc.

vdump example:

vdump of / complains about backing up /proc. It should ignore
this area.

root@soak2> vdump -0uf /dev/rmt1h /
path     : /
dev/fset : root_domain#root
type     : advfs
advfs id : 0x0c3a0248.fffffc00.e17f340
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: error reading extend attributes for directory <./proc>
vdump: Dumping 1308099525 bytes, 284 directories, 1977 files
vdump: Dumping regular files
vvdump: error reading extend attributes for directory <./proc>
vdump: error reading extend attributes for file <./proc/00000>
vdump: unable to read file <./proc/00000>; [22] Invalid argument
vdump: error reading extend attributes for file <./proc/00001>
vdump: unable to read file <./proc/00001>; [22] Invalid argument
vdump: error reading extend attributes for file <./proc/00015>


PROBLEM:	(QAR 40359)		(Patch ID: OSF365-360013)
********
The system date is incorrect following reboot, even if 'date' has been run
and the correct date and time entered prior to the reboot.


PROBLEM:	(QAR 38782) 		(Patch ID: OSF365-360013)
********
After rebooting the system, a file that was changed via mmap() without an
msync(), may have corrupted data.  This only occurs if the advfs file system
containing the file that was mmapped, failed to unmount cleanly when the system
was shutdown.


PROBLEM:        (HPAQ71AFB) 		(Patch ID: OSF365-360018)
********
An application that issues large read requests (each larger
than 64 pages) can hang AdvFS or cause poor AdvFS performance.

A large number of processes will be sleeping from get_freebuf.  

Their stacks will show:

    thread_block
    get_freebuf

or
    bs_bfdmn_flush_all
    get_freebuf


PROBLEM: (MCPM249D4 MCPM29ACC UVO103810 HPAQ2A6ED)  (Patch ID: OSF365-350163)
********
A system using AdvFS can panic with "kernel memory fault" while a thread
is doing a directory search of an AdvFS fileset; for example, this has
been seen during backup operations.  A typical stack trace is:

0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1727]
1 panic() ["../../../../src/kernel/bsd/subr_prf.c":757]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1219]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
4 seq_search() ["../../../../src/kernel/msfs/fs/fs_dir_lookup.c":1593]
5 msfs_lookup() ["../../../../src/kernel/msfs/osf/msfs_lookup.c":608]
6 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":563]
7 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":2327]
8 lstat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2307]
9 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
10 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]


PROBLEM: (MCPM249D4 MCPM29ACC UVO103810 HPAQ2A6ED)  (Patch ID: OSF365-350163)
********
A system using AdvFS can panic with an "ADVFS EXCEPTION" panic while a thread
is doing a directory search of an AdvFS fileset, for example, this has
been seen during backup operations.  A typical stack trace is:

ADVFS EXCEPTION
Module=34, Line = 1624
N1 = -1027
panic (cpu 0): N1 = -1027

1 panic() ["../../../../src/kernel/bsd/subr_prf.c":757]
2 advfs_sad() ["../../../../src/kernel/msfs/bs/bs_misc.c":322]
3 seq_search() ["../../../../src/kernel/msfs/fs/fs_dir_lookup.c":1624]
4 msfs_lookup() ["../../../../src/kernel/msfs/osf/msfs_lookup.c":608]
5 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":563]
6 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":2327]
7 lstat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2307]
8 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
9 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]


PROBLEM:	(MGO101676 35958)	(Patch ID: OSF365-360028)
********
System panics in AdvFS code when either:

A. ls command is run in the fileset mount directory (containing the .tags file)

B. msfsck is run at least twice and then the AdvFS fileset is unmounted


Typical stack traces:

A:

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1735, ]
   1 panic("N1 = -1027") ["../../../../src/kernel/bsd/subr_prf.c":757, ]
   2 advfs_sad() ["../../../../src/kernel/msfs/bs/bs_misc.c":322, ]
   3 seq_search() ["../../../../src/kernel/msfs/fs/fs_dir_lookup.c":1624, ]
   4 msfs_lookup() ["../../../../src/kernel/msfs/osf/msfs_lookup.c":608, ]
   5 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":563, ]
   6 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":2327, ]
   7 lstat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2307, ]
   8 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519, ]
   9 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094, ]

B:

>  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1735, ]
   1 panic("") ["../../../../src/kernel/bsd/subr_prf.c":757, 0xfffffc000043d5b4]
   2 advfs_sad() ["../../../../src/kernel/msfs/bs/bs_misc.c":322, ]
   3 dqflush() ["../../../../src/kernel/msfs/fs/fs_quota.c":3648, ]
   4 quota_deactivate() ["../../../../src/kernel/msfs/fs/fs_quota.c":2163, ]
   5 msfs_unmount() ["../../../../src/kernel/msfs/osf/msfs_vfsops.c":1241, ]
   6 dounmount() ["../../../../src/kernel/vfs/vfs_syscalls.c":1191, ]
   7 unmount() ["../../../../src/kernel/vfs/vfs_syscalls.c":1116, ]
   8 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519, ]
   9 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094, ]


PROBLEM:        (SOO100628)             (Patch ID: OSF365-350123)
********
Attempting to mount a crashed AdvFS file system results in a

    "kernel memory fault"  panic.

1  panic("kernel memory fault")
2  trap() ["../../../../src/kernel/arch/alpha/trap.c"
3  _XentMM() "../../../../src/kernel/arch/alpha/locore.s"
4  ftx_fail_2() "../../../../src/kernel/msfs/bs/ftx_routines.c"
5  ftx_recovery_pass() "../../../../src/kernel/msfs/bs/ftx_recovery.c"
6  ftx_bfdmn_recovery() "../../../../src/kernel/msfs/bs/ftx_recovery.c"
7  bs_bfdmn_activate() "../../../../src/kernel/msfs/bs/bs_domain.c"
8  bs_bfdmn_tbl_activate() "../../../../src/kernel/msfs/bs/bs_domain.c"
9  bs_bfset_activate() "../../../../src/kernel/msfs/bs/bs_bitfile_sets.c"
10 advfs_mountfs() "../../../../src/kernel/msfs/osf/msfs_vfsops.c"
11 msfs_mount() "../../../../src/kernel/msfs/osf/msfs_vfsops.c"
12 mount() "../../../../src/kernel/vfs/vfs_syscalls.c"
13 syscall() "../../../../src/kernel/arch/alpha/syscall_trap.c"
14 _Xsyscall() ""../../../../src/kernel/arch/alpha/locore.s"

A user that has experienced this panic should do the following:

Apply the patch, build a new kernel, and boot the new kernel.  Mount the
AdvFS file system and once mounted, run msfsck to verify the integrity of
the domain.  If msfsck encounters errors, backup and restore the data onto
another domain.


PROBLEM:	(CLD HPXQ38EB8, MGO102089, HPAQ2811E)  (Patch ID: OSF365-360030)
********
This patch fixes a problem in which a system that was upgraded to 
Digital UNIX Version 3.2d and is running AdvFS, may not be able to mount
its AdvFS multi-volume domain.

Error messages will be displayed about incorrect sizes, volumes mounted
read-only, or incorrect volume information.


PROBLEM:        (TKTC51NLS, QAR 29248)  (Patch ID: OSF365-360041)
********
This patch fixes a problem in which the getrusage system call returns zero
for the values of ru_inblock and ru_outblock on an AdvFS file system.

To observe the problem on a system where /usr is an AdvFS file system,
do the following as root:

csh
cp /vmunix /usr/vmunix.tmp1
time cp /usr/vmunix.tmp1 /usr/vmunix.tmp2
# the time command shows 0+0io (before applying the patch)
rm /usr/vmunix.tmp1 /usr/vmunix.tmp2


PROBLEM:        (CLD SOO100812)         (Patch ID: OSF365-360051)
********
This fix corrects a problem when remote NFS clients crash and reboot while
holding locks againsts files on an AdvFS files system.  Prior to this fix
the daemon.log file would receive messages similar to the following:

  Jul 9 13:24:56  lockd[649]:
    can't clear locks after crash of client :  Invalid argument


PROBLEM:  (9WAB62151, QAR 46315, QAR 34257, QAR 35785) (Patch ID: OSF365-360061)
********
This patch fixes a problem in which a system using AdvFS can run out of
metadata space when the AdvFS domain still has some free space available.
The system will display error messages such as 'no space left on device'.

The problem may occur on a heavily fragmented system with many small files,
such as an Internet News server or Mail server.

To handle this problem, please use the -p and -x options when using
the mkfdmn command to create an AdvFS domain that is expected to have
many small files.  Specifying the new -p option to the mkfdmn command
pre-allocates internal AdvFS structures and the erroneous 'out of space'
messages will not occur.

NOTE:  Please run the mkfdmn command with no options or arguments to list
       the updated mkfdmn man page and the -p and -x option descriptions.


PROBLEM:  (Q38248) (Patch ID: OSF365-350232)
******** 
This patch fixes a problem in which an AdvFS system returns an error message 
when attempting to create greater than 764490 files in a directory.

Typical error message:
# cd /tom1
# touch foo
touch: foo cannot create
# mkdir foo
mkdir: cannot create foo.
foo: No space left on device


PROBLEM:  ( mcpm75130 ) (Patch ID: OSF365-360067)
********
The system can crash with a kernel memory fault in ubc_page_alloc().

A typical trace is:

...
5 panic("kernel memory fault") [src/kerubr_prf.c:719]
6 trap() [src/kernel/arch/alpha/trap.c:1243([]
8 ubc_page_alloc() [src/kernel/vfs/vfs_ubc.c:2112]
9 ubc_lookup() [src/kernel/vfs/vfs_ubc.c:1811]
10 ufs_getapage() [src/kernel/ufs/ufs_vnops.c:4728]
11 ufs_getpage() [src/kernel/ufs/ufs_vnops.c:5141([([([]
15 rwuio()[src/kernel/bsd/sys_generic.c:1069]
16 read() [src/kernel/bsd/sys_generic.c:1021]
17 syscall() [src/kernel/arch/alpha/syscall_trap.c:519]
18 _Xsyscall() [l/arch/alpha/locore.s:1094]


PROBLEM:	(QAR46333,QAR40839,ZPOT90826)	(Patch ID: OSF365-350324)
********
This patch fixes a problem that occurs with the telnet and ftp commands.

Telnet or ftp processes that are no longer in use, are left on the system
indefinitely.  When a user tries to log in, the login process hangs
after displaying the last login message.


PROBLEM:        (GOZ100505)              (Patch ID: OSF365-360031)
********
A system will panic with the panic string "simple_lock: time limit exceeded".
The stack trace of the panicing process is as follows:

        panic("simple_lock: time limit exceeded")
        simple_lock_fault()
        simple_lock_time_violation()
        msfs_getpage()
        u_seg_fault()
        u_map_fault()
        vm_fault()
        trap()
        _XentMM()


PROBLEM:	(HPXQ42587)            (Patch ID: OSF365-360071)
********
On an AdvFS system, a broadcast message will cause the idle time to be
reset to zero.


PROBLEM:	(MGO102584)		(Patch ID: OSF365-360088)
********
This patch fixes AdvFS to prevent the following two panics:

  o AdvFS Exception  Module = 1, line = 1891

  o kernel memory fault

with the following stack trace:

_XentMM()
bs_refpg_int()
bs_refpg()
tagdir_get_info()
bs_bfdmn_activate()
bs_bfdmn_tbl_activate()
fs_fset_get_info()
msfs_real_syscall()
msfs_syscall()
syscall()
_Xsyscall()


PROBLEM:        (MANBCP087,QAR 50227)   (Patch ID: OSF365-360090)
********
This patch fixes a problem that occurs on AdvFS systems in which the
system panics with the following error message:

        AdvFS exception Module=26 line=1483

This problem follows an I/O error, and may also cause memory and/or
data corruption without causing a system panic.

The stacktrace of the panic thread will be as follows:

panic()
advfs_sad()
ftx_fail_2()
ftx_fail()
fs_write()
msfs_write()
vn_write()
rwuio()
write()
syscall()
_Xsyscall()

The problem may have also led to memory and/or data corruption,
without the above panic.


PROBLEM:   (UTO101199,HPAQ30ETE,QAR 51485,QAR 52365)  (Patch ID: OSF365-360105)
********
This patch corrects a problem with an NFS V3 mounted AdvFS file system
where under heavy I/O load, data 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:        (GOZ100774)     (Patch ID: OSF365-360112)
********
This patch fixes a problem that occurs on AdvFS systems. The system
will panic with an error message similar to the following:

AdvFS I/O error

    faulting virtual address:     0x000000000000003c
    pc of faulting instruction:   0xfffffc00003998d0
    ra contents at time of fault: 0xfffffc000039ac70
    sp contents at time of fault: 0xffffffffb7d0f480

panic (cpu 0): kernel memory fault

The following is a sample stack trace:

        0 thread_block()
        1 thread_preempt()
        2 boot()
        3 panic()
        4 trap()
        5 _XentMM()
        6 imm_get_first_xtnt_desc()
        7 imm_get_first_hole()
        8 frag_list_extend()
        9 bs_frag_alloc()
        10 fs_create_frag()
        11 close_one_int()
        12 close_int()
        13 bs_vfs_close()
        14 msfs_inactive()
        15 vrele()
        16 utimes()
        17 syscall()
        18 _Xsyscall()


PROBLEM:	(QAR 54852)	(Patch ID: OSF365-360125)
********
Fixes a system panic when shutting down to single user mode using either
one of the following commands when AdvFS is the root or usr filesystem:
    # shutdown now
    # init s

The cause of this problem is subject to the timing of several kernel threads,
therefore the symptoms or panic may occur intermittently and on different 
platforms.

The example stack trace is as follows:

>  0 boot(0x0, 0x4, 0x1, 0x1, 0xfffffc00004893b8) ["../../../../src/kernel/arch/alpha/machdep.c":1795, 0xfffffc00004f4a6c]
   1 panic(s = 0xfffffc0000630098 = "panic stuck syncing disks") ["../../../../src/kernel/bsd/subr_prf.c":673, 0xfffffc0000450eb8]
   2 hardclock(pc = 0xfffffc0000281388 = "@", ps = 0x2) ["../../../../src/kernel/bsd/kern_clock.c":736, 0xfffffc0000437044]
   3 _XentInt(0x2, 0xfffffc0000281388, 0xfffffc0000681bd0, 0xfffffc0006152de0, 0x1) ["../../../../src/kernel/arch/alpha/locore.s":917, 0xfffffc00004f1764]
   4 ufs_fsync_clrflag_wakeup(ip = 0xfffffc0006152cb0, dolock = 0x6152c00) ["../../../../src/kernel/ufs/ufs_vnops.c":6242, 0xfffffc0000281384]
   5 ufs_inactive(vp = 0xfffffc0006152c00) ["../../../../src/kernel/ufs/ufs_inode.c":1231, 0xfffffc000026f180]
   6 vrele(vp = 0xfffffc0002196400) ["../../../../src/kernel/vfs/vfs_subr.c":2234, 0xfffffc00004638ec]
   7 mntbusybuf(mountp = (nil)) ["../../../../src/kernel/vfs/vfs_bio.c":1356, 0xfffffc0000460d30]
   8 boot(0x0, 0x0, 0xffffffff887fb4c8, 0x36, 0x8000000000) ["../../../../src/kernel/arch/alpha/machdep.c": 1751, 0xfffffc00004f4978]
   9 panic(s = 0xffffffff887fb4c8 = "N1 = 2") ["../../../../src/kernel/bsd/subr_prf.c":757, 0xfffffc0000451074]
  10 advfs_sad(0x1a, 0xae7, 0xfffffc000062ac30, 0x0, 0x2) ["../../../../src/kernel/msfs/bs/bs_misc.c":345, 0xfffffc00003e85dc]
  11 log_donerec_nunpin(ftxp = 0xfffffc0007cd8008, dmnp = (nil), lrdp = (nil)) ["../../../../src/kernel/msfs/bs/ftx_routines.c":2790, 0xfffffc00003c0218]
  12 ftx_done_urdr(ftxH = (...), agentId = FTA_BS_BMT_UPDATE_REC_V1, undoOpSz = 0x0, undoOp = (nil), rootDnOpSz = 0x0, rootDnOp = (nil), redoOpSz = 0x0, redoOp = (nil)) ["../../../../src/kernel/msfs/bs/ftx_routines.c":1225, 0xfffffc00003bda38]
  13 ftx_done_n(ftxH = (...), agentId = 30914472) ["../../../../src/kernel/msfs/bs/ftx_routines.c":978, 0xfffffc00003bd5bc]
  14 bmtr_update_rec_int(0xffffffff80287ef8, 0xff, 0xfffffc0007d61498,0x58, 0x0) ["../../../../src/kernel/msfs/bs/bs_bmt_util.c":1816, 0xfffffc00003b6308]
  15 bmtr_update_rec(0x400fe001f003c00, 0xff, 0xfffffc0007d61498, 0x58,0x0) ["../../../../src/kernel/msfs/bs/bs_bmt_util.c":1646, 0xfffffc00003b5fe8]
  16 fs_flush_saved_stats(0xfffffc000041cfa0, 0x0, 0x13000004b0273001, 0x2c000009f7000055, 0xfffffc0007cc0018) ["../../../../src/kernel/msfs/fs/fs_create.c":1100, 0xfffffc000041e1a8]
  17 cleanup_bfap_with_saved_stats(bfap = 0xfffffc000041cfb8) ["../../../../src/kernel/msfs/bs/bs_access.c" :766, 0xfffffc00003e5674]
  18 fs_cleanup_thread(0x0, 0xfffffc0007d61488, 0x130000018e0169, 0x281f00000000, 0xa80000053d0000) ["../../../../src/kernel/msfs/fs/fs_dir_init.c":906, 0xfffffc000041cfb4]


/usr/sys/BINARY/fs_dir_init.o           subset OSFADVFSBIN350
CHECKSUM: 61513     14  RCSfile: fs_dir_init.c  RCS: 1.1.51.2



FILE(s):

/sbin/mkfdmn            		subset OSFADVFS350
CHECKSUM: 64539    176  RCSfile mkfdmn.c   RCS: 1.1.17.2
/usr/sys/BINARY/bs_access.o             subset OSFADVFSBIN365
CHECKSUM: 24151    118  RCSfile bs_access.c  RCS: 1.1.280.2
/usr/sys/BINARY/bs_bitfile_sets.o       subset OSFADVFSBIN365
CHECKSUM: 50911    153  RCSfile: bs_bitfile_sets.c  RCS: 1.1.47.3
/usr/sys/BINARY/bs_bmt_util.o           subset OSFADVFSBIN350
CHECKSUM: 24364     40  RCSfile: bs_bmt_util.c	RCS: 1.1.25.4
/usr/sys/BINARY/bs_buffer2.o            subset OSFADVFSBIN365
CHECKSUM: 08458    140  RCSfile: bs_buffer2.c	RCS: 1.1.61.2
/usr/sys/BINARY/bs_domain.o     	subset OSFADVFSBIN365
CHECKSUM: 64001     44  RCSfile bs_domain.c   RCS: 1.1.165.2
/usr/sys/BINARY/bs_init.o       	subset OSFADVFSBIN350
CHECKSUM: 24706     18  RCSfile bs_init.c  RCS: 1.1.27.2
/usr/sys/BINARY/bs_misc.o       	subset OSFADVFSBIN350
CHECKSUM: 01731     43  RCSfile bs_misc.c  RCS: 1.1.62.3
/usr/sys/BINARY/bs_qio.o                subset OSFADVFSBIN365
CHECKSUM: 47327    114  RCSfile: bs_qio.c  RCS: 1.1.51.2
/usr/sys/BINARY/fs_create.o             subset OSFADVFSBIN365
CHECKSUM: 54930     15	RCSfile: fs_create.c  RCS: 1.1.78.2
/usr/sys/BINARY/fs_dir_init.o           subset OSFADVFSBIN350
CHECKSUM: 61513     14	RCSfile: fs_dir_init.c  RCS: 1.1.51.2
/usr/sys/BINARY/fs_dir_lookup.o         subset OSFADVFSBIN350
CHECKSUM: 26463     17  RCSfile: fs_dir_lookup.c  RCS: 1.1.24.2
/usr/sys/BINARY/fs_read_write.o         subset OSFADVFSBIN365
CHECKSUM: 16845     20  RCSfile: fs_read_write.c  RCS: 1.1.52.4
/usr/sys/BINARY/ftx_routines.o          subset OSFADVFSBIN350
CHECKSUM: 13927    122  RCSfile: ftx_routines.c   RCS: 1.1.27.2
/usr/sys/BINARY/msfs_io.o               subset OSFADVFSBIN365
CHECKSUM: 34357    106  RCSfile: msfs_io.c	RCS: 1.1.52.2
/usr/sys/BINARY/msfs_misc.o             subset OSFADVFSBIN365
CHECKSUM: 39879     27  RCSfile: msfs_misc.c      RCS: 1.1.94.5
/usr/sys/BINARY/msfs_vnops.o            subset OSFADVFSBIN365
CHECKSUM: 24733    142  RCSfile: msfs_vnops.c     RCS: 1.1.138.3
/usr/sys/BINARY/msfs_vfsops.o           subset OSFADVFSBIN365
CHECKSUM: 52452     28  RCSfile: msfs_vfsops.c	RCS: 1.1.115.5

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

Fixes an AdvFS problem in which the "advfsstat -n" command causes a core dump.
The system displays the message:  Memory fault(coredump)
PROBLEM:        (QAR 55308,QAR 55447)   (Patch ID: OSF365-350452)
********
This patch fixes an AdvFS problem in which the "advfsstat -n" command
causes a core dump. The system displays the following error message:

 Memory fault(coredump)


FILE(s):
»European Site

Files on this server are as follows:

»duv32de2as00004-19980311.README
»duv32de2as00004-19980311.CHKSUM
»duv32de2as00004-19980311.tar
»duv32de2as00004-19980311.ps
privacy statement using this site means you accept its terms