
 DUV40AS00006-19980610 DIGITAL UNIX V4.0 Aggregate ECO Summary

 

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

PRODUCT:    DIGITAL UNIX [R] 4.0
SOURCE:     DIGITAL Equipment Corporation

ECO INFORMATION:

     ECO Name:  DUV40AS00006-19980610
     ECO Kit Approximate Size:  60MB 
     Kit Applies To:  DIGITAL UNIX 4.0


ECO KIT SUMMARY:

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

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

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


INSTALLATION NOTES:

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

{2. other installation notes}

  
SUPERSEDED PATCH LIST:

This patch kit supersedes the following DIGITAL UNIX patches:

  DUV40AS00005-19980105			! Previous Aggregate Patch Kit


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

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

Programs generated by lex that use the %pointer definition in the lex grammar 
file produce a memory fault and a core dump.
PROBLEM:  (QAR 45497) 			(Patch ID: OSF400-011)
********
C language programs generated by the lex command cause a memory fault and dump 
core when the "%pointer" keyword is specified in the lex grammar file.

To reproduce this problem, create a file called transmute.l containing the 
following grammar to reproduce the problem.

csh> cat transmute.l
%pointer
%%
(LEAD)  printf("GOLD");

csh> lex transmute.l
csh> cc lex.yy.c -o transmute -ll
csh> transmute < transmute.l
 Memory fault(coredump)
csh> 


FILE(s):

/usr/ccs/lib/ncpform 		subset OSFPGMR400
CHECKSUM: 22348      6	RCSfile: ncpform   RCS: 1.1.7.2

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

Data corruption due to change in DNAD register behavior on Symbios 
810A/825A/860/875 chips.
PROBLEM:  (QAR 46878)	 	(Patch ID: OSF400-029)
********
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.


FILE(s):

/sys/BINARY/cam_psiop.mod 			subset OSFHWBIN400
CHECKSUM: 36007    216
/usr/sys/include/io/cam/siop/pci_scripthost.h 	subset OSFBINCOM400
CHECKSUM: 41447     16     RCSfile: pci_scripthost.h      RCS: 1.1.38.2

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

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


FILE(s):

/usr/sbin/ping                      subset OSFCLINET400
CHECKSUM: 17471     32     RCSfile: ping.c      RCS: 4.2.29.2

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

Add the time out options -t nnn & -T to the 'showmount' command.
PROBLEM:  (HPXQ36487/QAR 46954) (Patch ID: OSF400-036)
********
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 OSFNFS400
CHECKSUM: 36213     24     RCSfile: showmount.c      RCS: 4.2.9.2

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

NIS slaveservers will not accept a push from the master server of a new map.
PROBLEM:  (QAR 46193)	 (Patch ID: OSF400-042)
********
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 OSFINET400
CHECKSUM: 54610     48     RCSfile: ypserv_proc.c      RCS: 4.2.22.2

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

This patch allows a system that is running gated to update internal routing 
tables to manage the router discovery function.
PROBLEM:   (QAR 47428) 			(Patch ID: OSF400-058)
********
This patch allows a system that is running gated to update internal routing 
tables to manage the router discovery function.  The problem is that the gated 
deamon cannot parse the 'routerdiscovery client' and 'routerdiscovery server' 
statements.


FILE(s):

/usr/sbin/gated		subset OSFCLINET400
CHECKSUM: 33750   1368      

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

This patch fixes a problem that occurs on multiprocessor 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.
PROBLEM:  (QAR 47149, UVO104578CBR) (Patch ID: OSF400-061)
********
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 OSFBASE400
CHECKSUM: 28714     48     RCSfile: cron.c      RCS: 4.2.40.2

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

SUPERSEDED PATCHES:	OSF400-069 (69.00), OSF400-069-1 (69.01)

This patch corrects the following:

- Corrects the following problems that occur when an application is started
  from a subshell, for example, sh -c :

- An application will hang if it receives an interrupt signal, for example,
  if the user enters Ctrl/C.

- While an application is running, if Ctrl/C is entered, the parent process
  exits, but the child process remains.
PROBLEM:	(STLB81811,SOO100674)	(Patch ID: OSF400-069)
********
Fixes the following problems when running an application inside a shell, 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.


FILE(s):

/usr/bin/sh		subset OSFBASE400
CHECKSUM: 36393    128    
/usr/bin/Rsh		subset OSFBASE400
CHECKSUM: 36393    128 
/sbin/sh		subset OSFBASE400
CHECKSUM: 28719    264 
/sbin/Rsh		subset OSFBASE400
CHECKSUM: 28719    264 

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

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: OSF400-074)
********
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 OSFCLINET400
CHECKSUM: 10291     32     RCSfile: rlogin.c      RCS: 4.2.24.2

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

This patch corrects the following ZLXp-L1 or ZLXp-L2 graphics option problems:

- Stereo mode (XStereo) does not function properly.

- Applications that use the second hardware colormap do not display the correct
  colors.
PROBLEM:  (03D-1113) 		(Patch ID: OSF400-081)
********
On systems with a ZLXp-L1 or ZLXp-L2 graphics option, stereo mode (XStereo)
does not function properly.

PROBLEM:  (O3D-1121) 		(Patch ID: OSF400-081)
********
On systems with a ZLXp-L1 or ZLXp-L2 graphics option, applications that use
the second hardware colormap do not display the correct colors.
 

FILE(s):

/sys/BINARY/pvp.mod            		 subset OSFHWBIN400
CHECKSUM: 32478     60
/usr/sys/include/io/dec/ws/pvp.h	 subset OSFBINCOM400
CHECKSUM: 19984     51     RCSfile: pvp.h      RCS: 1.1.11.2
/usr/sys/data/pvp_data.c		 subset OSFBINCOM400
CHECKSUM: 07265     15     RCSfile: pvp_data.c RCS: 1.1.7.2

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

A potential security vulnerability has been discovered in 'ris_pax', where 
under certain circumstances users may gain unauthorized access. Digital has 
corrected this potential vulnerability.
PROBLEM:  (SSRT0413U, QAR 48213) (Patch ID: OSF400-089)
********
A potential security vulnerability has been discovered in 'ris_pax', where 
under certain circumstances users may gain unauthorized access.  Digital has 
corrected this potential vulnerability.


FILE(s):

/usr/var/adm/ris/bin/ris_pax		subset OSFRIS400
CHECKSUM: 49630     16     

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

On system with a PowerStorm 4D20 (TGA2) graphics option, monitor resolution
setting 4 (1600x1200 at 65 Hz) is not setup properly.
PROBLEM:  (CFS.41048) (Patch ID: OSF400-090)
********
On system with a PowerStorm 4D20, resolution 1600x1200 @ 65 hz (switch setting 
4) does not produce the documented output.

 
FILE(s):

/sys/BINARY/tga.mod		subset OSFHWBIN400
CHECKSUM: 51254    117     

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

SUPERSEDED PATCHES:	OSF400-044 (44.00)

This patch corrects the following:

- A halt/restart problem with the FDDI DEMFA driver when the interface 
  performs the ESP self tests.
PROBLEM:  (ZPOB71633) 		(Patch ID: OSF400-044)
********
This patch fixes a halt/restart problem with the FDDI DEMFA driver.  The DEMFA 
interface may not restart after the ESP self tests.  

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

PROBLEM:  (ZPOB83066) 		(Patch ID: OSF400-095)
********
This patch fixes a halt/restart problem with the FDDI DEMFA driver when the 
interface performs the ESP self tests.

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.


FILE(s):

/sys/BINARY/mfa.mod         subset OSFHWBIN400
CHECKSUM: 42498     46     

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

Ping command can time out after invoking the "rcinet restart" command.
PROBLEM:  (HPAQ88A35) 		(Patch ID: OSF400-117)
********
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 OSFCLINET400
CHECKSUM: 48670      3     RCSfile: route      RCS: 1.1.15.2

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

This patch fixes a "kernel memory fault" in the dqget() routine.
PROBLEM:  (HPAQ92E5E)		 (Patch ID: OSF400-126)
********
This patch fixes a "kernel memory fault" in the dqget() routine.  The crash
signature will look like the following:

  0 boot()            [../../../../src/kernel/arch/alpha/machdep.c]
  1 panic(kernel memory fault) [../../../../src/kernel/bsd/subr_prf.c]
  2 trap()            [../../../../src/kernel/arch/alpha/trap.c]
  3 _XentMM()         [../../../../src/kernel/arch/alpha/locore.s]
  4 dqget()           [../../../../src/kernel/ufs/ufs_quota.c]
  5 quota_chown()     [../../../../src/kernel/ufs/ufs_quota.c]
  6 chown1()          [../../../../src/kernel/ufs/ufs_vnops.c]
  7 ufs_setattr()     [../../../../src/kernel/ufs/ufs_vnops.c]
  8 chown2()          [../../../../src/kernel/vfs/vfs_syscalls.c]
  9 chown()           [../../../../src/kernel/vfs/vfs_syscalls.c]
 10 syscall()         [../../../../src/kernel/arch/alpha/syscall_trap.c]
 11 _Xsyscall()       [../../../../src/kernel/arch/alpha/locore.s]


FILE(s):

/usr/sys/BINARY/ufs_quota.o         subset OSFBIN400
CHECKSUM: 42632     80     RCSfile: ufs_quota.c      RCS: 4.2.32.2

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

SUPERSEDED PATCHES:	OSF400-124 (124.00)

This patch corrects the following:

- On systems with PCXAL, LK411, and similar keyboards, sometimes on boot or
  between sessions on the workstation monitor, the keyboard stops working.

- Issuing a SET_DEVICE_MODE ioctl to the workstation driver to change
  cursor reporting to relative mode fails.
PROBLEM:  (TKTB49381,GOZ100613,UTO101179) (Patch ID: OSF400-124)
********
On systems with PCXAL, LK411, and similar keyboards, sometimes on boot or
between sessions on the workstation monitor, the keyboard stops working.

PROBLEM:  (QAR 49961)		 	(Patch ID: OSF400-128)
********
Issuing a SET_DEVICE_MODE ioctl to change the reporting of the cursor
position from absolute mode to relative mode fails.  The ioctl is not
being handled correctly by the workstation driver.


FILE(s):

/usr/sys/data/pcxal_data.c		subset OSFBINCOM400
CHECKSUM: 49997     72     RCSfile: pcxal_data.c      RCS: 1.1.28.2
/sys/BINARY/gpc.mod			subset OSFHWBIN400
CHECKSUM: 06809     17
/sys/BINARY/gpc_input.mod		subset OSFHWBIN400
CHECKSUM: 57239     27
/sys/BINARY/ws.mod			subset OSFHWBIN400
CHECKSUM: 22471     97

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

On systems with an ATI Mach64 graphics card, sometimes the monitor goes
into power-save mode and cannot be restored.
PROBLEM:  (HPAQ95AF2, QAR 46780) (Patch ID: OSF400-140)
********
On systems with an ATI Mach64 graphics card, sometimes the monitor goes
into power-save mode and cannot be restored without stopping and restarting
the X server.


FILE(s):

/sys/BINARY/ati64.mod		subset OSFHWBIN400
CHECKSUM: 16253     44

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

SUPERSEDED PATCHES:	OSF400-075 (75.00)

This patch corrects the following:

- Prevents terminal line characteristics for telnet with a modem to be
  reset to 7-bits/no-parity from 8-bits/no-parity. Incorrect terminal line 
  characteristics cause garbage to be displayed when using telnet.

- Fixes a problem where telnet dumps core if the USER environment variable
  is the last variable in the enviroment list.
PROBLEM:  (CLD MCPM823A9, QAR 43433) (Patch ID: OSF400-075)
********
The terminal line characteristics for telnet with a modem are being reset to 
7-bits/no-parity from 8-bits/no-parity.  Incorrect terminal line characteristic
settings will cause garbage to be displayed when using telnet.

If an application requires 8 bits/no-parity for use with serial terminals and 
dial-in modems, telnet will override the setting giving 7 bits/no-parity.  A 
user can check terminal settings with the command stty -a.  

The following response indicates 7-bit character setting:
  -parenb -parodd cs7 -cstopb hupcl cread -clocal

The following response indicates 8-bit character setting:
  -parenb -parodd cs8 -cstopb hupcl cread -clocal


PROBLEM:  (FNO100131, QAR 43995) (Patch ID: OSF400-150)
********
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 OSFCLINET400
CHECKSUM: 54742    136     RCSfile: sys_bsd.c     RCS: 4.2.24.2

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

This patch fixes a problem that may cause /sbin/loader to fail to resolve
duplicate symbols in dlopen'ed shared libraries.
PROBLEM:  (ULC-60, USG-04340, 50807) (Patch ID: OSF400-152)
********
This patch fixes a problem that may cause /sbin/loader to fail to resolve 
duplicate symbols in dlopen'ed shared libraries.  Duplicate symbols only exist 
in large multi-GOT objects. The application's dlopen call may get a 
segmentation violation and there may be no traceback information.

Application developers may consider linking their application against the 
multi-GOT shared libraries as a test for this problem.  Statically loading the 
libraries should work.

More information on multi-Got objects can be obtained from the odump man page 
and the Assembly Language Programmer's Guide.


FILE(s):

/sbin/loader		subset OSFBASE400
CHECKSUM: 34538    136

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

SUPERSEDED PATCHES:	OSF400-063   (63.00),   OSF400-071 (71.00),
			OSF400-071-1 (71.01),   OSF400-160 (160.00)

This patch corrects the following:

- If the user sending mail makes an error entering the destination address 
  the user will receive a mail message that contains both the text of the
  mail and the error messages.  The error messages do not correctly describe
  the exact nature of the problem.

- Fixes a problem that can occur with programs linked with libaio.
  These programs could dump core with a SIGSEGV signal or corrupt memory
  when calling the close() function with a bad file descriptor value.

- 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.
PROBLEM:  (CLD-HPXQ22677) 	(Patch ID: OSF400-063)
********
Fixed the problem of mail failing where a distribution list on the "TO:" or
"Cc:" line is very long or more than 1024 characters.  The typical error 
message is listed as follows:

   ----- Transcript of session follows -----
554 Unbalanced '('
554 ""... Unbalanced '('
554 ""... Unbalanced '('

   ----- Unsent message follows -----
        id AAxxxxx; Tue, 20 Feb 96 13:53:39 EST
        .
        .
        
        


PROBLEM:  (HPAQ69EDF)		 (Patch ID: OSF400-071)
********
This patch fixes a problem with the sendmail command.  If the user sending mail
makes an error entering the address of the person he/she is sending mail to, 
he/she will receive a mail message that contains both the text of his/her 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:  (SSRT0421U, QAR 49337) (Patch ID: OSF400-160-1)
********
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/sendmail			   subset OSFBASE400
CHECKSUM: 53257    200
/usr/sbin/mailq	  			   subset OSFBASE400
CHECKSUM: 53257    200
/usr/sbin/newaliases            	   subset OSFBASE400
CHECKSUM: 53257    200
/usr/var/adm/sendmail/.mrg..sendmail.cf    subset OSFBASE400
CHECKSUM: 34462      5	RCSfile: .mrg..sendmail.cf   RCS: 1.1.10.2
/usr/var/adm/sendmail/.new..sendmail.cf    subset OSFBASE400
CHECKSUM: 12224     21
/usr/sbin/smtpd				   subset OSFBASE400
CHECKSUM: 53257    200

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

This patch fixes a problem that can occur with programs linked with libaio.
These programs could dump core with a SIGSEGV signal or corrupt memory
when calling the close() function with a bad file descriptor value.
PROBLEM:  (QAR 50120,QAR 40188,QAR 47526,QAR 47839) (Patch ID: OSF400-164)
********
This patch fixes a problem that can occur with programs linked with libaio.
These programs could dump core with a SIGSEGV signal or corrupt memory
when calling the close() function with a bad file descriptor value.

A bad or incorrect file descriptor value would be one greater than or equal
to 4096 or less than 0.

The following is a sample stack trace:

thread 0xb signal IOT/Abort trap at >*[nxm_thread_kill, 0x3ff8053eab0]
 0 nxm_thread_kill(...) [0x3ff8053eab0]
 1 pthread_kill(...) [0x3ff8056ed4c]
 2 (unknown)() [0x3ff805756ec]
 3 __tis_raise(...) [0x3ff8010fb00]
 4 raise(...) [0x3ff80159f40]
 5 abort(...) [0x3ff80170a68]
 6 errAbort(...) [0x3ff80565b04]
 7 (unknown)() [0x3ff80566398]
 8 (unknown)() [0x3ff807b220c]
 9 (unknown)() [0x3ff807b3620]
 10 exc_unwind(...) [0x3ff807b3664]
 11 exc_raise_signal_exception(...) [0x3ff807b38e8]
 12 (unknown)() [0x3ff81002490]
 13 close(...) [0x3ff81003488]
 14 main(argc = 4, argv = 0x11ffff988) ["aio_test.c":157, 0x120001d64]


FILE(s):

/usr/ccs/lib/libaio.a           subset OSFLIBA400
CHECKSUM: 17919     20

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

This patch fixes a problem in which settting full duplex mode on DEFPA using
"/usr/sbin/fddi_config -i fta0 -x1" will not enable full duplex mode.
PROBLEM:  ( HPAQ82D5D ) (Patch ID: OSF400-166)
********
This patch fixes a problem in which settting full duplex mode on DEFPA using
"/usr/sbin/fddi_config -i fta0 -x1" will not enable full duplex mode.


FILE(s):

/usr/sbin/fddi_config		    subset OSFCLINET400
CHECKSUM: 33580     16     RCSfile: fddi_config.c      RCS: 1.1.10.2

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

This patch fixes a problem in which "netstat -I fta0 -s" reports 6 bytes of
the 8 byte "Station UID" and "Station ID".
PROBLEM:  ( HPAQ82D5D )
********
This patch fixes a problem in which "netstat -I fta0 -s" reports 6 bytes of the
8 byte "Station UID" and "Station ID".


FILE(s):

/usr/sbin/netstat		subset OSFHWBASE400
CHECKSUM: 41170    112

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

SUPERSEDED PATCHES:	OSF400-020 (20.00)

This patch corrects the following:

- Fixes a problem in which dynamically configured device drivers on an EISA
  bus may fail to configure into the kernel. Apply this patch if your system
  supports a loadable EISA bus driver.

- Fixes two problems that occur on systems with an EISA bus:

    o A system running four DE425 adapters off an EISA bus may hang.

    o 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:  (QAR 46251)		 (Patch ID: OSF400-020)
********
This patch fixes a problem in which dynamically configured device drivers on an
EISA bus may fail to configure into the kernel.  

A user may find that an EISA loadable device driver works on one machine, but 
will fail when moved to another platform.  If the configuration fails, the 
following line will appear in the /usr/admin/messages file:

CBUS2_PCI_IO_TRANSLATE unsupported bus io_handle_t: 0xffffffa000008c80

PROBLEM:  (EVT101968) 		 (Patch ID: OSF400-170)
********
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: OSF400-170)
********
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):

/sys/BINARY/eisa.mod 		subset OSFHWBIN400
CHECKSUM: 18378     71

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

This patch fixes two problems with the mailx command.
PROBLEM:  (UVO105070, QAR 50239)	 (Patch ID: OSF400-172)
********
This patch fixes a problem with the mailx command. 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

PROBLEM:  (QAR 45357)	 		(Patch ID: OSF400-172)
********
This patch provides a way for the mailx command to display the next message
instead of redisplaying the current message (default behavior).

When you press the Return key while reading mail, the default behavior for
mailx is to redisplay the current message. This patch provides a new variable,
"gonext", which allows you to read the next message.  You can set the "gonext"
variable in the .mailrc file or at the mailx prompt using the "set gonext"
command. Setting the "gonext" variable in the .mailrc file makes the change
permanent. Setting the "gonext" variable at the mailx prompt means the "gonext"
variable is only valid for the duration of the current mail session.

FILE(s):

/usr/bin/mailx          subset OSFBASE400
CHECKSUM: 56417    208
/usr/bin/Mail 	        subset OSFBASE400
CHECKSUM: 56417    208

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

SUPERSEDED PATCHES:	OSF400CDE-001 (175.00)

This patch corrects the following:

- Corrects a problem where applications behave as if 'unaligned access` error
  messages have been suppressed.  This can lead to poor application performance
  without a visible cause.
PROBLEM:  (QAR 45656) (Patch ID: OSF400CDE-001)
********
A program which generates 'unaligned access' error messages will not behave as 
on prior releases using DECwindows/xdm. Under CDE, the application will behave 
as if the 'uac' command had been used to suppress those messages. This can lead 
to poor application performance without a visible cause, as unaligned fixups 
are made.

FILE(s):

/usr/dt/bin/dtsession 		subset OSFCDEDT400
CHECKSUM: 62703    176     RCS: 2.1.7.2 (SmMain.c)

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

This patch fixes two problems with the CDE window manager. In the first problem,
the CADDS5 (a third party cad tool) text window tends to walk off the screen.
In the second problem, the CDE icon box moves 29 pixels higher along the x axis
each time the user's home session is resumed.
PROBLEM:  (CLD USG-04316) 	(Patch ID: OSF400CDE-005)
********
Under the CDE window manager the CADDS5 (a third party cad tool) Text Window 
tends to walk off the screen.

PROBLEM:  (QAR 49251) 		(Patch ID: OSF400CDE-005)
********
The CDE icon box moves 29 pixels higher along the x axis each time the user's 
home session is resumed.


FILE(s):

/usr/dt/bin/dtwm		subset OSFCDEDT400
CHECKSUM: 65326    648

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

This patch corrects the following:

- dxsysinfo causes the X server's colormap entries to be corrupted

- dxsysinfo may display certain filesystem percent full values incorrectly

- dxsysinfo repeatedly adds device /dev/prf as a tape entry into its Device 
  Information Area

- dxsysinfo leaves its child process orphaned after a logout

- hard disk icons fail to display in the Device Information Area when the 
  colormap is full or on a black/white screen
PROBLEM: (QAR 45825)		(Patch ID: OSF400DX-001)
********
This patch fixes a problem that causes the X server's colormap entries to be 
corrupted. The current session's colors may become mixed up.  For example, the 
black may be white, the white may be red, and so on.

PROBLEM: (QAR 44365 and 46643)	(Patch ID: OSF400DX-001)
********
This patch fixes a problem in which certain file system percent full values may
be displayed incorrectly. The percent full values may not match (by more than 
1%) the values displayed by the df command. This is especially true for 
relatively large file systems and for AdvFS file systems.

PROBLEM: (QAR 41445)		(Patch ID: OSF400DX-001)
********
This patch fixes a problem with the dxsysinfo application.  For systems that 
have the System V environment subset installed, dxsysinfo displays the /dev/prf 
device in its Device Information Area as a tape device and each time Update 
Devices is selected, another /dev/prf icon is added.

PROBLEM: (QAR 44882)		(Patch ID: OSF400DX-001)
********
This patch fixes a problem with the dxsysinfo application. When a user logs out
of the CDE session, the child process becomes orphaned and continues to run.

PROBLEM: (QAR 40964)		(Patch ID: OSF400DX-001)
********
This patch fixes a problem in which the hard disk icons fail to display in the 
Device Information Area when the colormap is full or when a black/white screen 
is used.


FILE(s):

/usr/bin/X11/dxsysinfo				       subset OSFXADMIN400
CHECKSUM: 12181    152     
/usr/dt/appconfig/icons/C/physdisk.m.pm		       subset OSFXSYSMAN400
CHECKSUM: 41432      4     RCSfile: physdisk.m.pm      RCS: 1.1.9.2
/usr/dt/appconfig/icons/C/physdisk.t.pm		       subset OSFXSYSMAN400
CHECKSUM: 29587      3     RCSfile: physdisk.t.pm      RCS: 1.1.9.2
/usr/dt/appconfig/icons/C/physdisk_bad.m.pm	       subset OSFXSYSMAN400
CHECKSUM: 55153      4     RCSfile: physdisk_bad.m.pm  RCS: 1.1.9.2
/usr/dt/appconfig/icons/C/physdisk_bad.t.pm	       subset OSFXSYSMAN400
CHECKSUM: 55130      3     RCSfile: physdisk_bad.t.pm  RCS: 1.1.9.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
(filters) that can not handle escape sequences.
PROBLEM:  (CLD TKTQA2401) 		(Patch ID: OSF400DX-002)
********
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 OSFX11400
CHECKSUM: 32315    720     

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

X server performance is slow when an application is drawing arcs which are 
outside the bounds of the drawable window.
PROBLEM:  (OSF_QAR 45015) (Patch ID: OSF400X11-002)
********
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 OSFX11400
CHECKSUM: 07793    320     	RCS: 1.1.8.2 (miarc.c)

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

SUPERSEDED PATCHES:	OSF400X11-001 (184.00)

This patch corrects the following:

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

- On systems with an ATI Mach64 graphics card, sometimes the monitor will
  lose synchronization or become stuck in power-save mode.
PROBLEM:  (MGO102057) 		(Patch ID: OSF400X11-001)
********
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: OSF400X11-009)
********
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 OSFSERPC400
CHECKSUM: 35712    128    
/usr/shlib/X11/lib_dec_ws.so            subset OSFSER400
CHECKSUM: 24064    112    
/usr/shlib/X11/libextdpms.so            subset OSFSER400
CHECKSUM: 63040     32 

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

This patch fixes a LEX problem. Without this patch, LEX rejects quoted regular
expressions where the ending quote is preceded by a double backslash, as in:
"\\"xxx, and produces the following message: "lex:(Warning at line 8)Non-
terminated string".
PROBLEM:  (QAR 51280)	 (Patch ID: OSF400-177)
********
LEX rejects a quoted regular expression where the ending quote  is preceded
by a double backslash, as in: "\\"xxx. The following warning is produced by
LEX: "lex: (Warning at line 10)Non-terminated string". The resultant lex.yy.c
file may or may not compile cleanly.

To reproduce the problem, use the following lex specification:

%{
extern char cbuf[];
extern int clen;
%}

%%
"\\\""         {cbuf[clen++] = '"';}
"\\"n          { cbuf[clen++]='\n'; }
"\\"t          { cbuf[clen++]='\t'; }
"\\"b          { cbuf[clen++]='\b'; }
"\\"r          { cbuf[clen++]='\r'; }
"\\"f          { cbuf[clen++]='\f'; }
"\\\\"         { cbuf[clen++]='\\'; }
%%
char cbuf[100];
int clen;
int main()
{
   clen = 0;
   yylex();
   cbuf[clen] = 0;
   printf("%s\n", cbuf);
}

sauron:test/qar/48948 [577%] lex yong.l
lex: (Warning at line 8)Non-terminated string
line 16: syntax error
lex: (Warning) bad state  205 175
sauron:test/qar/48948 [580%] lex yong.l
sauron:test/qar/48948 [599%] cc lex.yy.c -ll
sauron:test/qar/48948 [600%] a.out
abc

def

abcdef


FILE(s):

/usr/ccs/bin/lex                subset OSFPGMR400
CHECKSUM: 13734     80

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

uugetty - CD/DSR not dropping right away after dial-out.
PROBLEM:  (QAR 49652)		 (Patch ID: OSF400-179)
********
When dialing out on a port running uugetty, an immediate hang-up is not
performed after the session completes.  The hang-up occurs approximately
60 seconds following the end of the session.


FILE(s):

/usr/lib/uucp/uugetty               subset OSFUUCP400
CHECKSUM: 08400    224     RCSfile: uugetty.c      RCS: 4.3.21.2

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

This patch fixes a problem in which rwhod daemon can cause a core dump with
a segmentation fault.
PROBLEM:  (HPAQC0XEH, TKTQ81868)	 (Patch ID: OSF400-183)
********
This patch fixes a problem in which rwhod daemon can cause a core dump with a
segmentation fault.

A typical stack trace shows:

>  0 __getutid_r()[]
   1 __getutid() []


FILE(s):

/usr/sbin/rwhod         	    subset OSFCLINET400
CHECKSUM: 65385     24     RCSfile: rwhod.c      RCS: 4.2.17.2

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

This patch fixes a problem in which users logging into a system that has a 
nodename longer than 32 characters cause ttsession to core dump.  This only 
happens when using CDE desktop.
PROBLEM:  (CLD MGO102608)        (Patch ID: OSF400CDE-006)
********
This patch fixes a problem in which users logging into a system that has a
nodename longer than 32 characters cause ttsession to core dump.  This only
happens when using CDE desktop.


FILE(s):

/usr/dt/lib/libtt.so            subset OSFCDEMIN400
CHECKSUM: 01938   1320

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

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: OSF400-190)
********
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 OSFNFS400
CHECKSUM: 23756    104

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

This patch fixes a problem where the NTP deamon (xntpd) does not work using a
Spectracom radio clock as a reference.
PROBLEM:  (HPXQ10VTZ/QAR 48622)		 (Patch ID: OSF400-191)
********
This patch fixes a problem where the NTP deamon (xntpd) does not work using a
Spectracom radio clock as a reference.
If NTP is configured for a radio clock, at the first response from the clock,
the code will loop using all CPU cycles.


FILE(s):

/usr/sbin/xntpd         subset OSFCLINET400
CHECKSUM: 53808    304

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

This patch 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: OSF400-194)
********
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/.new..root         subset OSFBASE400 
CHECKSUM: 19634      2
/usr/var/spool/cron/crontabs/.mrg..root         subset OSFBASE400 
CHECKSUM: 08670      5     RCSfile: .mrg..root      RCS: 1.1.13.2

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

SUPERSEDED PATCHES:	OSF400-115 (115.00)

This patch corrects the following:

- Under enhanced security, sometimes users (even root) are unable to log in
  on graphics console, even after using dxdevices or edauth to clear the
  t_failures count.
 
- On systems running enhanced security, user-written applications
  that call auth_for_terminal() may fail with a segmentation fault.
PROBLEM:  (HPAQ17931, HPAQA353A) (Patch ID: OSF400-115)
********
On systems running enhanced security, if a customer's application calls the 
auth_for_terminal() routine when 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 
customer's application will fail with a segmentation fault.

PROBLEM:  (CLD HGOQB0282)	 (Patch ID: OSF400-203)
********
On a system using enhanced security, login attempts at a graphic console can
fail, giving the message: "Terminal is disabled -- see Account Administrator."
This failure persists even after using dxaccounts or edauth to clear the
t_failures entry for the display in the terminal control databas


FILE(s):

/usr/ccs/lib/libsecurity.a		subset OSFC2SEC400
CHECKSUM: 42823    395

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

This patch fixes a problem that causes dbx to hang when stepping past a 
system() function call.
PROBLEM:  (HPAQ20QW1, 51670)	 (Patch ID: OSF400-205)
********
Attempting to step past a system() function call causes dbx to hang.


FILE(s):

/usr/ccs/lib/cmplrs/cc/dbx          subset OSFBASE400
CHECKSUM: 21064    952     RCSfile: dbxsignal.c      RCS: 1.1.16.5

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

This patch fixes a problem in which the tic command incorrectly returns a
non-zero exit value upon successful completion. An exit value of 0 should
be returned upon successful completion.
PROBLEM:  (QAR 46522)		 (Patch ID: OSF400-206)
********
This patch fixes a problem in which the tic command incorrectly returns a
non-zero exit value upon successful completion. An exit value of 0 should
be returned upon successful completion.

Typical behavior for this problem is exhibited by:

# TERMINFO=/tmp
# export TERMINFO
# cp /usr/share/lib/terminfo/dec.ti .
# tic dec.ti
# echo $?
78


FILE(s):

/usr/bin/tic            	    subset OSFBASE400
CHECKSUM: 39109     32     RCSfile: tic.c      RCS: 4.2.17.2

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

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
potential vulnerability.
PROBLEM:  (CLD SSRT0438U)	 (Patch ID: OSF400CDE-007)
********
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/dt/bin/dtpad               subset OSFCDEDT400
CHECKSUM: 32434    112     RCSfile: dtpad.c      RCS: 2.1.6.2

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

SUPERSEDED PATCHES: 	OSF400-211 (227.00)

This patch corrects the following:

- Fixes a problem in which the dd command can corrupt output on very large
  files (2GB or greater) when the "conv=sparse" option is used.
PROBLEM:  (QAR 47063)		 (Patch ID: OSF400-211)
********
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 OSFBASE400
CHECKSUM: 25043     32     RCSfile: dd.c      RCS: 4.3.30.2
/usr/bin/dd             	    subset OSFBASE400
CHECKSUM: 10047     32     RCSfile: dd.c      RCS: 4.3.30.2

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

SUPERSEDED PATCHES: 	OSF400X11-013 (226.00)

This patch corrects the following:

- On systems with PowerStorm 4D40T, 4D50T, or 4D60T graphics options,
  the X server may hang every 49 days.

- Screen flickers on and off when in power-save mode.
PROBLEM:  (QAR 50045)		 (Patch ID: OSF400X11-013)
********
On a system with a graphics card and monitor which support VESA Display Power
Management Signalling (DPMS), the monitor can become stuck in power-save mode
or the screen can flicker on and off when the X server screen saver is turned
off, DPMS is enabled, and the mouse is moved to bring the display out of 
power-save mode.  The display does not come out of power-save mode correctly
until you press a key on the keyboard or click a mouse button.
or click a mouse button.

This problem is particularly noticeable on ALPHAbook 1 systems.

PROBLEM:  (7KSB31809) 		(Patch ID: OSF400X11-014)
********
On systems with PowerStorm 4D40T, 4D50T, or 4D60T graphics options, the X
server may hang (and not exit) at or near the following local times:

        Fri Jan 31 03:14:51 1997
        Fri Mar 21 20:17:39 1997
        Sat May 10 14:20:26 1997
        Sun Jun 29 07:23:13 1997
        Mon Aug 18 00:26:01 1997
        Mon Oct  6 17:28:48 1997
        Tue Nov 25 09:31:35 1997
        


FILE(s):

/usr/shlib/X11/libos.so         subset OSFX11400
CHECKSUM: 17992    272

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

This patch fixes the following problems in the DECwindows Session Manager
(dxsession) application.  Ungraceful exit can be made through the window
manager's 'Close' button, whose behavior is inconsistent with that of
dxsession's 'End Session' button.
PROBLEM:  (HPAQ210HY) 		(Patch ID: OSF400DX-007)
********
When exiting the session from the DECwindows Session Manager's (dxsession)
'Close' button, the dxsession scratch file is stored in /tmp/smdb-:0.0.defaults.
This exit is ungraceful, and inconsistent with the way that the dxsession
'End Session' handles it.  Included in this fix is the solution, from CLD
SSRT0432U.  The ungraceful exit was fixed by making the window manager's
'Close' button behave in the same manner as dxsession's 'End Session' button
does.  Thus, both buttons are now consistent in providing a graceful exit
of the session manager.  Please remember to "setenv bypassAccessControl".
(an internal debug switch) to bypass the access control of dxsession, if
you're invoking dxsession from a remote host.


FILE(s):

/usr/bin/X11/dxsession          subset OSFOLDX11400
CHECKSUM: 16762    224

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

A potential security vulnerability in talkd has been corrected.
PROBLEM:  (SSRT0446U)		 (Patch ID: OSF400-223)
********
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 OSFCLINET400
CHECKSUM: 26753     32     RCSfile: talkd.c      RCS: 4.2.6.2
/usr/sbin/ntalkd
CHECKSUM: 26753     32

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

This patch corrects two problems that occur when using the dtksh command:

  o dtksh can lose output lines when a pipe or I/O indirection is used.
  o The following error message may be displayed after using a pipe in dtksh:

        dtksh: hist_flush: EOF seek failed errno=9
PROBLEM:  (EVT102013, QAR 50237, QAR 39301) (Patch ID: OSF400CDE-009)
********
This patch fixes a problem in which the dtksh command can lose output lines
when a pipe or I/O indirection is used.

PROBLEM:  (QAR 46945, QAR 32865)	    (Patch ID: OSF400CDE-009)
********
This patch fixes a problem in which the following message may be displayed
after using a pipe in dtksh:

        dtksh: hist_flush: EOF seek failed errno=9


FILE(s):

/usr/dt/bin/dtksh               subset OSFCDEMIN400
CHECKSUM: 23942    848

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

This patch fixes a problem in which the size field of a process displayed by
the acctcom command is displayed incorrectly.
PROBLEM:  (TKTQ 72352)		 (Patch ID: OSF400-230)
********
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 OSFACCT400
CHECKSUM: 53415     40     RCSfile: acctcom.c      RCS: 4.3.21.2

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

This patch fixes a problem in which loadable kernel modules that are loaded
with the kloadsrv daemon at run time, may cause a system panic.
PROBLEM:  (QAR #51743)		 (Patch ID: OSF400-243)
********
This patch fixes a problem in which loadable kernel modules that are loaded
with the kloadsrv daemon at run time, may cause a system panic.  Generally,
this problem will only be seen by engineers who are developing loadable
drivers.

This problem will only be seen in loadable drivers that are compiled with
the "cc -Wb,-static ..." switch and have a reference to the gp register in
the first instruction. The dis command can be used to determine if the gp
register is referenced in the first instruction.


FILE(s):

/sbin/kloadsrv          	    subset OSFBASE400
CHECKSUM: 33680    176     RCSfile: kloadsrv.c      RCS: 4.2.15.6

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

This patch fixes several problems with the network lock daemon, rpc.lockd:

   o NFS mounted file systems may hang.

   o 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

   o An NFS problem may occur. The system displays the following error message:

       	     NFS error 48 cannot bind sockets
PROBLEM:  (QAR 51227)		 (Patch ID: OSF400-246)
********
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: OSF400-246)
********
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 43271)		 (Patch ID: OSF400-246)
********
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 45844)		 (Patch ID: OSF400-246)
********
This patch fixes a problem that can cause an NFS mounted file system to hang
during file locking.

PROBLEM:  (QAR 46298) 		(Patch ID: OSF400-246)
********
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: OSF400-246)
********
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: OSF400-246)
********
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 OSFNFS400
CHECKSUM: 57369    136

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

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.
PROBLEM:  (MCPM40H5M)	 (Patch ID: OSF400-255)
********
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):

/sys/BINARY/lsm.mod             subset OSFLSMBIN400
CHECKSUM: 52624    280 

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

SUPERSEDED PATCHES:	OSF400-046 (46.00)

This patch corrects the following:

- The ar command's -x option, which extracts objects from archive files, may 
  incorrectly output a message stating that the file was not found.

- Fixes the following problems with the ar command:

    o When creating or modifying an archive, the ar command may
      leave a large file in /tmp or in the current directory
      (when the -l option is used).

    o If Patch 46.00 was previously installed (OSF400-046), the ar
      command cannot find object modules specified for deletion
      or extraction if the file name is longer than 13 characters.
      An error message similar to the following is displayed:

       ar: Error: button_previous.gif not found
PROBLEM:  (DJOB3K133, QAR 46595) (Patch ID: OSF400-046)
********
The ar command's -x option, which extracts objects from archive files, may 
incorrectly output 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.

PROBLEM:  (QAR 46095,47425)	 (Patch ID: OSF400-263)
********
When creating or modifying an archive, the ar command may leave a large file
in /tmp or in the current directory  (when the -l option is used) if the
process running ar is aborted with the kill command, a Ctrl/c, or terminates
abnormally on its own.

PROBLEM:  (QAR 51801)		 (Patch ID: OSF400-263)
********
If Patch 46.00 was previously installed (OSF400-046), the ar command cannot
find object modules specified for deletion or extraction if the file name is
is longer than 13 characters.  An error message similar to the following is
displayed:

        ar: Error: button_previous.gif not found


FILE(s):

/usr/ccs/lib/cmplrs/cc/ar	    subset OSFBASE400
CHECKSUM: 24001    400     RCSfile: bsearch.c      RCS: 4.2.6.3

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

This patch fixes several problems with system time when the MICRO_TIME
kernel configuration option is used.

It resolves a one second delay in updating secondary processors after 
changing the system time.

BOOTTIME is now written properly to utmp from a secondary processor
during boot.

Processors are immediately updated when brought on-line during boot
or via the psradm utility.
PROBLEM:  (CLD MCPM21DNQ)	 (Patch ID: OSF400-268)
********
This patch fixes several problems with system time when the MICRO_TIME
kernel configuration option is used.

It resolves a one second delay in updating secondary processors after 
changing the system time.

BOOTTIME is now written properly to utmp from a secondary processor during
boot.

Processors are immediately updated when brought on-line during boot or via
the psradm utility.


FILE(s):

/usr/sys/BINARY/micro_time.o            subset OSFBIN400
CHECKSUM: 14512     21     RCSfile: micro_time.c      RCS: 1.1.10.2

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

This patch fixes a problem in which yppasswd users get the error "password
mismatch, password unchanged" creating passwords longer than 8 characters.
PROBLEM:  (HPAQ8803B, 51543)	 (Patch ID: OSF400-269)
********
This patch fixes a problem in which yppasswd users get the error "password
mismatch, password unchanged" creating passwords longer than 8 characters.


FILE(s):

/usr/bin/yppasswd               subset OSFCLINET400
CHECKSUM: 32773     24     RCSfile: yppasswd.c      RCS: 4.2.12.2
			   RCSfile: yppasswdxdr.c   RCS: 4.2

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

SUPERSEDED PATCHES:	OSF400CDE-002 (176.00)

This patch corrects the following:

- The CDE Application Builder will core dump on second attempt to add pulldown 
  menus to a menubar item.

- The application builder (dtbuilder) core dumps when changing the default
  button in the revolving property editor. 
PROBLEM:  (QAR 46629) (Patch ID: OSF400CDE-002)
********
The CDE application builder will core dump when trying to add a 2nd pulldown 
menu instance.

 1) Launch the CDE application builder from the CDE application manager or 
    start up /usr/dt/bin/dtbuilder

 2) Drag a 'main window' icon from the top left of the window to the root 
    window; click on 'cancel' ignore changing the title

 3) Drag the "File Edit ... Help" menubar into the new main window

 4) Select the menu bar by clicking on it, then click MB3 to bring up another 
    menu, then select Props->Revolving

 5) In the new window, in the Pulldown Menu item, click on the selection button
    and select "Create New Menu". This brings up a 3rd window; in that one, 
    click on "Apply" and "OK" to dismiss it, then click on "Apply" and "OK" on 
    the current window.

 6) Repeat steps 4 and 5; when you try to use the Pulldown Menu the 2nd time, 
    the application will core dump.

PROBLEM:  (CLD STLB32273) 		(Patch ID: OSF400CDE-010)
********
The application builder (dtbuilder) core dumps when changing the default
button in the revolving property editor.

To reproduce the problem:
- Start the Application Builder.
- Click on the 'Custom Dialog', hold down the mouse button, and move the
  cursor out of the main window.
- Double click on the white section of the 'Custom Dialog' window.
- The Revolving Property Editor comes up.  Click on 'Default Button' and change
  it to 'dialog_button_1'.
- Click on 'Apply'.


FILE(s):

/usr/dt/bin/dtbuilder 		subset OSFCDEDEV400
CHECKSUM: 58582   2616    RCS: dtbuilder.c      Revision: 2.1.2.3

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

This patch fixes a kernel memory fault caused by the faa FDDI driver. The panic
was due to incomplete handling of an error condition by the driver ("Timeout
in command request").  The command request buffer was freed, however the
reference to it was not removed from the command request list.  When this list.
When this list was later accessed, the invalid memory reference panic occurred.
PROBLEM:  (UVO105384/QAR 52786)	 (Patch ID: OSF400-280)
********
This patch fixes a kernel memory fault caused by the faa FDDI driver.
The panic was due to incomplete handling of an error condition by the
driver ("Timeout in command request").  The command request buffer
was freed, however the reference to it was not removed from the command
request list.  When this list was later accessed, the invalid memory
reference panic occurred.

A typical stack trace for the fault will look like this:

        cpu_ip_intr()
        _XentInt
        simple_lock_D
        faaintr
        faaintr_2
        _XentInt
        wanTimerSysTick
        softclock_scan
        hardclock


FILE(s):

/sys/BINARY/faa.mod             subset OSFHWBIN400
CHECKSUM: 59534     93 

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

SUPERSEDED PATCHES:	OSF400-214 (293.00)

This patch corrects the following:

- Fixes a problem in which the rpc.rquotad daemon hangs when using quotas
  for NFS filesystems in a TruCluster or Available Server (ASE) v1.4
  environment.

- Fixes the following problems with the rpc.rquotad:

   o When the NFS server is a member of an ASE or TruCluster environment, 
     the rpc.rquotad daemon may exit abnormally.  The abnormal exit causes
     the quota command on NFS clients to not report quotas for NFS mounted
     file systems.

   o When the quota command is repeatedly run from a remote system, the
     virtual size of the rpc.rquotad daemon on the local system will grow
     due to a memory leak.
PROBLEM:  (MCPM21BM5)			 (Patch ID: OSF400-214)
********
This patch fixes a problem in which the rpc.rquotad daemon hangs when
using quotas for NFS filesystems in a TruCluster or Available Server (ASE)
v1.4 environment.

When attempting to get a report on user quotas for NFS mounted filesystems,
the quota command always return 'none'.  The rpc.rquotad daemon on the NFS
server hangs until the connect system call eventually times out.

PROBLEM:  (MCPM21BM5 &  QAR 52038)	 (Patch ID: OSF400-282)
********
This patch fixes the following problems with the rpc.rquotad:

  o When the NFS server is a member of an ASE or TruCluster environment, the
    rpc.rquotad daemon may exit abnormally.  The abnormal exit causes
    the quota command on NFS clients to not report quotas for NFS mounted
    file systems.

  o When the quota command is repeatedly run from a remote system, the
    virtual size of the rpc.rquotad daemon on the local system will grow
    due to a memory leak.


FILE(s):

/usr/sbin/rpc.rquotad               subset OSFCLINET400
CHECKSUM: 48419     32     RCSfile: rpc.rquotad.c      RCS: 1.1.12.3

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

SUPERSEDED PATCHES:	OSF400-189 (203.00), OSF400-189C (297.00)

This patch corrects the following:

- 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:  (SSRT0296U)    (Patch ID: OSF400-189C)
********
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/lib/uucp/uucico                       subset OSFUUCP400
CHECKSUM: 51151    600
/usr/lib/uucp/uucleanup                    subset OSFUUCP400
CHECKSUM: 04329    424     RCSfile: uucleanup.c    RCS: 4.3.10.2
/usr/bin/uucp                              subset OSFUUCP400
CHECKSUM: 38714    448     RCSfile: uucp.c         RCS: 4.3.10.3
                           RCSfile: uucpdefs.c     RCS: 4.3.8.2
                           RCSfile: uucpname.c     RCS: 4.3.7.2
/usr/sbin/uucpd                            subset OSFUUCP400
CHECKSUM: 52075    376     RCSfile: uucpd.c        RCS: 4.3.8.2

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

This patch fixes a problem where the lpq command causes the program to crash
(Memory fault).
PROBLEM:  (QAR 52528)		 (Patch ID: OSF400-290)
********
This patch fixes a problem where the lpq command causes the program to crash
(Memory 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:

Fri Jun 20 14:55:30 1997:
Rank   Pri Owner      Job  Files                                 Total Size
1st    0   root       1    err3                                 28 bytes
2nd    0   root       2    file                                 195 bytes
3rd    0   root       3    file                                 195 bytes
4th    0   root       4    file                                 195 bytes
5th    0   root       5    file                                 195 bytes
6th    0   root       6    file                                 195 bytes
7th    0   root       8    file                                 195 bytes

Memory fault - core dumped


FILE(s):

/usr/lbin/lpd           	subset OSFPRINT400
CHECKSUM: 18046    112     RCSfile: lpd.c      RCS: 4.2.9.3
/usr/bin/lpq            	subset OSFPRINT400
CHECKSUM: 41712     48     RCSfile: lpq.c      RCS: 4.2.5.2

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

This patch fixes a problem with the mouse cursor when the system contains the
HX (PMAGB-BA) graphics option.  The cursor offset is incorrect on the Y Axis
by 2 pixels.
PROBLEM:  (CLD FNO100141,QAR 51990) (Patch ID: OSF400-295)
********
This patch fixes a problem with the mouse cursor when the system contains the
HX (PMAGB-BA) graphics option.  The cursor offset is incorrect on the Y Axis
by 2 pixels.


FILE(s):

/sys/BINARY/sfbp.mod            subset OSFHWBIN400
CHECKSUM: 28705     44

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

SUPERSEDED PATCHES: 	OSF400-299 (306.00)

This patch corrects the following:

- Fixes a problem with the comm command. The comm command may split input
  lines that are greater than 255 characters in length by inserting a
   in the line when written to an output file.  In some
  cases, characters will be truncated.
PROBLEM:  (QAR 53754)		 (Patch ID: OSF400-299)
********
This patch fixes a problem with the comm command. The comm command may split
input lines that are greater than 255 characters in length by inserting
a  in the line when written to an output file.  In some
cases, characters will be truncated.

For example, execute the following command on a system running Digital UNIX
V4.0 or greater:

  # comm -12 /etc/sysconfigtab /etc/sysconfigtab > outfile

When you view the outfile, you will notice that the long lines under the 
"# %%%PCI" header are split. In this case the lines were being split after
Sub_Vid_Mo_Fla and before - O on lines beginning with "PCI_Option = PCI_SE_Rev".


FILE(s):

/usr/bin/comm           	   	subset OSFBASE400
CHECKSUM: 45209     24     RCSfile: comm.c      RCS: 4.2.14.2 

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

SUPERSEDED PATCHES: 	OSF400-066  (66.00), OSF400-218 (235.00),
			OSF400-218-1 (235.01)

This patch corrects the following problems with ddr_config:

- DDR subsystem updated to handle SCSI devices returning a non-standard
  device type.

- ddr_config would sometimes build partial device records.

- ddr_config on Digital UNIX V4.0 was not compatible with input files created 
  prior to this version.

- Adding support for TZS20, and device recognition for TZS2, TLZ10, and
  TLZ1 tape drives
PROBLEM:  (QAR 45730 and QAR 46647) (Patch ID: OSF400-066)
********
DDR partially builds some device records.  This problem is extremely hard to 
detect, as the creation of device records usually happens silently in the 
kernel as it encounters new devices. Symptoms of this error may be slight 
oddities in device behavior. Unfortunately, the extent to which behavior is 
affected cannot be predicted.

The problem can be seen most easily by executing the following:

      Invoke "ddr_config -s disk DEC RZ28B".

      The (failing) output should look as follows:
         Building Device Information for:
           Type = disk
           Vendor ID: "DEC"   Product ID: "RZ28B"

         Applying Modifications from Device Record for :
           Vendor ID: "DEC"   Product ID: "RZ28"
             TagQueueDepth = 0x4a

The (correct) output should look as follows:

         Building Device Information for:
           Type = disk
           Vendor ID: "DEC"   Product ID: "RZ28B"

         Applying Modifications from Device Record for :
           Vendor ID: "DEC"   Product ID: "RZ28"
             TagQueueDepth = 0x4a

         Applying Modifications from Device Record for :
           Vendor ID: "DEC"   Product ID: "RZ28B"
             TagQueueDepth = 0x40

PROBLEM:  (QAR 45730 and QAR 46647) (Patch ID: OSF400-066)
********
The "ddr_config -x" option fails to compile a cam_data.c file from a version 
prior to Digital UNIX v4.0.

The following error messages will be reported:

       ddr_config.ORIG: Line 3233: Syntax Error
       ddr_config.ORIG: Line 3233: Failed parsing DENSITY_TBL entry

       Conversion of /sys/data/cam_data.c failed. 

Line numbers are relative to the temporary file /tmp/cam_data.tmp

Looking at the /tmp/cam_data.tmp file, the error occurs between two records
separated by a comma. For example:

       TYPE
       Record_A = { ....
       },                           <----- fails here
       Record_B = { ...
       };

PROBLEM:  (HPAQB16E6)		 (Patch ID: OSF400-218)
********
The DDR subsystem did not appropriately handle SCSI devices that return
non-standard device types. The standard device types range from 0 (disk
device) to 9 (Communications Device).

For example, a custom SCSI device that returns a device type of UNKNOWN (0x1f)
could panic the system with the following message:

   "trap: invalid memory read access from kernel mode"

A device with a non-standard device type would ordinarily not be shown as 
present on the system as it would require a custom SCSI device driver to
access it (one which does not come with the base operating system).

Note: Non-standard device types are supported by CAM in pre-v4.0 releases.

PROBLEM:  		(Patch ID: OSF400-303)
********
Adding support for TZS20, and device recognition for TZS2, TLZ10, and
TLZ1 tape drives.


FILE(s):

/sbin/ddr_config                subset OSFHWBASE400
CHECKSUM: 43497    256     RCSfile: ddr_config.c      RCS: 1.1.7.2
/sys/BINARY/ddr.mod		subset OSFBIN400
CHECKSUM: 44595     43 
/etc/.mrg..ddr.db               subset OSFHWBASE400
CHECKSUM: 47113      3
/etc/.new..ddr.db		subset OSFHWBASE400 
CHECKSUM: 16024     17 
/etc/.mrg..ddr.dbase            subset OSFHWBASE400
CHECKSUM: 63432     28     RCSfile: .mrg..ddr.dbase  RCS: 1.1.10.2
/etc/.new..ddr.dbase		subset OSFHWBASE400 
CHECKSUM: 26639     57 
/genvmunix              	subset OSFHWBASE400
CHECKSUM: 38609   7631 

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

This patch fixes a problem related to misinterpretation of multibyte characters
by the diff command. The problem also affects the delta command of SCCS.
The symptom of the problem in the diff command is that it sometimes treats
a text file containing multibyte characters as a binary file.  The symptom
of the problem in the delta command is that it sometimes fails to check in
a program source file containing multibyte characters.
PROBLEM:  (CLD TKTQ60593)		 (Patch ID: OSF400-305)
********
The problem in the diff command that is fixed by this patch is that the
command sometimes misinterprets a text file containing multi-byte
characters as a binary file. The character misinterpretation occurs only
when a multi-byte character falls on a buffer boundary, which breaks the
character into partial characters on each side of the boundary.
This condition does not occur in all files, so the problem is sporadic.

SCCS's delta command uses the bdiff command that, in turn, uses diff to
generate a differences file for the original and the new version of a
program source file. When the diff command reports a "Binary files differ"
error message, the delta command does not correctly interpret this error
and concludes that there is no difference between the new version of the
file and the original. By fixing the problem in diff, the problem in the 
delta command is also fixed.


FILE(s):

/sbin/diff              	subset OSFBASE400
CHECKSUM: 38002     56     RCSfile: diff.c      RCS: 4.2.10.4
			   RCSfile: diffdir.c   RCS: 4.2.22.2
			   RCSfile: diffreg.c   RCS: 4.2.17.3
/usr/bin/diff           	subset OSFBASE400
CHECKSUM: 21689     56     RCSfile: diff.c      RCS: 4.2.10.4
			   RCSfile: diffdir.c   RCS: 4.2.22.2
			   RCSfile: diffreg.c   RCS: 4.2.17.3

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

The S3 Trio64V+ graphics card (PB2GA-JC or PB2GA-JD) is not being uniquely
identified by the driver at startup.
PROBLEM:  (QAR 50202) 		(Patch ID: OSF400-309)
********
The S3 Trio64V+ graphics card (PB2GA-JC or PB2GA-JD) was not being uniquely
identified by the driver at startup.  The identification string that the
driver prints at startup now includes the "V+" suffix to distinguish between
the S3 Trio64V+ card and the original S3 Trio64 card.


FILE(s):

/usr/sys/include/io/dec/ws/s3trio.h             subset OSFBINCOM400
CHECKSUM: 58058      9     RCSfile: s3trio.h      RCS: 1.1.24.2
/sys/BINARY/s3trio.mod          		subset OSFHWBIN400
CHECKSUM: 45775     42 

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

SUPERSEDED PATCHES:	OSF400DX-003 (182.00)

This patch corrects the following:

- Bookreader aborts with a segmentation fault 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).

- A potential security vulnerability has been discovered, where under certain
  circumstances, system integrity may be compromised.  This may be in the 
  form of improper file or privilege management. Digital has corrected this
  potential vulnerability.
PROBLEM:  (MGO101893, HPXQ931C7) (Patch ID: OSF400DX-003)
********
Bookreader aborts with a segmentation fault 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.

PROBLEM:  (HPAQ50DHH,SSRT0514U)		 (Patch ID: OSF400DX-012)
********
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/bin/X11/dxbook			subset OSFX11400
CHECKSUM: 53236    800     
/usr/lib/X11/uid/DXBookreader_1_2.uid	subset OSFX11400
CHECKSUM: 63113    164    

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

This patch fixes a problem in which the io_zero() system call returns an
incorrect value on an AlphaServer 1000.
PROBLEM:  (QAR  51566,49877)		 (Patch ID: OSF400-321)
********
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):


/sys/BINARY/lca.mod             subset OSFHWBIN400
CHECKSUM: 08053     21
/sys/BINARY/apecs.mod           subset OSFHWBIN400
CHECKSUM: 32096     21     RCSfile: apecs.c      RCS: 1.1.54.2

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

This patch fixes the following problems:

o  The atom command terminates with SIGSEVG signal if the threaded
   program being instrumented has a stripped shared library.

o  The "atom -all -env threads" command produces an instrumented version of a
   threaded (eg DCE) application that will not execute correctly, with either
   "-tool third" or "-tool hiprof" tool options.
PROBLEM:  (QAR 53676,44972)	 (Patch ID: OSF400-325)
********
The atom command terminates with a SIGSEGV signal if the threaded program
being instrumented uses a stripped shared library.

The typical symptoms of the atom instrumentation failure are warnings like
this:

  > atom -tool third -env threads server
  atom: Error: Command '/tmp/atomAAAaaBpfa/server.tool' terminated with receipt
  of SIGSEGV signal.
  atom: Error: Run atom with the -debug switch to see if the error is in the
  instrumentation code.
  >

Using the -debug switch as suggested will show a segmentation fault in the
search_procedures routine, for example:

  > atom -tool third -env threads server -debug
  dbx version 3.11.10
  Type 'help' for help.

  [2] stop in InstrumentAll
  signal Segmentation fault at >*[search_procedures, 0x12008d1d0] ldl r2, 12(r2)
  (/bin/dbx)

One kind of application that triggers this problem is one that uses DCE,
because the libdce.so is stripped. However, any other threaded program
that uses a stripped shared library can trigger it.

PROBLEM:  (QAR 51465)			 (Patch ID: OSF400-325)
********
A threaded program may not execute correctly when instrumented with the
"atom -tool third -all -env threads" or "atom -tool hiprof -all -env threads"
command. This is because these commands instrument shared libraries (such as
libc.so) that may be called by critical sections of libpthread.so.

A workaround is to avoid instrumenting the system-libraries, by omitting
the -all option from the atom command line or by appending the
"-excobj libpthreads.so -excobj libmach.so -excobj libexc.so -excobj libc.so"
options to the atom command.

This patch changes the tools so that they always exclude these system-libraries
from instrumentation, which results in the instrumented program executing
correctly.


FILE(s):

/usr/ccs/lib/cmplrs/atom/Atom/aom.o                     subset OSFPGMR400
CHECKSUM: 52825    989
/usr/ccs/lib/cmplrs/atom/tools/hiprof.inst.o            subset OSFSDE400
CHECKSUM: 55994     94
/usr/ccs/lib/cmplrs/atom/tools/hiprof.threads.inst.o    subset OSFSDE400
CHECKSUM: 45565    100
/usr/ccs/lib/cmplrs/atom/tools/third.anal.o             subset OSFSDE400
CHECKSUM: 63470    161
/usr/ccs/lib/cmplrs/atom/tools/third.inst.o             subset OSFSDE400
CHECKSUM: 07674    260
/usr/ccs/lib/cmplrs/atom/tools/third.threads.anal.o     subset OSFSDE400
CHECKSUM: 47998    171
/usr/ccs/lib/cmplrs/atom/tools/third.threads.inst.o     subset OSFSDE400
CHECKSUM: 20673    261

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

SUPERSEDED PATCHES:	OSF400-103 (103.00)

This patch corrects the following:

- AlphaServer 2100A systems crash during boot with greater than 1GB of memory 
  installed.

- Fixes a problem that occurs on an AlphaServer 2100A system.  When the system
  is shut down using the "shutdown -r" command, the system will not reboot.
PROBLEM:  (EMZB83716, QAR 48019) (Patch ID: OSF400-103)
********
The Digital 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: OSF400-327)
********
This patch fixes a problem that occurs on an AlphaServer 2100A system.
When the system is shut down using the "shutdown -r" command, the system
will not reboot.


FILE(s):

/sys/BINARY/cbus2_pci_mult.mod			subset OSFHWBIN400
CHECKSUM: 56383     53
/sys/BINARY/cbus2_pci.mod			subset OSFHWBIN400
CHECKSUM: 07599     52 
/usr/sys/include/arch/alpha/hal/cbus2_pci.h     subset OSFBINCOM400
CHECKSUM: 36011     36     RCSfile: cbus2_pci.h     RCS: 1.1.15.2

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

This patch fixes a problem that causes the 'doconfig' program to hang when
invoked by the uuxqt program.
PROBLEM:  (QAR 53588) 		  (Patch ID: OSF400-337)
********
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 OSFUUCP400
CHECKSUM: 21308    448     RCSfile: uuxqt.c      RCS: 4.3.8.3

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

SUPERSEDED PATCHES:	OSF400-086 (86.00), OSF400-267 (282.00)

This patch corrects the following:

- Allows user control messages to be passed between a STREAMS pty pair.
  This is a new feature.

- Applications running System V pseudoterminal slave pty can hang forever on
  open() system call.

- A potential security vulnerability has been discovered, where under certain
  circumstances, a kernel memory fault panic may occur.
PROBLEM:  (USG-03878) 		(Patch ID: OSF400-086)
********
This fix allows user control messages to be passed between a STREAMS pty pair.
This capability was not available in the original released software.

PROBLEM:  (QAR 52115) 		(Patch ID: OSF400-267)
********
An application running System V using psuedoterminals may hang if it opens
the slave side before the master is open.

If the slave side of a System V master psuedoterminal is opened before it is
unlocked on the master side via unlockpt(), the calling process will block
forever on the open() even after the unlockpt() has been issued and the lock
flag lifted from the device.  Once the out of sequence race condition occurs,
the slave device cannot be opened again by any process until the original hung
process is terminated.

PROBLEM:  (SSRT0476U, QAR53372)	 (Patch ID: OSF400-339)
********
A potential security vulnerability has been discovered, where under certain
circumstances, a kernel memory fault panic may occur.  Digital has corrected
this potential vulnerability.

The kernel memory fault panic will have a stack trace of the panic'ing process
as follows:

   1 panic(s = 0xfffffc00006a13e0 = "kernel memory fault")
   2 trap()
   3 _XentMM()
   4 putq_owned
   5 putq
   6 pts_wput
   7 csq_lateral
   8 puthere
   9 ldtty_wput
  10 csq_turnover
  11 osr_pop_subr
  12 osr_close_subr
  13 pse_close
  14 speclose
  15 clearalias
  16 exit
  17 rexit
  18 syscall
  19 _Xsyscall


FILE(s):

/sys/BINARY/pts.mod		subset OSFBIN400
CHECKSUM: 00507    120 

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

SUPERSEDED PATCHES:	OSF400-043 (43.00)

This patch corrects the following:

- Enhancements to the date command for Year 2000 support.

- Fixes the problem in which 'date' command is unable to set the date to
  January 1, 1970 00:00:00 GMT or February 29, 2000.
PROBLEM:  (TKTQ22519, UVO104025, QAR 45258) (Patch ID: OSF400-043)
********
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.

	Using the XPG4-UNIX format:

	date mmddHHMM[yy]

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

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.

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.

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: OSF400-340)
********
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 OSFBASE400
CHECKSUM: 30685      1     
/usr/bin/date					    subset OSFBASE400
CHECKSUM: 02858     24     RCSfile: date.c      RCS: 4.2.34.3
/sbin/date					    subset OSFBASE400
CHECKSUM: 48480     24     RCSfile: date.c      RCS: 4.2.34.3

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

SUPERSEDED PATCHES:	OSF400-034 (34.00)

This patch corrects the following:

- mountd dies without logging the event in the daemon.log file and there is
  no core file.

- A potential security vulnerability has been discovered, where under certain
  circumstances, system integrity may be compromised. This may be in the form
  of improper file or privilege management. Digital has corrected this
  potential vulnerability.
PROBLEM:  (HPXQ36487/QAR 45362) 	(Patch ID: OSF400-034)
********
'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 
third-party product (where a large number was greater than 100 of the 
third-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: OSF400-343)
********
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 OSFNFS400
CHECKSUM: 10085     56     RCSfile: mountd.c      RCS: 4.2.43.4

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

SUPERSEDED PATCHES:     OSF400-331 (339.00)

This patch corrects the following:

-  Allows the uusend, uustat, uucpd, and uudecode commands to work correctly
   when the customer builds a hashed passwd database using a non-default page
   file block size.
PROBLEM:  (Patch ID: OSF400-331B)
********
This patch allows the uusend, uustat, uucpd, and uudecode commands to work
correctly when the customer builds a hashed passwd database using a non-default
page file block size.


FILE(s):

/usr/bin/uusend         subset OSFUUCP400
CHECKSUM: 20385    432     RCS: uusend.c      Revision: 4.3.10.2
/usr/bin/uustat         subset OSFUUCP400
CHECKSUM: 28264    408     RCS: uustat.c      Revision: 4.3.14.3

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

SUPERSEDED PATCHES:     OSF400-331 (339.00)

This patch corrects the following:

- Allows customers to create hashed passwd databases from large passwd files
  by using a new option (-s) to the mkpasswd command.  The -s option increases
  the block size of the database page file.
PROBLEM:  (Patch ID: OSF400-331C)
********
When the /etc/passwd file is very large, a performance degradation may occur.

When the number of passwd entries reaches up into the 30,000 to 80,000 range
or greater, mkpasswd will sometimes fail to create a hashed (ndbm) database.
Since the purpose of this database is to allow for efficient (fast) searches
for passwd file information, failure to build it causes commands that rely
on it to do a linear search of /etc/passwd.  This results in a serious per-
formance degradation for those commands.  This patch allows the admin,
cdc, comb, delta, get, lprsetup, prs, rmdel, sact, sccs, unget and val
commands to work correctly when the customer builds a hashed passwd data-
base using a non-default page file block size.

For customers choosing to use the mkpasswd -s option to avoid this type of
failure, a potential database/binary compatibility problem may arise.  If a
customer application that accesses the password database created by mkpasswd
is built statically (non-shared), that application will be unable to read
from or write to the password database correctly.  This would cause the
customer application to fail either by generating incorrect results or by
possibly dumping core.  Any statically linked application would be affected
if it directly or indirectly calls any of the libc ndbm routines documented
in the ndbm(3) man page and then accesses the password database.  To remedy
this situation, the customer would need to re-link the application.

Customers who do not use the mkpasswd -s option will not see this database/
binary compatibility problem.


FILE(s):
/usr/bin/admin                                  subset OSFSCCS400
CHECKSUM: 07806    376     RCS: admin.c      Revision: 4.2.7.2
/usr/bin/cdc                                    subset OSFSCCS400
CHECKSUM: 43643    368 
/usr/bin/comb                                   subset OSFSCCS400
CHECKSUM: 36985    360     RCS: comb.c      Revision: 4.2.5.2
/usr/bin/delta                                  subset OSFSCCS400
CHECKSUM: 03098    376     RCS: delta.c      Revision: 4.2.8.6
/usr/bin/get                                    subset OSFSCCS400
CHECKSUM: 62496    384     RCSfile: get.c            RCS: 4.2.9.5
                           RCSfile: catgets.c        RCS: 4.2.10.3
                           RCSfile: fgets.c          RCS: 4.2.10.2
                           RCSfile: getopt.c         RCS: 4.2.9.2
                           RCSfile: getpasswd.c      RCS: 1.1.13.3
                           RCSfile: gets.c           RCS: 4.3.12.2
                           RCSfile: getwd.c          RCS: 4.2.9.2
                           RCSfile: getenv.c         RCS: 4.2.11.4
                           RCSfile: sia_getpass.c    RCS: 1.1.17.6
                           RCSfile: getcwd.c         RCS: 4.2.12.2
                           RCSfile: __getmbcurmax.c  RCS: 1.1.7.2
                           RCSfile: siad_getpass.c   RCS: 1.1.25.8
                           RCSfile: NLgetamsg.c      RCS: 4.2.11.2
                           RCSfile: getcommon.c      RCS: 4.2.21.2
                           RCSfile: getnetgrent.c    RCS: 4.2.11.2
                           RCSfile: sia_getmsg.c     RCS: 1.1.6.2
                           RCSfile: pmap_getport.c   RCS: 4.2.20.2
                           RCSfile: getgroup.c       RCS: 1.1.13.3
                           RCSfile: sia_getgroup.c   RCS: 1.1.17.7
                           RCSfile: sia_get_grps.c   RCS: 1.1.2.2
                           RCSfile: Ugetut.c         RCS: 1.1.2.9
                           RCSfile: siad_getgrp.c    RCS: 1.1.20.10
                           RCSfile: getgroup_r.c     RCS: 1.1.13.3
                           RCSfile: getut.c          RCS: 4.2.12.11
                           RCSfile: getline.c        RCS: 4.2
/usr/sbin/lprsetup                              subset OSFPRINT400
CHECKSUM: 60828    424     RCSfile: lprsetup.c       RCS: 4.2.14.4
/usr/bin/prs                                    subset OSFSCCS400
CHECKSUM: 57125    384     RCSfile: prs.c            RCS: 4.2.7.4
/usr/bin/rmdel                                  subset OSFSCCS400
CHECKSUM: 09904    368 
/usr/bin/sact                                   subset OSFSCCS400
CHECKSUM: 56060    344 
/usr/bin/sccs                                   subset OSFSCCS400
CHECKSUM: 53179    344     RCSfile: sccs.c           RCS: 4.2.8.4
/usr/bin/unget                                  subset OSFSCCS400
CHECKSUM: 51967    344     RCSfile: unget.c          RCS: 4.2.5.3
/usr/bin/val                                    subset OSFSCCS400
CHECKSUM: 54596    360     RCSfile: val.c            RCS: 4.2.5.3

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

SUPERSEDED PATCHES:     OSF400-331 (339.00)

This patch corrects the following:

- Allows the uusend voliod commands to work correctly when the customer 
  builds a hashed passwd database using a non-default page file block
  size.
PROBLEM:                (Patch ID: OSF400-331D)
********
This patch allows the uusend voliod commands to work correctly when the customer
builds a hashed passwd database using a non-default page file block size.


FILE(s):

/sbin/voliod                                    subset OSFLSMBASE400
CHECKSUM: 05806    336     RCSfile: voliod.c       RCS: 1.1.8.4

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

SUPERSEDED PATCHES:     OSF400-073 (73.00), OSF400-112 (112.00),
			OSF400-122 (122.00)

This patch corrects the following:

- Correct quota command to return worst error status on exit.

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

- Correct quota command to return most severe error status on exit.
PROBLEM:  (HPXQ87072) 		(Patch ID: OSF400-073)
********
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.

PROBLEM:  (QAR 49370)		 (Patch ID: OSF400-112)
********
Correct problems where quota program was not returning worst error as exit 
status. 
                                                              
PROBLEM:  (QAR 49941) 		(Patch ID: OSF400-122)
********
Correct problems where quota program was not returning most severe error as 
exit status.


FILE(s):

/usr/sbin/edquota				subset OSFBASE400
CHECKSUM: 27396     40     RCSfile: edquota.c      RCS: 4.2.28.2
/usr/lib/nls/msg/en_US.ISO8859-1/edquota.cat    subset OSFBASE400
CHECKSUM: 26567      2     
/usr/sbin/quota					subset OSFBASE400
CHECKSUM: 55150     40     RCSfile: quota.c        RCS: 4.2.36.5
/usr/lib/nls/msg/en_US.ISO8859-1/quota.cat	subset OSFBASE400
CHECKSUM: 15489      1    

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

SUPERSEDED PATCHES:	OSF400-015 (15.00), OSF400-162 (162.00)

This patch corrects the following:

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

- Corrects a problem where packet reception on the DE500-XA PCI Fast 
  Ethernet interface (device mnemonic "tu") comes to a halt under heavy system 
  and network load.

- An enhancement to the ethernet driver for the DE500-XA Fast Ethernet
  Interface.  This patch improves the failover time in an ASE environment
  when the cluster members use DE500-XA interfaces.
PROBLEM:  (OSF_QAR 45779)	 (Patch ID: OSF400-015)
********
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:  (CLD SOO100882)	 (Patch ID: OSF400-162)
********
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)

PROBLEM:  (QAR 54987)		 (Patch ID: OSF400-349)
********
This patch is an enhancement to the ethernet driver for the DE500-XA Fast
Ethernet Interface.  This patch improves the failover time in an ASE
ASE environment when the cluster members use DE500-XA interfaces.


FILE(s):

/sys/BINARY/tu.mod 		subset OSFHWBIN400
CHECKSUM: 28622     40 

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

SUPERSEDED PATCHES:	OSF400-318 (327.00)

This patch corrects the following:

- Fixes problem in which 'awk' consume memory until the machine swaps itself
  and core dumps with following error:

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

- Fixes a problem in which the awk -FS command does not display the correct
  output.
PROBLEM:  (QAR 30334)		 (Patch ID: OSF400-318)
********
This patch fixes problem in which 'awk' will consume memory until the machine
swaps itself and core dumps with the following error:

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

PROBLEM:  (QAR 47890, QAR 52639) 	(Patch ID: OSF400-358)
********
This patch fixes a problem in which the awk -FS command does not display the
correct output. For example,

     echo "pat@lampert@31050" | awk '{FS = "@";print $1$2$3}'

Should print "patlampert31050". Instead, it prints "pat@lampert@31050",
which is incorrect.


FILE(s):

/usr/bin/nawk           subset OSFBASE400
CHECKSUM: 44724    152 
/usr/bin/awk		subset OSFBASE400
CHECKSUM: 44724    152 

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

This patch fixes a problem that affects systems running the audit subsystem.
When reading directives from a file, the auditmask utility does not correctly
handle lines formatted as follows:   event    fail
PROBLEM:  (QAR 45629) 			(Patch ID: OSF400-359)
********
This patch fixes a problem that affects systems running the audit subsystem.
When reading directives from a file, the auditmask utility does not correctly
handle lines formatted as follows:

     event   fail

  To reproduce this problem, do the following:

   WARNING:  This particular test for the bug will change the
             audit mask on your system.  Be prepared to restore it to
             the previous state.

  1. Become root and create an audit event file, for example,
     /etc/sec/my_audit_events, containing the following events:

        open                  fail
        fstat   succeed  fail
        fchmod                 nosucceed        fail
        close                 succeed
        unlink

  2. Clear the auditmask:

     /usr/sbin/auditmask -n

  3. Load the new event file:

     /usr/sbin/auditmask < /etc/sec/my_audit_events

  4. List the event:

     /usr/sbin/auditmask

  A bug is indicated by the absence of the "open fail" event.


FILE(s):

/usr/sbin/auditmask             subset OSFBASE400
CHECKSUM: 44458     32     RCSfile: auditmask.c      RCS: 1.1.23.2

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

This patch fixes the following problems:

o  The uprofile and kprofile commands report incorrect statistics on an SMP
   system or when trying to measure EV5 events other than cycles.

o  The pfm driver ioctl PCNT5GETCNT returns incorrect data.

o  An unstoppable stream of pfm interrupts is produced if an EV5 machine is
   rebooted with the pfm driver active.

o  The pfm(8), uprofile(1), and kprofile(1) manpages do not describe the
   EV5 statistics supported by the software.

All users of the pfm driver and uprofile or kprofile commands should
install this patch.
PROBLEM:  (QAR 54099)		 (Patch ID: OSF400-371)
********
The uprofile and kprofile commands will report incorrect statistics on an
SMP system or when trying to measure EV5 events other than cycles.

Without this patch, results from CPUs other than CPU 0 will not be reported.
Also, the "cycles" statistic will always be reported regardless of the 
user's selection of EV5 events to measure.

PROBLEM:  (QAR 49430)		 (Patch ID: OSF400-371)
********
The pfm driver ioctl PCNT5GETCNT returns incorrect data.

PROBLEM:  (QAR 49456)		 (Patch ID: OSF400-371)
********
Interrupts are not stopped when the pfm device is closed.  This leads to
an unstoppable stream of performance counter interrupts if an EV5 machine
is rebooted with the driver active.  When rebooting, the console reports:

        unexpected exception/interrupt through vector 650
        .
        .
        .
        unexpected exception/interrupt through vector 650

continuously.  The only way out is to reset the system.

PROBLEM:  (QAR 54562)		 (Patch ID: OSF400-371)
********
The pfm(8), uprofile(1), and kprofile(1) manpages do not describe the EV5
statistics supported by the software.


FILE(s):

/sys/BINARY/pfm.mod             	subset OSFHWBIN400
CHECKSUM: 23601     18
/usr/sys/include/sys/pfcntr.h           subset OSFBINCOM400
CHECKSUM: 25022     14     RCSfile: pfcntr.h   RCS: 1.1.25.2
CHECKSUM: 37517      7

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

This patch fixes several LSM problems related to the volunroot, volrootmir,
and vol-reconfig scripts.
PROBLEM:  (QAR 54779)		 (Patch ID: OSF400-370)
********
This patch fixes several LSM problems related to the volunroot, volrootmir,
and vol-reconfig scripts.

PROBLEM:  (QAR 46783)		 (Patch ID: OSF400-370)
********
This patch fixes a problem in which the volrootmir script does not detect
the fact that devices with different suffixes are actually the same type
of device and should be allowed.

PROBLEM:  (QAR 46368)		 (Patch ID: OSF400-370)
********
This patch fixes a problem in which the volrootmir script does not support
either the -h or help options.

PROBLEM:  (QAR 46369)	  	(Patch ID: OSF400-370)
********
This patch fixes a problem in which the volrootmir script calls the volencap
script with an invalid argument, "nlog=1". This option is no longer supported
by volencap.

PROBLEM:  (QAR 44088)		 (Patch ID: OSF400-370)
********
This patch fixes a problem in which the volunroot script uses a disk device
name instead of the disk media name when performing unencapsulation
requirement checks.

PROBLEM:  (QAR 45117)		 (Patch ID: OSF400-370)
********
This patch fixes a problem in which the volunroot/vol-reconfig script invokes
the shutdown command incorrectly, essentially passing it a time value without
the necessary '+' symbol.

PROBLEM:  (QAR 46738)		 (Patch ID: OSF400-370)
********
This patch fixes a problem in which the vol-reconfig script does not properly
recover from a disk failure. The problem is with the recover.sh script.


FILE(s):

/usr/sbin/volrootmir            subset OSFLSMBASE400
CHECKSUM: 25696     14     RCSfile: volrootmir.sh      RCS: 1.1.17.2
/usr/sbin/volunroot             subset OSFLSMBASE400
CHECKSUM: 46345      9     RCSfile: volunroot.sh       RCS: 1.1.19.2
/sbin/vol-reconfig              subset OSFLSMBASE400
CHECKSUM: 09089     13     RCSfile: vol-reconfig.sh    RCS: 1.1.23.2

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

This patch fixes two system run level problems:

o On a system running LSM, whenever there is a run level change, the
  lsmbstartup script runs.  This causes root to be mounted read/write
  in single-user mode.

o The bcheckrc command script continues to run even if there is an
  invalid root entry. This leaves the system in an unusable state
  in single-user mode.
PROBLEM:  (QAR 51645,41116,48720,50207) (Patch ID: OSF400-364) 
********
This patch fixes two system run level problems:

  o On a system running LSM, whenever there is a run level change, the
    lsmbstartup script runs.  This causes root to be mounted read/write
    in single-user mode.

  o The bcheckrc command script continues to run even if there is an
    invalid root entry. This leaves the system in an unusable state
    in single-user mode. Root is not mounted writeable and cannot be
    modified with the mount -u command.

FILE(s):

/sbin/.mrg..bcheckrc            subset OSFBASE400
CHECKSUM: 08107      4
/sbin/.new..bcheckrc            subset OSFBASE400
CHECKSUM: 56283      3

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

This patch fixes a probem that affects systems using databases with the btree
file format.  Only applications using btree in libdb.a or libdb.so are affected
and may return incorrect data or crash.
PROBLEM:  (QAR53001) 		(Patch ID: OSF400-365)
********
This patch fixes a probem that affects systems using databases with the btree
file format.  Only applications using btree in libdb.a or libdb.so are affected
and they may return incorrect data or crash.

This bug is not easily reproducible. The btree bug can be observed in large 
database applications that sometimes crash or access incorrect data.


FILE(s):

/usr/shlib/libdb.so             subset OSFBASE400
CHECKSUM: 29122     96

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

SUPERSEDED PATCHES:	OSF400-038 (38.00), OSF400-077 (77.00),
			OSF400-174 (174.00)

This patch corrects the following:

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

- A performance problem that the linker has with hidden symbols (-hidden flag) 
  and large numbers of shared library files (.so files).

- Fixes a problem where use of "ld -r" will change symbol preemption behavior.

- Fixes four linker problems: Hidden/export symbols, Assert getting generated
  with R_GPVALUE relocations, improper Text segment alignment processing, and
  linker memory managment problem processing c++ symbols.
PROBLEM:  (QAR 42274) 		(Patch ID: OSF400-038)
********
Link times increases exponentially when using ld's -hidden option.

PROBLEM:  (QAR 43546)		 (Patch ID: OSF400-038)
********
The linker is extremely slow when linking against a large number of .so
(shared library) files.

PROBLEM:  (QAR 47588) 		(Patch ID: OSF400-077)
********
Linker executes an error exit with chmod() permission problems and certain 
data-segment alignments for OMAGIC files.

PROBLEM:  (QAR 48365)		 (Patch ID: OSF400-077)
********
Linker hangs (fails to complete execution).

PROBLEM:  (QAR 49301) 		(Patch ID: OSF400-174)
********
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: OSF400-375)
********
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.
The error produces output messages in the following form:

assertion failed: EX at ../../../../../../src/usr/ccs/bin/ld/relocate.c line
2471

PROBLEM:  (QAR 55440)		 (Patch ID: OSF400-375)
********
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: OSF400-375)
********
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: OSF400-375)
********
The linker fails to link a c++ program issuing an "ld_munmap error" message.


FILE(s):

/usr/ccs/lib/cmplrs/cc/ld                        subset OSFBASE400
CHECKSUM: 15744    824     RCSfile: ld.c         RCS: 4.3.87.5
			   RCSfile: uldgnum.c    RCS: 1.1.13.2
			   RCSfile: ldgetname.c  RCS: 4.3.5.2
			   RCSfile: lderr.c      RCS: 1.1.2.2
			   RCSfile: ldr_atexit.c RCS: 4.2.11.4
			   RCSfile: schyield.s   RCS: 1.1.2.2
			   RCSfile: ldr_dummy.c  RCS: 4.2.17.2
			   RCSfile: ldr_status.c RCS: 4.2.8.3
			   RCSfile: ldr_load.c   RCS: 1.1.3.5

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

SUPERSEDED PATCHES:	OSF400-097 (97.00)

This patch corrects the following:

- Corrects a problem with packets out of order experienced by some PATHWORKS
  Netbuei clients.

- Fixes a memory leak problem that occurs with the STREAMS Data Link Bridge
  (dlb) pseudodevice driver. This problem could cause a "freeing free mbuff"
  panic when system memory is exhausted.
PROBLEM:  (QAR 47254  CLD HPXQ77186) (Patch ID: OSF400-097)
********
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: OSF400-377)
********
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):

/sys/BINARY/dlb.mod		subset OSFBIN400
CHECKSUM: 21575    139     

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

This patch lets dtmail correctly display Japanese and Korean mail messages
that do not have a Content-Type header.
PROBLEM:  (QAR 55268)		 (Patch ID: OSF400CDE-011)
********
This patch lets dtmail correctly display Japanese and Korean mail messages
that do not have a Content-Type header.

The patch only takes effect when you run dtmail in a Japanese or Korean locale.
It is useful if you receive mail from older Japanese or Korean mail programs
that encode their messages in ISO-2022-JP or ISO-2022-KR, but do not include
a MIME Content-Type header.  That header normally identifies the encoding of
the mail message like this:

    Content-Type: text/plain; charset=ISO-2022-JP

For Japanese and Korean mail messages that do not include this header, dtmail
currently assumes that they are encoded in us-ascii.  As a result, it does
not display them correctly.  This patch fixes the problem by telling dtmail
to assume that the messages are encoded in ISO-2022-JP for Japanese locales
and ISO-2022-KR for Korean locales.


FILE(s):

/usr/dt/config/svc/OSF1.lcx             subset OSFCDEDT400
CHECKSUM: 36237     31     RCSfile: OSF1.lcx      RCS: 2.1.10.2

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

The X server can loop or run out of sockets when dealing with a font server.
PROBLEM:  (ISO100289, TKTR90902) 	(Patch ID: OSF400X11-018)
********
When running the X server with a font server in its font path, if the font
server goes away, the X server starts consuming almost all of the CPU time
on the system.

PROBLEM:  (ISO100291) 			(Patch ID: OSF400X11-018)
********
If you repeatedly add and then remove font servers from the X server's font
path, the X server will eventually run out of sockets because the X server
is not releasing sockets correctly.


FILE(s):

/usr/shlib/X11/libfont.so               subset OSFX11400
CHECKSUM: 59296    200
/usr/shlib/X11/libfr_Speedo.so          subset OSFX11400
CHECKSUM: 30633     96
/usr/shlib/X11/libfr_Type1.so           subset OSFX11400
CHECKSUM: 55201    200
/usr/shlib/X11/libfr_fs.so              subset OSFX11400
CHECKSUM: 33576    120

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

SUPERSEDED PATCHES: 	OSF400X11-012 (202.00), OSF400X11-015 (254.00)

This patch corrects the following:

- Fixes the following problem in the Motif toolkit.  The drag-n-drop operation
  fails, which may cause Motif applications to abort.

- Fixes the following problems in the Motif toolkit. Message strings with
  consecutive newline charaters("\n\n"), lose one newline for every two
  specified.  A character height of zero is possible, and the message box
  containing the string will not be resized properly.

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

- Fixes the memory leak in the Motif text widget when changing colors using
  XtVaSetValues().
PROBLEM:  (USG-00555)		 (Patch ID: OSF400X11-012)
********
When using the Motif toolkit, message strings with consecutive newline
charaters("\n\n"), lose one newline for every two specified.  As a result,
a character height of zero is possible.  The message box containing the
string with lost spaces will not be resized properly, when the target display
is running in CDE mode.

PROBLEM:  (USG-00572 and QAR 51941) (Patch ID: OSF400X11-015)
********
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:  (MGO102524)		 (Patch ID: OSF400X11-020)
********
The Motif text widget is afflicted with a memory leak.  A small amount of
dynamic memory is lost each time the colors are changed using XtVaSetValues().


FILE(s):

/usr/lib/libXm.a                subset OSFXLIBA400
CHECKSUM: 04919   2357
/usr/shlib/libXm.so             subset OSFX11400
CHECKSUM: 59151   2224

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

This patch corrects a problem when exitting an llogin session. If the user
does not enter a carriage return to display the shell prompt, the llogin
will process continue to run, consuming all the free CPU time available.
PROBLEM:  (CLD CA7Q94761, QAR 43813) (Patch ID: OSF400-383)
********
This patch corrects a problem when exitting an llogin session. If the user
does not enter a carriage return to display the shell prompt, the llogin
will process continue to run, consuming all the free CPU time available.


FILE(s):

/usr/bin/llogin         subset OSFLAT400
CHECKSUM: 48027    144     RCSfile: llogin.c      RCS: 1.1.2.11

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

SUPERSEDED PATCHES:	OSF400-204 (217.00)

- Fixes several problems in the ex and vi editors.

    o Blank lines in the .exrc file prevent the vi editor from executing.

    o The ex editor does not properly manage the file name buffers
      when a "write append" command fails.

    o The vi editor may erroneously report a "Bad file number" error
      message when switching between files.

- Fixes a problem in which the vi command, "ce", does not work as expected.
PROBLEM:  (UVO104615 QAR 44614 QAR 47303) (Patch ID: OSF400-204)
********
Blank lines in the .exrc file prevent the vi editor from executing.

To recreate this problem, create a .exrc file in your home directory.
Leave a blank line at the end of the .exrc file.  Enter the vi command;
vi will exit immediately and your terminal window will display the shell
prompt.

PROBLEM:  (QAR 39453)		 (Patch ID: OSF400-204)
*********
The ex editor does not properly manage the file name buffers when a 
"write append" command fails.

For example, prior to invoking the ex editor, assume file "a" does not exist,
but file "b" does.  Run ex without specifying a file name, enter some characters
and try to get ex to output these characters in append mode to a file that 
does not exist.  After it correctly reports "no such file or directory",
specify a file that does exist.

For example:

   systema> ex
   :a
   hello worlds
   .
   :w
   No current filename
   :w  >> a
   "aa" No such file or directory
   :w >> b
   "b" 3 lines, 12 characters

When you try to exit the file, ex will write to the wrong file.

   :e b
   No write since last change (:edit! overrides)   #>-- won't do it

   :xit                                            #<-- Let's quit
   "a" [New file] 3 lines, 12 characters          #>-- ok, I'll write
for you
   systema>

The problem is that ex creates a new file when it should not.  After applying
this patch, the ex editor will provide the following error message:

        No current file name

PROBLEM:  (QAR 46284)		 (Patch ID: OSF400-204)
********
The vi editor may erroneously report a "Bad file number" error message when
switching between files.

For example, if file "xx" has access privileges of -r--r--r-- (no write enabled)
and file "yy" has privileges of -rw-r--r-- (write enabled, the following
example will cause vi to report "Bad file number":

        vi xx yy
        :n
        Shift+Ctrl+^
        dd
        :w
        Shift+Ctrl+^
        :e!
        "xx" [Read only] Bad file number
        Shift+Ctrl+^
        "yy" Bad file number

After applying this patch, the "xx" file is reported to be read-only and the
write will fail.  The "yy" file, will be written with no error message.

PROBLEM:  (QAR 53323, QAR 45227)	 (Patch ID: OSF400-390)
********
This patch fixes a problem in which the vi command, "ce", does not work as
expected. For example, when the cursor is on the beginning of the word "name",
typing "ce" should place a dollar sign (S) over the letter "e":

       nam$\n",
       ^ cursor is here, type "ce"

Instead, the vi command "ce" places the dollar sign at the end of the line,
over the comma:

       name\n"$
       ^ cursor is here, type "ce"


FILE(s):

/usr/bin/ex             			subset OSFBASE400
CHECKSUM: 46081    288     RCSfile: ex.c        RCS: 4.3.32.2
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_addr.c   RCS: 4.2.9.4
			   RCSfile: ex_re.h     RCS: 4.2.7.3
			   RCSfile: ex_cmds.c   RCS: 4.3.25.2
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_cmds2.c  RCS: 4.2.9.4
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_cmdsub.c RCS: 4.2.19.3
		  	   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_data.c   RCS: 4.2.7.2
			   RCSfile: ex_extern.c RCS: 4.2.7.2
			   RCSfile: ex_re.h     RCS: 4.2.7.3
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_get.c    RCS: 4.2.7.2
			   RCSfile: ex_io.c     RCS: 4.4.34.2
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_put.c    RCS: 4.2.10.5
			   RCSfile: ex_re.c     RCS: 4.2.9.7
			   RCSfile: ex_re.h     RCS: 4.2.7.3
			   RCSfile: ex_set.c    RCS: 4.2.7.3
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_subr.c   RCS: 4.3.9.4
			   RCSfile: ex_re.h     RCS: 4.2.7.3
			   RCSfile: ex_temp.c   RCS: 4.3.12.5
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_tty.c    RCS: 4.2.7.3
			   RCSfile: ex_unix.c   RCS: 4.2.7.4
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
			   RCSfile: ex_v.c      RCS: 4.2.7.3
			   RCSfile: ex_re.h     RCS: 4.2.7.3
			   RCSfile: ex_vadj.c   RCS: 4.2.7.2
		 	   RCSfile: ex_vget.c   RCS: 4.2.14.4
			   RCSfile: ex_vmain.c  RCS: 4.2.11.3
			   RCSfile: ex_voper.c  RCS: 4.2.7.4
			   RCSfile: ex_vops.c   RCS: 4.2.7.4
			   RCSfile: ex_vops2.c  RCS: 4.2.11.2
			   RCSfile: ex_vops3.c  RCS: 4.2.7.4
			   RCSfile: ex_vput.c   RCS: 4.2.9.2
			   RCSfile: ex_vwind.c  RCS: 4.2.7.2
			   RCSfile: ex_crypt.c  RCS: 4.2.5.4
			   RCSfile: ex_temp.h   RCS: 4.2.7.3
/usr/bin/edit				subset OSFBASE400
CHECKSUM: 46081    288 
/usr/bin/vedit				subset OSFBASE400
CHECKSUM: 46081    288 
/usr/bin/vi				subset OSFBASE400
CHECKSUM: 46081    288 
/usr/bin/view				subset OSFBASE400
CHECKSUM: 46081    288 

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

SUPERSEDED PATCHES:	OSF400-330 (337.00), OSF400-331-1 (339.01)
                        OSF400-351 (222.00), OSF400-250   (268.00)
                        OSF400-210 (223.00), OSF400-241   (261.00),
                        OSF400-275 (290.00), OSF400-065   (65.00),
                        OSF400-014 (14.00)

This patch corrects the following problems:

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

- When the /etc/passwd file is very large, a performance degradation may occur.

- Over time, a multithreaded application may find that asynchronous signals
  are not being delivered to it.
PROBLEM:  (SSRT0296U)    (Patch ID: OSF400-189)
********
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:                (Patch ID: OSF400-331)
********
When the /etc/passwd file is very large, a performance degradation may occur.

When the number of passwd entries reaches up into the 30,000 to 80,000 range
or greater, mkpasswd will sometimes fail to create a hashed (ndbm) database.
Since the purpose of this database is to allow for efficient (fast) searches
for passwd file information, failure to build it causes commands that rely
on it to do a linear search of /etc/passwd.  This results in a serious per-
formance degradation for those commands.

For customers choosing to use the mkpasswd -s option to avoid this type of
failure, a potential database/binary compatibility problem may arise.  If a
customer application that accesses the password database created by mkpasswd
is built statically (non-shared), that application will be unable to read
from or write to the password database correctly.  This would cause the
customer application to fail either by generating incorrect results or by
possibly dumping core.  Any statically linked application would be affected
if it directly or indirectly calls any of the libc ndbm routines documented
in the ndbm(3) man page and then accesses the password database.  To remedy
this situation, the customer would need to re-link the application.

Customers who do not use the mkpasswd -s option will not see this database/
binary compatibility problem.

PROBLEM:  (HPAQB17NM, QAR 50343, QAR 49427, QAR 52143) (Patch ID: OSF400-227)
********
When the /etc/passwd files are very large, a performance degradation may occur.

When the number of passwd entries reaches up into the 30,000 to 80,000 range,
mkpasswd will sometimes fail to create an ndbm database.  Since the purpose of
this database is to allow for efficient (fast) searches for passwd file
information, failure to build it causes a serious performance degradation for
commands that rely on it.

The change to the mkpasswd command creates one potential database compatibility
problem.  If a customer application that accesses the password database created
by mkpasswd is built static, i.e., non-shared, that application will be unable
to read from or write to the password database correctly.  This would cause
the customer application to fail either by generating incorrect results or
by possibly dumping core.  Any staticly linked application that directly or
indirectly calls any of the libc ndbm routines documented in the ndbm(3) man
page and then accesses the password database would be affected.  To remedy
this situation, the customer would need to re-link the application using the
libc.a supplied with this patch.

PROBLEM:  (QAR 52332)            (Patch ID: OSF400-239)
********
Over time, a multithreaded application may find that asynchronous signals are
not being delivered to it.  The asynchronous signal may have originated outside
the application or from within it. The effect will be that the signal is
pending against a thread, the thread will NOT have the signal blocked, but it
will not be delivered to that thread.


FILE(s):

/usr/include/esnmp.h                    	subset OSFINCLUDE400
CHECKSUM: 53307     16     RCSfile: esnmp.h     RCS: 1.1.14.2
/usr/include/arpa/nameser.h             	subset OSFINCLUDE400
CHECKSUM: 10429     12     RCSfile: nameser.h   RCS: 4.2.17.2
/usr/include/ndbm.h            			subset OSFINCLUDE400
CHECKSUM: 14045      6     RCSfile: ndbm.h      RCS: 4.2.24.3
/usr/include/netdb.h                     	subset OSFINCLUDE400
CHECKSUM: 11906     10     RCSfile: netdb.h     RCS: 4.2.28.3
/usr/include/pthread.h                   	subset OSFINCLUDE400
CHECKSUM: 58953     66     RCSfile: pthread.h   RCS: 1.1.13.6
/usr/include/resolv.h          			subset OSFINCLUDE400
CHECKSUM: 19041     11     RCSfile: resolv.h    RCS: 4.2.20.2
/usr/include/tis.h            			subset OSFINCLUDE400
CHECKSUM: 53110     16     RCSfile: tis.h       RCS: 1.1.9.2
/usr/include/wchar.h                     	subset OSFINCLUDE400
CHECKSUM: 27604   7        RCSfile: wchar.h     RCS: 4.2.15.2
/usr/include/dirent.h                 		subset OSFINCLUDE400
CHECKSUM: 13206      8     RCSfile: dirent.h    RCS: 4.2.18.2
/usr/include/grp.h                     		subset OSFINCLUDE400
CHECKSUM: 30440      5      RCSfile: grp.h      RCS: 4.2.18.2
/usr/include/pwd.h                      	subset OSFINCLUDE400
CHECKSUM: 47906      5      RCSfile: pwd.h      RCS: 4.2.15.2
/usr/include/time.h                     	subset OSFINCLUDE400
CHECKSUM: 31785      8      RCSfile: time.h     RCS: 4.3.20.2
/usr/include/unistd.h                  		subset OSFINCLUDE400
CHECKSUM: 49844     18      RCSfile: unistd.h   RCS: 4.2.28.2
/usr/include/stdlib.h                   	subset OSFINCLUDE400
CHECKSUM: 53968     11      RCSfile: stdlib.h   RCS: 4.3.28.2
/usr/include/standards.h                	subset OSFINCLUDE400
CHECKSUM: 33321      7      RCSfile: standards.h  RCS: 4.2.18.2
/usr/include/mqueue.h               		subset OSFINCLUDE400
CHECKSUM: 03140      9      RCSfile: mqueue.h   RCS: 1.1.16.2
/usr/sys/include/streamsm/xti.h			subset OSFINCLUDE400
CHECKSUM: 53541     19     RCS: xti.h      Revision: 4.2.26.2

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

SUPERSEDED PATCHES:	OSF400X11-011 (190.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).

- On systems with an S3 Trio64V+ graphics card (PB2GA-JC or PB2GA-JD),
  the X server hangs while drawing the login screen.
PROBLEM:  (QAR 51230) 		(Patch ID: OSF400X11-011)
********
Systems with an S3 Trio64 graphics card can loose time (on the order of a few 
minutes a day).

PROBLEM:  (QAR 53006) 		(Patch ID: OSF400X11-016)
********
On systems with an S3 Trio64V+ graphics card (PB2GA-JC or PB2GA-JD), the X
server hangs while drawing the login screen.


FILE(s):

/usr/shlib/X11/lib_dec_s3.so            subset OSFSERPC400
CHECKSUM: 12473    160

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

This patch fixes the following problem in the Bookreader library, which is
part of the DECwindows Motif toolkit.  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.  If an application like dxchpwd is run from a
non-root account, it fails with a privilege violation.
PROBLEM:  (HPAQ214QG and QAR 44630)	 (Patch ID: OSF400X11-019)
********
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 OSFXLIBA400
CHECKSUM: 64245     20
/usr/shlib/libDXm.so            subset OSFX11400
CHECKSUM: 42737    960
/usr/shlib/libbkr.so            subset OSFX11400
CHECKSUM: 19067     48

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

SUPERSEDED PATCHES:	OSF400-014 (14.00),  OSF400-065 (65.00),
			OSF400-275 (290.00), OSF400-330 (337.00)

This patch corrects the following:

- Allows the extensible SNMP daemon to handle a very high volume of SNMP trap 
  requests.

- In the operation of the SNMP agent (returned MIB values) and 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

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

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

- This patch removes support for atTable, so that common applications
  (like NetView autodiscovery) will use the ipNetToMediaTable instead.
PROBLEM:  (QARs 44872, 44885 & CLD HPXQ34A01) (Patch ID: OSF400-014)
********
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: OSF400-065)
********
When the system experiences a very high volume of SNMP trap requests, some SNMP
traps may be lost.

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

PROBLEM:  (GOZ100745) 			(Patch ID: OSF400-330)
*********
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.

This patch removes support for atTable, so that common applications
(like NetView autodiscovery) will use the ipNetToMediaTable instead.


FILE(s):

/usr/shlib/libesnmp.so 			subset OSFCLINET400
CHECKSUM: 02492     88
/usr/sbin/os_mibs 			subset OSFCLINET400
CHECKSUM: 02492    176     RCSfile: os_mibs.c      RCS: 1.1.19.2 
			   RCSfile: os_mibs_shm.c  RCS: 1.1.2.5
/usr/sbin/snmpd         		subset OSFCLINET400
CHECKSUM: 61907    120     RCSfle: mstr_sr.c       RCS: 1.1.9.2

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

SUPERSEDED PATCHES: 	OSF400-109 (109.00), OSF400-109-1 (109.01),
			OSF400-215 (231.00)

This patch corrects the following:

- When setting the date with the clock_settime rtl service routine,
  the date will not get past the date of 'Sat Sep  8 19:46:39 2001'
  If you try to set past this date the routine returns a EINVAL error.

- Fixes a problem in which a system running POSIX message queue functions
  in the realtime library will either exhibit message queue data corruption
  or it will hang.
PROBLEM:  (QAR 48248) 		(Patch ID: OSF400-109)
********
This patch fixes a problem in which a system running the POSIX Message Queue 
functions in the realtime library (librt.a, librt.so) will either exhibit 
message queue data corruption or it will hang.

The problem occurs if more than one message queue is actively used in a user 
process.

If two or more user processes open more than one POSIX message queue using 
mq_open(), and open them in a different order, for example, process 1 opens 
queue 1 followed by queue 2, and process 2 opens queue2 followed by queue 1, 
then data corruption in the queue will occur. The data corruption may show up 
as a panic or a hang, or simply as bad data.  The problem may present itself in
other forms.

To reproduce the problem,  compile and execute the following two tests. The 
sources for these tests (mqread.c and mqwrite.c) are included at the end of 
this text.

To compile:
# cc -o mqread mqread.c -lrt
# cc -o mqwrite mqwrite.c -lrt

To execute:

In order to demonstrate the problem, run mqwrite followed by mqread, but pass 
argument 1 to mqwrite. This forces mqwrite to open the two queues in a 
different order than the order in which mqread opens them in. The mqwrite will 
succeed, but the mqread will fail, but not always in the same way.  Sometimes 
mqread will kill the window that the test is running in.  At other times, the 
test will complete, but the data will be corrupted.

The output of the data corruption case is included below:

    # ./mqwrite 1
    START OF TEST_SEND

     SWAPPED ORDER A
    queues descriptors : mqueue_1 65537 mqueue_2 65536
    successful call to mq_send, i = 0
    successful call to mq_send, i = 1
    successful call to mq_send, i = 2
    successful call to mq_send, i = 3
    successful call to mq_send, i = 4
    successful call to mq_send, i = 5
    successful call to mq_send, i = 6
    successful call to mq_send, i = 7
    successful call to mq_send, i = 8
    successful call to mq_send, i = 9
    About to exit the sending process after closing the queue

    # ./mqread 
    START OF TEST_RECEIVE

     NORMAL ORDER
    queue descriptors : mqueue_1 65536 mqueue_2 65537
    data read for iteration 0 = x`r@
    data read for iteration 1 = PRIORITY2a@
    data read for iteration 2 = PRIORITY2a@
    data read for iteration 3 = PRIORITY2a@   
    data read for iteration 4 = PRIORITY2a@
    data read for iteration 5 = PRIORITY2a@
    data read for iteration 6 = PRIORITY2a@
    data read for iteration 7 = PRIORITY2a@
    data read for iteration 8 = PRIORITY2a@
    data read for iteration 9 = PRIORITY2a@
    About to exit the receiving process after closing and unlinking the queue

NOTE that the 'data read for iteration 0' shows corrupt data.

After the patch is installed, and the test is rerun, the mqread will succeed, 
and it will print the following to the screen:

    # ./mqread
    START OF TEST_RECEIVE

     NORMAL ORDER
    queue descriptors : mqueue_1 65536 mqueue_2 65537
    data read for iteration 0 = PRIORITY2a@
    data read for iteration 1 = PRIORITY2a@
    data read for iteration 2 = PRIORITY2a@
    data read for iteration 3 = PRIORITY2a@
    data read for iteration 4 = PRIORITY2a@
    data read for iteration 5 = PRIORITY2a@
    data read for iteration 6 = PRIORITY2a@
    data read for iteration 7 = PRIORITY2a@
    data read for iteration 8 = PRIORITY2a@
    data read for iteration 9 = PRIORITY2a@
    About to exit the receiving process after closing and unlinking the queue
 


The following are the mqwrite.c and mqread.c source files:
/******************************************************************/
/* mqwrite.c: 
 *
 * Example of write (send) message queue
 *
 * Opens two queues "mqueue_1" which is the only queue used in transfers and
 * a second queue "mqueue_2" which after being opened is never used
 *
 * To open queues in the order mqueue_1 followed by mqueue_2 run program with
 * argument 0, or no argument
 * i.e.
 *   mqwrite 0
 * To open queues in the order mqueue_2 followed by mqueue_1 run program with
 * argument=1
 * i.e.
 *   mqwrite 1
 *
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#define PMODE 0666

int main(int argc, char *argv[])
{
int i;
int status = 0;
mqd_t mqueue_1, mqueue_2;
char msg_buffer[P4IPC_MSGSIZE];
struct mq_attr attr;
int open_flags = 0;
int num_bytes_to_send;
int priority_of_msg;

int swap;

swap=0;
if (argc < 2)
    swap=0;
else
    {
    if (atoi(argv[1]) != 1)
        swap=0;
    else
       swap=1;
    }

printf("START OF TEST_SEND \n");

/* Fill in attributes for message queue */
attr.mq_maxmsg = 20;
attr.mq_msgsize = P4IPC_MSGSIZE;
attr.mq_flags   = 0;

if (swap != 0)
    {
    printf ("\n SWAPPED ORDER A\n");    
    if ((mqueue_2 = mq_open ("mqueue_2", O_WRONLY | O_CREAT, PMODE, &attr)) == -1)
        {
        perror ("mq_open of mqueue_2 failed");
        exit (1);
        }
    if ((mqueue_1 = mq_open ("mqueue_1", O_WRONLY | O_CREAT, PMODE, &attr)) == -1)
        {
        perror ("mq_open of mqueue_1 failed");
        exit (1);
        }
    }
else
    {
    printf("\n NORMAL ORDER\n"); 
    if ((mqueue_1 = mq_open ("mqueue_1", O_WRONLY | O_CREAT, PMODE, &attr)) == -1)
        {
        perror ("mq_open of mqueue_1 failed");
        exit (1);
        }
    if ((mqueue_2 = mq_open ("mqueue_2", O_WRONLY | O_CREAT, PMODE, &attr)) == -1)
        {
        perror ("mq_open of mqueue_2 failed");
        exit (1);
        }
    }

printf("queues descriptors : mqueue_1 %d mqueue_2 %d \n", mqueue_1, mqueue_2);

/* Fill in a test message buffer to send */
msg_buffer[0] = 'P';
msg_buffer[1] = 'R';
msg_buffer[2] = 'I';
msg_buffer[3] = 'O';
msg_buffer[4] = 'R';
msg_buffer[5] = 'I';
msg_buffer[6] = 'T';
msg_buffer[7] = 'Y';
msg_buffer[8] = '2';
msg_buffer[9] = 'a';

num_bytes_to_send = 10;
priority_of_msg = 1;
for (i = 0; i < 10; i++)
    {
    if (mq_send (mqueue_1, msg_buffer, num_bytes_to_send, priority_of_msg) == -1)
        perror ("mq_send failure on mqueue_1");
    else
        printf ("successful call to mq_send, i = %d\n",i);
    }

/* Done with queue, so close it */
if (mq_close(mqueue_1) == -1)

    perror ("mq_close failure on mqfd");

printf("About to exit the sending process after closing the queue \n");
mq_close(mqueue_2);

}

/******************************************************************/
/*
 * Example of read (receive) message queue
 *
 * Opens two queues "mqueue_1" which is the only queue used in transfers and
 * a second queue "mqueue_2" which after being opened is never used
 *
 * To open queues in the order mqueue_1 followed by mqueue_2 run program with
 * argument 0, or no argument:
 * i.e.
 *   mqread 0
 * To open queues in the order mqueue_2 followed by mqueue_1 run program
 * with argument=1
 * i.e.
 *   mqread 1
 *
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#define PMODE 0666


int main(int argc, char *argv[])
{
int i;
int status = 0;
mqd_t mqueue_1, mqueue_2;
char msg_buffer[P4IPC_MSGSIZE];
struct mq_attr attr;
int open_flags = 0;
int priority_of_msg;
int swap;

swap=0;
if (argc < 2)
    swap=0;
else
    {
    if (atoi(argv[1]) != 1)
        swap=0;
    else
        swap=1;
    }


printf("START OF TEST_RECEIVE\n");

/* Fill in attributes for message queue */
attr.mq_maxmsg = 20;
attr.mq_msgsize = P4IPC_MSGSIZE;
attr.mq_flags   = 0;

if (swap != 0)
    {
    printf ("\n SWAPPED ORDER A\n");
    if ((mqueue_2 = mq_open ("mqueue_2",  O_RDONLY | O_CREAT, PMODE, &attr)) == -1)
        {
        perror ("mq_open of mqueue_2 failed");
        exit (1);
        }
    if ((mqueue_1 = mq_open ("mqueue_1",  O_RDONLY | O_CREAT, PMODE, &attr)) == -1)
        {
        perror ("mq_open of mqueue_1 failed");
        exit (1);
        }
    }
else
    {
    printf ("\n NORMAL ORDER\n");
    if ((mqueue_1 = mq_open ("mqueue_1", O_RDONLY | O_CREAT, PMODE, &attr)) == -1)
        {
        perror ("mq_open of mqueue_1 failed");
        exit (1);
        }
    if ((mqueue_2 = mq_open ("mqueue_2", O_RDONLY | O_CREAT, PMODE, &attr)) == -1)
        {
        perror ("mq_open of mqueue_2 failed");
        exit (1);
        }
    }

printf("queue descriptors : mqueue_1 %d mqueue_2 %d \n", mqueue_1, mqueue_2);

for (i = 0; i < 10; i++)
    {
    if (mq_receive (mqueue_1, msg_buffer, P4IPC_MSGSIZE, 0) == -1)
        perror ("mq_receive failure on mqfd");
    else
        printf ("data read for iteration %d = %s \n", i, msg_buffer);
    }

/* Done with queue, so close it */
if (mq_close (mqueue_1) == -1)
    perror("mq_close failure on mqueue_1");

/* Done with test, so unlink the queue,
 * which destroys it.
 * You only need one call to unlink.
 */
if (mq_unlink("mqueue_1") == -1)
    perror("mq_unlink failure in test_ipc");

printf("About to exit the receiving process after closing and unlinking the queue \n");
mq_close(mqueue_2);
mq_unlink("mqueue_2");
}

PROBLEM:  (CLD MCPM20W7F, QAR 51771)	 (Patch ID: OSF400-215)
********
When setting the date with the clock_settime rtl service routine, the date will
not get past the date of 'Sat Sep  8 19:46:39 2001'.  If you try to set past
this date the routine returns a EINVAL error.


FILE(s):

/usr/sys/include/mqueue.h	    subset OSFBINCOM400
CHECKSUM: 03140      9     RCSfile: mqueue.h      RCS: 1.1.16.2
/usr/ccs/lib/librt.a		    subset OSFRTDEV400
CHECKSUM: 18365     59
/usr/shlib/librt.so		    subset OSFRTDEV400
CHECKSUM: 02745     72

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

SUPERSEDED PATCHES:     OSF400-083 (83.00), OSF400-293 (302.00),
                        OSF400-362 (363.00)

This patch corrects the following:

- Fixes the problem of the math library functions not returning the correct
  NaN value as defined in the Alpha AXP Architecture Reference Manual
  (Second Edition).

- Fixes a problem with fastmath functions F_Exp() and F_Pow() that would
  cause floating exception core dumps.
PROBLEM:  (QAR 48474)           (Patch ID: OSF400-083)
********
This fix changes the encoding of IEEE floating-point Quiet NaNs returned by the
math library by setting the sign bit. This fix corrects inconsistency between
the value returned by the math functions and the kernel encoding.

A NaN is the floating-point representation of a result that is "Not A Number"
(e.g. the floating-point result of zero divided by zero is a NaN).

This change is only of interest to programmers who use IEEE floating-point math
 with the -ieee or the -ieee_with_inexact option. It does not affect programs
or libraries not using the full IEEE math support.

For more information, see the IEEE Standard for Binary Floating Point
Arithmetic ANSI/IEEE (Std 754-1985). For information about the Alpha AXP
implementation, see the Alpha AXP Architecture Reference Manual (Second Edition)
by Richard L. Sites and Richard T. Witek, Digital Press, 1995. See the section
on "Encodings" (4.7.4).

Compile the following program using the -ieee and -lm options:

#include 
#include 
#include 
#include 
main()
{
    double a, b, c, d;
    int i;

    a = sqrt( -1.0 );
    i = sscanf("0.0 0.0 0.0", "%lf %lf %lf", &b, &c, &d);
    assert(i == 3);
    printf( "sqrt( -1.0 ) = %f\t\t0x%016lx\n", a, *(long *)&a );

    d = b / c;

    printf( "0.0 / 0.0 = %f\t\t0x%016lx\n", d,*(long *)&d );
}

Compile this program using the -ieee and -lm command line options.

Results before installing new math library:
sqrt( -1.0 ) = NaNQ             0x7fffffffffffffff
0.0 / 0.0 = -NaNQ               0xfff8000000000000

Results after installing new math library:
sqrt( -1.0 ) = -NaNQ            0xfff8000000000000
0.0 / 0.0 = -NaNQ               0xfff8000000000000

PROBLEM:  (QAR 52294, CLD SDT-1335) (Patch ID: OSF400-293)
********
There is a problem with the F_exp(), the fast exponentiation function, and the
F_pow(), the fast math power function, in the way that they handle underflow
arguments.

For certain arguments, a calls to F_exp() and F_pow() result in a floating-point
exceptions.

PROBLEM:  (QAR 52294, CLD SDT-1335)      (Patch ID: OSF400-362)
********
There is a problem with the F_exp(), the fast exponentiation function, and
the F_pow(), the fast math power function, in the way that they handle underflow
arguments.

For certain arguments, a calls to F_exp() and F_pow() result in floating-point
exceptions accompanied by core dumps.


FILE(s):
/usr/ccs/lib/libm.a                        subset OSFLIBA400
CHECKSUM: 21402    651

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

A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised.  This may  be in the form
of improper file or privilege management.  Digital has corrected this potential
vulnerability.
PROBLEM:  (SSRT0487U, QAR 54187)	 (Patch ID: OSF400-404)
********
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/bin/crontab                subset OSFBASE400
CHECKSUM: 46919     40     RCSfile: crontab.c      RCS: 4.2.29.2

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

A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised.  This may be in the form
of improper file or privilege management.  Digital has corrected this potential
vulnerability.
PROBLEM:  (SSRT0495U)		 (Patch ID: OSF400-406)
********
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/bin/man            		       subset OSFBASE400
CHECKSUM: 21437     48     RCSfile: man.c      RCS: 4.2.23.2
		           RCSfile: man_conv.c RCS: 1.1.2.7
/usr/bin/apropos				subset OSFBASE400
CHECKSUM: 21437     48 
/usr/bin/whatis					subset OSFBASE400
CHECKSUM: 21437     48 
/usr/lib/nls/msg/en_US.ISO8859-1/man.cat       subset OSFBASE400
CHECKSUM: 35517      2 

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

SUPERSEDED PATCHES:	OSF400-120 (120.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 log 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, 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:  (SOO100842 & QAR number 45974)	(Patch ID: OSF400-120)
********
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.

PROBLEM:  (SSRT0456U)		 (Patch ID: OSF400-412)
********
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/rpc.statd             subset OSFNFS400
CHECKSUM: 36760     32 

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

This patch fixes a problem that occurs when more than 140 users are logged on 
to a system and the who command is issued. If the output from the command is 
redirected or piped, the last several lines become corrupt.
PROBLEM:  (QAR 51122,52098)		 (Patch ID: OSF400-416)
********
This patch fixes a problem that occurs when more than 140 users are logged on
to a system and the who command is issued. If the output from the command is
redirected or piped, the last several lines become corrupt.


FILE(s):

/usr/bin/who            subset OSFBASE400
CHECKSUM: 55101     24     RCS: who.c      Revision: 4.2.23.2
/sbin/who               subset OSFBASE400
CHECKSUM: 39939     24     RCS: who.c      Revision: 4.2.23.2

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

SUPERSEDED PATCHES:	OSF400-189 (203.00), OSF400-189B (296.00),
			OSF400-189B-1 (296.01), OSF400-313 (323.00)

This patch corrects the following:

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

- Corrects a problem where, if the FLAG bit is set in the IP header, screend
  incorrectly reports:

        ACCEPT: Not first frag, off 64

- A potential security vulnerability has been discovered, where under certain
  circumstances, system integrity may be compromised.  This may be in the form
  of improper file or privilege management.  Digital has corrected this
  potential vulnerability.
PROBLEM:  (SSRT0296U)    		(Patch ID: OSF400-189B)
********
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:  (TKTBC2528, 46553)		 (Patch ID: OSF400-313)
********
This patch corrects a problem where, if the FLAG bit is set in the IP header,
screend incorrectly reports:

        ACCEPT: Not first frag, off 64

PROBLEM:  (SSRT0494U)		 (Patch ID: OSF400-422)
********
This patch corrects a security vulnerability which might allow unauthorized
access to a Digital Unix system.


FILE(s):

/usr/sbin/named                            subset OSFINET400
CHECKSUM: 33281    184 
/sbin/named             		   subset OSFINET400
CHECKSUM: 22771    184 
/usr/sbin/named-xfer                       subset OSFINET400
CHECKSUM: 23933     48     RCSfile: named-xfer.c  RCS: 4.2.16.2
/usr/sbin/screend                          subset OSFINET400
CHECKSUM: 24142    384     RCSfile: screend.c      RCS: 1.1.5.2

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

SUPERSEDED PATCHES:     OSF400-136 (136.00)

This patch corrects the following:

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

- An upgrade/replacement for the Token Ring driver.  This patch fixes an
  intermittent kernel memory fault problem.  To ensure data integrity,
  additional enhancements to transmit and receive list processing routines
  have also been added.
PROBLEM:	(HPAL83FE3)	(Patch ID: OSF400-136)
********
Fixes a Token Ring transmission timeout - the driver can experience 
"ID 380PCI20001 (8/13/95)" as described in the TI380PCI Errata.

PROBLEM:  (UTO101539)		 (Patch ID: OSF400-423)
********
This patch is an upgrade/replacement for the Token Ring driver.  This patch
fixes an intermittent kernel memory fault problem.  To ensure data integrity,
additional enhancements to transmit and receive list processing routines have
also been added.


FILE(s):

/sys/BINARY/tra.mod		 subset OSFHWBINOBJECT400
CHECKSUM: 49913     68	RCSfile: if_tra.c   RCS: 1.1.22.11 

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

Fix for rdist utility to prevent segmentation fault.
PROBLEM:  (MGO103141)		 (Patch ID: OSF400-424)
********
A coding error in the rdist utility could result in a segmentation fault when
transferring large files.  This patch corrects the problem.


FILE(s):

/usr/bin/rdist          subset OSFINET400
CHECKSUM: 14395     88 

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

A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised.  This may be in the form
of improper file or privilege management.  Digital has corrected this potential
vulnerability.
PROBLEM:  (SSRT0490U, QAR 56474) (Patch ID: OSF400-427)
********
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/restore               subset OSFHWBASE400
CHECKSUM: 44669     96     RCSfile: restore.h       RCS: 4.2.16.3
			   RCSfile: restore.c       RCS: 4.2.2.3
		   	   RCSfile: restoreextern.c RCS: 4.2.4.3
/usr/sbin/rrestore              subset OSFCLINET400
CHECKSUM: 15233    104 
/sbin/restore         		subset OSFHWBASE400
CHECKSUM: 28803    104    RCSfile: restore.h       RCS: 4.2.16.3
			   RCSfile: restore.c       RCS: 4.2.2.3
			   RCSfile: restoreextern.c RCS: 4.2.4.3
/usr/lib/nls/msg/en_US.ISO8859-1/restore.cat            subset OSFHWBASE400
CHECKSUM: 19759      9 

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

SUPERSEDED PATCHES:     OSF400-167 (167.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.
PROBLEM:  (SSRT0448U, QAR 51211)	 (Patch ID: OSF400-167)
********
A potential security vulnerability has been discovered, where under certain 
circumstances, system integrity may be compromised. This may be in the form of 
improper file or privilege management. Digital has corrected this potential 
vulnerability.

PROBLEM:  (SSRT0452U) 		(Patch ID: OSF400-428)
********
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 OSFCLINET400
CHECKSUM: 05865    104     RCSfile: ftpd.c         RCS: 4.2.41.2
			   RCSfile: ftpd_syslog.c  RCS: 1.1.4.2	
/usr/lib/nls/msg/en_US.ISO8859-1/ftpd.cat               subset OSFCLINET400
CHECKSUM: 49951      6 

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

SUPERSEDED PATCHES:     OSF400-023 (23.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.

- Provides the followig bug fixes and performance enhancements:

    o When signals causing pcnfsd to terminate or when a SIGPIPE signal
      was not caught, pcnfsd would exit without producing a core file.

    o The pcnfsd authentication would cause crashes and memory corruption.
PROBLEM:  (SSRT0396U, QAR 45778)	 (Patch ID: OSF400-023)
********
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.

PROBLEM:  (QAR 49002)		 (Patch ID: OSF400-429)
********
This patch is actually a correction for several failures and performance
enhancements. They are further described:

PROBLEM:  (QAR 46407)		 (Patch ID: OSF400-429)
********
A signal handler was added that will log an entry in the syslog file and create
a core file. This will occur for all signals that can cause pcnfsd to terminate
without producing a core file.

SIGPIPE signal, which can happen during a write when a client closes the socket,
can cause the pcnfsd to terminate if it was not caught.  This fix now catches
the SIGPIGE signal.

PROBLEM:  (QAR 45304)		 (Patch ID: OSF400-429)
********
The pcnfsd authentication would cause crashes and memory corruption.  This is
evident when a user runs "audit_tool -e login:1:0 auditlog.084" command and see
odd failures being logged instead of logging successes.  An example of an odd
failure would be a user who does not have a valid UID on the system trying to
mount via pcnfsd.


FILE(s):

/usr/sbin/rpc.pcnfsd 		subset OSFNFS400
CHECKSUM: 57760     72 

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

SUPERSEDED PATCHES:	OSF400-030 (30.00),  OSF400-035 (35.00), 
			OSF400-053 (53.00),  OSF400-041 (41.00),
			OSF400-067 (67.00),  OSF400-085 (85.00),
			OSF400-092 (92.00),  OSF400-142 (142.00),
			OSF400-146 (146.00), OSF400-236 (256.00),
			OSF400-324 (333.00), OSF400-368 (369.00)

This patch corrects the following:

- Fixes "kernel memory fault" panics from the kernel malloc() routine when
  System V FIFOs created via STREAMS and fattach() are in use.

- A remote user will kill rlogin or telnet and the server host will have an 
  orphan login process and rlogind or telnetd process in the sleep state 
  indefinitely.  This is seen only with Asian tty (atty) or any other hosts
  which are running c-list rather than STREAMS tty's.

- A panic (kernel memory fault) associated with the STREAMS code when stopping 
  layered products.

- Prevents delivery of data in subsequent streams messages with one read of a 
  streams pipe.  This problem only happens if the read has a message length 
  greater than the length of the first message in the pipe.

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

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

- A system could hang after Patch OSF400-035 is installed.

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

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

- System causes an "assert_wait" panic and the stack contains streams modules. 

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

- Fixes a problem that occurs when running STREAMS.  The system panics with 
  a kernel memory fault in either osr_run() or osr_reopen().

- 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 on an SMP system when running STREAMS.  The system
  panics with the following error message:   "kernel memory fault"
PROBLEM:  (TKTR21634)		 (Patch ID: OSF400-030)
********
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: OSF400-030)
********
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:  (QAR 46691)		 (Patch ID: OSF400-035)
********
The SVR4 STREAMS 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 is being set.

PROBLEM:  (HPAQ68777) 		(Patch ID: OSF400-053)
********
This patch fixes a kernel memory fault panic. This panic occurs on systems 
running System V applications or any user process compiled with the System V 
environment, even if System V is not loaded on the system.

A representative stack trace is:

5 panic("kernel memory fault")subr_prf.c:719
6 trap()trap.c:1243
7 _XentMM()locore.s:1307
8 malloc()kern_malloc.c:743
9 osr_alloc()str_scalls.c:232
10 pse_ioctl()str_scalls.c:1498
11 spec_ioctl()spec_vnops.c:1987
12 syioctl()tty_tty.c:210
13 spec_ioctl()spec_vnops.c:1987
14 vn_ioctl()vfs_vnops.c:1109
15 ioctl_base()sys_generic.c:465
16 ioctl()sys_generic.c:344
17 syscall()syscall_trap.c:519

PROBLEM:  (QAR 47488) 		(Patch ID: OSF400-041)
********
A system that has Patch OSF400-035 installed may hang. Patch OSF400-035
corrects 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 to prevent the hang caused
by patch OSF400-035.

PROBLEM:  (QAR 48449)  		(Patch ID: OSF400-067)
********
When reading a streams pipe, if more than one message is in the pipe, a read 
with a message length greater than the first message will result in reading all 
of the messages in the pipe concatenated.

PROBLEM:  (MXOQ10017,HPAQB5D39) (Patch ID: OSF400-085)
********
This problem occurs when unlinking STREAMS Multplexors.  Note that there are no
STREAMS multi-plexors 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:  (TKTR70408, QAR 47306) (Patch ID: OSF400-092)
********
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.
            
PROBLEM:  (HPAQ95241, QAR 50022) (Patch ID: OSF400-142)
********
This patch fixes a problem that causes the system to "assert_wait" panic and 
the stack contains streams modules.  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:  (QARs 49942 & 49814) (Patch ID: OSF400-146)
********
This patch fixes a problem that causes the system to panic with a kernel memory
fault or "malloc_audit: guard space corruption" with osr_run as an entry in the
stack.  At this time no additional stack information is available.

PROBLEM:  (QAR 52041)		 (Patch ID: OSF400-236)
********
A "kernel memory fault" panic will be seen originating from the malloc()
routine.  The top stack entries will be as follows.  Many different kernel
routines may appear in the stack below malloc().

        panic("kernel memory fault")
        trap()
        _XentMM()
        malloc()

This problem is due to malloc() bucket corruption that occurs when there
is a racing close() and fdetach() of a System V fifo.  In the dump the
thread that did the racing close can often be found with the traceback:

        thread_block()
        vfs_busy()
        dounmount()
        sth_update_times()
        osr_close_subr()
        pse_close()
        speclose()
        spec_close()
        vn_close()
        closef()
        close()
        syscall()
        _Xsyscall()

PROBLEM:  (CLD TKTQ42309)		 (Patch ID: OSF400-324)
********
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: OSF400-324)
********
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: OSF400-368)
********
This patch fixes the problem of a system hang due to corruption of a STREAM
synchronization queue's forward pointer.  The system hangs in the csq_cleanup()
function.

A sample stack trace is as follows:

       csq_cleanup
       osr_pop_subr
       osr_close_subr
       pse_close
       speclose
       spec_close
       vn_close
       closef
       close
       syscall

PROBLEM:  (CLD MCGM91B24)	 (Patch ID: OSF400-433)
********
This patch fixes a problem that occurs on an SMP system when running STREAMS.
The system panics with the following error message:

  "kernel memory fault"

A sample stack trace is shown as follows:

 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1763,]
 1 panic(s = 0xfffffc0000586480 = "kernel memory fault")
 2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1243, 0xfffffc000047c614]
 3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307,]
 4 ldtty_wsrv() ["../../../../src/kernel/tty/ldtty.c":749,]
 5 sq_wrapper() ["../../../../src/kernel/streams/str_runq.c":]
 6 csq_lateral() ["../../../../src/kernel/streams/str_synch.c":977,]
 7 runq_run() ["../../../../src/kernel/streams/str_runq.c":108,]
 8 netisr_thread() ["../../../../src/kernel/net/netisr.c"]


FILE(s):

/sys/BINARY/bsd_tty.mod			subset OSFBIN400
CHECKSUM: 16278     45
/sys/BINARY/pty.mod                     subset OSFBIN400
CHECKSUM: 09143     20 
/sys/BINARY/streams.mod			subset OSFBIN400
CHECKSUM: 17714    270 
/usr/sys/include/streams/str_stream.h   subset OSFBINCOM400
CHECKSUM: 42195     20     RCSfile: str_stream.h      RCS: 4.2.44.3

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

SUPERSEDED PATCHES:     OSF400-193 (206.00)

This patch corrects the following:

- Corrects several serious problems with the "csh" command.  Some of these
  problems can cause the "grep" and "find" commands to fail, when the user
  runs the commands under the "csh" shell.

- Fixes a problem that occurs when using the C shell (csh).  When a command that
  does both wildcard expansion and command substitution is run in csh, incorrect
  results are produced.
PROBLEM:  (QAR 41085)		 (Patch ID: OSF400-193)
********
Fixes a problem in which the :q history substitution modifier in csh may result
in a syntax error.

PROBLEM:  (QAR 41087)		 (Patch ID: OSF400-193)
********
Fixes a problem in which the :x history substitution modifier in csh may result
result in a syntax error.

PROBLEM:  (QAR 41746)		 (Patch ID: OSF400-193)
********
Fixes a problem in which receipt of a SIGALRM signal by a child process of csh
does not result in csh reporting the death of the child process with the m
message 'Alarm clock'. Instead the system displays the following message:

        	auto-logout

PROBLEM: (QAR 42250)		 (Patch ID: OSF400-193)
********
Fixes a problem in which csh erroneously jumps to the middle of an embedded
if-then statement. This occurs upon reaching the end of a while loop, when
the loop is entered manually, rather than executed from a script.

PROBLEM:  (QAR 43026, QAR 45613, QAR 47089, QAR 47146, HPXQC14BV, HPXQC15ND )
********  ( Patch ID: OSF400-193)
Fixes a problem in which an error in a file sourced by cs results in a logout 
of the csh process.

PROBLEM:  (QAR 44539) 		(Patch ID: OSF400-193)
********
Fixes a problem in which the default value for prompt2 in csh is ">" instead
of "?".

PROBLEM:  (QAR 46802)		 (Patch ID: OSF400-193)
********
Fixes a problem in which csh can core dump when expanding a large "*" pattern.

PROBLEM:  (QAR 45059)		 (Patch ID: OSF400-193)
********
Fixes a problem in which csh fails to do file name substitution on the result
of a command substitution.

PROBLEM:  (QAR 46160, QAR 47019, TKTQB1363) (Patch ID: OSF400-193)
********
Fixes a problem in which csh expands metacharacters (for example, "*") even
when they are inside quoted strings. This problem can cause the grep, sed,
and find commands to fail when "*" appears inside a quoted regular expression
argument.

PROBLEM:  (QAR 45632)		 (Patch ID: OSF400-193)
********
Fixes a problem in which csh does not expand tilde ("~") in a path name that
also contains a backquoted expression ("`...`").

PROBLEM:  (QAR 47453)		 (Patch ID: OSF400-193)
********
Fixes a problem in which the autologout feature of csh is by default enabled
for pseudo ttys (for example, during an rlogin session).

With this patch, autologout is enabled by default if csh runs as a login shell
and if the standard input stream is not a pseudo tty and the DISPLAY environ-
ment variable is not set. Autologout under these conditions can be disabled
by adding the following line to your .login or .cshrc file:

			set autologout = 0

If autologout is set to a value greater than 0 (zero), csh terminates if a 
command is not entered within the prescribed number of minutes after issuing
the csh prompt. You can find out whether the autologout feature is enabled
for the session by checking the value of $autologout.

PROBLEM:  (QAR 48250)		 (Patch ID: OSF400-193)
********
Fixes a problem in which csh can core dump while using the history facility
when edit mode is set to emacs.

PROBLEM:  (QAR 46161)		 (Patch ID: OSF400-193)
********
Fixes a problem in which csh does not read the .cshrc and .login files in the 
user's home directory if they are not owned by the user and in the same group
as the user.

PROBLEM:  (QAR 44298)		 (Patch ID: OSF400-193)
********
Fixes a problem in which csh prints a misleading message ("No match") when a
command line contains characters such as "*" or "?" and the user does not have
read access to the current directory.  With this patch, csh will print the more
descriptive message "Glob aborted - Permission denied".
 
PROBLEM:  (QAR 26082)		 (Patch ID: OSF400-193)
********
Fixes a problem in which a csh loop that runs background processes exits when
too many processes have been created. With this patch, csh works like ksh in
that it waits for process creation to succeed.

PROBLEM:  (ZUO101309)		 (Patch ID: OSF400-434)
********
This patch fixes a problem that occurs when using the C shell (csh).  When a
command that does both wildcard expansion and command substitution is run in
csh, incorrect results are produced.  For example:

$ /usr/bin/csh
$ ls *.c `ls *.h`
*.c not found
a.h b.h
example: 
$ /usr/bin/csh
$ ls *.c `ls *.h`
a.c  a.h  b.c  b.h


FILE(s):

/usr/bin/csh            subset OSFBASE400
CHECKSUM: 55591    248 

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

SUPERSEDED PATCHES:	OSF400-002   (2.00),   OSF400-002-1 (2.01),
			OSF400-002-2 (2.02),   OSF400-118   (118.00),
			OSF400-169   (169.00), OSF400-157   (157.00),
			OSF400-234   (253.00), OSF400-270   (285.00),
			OSF400-304   (316.00), OSF400-326   (335.00)

This patch corrects the following:

- Fixes a problem that occurs if the kernel tunable variable "old-obreak"
  is set to zero and the system is running the Korn shell (ksh).  The
  shell gets caught in an infinite loop printing a message similar to
  the following. Eventually the process will core dump.

     /adp/bin/adpbkup[135]: no space

- Fixes the following problem.  If an attribute has been set to "read-only",
  and it cannot be set back (unset) to "read/write" status by using the
  built-in command typeset of the ksh (eg. typeset +r).

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

- Fixes a problem that occurs when using the Korn shell (ksh).  Keyboard input
  is not echoed when a user exits via a trap, after editor options have been
  been set in ksh.

- Fixes a problem with the ksh shell program. ksh prevents a command which 
  runs in a sub-process from writing to a tape device.

- Fixes a problem in which the ksh command periodically prints erroneous
  characters instead of the command that was typed.

- Fixes a problem in which the ksh shell sometimes reverses the group id (GID)
  and the effective group id (egid) of the calling process.

- Fixes problems that occur when using the ksh shell. When the PATH for a
  command is not found, the following error message is displayed.  Also,
  when the set command is executed, the system core dumps.

     /bin/ksh: invalid multibyte character

- Fixes a problem that occurs when using the Korn shell (ksh).  Variables set 
  with the typeset -L[n] built-in command do not work correctly when other
  subshells are spawned.
PROBLEM:  (CLD/USG-01932)	 (Patch ID: OSF400-002)
********
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_history) 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 the 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: OSF400-118)
********
This patch fixes a problem that occurs when using the Korn shell (ksh). 
Keyboard input is not echoed when a user exits via a trap, after editor options
have been set in ksh.

To restore the tty modes, enter the following command:
     stty sane 

To reproduce the problem 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 ksh exits, the keyboard should echo characters. If 
it does not, then this bug has occurred.

PROBLEM:  (QAR 50297)	 	(Patch ID: OSF400-169)
********
This patch fixes a problem with the ksh shell program. ksh prevents a command, 
which runs in a sub-process, from writing to a tape device.  For example:

$ /usr/bin/ksh -c "/bin/echo foo | /bin/cat > /dev/rmt0h"
/usr/bin/ksh: /dev/rmt0h: cannot create

PROBLEM:  (HPAQ22AF7)	 	(Patch ID: OSF400-157)
********
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:  (QAR 51086)		 (Patch ID: OSF400-234)
********
This patch fixes a problem that occurs if the kernel tunable variable 
"old-obreak" is set to zero and the system is running the Korn shell
(ksh). The shell gets caught in an infinite loop printing a message
similar to the following. Eventually the process will core dump.

     /adp/bin/adpbkup[135]: no space

PROBLEM:  (QAR  26933)		 (Patch ID: OSF400-270)
********
This patch fixes a problem in which the ksh command periodically prints
erroneous characters instead of the command that was typed.

The only identifiable effects are loss of logging information and the loss
of access to the command from the command line edit.

PROBLEM:  (QAR 52892,49928)	 (Patch ID: OSF400-304)
********
This patch fixes a problem in which the ksh shell sometimes reverses the
group id (GID) and the effective group id (egid) of the calling process.

For example if the calling process (starter) spawns ksh to execute the
"/usr/bin/id" command, the output would be:

$ ./starter xx
uid=4294967200(vsctest) gid=15(users) egid=4(bin) groups=0(system)
uid=4294967200(vsctest) gid=4(bin) egid=15(users) groups=0(system)
$
### Note that the gid and egid have been interchanged

PROBLEM:  (CLD HGOQ50006, QAR 52992) (Patch ID: OSF400-326)
********
This patch fixes problems that occur when using the ksh shell. When the PATH
for a command is not found, the following error message is displayed.  Also,
when the set command is executed, the system core dumps.

     /bin/ksh: invalid multibyte character

PROBLEM:  (USG-05628)		 (Patch ID: OSF400-435)
********
This patch fixes a problem that occurs when using the Korn shell (ksh).
Variables set with the typeset -L[n] built-in command do not work correctly
when other subshells are spawned. For example:

Example: < Incorrect results >
$ /usr/bin/ksh
$ typeset -xL3 var=hello
$ typeset | grep var
export 3 leftjust 3 var
$ echo $var
hel
$ /usr/bin/ksh
$ typeset -xL3 var=hello
$ typeset | grep var
export 3 leftjust 3 var
$ echo $var

$
Example: < Correct results >
$ /usr/bin/ksh
$ typeset -xL3 var=hello
$ typeset | grep var
export 3 leftjust 3 var
$ echo $var
hel
$ /usr/bin/ksh
$ typeset -xL3 var=hello
$ typeset | grep var
export 3 leftjust 3 var
$ echo $var
hel
$


FILE(s):

/usr/bin/ksh 		subset OSFBASE400
CHECKSUM: 20753    264 
/usr/bin/posix/sh	subset OSFBASE400
CHECKSUM: 20753    264 

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

This patch fixes segfaults in nm for object files generated by the C++ compiler.
PROBLEM:  (QAR 45427)		 (Patch ID: OSF400-438)
********
This patch fixes segfaults in nm for object files generated by the C++ compiler.

This problem will only occur for most C++ objects compiled with full debug info
using the compiler option "-g", "-g2" or "-g3".  nm may produce partial output
before the segfault occurs and nm dumps core.


FILE(s):

/usr/ccs/lib/cmplrs/cc/nm               subset OSFBASE400
CHECKSUM: 01712    344     RCS: nm.c      Revision: 4.2.15.3

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

This patch fixes a problem that occurs when the default c compiler is used to
compile a program using the following switches on the command line: 
-c -compress -fast.
PROBLEM:  (QAR 56987)		 (Patch ID: OSF400-439)
********
When the -fast switch is specified on the command line, the cc command (driver)
instructs the c compiler to create a single object file for all of the .c files
specified.  If the -c switch is also included, this one large object file 
remains after the compilation completes.  When these two switches are specified,
and the -compress switch is also specified asking for a compressed object, the
cc driver fails to supply its call to objZ (to do the compression) with the
object file name that is being used for the final object file output.

Without this patch, when these switches are used in combination, the call to
objZ to compress the object file fails with a "usage" error since no object
file is specified for the compression.


FILE(s):

/usr/ccs/lib/cmplrs/cc/driver           subset OSFCMPLRS400
CHECKSUM: 15639    264 

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

This patch fixes a problem that occurs on AdvFS systems.  The chfsets function
returns incorrect exit values and inappropriate error messages.
PROBLEM:  (QAR 54607,56125)	 (Patch ID: OSF400-443)
********
This patch fixes a problem that occurs on AdvFS systems. The chfsets function
returns incorrect exit values and inappropriate error messages.

This problem occurs when an inactive domain is specified along with an explicit
list of filesets.  In this case, a successful exit code is returned, which is
incorrect.   If an inactive domain is specified without any filesets then it
fails properly.


FILE(s):

/sbin/chfsets           subset OSFADVFS400
CHECKSUM: 41057     24     RCSfile: chfsets.c      RCS: 1.1.10.2

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

SUPERSEDED PATCHES:	OSF400-007 (7.00),    OSF400-017 (17.00), 
			OSF400-022 (22.00),   OSF400-024 (24.00), 
			OSF400-025 (25.00),   OSF400-027 (27.00),
			OSF400-037 (37.00),   OSF400-047 (47.00), 
			OSF400-039 (39.00),   OSF400-070 (70.00), 
			OSF400-076 (76.00),   OSF400-080 (80.00),
                        OSF400-083 (83.00),   OSF400-088 (88.00), 
			OSF400-093 (93.00),   OSF400-101 (101.00), 
			OSF400-106 (106.00),  OSF400-119 (119.00), 
			OSF400-131 (131.00),  OSF400-133 (133.00), 
			OSF400-139 (139.00),  OSF400-143 (143.00), 
			OSF400-153 (153.00),  OSF400-154 (154.00),
			OSF400-189 (203.00),  OSF400-195 (208.00),
			OSF400-210 (223.00),  OSF400-226 (243.00),
			OSF400-064 (64.00),   OSF400-227 (246.00),
			OSF400-239 (259.00),  OSF400-241 (261.00),
			OSF400-261 (277.00),  OSF400-284 (295.00),
			OSF400-293 (302.00),  OSF400-302 (312.00),
			OSF400-307 (315.00),  OSF400-331 (339.00),
			OSF400-331-1 (339.01), OSF400-323 (332.00), 
			OSF400-334   (340.00), OSF400-341 (345.00), 
			OSF400-348   (354.00), OSF400-362 (363.00),
			OSF400-372   (377.00), OSF400-393 (389.00),
			OSF400-400   (392.00), OSF400-402 (393.00),
			OSF400-403   (397.00), OSF400-408 (400.00),
			OSF400-410   (396.00), OSF400-410B (407.00),
                        OSF400-417   (482.00), OSF400-430 (431.00)



This patch corrects the following:

- Fixes a problem with the DECthreads "legacy" library.  Specifically, this
  patch addresses the potential hang of programs that use the Draft 4 interface
  for pthread_once().

- Fixes a problem in which multithreaded applications that reference a 
  pthread_mutex_destroy routine may fail with EBUSY or the application
  may hang.

- Fixes a problem whereby mkpasswd fails for /etc/passwd files that are
  very large (containing roughly 30 thousand to 80 thousand entries).

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

- Fixes problems in threaded applications with incorrect signal behavior
  and thread creation failures using user allocated stacks.

- Fixes problems that might cause threaded programs running under Digital 
  UNIX 4.0 to hang.  Specifically, this patch addresses situations related
  to DECthread bugcheck, pthread_once() or cma_once(), and unhandled
  exceptions.
 
- Fixes problems in threaded programs related to DECthreads bugchecks, fork()
  fork(), stack corruptions and exception handlin problems.  This patch may
  also fix problems with non-threaded program relating to exception handling.
  
- 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.

- Prevents gethostent() from returning all YP or bind served entries.

- Multithreaded programs running on a multiprocessor may behave as if they 
  have fewer CPUs available for execution.  A considerable performance 
  degradation can be observed in some cases.

- Some valid programs compiled with IEEE mode to receive a floating-point 
  exception even though they should run to completion.

- inet_makeaddr() routine in libc that was returning 8 bytes instead of 4.

- Math library functions not returning the correct NaN value as defined in 
  the Alpha AXP Architecture Reference Manual (Second Edition).

- 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. This
  problem occurs after a user logs into a system with an SRV4-style LAT device.

- Deadlocks that may occur in multithreaded applications which make concurrent 
  use of the fork() and fclose() functions, or the getenv()/setenv() and any 
  time-related function (e.g., localtime()).

- Memory leaks with heavily threaded applications using NIS services for 
  passwd, group, and other system database files.

- The malloc function fails to allocate all available space within the 2GB 
  address space allowed by the taso option.

- On systems running DECthreads: Computations that depend on rounding a 
  floating point value to its nearest integer equivalent will receive an 
  integer with the decimal point value truncated.

- The filename pattern-matching behavior of the find command when it includes 
  the "?" metacharacter. 

- The incorrect parameter type declaration in the new swscanf() routine.

- Unsuccessful attempts to su to root were not recorded in the syslog/auth.log 
  file, for BASE security.

- A memory leak problem associated with the strxfrm() and wcsxfrm() functions.

- Compiling under DEC C++ - Reported by our customer SYBASE

- Using fork() in a multithreaded environment

- Generating core files in a multithreaded environment

- Extra signals delivered in multithreaded programs

- Behavior of TIS mutex lock operations

- The printing, encoding, and propagation of Quiet NaNs in programs using 

- The interaction of signals with setjmp/longjmp called repeatedly in a loop
  was causing a segmentation violation and core dump in a customer's
  application.
  full IEEE math support.

- Threaded applications seeing a deadlock with fork(), premature stack
  overflows, corrupted mutexes, orphaned condition variable or mutex
  blocking structures.

- Fixes a deadlock problem that may occur with multithreaded applications
  calling any of the functions for getting system database information
  (gethostent, getservent, etc.) and which also call fork.  The deadlock
  may occur when such applications are run on systems configured to use
  YP services.

- older call_shared FORTRAN applications to find missing symbols in libc.so.

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

- Fixes a problem where a call to popen() hangs after a bad call to pclose()
  in a threaded program.

- Fixes a problem in which mallopt(M_MXFAST), instead of making malloc() 
  faster makes it as much as 65 times slower.

- Fixes problems with redundant close operations on file descriptors by
  Network Information Services (NIS) and Remote Procedure Calls (RPC) in
  multithreaded applications.

- Fixes a problem where conversion from double-precision floating point
  numbers to single-precision floating point numbers may not round properly
  in IEEE mode when the result should be the smallest denormal.

- Fixes a problem with fastmath functions F_Exp() and F_Pow() that would
  cause floating exception core dumps.

- Fixes a problem in which the rcmd function may cause the system to dump core.

- Fixes the following two problems that occur in the DECthreads core library:

     o The process blocked signal mask, as set by sigprocmask(),
       cleared in the child process following a fork().

     o Under certain load conditions, a DECthreads bugcheck occurs
       in pthread_kill(). This results in a core dump.

- Allows customers to create hashed passwd databases from large passwd
  files by using a new option (-s) to the mkpasswd command.  The -s
  option increases the block size of the database page file.

- 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 deadlock issue between fork() processing and exception handling
  on Digital UNIX 4.0.  An exception occuring during a fork() operation
  would cause the child and parent processes to hang with no cpu activity.

- Fixes a problem in libc.  The allocation of pty's sometimes doesn't work
  correctly.  This can cause problems with the EMACS editor.

- Fixes a couple of problems in the mkpasswd command.

- Fixes a problem with fastmath functions F_Exp() and F_Pow() that would
  cause floating exception core dumps.

- This patch fixes two problems in the DECthreads library:

   o On multiprocessor platforms, condition variable broadcasts were
     occassionally being lost.

   o Stack unwinding during exception processing was losing contexts,
     resulting in incorrect stack traces.

- fixes a problem that may cause a program to cause the IEEE floating point
  emulator to emit this message: "FATAL IEEE FLOATING POINT EMULATION ERROR:

- Corrects a problem related to the statically initialized mutexes in 
  DECthreads library (libpthread.so).

- Fixes a problem whereby a call to the libc dbm_open() routine followed
  immediately by a call to dbm_close() causes hashed database directory
  files to be truncated.

- Corrects a problem which occurs when pthread_cond_timedwait() is called
  with a large timeout value (greater than 23 days).

-There is a problem in the Bind 4.9.3 patch which may cause incorrect messages
 to be reported. It may also cause statically linked programs using certain
 network functions in libc to core dump.

- Fixes a problem with call_shared executables that are linked with libc.a
  instead of libc.so. A symptom of this problem is that routines like 
  dlopen(3) and __fini_* routines are not run.

- Fixes a problem with the auditd daemon.  If auditd is logging to a server
  and the server becomes unavailable, the CPU usage for the daemon rises
  dramatically.

- Fixes a problem in which RPC client functions do not correctly handle system
  calls interrupted by a signal (EINTR errors).

- Fixes two kernel memory faults in networking code.

- Fixes a problem that causes the readdir_r() function to read past the end
  of its input buffer.
PROBLEM: (QAR 44327)    	(Patch ID: OSF400-007)
********
This fix changes the internal encoding of IEEE floating-point Quiet NaNs by
setting the sign bit. This fix also removes an inconsistency between the "user
space" and kernel encoding.  Finally, printf() has been fixed so that a
negative NaN will not be displayed even if the NaN's sign bit is set. This is
in accordance with the IEEE Std 754-1985.

A NaN is the floating-point representation of a result which is "Not A Number"
(e.g. the floating-point result of zero divided by zero is a NaN).

This change is only of interest to programmers who use IEEE floating-point math
with the -ieee or the -ieee_with_inexact option. It does not affect programs or
libraries not using the full IEEE math support. Further, the libm isnan()
routine and the IS_*NAN() macros in /usr/include/fp.h are compatible with both
the old and new encodings.

For more information, see the IEEE Standard for Binary Floating Point
Arithmetic ANSI/IEEE (Std 754-1985). For information about the Alpha AXP
implementation, see the Alpha AXP Architecture Reference Manual (Second Edition)
by Richard L. Sites and Richard T. Witek, Digital Press, 1995. See the section
on "Encodings" (4.7.4).

Compile and execute the example listed below.

       csh>
       csh> cat test.c
       #include 
       #include 
       int main()
       {
           double d_libc = DBL_QNAN, d_zero, d_zero1, d_compute;
           float f_libc = FLT_QNAN, f_zero, f_zero1, f_compute;

           sscanf("0.0","%le",&d_zero);        /* fake out optimizer */
           sscanf("0.0","%le",&d_zero1);       /* so we test dev env */
           f_zero = d_zero;
           f_zero1  = d_zero1;

           d_compute = d_zero / d_zero1;       /* Propagate a NaN */
           f_compute = f_zero / f_zero1;       /* Propagate a NaN */

           printf("DBL_QNAN:%lX\n", *(long *)&d_libc);
           printf(" generated:%lX\n", *(long *)&d_compute);

           printf("FLT_QNAN:%lX\n", *(int *)&f_libc);
           printf(" generated:%lX\n", *(int *)&f_compute);
       }

       Results on a system with out the patches installed.

       csh>
       csh> cc -ieee test.c
       csh>
       csh> a.out
        DBL_QNAN:7FF8000000000000
         generated:7FFFFFFFFFFFFFFF
        FLT_QNAN:7FC00000
         generated:7FFFFFFF
       csh>

       Results on a system with the patches installed, NO recompilation.

       csh> a.out
        DBL_QNAN:FFF8000000000000
         generated:FFF8000000000000
        FLT_QNAN:FFC00000
         generated:FFC00000
       csh>


PROBLEM:  (QAR 45808)  			(Patch ID: OSF400-017)
********
"pthread.h" incorrectly defines the routines pthread_self(),
pthread_testcancel(), pthread_lock_global_np() and pthread_unlock_global_np()
when using a compiler which does not support "#pragma extern_prefix".

The typical symptom of this problem will be an error message from the compiler
being used stating that one of the four routines above are not defined somehow.

A failure case might look like the following:
 cxx: Error: try.cxx, line 9: In the initializer for self, \
                    "pthread_self" is not declared.
              pthread_t self = pthread_self();
            -------------------^

PROBLEM:  (QAR #45997)   	(Patch ID: OSF400-017)
********
Attempting to fork a child process, in a multithreaded program, after having
used a condition variable, may cause a SEGV in the child process.

The symptom of this problem is a SEGV in a child process from a parent which
is multithreaded.

A typical stack trace might look like the following:
            0 cvReinit(0x3ffc008ae28, 0x3ff80578c0c, 0x3ff80577f8c, \
                0x3ffc0187938, 0x3ffc0080c50) [0x3ff805602ec]
            1 uxForkHandler(0x3ff80577f8c, 0x3ffc0187938, 0x3ffc0080c50, \
                0x3ffc0081de0, 0x3ff800d3784) [0x3ff80577f88]
            2 __fork(0x1200165b4, 0x140009900, 0x14003bc20, 0x140003d70, \
                0x3ffc00993c8) [0x3ff800d3780]

PROBLEM:  (QAR #45997)   		(Patch ID: OSF400-017)
********
A child process, created by a multithreaded program, receives an error from a
call to pthread_mutex_destroy() on a mutex.  This will only occur when the
parent calls fork() with other threads blocked on the mutex being destroyed.
If the child unlocks the mutex and then tries to destroy it, EBUSY will be
returned.

The symptom of this problem would be a multithreaded child process exiting or
emitting a message because pthread_mutex_destroy() returned EBUSY.

Another symptom may be an infinite loop in the application.  It is common for
multithreaded programs to retry when EBUSY is returned.

PROBLEM:  (QAR #46441)   (Patch ID: OSF400-017)
********
Multi-threaded programs never create core files.  Usually a DECthreads error
message will have been displayed, the program terminated, but no core file can
be found.

PROBLEM:  (QAR #46442)   (Patch ID: OSF400-017)
********
Multi-threaded programs may receive extra signals.  WARNING: This is a
difficult problem to identify and in the user program.

A simple way to identify the problem would be to modify the user's application
to count the signals it sends and then count how many they receive.  The
number should never be greater than the number sent.  The sender and receiver
must be synchronized somehow, though, to properly identify the problem.

PROBLEM:  (QAR #46443)   (Patch ID: OSF400-017)
********
tis_mutex_lock() in the single-threaded case will recursively lock a mutex of
the default type.  Only mutexes explicitly created as RECURSIVE mutexes should
allow a thread to lock a mutex it has already locked.  When tis_mutex_lock()
is used in a multithreaded environment, the correct behavior exists.


There is no good way to identify this problem.  If an application issues a lock
against a non-recursive type mutex, this patch will cause the illegal recursive
lock attempt to fail.

PROBLEM:  (CLD MGO102122, QAR 45686) (Patch ID: OSF400-022)
********
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:  (ZUO100558)   	(Patch ID: OSF400-024)
********
Unsuccessful attempts to su to root were not recorded in the syslog/auth.log
file, for BASE security.

PROBLEM:  (QAR 46371) 		(Patch ID: OSF400-025)
********
This patch fixes the incorrect parameter type declaration in the swscanf()
routine. This is a new routine introduced in Version 4.0 for ISO C conformance.
According to the ISO C standard, the function prototype for the swscanf()
routine is as follows:

        int swscanf(const wchar_t *, const wchar_t *, ...)

However, this routine was incorrectly implemented by using the following
function prototype:

        int swscanf(const char *, const wchar_t *, ...)

This patch changes the function prototype of the routine to conform to the ISO
C standard. The patch also makes associated changes in the routine's behavior
so that it accepts a Wide-character string for interpretation.

PROBLEM:  (QAR 45694) 		(Patch ID: OSF400-027)
********
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 that the problem fixed by this patch occurs only when you use
locales other than the default C locale.

PROBLEM:  (QAR #46503, CLD USG-03462) (Patch ID: OSF400-037)
********
This patch fixes a problem that occurs on systems running DECthreads.
Multithreaded programs do not create threads with the proper IEEE floating
point rounding mode. Computations that depend on rounding a floating point
value to its nearest integer equivalent will receive an integer with the
decimal point value truncated.

Note that the initial thread does not have a rounding mode problem.

To reproduce this problem, create a thread and use the rint function to round
a floating point value to the nearest integer. The following shows an incorrect
value returned by the rint function:          rint(4.7) -> 4

PROBLEM:  (QAR #47839) 		(Patch ID: OSF400-047)
********
Multithreaded programs running on a multiprocessor system may behave as
ifi they are utilizing only a few of the CPUs available for execution.

To recognize this problem, attach to the process with this suspect behavior
with ladebug.  Issue the command:

        (ladebug) show thread

If you see any "null threads" in the "running" state while there are user
threads in the "ready" state, the application is experiencing this problem.

Output from a ladebug "show thread" for a process with the suspected behavior
may look like this on a four processor system:

Thread State      Substate        Policy     Priority Name
~~~~~ ~~~~~      ~~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~
     1 blocked    cond wait       throughput 11       default thread
    -1 blocked    kernel          fifo       32       manager thread
    -2 running                    idle        0       null thread for VP 0x0
    -3 ready                      idle        0       null thread for VP 0x1
    -4 running                    idle        0       null thread for VP 0x2
    -5 running                    idle        0       null thread for VP 0x3
     2 ready                      throughput 11       
     3 ready                      throughput 11       
     4 ready                      throughput 11       
     5 ready                      throughput 11       
     6 ready                      throughput 11       
     7 ready                      throughput 11       
     8 ready                      throughput 11       
     9 ready                      throughput 11       
    10 ready                      throughput 11       
    11 ready                      throughput 11       
    12 ready                      throughput 11       
    13 ready                      throughput 11       
    14 ready                      throughput 11       
    15 ready                      throughput 11       
>*  16 running                    throughput 11       
    17 ready                      throughput 11       
    18 ready                      throughput 11       
    19 ready                      throughput 11       
    20 ready                      throughput 11       
    21 ready                      throughput 11       

PROBLEM:  (MCPM64E8E) 		(Patch ID: OSF400-039)
********
This patch fixes a problem in which the malloc function fails to allocate all
available space within the 2GB address space allowed by the taso option.

When a call_shared executable built with the taso option calls the malloc
function with certain large values as the requested amount of memory (for
example, 32*1024*1024), malloc may fail to utilize all of the available 31-bit
address space.  With the given example, malloc returns a NULL and sets ERRNO
after 250MB when it should have been able to allocate closer to 1 GB (other
system and process limits permitting).

The problem does not show up when the taso option is not used, or in statically
linked executables.

PROBLEM:  (48427) 		(Patch ID: OSF400-070)
********
On systems configured to use Network Information Services (formerly known as
Yellow Pages), long-lived multithreaded processes that consist of a series of
shorter lived threads which call system database functions such as getpwent()
or getgrnam(), are likely to accumulate large amounts of unused memory.  This
will show up with the "ps -l" command as a continually growing number under the
"SZ" field for the process.  The problem is caused by failure to free resources
allocated for the thread cache information needed in processing NIS data.  The
problem will not show up in single threaded applications, applications that do
not use the get* functions, or on systems that are not configured in
/etc/svc.conf to use the "yp" (NIS) services.

PROBLEM:  (48354, 48675) 	(Patch ID: OSF400-076)
********
This problem causes multithreaded applications to hang indefinitely.  It is
difficult to isolate the problem to a condition that matches this fix, but
if decladebug indicates you have one or more threads in fork() and one or
more in fclose(), you are probably experiencing this problem.  Likewise you
could also be experiencing the problem if you find one thread in getenv() or
setenv() and another in one of the time functions such as localtime().

PROBLEM:  (BRO100738) 		(Patch ID: OSF400-080)
********
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:  (QAR 48474) 		(Patch ID: OSF400-083)
********
This fix changes the encoding of IEEE floating-point Quiet NaNs returned by the
math library by setting the sign bit. This fix corrects inconsistency between
the value returned by the math functions and the kernel encoding.

A NaN is the floating-point representation of a result that is "Not A Number"
(e.g. the floating-point result of zero divided by zero is a NaN).

This change is only of interest to programmers who use IEEE floating-point math
 with the -ieee or the -ieee_with_inexact option. It does not affect programs
or libraries not using the full IEEE math support.

For more information, see the IEEE Standard for Binary Floating Point
Arithmetic ANSI/IEEE (Std 754-1985). For information about the Alpha AXP
implementation, see the Alpha AXP Architecture Reference Manual (Second Edition)
by Richard L. Sites and Richard T. Witek, Digital Press, 1995. See the section
on "Encodings" (4.7.4).

Compile the following program using the -ieee and -lm options:

#include 
#include 
#include 
#include 
main()
{
    double a, b, c, d;
    int i;

    a = sqrt( -1.0 );
    i = sscanf("0.0 0.0 0.0", "%lf %lf %lf", &b, &c, &d);
    assert(i == 3);
    printf( "sqrt( -1.0 ) = %f\t\t0x%016lx\n", a, *(long *)&a );

    d = b / c;

    printf( "0.0 / 0.0 = %f\t\t0x%016lx\n", d,*(long *)&d );
}

Compile this program using the -ieee and -lm command line options.

Results before installing new math library:
sqrt( -1.0 ) = NaNQ             0x7fffffffffffffff
0.0 / 0.0 = -NaNQ               0xfff8000000000000

Results after installing new math library:
sqrt( -1.0 ) = -NaNQ            0xfff8000000000000
0.0 / 0.0 = -NaNQ               0xfff8000000000000

PROBLEM:  (QAR 45667)           (Patch ID: OSF400-088)
********
The inet_makeaddr() libc library routine in V4.0 may corrupt the stackframes of
applications built from V5.1 or earlier versions of the Digital UNIX C++
compiler.   There is no problem for applications built with cc or cc -migrate
or with C++ V5.3 or newer.  The routine inet_makeaddr() is defined to return a
4-byte structure.  However, in V4.0, that routine returns both the required 4
bytes plus an extra 4 bytes of padding.  The V5.1 or earlier versions of C++
were the only compilers that did not provide the extra 4 bytes of padding in
the caller's stackframe.  As a result, the next 4 bytes on the caller's stack
were likely to be corrupted by the extra four bytes of padding.

An example of the problem is shown below:

        % cat a.cxx
        #include 
        #include 

        void main() {
            in_addr  ret;
            long l = 0x5555555555555555;

            printf("l = %lx\n",l);
            ret = inet_makeaddr(inet_addr("16.140.16.3"),
                                inet_addr("16.140.16.3"));
            printf("l = %lx\n",l);
        }

        Results on a system without the patches installed.

        % cxx a.cxx ; a.out
        l = 5555555555555555
        l = 5555555500000000

        Results on a system with the patches installed.

        % cxx a.cxx ; a.out
        l = 5555555555555555
        l = 5555555555555555

This problem is corrected by the patch to the /usr/ccs/lib/libc.a and
/shlib/libc.so libraries.

There are two other alternative solutions to this problem. The first is to
update to the Digital UNIX V4.0A release.  V4.0A contains the corrected
inet_makeaddr() library routines.  The second solution is to recompile the
C++ application with Digital UNIX C++ V5.3 or later.  This newer C++ compiler
allocates 8 bytes of stack space for routines that return 4-byte structures.

PROBLEM:  (QAR 36520, QAR 48372) (Patch ID: OSF400-093)
********
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%]

PROBLEM:  (QAR #48439) 		(Patch ID: OSF400-101)
********
Multi-threaded programs running on a multiprocessor system may behave as if
they are utilizing only a few of the CPUs available for execution.

To recognize this problem, attach to the process with this suspect behavior
with ladebug.  Issue the command:

        (ladebug) show thread

If you see any "null threads" in the "running" state while there are user
threads in the "ready" state, the application is experiencing this problem.

Output from a ladebug "show thread" for a process with the suspected behavior
may look like this on a four processor system:

Thread State      Substate        Policy     Priority Name
~~~~~ ~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~
     1 blocked    cond wait       throughput 11       default thread
    -1 blocked    kernel          fifo       32       manager thread
    -2 running                    idle        0       null thread for VP 0x0
    -3 ready                      idle        0       null thread for VP 0x1
    -4 running                    idle        0       null thread for VP 0x2
    -5 running                    idle        0       null thread for VP 0x3
     2 ready                      throughput 11       
     3 ready                      throughput 11       
     4 ready                      throughput 11       
     5 ready                      throughput 11       
     6 ready                      throughput 11       
     7 ready                      throughput 11       
     8 ready                      throughput 11       
     9 ready                      throughput 11       
    10 ready                      throughput 11       
    11 ready                      throughput 11       
    12 ready                      throughput 11       
    13 ready                      throughput 11       
    14 ready                      throughput 11       
    15 ready                      throughput 11       
>*  16 running                    throughput 11       
    17 ready                      throughput 11       
    18 ready                      throughput 11       
    19 ready                      throughput 11       
    20 ready                      throughput 11       
    21 ready                      throughput 11       

PROBLEM:  (49260)        (Patch ID: OSF400-106)
********
Customer applications that repeatedly call gethostent(), when run on systems
configured to use YP and/or bind services for host entries, will see only the
entries in the local /etc/hosts file.  The problem is not present for similar
routines such as gethostbyname().

The only way to reproduce the problem is to write a program that repeatedly
calls gethostent() and then verify that it does not return all the entries
present in the YP and bind databases served to the machine.

PROBLEM:  (ULC-43)       (Patch ID: OSF400-119)
********
The customer's application sets a timer to go off every 200 milliseconds
via a call to setitimer().  It then loops indefinitely, calling a function
that does a setjmp() and then calling a function that does a longjmp().  On
Digital UNIX V4.0 r386, the application fails with a segmentation fault after
a variable number of loop iterations.

PROBLEM:  (QAR #49720)   (Patch ID: OSF400-131)
********
Multi-threaded applications running on SMP systems, may find their applications
hanging because a thread is never told that a mutex has been unlocked or that a
condition variable has been signaled.

To recognize this problem, use ladebug to display the list of mutexes and
condition variables.

        (ladebug) pthread "mutex -faq; condition -faq"

This will display a very long list of mutexes and condition variables, including
those that belong to libc or libpthread.  An example of the output follows:

(ladebug) pthread "mutex -faq; condition -faq"
.
.
.
Mutex 103 (normal) "mutex at 0x140000b10" (0, block 0x140008b90) is
orphaned blocking structure, 2 threads waiting; waiters: 56, 51
.
.
.
Condition variable 203, "cond at 0x14030b510" (0) is orphaned blocking
structure, 2 threads waiting; waiters: 91, 5
.
.
.

The application will hang forever because the threads are waiting on a blocking
structure not attached to the mutex or condition variable.


PROBLEM:  (QAR #49520)   (Patch ID: OSF400-131)
********
Multi-threaded applications running on SMP systems, may find their applications
hanging because of a corrupted mutex.

To recognize this problem, use ladebug to display the list of mutexes that are
locked:

        (ladebug) pthread "mutex -fal"

This will display a list of locked mutexes.  Some mutexes will be recursive or
error check type mutexes.  Those types of mutexes record the thread that owns
the lock on the mutex.  The corruption is exposed as a recursive or error check
mutex without a thread owner:

(ladebug) pthread "mutex -fal"
Mutex 56 (recursive) "exc cr" (0x3ffc0082f80, block 0x140009d10) is locked
(depth 1), 4 threads waiting; ref count is 4

The output should have a "by thread x" after the "is locked" line above.


PROBLEM:  (QAR #49520)   (Patch ID: OSF400-131)
********
Multi-threaded applications may overflow the stacks of created threads
prematurely.  Applications may receive a SEGV and dump core at unexpected
places when this problem occurs.  The SEGV should be because a memory location
in or near the thread's stack was referenced.

To recognize this problem, use ladebug to run appliation in question and wait
for the SEGV to occur.  Then find the thread that took the SEGV and check to
see what value of the stack pointer is.  Then display the full information on
the thread itself and compare the current stack pointer to the limits displayed.
An example debug session:

(ladebug) run 
Thread received signal SEGV
stopped at [hstTransferContext: ??? 0x3ff80572ca8]
(ladebug) p $sp
0x140028bb8
(ladebug) pthread "thread -f x"
thread 2 (running) "" (0x140006030), created by pthread
  Scheduling: throughput policy at priority 11
  Masked signals: none
  Pending signals: none
  Terminated, result value 0
  Object flags: none; self flags: none; sched flags: none; mutex flags:
    terminated; atomic flags: none
  Thread specific data: 0=0x140006488
  Stack: 0x14002fa38; base is 0x140030000, guard area at 0x140027fff
  General cancelability disabled, asynch cancelability disabled
  Current vp is 0, synch port is 0, vp ID is 0
  Join uses mutex 22 and condition variable 7; wait uses mutex 23 and
    condition variable 8
  The thread's start function and argument are 0x120001bc0
(0x3ffc01834c8)
  The thread's latest errno is 0


You should see that there is a considerable amount of free space on the stack.
(0x140028b
b8 - 0x140027fff = 0xbb9 or 3001 bytes!)

PROBLEM:  (QAR #49804)   (Patch ID: OSF400-131)
********
Multi-threaded applications which use fork() may find their applications hanging
because of a deadlock situation.

To recognize this problem, use ladebug to display the list of locked mutexes
and their waiters.

(ladebug) pthread "mutex -alrq"
  Mutex 1 (normal) "malloc" is locked by 13848, 4 threads waiting;
waiters: 13846, 3, 567, 8
  Mutex 10 (normal) "VM 0 cache" is locked, 1 thread waiting; waiters: 1
  Mutex 13 (normal) "VM 3 cache" is locked, 1 thread waiting; waiters: 13848

In the example above, the malloc mutex is held by thread 13848, but it is
waiting on mutex 13.  A stack trace inspection reveals that mutex 13 is held by
thread 13846.

PROBLEM:  (QAR 49787)    (Patch ID: OSF400-133)
********
A multithreaded application that calls any of the system database "get*"
functions (gethostent, getservent, etc.) and that calls fork(), may deadlock.
DECladebug will show a thread blocking on a mutex lock with the call to fork()
on its call stack, while another thread will also be stuck in the mutex
blocking function with a function name like gethostbynam() on its stack. Other
threads may or may not be stuck on other mutex locks.  The two threads in
question will never progress.  Any subsequent calls to fork will block forever.

PROBLEM:  (CLD #HPXQ9B161, QAR #48888) (Patch ID: OSF400-139)
********
On V4.0 and later, when running a call_shared FORTRAN application linked on an
earlier release, the loader will issue the error message:

 "dlopen: Unresolved symbols".  The error can also occur in older non-FORTRAN
applications that are linked with libc_r.so and call dlopen().  The problem
occurs even though there is no explicit reference to the symbol in the
application or library.

In the particular test reported and fixed by this patch, the DEC FORTRAN
Runtime Library (libfor.so) was inadvertently referencing the following libc
entry symbols:  __index, __rindex,
__realtime_kernel, chk_perm, __chk_perm, fchk_perm, __fchk_perm
and __list_free.  The entry symbols have been replaced in libc.
However, in some cases, they are just error termination routines and are treated
as unsupported.   This fix only handles the resolution of the missing symbols.

PROBLEM:  (CLD SSRT0425U) 	(Patch ID: OSF400-143)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form of
improper file or privilege management. Digital has corrected this potential
vulnerability.

PROBLEM:  (QAR50691)		 (Patch ID: OSF400-153)
********
A call to popen() was hanging after a call to pclose() with an invalid stream
pointer (such as a stream that was not popened) in a threaded program (one
built with -pthread).

PROBLEM:  (50746, 50316) (Patch ID: OSF400-154)
********
When a call to mallopt(M_MXFAST, value) was performed, the performance of
subsequent calls to malloc() slowed by as much as 65 times.

PROBLEM:  (SSRT0296U)    (Patch ID: OSF400-189)
********
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 50961)            (Patch ID: OSF400-195)
********
The native exception handling facility may corrupt the users stack.  This is
most easily seen in an application using threads since the exception handling
facility is always present there. But other applications linked with "-lexc"
may see this problem as well.

A typical stack trace from Ladebug showing this problem may look like this:

(ladebug) t
Stack trace for thread 2
>0  0x3ff80579a94 in /usr/shlib/libpthread.so
#1  0x3ff80110b98 in /usr/shlib/libc.so
#2  0x3ff80110318 in __tis_read_unlock(0x3ff8011031c, 0x3ffc0092500,
        0x3ff8017345c, 0x3ffc0092500, 0x3ffc0087fe0, 0x0)
        DebugInformationStrippedFromFile738
#3  0x3ff80173458 in /usr/shlib/libc.so
#4  0x3ff807b2004 in exc_lookup_function_entry(0x14005d180, 0x3ff807b1d30,
        0x14005d180, 0x23bd5eb8, 0x3ff807b325c, 0x14005c640)
        DebugInformationStrippedFromFile0
#5  0x3ff807b3258 in UnknownProcedure16FromFile1(0x0, 0x14005d9a8, 0x100000001,
        0x14005c640, 0xabadabad00beed00, 0x3ff80579ac0)
        DebugInformationStrippedFromFile1
#6  0x3ff807b3634 in exc_unwind(0x100000001, 0x14005c640, 0xabadabad00beed00,
       0x3ff80579ac0, 0x3ff807b3b04, 0x3ff807b3aa0)
        DebugInformationStrippedFromFile1
#7  0x3ff807b3b00 in __Ots_CSpecificHandler(0x3ff807b3980, 0x14005d6f8,
        0x14005d6d0, 0x14005d180, 0x3ff00000000, 0x14005d408)
        DebugInformationStrippedFromFile4
#8  0x3ff807b2ac4 in UnknownProcedure12FromFile1(0x0, 0x3ff8055c8d8, 0x0,
        0x63ff0000, 0x14005de78, 0x0) DebugInformationStrippedFromFile1
#9  0x3ff807b2da0 in exc_dispatch_exception(0x14005de78, 0x3ff8055c460,
        0x14005d180, 0x23bd5f3c, 0x3ff807b24e0, 0x0)
        DebugInformationStrippedFromFile1
#10 0x3ff807b2534 in exc_raise_exception(0x3ffc00802a0, 0x0, 0x3ff80579a60,
        0x0, 0x3ffc0087650, 0x120002604) DebugInformationStrippedFromFile1
#11 0x14005d17c

Note that the last frame (frame #11 above) does not have any information
printed.  This is symptomatic of the stack being corrupted in such a way
that the debugger cannot interpret it correctly.

PROBLEM:  (QAR 50392)            (Patch ID: OSF400-195)
********
Some applications have bugs in them that developers are trying to find.  The
nature of these bugs might be to corrupt the internal workings of malloc()
or free() such that calling them causes a SEGV.

When this happens, it is possible for the native exception handling routines
to block while accessing their internal procedure descriptor list, due to some
other thread performing a lookup on that list. If the exception handling
routines actually try to block, it is possible for the blocking operation
itself to try to allocate memory and to call malloc() again.  This attempt to
call malloc() will hang.

A typical stack trace from Ladebug showing this error might look like this:

(ladebug) t
>0  0x3ff8057ca24 in /usr/shlib/libpthread.so
#1  0x3ff8057a450 in hstTransferContext(0x1, 0x140048030, 0x3ffc018a010, 0x4,
        0x3ffc0188a50, 0x90) DebugInformationStrippedFromFile109:???
#2  0x3ff8056429c in dspDispatch(0x14000c210, 0x140048c68, 0x140048af0, 0x8f4,
        0x3ffc0082770, 0x0) DebugInformationStrippedFromFile89:???
#3  0x3ff80567b98 in pthread_mutex_block(0x3ffc018a1c0, 0x3ffc018a1d0,
        0x1400e6ef0, 0x8f4, 0x3ffc0082770, 0x0)
        DebugInformationStrippedFromFile95:???
#4  0x3ff8057c820 in __pthread_mutex_lock(0x3ffc018a1d0, 0x1400e6ef0, 0x8f4,
        0x3ffc0082770, 0x0, 0x3ff80575e88)
        DebugInformationStrippedFromFile111:???
#5  0x3ff80575e84 in UnknownProcedure3FromFile103(0x8f4, 0x3ffc0082770, 0x0,
        0x3ff80575e88, 0x3ff800d194c, 0x0)
        DebugInformationStrippedFromFile103:???
#6  0x3ff800d1948 in malloc(0x3ff800d194c, 0x0, 0x3ff80579170, 0x90, 0x0,
        0x3ffc0184e70) DebugInformationStrippedFromFile22:???
#7  0x3ff8057916c in vmAlloc(0x3ff8055d94c, 0x3ffc0082870, 0x0, 0x0,
        0x3ffc018a1c0, 0x3ff8055d934) DebugInformationStrippedFromFile108:???
#8  0x3ff8055d948 in cvGetBlock(0x3ffc0082818, 0x3ffc0082800, 0x14000c040,
        0x3ffc008f7ec, 0x3ffc008f868, 0x3ff8057c8fc)
        DebugInformationStrippedFromFile1:???
#9  0x3ff8055f574 in cvWait(0x3ffc008f868, 0x8f4, 0x3ffc0082870, 0x140048af0,
        0x0, 0x3ff80575e88) DebugInformationStrippedFromFile1:???
#10 0x3ff8055d45c in __pthread_cond_wait(0x3ffc0082870, 0x140048af0, 0x0,
        0x3ff80575e88, 0x3ff8010fd54, 0x0) DebugInformationStrippedFromFile1:???
#11 0x3ff8010fd50 in /usr/shlib/libc.so
#12 0x3ff8010f570 in __tis_write_lock(0x3ff8010f574, 0x3ff8019241c,
        0x3ff80172aec, 0x1, 0x3ff800ccda0, 0x1)
        DebugInformationStrippedFromFile735:???
#13 0x3ff80172ae8 in __exc_lookup_function_entry(0x0, 0x0, 0x3ffc018a010, 0x0,
        0x3ff800d1540, 0x1401e5020) DebugInformationStrippedFromFile304:???
#14 0x3ff807b2004 in exc_lookup_function_entry(0x3ffc018a010, 0x0,
        0x3ff800d1540, 0x1401e5020, 0x3ff807b2bec, 0x1400249e0)
        DebugInformationStrippedFromFile0:???
#15 0x3ff807b2be8 in exc_dispatch_exception(0x0, 0x12009407c, 0x140122910,
        0x140020000, 0x0, 0x0) DebugInformationStrippedFromFile1:???
#16 0x3ff807b38c4 in exc_raise_signal_exception(0x80, 0x0, 0x3ff8019241c, 0x1,
        0x1, 0x140048af0) DebugInformationStrippedFromFile3:???
#17 0x3ff800d3b28 in __sigtramp(0x3ff8019241c, 0x1, 0x1, 0x140048af0,
        0x140122ef8, 0x0) DebugInformationStrippedFromFile105:???
#18 0x3ff8019241c in UnknownProcedure22FromFile22(0x3ffc0080c50, 0x1,
        0x14017cc00, 0x2f, 0x140024f20, 0x3ff8057c824)
        DebugInformationStrippedFromFile22:???
#19 0x3ff80192f40 in UnknownProcedure17FromFile22(0x3ff801943c8, 0x1, 0x10,
        0x3ffc0080e18, 0x72, 0x140024f20) DebugInformationStrippedFromFile22:???
#20 0x3ff801943c4 in /usr/shlib/libc.so
#21 0x3ff80194604 in /usr/shlib/libc.so
#22 0x3ff800d1958 in malloc(0x3ff800d195c, 0x0, 0x12008e3bc, 0x140024f20,
        0x1401232a0, 0x14017cc00) DebugInformationStrippedFromFile22:???
#23 0x12008e3b8 in lxldalc() /vobs/nlsrtl3/src/lxi/lxldalc.c:54

Note that frame #23 has a call to malloc().  In frame #16 a synchronous signal
(such as a SEGV) is taken, which results in an exception being raised.  Notice
in frame #6 that malloc() is called again as part of handling the exception,
which leads to the thread blocking.  This is because the previous call to
malloc() caused it to lock its internal mutex for synchronization purposes.

This recursive call to malloc() is the problem.  The user might be able to fix
the cause of the original SEGV if its accompanying exception is fully processed.
This patch allows the SEGV to be processed fully and correctly.

PROBLEM:  (QAR 49804)            (Patch ID: OSF400-195)
********
Threaded applications may see hangs when trying to use fork().  A prior patch
fixed only a part of the problem.

The user sees the child process with a stack trace from Ladebug like this:

(ladebug) t
>0  0x3ff8057ca24 in /usr/shlib/libpthread.so
#1  0x3ff8057a450 in hstTransferContext(0x1, 0x140ae11f0, 0x3ffc018a010, 0x4,
        0x3ffc0188a50, 0x3ffc01852c0) DebugInformationStrippedFromFile109:???
#2  0x3ff8056429c in dspDispatch(0x140051810, 0x1408641a8, 0x140864030, 0x0,
        0x3ffc01851d0, 0x0) DebugInformationStrippedFromFile89:???
#3  0x3ff80567b98 in pthread_mutex_block(0x3ffc008ae28, 0x3ffc01876f8,
        0x140621c00, 0x0, 0x3ffc01851d0, 0x0)
        DebugInformationStrippedFromFile95:???
#4  0x3ff8057c820 in __pthread_mutex_lock(0x3ffc01876f8, 0x140621c00, 0x0,
        0x3ffc01851d0, 0x0, 0x3ff8057984c)
        DebugInformationStrippedFromFile111:???
#5  0x3ff80579848 in vmReinit(0x0, 0x3ff8057984c, 0x3ff80578e70, 0x0,
        0x3ffc0080c50, 0x3ffc0081de0) DebugInformationStrippedFromFile108:???
#6  0x3ff80578e6c in /usr/shlib/libpthread.so
#7  0x3ff800d36e0 in __fork(0x120040830, 0x0, 0x140684bc0, 0x0, 0x1f, 0x0)
        DebugInformationStrippedFromFile335:???
#8  0x12004082c in forkTranslator(inoutp_handle=0x140a9b8f8,
        inoutp_operation_data=0x140763a00) dp_xlatr.c:3610
#9  0x12004040c in forkedTranslatorInterface(inoutp_handle=0x140a9b8f8,
        in_operation_code=eConnect, inoutp_operation_data=0 x140763a00,
        getr=0x0, putr=0x0, arg_p=0x0) dp_xlatr.c:3471
#10 0x12003e0c0 in dp_callTranslator(inoutp_handle=0x140a9b8f8,
        in_operation_code=eConnect, inoutp_operation_data=0x140763a00,
        inp_scb=0x140621c00, getr=0x0, putr=0x0, arg_p=0x0) dp_xlatr.c:1894
#11 0x12003d878 in dp_connectToTranslator(inp_scb=0x140621c00) dp_xlatr.c:1468
#12 0x1200649d0 in dp_pjaConnectToTranslator(inp_Scb=0x140621c00,
        in_docPdlOid=1252, inoutp_printerPdlOid=0x140a9b988,
        outp_needsTranslator=0x140a9b9a8) pja_doc.c:726
#13 0x12005b4a0 in startDocument_1(getr=0x12004bb0c, putr=0x12005dc40,
        inp_fib=0x140a53c00) dp_pja.c:1508
#14 0x12004b234 in fiberRoutineJacket(inp_fib=0x140a53c00) dp_jbstp.c:1276
#15 0x12004b430 in fibThreadJacket(inp_fib=0x140a53c00) dp_jbstp.c:1331
#16 0x3ff80574b94 in thdBase(0x0, 0x3ffc0183430, 0x3ffc018a010, 0x1, 0x45586732,
        0x3) DebugInformationStrippedFromFile101:???

    Note that frame #7 above shows the call to fork().  The DECthreads library
    is then entered with an attempt to lock a DECthreads internal mutex in
    frame #4.  This attempt causes the thread to block while waiting for
    another thread to unlock the mutex.  But because this is the only thread
    left in the child process after the parent forks, this mutex will never
    be unlocked.  The parent failed to lock this mutex during the fork
    operation and so is incorrectly left in the locked state in the child.

PROBLEM:  (QAR 51033)                    (Patch ID: OSF400-195)
********
Threaded applications using pthread_kill() may experience a stack corruption.
This is rather difficult to detect.

PROBLEM:  (QAR 51214)                    (Patch ID: OSF400-195)
********
A threaded application can experience a DECthreads bug check with a message
that mentions the routine nxm_resched(). This application might also hang
with one of its threads having a stack trace containing a frame for a call
to the routine errBugcheck().

The formatted DECthreads bugcheck message might look like this:

(ladebug) t
>0  0x3ff80568b20 in pthread_mutex_unblock(0x3ffc00802a0, 0x0, 0x0,
        0x3ffc0181580, 0x3ffc018a968, 0x0)
        DebugInformationStrippedFromFile95:???
#1  0x3ff8057c1f8 in __pthread_mutex_unlock(0x0, 0x0, 0x3ffc0181580,
        0x3ffc018a968, 0x0, 0x3ff80575618)
        DebugInformationStrippedFromFile111:???
#2  0x3ff80575614 in UnknownProcedure5FromFile103(0x3ffc0181580,
        0x3ffc018a968, 0x0, 0x3ff80575618, 0x3ff800d6904, 0x3ffc0187760)
        DebugInformationStrippedFromFile103:???
#3  0x3ff800d6900 in fflush(0x3ff800d6904, 0x3ffc0187760, 0x3ff80565cfc,
        0x3ffc018a968, 0x3ffc0187768, 0x0)
        DebugInformationStrippedFromFile84:???
#4  0x3ff80565cf8 in errBugcheck(0x3ffc0185da0, 0x3ffc01700d8, 0x4, 0x26e,
        0x0, 0x3ffc018aae0) DebugInformationStrippedFromFile90:???
#5  0x3ff8057bcd4 in UnknownProcedure26FromFile109(0x0, 0x14014b438,
        0x3ffc018a968, 0x3ffc018a968, 0x1, 0x14014b438)
        DebugInformationStrippedFromFile109:???
#6  0x3ff8057b0d8 in UnknownProcedure20FromFile109(0x500, 0x1f4, 0x1,
        0xffffffffdfbbee16, 0x1f4, 0x14014b478)
        DebugInformationStrippedFromFile109:???
#7  0x3ff80535200 in msg_receive(0x0, 0x3ffc018abf0, 0x0, 0x0, 0x3ffc018a968,
        0x0) DebugInformationStrippedFromFile6:???
#8  0x3fefffffffd in ???

Note that frame #8 above is not readable.  This is to be expected because the
problem is occuring in an "upcall" frame.  (This "upcall" frame is used by the
kernel to call into user space to perform an operation.) Note that frame #4
above contains the DECthreads bugcheck call, but als note that it eventually
calls pthread_mutex_unblock() (frame #0 above). This call to ed_mutex_unblock()
hangs because it is incorrect to call pthread_mutex_unblock() within the context
of an upcall.

PROBLEM:  (QAR 51214) (Patch ID: OSF400-210)
********
A threaded application might hang while attempting to issue a message from the
DECthreads bugcheck.  A stack trace of a thread in this state will contain
frames for calls to the routines errBugcheck(), fflush() and
pthread_mutex_unblock().

A typical stack trace for this problem might look like the following:

 (ladebug) t
>0  0x3ff80568b20 in pthread_mutex_unblock(0x3ffc00802a0, 0x0, 0x0,
0x3ffc0181580, 0x3ffc018a968, 0x0) DebugInformationStrippedFromFile95:???
#1  0x3ff8057c1f8 in __pthread_mutex_unlock(0x0, 0x0, 0x3ffc0181580,
0x3ffc018a968, 0x0, 0x3ff80575618) DebugInformationStrippedFromFile111:???
#2  0x3ff80575614 in UnknownProcedure5FromFile103(0x3ffc0181580,
0x3ffc018a968, 0x0, 0x3ff80575618, 0x3ff800d6904, 0x3ffc0187760)
DebugInformationStrippedFromFile103:???
#3  0x3ff800d6900 in fflush(0x3ff800d6904, 0x3ffc0187760,
0x3ff80565cfc, 0x3ffc018a968, 0x3ffc0187768, 0x0)
DebugInformationStrippedFromFile84:???
#4  0x3ff80565cf8 in errBugcheck(0x3ffc0185da0, 0x3ffc01700d8, 0x4,
0x26e, 0x0, 0x3ffc018aae0) DebugInformationStrippedFromFile90:???
#5  0x3ff8057bcd4 in UnknownProcedure26FromFile109(0x0, 0x14014b438,
0x3ffc018a968, 0x3ffc018a968, 0x1, 0x14014b438)
DebugInformationStrippedFromFile109:???
#6  0x3ff8057b0d8 in UnknownProcedure20FromFile109(0x500, 0x1f4, 0x1,
0xffffffffdfbbee16, 0x1f4, 0x14014b478)
DebugInformationStrippedFromFile109:???
#7  0x3ff80535200 in msg_receive(0x0, 0x3ffc018abf0, 0x0, 0x0,
0x3ffc018a968, 0x0) DebugInformationStrippedFromFile6:???
#8  0x3fefffffffd in ???

Note that frame #8 above is not readable.  This is to be expected because the
problem is occuring in an "upcall" frame.  (This "upcall" frame is used by the
kernel to call into user space to perform an operation). Note that frame #4
above contains the DECthreads bugcheck call, but also note that it eventually
pthread_mutex_unblock() hangs because it is incorrect to call
pthread_mutex_unblock() within the context of an upcall.

PROBLEM: (EVMS-GRYPHON-FT QAR 00237) (Patch ID: OSF400-210)
********
This patch fixes a situation where threads would hang in pthread_once() or
cma_once() routines.

The DECthreads routines pthread_once() and cma_once() use the DECthreads global
mutex.  The first thread to call pthread_once() or cma_once() would lock this
mutex and subsequent threads calling pthread_once() or cma_once() would hang.
This problem was fixed on OpenVMS and the patch has been ported to Digital
UNIX 4.0.

PROBLEM: (IPMT HPAQ11MMTG) (Patch ID: OSF400-210)
********
For the signals traditionally representing synchronous errors in a program
DECthreads catches the signal and converts it into an equivalent exception.
Digital UNIX 4.0 attempts to print an abort message for an unhandled exception.
If an unhandled exception occurs in a libc library I/O routine, the thread
causing the exception may hang in abort() because of a deadlock over an I/O
mutex.

PROBLEM:  (QAR 52332, 51161)             (Patch ID: OSF400-226)
********
This patch corrects problems encountered when using signals with multithreaded
programs.  It is possible for threaded applications to lose signals on occasion.

PROBLEM:  (QAR 52339)                    (Patch ID: OSF400-226)
********
This patch corrects a random memory corruptor in multithreaded applications.

PROBLEM:  (IPMT HPAQ309UJ)               (Patch ID: OSF400-226)
********
This patch corrects problems encountered where multithreaded applications
fail to create threads with user allocated stacks.

PROBLEM:  (HPAQ31FCB)                   (Patch ID: OSF400-064)
********
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.

PROBLEM:  (HPAQB17NM, QAR 50343, QAR 49427, QAR 52143) (Patch ID: OSF400-227)
********
When the /etc/passwd files are very large, a performance degradation may occur.

When the number of passwd entries reaches up into the 30,000 to 80,000 range,
mkpasswd will sometimes fail to create an ndbm database.  Since the purpose of
this database is to allow for efficient (fast) searches for passwd file
information, failure to build it causes a serious performance degradation for
commands that rely on it.

The change to the mkpasswd command creates one potential database compatibility
problem.  If a customer application that accesses the password database created
by mkpasswd is built static, i.e., non-shared, that application will be unable
to read from or write to the password database correctly.  This would cause
the customer application to fail either by generating incorrect results or 
by possibly dumping core.  Any staticly linked application that directly or
indirectly calls any of the libc ndbm routines documented in the ndbm(3) man 
page and then accesses the password database would be affected.  To remedy 
this situation, the customer would need to re-link the application using the
libc.a supplied with this patch.

PROBLEM:  (QAR 45580)           (Patch ID: OSF400-239)
********
Multithreaded applications that call the pthread_mutex_destroy routine may
fail when there are no threads referencing the mutex.  This is caused by
a race condition inside the pthread_mutex_unlock code.  The typical symptom
will be a return value of EBUSY from pthread_mutex_destroy.

*** NOTE ***
Applications using "inline" mutex operations, as described in the pthread.h
header file, will need to RECOMPILE with the application of this patch.
The instruction sequences for the pthread_mutex_unlock routine have changed.

Please refer to the existing note in pthread.h entitled "NOTICE: inline function
performance vs. binary compatibility" for more information.

PROBLEM:  (QAR 52332)            (Patch ID: OSF400-239)
********
Over time, a multithreaded application may find that asynchronous signals are
not being delivered to it.  The asynchronous signal may have originated outside
the application or from within it. The effect will be that the signal is
pending against a thread, the thread will NOT have the signal blocked, but it
will not be delivered to that thread.

PROBLEM: (QAR 00237)            (Patch ID: OSF400-241)
********
This patch fixes a situation where threads would hang in the DECthreads POSIX
1003.41/Draft 4 (d4) interface's pthread_once() routine.

The d4 legacy routine pthread_once() uses the DECthreads global mutex.
The first thread to call pthread_once() would lock this mutex and
subsequent threads calling pthread_once() would hang.  This problem
was fixed on OpenVMS and the patch has been ported to Digital UNIX 4.0.

PROBLEM:  (QAR 52405, QAR 52710)	 (Patch ID: OSF400-261)
********
The problem this patch fixes shows up only in multithreaded applications.
File descriptors opened by the application may unexpectedly be closed when NIS
or RPC services are called, either directly or through remote database lookups
(e.g., getpwent()).  Subsequent I/O operations on the applications file
descriptor will typically produce an error with errno set to EBADF.

PROBLEM:  (QAR 52450, QAR  52464)	 (Patch ID: OSF400-261)
********
The problem this patch fixes will only show up in multithreaded applications.
The problem symptoms are that heavy usage of any of the several database
lookup functions such as getpwent() and getprotoent(), from multiple short-lived
threads, may eventually result in the application getting a segmentation
violation, core dumping, and exiting.

PROBLEM:  (QAR 52810,40239,53048) (Patch ID: OSF400-284)
********
This patch is mandatory for JAVA applications.

This patch fixes a problem where conversion from double-precision floating
point numbers to single-precision floating point numbers may not round
properly in IEEE mode when the result should be the smallest denormal.

More specifically, software completion of the Alpha CVTTSSU instruction does
not properly round the result when the input double value is between the
smallest S-float denormal and 1/2 the smallest S-float.

For example:

   double d = 1.5E-45;
   double f;
   f = d;

   The result should be:1.40129846E-45
   The result before the patch is 0.0.

PROBLEM:  (QAR 52294, CLD SDT-1335) (Patch ID: OSF400-293)
********
There is a problem with the F_exp(), the fast exponentiation function,
and the F_pow(), the fast math power function, in the way that they
handle underflow arguments.

For certain arguments, a calls to F_exp() and F_pow() result in a
floating-point exceptions.

PROBLEM:  (CLD HPAQ30CW2, QAR 51943)	 (Patch ID: OSF400-302)
********
This patch fixes a problem in which the rcmd function may cause the system
to dump core.  User applications that produce a call to rcmd() may experience
this problem.  Typically, the application has calls to either the fget()
or fclose() function.

PROBLEM:  (QAR 53701)		 (Patch ID: OSF400-307)
********
In applications linked with -pthreads, the process signal mask is being lost
(set to zero) in the child process following a fork() operation.

PROBLEM:  (QAR 53767)		 (Patch ID: OSF400-307)
********
Occasionally, under certain load condtions, a DECthreads bugcheck occurs
in pthread_kill().  This results in a core dump.

PROBLEM:  		(Patch ID: OSF400-331)
********
When the /etc/passwd file is very large, a performance degradation may occur.

When the number of passwd entries reaches up into the 30,000 to 80,000 range
or greater, mkpasswd will sometimes fail to create a hashed (ndbm) database.
Since the purpose of this database is to allow for efficient (fast) searches
for passwd file information, failure to build it causes commands that rely
on it to do a linear search of /etc/passwd.  This results in a serious per-
formance degradation for those commands.

For customers choosing to use the mkpasswd -s option to avoid this type of
failure, a potential database/binary compatibility problem may arise.  If a
customer application that accesses the password database created by mkpasswd
is built statically (non-shared), that application will be unable to read
from or write to the password database correctly.  This would cause the
customer application to fail either by generating incorrect results or by
possibly dumping core.  Any statically linked application would be affected
if it directly or indirectly calls any of the libc ndbm routines documented
in the ndbm(3) man page and then accesses the password database.  To remedy
this situation, the customer would need to re-link the application.

Customers who do not use the mkpasswd -s option will not see this database/
binary compatibility problem.

PROBLEM:  (QAR 53135,44398)		 (Patch ID: OSF400-323)
********
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 53589)		 (Patch ID: OSF400-334)
********
In applications linked with -pthreads, the parent and child processes of
a fork() operation may be seen to hang if an exception occurs during fork()
processing.

PROBLEM:  (QAR 52093)		 (Patch ID: OSF400-341)
********
The openpty() routine in libc doesn't handle signal logic correctly.
This can cause the following problem to occur when using the EMACS editor.
If you use the command "M-X shell" to start up a shell in a buffer, then
you will sometimes see the message:

  Warning: no access to tty; thus no job control in this shell...

PROBLEM:  (Patch ID: OSF400-348)
********
The mkpasswd command dumps core when user just types 'mkpasswd -s' with no
other arguments.  It also wasn't using the page block size of an existing
database if the -s option was not specified.

PROBLEM:  (QAR 52294, CLD SDT-1335)	 (Patch ID: OSF400-362)
********
There is a problem with the F_exp(), the fast exponentiation function, and
the F_pow(), the fast math power function, in the way that they handle
underflow arguments.

For certain arguments, a calls to F_exp() and F_pow() result in floating-point
exceptions accompanied by core dumps.

PROBLEM: (QAR 55232)		 (Patch ID: OSF400-372) 
********
Broadcasts of a condition variable was occassionally being lost, even though
there were threads actually waiting on that condition variable.  The result
was that threads would never receive notice to unblock and start running
again.  This problem is most evident on multiprocessor systems.

PROBLEM: (QAR 55647)		 (Patch ID: OSF400-372) 
********
During the search for exception handlers, DECthreads unwound the stack and,
in the process, removed the stack frame in which the exception occurred. 
The result was an incorrect stack trace with missing frames.

PROBLEM:  (QAR 51274, HPAQC0X4J)	 (Patch ID: OSF400-393)
********
The multiplication of 2 single precision floating point numbers in ieee
mode when the result prior to rounding is the largest denormal will cause
the IEEE emulator to fail with the message:

    FATAL IEEE FLOATING POINT EMULATION ERROR:
    unf:  "UNEXPECTED 2nd execution calls underflow"

Compile the following program with the command
"cc  -float -ieee emerror.c -o emerror":
#include 
 /* This code causes the IEEE emulator to fail with the
  * message indicated below:
  FATAL IEEE FLOATING POINT EMULATION ERROR:
  floating_underflow:  "UNEXPECTED 2nd execution calls underflow"
  * The -ieee and either (-float  or -std1 ) switch is imperative.
  * cc -ieee -float emerror.c -o emerror
  */
 main(){
     float fr,fi,gi,gr,ci;
     sscanf("0 80020c18 bf7fffff 80800000", "%x%x%x%x", &fr, &gi, &fi, &gr);
     printf("%s=%18.9e (%08x)\n","fr",fr,*(int*)&fr);
     printf("%s=%18.9e (%08x)\n","gi",gi,*(int*)&gi);
     printf("%s=%18.9e (%08x)\n","fi",fi,*(int*)&fi);
     printf("%s=%18.9e (%08x)\n","gr",gr,*(int*)&gr);
     ci = fr*gi + fi*gr;
     printf("%s=%18.9e (%08x)\n","ci",ci,*(int*)&ci);
 }
Results before applying the patch:
fr=   0.000000000e+00 (00000000)
gi=  -1.880094124e-40 (80020c18)
fi=  -9.999999404e-01 (bf7fffff)
gr=  -1.175494351e-38 (80800000)
FATAL IEEE FLOATING POINT EMULATION ERROR:
unf:  "UNEXPECTED 2nd execution calls underflow"
   pc:    0xfffffc000060e368
  ins: 0x20001274
  op1: 0x5ad9b01a
  op2: 0x800000000Killed

Results after applying the patch: (a kernel reboot is necessary)
fr=   0.000000000e+00 (00000000)
gi=  -1.880094124e-40 (80020c18)
fi=  -9.999999404e-01 (bf7fffff)
gr=  -1.175494351e-38 (80800000)
ci=   1.175494351e-38 (00800000)

PROBLEM: (QAR 55153)		 (Patch ID: OSF400-400)
********
There is a problem in the statically initialized mutex operations.  If the
preprocessor symbol _PTHREAD_NOMETER_STATIC is not defined, a statically
initialized mutex makes a call into DECthreads before it attempts to lock
or to unlock for the first time. This call provides metering information.
If the metering is not enabled, the mutex, in its subsequent attemps to 
lock or to unlock, will not make the call into DECthreads unless there is
contention. There was a bug in the call which is causing the mutex to make
the call every time it attempt to lock or to unlock.  The bug results into
slow mutex operations.  The dynamically initialized mutex operations are
unaffected by the bug. The fix helps all statically initialized mutex 
operations that do not use metering.

PROBLEM:  			(Patch ID: OSF400-402)
********
A call to the libc dbm_open() routine followed immediately by a call to
dbm_close() causes hashed database directory files to be truncated and
applications that do such a thing to fail.

PROBLEM: (CLD HPAQA0X6X) 	(Patch ID: OSF400-403)
********
There is a bug in the DECthreads libpthread library for Digital UNIX 4.0
and later that is manifested by calling pthread_cond_timedwait() with
an pthread_cond_timedwait() with an unusually large timeout value 
(greater than 23 days).  The symptom is that the threaded program takes
up a significant amount of CPU time (close to 100%). The bug does not
occur if the timeout value is either less than 2,000,000 seconds or more
than 5,000,000 seconds. With the fix, pthread_cond_timedwait() can be
called with any timeout value.

PROBLEM:  (QAR 56298)		 (Patch ID: OSF400-408)
********
There is a problem in the Bind (Domain Name Service) patch which may cause
incorrect messages to be reported from certain networking related applications
and from certain networking related functions in the C runtime library.
It may also cause segmentation violations in existing statically linked
applications using the US english message catalog, and in dynamically linked
applications using non-english message catalogs.  In all cases the problem will
only occur if the LANG environment variable is set.

PROBLEM:  (QAR 48541)		 (Patch ID: OSF400-410)
********
Executables that are explicitly linked call_shared with the archive version
of libc (libc.a) and *not* the shared library version of libc (libc.so) may
have problems using libc features that are supported by the loader.  These
loader features are documented in the loader(5) man page in the section that
describes the low level _rld_new_interface() routine and includes running
the application's fini routines (if any) and proper functioning of the dl*
routines such as dlopen(3).

One might be able to identify this problem by using the debugger to set a 
breakpoint in the _rld_new_interface() routine and running the application
with the failing loader feature(s). If the breakpoint is hit and the 
_rld_new_interface() is simply doing a return, the libc archive version of
_rld_new_interface() which is defined in ldr_dummy.o is being run instead
of being preempted by a call into the loader.  Relinking the application
with the patched version of libc.a should correct this problem.

PROBLEM:  (GOZ100846)		 (Patch ID: OSF400-417)
********
If the server to which an auditd daemon has been configured to send its audit
information becomes unavailable, the local auditd daemon cpu usage rises
dramatically.

PROBLEM:  (QAR 52255,52836,55617)	 (Patch ID: OSF400-430)
********
This patch fixes a problem in which RPC client functions do not correctly handle
system calls interrupted by a signal (EINTR errors).

If a multi-threaded RPC client process catches a signal, a read or write to an
RPC socket can get interrupted, and the RPC operation fails.

PROBLEM:  (QAR 56286)		 (Patch ID: OSF400-448)
********
There is a problem with the readdir function in that the readdir_r() function
reads past the end of its input buffer.

The readdir_r() function is using memcpy to copy data that's partly off the
end of its internal buffer.  This happens when the buffer is close to an
an unmapped page.


FILE(s):

/usr/sbin/auditd                           subset OSFBASE400
CHECKSUM: 01055    504     RCSfile: auditd.c       RCS: 1.1.8.6
/sys/BINARY/fp.mod                         subset OSFBIN400
CHECKSUM: 01768     69 
/sbin/halt              		   subset OSFBASE400
CHECKSUM: 47796    352     RCSfile: halt.c         RCS: 4.2.18.4
/usr/ccs/lib/libc.a                        subset OSFCMPLRS400
CHECKSUM: 26474   1954 
/usr/ccs/lib/libc_r.a                      subset OSFCMPLRS400
CHECKSUM: 26474   1954 
/usr/lib/nls/msg/en_US.ISO8859-1/libc.cat  subset OSFBASE400
CHECKSUM: 06660     13
/shlib/libc.so                             subset OSFBASE400
CHECKSUM: 22278   1543 
/shlib/libc_r.so                           subset OSFBASE400
CHECKSUM: 22278   1543 
/usr/shlib/libexc.so                       subset OSFBASE400
CHECKSUM: 47269     48
/usr/shlib/libpthread.so                   subset OSFBASE400
CHECKSUM: 11178    416 
/usr/shlib/libpthreads.so                  subset OSFBASE400
CHECKSUM: 26748    120
/usr/shlib/libpthreaddebug.so              subset OSFBASE400
CHECKSUM: 16295    144 
/sbin/ls                                   subset OSFBASE400
CHECKSUM: 10393    416     RCSfile: ls.c           RCS: 4.3.23.6
                           RCSfile: flsbuf.c       RCS: 4.2.15.2
                           RCSfile: errlst.c       RCS: 4.2.9.2
                           RCSfile: __lc_dlsym.c   RCS: 1.1.2.5
                           RCSfile: sia_globals.c  RCS: 1.1.11.2
                           RCSfile: dlsym.c        RCS: 1.1.2.5
/usr/sbin/mkpasswd                         subset OSFBASE400
CHECKSUM: 06128     24     RCSfile: mkpasswd.c     RCS: 4.2.17.5 
/sbin/mount                                subset OSFBASE400
CHECKSUM: 07139    512     RCSfile: mountxdr.c     RCS: 4.2.7.2
                           RCSfile: mountxdr_v3.c  RCS: 1.1.2.3
                           RCSfile: mount.c        RCS: 4.3.42.18
                           RCSfile: mountxcdr.c    RCS: 1.1.2.4
/usr/sbin/mount         		   subset OSFBASE400
CHECKSUM: 12875     56     RCSfile: mountxdr.c     RCS: 4.2.7.2
/usr/sbin/umount                           subset OSFBASE400
CHECKSUM: 63922     24     RCSfile: umount.c       RCS: 4.2.18.2
/sbin/umount            		   subset OSFBASE400
CHECKSUM: 37134    336     RCS: umount.c      Revision: 4.2.18.2
/usr/bin/nslookup                          subset OSFCLINET400
CHECKSUM: 33376     96
/usr/lib/nls/msg/en_US.ISO8859-1/nslookup.cat subset OSFCLINET400
CHECKSUM: 10924      7
/sbin/reboot            		   subset OSFBASE400
CHECKSUM: 27445    336     RCSfile: reboot.c       RCS: 4.2.16.3
/usr/bin/uudecode               	   subset OSFBASE400
CHECKSUM: 56566    360     RCSfile: uudecode.c     RCS: 4.3.11.3
/usr/lbin/upd_merge             	   subset OSFBASE400
CHECKSUM: 64700    384 
/usr/sys/include/arch/alpha/fpu.h          subset OSFBINCOM400
CHECKSUM:  17133     12
/usr/sbin/ypbind                           subset OSFCLINET400
CHECKSUM: 50576    328     RCSfile: ypbind.c       RCS: 4.2.7.3

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

This patch fixes a problem with the lex command.  Programs built with lex 
may exhibit various problems which only occur after the following warning:

        Maximum token length exceeded
PROBLEM:  (QAR 57670)		 (Patch ID: OSF400-455)
********
This patch fixes a problem with the lex command. Programs built with lex may
exhibit various problems which only occur after the following warning:

        Maximum token length exceeded

To reproduce the problem, use the following lex specification:

%{
#define NUMBER 400
#define COMMENT 401
#define TEXT 402
#define COMMAND 403
#if defined (YYLMAX)
#undef YYLMAX
#define YYLMAX 20
#endif
%}
%%
[ \t]+  ;
[0-9]+                  |
[0-9]+\.[0-9]\+ |
\.[0-9]+        { return NUMBER; }
#*                      { return COMMENT; }
\.[^\"\n]*\"    { return TEXT; }
[a-zA-Z][a-zA-Z0-9]+    { return COMMAND; }
\n                                              { return '\n'; }
%%
#include 

int main(int argc, char *argv[])
{
        int val;

        while(val = yylex()) switch(val) {
                case NUMBER:
                        printf("NUMBER\n");
                        break;

                case COMMENT:
                        printf("COMMENT\n");
                        break;

                case TEXT:
                        printf("TEXT\n");
                        break;

                case COMMAND:
                        printf("COMMAND\n");
                        break;

                case '\n':
                        printf("RETURN\n");
                        break;

                default:
                        printf("Unknown:%d\n", val);
        }

        return 0;
}
lex lexer.l
cc lex.yy.c -o lexer

To execute the test, type in any character sequence. If you type a character
sequence greater than 20, you will receive the following message:

          Maximum token length exceeded


FILE(s):

/usr/ccs/lib/ncform             subset OSFPGMR400
CHECKSUM: 48894      6 

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

SUPERSEDED PATCHES:	OSF400-258 (274.00), OSF400-320 (329.00),
			OSF400-374 (383.00), OSF400-391 (484.00),
			OSF400-395 (485.00)

This patch corrects the following:

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

- 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 problem in which /usr/bin/pax : cpio -pl does not link files when
  possible, but copies them.

- Fixes a file corruption problem that may occur with certain applications, for
  example Realtime applications, that use the plock() system call or the mlock()
  and mlockall() library routines.

- Fixes the following problems with the pax command when cpio format is used:

     o The cpio -z command hangs the system when small files are read using
       a large block size.

     o When reading a series of commands, cpio fails on the second command
       and displays a "No input" error message. If an identical third cpio
       read is issued, cpio works as expected.

- Fixes a problem with the tar and pax programs.  These programs incorrectly
  append files to an existing archive and cause the file to become corrupt.
PROBLEM:  (MANBBP075, HPXQC1120) (Patch ID: OSF400-258)
********
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: OSF400-320)
********
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.

PROBLEM:  (QAR  50945, QAR 52097)	 (Patch ID: OSF400-374)
********
This patch fixes problem in which /usr/bin/pax : cpio -pl does not link
files when possible, but copies them.

PROBLEM:  (QAR 48149,47127)		 (Patch ID: OSF400-395)
********
This patch fixes the following problems with the pax command when cpio format
is used:

  o The cpio -z command hangs the system when small files are read using
    large block size.

  o When reading a series of commands, cpio fails on the second command
    and displays a "No input" error message. If an identical third cpio
    read is issued, cpio works as expected.

PROBLEM:  (MCGMA0CZ6,QAR 57700)		 (Patch ID: OSF400-457)
********
This patch fixes a problem with the tar and pax programs. These programs 
incorrectly append files to an existing archive and cause the file to
become corrupt.

A user will not notice the corruption until they read the archive using
either the "tar t" or "tar x" commands. For example, a file named foo.tar
would have the following message in the middle of the output:

     tar: foo.tar : This doesn't look like a tar archive
     tar: foo.tar : Skipping to next file...


FILE(s):
/usr/bin/pax            	subset OSFBASE400
CHECKSUM: 34876    120             RCSfile: pax.c    RCS: 1.1.16.9
/usr/bin/cpio           	subset OSFBASE400
CHECKSUM: 34876    120 
/usr/bin/tar           		subset OSFBASE400
CHECKSUM: 34876    120 
/sbin/.upd..pax        		subset OSFBASE400 
CHECKSUM: 14526    120    RCSfle: pax.c     RCS: 1.1.16.9
/sbin/.upd..cpio        	subset OSFBASE400 
CHECKSUM: 14526    120 
/sbin/.upd..tar  	        subset OSFBASE400 
CHECKSUM: 14526    120 

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

SUPERSEDED PATCHES:	OSF400-018 (18.00),   OSF400-040 (40.00), 
			OSF400-059 (59.00),   OSF400-072 (72.00), 
			OSF400-078 (78.00),   OSF400-084 (84.00),
			OSF400-102 (102.00),  OSF400-138 (138.00),
			OSF400-219 (237.00),  OSF400-253 (269.00),
			OSF400-286 (307.00),  OSF400-288 (299.00),
                        OSF400-411 (413.00), OSF400-425 (426.00),
                        OSF400-432 (433.00), OSF400-288 (299.00),
                        OSF400-411 (413.00), OSF400-425 (426.00),
                        OSF400-432 (433.00)

This patch corrects the following:

- Fixes problems in the error paths of the ATM subsystem.  A majority of
  these result in system crashes.  These crashes are most prevalent when
  stressing LAN Emulation (LANE).

- The system fails to establish one of the required VCs when joining an
  ATM Emulated LAN (LANE).

- A panic and other problems that can occur in the ATM subsystem when there 
  is a large amount of signalling activity.  It also fixes a potentially 
  invalid signalling message.

- The ATM LAN Emulation code which was preventing correct emulation of 
  Ethernet Multicast functionality.

- A panic when the ATM driver is brought up/down and Lan Emulation (LANE) is 
  active.  A lockmode=4 (lock debug mode) panic is also fixed.  Both of these 
  are a by-product of installing patch OSF400-040.

- A number of kernel memory fault panics in the ATM subsystem. The panics are 
  seen when the connection to the ATM switch is lost, particularly under heavy 
  load.  The patch also fixes problems with ATM timers and memory leaks.

- ATM issues relating to the use of UNI 3.1 signaling

- ATM issues relating to running LANE (Lan Emulation) 

- Systems with a high rate of connection startup/teardown may panic in 
  atm_arp_timer() with "kernel memory fault".

- Systems running ATM in multivendor environments can panic in atmip_send() 
  with "kernel memory fault".

- The atmarp hostname command may return without printing out the contents of
  the ATM ARP entry for the hostname.

- Two panics in the lta driver, ATM LANE interoperability problems with IBM
  switches and slow recovery of UNI 3.0 signalling from network interruptions.

- An upgrade/replacement for the OTTO/OPPO ATM driver and fixes a number of
  flow control and signalling problems.  If you are seeing "No Buffer Space"
  messages, experiencing pauses or hangs when receiving data on signalling/
  ilmi pvc's, or have any problems with FLOWMASTER flow control with CLIP
  or LANE over ATM, you should install this patch.

- Contains performance enhancements to the ATM OTTO driver when greater 
  than 300 VC's are configured.  This replacement driver uses hash buckets
  to improve search time in the VC data structures resulting in significant
  performance gains.

- When tcpdump is run with ATM LAN emulation, a kernel memory fault occurs.

- Fixes two problems with the ATM 350 driver.

  On reboot, a panic could be encountered before getting into single user
  mode. The panic would occur inside the ltaintr routine and this routine
  would be noted in the dump stack trace.  This problem was seen on Personal
  Workstation 500ua (MIATA) and the ATM 350 card.

  The second problem is a panic: thread_block: interrupt level call when
  rt_preempt_opt (REALTIME preemption) is enabled.  A typical stack trace
  would look like this for the top of the stack:

  panic
  thread_block()
  thread_preempt()
  panic
  thread_block()
  unix_release_force()
  unix_release()
  schedtransmit()
  softclock_scan()

  or this:

  panic
  thread_block()
  thread_preempt()
  panic
  thread_block()
  unix_release_force()
  unix_release()
  ottooutput()
  atm_cmm_send()

- An upgrade enhancement to the ATM350 driver.  This patch prevents panics in
  driver routines that can be called from different interrupt levels.

- Fixes a problem with the ATMworks 351 (Meteor) loadable driver.
PROBLEM:  (QAR 46172) 		(Patch ID: OSF400-018)
********
This patch fixes a panic in atm_arp_timer().  This panic will only be seen on 
Systems with high rate of connection startup/teardown.

Stack trace looks like:

    panic(""kernel memory fault")  
    ["../.  ./../../src/kernel/bsd/subr_prf.c":791]
    trap() ["../../../../src/kernel/arch/alpha/trap.c":1457]
    _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1388]
    atm_arp_timer() ["../../../../src/kernel/netinet/atm/atm_arp.c":4019]
    softclock_scan() ["../../../../src/kernel/bsd/kern_clock.c":1287]
    hardclock() ["../../../../src/kernel/bsd/kern_clock.c":1072]
    _XentInt() ["../../../../src/kernel/arch/alpha/locore.s":996]


PROBLEM:  (QAR 46545)		 (Patch ID: OSF400-018)
********
This patch fixes a panic in atmip_send().  This panic will only be seen in 
mixed vendor ATM environments where the Digial UNIX V4.0 system is acting as 
the ARP server.

Stack trace looks like:

     boot() ["../../../../src/kernel/arch/alpha/machdep.c":2342]
     panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":791]
     trap() ["../../../../src/kernel/arch/alpha/trap.c":1457]
     _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1388]
     atmip_send() ["netinet/atm/ip_converge.c":568]
     atm_arp_process_inreq() ["netinet/atm/atm_arp.c":1952]
     atm_arp_process_receive() ["netinet/atm/atm_arp.c":1308]


PROBLEM:  (QAR 46546) 		(Patch ID: OSF400-018)
********
The "atmarp hostname" command may just return without printing out the contents
of the ATM ARP entry for hostname (as documented in the man page).

PROBLEM:  (QAR 45396) 		(Patch ID: OSF400-040)
********
Use of LANE on Digital Unix V4.0 can lead to system crashes which are caused by
kernel memory corruption.  The stack traces are varied but typically will panic
in the kernel malloc routine.  The stack trace attached below is an example
of this scenario:

  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2412]
  1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":791]
  2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1457]
  3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1388]
  4 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":871]
  5 atm_cmm_esi_alloc() ["../../../../src/kernel/atm/cmm/cmm_esi.c":112]
  6 atm_cmm_new_global_esi() ["../../../../src/kernel/atm/cmm/cmm_esi.c":139]
  7 atm_cmm_error() [" ../../../../src/kernel/atm/cmm/cmm_adi.c":952]
  8 otto_manage_up() 
    ["/usr/sde/osf1/build/ptaos.nightly/src/kernel/io/atm/drivers/otto/
     if_otto.c" :2398]
  9 otto_manage() ["/usr/sde/osf1/build/ptaos.nightly/src/kernel/io/atm/
    drivers/otto/if_otto.c":2345]
  10 atm_cmm_driver_config() ["../../../../src/kernel/atm/cmm/cmm_adi.c":1191]
  11 atm_cmm_mmi_private() ["../../../../src/kernel/atm/cmm/cmm_manage.c":3940]
  12 atm_cmm_ioctl() ["../../../../src/kernel/atm/cmm/cmm_manage.c":347]
  13 spec_ioctl() ["../../../../src/kernel/vfs/spec_vnops.c":2130]
  14 vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1165]
  15 ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":498]
  16 ioctl() ["../../../../src/kernel/bsd/sys_generic.c":374]
  17 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":540]
  18 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1173]
  
PROBLEM:  (QAR 47297) 		(Patch ID: OSF400-040)
********
When using the mtu option (maximum transmit unit) of the atmelan(1) command, 
the mtu does not get correctly updated if the LANE Configuration Server/LANE 
Server negotiates the mtu down.  This can lead to dropped data over the ATM 
network. 

PROBLEM:  (QAR 45183)		 (Patch ID: OSF400-040)
********
The thread used to perform ATM timer activity generates an excessive amount of 
context switching.  The thread is started even if no ATM hardware is in use.
Also, shutting down and restarting an interface results in the timers speeding 
up.

PROBLEM:  (QAR 45184) 		(Patch ID: OSF400-040)
********
Once ATM signalling is disabled via "atmsig down" it can't be reenabled without
first disabling and reenabling the inteface (atmconfig down/atmconfig up).
Note that though this is fixed for "Classical IP over ATM" (RFC 1577) it
is still a problem for LANE.

PROBLEM:  (QAR 47902) 		(Patch ID: OSF400-040)
********
LANE does not work with UNI 3.1 signaling.

PROBLEM:  (46382, 42406) 	(Patch ID: OSF400-059)
********
This patch fixes a number of possible kernel memory fault panics that can
occur in the ATM subsystem.  The panics are seen when the signalling and ILMI
connections to the ATM switch are lost, for example when the switch fails, or
when the fiber-optic link is disconnected.  The problem is most likely to 
occur when the there is heavy ATM traffic from the system, such that 
re-connections are being attempted frequently.

The patch also adds a backoff mechanism which moderates the rate at which 
ATM reconnections are attempted for Classical IP (RFC 1577) networks.  This
prevents the ATM switch from being continuously bombarded with requests.

Three representative panic stack traces are shown below:

    0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2342]
    1 panic("thread_block: simple lock owned") 
      ["../../../../src/kernel/bsd/subr_prf.c":707]
    2 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1847]
    3 thread_preempt() ["../../../../src/kernel/kern/sched_prim.c":3704]
    4 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2286]
    5 panic("kernel memory fault") 
      ["../../../../src/kernel/bsd/subr_prf.c": 791]
    6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1457]
    7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1388]
    8 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":871]
    9 atmip_new_ppa() ["../../../../src/kernel/netinet/atm/ip_converge.c":1585]
   10 atmip_exception() ["../../../../src/kernel/netinet/atm/ip_converge.c":779]
   11 atm_cmm_ppa_tell() ["../../../../src/kernel/atm/cmm/cmm_ppa.c":537]
   12 atm_cmm_new_ppa() ["../../../../src/kernel/atm/cmm/cmm_ppa.c":366]
   13 fsm_set_response_rcvd() 
      ["../../../../src/kernel/atm/uni3.x/ilmi/fsm.c":1169]
   14 proc_resp() ["../../../../src/kernel/atm/uni3.x/ilmi/agent.c":1369]
   15 agent_parse() ["../../../../src/kernel/atm/uni3.x/ilmi/agent.c":343]
   16 atm_ilmi_process_receive() 
      ["../../../../src/kernel/atm/uni3.x/ilmi/agent.c":191]
   17 atm_sig_event_process() 
      ["../../../../src/kernel/atm/uni3.x/cmmintf/qsaal_converge.c":1136]


   0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":488]
   1 panic("event_timeout: panic request") 
     ["../../../../src/kernel/bsd/subr_prf.c":703]
   2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":979]
   3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":844]
   4 printf() ["../../../../src/kernel/bsd/subr_prf.c":379]
   5 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":753]
   6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1457]
   7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1392]
   8 atm_cmm_release_vc() ["../../../../src/kernel/atm/cmm/cmm_cmi.c":927]
   9 atm_cmm_con_release() ["../../../../src/kernel/atm/cmm/cmm_smi.c":938]
  10 atm_sig_release_all_calls() 
     ["../../../../src/kernel/atm/uni3.x/cmmintf/q93b_sig.c":3016]
  11 AmUiAmtRstInd() 
     ["../../../../src/kernel/atm/uni3.x/cmmintf/q93b_sig.c":2885]
  12 amComTCON() ["../../../../src/kernel/atm/uni3.x/q93b/am_bdy2.c":3517]
  13 amCbTmrExpiry() ["../../../../src/kernel/atm/uni3.x/q93b/am_bdy3.c":775]
  14 cmPrcTmr() ["../../../../src/kernel/atm/uni3.x/common/cm_bdy5.c":180]
  15 amActvTmr() ["../../../../src/kernel/atm/uni3.x/q93b/am_bdy1.c":4286]
  16 schedule_sig_timers() 
     ["../../../../src/kernel/atm/uni3.x/common/ss_ptsp.c":3651]

   0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":414]
   1 panic("event_timeout: panic request") 
     ["../../../../src/kernel/bsd/subr_prf.c":703]
   2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":811]
   3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":844]
   4 printf() ["../../../../src/kernel/bsd/subr_prf.c":379]
   5 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":753]
   6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1457]
   7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1388]
   8 atmip_make_call() ["../../../../src/kernel/netinet/atm/ip_converge.c":2004]
   9 atmip_output() ["../../../../src/kernel/netinet/atm/ip_converge.c":445]
  10 ip_output() ["../../../../src/kernel/netinet/ip_output.c":616]
  11 rip_output() ["../../../../src/kernel/netinet/raw_ip.c":240]
  12 raw_usrreq() ["../../../../src/kernel/net/raw_usrreq.c":338]
  13 rip_usrreq() ["../../../../src/kernel/netinet/raw_ip.c":435]
  14 sosend() ["../../../../src/kernel/bsd/uipc_socket.c":1161]
  15 sendit() ["../../../../src/kernel/bsd/uipc_syscalls.c":874]
  16 sendto() ["../../../../src/kernel/bsd/uipc_syscalls.c":713]
  17 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":540]
  18 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1173]

PROBLEM:  		(Patch ID: OSF400-059)
********
The ATM signalling timer values are not correctly initialized when the user
switches the interface between UNI versions.  For example, following the 
command:
	atmsig version driver=lta0 uni=3.1
the command:
	atmsig timers driver=lta0
will show that the timers are still set to the UNI version 3.0 values.

PROBLEM:  		(Patch ID: OSF400-059)
********
When an outgoing ATM connection is attempted, but is not completed, the lta
driver does not free some memory used to keep track of the connection.  This
can result in excessive consumption of kernel memory.  The command:
	vmstat -M
would show a continuing increase in memory allocated to the ATM subsystem.

PROBLEM:  (QAR 48570) 	(Patch ID: OSF400-072)
********
If the ATM driver is brought down while LANE is active the system will 
panic.  The sequence of commands causing this are:

atmconfig up driver=lta0
atmsig up driver=lta0
atmelan create driver=lta0
atmconfig down driver=lta0
atmsig up driver=lta0

This will occur after installing patch id OSF400-040.  The kernel stack trace
associated with this problem is as follows:

   0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2361]
   1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":791]
   2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1457]
   3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1388]
   4 strncmp() ["../../../../src/kernel/arch/alpha/copy.c":211]
   5 cm_ppa_add() ["../../../../src/kernel/net/if_lane/cm_sap_shim.c":980]
   6 cm_exception() ["../../../../src/kernel/net/if_lane/cm_sap_shim.c":1122]
   7 atm_cmm_ppa_tell() ["../../../../src/kernel/atm/cmm/cmm_ppa.c":543]
   8 atm_cmm_pvc_ppa_create() ["../../../../src/kernel/atm/cmm/cmm_ppa.c":239]
   9 atm_cmm_error() ["../../../../src/kernel/atm/cmmi/cmm_adi.c":946]
  10 otto_manage_up()
     ["../../../../src/kernel/io/atm/drivers/otto/if_otto.c":2398]
  11 otto_manage()"../../../../src/kernel/io/atm/drivers/otto/if_otto.c":2345]
  12 atm_cmm_driver_config()["../../../../src/kernel/atm/cmm/cmm_adi.c":1191]
  13 atm_cmm_mmi_private()["../../../../src/kernel/atm/cmm/cmm_manage.c":394]
  14 atm_cmm_ioctl() ["../../../../src/kernel/atm/cmm/cmm_manage.c":347]
  15 spec_ioctl() ["../../../../src/kernel/vfs/spec_vnops.c":2117]
  16 vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1165]
  17 ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":498]
  18 ioctl() ["../../../../src/kernel/bsd/sys_generic.c":374]
  19 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":540]
  20 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1173]

PROBLEM:  (QAR 48569) 		(Patch ID: OSF400-072)
********
When the system is running in debug lockmode (lockmode=4 - usually set in the 
/etc/sysconfigtab).  The system will panic when bringing up ATM.  This only 
occurs after the installation of patch OSF400-040.

The resulting kernel stack trace will look like:

   0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2361]
   1 panic() ["../../../../src/kernel/bsd/subr_prf.c":707]
   2 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1855]
   3 thread_preempt() ["../../../../src/kernel/kern/sched_prim.c":3712]
   4 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2305]
   5 panic("simple_lock: uninitialized lock") 
     ["../../../../src/kernel/bsd/subr_prf.c":791]
   6 simple_lock_fault() ["../../../../src/kernel/kern/lock.c":2065]
   7 simple_lock_valid_violation() ["../../../../src/kernel/kern/lock.c":2065]
   8 atm_cmm_esi_start() ["../../../../src/kernel/atm/cmm/cmm_esi.c":225]
   9 atm_cmm_error() ["../../../../src/kernel/atm/cmmi/cmm_adi.c":946]
  10 otto_manage_up()
     ["../../../../src/kernel/io/atm/drivers/otto/if_otto.c":2398]
  11 otto_manage()"../../../../src/kernel/io/atm/drivers/otto/if_otto.c":2345]
  12 atm_cmm_driver_config()["../../../../src/kernel/atm/cmm/cmm_adi.c":1191]
  13 atm_cmm_mmi_private()["../../../../src/kernel/atm/cmm/cmm_manage.c":394]
  14 atm_cmm_ioctl() ["../../../../src/kernel/atm/cmm/cmm_manage.c":347]
  15 spec_ioctl() ["../../../../src/kernel/vfs/spec_vnops.c":2117]
  16 vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1165]
  17 ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":498]
  18 ioctl() ["../../../../src/kernel/bsd/sys_generic.c":374]
  19 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":540]
  20 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1173]

PROBLEM:  (QAR 48793) 		(Patch ID: OSF400-078)
********
The ATM LANE (LAN Emulation) component was not correctly handling LAN 
Multi-casting.  Without basic LAN Multi-casting, routing protocols fail
to run over LANE interfaces.  This forces the use of static routes.

The UNIX ioctl, SIOCADDMULTI, will fail when attempting to join a Multi-cast 
group.  All multicast packets sent to a Digital UNIX LANE interface will get 
dropped.

PROBLEM:  (QAR 48537) (Patch ID: OSF400-084)
********
When a sustained high volume of ATM signalling traffic is present, the system 
may panic with an "invalid memory write access from kernel mode" error.  The 
stack trace for this panic is shown below:

  0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2361]
  1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":791]
  2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1457]
  3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1388]
  4 dequeue_head() ["../../../../src/kernel/kern/queue.c":114]
  5 SDequeueFirst() ["../../../../src/kernel/atm/uni3.x/common/ss_ptsp.c":1019]
  6 asV3xSendTxQueue() 
    ["../../../../src/kernel/atm/uni3.x/qsaal/as_bdy3.c":1035]
  7 asV30PduBSx() ["../../../../src/kernel/atm/uni3.x/qsaal/as_bdy3.c":4203]
  8 AsLiAalDatInd() ["../../../../src/kernel/atm/uni3.x/qsaal/as_bdy1.c":1641]
  9 atm_sig_process_receive() 
    ["../../../../src/kernel/atm/uni3.x/cmmintf/qsaal_converge.c":1029]
 10 atm_sig_event_process() 
    ["../../../../src/kernel/atm/uni3.x/cmmintf/qsaal_converge.c":1146]

Under similar conditions, the system may also stop processing ATM signalling
traffic, or the ATM subsystem may begin consuming large amounts of memory
(as shown by vmstat -M).  The memory problem is most likely to occur when UNI 
version 3.1 is enabled. 

PROBLEM:  		(Patch ID: OSF400-084)
********
The ATM signaling module generates an illegal SETUP message when a call is 
placed requesting a Broadband Bearer Class of other than "BCOB-X".  This 
problem does not occur when using Classical IP or LAN Emulation.  It could 
occur for a user-written convergence module which uses a different Bearer 
Class.

PROBLEM:  (HPAQA2CEE) 		(Patch ID: OSF400-102)
********
The system fails to establish one of the required VCs when joining an ATM 
Emulated LAN.  The problem has been observed particularly when the LAN 
Emulation server is provided by a FORE Systems switch.

The "atmelan show" command will show a control state of something other than
S_OPERATIONAL.  A signalling trace (via "atmsig trace driver=lta0 state=on
read") will show a CONNECT message repeatedly rejected with a Cause Value of 
"Information Element non-existent or not implemented".

PROBLEM:  (CLD ZUO101032) 	(Patch ID: OSF400-138)
********
This patch fixes a panic with the message "ltaintr: no TX pkt".  An example
stack trace is shown below:

   0 boot()
   1 panic(s = 0xfffffc000065e1f0 = "ltaintr: no TX pkt")
   2 ltaintr()
   3 kn15aa_dispatch_iointr()
   4 _XentInt()
   5 swap_ipl()
   6 boot()
   7 panic(s = 0xfffffc000065e1f0 = "ltaintr: no TX pkt")
   8 ltaintr()
   9 kn15aa_dispatch_iointr()
  10 _XentInt()
  11 gh_zero_memory()
  12 idle_thread()

The panic is a result of the ATM ILMI component overflowing a message buffer.
It will only occur for certain patterns of ATM addresses, and is most likely
to happen when ATM Classical IP is in use.

This patch may also fix other ILMI interoperability problems that do not result
in panics.

PROBLEM:  (CLD ZUO101032) 	(Patch ID: OSF400-138)
********
When the default UNI Version 3.0 signalling is used, it can sometimes take a 
very long time (1.5 minutes or more) for ATM connections to be re-established 
after a network interruption (e.g. a disconnected cable).

This patch changes the default recovery timer and greatly speeds up 
re-connection following an interruption.

PROBLEM:  (QAR 49699) 		(Patch ID: OSF400-138)
********
This patch fixes a possible kernel memory fault panic that might occur on an 
ATM ARP server.  The panic might also occur if a remote system tries to 
establish any ATM connection with invalid signalling parameters.  The panic 
occurs in the routine otto_manage_delvc().

PROBLEM:  			(Patch ID: OSF400-138)
********
This patch fixes a possible interoperability problem with IBM 8260 switches
(certain firmware revisions).  The problem prevents the Digital UNIX system
from joining an emulated LAN.  The system repeatedly rejects of the incoming 
point-to-multipoint VC connections with a cause value of 100.

This problem could also occur any time a remote system attempted a connection
where the Forward and Backward SDU sizes were not equal.

PROBLEM:  (DEKBC1129) 		(Patch ID: OSF400-219)
********
This problem is caused by corruption in an internal queue of the LANE ARP
code.  The symptoms are either a system hang in process_event_queue() or
one of the following kernel memory fault stack traces:

        0  boot()
        1  panic("kernel memory fault")
        2  trap()
        3  _XentMM()
        4  event_queue_insert()
        5  la_arp_update()


        0  boot()
        1  panic("kernel memory fault")
        2  trap()
        3  _XentMM()
        4  process_event_queue()
        5  la_arp_refresh_callback()
        6  timer_process()

PROBLEM:  (TKTB26124) 		(Patch ID: OSF400-219)
********
This problem is cause by incorrectly keeping track of the refernce counts of 
the internal ATM ESI structures.  The following is the stack trace of the 
kernel panic:

        0 boot()
        1 panic("ATM ESI CLONE DELETE BOTCH")
        2 atm_cmm_esi_cleanup()
        3 atm_cmm_collector()


PROBLEM:  (TKTB26122) 		(Patch ID: OSF400-219)
********
The symptoms of this problem vary depending on whether or not patch 138.00
is installed.  The problem is triggered by shutting down signaling (i.e.,
issuing the following command "atmsig down driver=xxxx") and then bringing
signaling back up (i.e., "atmsig up  driver=xxxx") when LANE is active.
Without patch id 138.00 installed the following kernel memory fault will result:

           0 boot
           1 panic(s = 0xfffffc00006c7680 = "kernel memory fault")
           2 trap()
           3 _XentMM()
           4 otto_manage_delvc()
           5 otto_manage()
           6 atm_cmm_zombiefy_vc()
           7 atm_cmm_new_call()
           8 AmUiAmtConInd()
           9 amUsrM05S00()
          10 amActvConTbl()
          11 AmLiAsdDatInd()
          12 AsUiAsdDatInd()
          13 asV3xAa4Sx_y()
          14 asV30ProcessSdPdu()
          15 asV30Pdu8S4()
          16 AsLiAalDatInd()
          17 atm_sig_process_receive()
          18 atm_sig_event_process()

With patch 138.00 installed, LANE will not restart unless the following
commands are issued:

         "atmconfig down driver=xxxxx"
         "atmconfig up driver=xxxxx"


PROBLEM:  (TKTB25174) 			(Patch ID: OSF400-219)
********
A system panic is caused by trying to funnel a thread which is in interrupt
context.  The kernel stack trace associated with this problem is as follows:

          0 boot()
          1 panic("thread_block: interrupt level call")
          2 thread_block()
          3 unix_release_force()
          4 unix_release()
          5 cm_rcv()
          6 atm_cmm_receive()
          7 ottoread()
          8 ltaintr()
          9 intr_dispatch_post()
          10 _XentInt()

PROBLEM:  (TKTR32485/QAR 51577)		 (Patch ID: OSF400-253)
********
This patch is an upgrade/replacement for the OTTO/OPPO ATM driver and fixes
a number of flow control and signalling problems.  If you are seeing
"No Buffer Space" messages, experiencing pauses or hangs when receiving data
on signalling/ilmi pvc's, or have any problems with FLOWMASTER flow control
with CLIP or LANE over ATM, you should install this patch.

PROBLEM:  (KAOQ51240/QAR 53078)		 (Patch ID: OSF400-286)
********
This patch contains performance enhancements to the ATM OTTO driver when
greater than 300 VC's are configured.  This replacement driver uses hash
buckets to improve search time in the VC data structures resulting in 
significant performance gains.

PROBLEM:  (CLD CA7Q10817)	 (Patch ID: OSF400-288)
********
When tcpdump is run with ATM LAN emulation, a kernel memory fault occurs.
The kernel memory fault is a result of LAN emulation code not setting up
support for the packet filter component.

A sample stack trace is shown as follows:

   0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2466,]
   1 panic(s = 0xfffffc00005974c0 = "thread_block: interrupt level call")
     ["../../../../src/kernel/bsd/subr_prf.c":707,]
   2 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1925,]
   3 thread_preempt() ["../../../../src/kernel/kern/sched_prim.c":3820,]
   4 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2410,]
   5 panic(s = 0xfffffc00005d2bc0 = "kernel memory fault")
     ["../../../../src/kernel/bsd/subr_prf.c":791]
   6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1512,]
   7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1424,]
   8 pfilt_filter() ["../../../../src/kernel/net/pfilt.c":2757,]
   9 ether_input() ["../../../../src/kernel/net/if_ethersubr.c":1123,]
  10 lec_rcv_cb() ["../../../../src/kernel/net/if_lane/lec_upper.c":229,]
  11 ld_rcv_callback() ["../../../../src/kernel/net/if_lane/lec_data.c":490,]
  12 cm_rcv() ["../../../../src/kernel/net/if_lane/cm_sap_shim.c":775,]
  13 atm_cmm_receive() ["../../../../src/kernel/atm/cmm/cmm_adi.c":881,]
  14 ottoread(0) ["../../../../src/kernel/io/atm/drivers/otto/if_otto.c":2132,]

PROBLEM:  (HPAQA05DF/QAR 56054)		 (Patch ID: OSF400-411)
********
This patch fixes two problems with the ATM 350 driver.

On reboot, a panic could be encountered before getting into single user mode.
The panic would occur inside the ltaintr routine and this routine would be
noted in the dump stack trace.  This problem was seen on Personal Workstation
500ua (MIATA) and the ATM 350 card.

The second problem is a panic: thread_block: interrupt level call when
rt_preempt_opt (REALTIME preemption) is enabled.  A typical stack trace would
look like this for the top of the stack:

   panic
   thread_block()
   thread_preempt()
   panic
   thread_block()
   unix_release_force()
   unix_release()
   schedtransmit()
   softclock_scan()

PROBLEM:  (ZPOBB1275/HPAQA05DF/QAR 56054) (Patch ID: OSF400-425)
********
This patch fixes two problems with the ATM 350 driver.

On reboot, a panic could be encountered before getting into single user mode.
The panic would occur inside the ltaintr routine and this routine would be
noted in the dump stack trace.  This problem was seen on Personal Workstation
500ua (MIATA) and the ATM 350 card.

The second problem is a panic: thread_block: interrupt level call when
rt_preempt_opt (REALTIME preemption) is enabled.  A typical stack trace would
look like this for the top of the stack:

panic
thread_block()
thread_preempt()
panic
thread_block()
unix_release_force()
unix_release()
schedtransmit()
softclock_scan()

        or this:

panic
thread_block()
thread_preempt()
panic
thread_block()
unix_release_force()
unix_release()
ottooutput()
atm_cmm_send()

PROBLEM:  (HPAQA05DF/ZPOBB12755/QAR 56054) (Patch ID: OSF400-432)
********
This patch is an upgrade enhancement to the ATM350 driver.  This patch prevents
panics in driver routines that can be called from different interrupt levels.

PROBLEM:  (QAR 58172)		 (Patch ID: OSF400-464)
********
This patch fixes a problem with the ATMworks 351 (Meteor) loadable driver.
The driver may not get configured at boot time.  The console message seen
is "Couldn't register with CMM" just after the display of the devices 8
MAC addresses.


FILE(s):

/sys/BINARY/atm.mod                                subset OSFATMBIN400
CHECKSUM: 48574    329 
/usr/sbin/atmelan				   subset OSFATMBASE400
CHECKSUM: 48279     24     RCSfile: atmelan.c       RCS: 1.1.9.2
/sys/BINARY/atmip.mod				   subset OSFATMBIN400
CHECKSUM: 54957    244
/usr/sys/include/netinet/atm/atm_arp.h		   subset OSFATMBINCOM400
CHECKSUM: 05478     14     RCSfile: atm_arp.h       RCS: 1.1.7.3
/usr/sys/include/atm/sys/atm_smi.h                 subset OSFATMBINCOM400
CHECKSUM: 07815      7     RCSfile: atm_smi.h       RCS: 1.1.9.3
/usr/sys/include/atm/cmm/cmm.h			   subset OSFATMBINCOM400
CHECKSUM: 39495     25     RCSfile: cmm.h           RCS: 1.1.15.4
/usr/sys/include/netinet/atm/ip_converge.h         subset OSFATMBINCOM400
CHECKSUM: 44834     10     RCSfile: ip_converge.h   RCS: 1.1.11.2
/sys/BINARY/lane.mod                               subset OSFATMBIN400
CHECKSUM: 45168    352 
/sys/BINARY/lta.mod                                subset OSFHWBIN400
CHECKSUM: 43848    151 
/sys/BINARY/uni3x.mod                              subset OSFATMBIN400
CHECKSUM: 10266    949
/usr/sys/include/io/atm/drivers/otto/if_ottodefs.h subset OSFHWBINCOM400
CHECKSUM: 51831     25    RCSfile: if_ottodefs.h   RCS: 1.1.20.5
/usr/sys/include/io/atm/drivers/otto/otto_flow.h   subset OSFHWBINCOM400
CHECKSUM: 49048     12     RCSfile: otto_flow.h     RCS: 1.1.9.2
/usr/sys/include/io/atm/drivers/otto/otto_fakesnmp.h subset OSFHWBINCOM400
CHECKSUM: 34204      7     RCSfile: otto_fakesnmp.h RCS: 1.1.9.2

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

This patch fixes a problem with the LSM volsave command.  The volsave command
returns an exit status of 1 (failure), even when the LSM configuration is
successfully saved.
PROBLEM:  (CA8Q11610, MCGM10TZ5, QAR 51575) (Patch ID: OSF400-465)
********
This patch fixes a problem with the LSM volsave command.  The volsave command
returns an exit status of 1 (failure), even when the LSM configuration is
successfully saved.


FILE(s):

/usr/sbin/volsave               subset OSFLSMBASE400
CHECKSUM: 29974      7     RCSfile: volsave.sh      RCS: 1.1.8.2

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

SUPERSEDED PATCHES:	OSF400-225 (242.00), OSF400-409 (399.00)

This patch corrects the following:

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

- Fixes a problem that may occur on systems with a FDDI controller.  During
  system boot, the system may panic with a message similar to the following:

             panic (cpu 8): kernel memory fault

- Fixes a kernel memory fault caused by the fta FDDI driver.
PROBLEM:  (749B23467/QAR 52293)		 (Patch ID: OSF400-225)
********
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:  (CLD MCPM40MKM, QAR 52790) (Patch ID: OSF400-409)
********
This patch resolves a problem in the FDDI driver during device reset and
initialization.

PROBLEM:  (MGO103292)	  (Patch ID: OSF400-467)
********
This patch fixes a kernel memory fault caused by the fta FDDI driver.  The stack
trace looks like this:

panic
trap
_XentMM
prf
printf
fta_poll_cmd_req
ftaioctl
ifioctl
soo_ioctl
ioctl_base
ioctl
syscall
_Xsyscall


FILE(s):

/sys/BINARY/fta.mod             	subset OSFHWBIN400
CHECKSUM: 08220     56 
/usr/sys/data/if_fta_data.c		subset OSFHWBIN400
CHECKSUM: 60813     21 

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

SUPERSEDED PATCHES:	OSF400X11-023 (501.00)

This patch corrects the following:

- Provides a new en_US.cp850 locale for processing text data originating from 
  the PC environment.

- Provides the ability to let dtterm display all the characters in the PC 
  codeset IBM-850.
PROBLEM:  (CLD DJOBB0755)	 (Patch ID: OSF400-468)
********
environment are not handled correctly when the user's application is running
under a DIGITAL UNIX Latin-1 locale.  This happens, for example, when DIGITAL
UNIX CDE applications are displayed to a PC where they must handle PC text data.

The cause of the problem is that PC code pages (analogous to the codesets of
UNIX locales) encode many displayable characters with values that are in the
ISO Latin-1 C1 control code region.  (0x80-0xa0).  When text files containing
such characters are manipulated under one of the DIGITAL UNIX Latin-1 locales,
applications cannot handle the characters correctly.

This patch installs a new locale, en_US.cp850, in the /usr/lib/nls/loc
directory. After the locale is installed, the user needs to set locale to
en_US.cp850 in order for the application to correctly handle text data
data originating from the PC environment.


PROBLEM:  (CLD DJOBB0755, QAR 54755) (Patch ID: OSF400X11-023)
********
This patch provides the ability to let dtterm display all the characters in 
the PC codeset IBM-850.  Currently, dtterm will not display the characters
0x80-0x9f in that codeset.

This patch is intended for customers who run dtterm on DIGITAL UNIX systems and 
display it against PC X servers.


FILE(s):

/usr/lib/nls/loc/en_US.cp850            subset OSFX11400
CHECKSUM: 51098     32 
/usr/lib/X11/locale/Compose/en_US.cp850  subset OSFX11400
CHECKSUM: 23031     53 
/usr/lib/X11/locale/XLC_LOCALE/cp850     subset OSFX11400 
CHECKSUM: 15930      2   
/usr/lib/X11/locale/compose.dir          subset OSFX11400
CHECKSUM: 64075      2  
/usr/lib/X11/locale/locale.dir           subset OSFX11400
CHECKSUM: 22816      3 

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

SUPERSEDED PATCHES:	OSF400-019  (19.00),	
			OSF400-019-1 (19.01), OSF400-031 (31.00), 
			OSF400-032 (32.00),   OSF400-048 (48.00), 
			OSF400-050 (50.00),   OSF400-052 (52.00),
			OSF400-054 (54.00),   OSF400-055 (55.00), 
			OSF400-057 (57.00),   OSF400-062 (62.00), 
			OSF400-082 (82.00),   OSF400-094 (94.00),
			OSF400-098 (98.00),   OSF400-099 (99.00), 
			OSF400-100 (100.00),  OSF400-110 (110.00), 
			OSF400-113 (113.00),  OSF400-114 (114.00),
		 	OSF400-121 (121.00),  OSF400-123 (123.00), 
			OSF400-127 (127.00),  OSF400-129 (129.00), 
			OSF400-141 (141.00),  OSF400-165 (165.00),
			OSF400-161 (161.00),  OSF400-163 (163.00),
			OSF400-180 (194.00),  OSF400-185 (199.00),
			OSF400-197 (210.00),  OSF400-200 (212.00),
			OSF400-202 (214.00),  OSF400-213 (229.00),
			OSF400-208 (221.00),  OSF400-056 (56.00),
			OSF400-198 (211.00),  OSF400-212 (228.00),
			OSF400-216 (232.00),  OSF400-220 (238.00,
			OSF400-221 (239.00),  OSF400-224 (241.00),
			OSF400-201 (213.00),  OSF400-021 (21.00),
			OSF400-012 (12.00),   OSF400-096 (96.00),
			OSF400-108 (108.00),  OSF400-145 (145.00),
 			OSF400-181 (195.00),  OSF400-182 (196.00),
			OSF400-186 (200.00),  OSF400-232 (251.00),
			OSF400-233 (252.00),  OSF400-242 (264.00),
			OSF400-244 (266.00),  OSF400-235 (255.00), 
			OSF400-010 (10.00),   OSF400-247 (267.00),
			OSF400-250 (268.00),  OSF400-237 (257.00), 
			OSF400-245 (265.00),  OSF400-130 (130.00),
			OSF400-262 (278.00),  OSF400-266 (281.00),
			OSF400-271 (286.00),  OSF400-240 (260.00),
			OSF400-287 (298.00),  OSF400-289 (300.00),
			OSF400-294 (303.00),  OSF400-296 (305.00),
			OSF400-298 (310.00),  OSF400-351 (222.00),
			OSF400-273 (288.00),  OSF400-281 (292.00),
			OSF400-283 (361.00),  OSF400-308 (319.00),
			OSF400-316 (326.00),  OSF400-335 (341.00),
			OSF400-342 (346.00),  OSF400-346 (358.00),
			OSF400-353 (359.00),  OSF400-354 (360.00),
			OSF400-356 (365.00),  OSF400-357 (367.00), 
		 	OSF400-360 (381.00),  OSF400-363 (391.00), 
			OSF400-367 (368.00),  OSF400-049 (49.00),
                        OSF400-104 (104.00),  OSF400-147 (147.00),
                        OSF400-229 (248.00),  OSF400-369 (366.00),
			OSF400-373 (390.00),  OSF400-378 (388.00),
			OSF400-384 (384.00),  OSF400-394 (387.00),
			OSF400-397 (401.00),  OSF400-407 (398.00)
                        OSF400-407B (408.00), OSF400-388 (409.00),
                        OSF400-389  (481.00), OSF400-414 (416.00),
                        OSF400-418  (420.00), OSF400-420 (421.00),
                        OSF400-421 (422.00), OSF400-431 (432.00),
                        OSF400-441 (441.00), OSF400-442 (442.00),
                        OSF400-446 (445.00), OSF400-451 (449.00),
                        OSF400-452 (450.00), OSF400-456 (454.00),
                        OSF400-458 (456.00), OSF400-459 (457.00),
                        OSF400-461 (459.00), OSF400-466 (464.00),
                        OSF400-469 (467.00)

This patch corrects the following:

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

- This network patch, which greatly improves Digital UNIX networking
  performance, is targeted at high traffic Web server systems or
  any system which handles a large number of TCP connections
  simultaneously, ie. more than several thousand at one time.

- This patch addresses compilation errors in the header file 
  for C and C++ programs.

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

- Fixes a problem that occurs on AlphaServer 8200 systems running a firmware
  revision prior to 3.9. The pset_info and psradm commands may fail to 
  correctly report that a CPU is shut down.

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

- This patch resolves a TCP/IP network hang due to IP Q ACK deadlock.
  When this condition occurs the IP Q becomes full due to saturation.
  Representative console messages indicating this condition are shown below:

   SIS00-00-root: IP q full, 315617 packets dropped in the last 5 mins.

- Fixes a performance problem that occurs with UFS file systems.

- Fixes a problem in which the system can panic with "lock already owned by
  thread"

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

- Fixes a problem that occurs on all systems that use networking services.

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

- A kernel memory fault panic that occurs in ip_forward.

- TCP connections may hang and eventually time out if IP options are in use.

- Datagram loss when real-time preemption is turned on.

- 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.  This patch is MANDATORY to install.

- Fixes a kernel memory fault in ether_output packet filter, when running
  tcpdump.

- Fixes problems encountered when using signals with multithreaded programs.

- Fixes a problem in which the ufs property list can become corrupted.

- The kernel panics with a "kernel memory fault", typically in either the
  vm_pg_alloc() or vm_zeroed_pg_alloc() routines.

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

- Fixes a problem that occurs in the vm subsystem. The system panics with 
  "PANIC: VL_UNWIRE: PAGE IS NOT WIRED" message.  This panic occurs most
  frequently on systems running database
  applications.

- When compiling a C++ program, an error message like the following is 
  returned: cxx: Error: toto.cc, line 9: In this statement, "_Plocaltime_r"
  is not declared 

  The interface given in the error message will always begin with _P and end
  with _r.

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

- Fixes a problem that occurs when the system panics with the following
  error message:

		 kernel memory fault

- Allows tuneablity for existing two level task swapping scheme.

- Provides support for the fuser utility. This utility displays a list
  of processes that are holding references to a file on the file 
  system that cannot be unmounted.

- The ObjectStore application from Object Design, Inc. fails with the
  following error:

       "Fatal error Invalid argument(errno = 22) munmap failed: cl_mmap:"

- This patch resolves a kernel memory fault.  This patch is MANDATORY to
  install.

- Fixes a problem that occurs when running the NetWorker Version 4.2c
  application.  Without this patch, NetWorker Version 4.2c will not perform
  well.
 
- The user or system UAC_NOPRINT settings are ignored when an unaligned access
  trap on a user address was taken while in kernel mode; the unwanted error
  message is still printed.

- This patch corrects a problem in which the system can panic when a ufs-mounted
  floppy is removed from the drive, then replaced and accessed. 

- Fixes kernel asynchronous I/O (AIO) problems that occur on clustered systems
  and systems using major databas products on raw disk partitions.  Users of
  database products are advised to install this AIO patch.
 
- Fixes system crash when setting the date on SMP systems. 
          
- Fixes a network socket problem with select() missing state changes on
  clients from non-write to writable.

- This is a mandatory patch for the following systems:

    o Systems that use program debuggers such as Ladebug, dbx, TotalView,
      or gdb
    o Systems that use the /proc file system in any other way (for example,
      the System V Environment ps command)
    o Systems that experience panics in the /proc file system
    o Systems that panic when running multithreaded programs that call
      an exec() function
 
- System panics with message: "vm_map_swapout: negative resident count".  

- vmstat(1) command displays negative numbers when used with the '-P' option.
  Problem may not appear on all platorms / configurations.  It is dependent on
  how the system constructs various internal data structures.
  
- Fixes "kernel memory fault" panics from the kernel malloc() routine, and
  threads hanging in vfs_busy() when file-on-file mounting (kernel option
  FFM_FS) is used with fattach()/fdetach() or System V STREAMS.

- System hangs and crashes in CAM that can occur when running HSZ40/50/70s.

- System panics 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

- Prevents a "kernel memory fault" in bread() during sync operations.

- Processes can hang waiting for a system call to table() to complete.

- When Fortran programs or multithreaded applications that were built on
  a Digital UNIX V3.2C system are run on a Digital UNIX V4.0 system, the
  system displays the following error message: 

	msg_copyout: map entry limit reached

- The /proc filesystem panics with either a "kernel memory fault" or 
  "thread_block: simple lock owned" message. This patch also improves the 
  behavior of the Ladebug debugger.

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

- The system will panic with "u_shm_oop_deallocate: reference count mismatch."

- May improve the performance of a multithreaded application (for example, a 
  video server) that experiences heavy I/O.

- Prevents duplicate namecache entries on SMP systems.

- Multiprocessor 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 too many 
  minutes but will eventually return to normal. This problem may also occur 
  on multiprocessor systems using the NFS client or graphics sub-systems.

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

- Processes hang in an uninterruptible state on a machine which uses NFS 
  loopback mounts.

- 'no sense' and 'unit attention' events are being logged in the error log 
  file as actual errors (CAM_ERROR packet types) when they should be logged 
  as informational (CAM_INFORMATIONAL packet types).

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

- The system panics with the message "panic (cpu #): kernel memory fault" .

- setsockopt(), getpeername(), or bind() will fail with EINVAL if the socket 
  is in a shut down state. In particular, AF_X25 sockets using setsockopt() 
  with the XSO_CLEARCALL option, and AF_WAN sockets using setsockopt() with 
  the HDLC_CLOSEPORT option, can experience this problem.

- Object Broker 2.6-07. Object Broker fails with the following message:
  Dynamic load of component 'OrbV12' for subsytem "Agent" failed.
  The specified executable for the method could not be dynamically loaded.

- A call to the mmap routine returns success without actually mapping the 
  memory region. Subsequent access to the memory region will generate a 
  segmentation fault.

- FORTRAN application fails with "Cannot map data".

- FORTRAN application fails with "Could not open message catalog".

- Provides additional event logging by the SCSI/CAM disk driver to the
  binary.errlog file.

- Fixes a panic that prints "kernel memory fault".

- Corrects a problem with an NFS V3 mounted AdvFS file system where under 
  heavy I/O load, data being written to a file may be lost.  Additionally,
  because file stats are not being saved, the file modification time may
  revert to a previous value.

- Fixes a panic occurs when a UNIX domain socket lock is being held while
  calling vrele().

- Fixes a 'recursion count overflow' problem that occurs on Digital UNIX
  systems.

- An enhanced fix to the solockpair() routine.  This fix was needed because
  the routine was freeing a socket lock structure that was concurrently
  spun upon in lock_write().  Typical problem symptoms include kernel 
  memory faults with sockets, mbufs and mblocks as well as hangs.
  Applications using sockets in a multithreaded, multicpu environment
  can experience a number of lock violations with the socket structures.
  This patch is MANDATORY to install on all systems.  It will be effective
  on Uniprocessor systems when lockmode debugging is invoked.

- Allows some third-party NFS v2 clients to experience a performance
  improvement.

- Fixes a problem that occurs when using real-time applications.  When writing
  large (sequential) files to a UFS file system, time constraints associated
  with the application may be violated.

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

- This is a mandatory patch for the following systems and conditions:

  . Systems that use program debuggers such as TotalView, Ladebug, dbx, or gdb
  . Systems that use the /proc file system in any other way (for example,
    the System V Environment ps command)
  . Systems that experience panics and hangs in the /proc file system
  . Systems that panic when running multithreaded programs that call
    an exec() function

- Fixes a problem with the "ifconfig -a" command. At times, the command will
  not display all of the network interfaces.

- Adds a mechanism to the poll() system call to allow it to be used as a timer.

- Fixes a problem related to misinterpretation of multibyte characters by 
  diff command. The problem also affects the delta command of SCCS.
  The symptom of the problem in the diff command is that it sometimes
  treats a text file containing multibyte characters as a binary file.
  The symptom of the problem in the delta command is that it sometimes
  fails to check in a program source file containing multibyte characters.

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

- Fixes a problem in which a system hang or core dump occurs when one program
  inadvertently overwrites the contents of another program.

- System experiences simple lock timeout panics in virtual memory routines
  when free memory is short and system is trying to reclaim memory.

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

- Fixes a problem in which a system may crash if multiple bad blocks on a
  SCSI device are encountered simultaneously.

- Fixes several problems in the vm subsystem:

    1) Processes using shared memory (SSM) may hang.
    2) Skewed swap space is not allocated evenly.
    3) shmget() failure can cause "Machine Check 660."

- 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 problems with the AdvFS filesystem commands "quotacheck -a" and
  "vquotacheck -a".  These commands erroneously set all quotas for users
  to values derived from the last AdvFS fileset in /etc/fstab, rather than
  correct values for each individual fileset.

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

- Fixes the problem of audit_tool terminating prematurely the reading of a
  complete large log file via zcat.  This usually occurs under gui control.

- This is a mandatory patch for SMP systems with AdvFS file systems.
  Fixes a performance degredation problem that may occur.

- Fixes a problem that may occur after a system panics.  The system may 
  hang when trying to do a crash dump.

- This is a mandatory patch for AlphaServer 2000 and AlphaServer 2100
  SMP systems.  This patch fixes the following problems:

   o Internal lockups may cause performance degradation.
   o The system clock may lose time.

- Fixes a panic with the panic string "spec_badop called" that can sometimes
  occur when an fpathconf system call is issued for a file in an ADvFS
  filesystem.  The panic has following stack trace:

        panic (s = "spec_badop called")
        spec_badop
        fpathconf
        syscall
        _Xsyscall

- Probe of isp fails intermittently during boot.

- A problem that occurs with the Qlogic driver. Because of a problem with
  the sim code, command timeouts occur and the printer device will not be
  detected during SCSI device configuration.

- ISP1020 driver corrections:

      o 'minimum spl violation' panics with lockmode=4
      o simple lock time limit exceeded panics
      o 'CAM_ERROR entry too large' messages
      o 'Unable to restart Qlogic(LUN queue after abort)' panics.
      o Probe of isp fails intermittently during boot.

- A number of problems have been fixed by this patch of the simport driver:

        1. Infrequently, under heavy disk I/O loads, user data can be
           written to the wrong disk, resulting in data corruption.

        2. When a tape drive was powered off, the HSZ40 rebooted, and the
           system then panicked with "simple_lock: time limit exceeded".

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

        4. The system panicked with a kernel memory fault while trying to
           remove an spo resource queue entry.

        5. The system panicked with: "xpt_callback: callback on freed CCB"

- Provides general support for Version A11 KZPSA firmware.

- Improves the performance of applications that map hundreds of thousands of
  files into the virtual address space.

- Fixes a problem in which a filesystem cannot be unmounted.  The system
  displays a "Device busy" error message.

- 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

- This patch is MANDATORY.  This patch contains two vm fixes in both the
  UFS and NFS code that collectively resolve a multitude of nfs and nfsd hangs.

- Corrects a raw I/O data corruption problem that occurs when using database
  applications. The problem is seen when the new-wire-method is active.

- Back-port of PTMIN-style multioption kmem_debug settings.  Changed
  all-or-one kmem_debug bucket selection to all-or-as-selected.  Added
  two new kmem_debug options, KMEM_DEBUG_LINKS and KMEM_DEBUG_PROTECT.

- Fixes a UFS file system problem.  The system may panic with the following 
  error message:     panic spec_badop called

- Eliminates the display of "Stack overflow: pid..." messages that may occur 
  when running Ladebug.

- Fixes a potential memory leak problem that occurs when using the 
  KMEM_DEBUG_PROTECT option of the kmem_debug tuneable attribute.

- This patch is MANDATORY.  Resolves an inode locking problem in the UFS
  iupdat() and itimes() functions.

- Fixes a problem in which a file-on-file system mount of either an NFS or a
  /proc file system will panic the system.

- Fixes an AdvFS problem in which the "advfsstat -n" command causes a core dump.
  The system displays the following error message:

        Memory fault(coredump)

- When a zero length message is sent to an invalid SVIPC message queue, kernel
  memory is corrupted.

- This is a mandatory patch.  This patch fixes a problem that occurs on programs
  that are linked with the pthreads library.  After a parent process forks a 
  child process, the child's floating point state may become corrupt.

- Fixes a problem in which core() system call would try to dump from a memory
  region that has no permission, cause an access violation in core() and the
  core file would be unusable.

  An example of the problem:

        % file core
        core:   core dump, core file is incomplete

        % dbx program core
                .
                .
                .
        can't attach to loader: I/O error
        Exiting due to error during startup

- Fixes a problem that causes the system to panic with the following error 
   message:	 u_anon_free: page busy

- Fixes a problem with the ufs_fsck. ufs_fsck would mishandle certain dir 
  corruptions,recursively asking the user if they want to fix it.

- Fixes a problem that occurs on AlphaServer 8200/8400 systems.  The sytem may
  panic with the following error message:    tb_shoot ack timeout

- Fixes a problem of memory corruption.  A TCP control structure is illegally
  accessed after it is released.  The corrupted memory buckets are the 256-byte
  size.

- Fixes a problem that occurs on AlphaServer 4100 systems.  If no devices are
  attached to the KZPSA disk controller, the system may panic when attempting
  to perform I/O.

- Fixes an AdvFS problem in which the system may panic with the following error
  message:	 thread_block: simple lock owned

- Fixes a problem in which the uswitch system call does not work when an 
  application tries to reset the USW_NULLP option.

- Fixes a problem with the nfsd daemon. Although the maximum number of threads
  that nfsd can run is 128, the nfsd daemon will not start when the sum of UDP
  threads and TCP threads equals 128.

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

- Fixes a panic that occurs when the system's message buffer size is increased
  to beyond the default size of 4096.  During the subsequent reboot, the syslogd
  daemon fails with a "Segmentation fault (core dumped)" message, and creates
  a core file in the "/" directory.
PROBLEM:  (CLD TKTR72070/QAR 47885) (Patch ID: OSF400-054)
********
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.

PROBLEM:  (MCPM750D6, HPXQ36ADF) (Patch ID: OSF400-057)
********
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("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"

PROBLEM:  (QAR 45204, QAR 45380) (Patch ID: OSF400-031)
********
The primary symptom of this problem is that a call to setsockopt(),
getpeername() or bind(), issued when a socket is in a shut down state, will 
fail with errno EINVAL ("Invalid argument").

setsockopt(), getpeername() or bind() fails with errno EINVAL ("Invalid 
argument").

PROBLEM:  (USG-03327/QAR 45030) (Patch ID: OSF400-048)
********
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:  (7MPBA0854, QAR 46525, QAR 38394) (Patch ID: OSF400-055)
********
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 multiprocessor systems using the NFS client or 
graphics sub-systems.

PROBLEM:  (QAR 47837, QAR 48320) (Patch ID: OSF400-062)
********
This patch may improve the performance of a multithreaded application (for 
example, a video server) that experiences heavy I/O.

PROBLEM:  (QAR 45083) 	(Patch ID: OSF400-032)
********
The system panics with the message "panic (cpu #): kernel memory fault" .  In 
the crash dump, the stack trace shows pmap_clrmod_fow calls pmap_pt_access. The
pmap_clrmod_fow does not check for a segment pte and calls pmap_pt_access,
which result in the fault.  This patch corrects that problem.

Stack Trace:

 > 0 stop_secondary_cpu(do_lwc = 0) ["../../../../src/kernel/arch/alpha/cpu.c":
   1 panic(s = 0xfffffc00006b4578 = "event_timeout: panic request") ["../../../
   2 event_timeout(func = 0xfffffc000027df90, arg = 0xfffffc00008892e8, timeout
   3 xcpu_puts(s = 0xfffffc000070ea00, prfbufp = 0xfffffc00008892e8) ["../../..
   4 printf(va_alist = -4398039748776) ["../../../../src/kernel/bsd/subr_prf.c"
   5 panic(s = 0xfffffc00006b70e0 = "kernel memory fault") ["../../../../src/ke
   6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1457, 0xfffffc00004ea37
   7 _XentMM(0x4, 0xfffffc00004fdc6c, 0xfffffc00006fea00, 0xfffffc0001520040, 0
   8 pmap_pt_access(map = 0x400010002, v = 14123853069314699368, pte1p = 0xffff
   9 pmap_clrmod_fow(phys = 18446739675775960960) ["../../../../src/kernel/arch
  10 ubc_msync(0x0, 0xfffffc0009b87e00, 0x700000040, 0xfffffc0009b87e08, 0xffff
  11 u_vp_msync(0x700000040, 0xfffffc0009b87e08, 0xfffffc0009b87e48, 0xfffffc00
  12 u_map_control(0xfffffc00006f7ce0, 0xfffffc000677b500, 0xfffffc0000fbce40,
  13 msync(0xfffffc0000fbce40, 0xfffffc00065f78c0, 0xfffffc0000000001, 0x0, 0xf
  14 syscall(0x1, 0x0, 0x4c1ef31517bdc, 0x12007dca4, 0xd9) ["../../../../src/ke
  15 _Xsyscall(0x8, 0x120080098, 0x14001ca20, 0x222000, 0x10000) ["../../../../

PROBLEM:  (HPAQC3A71) (Patch ID: OSF400-052)
********
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 active processes on the system will not help in identifying this problem.
The stack trace of some of the blocked processes on this system is the only
clue for recognizing this problem.  The analyst should pay special attention to 
the stack traces of all the NFS threads on the system.  The state of some of 
the NFS threads may be as follows if the system is experiencing this problem:

FOLLOWING IS THE STACK TRACE FOR AN NFS CLIENT THREAD:

>  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

FOLLOWING IS THE STACK TRACE FOR A SERVER THREAD WHICH WILL WAKE UP TO SERVICE 
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

FOLLOWING IS A STACK TRACE FOR A SERVER THREAD WHICH WAKES 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

PROBLEM:  (QAR 46136) 	(Patch ID: OSF400-019-1)
********
This patch fixes a problem with Object Broker 2.6-07.  Following are the two 
known symptoms:

a) When using Object Broker in the Implementation Manager window,
   double click on Localhost.  The following error message will be displayed: 

    Dynamic load of component 'OrbV12' for subsytem "Agent" failed.
    The specified executable for the method could not be dynamically loaded.

b) When using Object Broker in the System Administrator:Implementation
   Registry Window click on Authorization:

    Dynamic load of component 'Trusted' for subsystem 'Authentication' failed.
    The specified executable for the method could not be dynamically loaded.

PROBLEM:  (QAR 45495) 	(Patch ID: OSF400-019-1)
********
This patch fixes a problem in which, under certain circumstances, a call to the
mmap routine returns success without actually mapping the memory region. 
Subsequent access to the memory region will generate a segmentation fault. 

PROBLEM:		(Patch ID: OSF400-019-1)
********
FORTRAN application fails with "Cannot map data".  This happens if 
the application calls exec() recursively.

PROBLEM:		(Patch ID: OSF400-019-1)
********
FORTRAN application fails with "Could not open message catalog".

The attached FORTRAN test program fails to open message catalog
when executed by root (side effect of mlockall).

# ./testf
RA =  20.00
RA =  25.00
RA =  33.33
RA =  50.00
RA = 100.00
forrtl: info: Fortran error message number is 73.
forrtl: warning: Could not open message catalog: for_msg.cat.
forrtl: info: Check environment variable NLSPATH and protection of
/usr/lib/nls
/
msg/en_US.ISO8859-1/for_msg.cat.
forrtl: error (73): Message not found
RA =  Infin
forrtl: info: Fortran error message number is 299.
forrtl: warning: Could not open message catalog: for_msg.cat.
forrtl: info: Check environment variable NLSPATH and protection of
/usr/lib/nls
/
msg/en_US.ISO8859-1/for_msg.cat.
forrtl: info (299): Message not found
#

% ./testf
lockit: mlockall - : Not owner
process not locked in memory - exiting
RA =  20.00
RA =  25.00
RA =  33.33
RA =  50.00
RA = 100.00
forrtl: error (73): floating divide by zero
RA =  Infin
forrtl: info (299): 1 floating divide-by-zero traps

- -- test.f ---------------------------------------------------------------

      PROGRAM TESTF
C
      IMPLICIT NONE
C
      INTEGER*4  IA, JSTAT
      REAL*4     RA, RB
C
C     Lock the process in memory
C
      CALL LOCKIT ()
C
      IA = 5
      RB = 100.0

      DO WHILE ( JSTAT .EQ. 0 )
C
         RA = RB /  FLOAT ( IA )
         WRITE ( *, 1000 ) RA
1000     FORMAT ( ' RA = ', F6.2 )
         IA = IA - 1
C
         IF ( IA .LT. 0 ) JSTAT = 100
         CALL SLEEP_ ( 1 )
      ENDDO
C
      END

- -- lockit.c ---------------------------------------------------------------

#include 

void lockit ()
{
	if ( mlockall ( MCL_CURRENT | MCL_FUTURE ) == -1 ) {
		perror ( "lockit: mlockall - " );
		printf ( "process not locked in memory - exiting\n" );
	}
}

- -- Makefile ---------------------------------------------------------------

BINP = .
INCP = .
LIBP = .
OBJP = .

CCFLAGS = -c -g2 -std0 -0

F77FLAGS = -c -g2 -align dcommons -align records -assume nounderscore -fpe2

TESTF_OBJS  =   testf.o lockit.o

testf:      $(TESTF_OBJS)
	-f77 $(TESTF_OBJS) \
	-L/usr/ccs/lib -non_shared -lrt \
	-o testf

lockit.o: lockit.c
	cc -c -g2 -std1 -0 $<

testf.o: testf.f
	f77 $(F77FLAGS) -0 $<


PROBLEM:  (no problem report) 	(Patch ID: OSF400-050)
********
Errlog packets for 'no sense' and 'unit attention' events are being logged as
CAM_ERROR packets instead of the correct CAM_INFORMATIONAL packets.

PROBLEM:  (MGO102041) 		(Patch ID: OSF400-082)
********
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:  (QAR 48681) 		(Patch ID: OSF400-099)
********
This patch fixes a problem that occurs when Fortran programs or multithreaded 
applications that were built on a Digital UNIX V3.2C system are run on a 
Digital UNIX V4.0 or V4.0A system. The system displays the following error 
message:

   msg_copyout: map entry limit reached

The problem occurs because on a Digital UNIX V4.0 system, the libc_r.so shared 
library is a link to libc.so. The linker tries to map libc_r.so and fails 
because libc is already mapped.

PROBLEM:  (HPXQ43C4D, TKTR52185, QAR 46016) (Patch ID: OSF400-094)
********
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:  (MCPM7951F EVT101881) 	(Patch ID: OSF400-098)
********
This patch fixes a problem in which the system can panic with a "kernel memory 
fault"  message.  The trace looks like this:

panic (cpu 1): kernel memory fault
stack_trace[1]_begin:
0 stop_secondary_cpu
1 panic ("event_timeout: panic request")
2 event_timeout
3 xcpu_puts
4 printf
5 panic ("kernel memory fault")
6 trap
7 _XentMM
8 thread_getstatus
9 procfs_psinfo
10 procfs_ioct
11 vn_ioctl
12 procfs_ioctl_interface
13 ioctl_base
14 ioctl
15 syscall
16 _Xsyscall

This panic is likely to occur when the user is shutting down many processes.
Also, the SVE ps command or another application that makes use of the PIOCPSINFO
system call can provoke this panic.

PROBLEM:  (qar 47834) 		(Patch ID: OSF400-098)
********
The system can panic with "thread_block: simple lock owned "

0 boot
1 panic
2 thread_block
3 thread_preempt
4 boot
5 panic
6 thread_block
7 vm_wait
8 malloc_pg_alloc
9 malloc_mem_alloc
10 malloc
11 obj_entry_make
12 object_copyout
13 convert_thread_to_uport
14 nxm_idle
15 thread_bootstrap(0x0, 0x0, 0x0, 0x0, 0x0)

The panic is most likely to occur when the system is running in locmode 1, 3, 
or 4. The panic is provoked by multithreaded programs with high memory usage.

PROBLEM:  (QAR 48313  47550)		 (Patch ID: OSF400-098)
********
This patch provides improved debugger behavior.  The ladebug debugger can 
sometimes fail to attach to a threaded application.  

PROBLEM:  (CLDs HPAQ92E5E,TKTR90455/QAR 49011) (Patch ID: OSF400-100)
********
This patch prevents a "kernel memory fault" in the bread() routine while
performing sync operations.  The stack trace will look similar to the
following:

0 boot()      ["../../../../src/kernel/arch/alpha/machdep.c"]
1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c"]
2 trap()      ["../../../../src/kernel/arch/alpha/trap.c"]
3 _XentMM()   ["../../../../src/kernel/arch/alpha/locore.s"]
4 bread()     ["../../../../src/kernel/vfs/vfs_bio.c"]
5 iupdat()    ["../../../../src/kernel/ufs/ufs_inode.c"]
6 ufs_sync()  ["../../../../src/kernel/ufs/ufs_vfsops.c";
7 sync()      ["../../../../src/kernel/vfs/vfs_syscalls.c"]
8 syscall()   ["../../../../src/kernel/arch/alpha/syscall_trap.c"]
9 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"]

PROBLEM:  (CA6Q61192,UVO104419) (Patch ID: OSF400-110)
********
Processes can become hung during a system call to table().  Debuggers are 
particularly prone to this problem.

PROBLEM:  (HPAQ83C24)		 (Patch ID: OSF400-113)
********
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, ]

PROBLEM:  (QAR 45302) 		(Patch ID: OSF400-114)
********
DEVCONSOLE ioctl to the cam disk driver panics system when device is a tape.

Begin Trace for machine_slot[paniccpu].cpu_panic_thread:
0 boot
1 panic
2 trap
3 _XentMM
4 simple_lock_D
5 cdisk_ioctl
6 hal_getsysinfo
7 getsysinfo
8 syscall
9 _Xsyscall
End Trace for machine_slot[paniccpu].cpu_panic_thread:

PROBLEM:  (QAR 48762)		 (Patch ID: OSF400-114)
********
System can panic when the HSZ70 or HSZ40s is rebooted or restarted.

0 boot
1 panic
2 trap
3 _XentMM
4 xpt_action
5 ccmn_rem_ccb3
6 cdisk_complete
7 xpt_callback_thread

PROBLEM:  (QAR's 45847 48241)	 (Patch ID: OSF400-114)
********
If your system is running AIM 7 a 'kernel stack not valid' can occur.


PROBLEM:  (QAR 49556)		 (Patch ID: OSF400-121)
********
A "kernel memory fault" panic will be seen originating from the malloc()
routine.  The top stack entries will be as follows.  Many different kernel
routines may appear in the stack below malloc().

        panic("kernel memory fault")
        trap()
        _XentMM()
        malloc()

This problem is due to malloc() bucket corruption that occurs when there
are racing fdetach()/ file-on-file unmounts.  File-on-file mounting is most
often used with the fattach() library call and System V Environment pipes.

PROBLEM:  (QAR 49556)		 (Patch ID: OSF400-121)
********
Racing fdetach() or file-on-file unmounts can also cause threads to hang in
the kernel with the following stack trace.

        0 thread_block()
        1 vfs_busy()
        2 dounmount()
        3 unmount()
        4 syscall()
        5 _Xsyscall()


PROBLEM:  (QAR 49523)		 (Patch ID: OSF400-123)
********
The vmstat(1) command may display negative numbers when run with the '-P' 
option.  To reproduce the problem type:

                vmstat -P

Note: the problem may not exist on all platforms / configurations because it is
dependent on how the kernel build various internal data structures.

PROBLEM:  (QAR 49818)		 (Patch ID: OSF400-127)
********
System panics with messgae: "vm_map_swapout: negative resident count".  The
crash will most likely occur on a multiprocessor system during a heavy paging
load.  A typical stack trace for the panic will be as follows:

        panic("vm_map_swapout: negative resident count")
        vm_map_swapout()
        task_swapout()
        task_swapout_thread()


PROBLEM: (QAR 49316 QAR 49585) (Patch ID: OSF400-129)
********
This is a mandatory patch for the following systems:

  o Systems that use program debuggers such as Ladebug, dbx, TotalView, or gdb.

  o Systems that use the /proc file system in any other way (for example, the 
    System V Environment ps command).

  o Systems that experience panics in the /proc file system. The most common 
    panic string is "kernel memory fault"; a routine with the string "procfs" 
    will appear in the kernel stack trace.

PROBLEM:  (HPXQB6189/QAR 49949) (Patch ID: OSF400-141)
********
This patch fixes a network socket problem with select() missing state changes 
on clients from non-write to writable.
 
PROBLEM:  (MCPM94D74, QAR 49067) (Patch ID: OSF400-165)
********
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:  (QAR49798, QAR48200, QAR48879) (Patch ID: OSF400-161)
********
This patch fixes kernel asynchronous I/O (AIO) problems that occur on clustered
systems and systems using major database products on raw disk partitions.

The use of AIO over cluster distributed raw devices (DRD), and on raw disk
partitions, may enounter unexpected I/O errors and uninterruptible hangs when
a process exits. Most major database products use the AIO subsystem; any users
of database products are advised to install this AIO patch.

PROBLEM:  (QAR 44353 QAR 45425 QAR 45615 QAR 47956) (Patch ID: OSF400-163)
********
The system can panic when a ufs-mounted floppy is removed from the drive,
then replaced and accessed.

The panic string reports a memory fault.  The panic trace is as follows:

1 panic()
2 trap()
3 _XentMM()
4 vflushbuf()
5 ufs_sync()
6 dounmount()
7 unmount()
8 syscall()
9 _Xsyscall()

PROBLEM:  (HPXQB6BA4)			 (Patch ID: OSF400-180)
********
This patch fixes a problem where the user or system setting of UAC_NOPRINT
is ignored when an unaligned access trap is taken on a user address while
in kernel mode.  When this is a common event due to a customer application,
the console and "messages" file can be flooded with error messages of the
sort show below:

Oct 19 03:20:18 dekalb vmunix: Unaligned kernel access va=0x140018554 pc=0xfffff
c00004f5f24 ra=0xfffffc000025bc80 inst=0xffffffff
 
PROBLEM:  (QAR 36779)	 		(Patch ID: OSF400-185) 
********
This patch fixes a problem that occurs when running the NetWorker Version 4.2c
application.  The NetWorker application is unable to reset the atime (access
time) attribute on files being accessed. No errors or warnings are displayed.

Without this patch, NetWorker Version 4.2c will not perform well.

NetWorker application is unable to reset the atime on files being accessed.
Though this is undesirable bahavior, no errors or warnings are issued to
the user.

PROBLEM:  (CLD MCPMB7DEJ, QAR 50938)	 (Patch ID: OSF400-197)
********
This patch resolves a kernel memory fault.

A representative stack trace follows:

panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":753, ]
trap() ["../../../../src/kernel/arch/alpha/trap.c":1457, ]
_XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1392, ]
simple_lock_D() ["../../../../src/kernel/arch/alpha/lockprim.s":730, ]
u_anon_dupmcopy() ["../../../../src/kernel/vm/u_mape_anon.c":1603, ]
u_anon_dup() ["../../../../src/kernel/vm/u_mape_anon.c":1321, ]
u_map_copyin() ["../../../../src/kernel/vm/vm_umap.c":2085, ]
vm_map_copyin() ["../../../../src/kernel/vm/vm_map.c":1691, ]
procfs_psinfo() ["../../../../src/kernel/procfs/procfs_subrs.c":2425, ]
procfs_ioctl() ["../../../../src/kernel/procfs/procfs_ioctl.c":301, ]
vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1165, ]
procfs_ioctl_interface() ["../../../../src/kernel/procfs/procfs_ioctl.c":1716, ]
ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":426, ]
ioctl() ["../../../../src/kernel/bsd/sys_generic.c":374, ]

PROBLEM:  (QAR 51688)		 (Patch ID: OSF400-200)
********
The ObjectStore application from Object Design, Inc. fails with the following
error:

        "Fatal error Invalid argument(errno = 22)
         munmap failed: cl_mmap:"

PROBLEM:  (MCPM11KK6)		 (Patch ID: OSF400-202)  
*********
This patch provides the base support for the fuser utility. The utility will
be provided via another patch.

PROBLEM:  (USG-04536,51700) 	(Patch ID: OSF400-213)
********
Idle processes display poor interactive responsiveness. This patch prevents
idle processes from being outswapped too soon.

This patch allows tuneability for two level task swapping scheme that exists.
Currently all idle tasks are outswapped when the free list remains below
vm_page_free_target for 5 seconds.  This patch changes the logic so that you
can tune the threshold for swapping idle tasks.  Idle tasks will not be
outswapped until the free lists falls below vm_page_free_swap(default is 74
pages) and vm_page_free_swap is controlled by the vm-page-free-swap
sysconfigtab tunable parameter.

PROBLEM:  (CLD HPAQC07YV)        (Patch ID: OSF400-208)
********
This patch fixes a problem that occurs when the system panics with the following
error message:

               kernel memory fault

The following is a typical stack trace of the system panic:

 0 boot()                       [../../../../src/kernel/arch/alpha/machdep.c]
 1 panic("kernel memory fault") [../../../../src/kernel/bsd/subr_prf.c]
 2 trap()                       [../../../../src/kernel/arch/alpha/trap.c]
 3 _XentMM()                    [../../../../src/kernel/arch/alpha/locore.s]
 4 _svcauth_unix()              [../../../../src/kernel/rpc/svc_auth_unix.c]
 5 _authenticate()              [../../../../src/kernel/rpc/svc_auth.c]
 6 nfs_rpc_recv()               [../../../../src/kernel/rpc/svc.c]
 7 nfs_rpc_input()              [../../../../src/kernel/rpc/svc.c]
 8 nfs_input()                  [../../../../src/kernel/nfs/nfs_server.c]
 9 nfs_thread()                 [../../../../src/kernel/nfs/nfs_server.c]

PROBLEM:  (QAR 48162) (Patch ID: OSF400-056)
********
Several reentrant libc interfaces do not have proper prototypes in the
appropriate include files and produce error messages similar to the following
when compiled with c++:

cxx: Error: toto.cc, line 9: In this statement, "_Plocaltime_r" is not declared.

The interface given in the error message will always begin with _P and end
with _r.

PROBLEM:  (QAR 50697, MGO102332, FNO100130) (Patch ID: OSF400-198)
********
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:  (QAR 48951)		 (Patch ID: OSF400-212)
********
This patch fixes a problem that occurs in the vm subsystem. The system panics
with a "PANIC: VL_UNWIRE: PAGE IS NOT WIRED" message.  This panic occurs most
frequently on systems running database applications.

The problem occurs in the 'vm' subsystem when wiring and unwiring multiple user
buffers into kernel space. The system panics during the unwire of the second
user buffer when the 'vm' subsystem attribute "new-wire-method" is set to 1.
When the "new-wire-method" attribute is set to 0, the problem does not occur.

PROBLEM:  (QAR 50693, QAR 49421)	 (Patch ID: OSF400-216)
********
This patch corrects a problem with the exec() system function.  A shell script
that has "#! " as the first line of the script, invokes the
program but does not set the effective user id for the execution of the program.
For example:

$ cat myprog.c
 #include 
 main()
 {
         printf("geteuid() return  effective user ID of the calling
process=%d\n",geteuid());
 }

 $ cat test.sh
 #!./myprog
 echo "done with myprog"

 As root:
 # chmod 4755 myprog
 # chown root myprog


 As user ww
 $ ./myprog
 geteuid() return  effective user ID of the calling process=0

 $ ./test.sh
 geteuid() return  effective user ID of the calling process=7301

 In this case ./test.sh should return an euid of 0.

PROBLEM:  (EVT101963, QAR 52024) 	(Patch ID: OSF400-220)
********
The kernel panics with a "kernel memory fault".  Typical stack traces will
panic in either vm_zeroed_pg_alloc() or vm_pg_alloc() as shown below:

>  0 boot                 src/kernel/arch/alpha/machdep.c : 2361
   1 panic                src/kernel/bsd/subr_prf.c : 791
   2 trap                 src/kernel/arch/alpha/trap.c : 1457
   3 _XentMM              src/kernel/arch/alpha/locore.s : 1388
   4 vm_zeroed_pg_alloc   src/kernel/vm/vm_resident.c : 1289
   5 vm_anon_page_alloc   src/kernel/vm/vm_anonpage.c : 119
   6 anon_pagezero_alloc  src/kernel/vm/vm_anon.c : 448
   7 u_anon_faultpage     src/kernel/vm/u_mape_anon.c : 968
   8 u_anon_fault         src/kernel/vm/u_mape_anon.c : 861
   9 u_map_fault          src/kernel/vm/vm_umap.c : 501
  10 vm_fault             src/kernel/vm/vm_fault.c : 134
  11 trap                 src/kernel/arch/alpha/trap.c : 1467
  12 _XentMM              src/kernel/arch/alpha/locore.s : 1388

>  0 stop_secondary_cpu   src/kernel/arch/alpha/cpu.c : 414
   1 panic                src/kernel/bsd/subr_prf.c : 703
   2 event_timeout        src/kernel/arch/alpha/cpu.c : 811
   3 xcpu_puts            src/kernel/bsd/subr_prf.c : 844
   4 printf               src/kernel/bsd/subr_prf.c : 379
   5 panic                src/kernel/bsd/subr_prf.c : 753
   6 trap                 src/kernel/arch/alpha/trap.c : 1457
   7 _XentMM              src/kernel/arch/alpha/locore.s : 1388
   8 vm_pg_alloc          src/kernel/vm/vm_resident.c : 1162
   9 ubc_alloc            src/kernel/vfs/vfs_ubc.c : 3278
  10 ubc_page_alloc       src/kernel/vfs/vfs_ubc.c : 2240
  11 ubc_lookup           src/kernel/vfs/vfs_ubc.c : 1779
  12 page_lookup          src/kernel/msfs/bs/bs_buffer2.c : 1041
  13 seq_ahead            src/kernel/msfs/bs/bs_buffer2.c : 5258
  14 seq_ahead_cont       src/kernel/msfs/bs/bs_buffer2.c : 5013
  15 bs_refpg_int         src/kernel/msfs/bs/bs_buffer2.c : 1867
  16 bs_refpg             src/kernel/msfs/bs/bs_buffer2.c : 1596
  17 fs_read              src/kernel/msfs/fs/fs_read_write.c : 1549
  18 msfs_read            src/kernel/msfs/osf/msfs_vnops.c : 1883
  19 vn_read              src/kernel/vfs/vfs_vnops.c : 864
  20 rwuio                src/kernel/bsd/sys_generic.c : 1217
  21 read                 src/kernel/bsd/sys_generic.c : 1167
  22 syscall              src/kernel/arch/alpha/syscall_trap.c : 540
  23 _Xsyscall            src/kernel/arch/alpha/locore.s : 1173

PROBLEM:  (QAR 46424)		 (Patch ID: OSF400-221)
********
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 51161, QAR 51813)	 (Patch ID: OSF400-224)
********
This patch corrects problems encountered when using signals with multithreaded
programs. Specifcally, three problem may be encountered, all of them usually
resulting in an application hang:

1. Missed thread-specific signals. These are signal sent via the pthread_kill()
   function. Under extremely intensive use, a signal sent by pthread_kill()
   can be lost. This will usually manifest itself as an application hang,
   as an expected signal goes unreceived.

2. Inconsistent compute-bound hangs in the libpthreads.so.  Typically, a stack
   trace for such a hang would have the following mutex-related frames at the
   top of its stack:

        0 pthread_mutex_unblock()
        1 __pthread_mutex_unlock()
        2 (unknown)()
        3 free()
        .
        .
        .

   The frames below the mutex frames could be any routine that calls
   pthead_mutex_unlock().

3. Unexpected error return from system calls. When using process-level signals,
   certain system calls may return unexpectedly with an EINTR error without
   a signal actually having been delivered. Typcial victims of this problem
   are the sigwait() and read() functions.  Particularly in the case of read(),
   an application is likely to reissue the system call without noticing the
   error, resulting in a compute-bound loop.

PROBLEM:  (QAR 49821, QAR 49193)	 (Patch ID: OSF400-224)
********
A floating point operation initiated from a multithreaded program
can crash the kernel with a kernel memory fault.

PROBLEM:  (CLD EVT101664)		 (Patch ID: OSF400-232)
********
This patch fixes a performance problem that occurs with UFS file systems.
Data written to a file greater than 32 GB in length will be slower than
data written to the file when it is less than 32 GB in length.

PROBLEM: (GOZ100707, MCPM777CC, QAR 47889, QAR 48876) (Patch ID: OSF400-244)
********
This patch fixes a problem that occurs on AlphaServer 8200 systems running
a firmware revision prior to 3.9. The pset_info and psradm commands may
fail to correctly report that a CPU is shut down.

For example, a processor may fail to restart after a user tries to halt
the system by entering "Control-P Control-P" and then typing "continue"
on the console. This patch allows communication to the disabled processor
so that the correct status of the CPU is reported by the pset_info
and psradm commands.  However, psradm will still not be able to restart
the processor unless the firmware is up-to-date.

PROBLEM:  (MCPMC07S7)            (Patch ID: OSF400-201)
********
This patch fixes a kernel memory fault in ether_output packet filter, when
running tcpdump.

A representative stack trace of the 'tcpdump' process follows:

 read_io_port() src/kernel/io/dec/pci/pcia.c : 707
 fta_poll_cmd_req() src/kernel/io/dec/netif/if_fta.c : 3065
 ftaioctl() src/kernel/io/dec/netif/if_fta.c : 1831
 enetSetIfflags() src/kernel/net/pfilt.c : 3311
 decCopyAllCount() src/kernel/net/pfilt.c : 3367
 Pfilt_close() src/kernel/net/pfilt.c : 1376
 speclose() src/kernel/vfs/spec_vnops.c : 2486
 spec_close() src/kernel/vfs/spec_vnops.c : 2616
 ufsspec_close() src/kernel/ufs/ufs_vnops.c : 3632
 vn_close() src/kernel/vfs/vfs_vnops.c : 1280
 closef() src/kernel/bsd/kern_descrip.c : 1539
 close() src/kernel/bsd/kern_descrip.c : 1217

PROBLEM:  (QAR 45546)           (Patch ID: OSF400-021)
********
A TCP socket may "hang" and time out if IP options are in use.  IP options
are enabled via a setsockopt() system call with level == IPPROTO_IP and
option_name == IP_OPTIONS, and result in an IP header larger than 20 bytes.

This problem will manifest itself as an EPIPE (Broken pipe) error on the
sending TCP socket, with an ECONNRESET (Connection reset by peer) error on
the receiving socket.

The problem can be reproduced as follows:

1. create a TCP socket (Sa)
2. enable IP options on Sa (setsockopt(Sa, IPPROTO_IP, IP_OPTIONS, ...))
3. connect to another TCP socket (Sb)
4. issue a blocking write on Sa with enough data to overflow the
   socket send buffer and cause the write to block (50,000 bytes
   should be sufficient)
5. issue a blocking read on Sb to receive the data from Sa
6. wait (about 10 minutes)
7. the write on Sa will return successfully, the read on Sb will
   return ECONNRESET (Connection reset by peer)
8. issue another write on Sa, it will return EPIPE (Broken pipe)
   and a SIGPIPE signal will be generated

PROBLEM:  (HPAQ88145)    (Patch ID: OSF400-012 )
********
When real-time preemption is enabled (the rt-preempt-opt configuration parameter
is set to 1), the system may lose datagrams in some situations. This has been
seen using the ping command to solicit responses from a local broadcast
address.  Normally, a ping to the broadcast address will receive and display
responses from all nodes on the local network.  However, if another ping
process is started with a priority in the real-time preemption range, again
using the broadcast address, or there is other activity on the system, the
lower-priority process may cease receiving and displaying responses.  This
occurs even if the system is not very busy.

Although it has been observed with ping commands, it could occur with other
processes using datagrams for network communication.  This patch corrects
that problem.

PROBLEM:  (EVT101903)    (Patch ID: OSF400-096)
********
This patch fixes a kernel memory fault panic that occurs in ip_forward.  A
representative stack trace is:

0 boot
1 panic(s = "kernel memory fault")
2 trap
3 _XentMM
4 ip_forward
5 gw_forwardscreen
6 ip_forwardscreen
7 ipintr
8 netisr_thread

PROBLEM:  (FNO100128)   (Patch ID: OSF400-108)
********
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:  (MCPMA986D)    (Patch ID: OSF400-145)
********
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.  This patch is MANDATORY to install.

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:  (CA7Q10994)    (Patch ID: OSF400-181)
********
This patch fixes a problem that occurs on all systems that use networking
services.

The problem can be seen when a system attempts to ping a Digital UNIX Alpha
system connected to a token ring network and the ping uses a message size
that requires fragmentation. The Digital UNIX Alpha system receiving the ping
cannot respond. The token ring driver displays the following error message
to the console and resets the token ring adapter:

                List Error in transmit

PROBLEM:  (ZUO101015/QAR 49750)  (Patch ID: OSF400-182)
********
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:  (HPXQB4C4B)           (Patch ID: OSF400-186)
********
This patch fixes a problem in which the system can panic with "lock already
owned by thread". A typical stack trace shows:

        boot
        panic
        lock_fault
        lock_write
        solock
        socket_send
        ip_mforward
        ip_output
        rip_output
        raw_usrreq
        rip_usrreq
        sosend
        sendit
        sendto
        syscall

PROBLEM:  (CLD MCPMB04E3)	 (Patch ID: OSF400-233)
********
This patch resolves a TCP/IP network hang due to an IP Q ACK deadlock.
When this condition occurs the IP Q becomes full due to saturation.
Representative console messages indicating this condition are shown below:

   SIS00-00-root: IP q full, 315617 packets dropped in the last 5 mins.

PROBLEM:  (QAR 50363)		 (Patch ID: OSF400-235)
********
This patch fixes a problem with the fsck command. When fsck is run on a 
non-existent file system or on a currently mounted file system, it returns
a success status of zero. It should return a non-zero status.

An example where this problem is exhibited is shown here:

# fsck /dev/rz2a
/sbin/ufs_fsck /dev/rz2a
** /dev/rrz2a
Error: /dev/rrz2a or an overlapping partition is open.
FSCK CANNOT BE RUN ON AN ACTIVE FILESYSTEM.
# echo $?
0

ALSO:

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

PROBLEM:  		 (Patch ID: OSF400-247)
********
This network patch, which greatly improves Digital UNIX networking performance,
is targeted at high traffic Web server systems or any system which handles a
large number of TCP connection simultaneously, ie. more than several thousand
at one time.

The summary of improvements include:

Network kernel SMP locking improvements
        increased throughput due to reduced lock contention throughout
        the network stack on multiprocessor (SMP) systems

Socket code improvements
        improved performance in socket listen queue handling somaxconn,
        sominconn listen backlog support was increased from 32K to 64K
        maximum

TCP code improvements
        fully dynamic TCP hash table, can change size on the fly without
        having to reboot (tcbhashsize) support for TCP hash support for
        TCP hash table size larger than 1024 (tcbhashsize) improved TCP
        TCP timer algorithm eliminates a large percentage of the processing
        overhead needed to handle the tcp timer task more efficient port
        allocation code decreases outgoing connection overhead 
        (ipport_userreserved) randomized TCP initial sequence number
        IP reassembly fix for >12Gb memory systems and other minor TCP/IP 
        bug fixes

Kernel malloc improvements
        improved kernel malloc pool performance on SMP platforms

Kernel select improvements
        improved kernel select performance on SMP platforms when many
        open file descriptors are selected simultaneously

Additional kernel network tunable variables (using sysconfig):
        sobacklog_drops
        sobacklog_hiwat
        somaxconn_drops
        ipport_userreserved
        tcp_rexmit_interval_min
        tcp_cwnd_segments
        tcp_keepalive_default

PROBLEM:  (CLD HPXQ944E7, QAR 44282)     (Patch ID: OSF400-010)
********
This patch addresses compilation errors in the header file  for
C and C++ programs.

The  header file can cause two types of compilation errors under
the following conditions:

1. C++ programs can fail to compile when they reference the sa_handler field in
   struct sigaction. Attempting to build the following sample program shows how
   the C++ compiler reports the problem:

   $cat signal.C
   #include 
   void sighand(int sig) {}
   void foo()
   {
        struct sigaction sigact;
        sigact.sa_handler = (void(*)())sighand;
   }

   $cxx -c signal.C
   signal.C:6: error: In this statement, the referenced type \
     of the pointer value "(void ...)sighand" is \
     "function () returning void", which is not compatible \
     with "function (signed int) returning void".
   Compilation terminated with errors.

2. C programs fail to compile when they reference the SA_SIGINFO macro in the
    header file and explicitly define the _POSIX_C_SOURCE feature
   macro. Attempting to build the following sample program shows how the C
   compiler reports the problem:

   $ cat signal.c
   #define _POSIX_C_SOURCE 199309L
   #include 

   main()
   {
        printf("Value of SA_SIGINFO is %d\n", SA_SIGINFO);
   }

   $ cc -c signal.c
   cc: Error: signal.c, line 6: In this statement, "SA_SIGINFO" is not
     declared.
           printf("Value of SA_SIGINFO is %d\n", SA_SIGINFO);
   ----------------------------------------------^

PROBLEM:  (CLD: MCPM3028N)	 (Patch ID: OSF400-250)
********
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:  (ZPOB91873, HGOBB0092)	 (Patch ID: OSF400-237)
********
This patch provides additional details for hard errors logged after unsuccessful
I/O recovery attempts, and provides informational messages on the progress of
recovery events.

PROBLEM:  (QAR 51581)		 (Patch ID: OSF400-245)
********
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]

NOTE: This is a Mandatory Patch

PROBLEM:  (CLD UTO101199,HPAQ30ETE,QAR 51485,52365) (Patch ID: OSF400-262)
********
This patch corrects a problem with an NFS V3 mounted AdvFS file system where 
under heavy I/O load, data being written to a file may be lost.  Additionally,
because file stats are not being saved, the file modification time may revert
to a previous value.

PROBLEM:  (CLD FNO100138)	 (Patch ID: OSF400-266)
********
This patch fixes a 'recursion count overflow' panic that occurs on Digital UNIX.

Representative Stack trace:

panic ("lock_set_recursive: recursion count overflow") 
src/kernel/bsd/subr_prf.c : 791
 lock_fault()          src/kernel/kern/lock.c : 2003
 lock_set_recursive()  src/kernel/kern/lock.c : 1444
 makenfs3node()        src/kernel/nfs/nfs_subr.c : 1722
 nfs3_lookup()         src/kernel/nfs/nfs3_vnodeops.c : 2157
 namei()               src/kernel/vfs/vfs_lookup.c : 593
 stat1()               src/kernel/vfs/vfs_syscalls.c : 2801
 stat()                src/kernel/vfs/vfs_syscalls.c : 2769

PROBLEM:  (QAR 49023) (Patch ID: OSF400-130)
********
A "panic: lock_read: hierarchy violation in del_dealloc_stg" error occurs when
a socket lock is held by a UNIX domain while calling vrele().

PROBLEM:  (MGO102810/QAR 49847)		 (Patch ID: OSF400-271)
********
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 fault 
with sockets, mbufs and mblocks as well as hangs.  Applications using sockets in
a multithreaded, multicpu environment can experience a number of lock violations
with the socket structures.  This patch is MANDATORY to install on all systems.
It will be effective on Uniprocessor systems when lockmode debugging is invoked.

PROBLEM:  (EVT102039)		 (Patch ID: OSF400-287)
********
This patch fixes a problem that occurs when using real-time applications.
When writing large (sequential) files to a UFS file system, time constraints
associated with the application may be violated.

This problem can occur due to draining a large number of sequential pages
associated with the file. This draining occurs when the application requests
a new page AND the number of sequential pages exceeds a prescribed limit
(which is user-tuneable). The time limit constraint of the application may
be violated when the VM subsystem frees these excess pages.

PROBLEM:  (CLD HPXQ9722E)        (Patch ID: OSF400-240)
********
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: OSF400-289)
********
When a directory path on an NFS server is deleted, any process attempting
to access the missing path will cause NFS stale file handle messages to
be printed on the server's console. This patch will greatly reduce the
number of these messages.

PROBLEM:  (EVT102135,HPAQ50J6Z,SQO100374,MCPM50UKH,EVT102245,KAOB6KRMX,
********   QAR 52779,QAR 52525)   (Patch ID: OSF400-294)
This is a mandatory patch for the following systems and conditions:

   o Systems that use program debuggers such as TotalView, Ladebug, dbx,
     or gdb.

   o Systems that use the /proc file system in any other way (for example,
     the System V Environment ps command).

   o Systems that experience panics and hangs in the /proc file system.
     The most common panic string is "kernel memory fault"; also seen
     are "simple_lock time limit exceeded" panics. In all cases, a
     routine with the string "procfs_" will appear in the kernel stack
     trace.

   o Systems that panic when running multithreaded programs that call
     an exec() function

  Hangs usually involve either the debugger or debugged process or both
  entering the unkillable "U" state, as seen from the ps command.  The 
  hangs may be either quiescent or compute bound.  Other symptoms involve
  "" processes be left behind after a debugging session is terminated.

This patch is particularly important for debugging in a multithreaded 
enviroment on multiprocessor systems. The greater the concurrency of
the program being debugged, and the greater the number of processors,
the more likely problems are to occur.

PROBLEM:  (ISO100331)		 (Patch ID: OSF400-294)
********
A muli-threaded program that calls an exec() function can panic the system with
a kernel memory fault. A typical stack trace looks like this:

      0 boot()
      1 panic("kernel memory fault")
      2 trap()
      3 _XentMM()
      4 nxm_upcall()
      5 trap()
      6 _Xsyscall()

The critical feature of the stack trace is the presence of the nxm_upcall()
function prior to the kernel memory fault. The crash dump will show that
the thread is in process of processing an thread-block notification system
trap.

PROBLEM:  (CLD MCPM403TL, QAR 48048)  (Patch ID: OSF400-296)
********
This patch fixes a problem with the "ifconfig -a" command. At times, the command
will not display all of the network interfaces.

PROBLEM:  (QAR 49164)		 (Patch ID: OSF400-298)
********
This patch adds a mechanism to the poll() system call to allow it to be used as
a timer by passing in a null argument for the number of file descriptors.

Currently the poll() system call will return immediately when passed a null
argument for the number of file descriptors.

PROBLEM:  			(Patch ID: OSF400-351)
********
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:  (QAR 52525, QAR 46833)	 (Patch ID: OSF400-273)
********
This patch fixes a problem in which a system hang or core dump occurs when
one program inadvertently overwrites the contents of another program.

For example, a program, test1, is running and another program, test2, is
copied ("cp") onto test1, overwriting the contents of test1.  The result
is a system hang or a core dump.

An example of the problem follows:
# cp test2 test1art running ./test1, while on another:

The result is shown here:

# ./test1
.
.
.
Test2 looping -- 2819
Test2 looping -- 281a
Test2 looping -- 281b
Memory fault - core dumped
# ls -l core
-rw-------   1 root     system    360448 May 22 18:46 core

An example with the patch shows:
On one window start running ./test1, while on another:

# cp test2 test1
cp: test1: Text file busy
# cp test2 test1
cp: test1: Text file busy

The result is shown here:

# ./test1
.
.
.
Test2 looping -- 2819
Test2 looping -- 281a
Test2 looping -- 281b

# ls -l
total 50
-rwxr-xr-x   1 root     system     24576 May 20 20:05 test1
-rw-r--r--   1 root     system       121 May 20 20:03 test1.c
-rwxr-xr-x   1 root     system     24576 May 20 20:05 test2
-rw-r--r--   1 root     system       121 May 20 20:03 test2.c

PROBLEM:  (CLD HPAQ400UX)	  (Patch ID: OSF400-281)
********
On large memory, multicpu systems that have a high demand on virtual memory,
a simple lock fault can occur on the lru.

On large memory, multicpu systems, when free memory is exhausted, a simple
lock timeout can occur in vm routines.  The stack trace could look like one
of the following:

   5 panic(s = 0xfffffc0000583a08 = "simple_lock: time limit exceeded")
   6 simple_lock_fault()
   7 simple_lock_time_violation()
   8 vm_page_stealer()
   9 vm_pg_alloc()
  10 malloc_thread()

or

   5 panic(s = 0xfffffc0000583a08 = "simple_lock: time limit exceeded")
   6 simple_lock_fault()
   7 simple_lock_time_violation()
   8 vm_ops_reference_def()
   9 vm_map_clip_start()
  10 k_mem_entry_adjust()
  11 k_mem_lockop()
  12 k_map_wire()
  13 vm_map_pageable_orig()
  14 vm_map_pageable()
  15 thread_swapout()
  16 task_swapout()
  17 task_swapout_thread()

PROBLEM:  (SSRT0482U)			 (Patch ID: OSF400-283)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this potential
vulnerability.

PROBLEM:  (QAR 49683  QAR 47674)	 (Patch ID: OSF400-308)
********
This patch fixes a problem in which a system may crash if multiple bad blocks
on a SCSI device are encountered simultaneously.

The stack trace is as follows:

   0 boot()
   1 panic()
   2 trap()
   3 _XentMM()
   4 cdisk_bbr_done()
   5 cdisk_bbr_write()
   6 cdisk_bbr_reassign_done()
   7 cdisk_bbr_work()
   8 cdisk_bbr_comp()
   9 as_finish()
  10 xpt_callback_thread()

PROBLEM:  (QAR 49783) 			(Patch ID: OSF400-316)
********
This patch fixes several problems in the vm subsystem:

1) Processes using SystemV shared memory may hang.

   It is possible for processes using shared memory to hang if
   they are using SSM and the system is paging.  If ssm-threshold
   is set (as in a default configuration) and the shared memory size is
   greater 8 MB, then the system will select SSM instead of
   standard shared memory.  Processes would appear as uninterruptible (U)
   in a 'ps' list.

2) Skewed swap space allocation does not allocate
   evenly across all available areas.

3) A failure to obtain shared memory from the shmget() system call
   can cause machine check (660).

PROBLEM:  (QAR 51268)			 (Patch ID: OSF400-335)
********
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:  (HPXQB22D0, QAR 45498)	 (Patch ID: OSF400-342)
********
This patch fixes problems with the AdvFS filesystem commands "quotacheck -a"
and "vquotacheck -a".  These commands 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.

PROBLEM:  (UVO105527)		 (Patch ID: OSF400-346)
********
This patch fixes a problem that causes systems to panic with a "kernel
memory fault" from u_dev_lockop().  This has happened when a database
tried to memory map a file.

A typical stack trace follows:

5 panic("kernel memory fault") [src/kernel/bsd/subr_prf.c:753]
6 trap() [src/kernel/arch/alpha/trap.c:1512]
7 _XentMM() [src/kernel/arch/alpha/locore.s:1424]
8 u_dev_lockop() [src/kernel/vm/u_mape_dev.c:535]
9 u_dev_unmap() [src/kernel/vm/u_mape_dev.c:481]
10 u_map_delete() [src/kernel/vm/vm_umap.c:1321]
11 u_dev_create() [src/kernel/vm/u_mape_dev.c:202]
12 spec_mmap() [src/kernel/vfs/spec_vnops.c:2962]
13 smmap() [src/kernel/bsd/kern_mman.c:831]
14 syscall() [src/kernel/arch/alpha/syscall_trap.c:540]
15 _Xsyscall() [src/kernel/arch/alpha/locore.s:1209]

kernel_memory_fault_data:

    faulting virtual address:     0x001ffc003568af9c
    pc of faulting instruction:   0xfffffc000042dd4c
    ra contents at time of fault: 0xfffffc000042dcb8
    sp contents at time of fault: 0xffffffffa9243600

PROBLEM:  (QAR 47473)		 (Patch ID: OSF400-353)
********
This patch fixes the problem of audit_tool terminating prematurely the reading
of a complete large log file via zcat.  This usually occurs under gui control.

To reproduce error from the command line:

  /usr/sbin/audit_tool large_audit_file.Z
  The file must be big enough to enter the following so zcat can be
  suspended and restarted.  Be carefull of other zcat proc's.

  kill -17 $( echo $( ps -ef | grep zcat | grep -v grep | awk '{print $2}' ) )
  kill -19 $( echo $( ps -ef | grep zcat | grep -v grep | awk '{print $2}' ) )

  The repaired binary will continue after kill -19, CONT.

PROBLEM:  (EVT102135, HPAQ50J6Z, SQO100374, MCPM50UKH, EVT102245,
********   KAOB6KRMX, QAR 52779, QAR 52525) (Patch ID: OSF400-354) 
This is a mandatory patch for the following systems and conditions:

. Systems that use program debuggers such as TotalView, Ladebug, dbx,
  or gdb.

. Systems that use the /proc file system in any other way (for example,
  the System V Environment ps command).

. Systems that experience panics and hangs in the /proc file system.
  The most common panic string is "kernel memory fault"; also
  seen are "simple_lock time limit exceeded" panics. In all cases,
  a routine with the string "procfs_" will appear in the kernel stack
  trace.

  Hangs usually involve either the debugger or debugged process
  or both entering the unkillable "U" state, as seen from the ps
  command. The hangs may be either quiescent or compute bound.
  Other symptoms involve "" processes be left behind
  after a debugging session is terminated.

This patch is particularly important for debugging in a multithreaded
enviroment on multiprocessor systems. The greater the concurrency of 
the program being debugged, and the greater the number of processors,
the more likely problems are to occur.

PROBLEM:  (ISO100331)		 (Patch ID: OSF400-354)
********
A mulithreaded program that calls an exec() function can panic the system
with a kernel memory fault. A typical stack trace looks like this:

      0 boot()
      1 panic("kernel memory fault")
      2 trap()
      3 _XentMM()
      4 nxm_upcall()
      5 trap()
      6 _Xsyscall()

The critical feature of the stack trace is the presence of the nxm_upcall()
function prior to the kernel memory fault. The crash dump will show that the
thread is in process of processing an thread-block notification system trap.

PROBLEM:  (QAR 53003,MCPM40EQC,QAR 55150) (Patch ID: OSF400-356)
********
This is a mandatory patch for SMP systems with AdvFS file systems.  This patch
fixes a performance degration problem that may occur.  The problem occurs when
processors try to get internal AdvFS locks.

PROBLEM:  (ZPOB54022)		 (Patch ID: OSF400-357)
********
This patch fixes a problem that may occur after a system panics.  The system
may hang when trying to do a crash dump. The problem is due to the system
getting into a boot/panic loop. The following is an example of a typical stack
trace:

1 panic("event_timeout: panic request")
2 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005]
3 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244]
4 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":1220"]
5 drvr_flush()["/src/kernel/io/common/driver_support.c":2115"]
6 boot()["/src/kernel/arch/alpha/machdep.c":2525]
7 panic("event_timeout: panic request")
8 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005"]
9 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244]
10 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":2115]
11 drvr_flush()[/src/kernel/io/common/driver_support.c":2115"]
12 boot()["/src/kernel/arch/alpha/machdep.c":2525]
13 panic("event_timeout: panic request")
14 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005"]
15 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244]
16 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":2115]
17 drvr_flush()[/src/kernel/io/common/driver_support.c":2115"]
18 boot()["/src/kernel/arch/alpha/machdep.c":2525]

PROBLEM:  (QAR 48660,49822)		 (Patch ID: OSF400-360)
********
This is a mandatory patch for AlphaServer 2000 and AlphaServer 2100 SMP systems.
This patch fixes the following problems:

  o Internal lockups may cause performance degradation.
  o The system clock may lose time.

PROBLEM:  (FNO100126,UTO101198,MGO102729,UVO105463,MGO102993,TKTB91678,
********   QAR 43407) (Patch ID: OSF400-363)
This patch fixes a panic with the panic string "spec_badop called", that can
sometimes occur when an fpathconf system call is issued for a file in an
AdvFS filesystem.  The panic has following stack trace:

        panic (s = "spec_badop called")
        spec_badop
        fpathconf
        _Xsyscall

PROBLEM:  (STLB51417)		 (Patch ID: OSF400-367)
********
This patch improves the performance of applications that map tens or even
hundreds of thousands of files into the virtual address space.  This is 
accomplished by creating an index into the list of map entries or data
structures that describe the mapping of a file.  This index is used to
significantly shorten the time it takes to locate a file mapped within
a process address space.

There are 5 additional tunable parameters associated with this patch:

   o vm-map-index-enabled:  This parameter controls whether or not the entire
     indexing of the vm_map_entries.  If this is non-zero, the map entries
     will be indexed in all processes.  The default is 1(non-zero).

   o vm-map-index-count:  This is the size of the map entry index.  A larger
     index will create a faster lookup time but a potentially more costly
     rebalancing operation.  The default is 64, in other words you can expect
     the lookups to be at least 64 times faster than without this fix.

   o vm-map-index-rebalance:  This parameter controls how frequently the
     index gets rebalanced, if the difference between the longest map
     entry list and the shortest map entry list is greater than this
     parameter, the system rebalances the index.  Setting this parameter
     to a lower value will cause more rebalancing but will result in
     faster lookups.  Setting this parameter to a higher value will
     result in less rebalancing but will result in slower lookups.

   o vm-map-index-hiwat: This parameter controls when the index will
     will be created.  The default is 4.  When a process allocates
     vm-map-index-count * vm-map-index-hiwat(256 by default) the
     system allocates a map entry index and begins using it for
     faster lookups.

   o vm-map-index-lowat: This parameter controls when the index will
     will be deleted.  The default is 2.  Then a process deletes
     enough map entries so that there are fewer than vm-map-index-count *
     vm-map-index-lowat(128 by default) the system frees the map entry
     index and no longer uses it for faster lookups.

     The symptom of a customer needing this patch is:  Very high percentage 
     of system time and vm-mapentries set very high(greater than 2000) in the
     /etc/sysconfigtab file and running an application that mmap()'s thousand
     of files.

PROBLEM:  (TKTB52828, QAR 42761)   (Patch ID: OSF400-049)
********
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: OSF400-049)
********
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: OSF400-049)
********
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: OSF400-049)
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:  (7BXB84511)    (Patch ID: OSF400-104)
********
This patch fixes a problem that occurs with the Qlogic driver. The sim code
violates the CAM specifications in its use of flags that determine how to
handle synchronous data negotiations. As a result, command timeouts occur and
the printer device will not be detected during SCSI device configuration.

PROBLEM:  (HGOBB0043, HGOBB0597)         (Patch ID: OSF400-147)
********
Intermittently, the probe of an isp will fail during a boot.  This happens
maybe once in 20 system boots, so a workaround is to try the boot again.

A typical console listing looks like this when it fails:

        .
        .
        .

  Created FRU table configuration errorlog packet
  tiop0 at tlsb0 node 8
  tiop0: cpu interrupt mask being set as 1.
  pci0 at tiop0 slot 0
  isp0 at pci0 slot 0
  isp0: QLOGIC ISP1020 - Differential Mode
  cam_logger: CAM_ERROR packet
  cam_logger: bus 0
  isp_mailbox complete
  Timeout on mailbox command completion scheduling chip reinit
  cam_logger: CAM_ERROR packet
  cam_logger: bus 0
  isp_init
  Mailbox operations not functional for common init
  cam_logger: CAM_ERROR packet
  cam_logger: bus 0
  isp_probe
  Common init failure - Failing probe
  isp0: Not probed.
  isp in slot 0 not configured.
        .
        .
        .

PROBLEM:  (QAR 49540)            (Patch ID: OSF400-229)
********
Infrequently, under heavy disk I/O loads, user data can be written to the
wrong disk, resulting in data corruption.

PROBLEM:  (CLD HPXL85F5D)        (Patch ID: OSF400-229)
********
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:  (CLD HPXLB76FB)                (Patch ID: OSF400-229)
********
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: OSF400-229)
********
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: OSF400-229)
********
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:   (Patch ID: OSF400-369)
********
This patch provides general support for Version A11 KZPSA firmware.

PROBLEM:  (CLD EVT102273,SPR VNO100100,QAR 55615) (Patch ID: OSF400-373)
********
This patch fixes a problem in which a filesystem cannot be unmounted
The system displays a "Device busy" error message.

PROBLEM:  (MCSM80GC5)		 (Patch ID: OSF400-378)
********
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:  (CLD MCPMA7154,MCPMB1B9V,MCPM41683,MCPM70JFF,QAR 49696,52727,51574)
********  (Patch ID: OSF400-384)
This patch is MANDATORY.

This patch contains two vm fixes in both the UFS and NFS code that collectively
resolve a multitude of nfs and nfsd hangs.

PROBLEM:  (QAR 55112,55110,54413)	 (Patch ID: OSF400-394)
********
This patch is in reference to BLITZ TD# 2278.
This patch corrects a raw I/O data corruption problem that occurs when using
database applications. The problem is seen when the new-wire-method is active.

PROBLEM:  (CLD TKTR91730)	 (Patch ID: OSF400-397)
********
This patch fixes a problem in which the kernel can panic with a "kernel memory
fault" when attempting to push a signal state onto the stack of a thread in
a multithreaded program.

The stack trace will be:

        panic("kernel memory fault")
        trap()
        _XentMM()
        sendsig()
        psig()
        trap()
        _XentIF()

The faulting VA will contain an address simular to:

        0x000000011ffff???

And the instructions leading to the faulting pc will be:

        bsr     ra, ieee_get_fp_control(line 61)
        lda     a0, 16383(zero)
        stq     v0, 560(s5)

PROBLEM:  (MCPM905D0, QAR 56258)	 (Patch ID: OSF400-401)
********
The current kmem_debug capability has significant shortcomings due to the
fact that is an all-or-nothing entity:

  1.  It consists of several distinct debugging capabilities, all of which
      are imposed when kmem_debug is turned on.
  2.  It imposes all of the debugging capabilities on all of the 32 bucket
      sizes.

Therefore, when turned on, it imposes a huge performance degradation that make
its use impossible in many customer runtime environments.  The following
solutions have been put into place by this patch:

  1.  The capability of selection one or more kmem_debug options.
  2.  The capability of selecting one or more specific bucket sizes for
      debugging.
  3.  The addition of two popular debugging options that until now have only
      been available through the use of two "unofficial" patches:

      - The "kmem_debug_lite" patch has been incorporated as KMEM_DEBUG_LINKS
      - The "bear-trap" patch has been incorporated as KMEM_DEBUG_PROTECT

PROBLEM:  (CLD MCPM81FWD)		(Patch ID: OSF400-407)
********
This patch is MANDATORY.

This patch resolves an inode locking problem in the UFS iupdat() and itimes()
functions.

PROBLEM:  (QAR 54532,55448) 	(Patch ID: OSF400-388)
********
This patch fixes a problem in which a file-on-file system mount of either an
NFS or a /proc file system will panic the system.

PROBLEM:  (HPAQB18Q8 QAR 51560)	 (Patch ID: OSF400-391)
********
This patch fixes a file corruption problem that may occur with certain 
applications, for example Realtime applications, that use the plock()
system call or the mlock() and mlockall() library routines.

PROBLEM:  (HPAQ81XSG HPAQA0S4S)	 (Patch ID: OSF400-414)
********
When using msgsnd(), and sending a message with a size of zero to an invalid
queue, kernel memory is corrupted.  This will result in a panic with one of
the two following stack traces:

   panic("kernel memory fault")
   trap()
   _XentMM()
   free()
   msgsnd()
   syscall()
   _Xsyscall()

or

   panic("syscall: unexpected syscall arguments")
   syscall()
   _Xsyscall()

PROBLEM:  (QAR 54894,50056)		 (Patch ID: OSF400-418)
********

This patch fixes a UFS file system problem.  The system may panic with the
following error message:

     panic spec_badop called

The following is an example of a stack trace:

Begin Trace for machine_slot[paniccpu].cpu_panic_thread:
thread 0xfffffc0005a96b00 stopped at  [boot:2412 ,0xfffffc000045fdd0]
Source not available
>  0 boot(0x0, 0xfffffc0005a96b00, 0x2c0000002c, 0x31, 0xfffffc0000000001)
1 panic(s = 0xfffffc00006dcfb0 = "spec_badop called")
2 spec_badop(0x800, 0xfffffc0004b9afb8, 0xfffffc00006dcfb0,
0xfffffc0000000000, 0xfffffc000066ad20)
3 dfs_writeop(vp = 0xfffffc0004b9ae00, uio = 0xffffffff85f5b5d0,
ioflag = 0x0, cred = 0xfffffc0005998d00)
4 itrunc(oip = 0xfffffc0004b9ae00, length = 0x40000)
5 ufs_setattr(vp = 0xfffffc0004b9ae00, vap = 0xffffffff85f5b808,
cred = 0xfffffc0005998d00)
6 rfs_setattr(args = 0xfffffc0002501400, ns = 0xfffffc000586c780,
xprt = (nil), xpd = 0xfffffc0001013580)
7 rfs_dispatch(req = (nil), xprt = 0xfffffc0005514800)
8 nfs_rpc_recv(0x3ee219bc00000002, 0xfffffc0000000001, 0xfffffc0004fdda40,
0xfffffc0000000028, 0xfffffc0004fddd60)
9 nfs_rpc_input(0xfffffc0004fdda40, 0xfffffc0000000028, 0xfffffc0000000000,
0xfffffc0004fddbd0, 0xfffffc0000000000)
10 nfs_input(m = 0xfffffc0001094100)
11 nfs_thread()
End Trace for machine_slot[paniccpu].cpu_panic_thread:

PROBLEM:  (QAR 56163)		 (Patch ID: OSF400-420)
********
When debugging programs using Ladebug, a message having the following form
may be displayed: "Stack overflow: pid ".  This patch guarantees that
this will not occur when a process is being traced since this problem was 
interfering with the Ladebug watchpoint support.

PROBLEM:  (MCPM905D0, QAR 56258)	 (Patch ID: OSF400-421)
********
This patch fixes a potential memory leak problem that occurs when using the
KMEM_DEBUG_PROTECT option of the kmem_debug tuneable attribute.

PROBLEM:  (BRO101068/TKTR90901/QAR 55619) (Patch ID: OSF400-431)
********
This patch fixes two kernel memory faults in networking code with the following
stack traces:

  panic                         panic
  trap                          trap
  _XentMM                       _XentMM
  ip_output                     ip_output
  tcp_respond                   ip_forward
  tcp_timers                    gw_forwardscreen
  tcp_usrreq                    ip_forwardscreen
  tcp_slowtimo                  ipintr
  pfslowtimo                    netisr_thread
  pftimeout_thread

PROBLEM:  (IPMT 51611)		 (Patch ID: OSF400-441)
********
Any multithreaded application running on V4.0 through V4.0C of Digital UNIX
can lose floating point state across calls to fork().  In instances in which
this problem occurs, the floating point registers $f0-$f31 will all contain
zero in the child process.  To reproduce this problem, write a simple program
that calls pthread_create(), have the newly created thread cause floating point
state to change (e.g., just load the floating point registers with some seed
values or do some floating point operations), call fork() from this thread, and
look at the contents of the floating point registers (e.g., store them to an
array and print them).  Note that the problem manifests itself inconsistently
such that the loss of floating point register contents does not occur in every
instance that fork() is called from a multi-threaded program.

PROBLEM:  (MGO103109, QAR 55570)	 (Patch ID: OSF400-442)
********
This patch fixes a problem in which core() system call would try to dump from
a memory region that has no permission, cause an access violation in core()
and and the core file would be unusable.

An example of the problem.

        % file core
        core:   core dump, core file is incomplete

        % dbx program core
                .
                .
                .
        can't attach to loader: I/O error
        Exiting due to error during startup

PROBLEM:  (QAR 56794,56787)		 (Patch ID: OSF400-446)
********
This patch fixes a problem that causes the system to panic with the following
error message:

        u_anon_free: page busy

A sample stack trace is as follows:

panic(s = 0xfffffc000068e158 = "u_anon_free: page busy")
u_anon_free()
u_anon_unmap()
u_map_delete()
vm_map_exit()
exit()
rexit()
syscall()

This is a MANDATORY patch if you installed the following patch from each of the
the following BL8 v4.0 family patch kit:

v4.0  (BL8, kit #5) patch 408.00
v4.0a (BL8, kit #5) patch 370.00
v4.0b (BL8, kit #6) patch 269.00
v4.0c (BL8, kit #4) patch 228.00

PROBLEM:  (QAR 45510,52698)	 (Patch ID: OSF400-451)
********
This patch  fixes a problem with the ufs_fsck. ufs_fsck would mishandle certain
dir corruptions,recursively asking the user if they want to fix it.

For example:
Corrupt the filesystem using fsdb.
#fsdb -w /dev/rz3g
>4:dir=45
>:q
#
Note: 4:dir=45 will change the inode number of the fourth directory entry to 45.

Run ufs_fsck with -o option.

#ufs_fsck -o /dev/rz3g
** /dev/rrz3g
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
DIRECTORY CORRUPTED  I=2  OWNER=root MODE=40755
SIZE=512 MTIME=Dec 10 11:21 1997
DIR=

SALVAGE? [yn] n

Directory corruption not fixed, cannot not handle multiple errors.

DIRECTORY SCAN CONTINUE? [yn]

PROBLEM:  (QAR 51647,46058)	 (Patch ID: OSF400-452)
********
This patch fixes a problem that occurs on an AlphaServer 8200/8400 system.
The system may panic with the following error message:

        tb_shoot ack timeout

PROBLEM:  (CLD MCPM60HH7)	 (Patch ID: OSF400-456)
********
This patch fixes a problem of memory corruption.  A TCP control structure is
illegally accessed after it is released.  The corrupted memory buckets are the
256-byte size.

If the crash tool command "kmem -v" is run on the dump to verify the integrity
of the kernel buckets, the following message is printed indicating the memory
corruption:

  kmembuckets[4]: invalid checksum in bucket element

The symptom for this problem can take many forms.  In one case, threads hung in
wait_for_vxlock() with the following stack trace.

   0 thread_block()
   1 wait_for_vxlock() ["../../../../src/kernel/vfs/vfs_subr.c":802]
   2 vgetm() ["../../../../src/kernel/vfs/vfs_subr.c":2142]
   3 iget() ["../../../../src/kernel/ufs/ufs_inode.c":735]
   4 scandir() ["../../../../src/kernel/ufs/ufs_lookup.c"]
   5 ufs_lookup() ["../../../../src/kernel/ufs/ufs_lookup.c":386]
   6 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":593]
   7 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":2824]
   8 lstat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2808]
   9 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":555]
  10 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1209]

PROBLEM:  (QAR 52608)		 (Patch ID: OSF400-458)
********
This patch fixes a problem that occurs on AlphaServer 4100 systems.  If no 
devices are attached to the KZPSA disk controller, the system may panic when
attempting to perform I/O.

This patch provides a workaround to the problem by suppressing the sending of
the "verify-adapter-sanity" command until a device has been attached to the
disk controller.

PROBLEM:  (QAR 55760,52224)	 (Patch ID: OSF400-459)
********
This patch fixes an AdvFS problem in which the system may panic with the
following error message:

        thread_block: simple lock owned

PROBLEM:  (QAR 57707)		 (Patch ID: OSF400-461)
********
This patch fixes a problem in which the uswitch(2) system call does not work
when an application tries to reset the USW_NULLP option.  When this option is
set, /dev/zero is mapped for read-only references at address 0, allowing 
subsequent user NULL pointer read references to return a zero.  If the option
is reset (turned off), however, the mapping is not removed, and the task's VM
map's minimum virtual address is left at zero, rather than at VM_MIN_ADDRESS
(0x10000).

The problem may manifest itself in failures of the libaio library code.
The libaio libary code maps a page in low memory, which it expects to be,
at a minimum, VM_MIN_ADDRESS.  However, with the returns an aio mapping
address of 0.  The libaio code, however, considers an address of 0 as an
indication that the mapping has failed.

PROBLEM:  (QAR 46500,57146) 		(Patch ID: OSF400-466)
********
This patch fixes a problem with the nfsd daemon. Although the maximum number
of threads that nfsd can run is 128, the nfsd daemon will not start when the
sum of UDP threads and TCP threads equals 128.

PROBLEM:  (SSRT0521U)		 (Patch ID: OSF400-469)
********
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):

/sys/BINARY/arch_alpha.mod      	subset OSFHWBIN400
CHECKSUM: 59267    420 
/sys/BINARY/arch_alphapmap.mod  	subset OSFHWBIN400
CHECKSUM: 38077    183 
/sys/BINARY/cam.mod             	subset OSFHWBIN400
CHECKSUM: 01108    409 
/sys/BINARY/cam_disk.mod        	subset OSFHWBIN400
CHECKSUM: 20556    290 
/sys/BINARY/cam_isp1020.mod             subset OSFHWBIN400
CHECKSUM: 60379     81
/sys/BINARY/cam_pza.mod   	        subset OSFHWBIN400
CHECKSUM: 07372    176     
/sys/BINARY/cam_sim.mod 	        subset OSFHWBIN400
CHECKSUM: 23941    122   
/sys/BINARY/cam_simport.mod         	subset OSFHWBIN400
CHECKSUM: 58323    233 
/usr/sys/include/dirent.h               subset OSFBINCOM400
CHECKSUM: 13206      8     RCSfile: dirent.h      RCS: 4.2.18.2
/sys/BINARY/ether.mod           	subset OSFBIN400
CHECKSUM: 27574    133
/sys/BINARY/ffm_fs.mod          	subset OSFBIN400
CHECKSUM: 23164     24 
/sys/BINARY/generic.mod         	subset OSFBIN400
CHECKSUM: 02356      6 
/usr/sys/include/sys/msgbuf.h           subset OSFBINCOM410
CHECKSUM: 45519      4
/sbin/savecore          		subset OSFBASE400
CHECKSUM: 20173     56      RCSfile: savecore.c      RCS: 1.1.42.2
/usr/sbin/ifconfig             		subset OSFCLINET400
CHECKSUM: 55792     40 
/sbin/ifconfig          		subset OSFCLINET400
CHECKSUM: 43005     40 
/sys/BINARY/inet.mod           		subset OSFBIN400
CHECKSUM: 36500    284 
/usr/sys/BINARY/init_main.o             subset OSFBIN400
CHECKSUM: 20268     96     RCSfile: init_main.c      RCS: 4.3.231.2
/usr/bin/lastcomm               	subset OSFBASE400
CHECKSUM: 58807     24     RCSfile: lastcomm.c    RCS: 4.2.20.2
/sys/BINARY/loop.mod       	        subset OSFBIN400
CHECKSUM: 31935     14 
/sys/BINARY/nfs.mod    	                subset OSFBIN400
CHECKSUM: 05375    424 
/sys/BINARY/nfs_server.mod              subset OSFBIN400
CHECKSUM: 58475    281 
/sys/BINARY/notprocfs.mod               subset OSFBIN400
CHECKSUM: 35247     95 
/sys/BINARY/presto.mod               	subset OSFBIN400
CHECKSUM: 08261    150
/sys/BINARY/procfs.mod          	subset OSFBIN400
CHECKSUM: 08349    195 
/usr/sbin/quotacheck            	subset OSFBASE400
CHECKSUM: 11631     48      RCSfile: quotacheck.c     RCS: 4.2.29.2
/sbin/quotacheck                	subset OSFBASE400
CHECKSUM: 44617     48      RCSfile: quotacheck.c     RCS: 4.2.29.2
/sys/BINARY/re_xcr.mod          	subset OSFHWBIN400
CHECKSUM: 20357     66
/sys/BINARY/socket.mod          	subset OSFBIN400
CHECKSUM: 07079      3
/sys/BINARY/std_kern.mod        	subset OSFBIN400
CHECKSUM: 23443   1106 
/sys/BINARY/ufs.mod             	subset OSFBIN400
CHECKSUM: 05095    328 
/sbin/ufs_fsck          		subset OSFBASE400
CHECKSUM: 23395    472 
/usr/sbin/ufs_fsck              	subset OSFBASE400
CHECKSUM: 56658    104 
/sys/BINARY/uipc.mod  			subset OSFBIN400
CHECKSUM: 47329     21 
/sys/BINARY/vfs.mod			subset OSFBIN400
CHECKSUM: 35634    419 
/sys/BINARY/vm.mod 			subset OSFBIN400
CHECKSUM: 62822    431 
/usr/sbin/audit_tool            	subset OSFBASE400
CHECKSUM: 48214    168      RCSfile: audit_tool.c    RCS: 1.1.30.3
/usr/sys/include/io/cam/cam_disk.h      subset OSFBINCOM400
CHECKSUM: 26721     27	    RCSfile: cam_disk.h      RCS: 1.1.33.4
/usr/sys/include/sys/fcntl.h            subset OSFBINCOM400
CHECKSUM: 17491     10      RCSfile: fcntl.h         RCS: 4.2.46.3
/usr/sys/include/sys/fcntl1.h           subset OSFBINCOM400
CHECKSUM: 18748      3      RCSfile: fcntl1.h        RCS: 1.1.2.2
/usr/sys/include/ufs/fs_proto.h         subset OSFBINCOM400 
CHECKSUM: 39564     12      RCSfile: fs_proto.h      RCS: 1.1.30.2
/usr/sys/include/net/if.h              	subset OSFBINCOM400
CHECKSUM: 62537     43      RCSfile: if.h            RCS: 4.3.89.2
/usr/sys/include/ufs/inode.h 	        subset OSFBINCOM400 
CHECKSUM: 49905     13      RCSfile: inode.h         RCS: 4.3.39.2
/usr/sys/include/netinet/in_pcb.h
CHECKSUM: 57265     11 
/usr/sys/include/netinet/ip_var.h       subset OSFBINCOM400
CHECKSUM: 63443     10      RCSfile: ip_var.h        RCS: 4.4.39.2
/usr/sys/include/io/cam/qlogic/isp1020.h        subset OSFBINCOM400
CHECKSUM: 12659     43     RCSfile: isp1020.h   RCS: 1.1.60.3
/usr/sys/kern/lockinfo.c        	subset OSFBINCOM400
CHECKSUM: 13523     95	    RCSfile: lockinfo.c	 RCS: 1.1.330.3
/usr/sys/include/sys/malloc.h           subset OSFBINCOM400
CHECKSUM: 39296     18      RCSfile: malloc.h        RCS: 1.1.58.3
/usr/sys/include/arch/alpha/nxm.h       subset OSFBINCOM400
CHECKSUM: 17618      9      RCSfile: nxm.h        RCS: 1.1.16.3
/usr/sys/include/arch/alpha/pal.h       subset OSFBINCOM400
CHECKSUM: 10592      4 
/usr/sys/include/io/cam/pdrv.h  	subset OSFBINCOM400
CHECKSUM: 01928     38      RCSfile: pdrv.h          RCS: 1.1.32.2
/usr/sys/include/procfs/procfs.h        subset OSFBINCOM400
CHECKSUM: 12489     30      RCSfile: procfs.h        RCS: 1.1.32.4
/usr/sys/include/sys/procfs.h           subset OSFBINCOM400
CHECKSUM: 12489     30      RCSfile: procfs.h        RCS: 1.1.32.4
/usr/sys/include/procfs/procfs_l.h      subset OSFBINCOM400
CHECKSUM: 17730     10      RCSfile: procfs_l.h      RCS: 1.1.35.3
/usr/sys/include/net/proto_uipc.h       subset OSFBINCOM400
CHECKSUM: 10799     10      RCSfile: proto_uipc.h    RCS: 4.2.31.2
/usr/sys/include/sys/ptrace.h   	subset OSFBINCOM400
CHECKSUM: 64816      4      RCSfile: ptrace.h        RCS: 4.2.13.2
/usr/sys/include/sys/mman.h             subset OSFBINCOM400
CHECKSUM: 10260      8      RCSfile: mman.h       RCS: 4.2.26.2
/usr/sys/include/io/cam/sim.h           subset OSFBINCOM400
CHECKSUM: 22382     34      RCSfile: sim.h        RCS: 1.1.60.3
/usr/sys/include/netinet/tcp_var.h      subset OSFBINCOM400
CHECKSUM: 55999     14      RCSfile: tcp_var.h    RCS: 4.2.42.2
/usr/sys/include/netinet/tcp_timer.h    subset OSFBINCOM400
CHECKSUM: 16002      8      RCSfile: tcp_timer.h  RCS: 4.2.28.2
/usr/sys/include/netinet/proto_inet.h   subset OSFBINCOM400
CHECKSUM: 37937     10      RCSfile: proto_inet.h    RCS: 4.3.45.2
/usr/sys/include/sys/socket.h           subset OSFBINCOM400
CHECKSUM: 16777     17      RCSfile: socket.h        RCS: 4.2.35.2
/usr/sys/include/sys/socketvar.h        subset OSFBINCOM400
CHECKSUM: 13947     15      RCSfile: socketvar.h     RCS: 4.2.54.3
/usr/sys/include/sys/time.h 		subset OSFBINCOM400
CHECKSUM: 08607      9	    RCSfile: time.h	  	 RCS: 4.4.46.2 
/usr/sys/include/sys/user.h            	subset OSFBINCOM400
CHECKSUM: 20092     24      RCSfile: user.h          RCS: 4.3.76.2
/usr/sys/vfs/vfs_conf.c        		subset OSFBINCOM400
CHECKSUM: 49921     11	    RCSfile: vfs_conf.c      RCS: 4.2.52.3
/usr/sys/include/vm/vm_anon.h  		subset OSFBINCOM400
CHECKSUM: 45629     12      RCSfile: vm_anon.h       RCS: 1.1.47.3
/usr/sys/include/vm/vm_ubc.h            subset OSFBINCOM400
CHECKSUM: 61595      9      RCSfile: vm_ubc.h        RCS: 1.1.10.2
/usr/sys/include/sys/siginfo.h         	subset OSFBINCOM400
CHECKSUM: 65468     12      RCSfile: siginfo.h       RCS: 1.1.32.2
/usr/sys/include/sys/signal.h          	subset OSFBINCOM400
CHECKSUM: 14670     25      RCSfile: signal.h        RCS: 4.3.29.5
/usr/sys/include/standards.h            subset OSFBINCOM400
CHECKSUM: 33321      7  i   RCSfile: standards.h     RCS: 4.2.18.2
/usr/sys/include/sys/syscall.h          subset OSFBINCOM400
CHECKSUM: 38984      7
/usr/sys/include/io/cam/spo/simport.h           subset OSFBINCOM400
CHECKSUM: 14749     42     RCS: simport.h      Revision: 1.1.64.2
/usr/sys/procfs/procfs_subrs_stubs.c    subset OSFBINCOM400
CHECKSUM: 11961      3      RCSfile: procfs_subrs_stubs.c   RCS: 1.1.21.2
/usr/sys/BINARY/startup.o		subset OSFHWBIN400
CHECKSUM: 38779     95 
/usr/sys/BINARY/pmap_init.o		subset OSFBIN400
CHECKSUM: 05540     13 

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

SUPERSEDED PATCHES:	OSF400-091 (91.00),  OSF400-149 (149.00),
			OSF400-187 (201.00), OSF400-257 (273.00)

This patch corrects the following:

- Fixes a DEC C compiler problem that occurred when compiling a structure
  tag whose length exceeded 256 characters.

- Fixes a problem where the DEC C compiler would hang when compiling files
  containing many thousands of #line directives.

- The compiler generates 8 bytes of return code for functions that are defined 
  to return a 4-byte structure.

- A non-standard use of the __builtin_va_start compiler builtin was causing the
  compiler to crash.

- The compiler preprocessor was incorrectly issuing a warning diagnostic on the
  use of an octal constant.

- The compiler was not issuing a diagnostic for the use of the "long double" 
  datatype.

- This patch provides a new version of the DEC C compiler to fix QAR 49944.
  It fixes a problem that causes the compiler to generate incorrect code
  for switch statements whose expression is of type short or type char.

- Fixes three DEC C compiler problems.
  o  Fixes "Assertion failure:  Compiler internal error" compiler crash
     that occurs when compiling xemacs.
  o  Fixes "Invalid expression" error with valid token-pasting macro.
  o  Fixes "Fatal: memory access violation" compiler crash when the left
     side of a structure pointer operator (->) was not an lvalue. This
     case should produce a compiler error.

- Fixes the following problems:

     o  A compiler code generation problem that caused incorrect code for
        a left shift on a signed int when compiled in ANSI (-std or -std1)
        compilation modes.

     o  A problem where a structure return temporary is not preserved until
        later used in an enclosing funtion call; originally reported in the
  	comp.unix.osf.osf1 newsgroup.

     o  A "GEM ASSERTION, Compiler internal error" problem when compiling a
	complex conditional expression with -O0.
PROBLEM:  (CLD HPAQ76CC9)       (Patch ID: OSF400-091)
********
The cc compiler would hang when trying to compile a file containing many 
thousands of "#line" directives.  The compiler now compiles such files without 
hanging.

PROBLEM:  (QAR 45667)     	(Patch ID: OSF400-091)
********
This fixes a problem in which the compiler would return 8 bytes of code (4 
bytes of data plus 4 bytes of zeros), for routines which are defined to return 
4-byte structures.  The extra 4 bytes of zeros would corrupt the next variable 
on the stack.  This problem only occurs in applications which are built with 
DEC C++ V5.1 or earlier which make calls to such routines.

PROBLEM:  (QAR 46728)     (Patch ID: OSF400-091)
********
A non-standard use of the __builtin_va_start compiler builtin was causing the 
compiler to crash. 

PROBLEM: (QAR 47664)     (Patch ID: OSF400-091)
********
The compiler preprocessor was incorrectly issuing a warning diagnostic on the 
use of an octal constant.  

PROBLEM: (QAR 48122)     (Patch ID: OSF400-091)
********
The compiler was not issuing a diagnostic for the use of the "long double" 
datatype.  A warning is issued now.  
                                                                
PROBLEM:  (QAR 49944)	(Patch ID: OSF400-149)
********
This patch fixes a compiler problem where the DEC C compiler will generate
incorrect code for switch statements whose expression is of type short or
type char.  The problem occurs at all optimization levels.

This problem can be identified by running the following test program.

% cat a.c
      main()
       {
          short step = 1;
          do {
              switch (step++)
              {
              case 1 : printf("step = 1\n");
                       break;
              case 2 : printf("step = 2\n");
                       break;
              }
          }
          while (step <= 2);
      }

# The incorrect program output is:

% cc a.c ; a.out
step = 1

# The correct program output is:

% cc a.c ; a.out
step = 1
step = 2

The version of this fixed compiler is "DEC C V5.2-035".

PROBLEM:  (QAR 51448)	 (Patch ID: OSF400-187)
********
This patch fixes a crash in the DEC C compiler that occurs when compiling
a structure whose tag is longer than 256 characters. The problem occurs
only when compiling with debug symbols (-g). Below is an example of a
program that will cause this crash.

% cat test.c
#define a(x) x##x##x##x##x##x##x##x##x##x##x##x##x##x##x##x
struct a(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX);

% cc -g test.c
cc: Fatal: A memory access violation (bus error or segmentation fault) has
occurred.  Please submit a problem report.

PROBLEM:  	(Patch ID: OSF400-257)
********
Fixes "Assertion failure:  Compiler internal error" compiler crash that
occurred when compiling xemacs editor. The compiler would crash in certain
cases where one expression is an lvalue and the other an rvalue.  The 
workaround was to use "cc -oldc".

PROBLEM:       (Patch ID: OSF400-257)
********
Fixes "Invalid expression" compiler error with valid token-pasting macro
that occurred when compiling a public domain calc program.

PROBLEM:  (QAR 51915, QAR 47301) (Patch ID: OSF400-257)
********
Fixes "Fatal: memory access violation" compiler crash that occurred when
the left side of a structure pointer operator (->) was not an lvalue.
This case should produce a compilation error and not a compiler crash.

PROBLEM:  (OSF_QAR 57232/CLD HPAQB11) (Patch ID: OSF400-473)
********
A compiler code generation problem that caused incorrect code for a left shift
operation on a signed int in ANSI (-std/-std1) compilation modes.

PROBLEM:  (OSF_QAR 57443) 		(Patch ID: OSF400-473)
********
A structure-return temporary was not preserved until later used in an enclosing
function call. This was originally reported in the comp.unix.osf.osf1 newsgroup.

PROBLEM:  (DECC 2212) 			(Patch ID: OSF400-473)
********
A "GEM ASSERTION, Compiler internal error" problem when compiling a complex
conditional expression with -O0. This compiler problem did not occur at other
optimization levels.


FILE(s):

/usr/ccs/lib/cmplrs/cc/gemc_cc		subset OSFCMPLRS400
CHECKSUM: 45628   4096 

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

SUPERSEDED PATCHES:     OSF400-107 (107.00)

This patch corrects the following:

- Corrects a problem where processes such as wall, ntalkd, and comsat, when 
  associated with LAT devices, get stuck in the 'u' state (processes are hung)
  and cannot be cleared from the system.

- When printing using Digital UNIX LAT (V4.0 or later) to a printer connected
  to a PC running Pathworks, "I/O error" is displayed and nothing is printed.
PROBLEM:  (DMO100204, HPXQ974C9) (Patch ID: OSF400-107)
********
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()

PROBLEM:  (CLD GOZ100849)	 (Patch ID: OSF400-478)
********
This patch corrects the problem when using DIGITAL UNIX LAT to print to a 
printer connected to a PC running Pathworks (i.e. V5 or V6). The message
"I/O error" is displayed and nothing is printed.


FILE(s):

/sys/BINARY/lat.mod		subset OSFLAT400
CHECKSUM: 00997    253 

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

SUPERSEDED PATCHES:	OSF400-173 (173.00), OSF400-312 (321.00)

This patch corrects the following:

- The STREAMS tty line discipline not correctly processing type ahead
  characters. Also this patch fixes a delay in closing the STREAMS tty
  line discipline (typically seen on LAT connections).

- Fixes a wide variety of system panics and other problems caused by
  random memory corruption.

- Fixes a problem when printing to slow printers using Digital UNIX LAT.  
  The end of a large file fails to print and no error is reported.
PROBLEM:  ( QAR 50783 ) (Patch ID: OSF400-173)
********
Under some circumstances type ahead characters are not processed if a new line 
is not entered.  This is prevalently seen on screen tools which switch from 
canonical mode (line process mode) to raw mode.

PROBLEM:  (HPXQ514E3, QAR 46310)	 (Patch ID: OSF400-173)
********
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.  There are no 
error messages during the pause or stall.  You must examine the stack in order 
to determine if this patch applies to your condition.

PROBLEM:  (HPAQ41AAX STLQ23067 UVO105389 HPAQ116QT HPAQ50RP5 HPAQ400K4
********   ZPOBA0391 ZPOB60233 ) (Patch ID: OSF400-312)

This is a mandatory patch for all systems.

This patch fixes a wide variety of system panics and other problems caused
by random memory corruption.  The problem has typically shown up at 
universities, or Internet service providers hosting a lot of streams
activity.

The following symptoms have appeared in a variety of places throughout the
kernel.  Corrupted memory buckets are usually the 256-byte size, although
they could be any other size.

o Lock timeouts
o Kernel memory faults
o Unaligned kernel accesses

A typical stack trace is shown in the following example:

   3 panic("pmap_activate lock timeout")
   4 pmap_activate() [/src/kernel/arch/alpha/pmap.c":2710]
   5 thread_run() [src/kernel/kern/sched_prim.c":2295]

   6 idle_thread() [src/kernel/kern/sched_prim.c":3105]

In the stack trace above, the lock timed out because the lock structure
(at 0xfffffc0067fefe00) appeared to be locked when it really was not.
This was due to corruption of the structure by user data that had overflowed
from an mblk structure preceding this memory block.

To identify whether you have this memory corruption problem you have to
look beyond the stack trace.  The stack traces will vary considerably,
even on the same system, so the only way to identify this problem is to
find the corrupted memory bucket and look at the contents.

This is a typical 512-byte corrupted memory bucket.  The first 17 bytes of
data have been overwritten by data that belongs to another thread.  The
17 bytes have overflowed from an mblk structure preceding this memory bucket,
and have corrupted this memory bucket, overwriting pointers or locks or
whatever the first 3 quadwords used to contain.

(kdbx) 0xfffffc0067fefe00/32X
fffffc0067fefe00:  6918a5e6f04e78d3 cf7814aca7a32d6f
fffffc0067fefe10:  0000000000000043 0000000000000000
fffffc0067fefe20:  0000000000000000 fffffffffffffff8
fffffc0067fefe30:  0000000000000000 0000000000000001
fffffc0067fefe40:  000000000044a5cc 000000000000001a
        ...

If you display the block of memory immediately preceding the corrupted memory,
you may see an mblk structure there, if it is still around by the time the
crash dump takes place.

Sometimes the data that has corrupted the memory bucket is readable ASCII,
but more often it is unreadable binary data.

The number of bytes of data can be anywhere from 1 byte to several quadwords
of data.

PROBLEM:  (CLD MGO103100)	 (Patch ID: OSF400-479)
********
This patch fixes a problem when printing to slow printers using Digital UNIX
Digital UNIX LAT through a terminal server.  The end of a large
file fails to print and no error is reported.

**** Beginning of Release Note ****

Before the line discipline streams module (ldtty) closes, it sleeps for 30
seconds, waiting for the write queue to drain. In this situation, the sleep
time needs to be longer. There is a kernel global variable, ldtty_drain_tmo,
that specifies this time. This variable can now be patched using dbx.

# dbx -k /vmunix

(dbx) print ldtty_drain_tmo
30
(dbx) patch ldtty_drain_tmo=60
60
(dbx) quit
#

Some experimentation may be necessary to find the correct value for a specific
customer environment.

**** End of Release Note ****


FILE(s):

/sys/BINARY/ldtty.mod           subset OSFBIN400
CHECKSUM: 00836    132 

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

SUPERSEDED PATCHES:	OSF400-079 (79.00)
This patch fixes problems that occur with the dump and rdump commands. The 
commands will fail with the following error message:

     available blocks n < estimated blocks m

When a member of group "operator" logged into the console and (r)dump was
invoked with the -n flag, an extraneous file (/dev/:0) was created.
PROBLEM:  (HPXQ72698,STLQ80579,HPXQ89BA1) (Patch ID: OSF400-079)
********
The dump command fails when it is run through a pipe.  The program will fail 
with the following error message:

	available blocks n < estimated blocks m

PROBLEM: (HPXQ65A29)  		(Patch ID: OSF400-079)
********
When using the rdump command to dump to a regular file or to dump to a system 
whose uname command does not report OSF or ULTRIX, the command fails. The 
program will fail with the following error message:

     available blocks n < estimated blocks m

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

PROBLEM:  (QAR 55069)		 (Patch ID: OSF400-382)
********
This patch fixes a problem in which the dump command fails when the full
pathname of the output file is not given.

The following is an example of a failed dump command:

#dump -f dufile /mnt1
dump: Dumping from host shuka.xko.dec.com
dump: Date of this level 9 dump: Fri Sep 19 10:26:50 1997 GMT+0500
dump: Date of last level 0 dump: the start of the epoch
dump: Dumping /dev/rrz0h (/mnt1) to dufile
dump: Mapping (Pass I) [regular files]
dump: Mapping (Pass II) [directories]
dump: Estimate: 205666 tape blocks on disk
The available blocks(0),is less than the estimated blocks(205666)
Dump is being aborted
dump: SIGTERM received
dump: The ENTIRE dump is aborted


FILE(s):

/usr/sbin/dump					subset OSFHWBASE400
CHECKSUM: 26764     80     RCSfile: dumpmain.c      RCS: 4.2.43.2
			   RCSfile: dumptape.c	    RCS: 4.2.46.2
/sbin/dump					subset OSFHWBASE400
CHECKSUM: 22951     80 
/usr/lib/nls/msg/en_US.ISO8859-1/dump.cat	subset OSFHWBASE400
CHECKSUM: 50223     10 
/usr/sbin/rdump					subset OSFCLINET400
CHECKSUM: 39606     80     

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

SUPERSEDED PATCHES:     OSF400-151 (151.00), OSF400-171 (171.00),
                        OSF400-196 (209.00), OSF400-264 (280.00),
                        OSF400-385 (397.00)

This patch corrects the following:

- Fix for a mutex lock problem in TLI. The problem causes multithreaded TLI
  applications to block forever.

- Fixes the problem of t_optmgmt() T_NEGOTIATE calls returning T_SUCCESS,
  but not actually negotiating the socket options. This behavior is a 
  UNIX95 specification standard compliance bug.

- Fix for a problem that manifests itself by the system hanging or becoming
  inoperable when a number of XTI connections reaches 500.

- Resolves a hang in the xticlose() routine and a kernel memory fault in the
  xti_discon_req() routine.

- Corrects a problem with the xti/streams interface module which could result
  in a kernel memory fault panic during use by xti application programs.

- Fixes a problem with the implementation of the TPI interface.  This problem
  occurs if you are using Digital's XTI libxti library with a third-party 
  (non-Digital) STREAMS driver.
PROBLEM:  ( QARs 49922 and 48633  ) (Patch ID: OSF400-151)
********
Multi-threaded TLI application blocks forever. dbx session will show that it 
blocks in the t_look() library routine. For this to happen, it is necessary 
that t_look() is called twice. Because it is called internally by a number of 
other TLI library routines, application can hang under all sorts of scenarios.

PROBLEM:  (QAR 49764)            (Patch ID: OSF400-171)
********
When attempting to establish a number of XTI connections, > 500, the client
system hangs and becomes inoperable. This fix  will allow an application to
issue a large number of connect requests (up to 3K connections).

PROBLEM:  (QAR 51684)            (Patch ID: OSF400-196)
********
This patch fixes the problem of t_optmgmt() T_NEGOTIATE calls returning
T_SUCCESS, but not actually negotiating the options.

PROBLEM:  (CLD MCPM209Q3, QAR 51394) (Patch ID: OSF400-264)
********
This patch fixes a hang in the xticlose() routine.  The user would see a
stack trace similar to the following.

thread_block() ["../../../../src/kernel/kern/sched_prim.c":2036 ]
mpsleep() ["../../../../src/kernel/bsd/kern_synch.c":563 ]
streams_mpsleep() ["../../../../src/kernel/streams/str_env.c":574 ]
xticlose() ["../../../../src/kernel/streamsm/xtiso.c":965 ]
close_wrapper() ["../../../../src/kernel/streams/str_subr.c":317 ]
csq_protect() ["../../../../src/kernel/streams/str_synch.c":770 ]
osr_pop_subr() ["../../../../src/kernel/streams/str_osr.c":1686 ]
osr_close_subr() ["../../../../src/kernel/streams/str_scalls.c":1345 ]
pse_close() ["../../../../src/kernel/streams/str_scalls.c":1196 ]
speclose() ["../../../../src/kernel/vfs/spec_vnops.c":2462 ]
spec_close() ["../../../../src/kernel/vfs/spec_vnops.c":2616 ]
vn_close() ["../../../../src/kernel/vfs/vfs_vnops.c":1292, ]
closef() ["../../../../src/kernel/bsd/kern_descrip.c":1539 ]
exit() ["../../../../src/kernel/bsd/kern_exit.c":936 ]
rexit() ["../../../../src/kernel/bsd/kern_exit.c":755 ]
syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":555 ]
_Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1177 ]

PROBLEM: (HPAQC12ZB, UVO105080)  (Patch ID: OSF400-264)
********
This patch fixes a kernel memory fault panic in the xti_discon_req() routine.
A representitive stack trace is:

boot() ["../../../../src/kernel/arch/alpha/machdep.c":2484 ]
panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":791 ]
trap() ["../../../../src/kernel/arch/alpha/trap.c":1520 ]
_XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1424 ]
xti_discon_req() ["../../../../src/kernel/streamsm/xtiso.c":4449 ]
xti_output() ["../../../../src/kernel/streamsm/xtiso.c":1729 ]
xtiwsrv() ["../../../../src/kernel/streamsm/xtiso.c":1639 ]
sq_wrapper() ["../../../../src/kernel/streams/str_runq.c":137 ]
csq_lateral() ["../../../../src/kernel/streams/str_synch.c":992 ]
runq_run() ["../../../../src/kernel/streams/str_runq.c":108 ]
netisr_thread() ["../../../../src/kernel/net/netisr.c":841 ]

PROBLEM:  (HPAQ9145N, HPAQ70F4R, and HPAQ90B3J) (Patch ID: OSF400-385)
********
Under some conditions, an xti application which attempts to disconnect an
endpoint will precipitate a kernel memory fault panic form the xti_discon_req
routine.

PROBLEM:  (QAR  54884)		 (Patch ID: OSF400-405)
********
This patch fixes a problem with the implementation of the TPI interface. This
problem occurs if you are using Digital's XTI libxti library with at third-
party (non-Digital) STREAMS driver.


FILE(s):

/usr/shlib/libtli.so		subset OSFBASE400
CHECKSUM: 01346     80 
/usr/shlib/libxnet.so		subset OSFBASE400
CHECKSUM: 06209     64 
/usr/shlib/libxti.so		subset OSFBASE400
CHECKSUM: 06209     64 
/sys/BINARY/xtiso.mod           subset OSFBIN400
CHECKSUM: 32958    161 

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

This patch fixes various problems with the find command.
PROBLEM: (QAR 26710) 		(Patch ID: OSF400-379)
********
The find -follow command does not detect previously visited directories 
properly.  The system displays error messages similar to the following
and gets caught in an infinite loop.

For example:

 $ find /tmp/level1 -follow -print /tmp/level1
 find: cannot open symbolic link < /tmp/level1/abc:: No such file or directory
 find: cannot open symbolic link < /tmp/level1/pass:: Not a directory
 /tmp/level1/level2
 find: cannot open symbolic link < /tmp/level1/level2/pcap:: Not a directory
 find: cannot open symbolic link < /tmp/level1/level2/newname::
 No such file or directory
    /tmp/level1/level2/magic
    /tmp/level1/level2/magic.old
    /tmp/level1/level2/level3
    /tmp/level1/level2/level4
    .
    (gets into an infinite loop)
    .

Note, level3 is a subdirectory of level2 and is linked to level1.

PROBLEM: (QAR 47329)	   (Patch ID: OSF400-379)
********
The find -follow command does not correctly handle symbolic links.  This can 
have the following symptoms:

  find /tmp/two -follow -print
  /tmp/two
  /tmp/two/second

  find: cannot open symbolic link < /tmp/two/second/pcap:: Not a directory
  /tmp/two/second/secondx
  /tmp/two/second/secondx/profile
  /tmp/two/second/secondx/protocols
  find: bad status-- /tmp/two/second/magic
  find: bad status-- /tmp/two/second/third
  find: bad status-- /tmp/two/secondx


PROBLEM: (QAR 52307)	    (Patch ID: OSF400-379)
********
The find -follow command goes into a loop when a symbolic link refers to an
object in the parent of the search tree.  For example:

  >cd /tmp
  >mkdir junk
  >cd junk
  >ln -s /tmp/junk child.link
  >ls
  child.link
  >find . -follow -print
  .
  ./child.link
  ./child.link/child.link
  ./child.link/child.link/child.link
  ./child.link/child.link/child.link/child.link
  ./child.link/child.link/child.link/child.link/child.link
  ./child.link/child.link/child.link/child.link/child.link/child.link

./child.link/child.link/child.link/child.link/child.link/child.link/child.

PROBLEM: (QAR 19076)		   (Patch ID: OSF400-379)
********
When cpio archives are created with the find command (find . -cpio ...), 'find'
does not allow for extended attributes from the property list mechanism.

PROBLEM: (QAR 44191)		   (Patch ID: OSF400-379)
********
The find command produces incorrect output when the -prune and -depth primaries
are used simultaneously.

PROBLEM: (QAR 47432)		   (Patch ID: OSF400-379)
********
The find command does not behave according to specification.  A problem occurs
when the search is restricted to a single file system.

PROBLEM: (QAR 49857)		   (Patch ID: OSF400-379)
********
The find . -fstype command does not report an error when given an unknown
file system.  For example:

  #prior to fix:

  $ find . -fstype banana -print
  $

  #After fix:

  $ ./find . -fstype banana -print
  find: Unknown file system type banana.

PROBLEM: (QAR 47223) 		   (Patch ID: OSF400-379)
********
The find command exits when it encounters a file system different from the
file system on which it started.


FILE(s):

/usr/bin/find           subset OSFBASE400
CHECKSUM: 40861     48    RCSfile: find.c      RCS: 4.3.50.2
/sbin/find              subset OSFBASE400
CHECKSUM: 19617     48     RCSfile: find.c      RCS: 4.3.50.2
/usr/lib/nls/msg/en_US.ISO8859-1/find.cat
CHECKSUM: 48082      2 

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

SUPERSEDED PATCHES:	OSF400-144 (144.00)

This patch corrects the following:

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

- A potential security vulnerability has been discovered, where under certain
  circumstances, system integrity may be compromised.  This may be in the form
  of improper file or privilege management. Digital has corrected this potential
  vulnerability.
PROBLEM:  (MCPMC0L3C/QAR 50410)	 (Patch ID: OSF400-144)
********
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.

PROBLEM:  (CLD SSRT0505U)	 (Patch ID: OSF400-396)
********
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/bin/ftp		            subset OSFCLINET400
CHECKSUM: 21243    120     RCSfile: ftp.c      RCS: 4.2.35.2

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

This patch provides the requried run-time support for images created by the
Digital C++ V6.0 and above compiler.  Contact the Digital C++ compiler group
(cxx@lego.zko.dec.com) for details.
PROBLEM: 		 (Patch ID: OSF400-487)
********
This patch provides the required run-time support for images created by the
Digital C++ V6.0 and above compiler.

When using th eDigital C++ V6.0 compiler, customers can use the un-documented
compiler switch:

     -use_system_libcxx

which will cause the compiler to use the system libcxx.so file when linking.
This switch should only be used if the resulting images are to be executed
either on other systems which have had the libcxx.so patch installed, or on
Digtial UNIX V4.0D and above systems.


FILE(s):

/usr/shlib/libcxx.so            subset OSFBASE400
CHECKSUM: 03297    280

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

A potential security vulnerability has been discovered in 'libDtSvc', where
under certain circumstances users may gain unauthorized access.  Digital has
corrected this potential vulnerability.
PROBLEM:  (CLD SSRT0498U) 	(Patch ID: OSF400CDE-013)
********
A potential security vulnerability has been discovered in 'libDtSvc', where
under certain circumstances users may gain unauthorized access.  Digital has
corrected this potential vulnerability.


FILE(s):

/usr/dt/lib/libDtSvc.a          subset OSFCDEDEV400
CHECKSUM: 62369    793 

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

When running the Common Desktop Environment (CDE), a dtterm window in which
vi is being used can hang when doing a cut and paste operation from a second
window.
PROBLEM:  (EVT102382)           (Patch ID: OSF400CDE-012)
********
When running the Common Desktop Environment (CDE), a dtterm window in which vi
is being used can hang when doing a cut and paste operation from a second
window.

FILE(s):

/usr/dt/lib/libDtTerm.so                subset OSFCDEMIN400
CHECKSUM: 00946    472

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

SUPERSEDED PATCHES:     OSF400CDE-008 (225.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.
PROBLEM:  (CLD SSRT0431U) 	(Patch ID: OSF400CDE-008)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this potential
vulnerability.

PROBLEM:  (QAR 57627)		 (Patch ID: OSF400CDE-015)
********
This fix replaces a previous fix for /usr/sbin/dop that contained an error
which prevented certain applications found in /etc/doprc from being started.
The applications affected were those which have one or more arguments to the
command in the path portion of the doprc entry.  An example entry is:

nissetup {
    {path   { /usr/share/sysman/bin/runterm /usr/sbin/nissetup }}
}

The affected /etc/doprc entries are: nissetup, latsetup and btcreate.
The dop error causes command startup to fail, with an exit code ($? variable)
of 2.


FILE(s):

/usr/dt/bin/dtappgather         	 subset OSFCDEDT400
CHECKSUM: 55800     56 
/usr/dt/bin/dtlogin             	 subset OSFCDEDT400
CHECKSUM: 49477    176
/usr/dt/config/Xsession.d/0030.dttmpdir  subset OSFCDEDT400
CHECKSUM: 04888      3

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

SUPERSEDED PATCHES:     OSF400CDE-003 (177.00), OSF400CDE-004 (178.00),

This patch corrects the following:

- Users appear to be logged in when they are not because CDE dtterm sometimes
  doesn't reset the utmp entry on exit.

- Prevents the escape sequence that sets DECterm window titles from hanging
  dtterm windows.

- When running the Common Desktop Environment (CDE), a dtterm window in which
  vi is being used can hang when doing a cut and paste operation from a second
  window.

- Provides the ability to let dtterm display all the characters in the PC
  codeset IBM-850.
PROBLEM:  (CLD STLQ73742) 	(Patch ID: OSF400CDE-003)
********
When the escape sequence that sets the window title for DECterm is sent to the 
default terminal emulator, dtterm, the dtterm window hangs because the escape 
sequence isn't properly parsed.  This patch prevents the window from hanging. 
The escape sequence that hangs the window is:
   echo "\033]21;\033\\"

PROBLEM:  (CLD ISO100270) 	(Patch ID: OSF400CDE-004)
********
Users appear to be logged in when they are not because CDE dtterm sometimes 
doesn't reset the utmp entry on exit.

PROBLEM:  (CLD DJOBB0755, QAR 54755) (Patch ID: OSF400CDE-014)
********
This patch provides the ability to let dtterm display all the characters in the
PC codeset IBM-850.  Currently, dtterm will not display the characters 0x80-0x9f
in that codeset.

This patch is intended for customers who run dtterm on DIGITAL UNIX systems and
display it against PC X servers.


FILE(s):

/usr/dt/bin/dtterm		    subset OSFCDEDT400
CHECKSUM: 47258    408     RCSfile: TermParseTable.c     RCS: 2.1.8.2
/usr/dt/config/Xconfig.con
CHECKSUM: 50931      6 
/usr/dt/config/Xconfig.nc           subset OSFCDEDT400
CHECKSUM: 11639      6 
/usr/dt/lib/libDtTerm.a             subset OSFCDEDEV400
CHECKSUM: 25738    472 

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

SUPERSEDED PATCHES:	OSF400DX-006 (216.00), OSF400DX-009 (272.00),
			OSF400DX-011 (322.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.

- Fixes a problem that occurs on Digital UNIX systems running Version 4.0 or
  higher with C2 security enabled and Patch OSF400DX-006 installed.  The dop
  command rejects all password attempts when run by non-root users.

- Fixes a problem that occurs on systems that have installed Patch OSF400DX-006.
  If more than one argument is given on the dop command line, dop passes all
  arguments as a single argument to the command.

- The startup of nissetup, latsetup and btcreate /etc/doprc entries via the
  dop command fails with exit code of 2.
PROBLEM: (QAR 50057,50155,50353, SSRT0435U)  (Patch ID: OSF400DX-006)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this potential
vulnerability.

PROBLEM:  (QAR 52285, SSRT0435U)	 (Patch ID: OSF400DX-009)
********
This patch fixes a problem that occurs on Digital UNIX systems running Version
4.0 or higher with C2 security enabled and Patch OSF400DX-006 installed.  The 
dop command rejects all password attempts when run by non-root users.

Patch OSF400DX-006 fixed a security violation that occurred in the dop command.
For systems that are enabled for C2 security, this patch introduced a problem
in which dop rejects all password attempts when run by non-root users.  While
not a security violation, it requires the user to be root before using the
system administration applications (for example, Network Configuraton or Disk
Configuration).

PROBLEM:  (QAR 53612)		 (Patch ID: OSF400DX-011)
********
This patch fixes a problem that occurs on systems that have installed Patch
OSF400DX-006. If more than one argument is given on the dop command line,
dop passes all arguments as a single argument to the command.

The following example passes the -c flag and the argument enclosed in quotation
marks ("") as a single argument to the dxdw command.

$ dop dxdw -c "/usr/bin/tail -f /var/adm/messages"

PROBLEM:  (QAR 57627)            (Patch ID: OSF400DX-015)
********
The startup of nissetup, latsetup and btcreate /etc/doprc entries via the dop
command fails with exit code of 2.


FILE(s):

/usr/share/sysman/bin/badpasswd         subset OSFSYSMAN400
CHECKSUM: 15249      4     RCSfile: badpasswd  RCS: 1.1.2.7
/usr/sbin/dop           		subset OSFSYSMAN400
CHECKSUM: 51640     40     RCSfile: dop.c      RCS: 1.1.7.4
/usr/share/sysman/bin/doperror          subset OSFSYSMAN400
CHECKSUM: 63161      5
/usr/share/sysman/bin/getpasswd         subset OSFSYSMAN400
CHECKSUM: 12699      7     RCSfile: getpasswd  RCS: 1.1.6.2
/usr/share/sysman/bin/getpriv           subset OSFSYSMAN400
CHECKSUM: 12649      8     RCSfile: getpriv    RCS: 1.1.2.4

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

SUPERSEDED PATCHES:	OSF400DX-005 (183.00), OSF400DX-008 (244.00)
			OSF400DX-010 (289.00)

This patch corrects the following:

- When creating a new user account with a home directory of root, the
  permissions on the root directory are changed to 700, rendering the
  root file system inaccessible to non-root users.  Patch Kit-0001
  causes a problem with the System V Environment (SVE)
  /usr/opt/svr4/usr/bin/passwd command. If an invalid password is
  entered, subsequent invocations of the passwd command,
  /usr/bin/X11/dxaccounts command, or the account management commands
  fail with the following error:

  The password and group files are currently locked by another user.

- Fixes for miscellaneous problems with the account management commands,
  specifically the Account Manager graphical user interface
  (/usr/bin/X11/dxaccounts) and the command line interface (useradd, userdel,
  groupadd, etc).

- Fixes a problem that causes the account management commands (dxaccounts,
  useradd, and usermod) to split long NIS group lines incorrectly.  This
  causes a majority of users to have improper access to files, directories,
  and applications and also causes the newgrp command to fail.

- Fixes the following problems:

    o  When Enhanced Security is enabled, the useradd and usermod commands
       incorrectly set the password expired and password lifetime attributes
       to 0 when not specified on the command line.

    o  The administrative_lock_applied command line option for useradd and
       usermod does not correctly lock and unlock an account.

    o  When Enhanced Security is enabled, userdel command incorrectly removes
       an account from /etc/passwd.
PROBLEM:        (QAR 46281)     (Patch ID: OSF400DX-005)
********
Using the Modify Selected Users dialog box, if you changed a set of users to be
NIS Override users, then the icons for those users were updated to reflect the 
change but the usernames in all the dialog box drop-down lists were not updated.
Specifically, the icons would be updated to have the "+" or "-" indicator for 
the user but the user's name was not changed to "user (+)" or "user (-)" in the 
drop-down lists.

The most noticeable symptom of this bug is a warning message printed to stdout 
when double clicking on one of the modified users:

  Warning: DtComboBoxWidget: Unable to find item to select
  (DtComboBoxSelectItem).

PROBLEM:        (QAR 48189)     (Patch ID: OSF400DX-005)
********
When running on an NIS master, using the Secondary Groups subdialog of the
Modify Selected NIS Users dialog box would not add the selected users to NIS 
groups - only local groups.  For example, if you selected user1 and user2 and 
used the Secondary Groups dialog to add them as members of group "users" and 
group "staff (NIS)", they would not be added as members of "staff" in 
/var/yp/src/group.

PROBLEM:        (QAR 48190)     (Patch ID: OSF400DX-005)
********
A related problem to 48189 above. If NIS is in use, then attempting to use the 
Modify Selected Users dialogs to change the primary group for the selected 
users would result in the error:

Group does not exists when the primary group was a NIS group.

PROBLEM:        (QAR 48191)     (Patch ID: OSF400DX-005)
********
If you attempt to change the primary group of a selected set of users using
ModifySelected dialog, the primary group of the users does not change.
However if you bring up the options dialog up by clicking the 'Options' button
and click Apply/Ok, the primary group all the selected users is changed.

PROBLEM:        (QAR 50998)     (Patch ID: OSF400DX-005)
********
On an Enhanced Security (C2) system, when adding a new user, the password
field in /etc/passwd is empty instead of being set to an asterisk ("*").
This is not a security issue for login authentication but can be a security
issue for third-party software that does not use Security Integration
Architecture (SIA) function calls.  Such software ignores the protected
password database and uses only /etc/passwd for password checking.

PROBLEM:        (QAR 49141)     (Patch ID: OSF400DX-005)
********
Dxaccounts would crash if you brought up a dialog from specific view, changed 
to a different view and then OK'd that dialog.  For example, if you brought up 
the Create/Modify User dialog, chose View/Local Groups to switch the main 
window to the Local Groups view, and then pressed OK in the Create/Modify User 
Dialog, dxaccounts would crash.

PROBLEM:        (QAR 49386)     (Patch ID: OSF400DX-005)
********
While adding/modifying a user or group, the UID or GID entered was not being
validated against the user-defined minimums and maximums set in the General 
Options dialog box.

PROBLEM:        (QAR 39332)     (Patch ID: OSF400DX-005)
********
Running two conncurrent instances of the account management commands is not 
supported. This restriction applies to the dxaccounts graphical user interface 
and the useradd, usermod, userdel, groupadd, groupmod, and groupdel commands. 
This restriction was release noted for Digital UNIX V4.0 and it is now enforced
in the software.

In order to prevent concurrent access, each account management command creates 
a lock file at startup called /etc/.AM_is_running. If any of the commands are 
terminated abnormally (e.g. kill -9) then this lock file will not be deleted 
and future command invocations will refuse to run with the error message:

  The password and group files are currently locked by another user.  
  Please try again later.

This message means that the account database files are either legitimately
locked OR one of the commands terminated abnormally leaving an
/etc/.AM_is_running lock file.  If no other root users are using the account
management commands, simply delete the lock file.

PROBLEM:        (QAR 47383)     (Patch ID: OSF400DX-005)
********
If NIS is not running on a system, then the Account Manager incorrectly tries 
to access the NIS databases. This happens when the system administrator uses 
the Modify Selected Users or Groups dialog boxes.

An error dialog box with an empty list is displayed that looked like:

             Account Manager Error List:
             ---------------------------
             Error accessing a system database file:
                   <empty list box>
             Please correct this error and restart Account Manager.
                       [OK]

PROBLEM:        (QAR 48221)     (Patch ID: OSF400DX-005)
********
When running the Account Manager on an Enhanced Security (C2) system, the 
"Remove User's Directory and Files" toggle button was ignored when a single-user
is retired using the Retire dialog box. The users directory would not be 
deleted. Only if multiple users were selected would the toggle button be 
honored.

PROBLEM:        (QAR 46468)     (Patch ID: OSF400DX-005)
********
When running the Account Manager on an Enhanced Security (C2) system, 
immediately deleting a newly created template would cause a crash.

PROBLEM:        (QAR 46730)     (Patch ID: OSF400DX-005)
********
When using useradd on an Enhanced Security (C2) system, the 
administrative_lock_applied flag is set unconditionally.

Also, the usermod command ignored the administrative_lock_applied flag so the
account could not be unlocked without using the dxaccounts graphical user
interface or the edauth command.

Now useradd honors the default setting of the administrative_lock_applied
flag. Specifying the flag on the command line will override the default
setting. Note that defaults are set using the -D option to usermod.

Also, usermod now correctly honors the administrative_lock_applied flag.

PROBLEM:        (QAR 44966)     (Patch ID: OSF400DX-005)
********
When using usermod on an Enhanced Security (C2) system, the -e and -f flags
were not honored. See the man page for a detailed description of these flags.

PROBLEM:        (QAR 46916)     (Patch ID: OSF400DX-005)
********
Using usermod -G to add a user to several groups as in:

  usermod user -G group1,group2,group3

would not add the user to all the specified groups.

PROBLEM:                        (Patch ID: OSF400DX-005)
********
While printing the accounts defaults using 'usermod -D', the inactive-
interval (i.e the maximum number of days allowed between usage of a login
ID before that login ID is declared invalid) was incorrectly printed as
a date instead of an interval.

PROBLEM:        (QAR 47123)     (Patch ID: OSF400DX-005)
********
Using "groupadd -g" to add a new group would crash and the group would not
get added if the directory /var/yp/src did not exist.

PROBLEM: 	(QAR 52127)	(Patch ID: OSF400DX-005)
********
When adding a new user using  /usr/bin/X11/dxaccounts or /usr/sbin/useradd,
if the account is created with a home directory of "/" then the permissions
on / are changed to 700. This renders the root file system inaccessible
to non-root users. Note that the persmissions are changed despite the
error message that is displayed:
          Errors encountered while adding the user: foo
             Cannot create user's home directory
             Home directory already exists
             Initial files not copied to home directory

The new behavior is to not change the permissions on a new user's home directory
if that directory already exists.

PROBLEM: 	(QAR 52042)	(Patch ID: OSF400DX-005)
********
The previous patch kit, Patch Kit-0001, caused a problem with the System V
Environment (SVE) password command /usr/opt/svr4/usr/bin/passwd. If the user
enters an invalid password then subsequent invocations of the passwd command,
/usr/bin/X11/dxaccounts, or the account management commands would fail with the
following error:

  The password and group files are currently locked by another user.

The problem was that the /etc/.AM_is_running lock file used by the account
managment commands was not being deleted properly.

PROBLEM:  (QAR 52479)		(Patch ID: OSF400DX-010)
********
When the a NIS-group entry in /var/yp/src/group file exceeds 256 characters,
certain functions performed in dxaccounts (such as locking or
unlocking an NIS/C2 user account) will split up the large group in the
/var/yp/src/group file into several smaller groups.  Each of these
smaller groups has the same group name and the same group id as the
original large group. As a result, users that are put in subsequent
occurences of the group don't actually get recognized as members of the
group.  This is causing severe problems in users' environment, causing
a majority of the users to not have proper access to files, directories
and applications and also causes the newgrp command to fail.

The current fix allows NIS-group entries upto 1000 characters. If any entry
exceeds 1000 characters while creating or modifying a group, the
Account Manager will print an error message stating that the nis group
must be split into severel groups of lengths less than 1000 characters
with group members evenly distributed among these groups, the groupname
must be in be in the format <group_name>_1, <group_name>_2 etc and the
id of all these groups must be the same as the original group.

PROBLEM: (QAR 55628) 	(Patch ID: OSF400DX-013)
********
When Enhanced Security is enabled, the useradd and usermod commands incorrectly
set the password expired and password lifetime attributes to 0 when they are
not specified on the command line.

PROBLEM: (QAR 56337) 	(Patch ID: OSF400DX-013)
********
When Enhanced Security is enabled, the administrative_lock_applied command line
options for useradd and usermod did not correctly set the lock attribute for
an account.  Accounts would remain locked if unlocking or remain unlocked if
locking.

PROBLEM: (QAR 56353) 	(Patch ID: OSF400DX-013)
********
When Enhanced Security is enabled, the userdel command removes an account from
the /etc/passwd file, but does not remove it from  the protected password 
database.  The userdel command when Enhanced Security is enable should retire
accounts, not remove them from the /etc/passwd file.


FILE(s):

/usr/lib/nls/msg/en_US.ISO8859-1/accmgrcli.cat   subset OSFSYSMAN400
CHECKSUM: 52865      3 
/usr/bin/X11/dxaccounts         		 subset OSFXSYSMAN400
CHECKSUM: 28616    456 
/usr/lib/nls/msg/en_US.ISO8859-1/Dxaccounts.cat  subset OSFSYSMAN400
CHECKSUM: 65207      8 
/usr/sbin/useradd               		 subset OSFSYSMAN400
CHECKSUM: 42621     72 
/usr/sbin/userdel              			 subset OSFSYSMAN400
CHECKSUM: 45077     64 
/usr/sbin/usermod              			 subset OSFSYSMAN400
CHECKSUM: 21003     72 
/usr/sbin/groupadd             			 subset OSFSYSMAN400
CHECKSUM: 06167     64 
/usr/sbin/groupdel              		 subset OSFSYSMAN400
CHECKSUM: 16774     64 
/usr/sbin/groupmod              	 	 subset OSFSYSMAN400
CHECKSUM: 36352     64 
/usr/shlib/libaccmgr.so         		 subset OSFSYSMAN400
CHECKSUM: 37283    312 

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

SUPERSEDED PATCHES:	OSF400X11-003 (186.00), OSF400X11-010 (189.00),
			OSF400X11-017 (320.00), OSF400X11-021 (403.00),
			OSF400X11-022 (498.00)
			
This patch corrects the following:

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

- Fixes a problem in which the output of the "last" or "finger" command lists
  users that are not currently logged in.

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

- Fixes a memory leak in Xlib when using fonts in an international (I18N)
  environment.  This problem affects Netscape Navigator in particular.

- X programs run by root or installed with suid root core dump on a fatal
  error such as an invalid display.

- When managing a CDE session on an X terminal from a Digital UNIX system,
  and the X terminal does not perform a normal logout, some of the CDE
  processes on the Digital UNIX system are left running.
PROBLEM:  (QAR 47205) 		(Patch ID: OSF400X11-003)
********
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:  (CLD UVO104899) 	(Patch ID: OSF400X11-010)
********
This patch fixes a problem in which the output of the "last" or "finger" 
command lists users that are not currently logged in.  This patch fixes the 
error by ensuring that the username field is cleared from the wtmp file when 
the user exits from an xterm process.

PROBLEM:  (SSRT0422U, HPAQ519VC, MGO102910) (Patch ID: OSF400X11-017)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised.  This may be in the form
of improper file or privilege management.  Digital has corrected this
potential vulnerability.

PROBLEM:  (QAR 53052) 			(Patch ID: OSF400X11-021)
********
This patch fixes a memory leak in Xlib when using fonts in an international
(I18N) environment.  This problem affects Netscape Navigator in particular.

PROBLEM:  (QAR 56775) 		(Patch ID: OSF400X11-022)
********
X programs run by root or installed with suid root core dump on a fatal error
such as an invalid display.  This problem was introduced by a previous patch
to the X Toolkit library (libXt).

PROBLEM:  (HPAQC0NDO) 		(Patch ID: OSF400X11-024)
*********
When managing a CDE session on an X terminal from a Digital UNIX system, and
the X terminal is turned off or otherwise does not perform a normal logout,
some of the CDE processes on the Digital UNIX system are left running.  
In particular, dtterm and dtstyle do not exit.


FILE(s):

/usr/bin/X11/xterm              subset OSFX11400
CHECKSUM: 14634    216 
/usr/lib/libX11.a               subset OSFXLIBA400
CHECKSUM: 63166   1506 
/usr/lib/libXt.a                subset OSFXLIBA400
CHECKSUM: 52852    621 
/usr/shlib/libX11.so            subset OSFX11400
CHECKSUM: 44137   1344 
/usr/shlib/libXt.so             subset OSFX11400
CHECKSUM: 08455    600 

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

This patch fixes a memory leak in the X server which is seen on systems with
a ZLX-E1, ZLX-E2, ZLX-E3, ZLXp-E1, ZLXp-E2, ZLXp-E3, PowerStorm 3D30, or
PowerStorm 4D20 graphics card.
PROBLEM:  (QAR 57031) 		(Patch ID: OSF400X11-025)
********
This patch fixes a memory leak in the X server which is seen on systems with
ZLX-E1, ZLX-E2, ZLX-E3, ZLXp-E1, ZLXp-E2, ZLXp-E3, PowerStorm 3D30, or 
PowerStorm 4D20 graphics card.


FILE(s):

/usr/shlib/X11/lib_dec_ffb.so           subset OSFSER400
CHECKSUM: 47911   1040 
/usr/shlib/X11/lib_dec_ffb_ev5.so       subset OSFSERPC400
CHECKSUM: 01198    976

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

SUPERSEDED PATCHES:	OSF400-306 (314.00)

This patch corrects the following:

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

- A potential security vulnerability has been discovered, where under certain
  circumstances, system integrity may be compromised. This may be in the form
  of improper file or privilege management. Digital has corrected this potential
  vulnerability.
PROBLEM:  (TKTB51380)		  (Patch ID: OSF400-306)
********
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.

PROBLEM:  (SSRT0499U)		 (Patch ID: OSF400-415)
********
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/syslogd               		subset OSFBASE400
CHECKSUM: 20853     40     RCSfile: syslogd.c      RCS: 4.2.36.4

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

SUPERSEDED PATCHES:	OSF400-001   (1.00),   OSF400-045  (45.00),
			OSF400-068   (68.00),  OSF400-111  (111.00),
			OSF400-105   (105.00), OSF400-148  (148.00),
			OSF400-125   (125.00), OSF400-176  (191.00),
			OSF400-176-1 (191.01), OSF400-217  (234.00), 
			OSF400-228   (247.00), OSF400-239B (294.00),
			OSF400-231   (250.00), OSF400-259  (275.00),
 			OSF400-122   (122.00), OSF400-297  (309.00),
			OSF400-254   (270.00), OSF400-315  (325.00),
			OSF400-322   (331.00), OSF400-344   (356.00),
                        OSF400-399   (486.00), OSF400-413   (415.00),
                        OSF400-436   (437.00), OSF400-445   (444.00),
                        OSF400-449   (447.00), OSF400-474   (471.00),
                        OSF400-476   (472.00), OSF400-482   (478.00),
			OSF400-497   (506.00), OSF400-489   (503.00)

This Patch corrects the following:

- Fixes two problems that occur on AdvFS systems:

    o An AdvFS data corruption problem can occur in user files.

  This problem will not produce either a core file or return non-zero system
  codes when accessing the corrupted file.

    o The verify command does not detect corrupted files.

- Multithreaded applications that call the pthread_mutex_destroy routine may
  fail when there are no threads referencing the mutex.  This is caused by a
  condition inside the pthread_mutex_unlock code.  The typical symptom will 
  be a return value of EBUSY from pthread_mutex_destroy.

- Fixes a problem with AdvFS in which the following two panics occur:

        AdvFS Exception  Module = 1, line = 1891
        kernel memory fault

- Systems running with AdvFS and LSM under heavy I/O loads can have sluggish
  interactive performance.  In a DECsafe environment, these systems can
  encounter unexpected relocation of services.

- Idle time is reset on broadcast message when AdvFS is the root file system.

- Fixes an AdvFS hang that could occur while running vdump.

- AdvFS hangs in routine cleanup_closed_list.

- A panic that is seen when running the auditd and auditing msfs_syscall.
  There will most likely be a lot of memory contention as well for this panic 
  to be triggered.

- NFS rpc.lockd "can't clear lock after crash of client" when AdvFS is being 
  used.

- A system may hang when an application or program attempts to read a file on 
  an AdvFS system.

- Fixes a system panic with the message "simple_lock: time limit exceeded".

- Fixes an "ADVFS EXCEPTION, Module = 26" panic that occurs after an
  "advfs I/O error" console message.

- Fixes a problem that occurs on AdvFS systems. When a user exceeds the
  quota limits, an excessive number of user warning messages are sent 
  to the system console if the user terminal is inaccessible.

- 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 that occurs on SMP systems with an AdvFS filesystem in
  which the system panics with the following message:

	simple_lock: time limit exceeded

- Fixes a problem that occurs on systems running AdvFS.  The system panics
  with the following error message:

        panic (cpu 0): bfs_invalidate: not on free list
        syncing disks...done

- When a user attempted to restore a vdump, which had been done with the
  "-D" option and included directories for which Access Control Lists (ACL's)
  had been declared, the vrestore program was failing to restore ACL's on
  directory files and issued warning messages.  When a user specified the 
  "-t" option, vrestore erroneously attempted to restore proplists on files
  that had them; issuing warning messages.

- Fixes a problem that occurs on AdvFS systems. The system will panic with
  an error message similar to the following:

	panic (cpu 0): kernel memory fault

- Corrects problems with AdvFS performance regression, and two AdvFS race 
  condition situations between multiple routines that can cause panics.

- Fixes a problem that occurs on an AdvFS file system. The system may panic
  with the following error message:

     ADVFS INTERNAL ERROR: dealloc_bits_page: can't clear a bit twice

- Fixes two problems that occur on AdvFS systems:

     o The system may panic with the following error message:

            	simple_lock: hierarchy violation

     o A locking problem in the AdvFS log data structures may cause the
       following problems to occur:

  		- System panics
		- Kernel memory faults
		- Memory corruption

- Fixes a problem that occurs on AdvFS systems.  If the "ls -l M1" command is
  given in a .tags directory, the fileset will become unmountable.  If the
  system is then halted, a panic will occur.

- Fixes an AdvFS problem in which improper handling of I/O queues cause either
  a kernel memory fault or the following panics:

        "bs_invalidate: cache rundown"
        "rm_or_moveq: ioDesc not on a queue"

- Corrects a problem in AdvFS where a data structure field is not initialized
  until after an AdvFS mount which is too late.  This results in the inability
  for example to see the files after a remount.

- Fixes a problem that occurs on an AdvFS file system.  While the symptoms of
  these AdvFS problems vary, the most common is a panic with the following 
  error message:

        bs_frag_alloc: pinpg faild\n N1 = -1035

        Alternately,

        bs_frag_dealloc: pinpg faild\n N1 = -1035

- Fixes an AdvFS problem that causes the system to panic with the following
  error message:	 simple_lock: lock already owned by cpu

- Fixes a system panic when shutting down to single user mode using one of the
  following commands:

        a.) # shutdown now
        b.) # init s

  when AdvFS is the root or usr filesystem.
PROBLEM:	(45411 39936 HPAQ71AFB) (Patch ID: OSF400-001)
********
This patch fixes a problem where a system may hang when an application or 
program attempts to read a file on an AdvFS system.

PROBLEM:  (CLD SOO100812) 	(Patch ID: OSF400-045)
********
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 <host> lockd[649]:
    can't clear locks after crash of client <ClientName>:  Invalid argument

PROBLEM:  (QAR 47190)	 	(Patch ID: OSF400-068)
********
This patch fixes a situation in which a kernel memory fault can occur.

This panic will only occur if the system is currently running the auditd demon
and auditing msfs_syscall calls. These are the AdvFs system calls. The panic
is most likely to occur if there is a heavy system load and paging is occuring.

The trace back will be:

    2 trap
    3 _XentMM
    4 audit_rec_build
    5 audit_call
    6 msfs_audit_syscall
    7 msfs_real_syscall
    8 msfs_syscall
    9 syscall
   10 _Xsyscall

PROBLEM:  (ZPOB82799)	 	(Patch ID: OSF400-111)
********
This fixes a problem where a hang occurs on an AdvFS filesystem. This problem
occurs because a thread is looping in routine "cleanup_closed_list".
Sample stack after forced crash:
   stop_secondary_cpu()
   panic("cpu_ip_intr: panic request")
   cpu_ip_intr()
   _XentInt()
   cleanup_closed_list()
   fs_cleanup_thread()

PROBLEM:  (GOZ100505)	 	(Patch ID: OSF400-105)
********
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:  (QAR 50227)	 	(Patch ID: OSF400-148)
********
This patch fixes an "ADVFS EXCEPTION" panic after an "advfs I/O error"
message to the console.  The traceback 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().

PROBLEM:  (HPAQ92E5E)	 	(Patch ID: OSF400-125)
********
The system is hung while running vdump and there is a thread with the following
signature (note: this is _NOT_ the vdump thread):

  0 imm_get_next_xtnt_desc() [../../../../src/kernel/msfs/bs/bs_inmem_map.c]
  1 imm_merge_xtnt_map()     [../../../../src/kernel/msfs/bs/bs_inmem_map.c]

PROBLEM:  (HPXQ42587, QAR46237)		 (Patch ID: OSF400-176)
********
On an AdvFS system, a broadcast message will cause the idle time to be reset to
zero.

PROBLEM:                          	(Patch ID: OSF400-176-1)
********        (QAR 36779) (Patch ID: OSF400-185 reference information)

This patch fixes a problem that occurs when running the NetWorker Version 4.2c
application.  The NetWorker application is unable to reset the atime (access
time) attribute on files being accessed. No errors or warnings are displayed.

Without this patch, NetWorker Version 4.2c will not perform well.

NetWorker application is unable to reset the atime on files being accessed.
Though this is undesirable bahavior, no errors or warnings are issued to
the user.

PROBLEM:  (TKTR71564 QAR 36411)		 (Patch ID: OSF400-217)
********
Systems running with AdvFS and LSM under heavy I/O loads can have sluggish
interactive performance.  In a DECsafe environment, these systems can 
encounter unexpected relocation of services.

PROBLEM:  (HPXQ43C4D, TKTR52185, QAR 46016) (Patch ID: OSF400-217)
********
A system can hang after the message "syncing disks..." prints during a panic.
When a hang occurs, the "syncing disks..." message does not print entirely
and the system does not take a dump.

A time-out mechanism was added to the "syncing disks" logic. This mechanism
improves 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.

PROBLEM:  (MGO102584)		 (Patch ID: OSF400-228)
********
This patch fixes AdvFS to prevent the following two panics:

        AdvFS Exception  Module = 1, line = 1891

        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:  (QAR 45580)            	(Patch ID: OSF400-239B)
********
Multithreaded applications that call the pthread_mutex_destroy routine may fail
when there are no threads referencing the mutex.  This is  caused by a race 
condition inside the pthread_mutex_unlock code.  The typical symptom will be
a return value of EBUSY from pthread_mutex_destroy.

Due to the pthreads fix vdump and vrestore need to be redistributed.

PROBLEM:  (QAR 51304, QAR 51596)	 (Patch ID: OSF400-231)
********
This patch fixes two problems that occur on AdvFS systems:

An AdvFS data corruption problem can occur in user files. This problem occurs
when AdvFS stores two different versions of a particular page (an 8K segment).
This problem will not produce either a core file or return non-zero system
codes when accessing the corrupted file.  The verify command will not detect
the corrupted file.

This patch provides the following:
  1. The OS is corrected to prevent any new files from being corrupted.
  2. The verify program now recognizes data corruptions.
  3. The verify -f command detects the corruption and moves the file into
     a temporary file. Another temporary file is created to show the
     contents of the corresponding "visible" page. These files are then
     available for analysis by the user for the purpose of manually
     repairing the corruption.

   The following is an example of a recovery procedure:

   To detect a corrupted file:

   # verify test_domain
   +++ Domain verification +++

   Domain Id 32d3e638.000a46a0

   Checking disks ...

   Checking storage allocated on disk /dev/rz1a

   Checking mcell list ...

   Checking mcell position field ...

   Checking tag directories ...

   +++ Fileset verification +++

   +++ Fileset test_fileset +++


   Checking frag file headers ...

   Checking frag file type lists ...

   Scanning directories and files ...
   Overlapping frag data corruption detected in:
   File: <mount point>/50226.file.4
   Page: 1
   Run verify -f on this domain to enable recovery of this data.

   Scanning tags ...

   Searching for lost files ...

   #

   The verify utility has detected a corrupted file in fileset
   test_fileset.  The name of the file is "50226.file.4" and it
   is located in the highest directory of the fileset when it is
   mounted.  The page that is corrupted is page 1.  Verify also
   suggests running verify again using the -f flag to enable recovery
   of the hidden data for page 1.

   At this point there are two choices:

   1. Delete the file and recreate it. The corruption problem has been
      fixed on the system. The newly created file will not exhibit the
      undesired behavior.

   2. Run verify with the -f flag to identify the corrupted data.


   To identify the corrupted data:


   Run the verify command with the -f flag.

   # verify -f test_domain
   +++ Domain verification +++

   Domain Id 32d3e638.000a46a0

   Checking disks ...

   Checking storage allocated on disk /dev/rz1a


   Checking mcell list ...

   Checking mcell position field ...

   Checking tag directories ...

   +++ Fileset verification +++

   +++ Fileset test_fileset +++

   Checking frag file headers ...

   Checking frag file type lists ...

   Scanning directories and files ...
   Overlapping frag data corruption detected in:
   File: <mount point>/50226.file.4
   Page: 1
   Temporary files created representing the two versions of
   page 1 of file <mount point>/50226.file.4
   Refer to the README file accompanying the patch for a description

   of how to use these temporary files to recover
   from this overlapping frag corruption problem.
   Scanning tags ...

   Searching for lost files ...

   #

   The verify utility reports that it has created two temporary files
   in the same directory as the corrupted file.  Mount the fileset to
   identify these two files:


   # mount test_domain#test_fileset /test
   # ls -l /test
   total 169
   drwx------   2 root  system      8192 Jan  8 13:23 .tags
   -rw-r--r--   1 root  system     24576 Jan  9 12:27 50226.file.1
   -rw-r--r--   1 root  system     40960 Jan  9 12:27 50226.file.2
   -rw-r--r--   1 root  system     32768 Jan  9 12:27 50226.file.3
   -rw-r--r--   1 root  system     24576 Jan  9 12:27 50226.file.4
   -rw-------   1 root  system      8192 Jan 13 14:32 50226.file.4.page_1.ext
   -rw-------   1 root  system      8192 Jan 13 14:32 50226.file.4.page_1.frag
   -rw-r-----   1 root  operator    8192 Jan  8 13:23 quota.group
   -rw-r-----   1 root  operator    8192 Jan  8 13:23 quota.user

   The .ext and .frag files contain information from the corrupted area. In
   the example above:

   50226.file.4              The original corrupted file
   50226.file.4.page_1.ext   A file containing the hidden version of page 1
                             of the corrupted file. A read() cannot
                             retrieve this data.
   50226.file.4.page_1.frag  A file containing the frag version of page 1

                             of the corrupted file.  This is the same data
                             that a read() of page 1 would return.


   To fix the corrupted file:

   1. View the .ext and .frag files to determine which to keep. Note that what
      might really be desired is a merge of the two.

      If the file 50226.file.4.page_1.ext contains the desired data, enter:


      If the file 50226.file.4.page_1.frag contains the desired data, enter:

      # ln -s 50226.file.4.page_1.frag desired_page_1

      If a merge of the two must be done, do the merge and put the result
      into a new file called desired_page_1.

   2. Create a new fixed version of the corrupted file using the
      corrupted file and new file (desired_page_1 in this example).

      A. Copy page 0 (good page) from the corrupted file into a new file:

         # dd if=50226.file.4 of=newfile bs=8192 count=1

      B. Append the desired page 1 to the new file by seeking over 1 page
         in the output file before writing:

         # dd if=desired_page_1 of=newfile bs=8192 count=1 seek=1

      C. Append the remainder of the original file to the end of the new file
         by skipping past the first two pages of the input file
         before reading, and seeking past the first 2 pages (already
         rewritten) in the output file before writing:

         # dd if=50226.file.4 of=newfile bs=8192 seek=2 skip=2

         Run the diff command on the new and the original file to confirm that
         only page 1 has changed to and that the difference is what is desired.
         For example:

         diff newfile 50226.file.4

      D. Rename the new file and remove the temporary files:

         # mv newfile 50226.file.4
         # rm 50226.file.4.page_1.ext 50226.file.4.page_1.frag desired_page_1

         If desired, the verify command can now be run on the domain again to
         confirm that the data corruption problem is gone.

PROBLEM:  (UVO105186)		 (Patch ID: OSF400-259)
********
This patch fixes a problem that occurs on AdvFS system. When a user exceeds
the quota limits, an excessive number of user warning messages are sent to
the system console if the terminal is inaccessible.

After applying this patch, if a user exceeds the quota limits, the warning
messages are still displayed on the terminal (when possible) but never on the
system console. Additionally, when a quota underflow occurs, the warning
message now describes the fileset and the user or group that is experiencing
the underflow problem.

PROBLEM:  (CLD UTO101199,HPAQ30ETE,QAR 51485,52365) (Patch ID: OSF400-262)
********  (Patch ID OSF400-351 (222.00) reference information)
This patch corrects a problem with an NFS V3 mounted AdvFS file system where
under heavy I/O load, data being written to a file may be lost.  Additionally,
because file stats are not being saved, the file modification time my revert
to a previous value.

PROBLEM:  (UVO105368)		 (Patch ID: OSF400-297)
********
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:  (MCPM31DX7)		 (Patch ID: OSF400-254)
********
This patch fixes a problem that occurs on SMP systems with an AdvFS filesystem
in which the system panics with the following message:

        simple_lock: time limit exceeded

The problem occurs when the lock is taken by a thread that calls the
msfs_unmount routine, as can be seen from lock structure in pmsgbuf:

    pc of caller:         0xfffffc00003d756c
    lock address:         0xfffffc00574e12f8
    current lock state:   0x00000000003d6a49
(cpu=0,pc=0xfffffc00003d6a48,busy)

The pc in "current lock state" was code executed by that thread.  This code can
be further defined by printing it in dbx:

    dbx>0xfffffc00003d6a48/i
    [msfs_unmount:2035]

PROBLEM:  (QAR 50858,44602,44776)	 (Patch ID: OSF400-315)
********
This patch fixes a problem that occurs on systems running AdvFS.  The problem
occurs when greater than 512 filesets are created.  The system panics with the
following error message:

        panic (cpu 0): bfs_invalidate: not on free list
        syncing disks...done

PROBLEM:  (HPAQ50U3T,ZUO101186)		  (Patch ID: OSF400-322)
********
When a user attempted to restore a vdump, which had been done with the "-D"
option and included directories for which Access Control Lists (ACL's) had
been declared, the vrestore program was failing to restore ACL's on directory
files and issued the following messages:

RECORD HEADER (unknown/unexpected)
 record type  : 14
 data offset  : 0
 record size  : 208
 flags        : <none>

RECORD HEADER (unknown/unexpected)
 record type  : 14
 data offset  : 0
 record size  : 208
 flags        : <none>
vrestore: error setting extended attributes 2

The "unknown/unexpected" error was being reported twice on each directory for
which ACL's had been found (since they are recorded twice  in the vdump).
When a user specified the "-t" option, vrestore erroneously attempted to
restore proplists on files that had them; issuing same warning messages.

PROBLEM: (Patch ID: OSF400-331)
********
When the /etc/passwd file is very large, a performance degradation may occur.

When the number of passwd entries reaches up into the 30,000 to 80,000 range
or greater, mkpasswd will sometimes fail to create a hashed (ndbm) database.
Since the purpose of this database is to allow for efficient (fast) searches
for passwd file information, failure to build it causes commands that rely
on it to do a linear search of /etc/passwd.  This results in a serious per-
formance degradation for those commands.  This patch allows the vedquota,
vquot, vquota and vquotacheck commands to work correctly when the customer
builds a hashed passwd database using a non-default page file block size.

For customers choosing to use the mkpasswd -s option to avoid this type of
failure, a potential database/binary compatibility problem may arise.  If a
customer application that accesses the password database created by mkpasswd
is built statically (non-shared), that application will be unable to read
from or write to the password database correctly.  This would cause the
customer application to fail either by generating incorrect results or by
possibly dumping core.  Any statically linked application would be affected
if it directly or indirectly calls any of the libc ndbm routines documented
in the ndbm(3) man page and then accesses the password database.  To remedy
this situation, the customer would need to re-link the application.

Customers who do not use the mkpasswd -s option will not see this database/
binary compatibility problem.

PROBLEM:  (GOZ100774)		 (Patch ID: OSF400-344)
********
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 48878,36473,44706,49895) (Patch ID: OSF400-399)
********
This patch corrects problems with AdvFS performance regression, and two AdvFS
race condition situations between multiple routines that can cause panics.

One AdvFS race condition is between the ubc routines that call putpage and
AdvFS invalidate. If this condition arises an ensuing panic may occur.
Output from the panic might look like:

lock_read: hierarchy violation

      pc of caller:         0xfffffc0000397728
      lock address:         0xffffffff8031a200
      lock info addr:       0xfffffc0000722200
      lock class name:      bfAccessT.xtntMap_lk
      class already locked: bfAccessT.putpage_lk
      current spl level:    0

  panic (cpu 0): lock_read: hierarchy violation
  syncing disks...
  lock_read: simple lock owned

      pc of caller:         0xfffffc00003c6f80
      lock address:         0xffffffff8031a2b0
      lock info addr:       0xfffffc0000722210
      lock class name:      bfAccessT.putpage_lk
      pcb slock count:      2
      current spl level:    2

The other AdvFS race condition is between msfs_putpage and
bs_real_invalidate_pages. If this condition were to arise,
it too might cause a panic to occur. Output from the panic
might look like:

panic "bs_real_invalidate_pages: buf refd or pinned"

PROBLEM:  (QAR 54983, QAR 49607)	 (Patch ID: OSF400-413)
********
This patch fixes a problem that occurs on an AdvFS file system. The system may
panic with the following error message:

     ADVFS INTERNAL ERROR: dealloc_bits_page: can't clear a bit twice

The following is an example of a stack trace:

 (dbx) t
 >  0 stop_secondary_cpu(do_lwc = 0x0)
    1 panic(s = 0xfffffc0000556528)
    2 event_timeout(func = 0xfffffc0000276738, arg = 0xfffffc000059a2c0,
timeout = 0x5)
    3 xcpu_puts(s = 0xfffffc00005798d0, prfbufp = 0xfffffc000059a2c0)
    4 printf(fmt = 0xfffffc000051fd68)
    5 panic(s = 0xffffffff88cb71d0)
    6 advfs_sad(0xfffffc000030a7c8, 0x0, 0xe, 0x1f500, 0xfffffc0005952000)
    7 CANT_CLEAR_TWICE(0x7b, 0xe, 0xffffffffffffff00, 0xc27f, 0x612)
    8 dealloc_bits_page(0x38, 0xfffffc00005311a0, 0xfffffc00075d2008,
0xfffffc00057ba000, 0x301001a)
    9 bitmap_undo_opx(0x3, 0xfffffc00005b9df8, 0xfffffc00075d2298, 0x0,
0xfffffc00075d3578)
   10 ftx_fail_2(ftxH = struct {
     hndl = 0x1a
     level = 0x2
     dmnh = 0x1
     }
   11 ftx_fail(ftxH = struct {
     hndl = 0x0
     level = 0x0
     dmnh = 0x0
     }
   12 fs_write_add_stg(0x1, 0xffffffff80287530, 0x7, 0xfffffc00020986e0, 0x0)
   13 fs_write(0xc884, 0x14, 0x45f4f, 0x200000002, 0x0)
   14 msfs_write(vp = 0xfffffc0002098600, uio = 0xffffffff88cb7848, cred =
0xfffffc0001e0be00)
   15 vn_write(0xfffffc00002839ec, 0xffffffff88cb78e0, 0xfffffc000783bfc0,
0xf888, 0x1)
   16 rwuio(0xfffffc0001fb6220, 0xfffffc0005431b80, 0xfffffc0000575ab0,
0xfffffc0001fb6000, 0xfffffc0 00783bfc0)
   17 write(0xc884, 0xffffffff88cb7838, 0x28000, 0xc88400000001, 0x100000000)
   18 syscall(0xf888, 0x1, 0xfffffc000045f7fc, 0x3ffc01877c0, 0x4)
   19 _Xsyscall(0x8, 0x3ff800d2ed8, 0x14000c2c0, 0x3, 0x140059000)
 (dbx)

PROBLEM:  (QAR 56152,55813)	 (Patch ID: OSF400-436)
********
This patch fixes two problems that occur on AdvFS systems:

   o The system may panic with the following error message:
     simple_lock: hierarchy violation

   o A locking problem in the AdvFS log data structures may cause the
     following to occur:

        - System panics
        - Kernel memory faults
        - Memory corruption

PROBLEM:  (QAR 51816,45334)	 (Patch ID: OSF400-445)
********
This patch fixes a problem that occurs on AdvFS systems. If the "ls -l M1"
command is given in a .tags directory, the fileset will become unmountable.
If the system is then halted, the following panic will occur.

   1 panic(...RefCnt =...)
   2 advfs_sad()
   3 bfs_dealloc()
   4 bs_bfs_remove_root( )
   5 dmn_dealloc()
   6 bs_bfdmn_deactivate()
   7 bs_bfset_deactivate()
   8 msfs_unmount( )
   9 dounmount()
  10 boot( )
  11 reboot()
  12 syscall()
  13 _Xsyscall()

PROBLEM:  (MCGMA1R2P,FNO100154)	 (Patch ID: OSF400-449)
********
This patch fixes an AdvFS problem in which improper handling of I/O queues cause
either a kernel memory fault or the following panics:

        "bs_invalidate: cache rundown"
        "rm_or_moveq: ioDesc not on a queue"

Sample stack traces follow:

1)
   5 panic(s = 0xfffffc00005efab0 = "kernel memory fault")
   6 trap()
   7 _XentMM()
   8 bs_osf_complete() (attempting to obtain a pointer to a virtual disk table
                        to log statistics for the disk that the i/o occurred on)
   9 msfs_async_iodone_lwc()
  10 lwc_schedule()
  11 thread_block()
  12 xpt_callback_thread()
  13 lwc_schedule()
2)
   9 panic()
  10 trap()
  11 _XentMM()
  12 bs_q_lazy()
  13 bs_q_list()
  14 bs_unpinpg()
3)
   9 panic()
  10 trap()
  11 _XentMM()
  12 consecutive_list_io()
  13 bs_startio()

Note:
Users should also not attempt to reduce the AdvFS per-volume cache to zero.
This could result in mismanagement of buffers associated with that device
and could cause further panics or corruptions. This is generally done by
performing "chvol -t 0 domain". In a future release this will be disallowed.

PROBLEM:  (QAR 57938,50417)		 (Patch ID: OSF400-474)
********
This patch corrects a problem in AdvFS where a data structure field is not
initialized until after an AdvFS mount which is too late. This results in
the inability for example to see the files after a remount.

An example of this problem would be the ls command not being able to list files
on an AdvFS mounted filesystem that is NFS exported.

PROBLEM:  (QAR 57680,57689,58050,49803) (Patch ID: OSF400-476)
********
While the symptoms of these AdvFS problems vary, the most common is a panic
with the following error message:

    bs_frag_alloc: pinpg faild\n N1 = -1035

    Alternately,

    bs_frag_dealloc: pinpg faild\n N1 = -1035

A sample stack trace follows:

   0 panic()
   1 event_timeout()
   2 xcpu_puts()
   3 printf()
   4 panic()
   5 advfs_sad()
   6 bs_frag_dealloc()
   7 fs_delete_frag()
   8 copy_and_del_frag()
   9 fs_write_add_stg()
  10 fs_write()
  11 msfs_write()
  12 vn_write()
  13 rwuio()
  14 write()
  15 syscall()
  16 _Xsyscall()

PROBLEM:  (QAR 56845, QAR 56403) 	(Patch ID: OSF400-482)
********
This patch fixes an AdvFS problem that causes the system to panic with the
following error message:

    simple_lock: lock already owned by cpu

PROBLEM:  (QAR 55308, QAR 55447)         (Patch ID: OSF400-389)
********
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)

PROBLEM:  (QAR 57258,56851) 	(Patch ID: OSF400-497)
********
This patch corrects a problem where the mcellCount on-disk was not being
updated as files were being migrated and this resulted in a panic situation.

The panic would produce a message like:

bs_frag_alloc: pinpg faild\n N1 = -1035

PROBLEM:  (QAR 57798,57702)	 (Patch ID: OSF400-497)
********
This patch fixes a race condition that occurs on an AdvFS file system.
The system panics with the following error message:

        panic (cpu 0): bs_frag_alloc: pinpg faild

PROBLEM:  (QAR 57086,56656) 	(Patch ID: OSF400-497) 
********
This patch fixes a problem that occurs on an AdvFS file system.
An AdvFS lock is not released which hangs the system next time a thread
tries to obtain the lock.

PROBLEM:  (QAR 55791,55773)	 (Patch ID: OSF400-497)
********
When executing /sbin/advfs/verify command on an unmounted
AdvFS domain, the system will panic with the following
panic string:

panic_string:  0xfffffc00006cad90 = "kernel memory fault"

The stack trace looks like the following:

        boot()
        panic()
        trap()
        _XentMM()
        fs_update_stats()
        cleanup_closed()
        fs_cleanup_thread()

PROBLEM:  (QAR 57164,54852) 	 (Patch ID: OSF400-489)
********
This patch fixes a system panic when shutting down to single user mode using
one of the following commands:

        a.) # shutdown now
        b.) # init s

When AdvFS is the root or usr filesystem.  This cause of this problem is subject
to the timing of several kernel threads, so therefore the symptoms or panic may
occur intermittantly and on different platforms.

The example stack trace is as follows:

>  0 boot(0x0, 0x4, 0x1, 0x1, 0xfffffc00004893b8)
["../../../../src/kernel/arch/alph a/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, 0xf ffffc0000437044]
 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, 0xf ffffc00003bd5bc]
 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, 0xfffffc0007cc00
 18) ["../../../../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]


FILE(s):

/sys/BINARY/advfs.mod           		subset OSFADVFSBIN400
CHECKSUM: 00939   1144 
/usr/sbin/advfsstat             		subset OSFADVFS400
CHECKSUM: 07856    232     RCSfile: advfsstat.c      RCS: 1.1.16.2
/sbin/advfs/logread             		subset OSFADVFS400
CHECKSUM: 61001     32     RCSfile: logread.c     RCS: 1.1.2.3
/sbin/advfs/verify              		subset OSFADVFS400
CHECKSUM: 22237    224     RCSfile: verify.c      RCS: 1.1.15.2
/usr/lib/nls/msg/en_US.ISO8859-1/verify.cat  	subset OSFADVFS400
CHECKSUM: 53996     12
/sbin/vdump                                     subset OSFADVFS400
CHECKSUM: 08585    432 
/sbin/vrestore                                  subset OSFADVFS400
CHECKSUM: 03671    464     RCSfile: vrestore.c    RCS: 1.1.45.3
/usr/sbin/vedquota              		subset OSFADVFS400
CHECKSUM: 56242    408     RCSfile: vedquota.c    RCS: 1.1.25.2
/usr/sbin/vquot         			subset OSFADVFS400
CHECKSUM: 20917    424     RCSfile: vquot.c       RCS: 1.1.7.3
/usr/sbin/vquota                		subset OSFADVFS400
CHECKSUM: 00466    352     RCSfile: vquota.c      RCS: 1.1.22.2
/usr/sbin/vquotacheck           		subset OSFADVFS400
CHECKSUM: 22962    384     RCSfile: vquotacheck.c RCS: 1.1.23.2

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

This patch fixes a problem in which users logging into a system that has a
nodename longer than 32 characters cause ttsession to core dump.  This only
happens when using CDE desktop.
PROBLEM:  (CLD MGO102608)	 (Patch ID: OSF400CDE-006)
********
This patch fixes a problem in which users logging into a system that has a
nodename longer than 32 characters cause ttsession to core dump.  This only
happens when using CDE desktop.


FILE(s):

/usr/dt/lib/libtt.a             subset OSFCDEDEV400
CHECKSUM: 21576   1607

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

- Fixes the problem of the math library functions not returning the correct
  NaN value as defined in the Alpha AXP Architecture Reference Manual
  (Second Edition).

- Fixes a problem with fastmath functions F_Exp() and F_Pow() that would
  cause floating exception core dumps.
PROBLEM:  (QAR 48474)           (Patch ID: OSF400-083)
********
This fix changes the encoding of IEEE floating-point Quiet NaNs returned by the
math library by setting the sign bit. This fix corrects inconsistency between
the value returned by the math functions and the kernel encoding.

A NaN is the floating-point representation of a result that is "Not A Number"
(e.g. the floating-point result of zero divided by zero is a NaN).

This change is only of interest to programmers who use IEEE floating-point math
 with the -ieee or the -ieee_with_inexact option. It does not affect programs
or libraries not using the full IEEE math support.

For more information, see the IEEE Standard for Binary Floating Point
Arithmetic ANSI/IEEE (Std 754-1985). For information about the Alpha AXP
implementation, see the Alpha AXP Architecture Reference Manual (Second Edition)
by Richard L. Sites and Richard T. Witek, Digital Press, 1995. See the section
on "Encodings" (4.7.4).

Compile the following program using the -ieee and -lm options:

#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
main()
{
    double a, b, c, d;
    int i;

    a = sqrt( -1.0 );
    i = sscanf("0.0 0.0 0.0", "%lf %lf %lf", &b, &c, &d);
    assert(i == 3);
    printf( "sqrt( -1.0 ) = %f\t\t0x%016lx\n", a, *(long *)&a );

    d = b / c;

    printf( "0.0 / 0.0 = %f\t\t0x%016lx\n", d,*(long *)&d );
}

Compile this program using the -ieee and -lm command line options.


Results before installing new math library:
sqrt( -1.0 ) = NaNQ             0x7fffffffffffffff
0.0 / 0.0 = -NaNQ               0xfff8000000000000

Results after installing new math library:
sqrt( -1.0 ) = -NaNQ            0xfff8000000000000
0.0 / 0.0 = -NaNQ               0xfff8000000000000

PROBLEM:  (QAR 52294, CLD SDT-1335) (Patch ID: OSF400-293)
********
There is a problem with the F_exp(), the fast exponentiation function, and the
F_pow(), the fast math power function, in the way that they handle underflow
arguments.

For certain arguments, a calls to F_exp() and F_pow() result in a floating-point
exceptions.

PROBLEM:  (QAR 52294, CLD SDT-1335)      (Patch ID: OSF400-362)
********
There is a problem with the F_exp(), the fast exponentiation function, and
the F_pow(), the fast math power function, in the way that they handle underflow
arguments.


For certain arguments, a calls to F_exp() and F_pow() result in floating-point
exceptions accompanied by core dumps.


FILE(s):
/usr/shlib/libm.so                         subset OSFBASE400
CHECKSUM: 52237    552

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

This patch corrects the following:

- Under enhanced security, sometimes users (even root) are unable to log in
  on graphics console, even after using dxdevices or edauth to clear the
  t_failures count.

- On systems running enhanced security, user-written applications
  that call auth_for_terminal() may fail with a segmentation fault.
PROBLEM:  (HPAQ17931, HPAQA353A) (Patch ID: OSF400-115)
********
On systems running enhanced security, if a customer's application calls the
auth_for_terminal() routine when 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
customer's application will fail with a segmentation fault.

PROBLEM:  (CLD HGOQB0282)        (Patch ID: OSF400-203)
********
On a system using enhanced security, login attempts at a graphic console can
fail, giving the message: "Terminal is disabled -- see Account Administrator."
This failure persists even after using dxaccounts or edauth to clear the
t_failures entry for the display in the terminal control databas

FILE(s):

/usr/shlib/libsecurity.so               subset OSFBASE400
CHECKSUM: 33187    360

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

This patch fixes two system run level problems:

o On a system running LSM, whenever there is a run level change, the
  lsmbstartup script runs.  This causes root to be mounted read/write
  in single-user mode.

o The bcheckrc command script continues to run even if there is an
  invalid root entry. This leaves the system in an unusable state
  in single-user mode.
PROBLEM:  (QAR 51645,41116,48720,50207) (Patch ID: OSF400-364)
********
This patch fixes two system run level problems:

  o On a system running LSM, whenever there is a run level change, the
    lsmbstartup script runs.  This causes root to be mounted read/write
    in single-user mode.

  o The bcheckrc command script continues to run even if there is an
    invalid root entry. This leaves the system in an unusable state
    in single-user mode. Root is not mounted writeable and cannot be
    modified with the mount -u command.

FILE(s):

/sbin/lsmbstartup               subset OSFLSMBASE400
CHECKSUM: 42579      4     RCSfile: lsmbstartup.sh      RCS: 1.1.16.2
/sbin/init.d/lsm                subset OSFLSMBASE400
CHECKSUM: 64364      3     RCSfile: lsm                 RCS: 1.1.15.2

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

This patch fixes the following problems:

o  The uprofile and kprofile commands report incorrect statistics on an SMP
   system or when trying to measure EV5 events other than cycles.

o  The pfm driver ioctl PCNT5GETCNT returns incorrect data.

o  An unstoppable stream of pfm interrupts is produced if an EV5 machine is
   rebooted with the pfm driver active.

o  The pfm(8), uprofile(1), and kprofile(1) manpages do not describe the
   EV5 statistics supported by the software.

All users of the pfm driver and uprofile or kprofile commands should
install this patch.
PROBLEM:  (QAR 54099)            (Patch ID: OSF400-371)
********
The uprofile and kprofile commands will report incorrect statistics on an
SMP system or when trying to measure EV5 events other than cycles.

Without this patch, results from CPUs other than CPU 0 will not be reported.
Also, the "cycles" statistic will always be reported regardless of the
user's selection of EV5 events to measure.

PROBLEM:  (QAR 49430)            (Patch ID: OSF400-371)
********
The pfm driver ioctl PCNT5GETCNT returns incorrect data.

PROBLEM:  (QAR 49456)            (Patch ID: OSF400-371)
********
Interrupts are not stopped when the pfm device is closed.  This leads to
an unstoppable stream of performance counter interrupts if an EV5 machine
is rebooted with the driver active.  When rebooting, the console reports:

        unexpected exception/interrupt through vector 650
        .
        .
        .
        unexpected exception/interrupt through vector 650

continuously.  The only way out is to reset the system.

PROBLEM:  (QAR 54562)            (Patch ID: OSF400-371)
********
The pfm(8), uprofile(1), and kprofile(1) manpages do not describe the EV5
statistics supported by the software.


FILE(s):

/usr/ccs/lib/cmplrs/cc/uprofile         subset OSFSDE400
CHECKSUM: 29173    184     RCSfile: uprofile.c RCS: 1.1.23.2
/usr/share/man/man1/uprofile.1.gz       subset OSFMANOS400
CHECKSUM: 33944      4
/usr/share/man/man1/kprofile.1.gz       subset OSFMANOS400
CHECKSUM: 47775      4
/usr/share/man/man7/pfm.7.gz            subset OSFMANOS400
CHECKSUM: 37517      7

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

This patch provides the requried run-time support for images created by the
Digital C++ V6.0 and above compiler.  Contact the Digital C++ compiler group
(cxx@lego.zko.dec.com) for details.
PROBLEM:                 (Patch ID: OSF400-487)
********
This patch provides the required run-time support for images created by the
Digital C++ V6.0 and above compiler.

When using th eDigital C++ V6.0 compiler, customers can use the un-documented
compiler switch:

     -use_system_libcxx

which will cause the compiler to use the system libcxx.so file when linking.
This switch should only be used if the resulting images are to be executed
either on other systems which have had the libcxx.so patch installed, or on
Digtial UNIX V4.0D and above systems.


FILE(s):

/usr/ccs/lib/libcxx.a           subset OSFLIBA400
CHECKSUM: 25347    233

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

A potential security vulnerability has been discovered in 'libDtSvc', where
under certain circumstances users may gain unauthorized access.  Digital has
corrected this potential vulnerability.
PROBLEM:  (CLD SSRT0498U)       (Patch ID: OSF400CDE-013)
********
A potential security vulnerability has been discovered in 'libDtSvc', where
under certain circumstances users may gain unauthorized access.  Digital has
corrected this potential vulnerability.

FILE(s):

/usr/dt/lib/libDtSvc.so         subset OSFCDEMIN400
CHECKSUM: 31275    680

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

SUPERSEDED PATCHES:     OSF400-151 (151.00), OSF400-171 (171.00),
                        OSF400-196 (209.00), OSF400-264 (280.00),
                        OSF400-385 (397.00)

This patch corrects the following:

- Fixes the problem of t_optmgmt() T_NEGOTIATE calls returning T_SUCCESS,
  but not actually negotiating the socket options. This behavior is a
  UNIX95 specification standard compliance bug.

- Fix for a problem that manifests itself by the system hanging or becoming
  inoperable when a number of XTI connections reaches 500.

- Resolves a hang in the xticlose() routine and a kernel memory fault in the
  xti_discon_req() routine.

- Corrects a problem with the xti/streams interface module which could result
  in a kernel memory fault panic during use by xti application programs.

- Fixes a problem with the implementation of the TPI interface.  This problem
  occurs if you are using Digital's XTI libxti library with a third-party
  (non-Digital) STREAMS driver.
PROBLEM:  ( QARs 49922 and 48633  ) (Patch ID: OSF400-151)
********
Multi-threaded TLI application blocks forever. dbx session will show that it
blocks in the t_look() library routine. For this to happen, it is necessary
that t_look() is called twice. Because it is called internally by a number of
other TLI library routines, application can hang under all sorts of scenarios.

PROBLEM:  (QAR 49764)            (Patch ID: OSF400-171)
********
When attempting to establish a number of XTI connections, > 500, the client
system hangs and becomes inoperable. This fix  will allow an application to
issue a large number of connect requests (up to 3K connections).

PROBLEM:  (QAR 51684)            (Patch ID: OSF400-196)
********
This patch fixes the problem of t_optmgmt() T_NEGOTIATE calls returning
T_SUCCESS, but not actually negotiating the options.

PROBLEM:  (CLD MCPM209Q3, QAR 51394) (Patch ID: OSF400-264)
********
This patch fixes a hang in the xticlose() routine.  The user would see a
stack trace similar to the following.

thread_block() ["../../../../src/kernel/kern/sched_prim.c":2036 ]
mpsleep() ["../../../../src/kernel/bsd/kern_synch.c":563 ]
streams_mpsleep() ["../../../../src/kernel/streams/str_env.c":574 ]
xticlose() ["../../../../src/kernel/streamsm/xtiso.c":965 ]
close_wrapper() ["../../../../src/kernel/streams/str_subr.c":317 ]
csq_protect() ["../../../../src/kernel/streams/str_synch.c":770 ]
osr_pop_subr() ["../../../../src/kernel/streams/str_osr.c":1686 ]
osr_close_subr() ["../../../../src/kernel/streams/str_scalls.c":1345 ]
pse_close() ["../../../../src/kernel/streams/str_scalls.c":1196 ]
speclose() ["../../../../src/kernel/vfs/spec_vnops.c":2462 ]
spec_close() ["../../../../src/kernel/vfs/spec_vnops.c":2616 ]
vn_close() ["../../../../src/kernel/vfs/vfs_vnops.c":1292, ]
closef() ["../../../../src/kernel/bsd/kern_descrip.c":1539 ]
exit() ["../../../../src/kernel/bsd/kern_exit.c":936 ]
rexit() ["../../../../src/kernel/bsd/kern_exit.c":755 ]
syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":555 ]
_Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1177 ]

PROBLEM: (HPAQC12ZB, UVO105080)  (Patch ID: OSF400-264)
********
This patch fixes a kernel memory fault panic in the xti_discon_req() routine.
A representitive stack trace is:

boot() ["../../../../src/kernel/arch/alpha/machdep.c":2484 ]
panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":791 ]
trap() ["../../../../src/kernel/arch/alpha/trap.c":1520 ]
_XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1424 ]
xti_discon_req() ["../../../../src/kernel/streamsm/xtiso.c":4449 ]
xti_output() ["../../../../src/kernel/streamsm/xtiso.c":1729 ]
xtiwsrv() ["../../../../src/kernel/streamsm/xtiso.c":1639 ]
sq_wrapper() ["../../../../src/kernel/streams/str_runq.c":137 ]
csq_lateral() ["../../../../src/kernel/streams/str_synch.c":992 ]
runq_run() ["../../../../src/kernel/streams/str_runq.c":108 ]
netisr_thread() ["../../../../src/kernel/net/netisr.c":841 ]

PROBLEM:  (HPAQ9145N, HPAQ70F4R, and HPAQ90B3J) (Patch ID: OSF400-385)
********
Under some conditions, an xti application which attempts to disconnect an
endpoint will precipitate a kernel memory fault panic form the xti_discon_req
routine.

PROBLEM:  (QAR  54884)           (Patch ID: OSF400-405)
********
This patch fixes a problem with the implementation of the TPI interface. This
problem occurs if you are using Digital's XTI libxti library with at third-
party (non-Digital) STREAMS driver.

FILE(s):

/usr/ccs/lib/libtli.a           subset OSFLIBA400
CHECKSUM: 30064     80
/usr/ccs/lib/libxnet.a          subset OSFLIBA400
CHECKSUM: 34988     67
/usr/ccs/lib/libxti.a           subset OSFLIBA400
CHECKSUM: 34988     67

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

This patch fixes a probem that affects systems using databases with the btree
file format.  Only applications using btree in libdb.a or libdb.so are affected
and may return incorrect data or crash.
PROBLEM:  (QAR53001)            (Patch ID: OSF400-365)
********
This patch fixes a probem that affects systems using databases with the btree
file format.  Only applications using btree in libdb.a or libdb.so are affected
and they may return incorrect data or crash.

This bug is not easily reproducible. The btree bug can be observed in large
database applications that sometimes crash or access incorrect data.


FILE(s):

/usr/ccs/lib/libdb.a            subset OSFLIBA400
<hr><br>
<font color=black size=+1>This patch can be found at any of these sites:</font><p>
<a name=colorado>
<a href=http://ftp1.support.compaq.com/public/unix/v4.0/duv40as00006-19980610.README>Colorado Site</a><br>
<a name=georgia>
<a href=http://ftp11.support.compaq.com/public/unix/v4.0/duv40as00006-19980610.README>Georgia Site</a><br>
<a name=europe>
<a href=http://ftp.service.digital.co.uk/public/unix/v4.0/duv40as00006-19980610.README>European Site</a><p>
<hr><br>
<font color=black size=+1>Files on this server are as follows:</font><p>
<pre>
<a href=/public/unix/v4.0/duv40as00006-19980610.README>duv40as00006-19980610.README</a>
<a href=/public/unix/v4.0/duv40as00006-19980610.CHKSUM>duv40as00006-19980610.CHKSUM</a>
<a href=/public/unix/v4.0/duv40as00006-19980610.tar>duv40as00006-19980610.tar</a>
<a href=/public/unix/v4.0/duv40as00006-19980610.ps>duv40as00006-19980610.ps</a>
</pre>
<!-- INSERT YOUR CONTENT ABOVE THIS POINT-->

        </td>
        </tr>
		<tr><td><br></td></tr>
        </table>
        </div>
		
		</td>
		<!-- End content column -->
<!--End main body content area-->

	</TR>
</TABLE>
<!-- End body table -->

<!--The include file below contains footer information that is common to all support pages-->
<!-- begin footer universal include -->
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" WIDTH="388">
	<TR>	
		<TD BGCOLOR="#000033"><IMG align=bottom  border=0 height=30 src="/images/spacer.gif" width=388></TD>
	</TR>
</TABLE>
<FONT FACE="verdana, arial, helvetica" SIZE="1"><A href="http://www.compaq.com/copyright.html">privacy and legal statement</A></FONT>
<!-- rev03.29.1999 -- DO NOT MODIFY! -- End universal footer -->
<BR CLEAR="all">
<IMG border=0 height=20 src="/images/spacer.gif" width=1>
<!-- end footer universal include -->





</BODY>
</HTML>