All Patches for PowerMAX 4.3 are:

1553v5drv-001   cnd-008         egl-002         inet-011        nsu-004         
1553v5drv-002   crosslibs-001   egl-003         inet-012        nsu-005         
1553v5drv-003   crosslibs-002   egl-004         inet-013        nsu-006         
1553v5drv-004   crosslibs-003   egl-005         inet-014        oam-001         
1553v5lib-001   crosslibs-004   egl-006         ip-001          pg-001          
1553v5lib-002   crosslibs-005   fbs-001         ip-002          pg-002          
base-001        crosslibs-006   fbs-002         ip-003          pg-003          
base-002        crosslibs-007   fbs-003         ip-004          pg-004          
base-003        crypt-001       fbs-004         ip-005          pg-005          
base-004        crypt-002       fbs-005         ip-006          pg-006          
base-005        crypt-003       fbs-006         is-001          pg-007          
base-006        crypt-004       fbs-007         ise-001         pg-008          
base-007        crypt-005       fbsman-001      kdb-001         rmxf-001        
base-008        crypt-006       fbsman-002      librt-001       rpc-001         
base-009        crypt-007       fbsman-003      man-001         rpc-002         
base-010        crypt-008       fibre-001       man-002         rpc-003         
base-011        crypt-int-001   fibre-002       man-003         rpc-005         
base-012        crypt-int-002   fibre-003       man-004         rvsrv-001       
base-013        crypt-int-003   fibre-004       man-005         softint-001     
base-014        crypt-int-004   fibre-005       man-006         softint-002     
base-015        crypt-int-005   gf-001          man-007         softint-003     
base-016        crypt-int-006   gpib-001        man-008         softint-004     
cld-001         crypt-int-007   hsde-001        man-009         trace-001       
cmds-001        dec-001         hsde-002        man-010         trace-002       
cmds-002        dec-002         ide-001         man-011         trace-003       
cmds-003        dec-003         ide-002         man-012         trace-004       
cmds-004        dec-004         ide-003         man-013         trace-005       
cmds-005        dec-005         ie-001          mvc-001         trace-006       
cmds-006        dec-006         ie-002          mvc-002         trace-007       
cmds-007        dec-007         ie-003          mvc-003         trace-008       
cmds-008        dec-008         ie-004          ncr-001         trace-009       
cmds-009        diskless-001    ie-005          ncr-002         via-001         
cmds-010        diskless-002    inet-001        ncr-003         via-002         
cmds-011        diskless-003    inet-002        netcmds-001     via-003         
cmds-012        diskless-004    inet-003        nfs-001         via-004         
cnd-001         diskless-005    inet-004        nfs-002         vmet-001        
cnd-002         diskless-006    inet-005        nfs-003         vp-001          
cnd-003         diskless-007    inet-006        nfs-004         xfsd-001        
cnd-004         diskless-008    inet-007        ngpib-001       xfsd-002        
cnd-005         diskless-009    inet-008        nsu-001                         
cnd-006         diskless-010    inet-009        nsu-002                         
cnd-007         egl-001         inet-010        nsu-003                         

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


              Concurrent Computer Corporation Software Development
                            Software Patch Report

 ##############################################################################

 Patch Name:           1553v5drv-001
 Date Issued:          02/02/2000 13:21:42
 Software Package:     1553v5drv pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640
 Related Patches:      1553v5lib-001
 Related SARs:         #HM12681
 
 Brief Description:

      PowerMAX OS 4.3 1553v5drv package release updates
 
 ##############################################################################

 Problem Description:
      
      1.  HM12681:  The SBS ABI1553V5 driver was not allowing the use of 32 RTs
	  (remote terminals) and 31 SAs (subaddresses).

 Problem Resolution: 
      
      1.  For one channel board, do not split the on-board memory anymore, so
	  the channel can use all the memory. For two-channel board, divide the
	  on-board memory in such a way that the first channel will have enough
	  memory to define all 32 RTs.
 
 Enhancements:
      
      None.
 
 Object(s) To Be Replaced: 
      
      /usr/include/1553v5drv/abi_type.h
      /usr/lib/lib1553v5drv.a

 Special Conditions for Installation: 
      
      None.
 
 Possible Side Effects: 
      
      None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 ##############################################################################

 Patch Name:           1553v5drv-001
 Date Issued:          02/02/2000 11:30:50
 Software Package:     1553v5drv pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6200/6800, PowerMAXION, TurboHawk
 Related Patches:      1553v5lib-001
 Related SARs:         #HM12681
 
 Brief Description:

      PowerMAX OS 4.3 1553v5drv package release updates
 
 ##############################################################################

 Problem Description:
      
      1.  HM12681:  The SBS ABI1553V5 driver was not allowing the use of 32 RTs
	  (remote terminals) and 31 SAs (subaddresses).

 Problem Resolution: 
      
      1.  For one channel board, do not split the on-board memory anymore, so
	  the channel can use all the memory. For two-channel board, divide the
	  on-board memory in such a way that the first channel will have enough
	  memory to define all 32 RTs.
 
 Enhancements:
      
      None.
 
 Object(s) To Be Replaced: 
      
      /usr/include/1553v5drv/abi_type.h
      /usr/lib/lib1553v5drv.a

 Special Conditions for Installation: 
      
      None.
 
 Possible Side Effects: 
      
      None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 Patch Name:           1553v5drv-002
 Date Issued:          09/21/2001 16:44:37
 Software Package:     1553v5drv pkg (Version 4.3)
 OS Release:           PowerMAX_OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640, PowerStack II/III, Motorola MCP750
 Related Patches:      base-008
 Related SARs:         #533
 Defect Tickets:       none
 
 Brief Description:

	PowerMAX_OS 4.3 1553v5drv package release updates
 
 Problem Description:

	1. When running the same application, the SBS 1553 controller
           "Rev R" board would hang intermittantly in the middle of a BCRT
           transfer whereas the "Rev P" board would not. The bus had to be
           reset after each hang.

           The problem would show up when using the Multi-function Display 
	   Unit (MFD) as the RT...not when simulating the MFD as an RT on 
	   a second board device.

 Problem Resolution: 

	1. Upgraded the 1553 firmware from f008c.dat and f009c.dat to
           f008f.dat and f009f.dat, respectively.
 
 Enhancements:

	None
 
 Object(s) To Be Replaced: 

	/usr/src/drivers/1553v5drv/firmware/f008f.dat
	/usr/src/drivers/1553v5drv/firmware/f009f.dat
	/usr/src/drivers/1553v5drv/firmware/firmware.cfg

 Special Conditions for Installation: 

	None.
 
 Possible Side Effects: 

	None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 Patch Name:           1553v5drv-002
 Date Issued:          09/28/2001 15:26:51
 Software Package:     1553v5drv pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6200/6800, PowerMAXION-4/8, TurboHawk
 Related Patches:      base-008
 Related SARs:         #533
 Defect Tickets:       none
 
 Brief Description:

	PowerMAX OS 4.3 1553v5drv package release updates
 
 Problem Description:

	1. When running the same application, the SBS 1553 controller
           "Rev R" board would hang intermittantly in the middle of a BCRT
           transfer whereas the "Rev P" board would not. The bus had to be
           reset after each hang.

           The problem would show up when using the Multi-function Display Unit
           (MFD) as the RT...not when simulating the MFD as an RT on a second
           board device.

 Problem Resolution: 

	1. Upgraded the 1553 firmware from f008c.dat and f009c.dat to
           f008f.dat and f009f.dat, respectively.
 
 Enhancements:

	None
 
 Object(s) To Be Replaced: 

	/usr/src/drivers/1553v5drv/firmware/f008f.dat
	/usr/src/drivers/1553v5drv/firmware/f009f.dat
	/usr/src/drivers/1553v5drv/firmware/firmware.cfg


 Special Conditions for Installation: 

	None.
 
 Possible Side Effects: 

	None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                        Software Service Release Report
	
##############################################################################
 Software Update Name: 1553v5drv-003
 Date Issued:          07/10/2002 14:43:32
 Software Package:     1553v5drv pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640, PowerStack II/III, Motorola MCP750
 Related Packages:     base-011
 Related SARs:         #644
 
 Brief Description:

      PowerMAX OS 4.3 1553v5drv package release updates
##############################################################################

 P1:  SAR #644: The 1553v5drv(7) manpage gave incorrect information with
      respect to the VME address to supply to the abiconfig utility for
      PowerHawk systems other than the Model 610.

 R1:  The 1553v5drv(7) manpage is modified to give the correct information
      with respect to the VME address to supply to the abiconfig utility for
      PowerHawk systems other than the Model 610.
 
 Enhancements:

	None.
 
 Object(s) To Be Replaced: 

	/usr/share/man/cat7/1553v5drv.7.z
	/usr/share/man/man7/1553v5drv.7

 Special Conditions for Installation: 

	None.
 
 Possible Side Effects: 

	None.
                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
###############################################################################
 Patch Name:           1553v5drv-003
 Date Issued:          07/24/2002 14:35:44
 Software Package:     1553v5drv pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6800, PowerMAXION, TurboHawk
 Related Patches:      base-011
 Related SARs:         #644
 
 Brief Description:

	PowerMAX OS 4.3 1553v5drv package release updates
###############################################################################
 
 P1:  SAR #644: The 1553v5drv(7) manpage gave incorrect information with
      respect to the VME address to supply to the abiconfig utility for
      PowerHawk systems other than the Model 610.

 R1:  The 1553v5drv(7) manpage is modified to give the correct information
      with respect to the VME address to supply to the abiconfig utility for
      PowerHawk systems other than the Model 610.

 Enhancements:

	None.
 
 Object(s) To Be Replaced: 

	/usr/share/man/cat7/1553v5drv.7.z
	/usr/share/man/man7/1553v5drv.7

 Special Conditions for Installation: 

	None.
 
 Possible Side Effects: 

	None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
###############################################################################
 Patch Name:           1553v5drv-004
 Date Issued:          01/07/2004 15:56:01
 Software Package:     1553v5drv pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640, PowerStack II/III, Motorola MCP750
 Related Patches:      base-014
 
 Brief Description: PowerMAX OS 4.3 1553v5drv package release updates
###############################################################################
 README format has changed. There will no longer be separate subsections for 
 "Problem Description:" or "Problem Resolution:". The new format will be 
 P#(Problem) followed by R#(Resolution) one after the other in 1 subsection.
###############################################################################

   P1:  SAR 1549:  The C++ compiler produced many warnings when compiling 
	the 1553V5 example programs, while the C compiler did not.  Working 
	executables were produced.

   R1:  Added -w, supress warnings, to the CFLAGS variable in the 
	examples Makefile.

 Enhancements:

	None.
 
 Object(s) To Be Replaced: 

	/usr/include/1553v5drv/abi.h

 Special Conditions for Installation: 

	None.
 
 Possible Side Effects: 

	None.
                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
###############################################################################
 Patch Name:           1553v5drv-004
 Date Issued:          01/07/2004 15:56:22
 Software Package:     1553v5drv pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6800, PowerMAXION, TurboHawk
 Related Patches:      base-014
 
 Brief Description: PowerMAX OS 4.3 1553v5drv package release updates
###############################################################################
 README format has changed. There will no longer be separate subsections for
 "Problem Description:" or "Problem Resolution:". The new format will be
 P#(Problem) followed by R#(Resolution) one after the other in 1 subsection.
###############################################################################

   P1:  SAR 1549:  The C++ compiler produced many warnings when compiling
        the 1553V5 example programs, while the C compiler did not.  Working
        executables were produced.

   R1:  Added -w, supress warnings, to the CFLAGS variable in the
        examples Makefile.

 Enhancements:

        None.

 Object(s) To Be Replaced:

        /usr/include/1553v5drv/abi.h

 Special Conditions for Installation:

        None.

 Possible Side Effects:

        None.
                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report

 ##############################################################################

 Patch Name:           1553v5lib-001
 Date Issued:          02/02/2000 13:22:31
 Software Package:     1553v5lib pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640
 Related Patches:      1553v5drv-001
 Related SARs:         #25, HM12681

 Brief Description:

      PowerMAX OS 4.3 1553v5lib package release updates
 
 ##############################################################################
 
 Problem Description:
      
      1.  #25:  The 48bit, 1 micro second resolution timer of CE1092 1553
	  Interface board was cleared (reset) every 10 - 20 msec.

      2.  HM12681:  The SBS ABI1553V5 driver was not allowing the use of 32 RTs
	  (remote terminals) and 31 SAs (subaddresses).

 Problem Resolution: 
      
      1.  Revised the SBS library code to allow user application program to
	  clear the timer.

      2.  For one channel boards, do not split the on-board memory anymore, so
	  the channel can use all the memory. For two-channel boards, divide
	  the on-board memory in such a way that the first channel will have
	  enough memory to define all 32 RTs.
 
 Enhancements:
      
      None.
 
 Object(s) To Be Replaced: 
      
      /usr/lib/lib1553v5lib.a

 Special Conditions for Installation: 
      
      None.
 
 Possible Side Effects: 
      
      None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 ##############################################################################

 Patch Name:           1553v5lib-001
 Date Issued:          02/02/2000 11:31:58
 Software Package:     1553v5lib pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6200/6800, PowerMAXION, TurboHawk
 Related Patches:      1553v5drv-001
 Related SARs:         #25, HM12681
 
 Brief Description:

      PowerMAX OS 4.3 1553v5lib package release updates
 
 ##############################################################################

 Problem Description:
      
      1.  #25:  The 48bit, 1 micro second resolution timer of CE1092 1553
	  Interface board was cleared (reset) every 10 - 20 msec.

      2.  HM12681:  The SBS ABI1553V5 driver was not allowing the use of 32 RTs
	  (remote terminals) and 31 SAs (subaddresses).

 Problem Resolution: 
      
      1.  Revised the SBS library code to allow user application program to
	  clear the timer.

      2.  For one channel boards, do not split the on-board memory anymore, so
	  the channel can use all the memory. For two-channel boards, divide
	  the on-board memory in such a way that the first channel will have
	  enough memory to define all 32 RTs.
 
 Enhancements:
      
      None.
 
 Object(s) To Be Replaced: 
      
      /usr/lib/lib1553v5lib.a

 Special Conditions for Installation: 
      
      None.
 
 Possible Side Effects: 
      
      None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
###############################################################################

	
 Patch Name:           1553v5lib-002
 Date Issued:          01/07/2004 15:56:11
 Software Package:     1553v5lib pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640, PowerStack II/III, Motorola MCP750
 Related Patches:      base-014
 
 Brief Description:
	PowerMAX OS 4.3 1553v5lib package release updates
###############################################################################
 README format has changed. There will no longer be separate subsections for
 "Problem Description:" or "Problem Resolution:". The new format will be
 P#(Problem) followed by R#(Resolution) one after the other in 1 subsection.
###############################################################################

   P1:  SAR 1549:  The C++ compiler produced many warnings when compiling
        the 1553V5 example programs, while the C compiler did not.  Working
        executables were produced.

   R1:  Added -w, supress warnings, to the CFLAGS variable in the
        examples Makefile.

 Enhancements:

        None.

 Object(s) To Be Replaced: 

	/usr/src/drivers/1553v5lib/examples/Makefile

 Special Conditions for Installation: 

	None.
 
 Possible Side Effects: 

	None.
                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
###############################################################################
 Patch Name:           1553v5lib-002
 Date Issued:          01/07/2004 15:56:34
 Software Package:     1553v5lib pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6800, PowerMAXION, TurboHawk
 Related Patches:      base-014
 
 Brief Description: PowerMAX OS 4.3 1553v5lib package release updates
###############################################################################
 README format has changed. There will no longer be separate subsections for
 "Problem Description:" or "Problem Resolution:". The new format will be
 P#(Problem) followed by R#(Resolution) one after the other in 1 subsection.
###############################################################################

  P1:  SAR 1549:  The C++ compiler produced many warnings when compiling
        the 1553V5 example programs, while the C compiler did not.  Working
        executables were produced.

   R1:  Added -w, supress warnings, to the CFLAGS variable in the
        examples Makefile.

 Enhancements:

        None.

 Object(s) To Be Replaced:

	/usr/src/drivers/1553v5lib/examples/Makefile

Special Conditions for Installation:

	None.
 
 Possible Side Effects: 

	None.
                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report

 ##############################################################################
 
 Patch Name:           base-001
 Date Issued:          09/15/1999 10:41:57
 Software Package:     base pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640, PowerStack II, Motorola MCP750
 Related Patches:      diskless-001, trace-001, ip (4.3)
 Related SARs:         HM12641, HM12685, HM12673 
 
 Brief Description:

      PowerMAX OS 4.3 base package release updates

 ##############################################################################
 
 PowerMAX OS 4.3 Patch Set 1
 ---------------------------

 Patches for PowerMAX OS are now released officially as "Patch Sets".  A patch
 set is a collection of patches released simultaneously.  Individual patches
 may have dependencies on other patches included in a patch set.  Not all 
 patches in a "Patch Set" may be available/applicable on all supported
 platforms.  It is important to install all applicable patches in order to
 ensure proper system operation.

 "4.3P1" is the abbreviated name for "PowerMAX OS 4.3 Patch Set 1".

 New PowerMAX OS 4.3 Software Patch(es):
 
      base-001       Base System Patch 001
      cmds-001       Advanced Commands Patch 001
      cnd-001        Condor Ethernet Driver Patch 001
      diskless-001   Diskless Systems Package Patch 001
      fbs-001        Frequency Based Scheduler Patch 001
      man-001">fbsman-001     Frequency Based Scheduler On-line Manual Pages Patch 001
      fibre-001      Fibre Channel Driver Patch 001
      ide-001        Internal IDE/ATA Disk Controller Patch 001
      inet-001       Internet Utilities Patch 001
      kdb-001        Kernel Debugger Patch 001
      man-001        On-line Manual Pages Patch 001
      nsu-001        Network Support Utilities Patch 001
      trace-001      KernelTrace Utilities Patch 001

 New PowerMAX OS 4.3 Software Package(s):

      ip             Interphase 4511 PMC FDDI Driver

 Note:  The "ip" package is currently only supported on the Power Hawk 620.

 ##############################################################################
 
 Problem Description:

      1.  HM12641:  Setting the PATH environment variable to NULL prior to
	  invocation of the idbuild(1M) or idtune(1M) utilities will result in
	  failure of those utilities.

      2.  The config(1M) utility aborts when searching for a kernel module
	  using the "Find by Keyword" operation.

      3.  HM12685:  The config(1M) utility aborts when displaying all tunables
	  using the "All Tunables" operation.

      4.  HM12673:  The IPC maximum number of semaphores per id is a hard-coded
	  value.  This should be modifiable as a system tunable.

      5.  The metrics calculations done in the kma and kmadbg modules during
	  allocations and deallocations of kernel virtual space were not
	  protected by locks or atomic operations.  Updates of these counters
	  could be lost if the same counter were being updated on different
	  CPUs or the update was interrupted by a higher priority function that
	  also requests an allocation or deallocation.  This could cause the
	  data returned by sar(1M) (`sar -k`) to be inaccurate.

      6.  The debug version of kernel space allocator was calling cmn_err()
	  with the kmacorrupt_lock locked.  cmn_err() was called to add an
	  informational message to the syslog that it was turning the detection
	  of "use-after-free" problems back on after it had previously been
	  turned off upon reaching the limits specified by the tunables
	  KMEM_LIMIT_UPPER and KMEM_LIMIT_LOWER.  Because cmn_err() also calls
	  the allocator, the system would hang forever trying to take the same
	  lock again.

      7.  strip(1) removed the symbol table of shared libraries.

      8.  pthread_self(3pthread), pthread_cleanup_push(3pthread), and 
	  pthread_cleanup_pop(3pthread) were not visible to c++ standard users.
       
      9.  There were instances when linking c++ programs where the .bss section
	  would end up with an odd number size.

     10.  Some snmp trap definitions were missing from <snmp/snmp_trap.h>.

     11.  The syscx(INT_VECTOR, ..) service would always return failure
	  condition on Power Hawk 640's even when passed a valid interrupt
	  vector.

	  The result is that it would be unable to determine which CPU an
	  interrupt vector is assigned to.  It would also result in a failure
	  when using the mpadvise(MPA_CPU_INTVEC) library routine.

     12.  Small timing windows in RCIM (real-time clock and interrupt module)
	  driver.  Evident when doing substantial simultaneous RCIM ETI
	  activity.

     13.  When ktrace(1) enables timing using RCIM clock, it could have a bad
	  effect on various system timing routines leading to failures.

     14.  Minor problems in clock_synchronize(1M) when using "interactive" mode.

     15.  On MTX604-070 systems, the PowerStack II system with 7 PCI slots, PCI
	  slots 0, 1, and 2 are functional but PCI slots 3, 4, 5, and 6 are not.

 Problem Resolution: 

      1.  The idbuild(1M) and idtune(1M) utilities were modified to define and
	  export the minimum PATH needed to execute successfully upon
	  invocation, returning the PATH to its original setting upon
	  completion.

      2.  Made config(1M) more robust in its handling of ill-formed module
	  descriptions and tunable descriptions.
 
      3.  Increased the number of tunables that config can display using
	  "All Tunables" operation.  Also, fixed so that utility doesn't abort
	  when this tunable limit is reached.
 
      4.  Added system tunable SEMMSL.
 
      5.  The macros used by the kma and kmadbg modules to increment and
	  decrement the metrics counters were not protected by locks or by the
	  use of the atomic increment/decrement functions.  The macros used by
	  these modules in <sys/metrics.h> were modified to use the atomic
	  increment and decrement functions.
        
      6.  kmem_alloc_debug() was changed to unlock the kmacorrupt_lock before
	  it calls cmn_err().
        
      7.  Fixed strip so that it does not remove the symbol table when
	  stripping a shared library.

      8.  Fixed header file <pthread.h> so that pthread_self,
	  pthread_cleanup_push, pthread_cleanup_pop are also visible to c++
	  standard users.

      9.  Fixed 'ld' so that in such occurences .bss is always rounded to next
	  16 bytes.

     10.  Added additional snmp trap definitions to <snmp/snmp_trap.h>.
    
     11.  Corrected Power Hawk 640 version of the system service that returns
	  CPU assignment for an interrupt vector.
 
     12.  Closed timing windows in RCIM driver.

     13.  Fixed so that RCIM clock is only used for trace purposes and not
	  other internal kernel timing functions. 

     14.  Corrected clock_synchronize(1M) utility. 
 
     15.  The kernel was modified to support the interrupt map defined by the
	  MTX604-070's Raven MPIC.

 Enhancements:
 
      1.  Added new attributes and tags to DWARF information used to provide
	  debug information for applications:

		a)  Added new attribute for phase3.2 of the MAXAda compiler:

			DW_AT_child_unit

		b)  Added new tag for phase4 of the MAXAda compiler:   

			DW_TAG_inst_package_param

		c)  Added new attributes to provide additional information about
		    inline calls in both the MAXAda and c++ compilers.
		    NightView will use this information to provide "virtual
		    walkback" information.  The attributes are:

			DW_AT_call_column
			DW_AT_call_file
			DW_AT_call_line

      2.  Added definition to <sys/adapter_pci.h> for ADAPTER_IP, which is
	  required to support the "ip" software package in PowerMAX OS 4.3.
	  The "ip" driver supports the Interphase PMC/PCI based 4511/5511 FDDI
	  adapters.  The "ip" package is currently only supported on the
	  Power Hawk 620 platform.

 Object(s) To Be Replaced: 

      /etc/conf/bin/idbuild
      /etc/conf/bin/idtune
      /etc/conf/mtune.d/ipc
      /etc/conf/pack.d/bsp4600/Driver.o
      /etc/conf/pack.d/bspall/Driver.o
      /etc/conf/pack.d/bspmtx/Driver.o
      /etc/conf/pack.d/ipc/space.c
      /etc/conf/pack.d/kma/Driver.o
      /etc/conf/pack.d/kmadbg/Driver.o
      /etc/conf/pack.d/name/Driver.o
      /etc/conf/pack.d/rcim/Driver.o
      /etc/conf/pack.d/svc/Driver.o
      /sbin/config
      /usr/ccs/bin/dump
      /usr/ccs/bin/ld
      /usr/ccs/bin/strip
      /usr/ccs/lib/libdwarf.a
      /usr/include/dwarfwrite.h
      /usr/include/libdwarf.h
      /usr/include/pthread.h
      /usr/include/snmp/snmp_trap.h
      /usr/include/sys/adapter_pci.h
      /usr/include/sys/metrics.h
      /usr/sbin/clock_synchronize

 Special Conditions for Installation: 

      1.  The following additional object will be replaced by base-001:

		*  /usr/bin/idld
 
 Possible Side Effects: 

      None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 ##############################################################################

 Patch Name:           base-001
 Date Issued:          09/15/1999 12:53:54
 Software Package:     base pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6200/6800, TurboHawk, PowerMAXION
 Related Patches:      none
 Related SARs:         HM12641, HM12685, HM12673 
 
 Brief Description:

      PowerMAX OS 4.3 base package release updates
 
 ##############################################################################

 PowerMAX OS 4.3 Patch Set 1
 ---------------------------

 Patches for PowerMAX OS are now released officially as "Patch Sets".  A patch
 set is a collection of patches released simultaneously.  Individual patches
 may have dependencies on other patches included in a patch set.  Not all 
 patches in a "Patch Set" may be available/applicable on all supported
 platforms.  It is important to install all applicable patches in order to
 ensure proper system operation.

 "4.3P1" is the abbreviated name for "PowerMAX OS 4.3 Patch Set 1".

 New PowerMAX OS 4.3 Software Patch(es):

      base-001       Base System Patch 001
      cmds-001       Advanced Commands Patch 001
      cnd-001        Condor Ethernet Driver Patch 001
      fbs-001        Frequency Based Scheduler Patch 001
      man-001">fbsman-001     Frequency Based Scheduler On-line Manual Pages Patch 001
      inet-001       Internet Utilities Patch 001
      kdb-001        Kernel Debugger Patch 001
      man-001        On-line Manual Pages Patch 001
      nsu-001        Network Support Utilities Patch 001
      trace-001      KernelTrace Utilities Patch 001

 ##############################################################################

 Problem Description:

      1.  HM12641:  Setting the PATH environment variable to NULL prior to
	  invocation of the idbuild(1M) or idtune(1M) utilities will result in
	  failure of those utilities.

      2.  The config(1M) utility aborts when searching for a kernel module
	  using the "Find by Keyword" operation.

      3.  HM12685:  The config(1M) utility aborts when displaying all tunables
	  using the "All Tunables" operation.

      4.  HM12673:  The IPC maximum number of semaphores per id is a hard-coded
	  value.  This should be modifiable as a system tunable.

      5.  The metrics calculations done in the kma and kmadbg modules during
	  allocations and deallocations of kernel virtual space were not
	  protected by locks or atomic operations.  Updates of these counters
	  could be lost if the same counter were being updated on different
	  CPUs or the update was interrupted by a higher priority function that
	  also requests an allocation or deallocation.  This could cause the
	  data returned by sar(1M) (`sar -k`) to be inaccurate.

      6.  The debug version of kernel space allocator was calling cmn_err()
	  with the kmacorrupt_lock locked.  cmn_err() was called to add an
	  informational message to the syslog that it was turning the detection
	  of "use-after-free" problems back on after it had previously been
	  turned off upon reaching the limits specified by the tunables
	  KMEM_LIMIT_UPPER and KMEM_LIMIT_LOWER.  Because cmn_err() also calls
	  the allocator, the system would hang forever trying to take the same
	  lock again.

      7.  strip(1) removed the symbol table of shared libraries.

      8.  pthread_self(3pthread), pthread_cleanup_push(3pthread), and 
	  pthread_cleanup_pop(3pthread) were not visible to c++ standard users.
       
      9.  There were instances when linking c++ programs where the .bss section
	  would end up with an odd number size.

     10.  Some snmp trap definitions were missing from <snmp/snmp_trap.h>.

     11.  Due to chip erratas, 'sync' instructions are required in the internal
	  kernel lock and atomic operations.  The TurboHawk uses the 'Mach5'
	  processor and does not require these instructions.  'sync'
	  instructions can have a substantial effect on overall system
	  performance.

     12.  The NCR SCSI controller was generating stray interrupts on TurboHawk
	  systems with 8 processors and 2 global memory boards.  The stray
	  interrupts were seen under the system level I/O test, PowerIO, when
	  the edge trigger interrupts were being exercised.  This problem
	  prevents configuring system disks on the global memory boards.

 Problem Resolution: 
 
      1.  The idbuild(1M) and idtune(1M) utilities were modified to define and
	  export the minimum PATH needed to execute successfully upon
	  invocation, returning the PATH to its original setting upon
	  completion.

      2.  Made config(1M) more robust in its handling of ill-formed module
	  descriptions and tunable descriptions.
 
      3.  Increased the number of tunables that config can display using
	  "All Tunables" operation.  Also, fixed so that utility doesn't abort
	  when this tunable limit is reached.
 
      4.  Added system tunable SEMMSL.
 
      5.  The macros used by the kma and kmadbg modules to increment and
	  decrement the metrics counters were not protected by locks or by the
	  use of the atomic increment/decrement functions.  The macros used by
	  these modules in <sys/metrics.h> were modified to use the atomic
	  increment and decrement functions.
        
      6.  kmem_alloc_debug() was changed to unlock the kmacorrupt_lock before
	  it calls cmn_err().
        
      7.  Fixed strip so that it does not remove the symbol table when
	  stripping a shared library.

      8.  Fixed header file <pthread.h> so that pthread_self,
	  pthread_cleanup_push, pthread_cleanup_pop are also visible to c++
	  standard users.

      9.  Fixed 'ld' so that in such occurences .bss is always rounded to next
	  16 bytes.

     10.  Added additional snmp trap definitions to <snmp/snmp_trap.h>.
    
     11.  At start-up time, the unnecessary 'sync' instructions are patched to
	  'nop' instructions if running on a TurboHawk.
 
     12.  The interrupt request function used by PowerMAX OS was not being
	  implemented properly.  In this case the edge trigger interrupt tests
	  were using the interrupt request function to activate an edge trigger
	  interrupt.  The interrupt request function was performing a
	  read-modify-write operation to the interrupt controller's request
	  register.  The function should have been performing a single bit
	  write to the request register.  

 Enhancements:
 
      1.  Added new attributes and tags to DWARF information used to provide
	  debug information for applications:

		a)  Added new attribute for phase3.2 of the MAXAda compiler:

			DW_AT_child_unit

		b)  Added new tag for phase4 of the MAXAda compiler:   

			DW_TAG_inst_package_param

		c)  Added new attributes to provide additional information about
		    inline calls in both the MAXAda and c++ compilers. 
		    NightView will use this information to provide "virtual
		    walkback" information.  The attributes are:

			DW_AT_call_column
			DW_AT_call_file
			DW_AT_call_line

      2.  Added definition to <sys/adapter_pci.h> for ADAPTER_IP.

 Object(s) To Be Replaced: 

      /etc/conf/bin/idbuild
      /etc/conf/bin/idtune
      /etc/conf/mtune.d/ipc
      /etc/conf/pack.d/bsp6800t/Driver.o
      /etc/conf/pack.d/bspall/Driver.o
      /etc/conf/pack.d/ipc/space.c
      /etc/conf/pack.d/kma/Driver.o
      /etc/conf/pack.d/kmadbg/Driver.o
      /etc/conf/pack.d/name/Driver.o
      /etc/conf/pack.d/util/Driver.o
      /sbin/config
      /usr/ccs/bin/dump
      /usr/ccs/bin/ld
      /usr/ccs/bin/strip
      /usr/ccs/lib/libdwarf.a
      /usr/include/dwarfwrite.h
      /usr/include/libdwarf.h
      /usr/include/pthread.h
      /usr/include/snmp/snmp_trap.h
      /usr/include/sys/adapter_pci.h
      /usr/include/sys/metrics.h

 Special Conditions for Installation: 

      1.  The following additional object will be replaced by base-001:

		*  /usr/bin/idld
 
 Possible Side Effects: 

      None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 ##############################################################################

 Patch Name:           base-002
 Date Issued:          02/02/2000 13:36:17
 Software Package:     base pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640, PowerStack II, Motorola MCP750
 Related Patches:      cnd-002, crosslibs-001, crypt-001, crypt-int-001,
		       dec-001, egl-001, fbs-002, man-002">fbsman-002, inet-002, ip-001,
		       librt-001, man-002, mvc-001, pg-001
 Related SARs:         #39, #45, #59, #72, #98, #103, #114, #116, #117, #166 
 
 Brief Description:

      PowerMAX OS 4.3 base package release updates
 
 ##############################################################################

 PowerMAX OS 4.3 Patch Set 2
 ---------------------------

 Patches for PowerMAX OS are now released officially as "Patch Sets".  A patch
 set is a collection of patches released simultaneously.  Individual patches
 may have dependencies on other patches included in a patch set.  Not all
 patches in a "Patch Set" may be available/applicable on all supported
 platforms.  It is important to install all applicable patches in order to
 ensure proper system operation.

 "4.3P2" is the abbreviated name for "PowerMAX OS 4.3 Patch Set 2".

 New PowerMAX OS 4.3 Software Patch(es):

      1553v5drv-001	1553v5-ABI User Level Driver Patch 001 (4.3P2)
      1553v5lib-001	1553v5-ABI Library Interfaces Patch 001 (4.3P2)
      base-002		Base System Patch 002 (4.3P2)
      cld-001		MPEG-2 Decoder Driver Patch 001 (4.3P2)
      cmds-002		Advanced Commands Patch 002 (4.3P2)
      cnd-002		Condor Ethernet Driver Patch 002 (4.3P2)
      crosslibs-001	Libraries for Cross Compiling Patch 001 (4.3P2)
      crypt-001		Domestic Encryption Utilities Patch 001 (4.3P2)
      crypt-int-001	International Encryption Utilities Patch 001 (4.3P2)
      dec-001		DEC Ethernet Driver Patch 001 (4.3P2)
      diskless-002	Diskless Systems Package Patch 002 (4.3P2)
      egl-001		Eagle Ethernet Driver Patch 001 (4.3P2)
      fbs-002		Frequency Based Scheduler Patch 002 (4.3P2)
      man-002">fbsman-002	Frequency Based Scheduler On-line Manual Pages
				Patch 002 (4.3P2)
      hsde-001		High Speed Data Enhanced Channel Driver
				Patch 001 (4.3P2)
      inet-002		Internet Utilities Patch 002 (4.3P2)
      ip-001		Interphase 4511 PMC FDDI Driver Patch 001 (4.3P2)
      librt-001		Real-time Libraries Patch 001 (4.3P2)
      man-002		On-line Manual Pages Patch 002 (4.3P2)
      mvc-001		Multiplexor VME Controller Driver Patch 001 (4.3P2)
      pg-001		Peregrine FDDI Driver Patch 001 (4.3P2)
      trace-002		KernelTrace Utilities Patch 002 (4.3P2)

 %#############################################################################

 Problem Description:
      
      1.  Use of more expensive sync instructions affected the virtual memory
	  system performance.

      2.  The vi(1) tag facility was not handling duplicate tags properly.
	  vi is supposed to treat duplicate tags as a circular list. 
	  Successive `:ta' commands (with no argument) takes the user to the
	  next duplicate in the list in a roundrobin fashion.  Instead, once
	  the end of the list was reached, error messages would be printed for
	  all following `:ta' commands.

      3.  #116:  Using standard mvc ports, reads return immediately if
	  conditions satisfy the read (i.e., adequate data are available to be
	  returned).  Using mvcrt ports, the initial read would stall when the
	  read should have been satisfied.

	  Additionally, if VMIN=0 and VTIME>0, a read would always wait for the
	  timeout before returning, even when data were available to satisfy
	  the read.  To be correct, VTIME is the time for completion of the
	  read, rather than an intercharacter timer, if the read cannot
	  otherwise be satisfied.  The read should complete if either a single
	  character is read or if the timer expires (no characters returned).
 
      4.  #59:  The xdr_double() function contained in libnsl will return an
	  Arithmetic Exception error and dump core.

      5.  #166:  When using gethostbyname() that is statically linked, a
	  hostname that is opposite in case to one in the /etc/hosts file will
	  fail.  The dynamically linked use of gethostbyname will pass as it
	  should.

      6.  #98:  The system(3S) I/O function should use fork1(2) in
	  multi-threaded applications instead of fork(2).

      7.  In UFS filesystems, the modification times of two different files
	  might show that the clock was running backwards, which means that the
	  file modified earlier might have the more recent timestamp.

      8.  #114:  ksh(1) can't address directory when its size exceeds 2 Gbytes.
	  When using ksh to do integer arithmetic operation with command
	  expr(1), the upper limit for the integer is 2^31 + 1.

      9.  User-level interrupt routines are allowed to do only a limited number
	  of system calls.  Two are server_wake and server_wake1.  However, in
	  some cases, this can cause a process preemption which would panic the
	  system.  Preemption is not allowed while in a user-level interrupt
	  routine.

     10.  Confusing debug messages were being printed when a configured drive
	  was not found.

     11.  User-level interrupts with shared vector devices could cause memory
	  corruption.  Counters associated with shared vectors was being used
	  incorrectly.

     12.  #72:  Threads may returned too early from pthread_once(3pthread).
	  When more than one thread calls pthread_once() at roughly the same
	  time, the threads that are not the first caller do not wait until the
	  first caller thread completes its execution of the initialization
	  routine.

     13.  If a parent process creates one or more POSIX timers and then calls
	  fork(2) or fork1(2), the child process will terminate with an
	  internal libthread error if the child attempts to also create a POSIX
	  timer with timer_create(3C).

     14.  If a parent process creates a POSIX timer with timer_create(3C) and
	  specifies the SIGEV_CALLBACK option and then calls fork(2), the
	  background callback thread will incorrectly exit and remove that
	  POSIX timer from the parent process.

     15.  #117:  sigtimedwait(2) may cause other threads within a process to
	  terminate.  In a multi-threaded process, if one of the threads uses
	  sigtimedwait(2) to catch certain signals, and one of these signals is
	  already pending by the time that thread enters the kernel's
	  sigtimedwait() routine, then the kernel will destroy all the other
	  LWPs in this process if there is no signal catching routine setup to
	  catch this signal and if the default action for the pending signal is
	  to terminate the process.

     16.  It is possible to create a symbolic link on an XFS filesystem in a
	  directory to which the user does not have write permission.

     17.  The kernel may panic with the functions page_sortadd() and
	  xfscr_getpage() in the stack trace under certain XFS file overwrite
	  conditions.  The failure conditions depend on the length and offset
	  of the overwrite, the file disk space allocation boundries and the
	  state of the page cache.  The problem occurs when the overwrite
	  requires the physical read of part of the overwritten data and is due
	  to a fault in the read optimization code.

     18.  #39:  One byte SAPs were not processed correctly on FDDI causing the
	  destination SAP to be based on random user data.  This caused the
	  following problems:

		- data was thrown away even though a properly bound SAP existed

                - data was sent to the wrong SAP

                - the amount of data returned to the user was incorrect

     19.  #39:  The destination SAP specified in the DL_UNITDATA_REQ was being
	  ignored for two-byte SAP messages.  For the one-byte SAP case, it
	  always assumed that a destination SAP was specified in the
	  dl_unitdata_req_t even when it had not been.

     20.  #39:  Because both 802.2 and Ethernet II format messages are
	  supported by the PowerMAX OS Ethernet drivers, it is impossible to
	  support SAPs in the range 0x100 to 0x5dc correctly.  PowerMAX OS did
	  not report an error if SAPs in this range were used for DL_ETHER.

     21.  #39:  DL_TEST_REQ messages do not work correctly.

     22.  #39:  The mac_type field being returned by DL_INFO_REQ was
	  incorrectly set to DL_CSMACD instead of the board type (DL_ETHER or
	  DL_FDDI) if the DL_INFO_REQ was issued before it had done the bind to
	  the desired SAP.

     23.  #39:  Data packets were being dropped when using DLPI with network
	  buffers to achieve maximum throughput over 100BaseT dec Ethernet and
	  pg FDDI. 

     24.  #39:  When a VME device board (i.e pg FDDI) was configured at a
	  VMEIRQ level other than level 5 on a PowerHawk 620 or 640, the system
	  would either:

	 	- panic in the dmac interrupt routine dmac_intr()

	  	- hang CPU 0 and the console

	  when a large amount of data was transferred over the pg FDDI
	  interface at high rates.  These hangs and panics could also occur
	  when using other VME devices (i.e cnd).

     25.  #45:  The system would hang with an out of memory condition when
	  using SOCK_RAW sockets with RAWIP under the following conditions:

		1)  The destination host for the sender is the local system and
		    there is no receiver currently running.

		2)  The destination host for both the sender and receiver is
		    the local system and both tests are currently running.

 	  If the destination host(s) is not the local system (data is going
	  over the wire), the hang does not occur.

     26.  RCIM devices configured as distributed interrupts could only be used
	  as Closely Coupled FBS timing devices within the same Closely Coupled
	  cluster.

     27.  Setting the RCIM_ETI_LEVEL tunable causes system to hang with stray
	  interrupts.

     28.  The rcimconfig(1M) utility reports polarity incorrectly.

     29.  RCIM devices configured as distributed interrupts could only be used
	  as Closely Coupled FBS timing devices within the same Closely Coupled
	  cluster.

     30.  #103:  The console could not initialize VGA compatible mode on Matrox
	  G200 SD PCI card.  The console program (resident monitor/boot loader)
	  includes a VGATTY driver designed to use keyboard and VGA compatible
	  video card for console I/O during system initialization.  However,
	  this function relies on a small library of device-specific init
	  routines that can place the selected video card into a VGA compatible
	  mode.

 Problem Resolution: 
      
      1.  The more expensive sync instruction was replaced in some places with
	  the cheaper eieio instruction.

      2.  When the end of the list is reached, an error message is printed.
	  The following `:ta' then goes back to the first tage in the duplicate
	  tag list.

      3.  mvcrt ports, when opened for reading, now immediately issue a read
	  command, permitting the first read issued by the user to be
	  immediately satisfied when data is available.

	  The VMIN/VTIME code now correctly checks for available data before
	  waiting for the timeout when VMIN=0 and VTIME>0.
 
      4.  The problem was in casting the return value from xdr_double() to a
	  long when it should be cast to a long long.

      5.  A strcasecmp() function that was left out of the nametoaddr library
	  functions from a previous NIS change was restored to its proper
	  location.  Now a statically linked use of gethostbyname() will work
	  as expected. 

      6.  The system(3S) I/O function has been modified to use fork1(2) instead
	  of fork(2) for all applications.

      7.  A global timer is used to keep the more recent time between the
	  time-of-the-day clock and the last file timestamp assigned to any
	  file.  A new file timestamp is assigned based on the global timer.

      8.  Long long integer support has been added to command expr. Now the
	  command can do integer arithmetic operation beyond 2^32 (up to
	  2^63+1).

      9.  When returning from user-level interrupt routine, it will no longer
	  check for and take requested preemptions.  If there is a requested
	  preemption it will be handled after the UI routine completes.

     10.  Removed the messages.

     11.  Fix shared-vector code in user-level interrupt logic.

     12.  Block the other threads so that they do not return from
	  pthread_once() until the initialization routine has been completely
	  executed by the first caller thread.

     13.  The thread library's internal POSIX timer structures are now
	  re-initialized by the first thread that calls timer_create(3C) or
	  timer_delete(3C) within the child process.

     14.  The kernel and thread library code was modified so that fork
	  operations no longer cause the background callback thread to call
	  thr_exit(3thread) upon an interrupted return while waiting on a
	  POSIX timer expiration internally within the thread library.

     15.  Change the kernel's sigtimedwait() routine so that when a signal is
	  already pending, the calling LWP will simply return to the caller
	  with the selected signal number, without interfering with the other
	  LWPs in the same process.

     16.  A check of the user write permission added to the symbolic link
	  create code path.

     17.  The filesystem page read optimization is fixed to request the correct
	  pages for the overwrite boundary conditions.

     18.  The code was using the wrong message offsets to determine the
	  destination SAP for one-byte SAPs for both FDDI and Ethernet.
	  The format of the header for a one-byte SAP message is different than
	  a two-byte SAP message header.  This caused the destination SAP to be
	  based on random user data, which may or may not match one of the
	  bound SAPs.  The code now uses the actual message type (one-byte or
	  two-byte format) to process the message, instead of assuming the
	  message type based on the type of SAP that ends up as the primary
	  receiver (it may not be the same type as the message).  This can
	  occur if the promiscuous SAP is the only receiver.

     19.  The destination SAP specified in the unitdata_req was being ignored
	  for two-byte SAP messages.  For the one-byte SAP case, it always
	  assumed that a destination SAP was specified in the dl_unitdata_req_t
	  even when it had not been.  If a two-byte destination SAP was
	  incorrectly specified when the source was a one-byte SAP, it would
	  use the first byte of the two-byte SAP specified as the destination
	  instead of producing an error.  If a destination is not specified,
	  the destination SAP will now default to be the source SAP number. 
	  Both cases now check to make sure that the source and destination
	  SAPs are the same type (one-byte vs two-byte).
	  
     20.  For SAP numbers in the range 0x100 to DL_MAX_PACKET (= 0x5dc):

		- The sending side was formatting the message in the two-byte
		  SAP format.

		- The receiving side was interpreting it as a one-byte SAP
		  format.

	  When both 802.2 and Ethernet II format messages are supported, it is
	  impossible to support SAPs in the range 0x100 to 0x5dc correctly.
	  DLunitdata_req() was changed so it will not allow bind requests to
	  SAPS in the range 0x100 to 0x5dc.  It will now return an error,
	  rather than sending a message that cannot be interpreted correctly by
	  the receiving side.  This problem occurred only with the Ethernet
	  drivers.  FDDI uses different header format standards that allow a
	  message to be properly identified for all possible one and two-byte
	  SAP values.

     21.  A PowerMAX OS 4.3 change modified the order of the promiscous SAP on
	  the board's valid sap list (SAPs that have been bound to).  Prior to
	  PowerMAX OS 4.3, the NULL SAP (SAP 0) would be in the valid SAP list
	  immediately before the promiscous SAP.  With the change to 4.3, the
	  NULL SAP was placed in the list after the promiscous SAP.  This can
	  cause a difference in the SAP that is selected by DLrecv() to receive
	  the message.

	  DL_TEST_REQ messages do not work correctly on PowerMAX OS 4.3 with
	  this SAP ordering if there is a user bound to the promiscuous SAP.
	  The promiscuous SAP would be chosen as the primary recepient of the
	  message by DLrecv() instead of the proper destination one-byte SAP.
	  DLrsrv() was incorrectly processing the message as a two-byte SAP
	  header.  DLproc_llc() that handles the special processing for test
	  messages was never called. 

	  The ordering of the SAPs done by DLinsert_sap() was changed back to
	  the way it was prior to 4.3. (i.e NULL SAP then promiscuous SAP).
	  DLrsrv() was changed to allocate an indication message for the
	  TEST/XID cases if there is a SAP that wants to receive it in addition
	  to the primary destination SAP.  A user bound to the promiscuous SAP
	  will now receive all messages, including all test messages.

     22.  The mac_type field being returned by DL_INFO_REQ was incorrectly set
	  to DL_CSMACD instead of DL_FDDI if the DL_INFO_REQ was issued before
	  it had done the bind to the desired SAP.  The board type in the
	  DL_sap_t structure being created was not being initialized during the
	  DLopen().  If a SAP structure had originally been bound to a one byte
	  SAP and then closed, the next open that used the DL_sap_t structure
	  would inherit the first bind's type (DL_CSMACD) instead of the board
	  type (DL_FDDI or DL_ETHER).  Bind will change this later to DL_CSMACD
	  if it gets bound to a one byte SAP.

     23.  Data packets were being dropped when using DLPI with network buffers
	  to achieve maximum throughput over 100BaseT dec Ethernet and pg FDDI. 

	  - The DLrecv() routine could not queue some of the incoming data
	    packets to the pg device queue because it was full.  The flow
	    control q_hiwat value on that queue was too small.  If these
	    packets were not processed by the read service routine DLrsrv()
	    quick enough, the interrupt routine would discard new packets that
	    arrived while the queue was full.  The q_hiwat value for pg was
	    changed from (16 * DL_MAX_PACKET) to (96 * DL_MAX_PACKET).

	  - The DLrsrv() routine was not able to queue some of the packets to
	    the stream head because its queue was also full.  The flow control
	    q_hiwat value on the stream head was too small.  If the receiving
	    user process did not read the packets fast enough, the next packet
	    received by DLrsrv() from the device queue would be discarded.
	    DLopen() was changed to set the stream head's q_hiwat to be the
	    same value as the q_hiwat for the device's queue.  This change
	    effects all Ethernet and FDDI devices.

	  - The Receive Load Adjustment constant that is downloaded to the pg
	    FDDI board was too large.  This value defines the maximum number of
	    packets that will be queued by the board to the host on one
	    interrupt.  The original value for PG_RX_LOADK was 8 which meant up
	    to 8 packets would be queued to the pg interrupt routine at one
	    time for an interrupt.  At a size of 8, packets were being dropped
	    by the board because it was running out of available receive
	    buffers.  With the new value of 4, the kernel is able to start
	    processing the received packets sooner and replenish the supply of
	    receive buffers fast enough so the pg FDDI board does not drop any
	    packets when the transfer rate is high.

     24.  The cause of these problems was not actually in the VME device
	  drivers but the dmac_intr() and the Xintr() routines.  A problem in
	  dmac_intr() caused the panic to occur.  It assumed that its queue of
	  work to do would never be empty (i.e point to itself) when it was
	  called.  If this occurred, dmac_intr() would branch to location 0
	  thereby causing the system to panic.  Checks for this condition were
	  added to dmac_intr() that increment a counter and return to its
	  caller.  The system hang was caused by a problem in Xintr() where it
	  processes a VME interrupt using the Universe II Tundra registers. 
	  The MPIC chip was not being cleared properly in certain situations
	  before the exit from the Xintr() routine.  This caused CPU 0 and the
	  console to hang.

     25.  There were a large number of outstanding kernel memory allocations by
	  icmp_pkt() and pullupmsg() that were not being deallocated until the
	  writer socket was closed.  If the test issued a large number of write
	  (sendto) requests to the socket, the system would eventually hang
	  waiting for kernel memory to become available.

	  The outstanding allocations were message blocks that contained
	  ICMP_SOURCE_QUENCH error messages.  These had been sent by ip because
	  the original data message could not be echoed to the read (RD) side
	  of the writer socket because it's queue became full.
	  icmp_inbound_error() was not checking for flow control before passing
	  the ICMP error message upstream to the next module.  It continued
	  sending the ICMP errors up through the rawip module even after the
	  stream head's queue was full.  In addition, rawip should have been
	  discarding these error messages.  Because the application never read
	  any of the echo or ICMP messages from the read side of the writer
	  socket, flow control was never being relieved and eventually the
	  machine ran out of memory.

	  icmp_inbound_error() was changed to call canputnext() to check for
	  flow control before an ICMP error message is passed upstream.
	  rawip_rput() was modified to discard all M_CTL type message blocks.
	  The memory leak detection debug code was also enhanced in the kma
	  and kmadbg kernel drivers.

     26.  RCIM Coupled FBS support is added to remove this restriction.  Any
	  set of SBCs that are:

		- connected to the same RCIM cable, and 
		- can communicate with each other over a TCP/IP connection,

	  may now use the same distributed interrupt RCIM device as a FBS
	  timing device.  A new pair of device registration function calls, and
	  a rdevfs(4) timing device information call:

		- fbs_register_rdev(3rt | 3F77rt)
		- fbs_unregister_rdev(3rt | 3F77rt)
		- fbsinfo_rdev(3rt | 3F77rt)

	  and new rtcp(1) device registration and information commands:

		- rd  (register Coupled FBS timing device)
		- urd (unregister Coupled FBS timing device)
		- vr  (view rdevfs file configuration information)

	  are provided for support of these new RCIM Coupled timing devices.
 
     27.  Fix code associated with RCIM_ETI_LEVEL.  It was setting the wrong
	  register.

     28.  Fixed rcimconfig.

     29.  RCIM Coupled FBS support is added to remove this restriction.  Any
	  set of SBCs that are:

		- connected to the same RCIM cable, and 
		- can communicate with each other over a TCP/IP connection,

	  may now use the same distributed interrupt RCIM device as a FBS
	  timing device.  A new pair of device registration function calls, and
	  a rdevfs(4) timing device information call:

		- fbs_register_rdev(3rt | 3F77rt)
		- fbs_unregister_rdev(3rt | 3F77rt)
		- fbsinfo_rdev(3rt | 3F77rt)

	  and new rtcp(1) device registration and information commands:

		- rd  (register Coupled FBS timing device)
		- urd (unregister Coupled FBS timing device)
		- vr  (view rdevfs file configuration information)

	  are provided for support of these new RCIM Coupled timing devices.

     30.  Added support to console program to initialize MGA G200 SD card's PCI
	  resources, SDRAM memory, PLLs, DAC, and then place the MGA chip into
	  a VGA compatible state.  After this initialization, the VGATTY driver
	  in console functions properly with the new G200 cards.

 Enhancements:
      
      None.
 
 Object(s) To Be Replaced: 
      
      /etc/conf/cf.d/except.s
      /etc/conf/cf.d/intr.s
      /etc/conf/pack.d/dmac/Driver.o
      /etc/conf/pack.d/fbs/stubs.c
      /etc/conf/pack.d/gd/Driver.o
      /etc/conf/pack.d/kma/Driver.o
      /etc/conf/pack.d/kmadbg/Driver.o
      /etc/conf/pack.d/mem/Driver.o
      /etc/conf/pack.d/name/Driver.o
      /etc/conf/pack.d/proc/Driver.o
      /etc/conf/pack.d/rcim/Driver.o
      /etc/conf/pack.d/rtserial/Driver.o
      /etc/conf/pack.d/sbc/stubs.c
      /etc/conf/pack.d/sfs/Driver.o
      /etc/conf/pack.d/svc/Driver.o
      /etc/conf/pack.d/ui/Driver.o
      /etc/conf/pack.d/xfs/Driver.o
      /sbin/config
      /stand/cp1
      /usr/bin/expr
      /usr/bin/vi
      /usr/ccs/lib/libc.a
      /usr/ccs/lib/libc.so
      /usr/ccs/lib/libp/libc.a
      /usr/lib/libthread.a
      /usr/lib/libthread.so
      /usr/lib/libnsl_i.a
      /usr/lib/libnsl_i.so
      /usr/lib/libc.so.1
      /usr/include/sys/fs/sfs_inode.h
      /usr/include/sys/bus.h
      /usr/include/sys/pin.h
      /usr/include/sys/resource.h
      /usr/sbin/rcimconfig

 Special Conditions for Installation: 
      
      During installation of base-002, an updated version of /stand/cp1 will be
      installed and the new console overlay will be written to partition 6 on
      the system disk.  Following successful installation, the system must be
      shut down and reset to load the new console before rebooting.  Failure
      to do so may result in unexpected or unreliable behavior.
 
      The following object(s) will also be replaced by base-002:

		*  /usr/bin/edit
		*  /usr/bin/ex
		*  /usr/bin/vedit
		*  /usr/bin/view
		*  /usr/ccs/lib/libp/libc.so
		*  /usr/lib/libposix1c.a
		*  /usr/lib/libposix1c.so
		*  /usr/lib/libnsl.a
		*  /usr/lib/libsocket.a
		*  /usr/lib/libxti.a
		*  /usr/lib/libnsl.so
		*  /usr/lib/libxti.so

 Possible Side Effects: 
      
      If the base-002 package is removed (pkgrm(1M)), the original console will
      be re-written to partition 6 on the system disk.  To ensure there are no
      adverse side effects, the kernel should be rebuilt (idbuild(1M)) and the
      system shut down and reset to load the original console before rebooting
      the system.

      Suggested procedure for removing base-002:

        # pkgrm base-002
        # /etc/conf/bin/idbuild -B
        # sync
        # init 0
        # Reset system

	Follow the normal boot procedure detailed in the PowerMAX OS Product
	Release Notes to load the new console and boot the new kernel.
 
                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 ##############################################################################

 Patch Name:           base-002
 Date Issued:          02/02/2000 11:23:28
 Software Package:     base pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6200/6800, PowerMAXION, TurboHawk
 Related Patches:      cnd-002, crosslibs-001, crypt-001, crypt-int-001, 
		       dec-001 egl-001, fbs-002, man-002">fbsman-002, ie-001, inet-002,
		       librt-001, man-002, mvc-001, pg-001
 Related SARs:         #39, #45, #47, #59, #72, #98, #114, #116, #117, #166 
 
 Brief Description:

      PowerMAX OS 4.3 base package release updates
 
 ##############################################################################

 PowerMAX OS 4.3 Patch Set 2
 ---------------------------

 Patches for PowerMAX OS are now released officially as "Patch Sets".  A patch
 set is a collection of patches released simultaneously.  Individual patches
 may have dependencies on other patches included in a patch set.  Not all
 patches in a "Patch Set" may be available/applicable on all supported
 platforms.  It is important to install all applicable patches in order to
 ensure proper system operation.

 "4.3P2" is the abbreviated name for "PowerMAX OS 4.3 Patch Set 2".

 New PowerMAX OS 4.3 Software Patch(es):

      1553v5drv-001	1553v5-ABI User Level Driver Patch 001 (4.3P2)
      1553v5lib-001	1553v5-ABI Library Interfaces Patch 001 (4.3P2)
      base-002		Base System Patch 002 (4.3P2)
      cmds-002		Advanced Commands Patch 002 (4.3P2)
      cnd-002		Condor Ethernet Driver Patch 002 (4.3P2)
      crosslibs-001	Libraries for Cross Compiling Patch 001 (4.3P2)
      crypt-001		Domestic Encryption Utilities Patch 001 (4.3P2)
      crypt-int-001	International Encryption Utilities Patch 001 (4.3P2)
      dec-001		DEC Ethernet Driver Patch 001 (4.3P2)
      egl-001		Eagle Ethernet Driver Patch 001 (4.3P2)
      fbs-002		Frequency Based Scheduler Patch 002 (4.3P2)
      man-002">fbsman-002	Frequency Based Scheduler On-line Manual Pages
				Patch 002 (4.3P2)
      hsde-001		High Speed Data Enhanced Channel Driver
				Patch 001 (4.3P2)
      ie-001		Night Hawk ISE Ethernet Interface Module
				Patch 001 (4.3P2)
      inet-002		Internet Utilities Patch 002 (4.3P2)
      librt-001		Real-time Libraries Patch 001 (4.3P2)
      man-002		On-line Manual Pages Patch 002 (4.3P2)
      mvc-001		Multiplexor VME Controller Driver Patch 001 (4.3P2)
      pg-001		Peregrine FDDI Driver Patch 001 (4.3P2)
      trace-002		KernelTrace Utilities Patch 002 (4.3P2)

 ##############################################################################

 Problem Description:
      
      1.  Use of more expensive sync instructions affected the virtual memory
	  system performance.

      2.  The vi(1) tag facility was not handling duplicate tags properly.
	  vi is supposed to treat duplicate tags as a circular list. 
	  Successive `:ta' commands (with no argument) takes the user to the
	  next duplicate in the list in a roundrobin fashion.  Instead, once
	  the end of the list was reached, error messages would be printed for
	  all following `:ta' commands.

      3.  #116:  Using standard mvc ports, reads return immediately if
	  conditions satisfy the read (i.e., adequate data are available to be
	  returned).  Using mvcrt ports, the initial read would stall when the
	  read should have been satisfied.

	  Additionally, if VMIN=0 and VTIME>0, a read would always wait for the
	  timeout before returning, even when data were available to satisfy
	  the read.  To be correct, VTIME is the time for completion of the
	  read, rather than an intercharacter timer, if the read cannot
	  otherwise be satisfied.  The read should complete if either a single
	  character is read or if the timer expires (no characters returned).
 
      4.  #59:  The xdr_double() function contained in libnsl will return an
	  Arithmetic Exception error and dump core.

      5.  #166:  When using gethostbyname() that is statically linked, a
	  hostname that is opposite in case to one in the /etc/hosts file will
	  fail.  The dynamically linked use of gethostbyname will pass as it
	  should.

      6.  #98:  The system(3S) I/O function should use fork1(2) in
	  multi-threaded applications instead of fork(2).

      7.  In UFS filesystems, the modification times of two different files
	  might show that the clock was running backwards, which means that the
	  file modified earlier might have the more recent timestamp.

      8.  #114:  ksh(1) can't address directory when its size exceeds 2 Gbytes.
	  When using ksh to do integer arithmetic operation with command
	  expr(1), the upper limit for the integer is 2^31 + 1.

      9.  User-level interrupt routines are allowed to do only a limited number
	  of system calls.  Two are server_wake and server_wake1.  However, in
	  some cases, this can cause a process preemption which would panic the
	  system.  Preemption is not allowed while in a user-level interrupt
	  routine.

     10.  Confusing debug messages were being printed when a configured drive
	  was not found.

     11.  User-level interrupts with shared vector devices could cause memory
	  corruption.  Counters associated with shared vectors were being used
	  incorrectly.

     12.  #72:  Threads may returned too early from pthread_once(3pthread).
	  When more than one thread calls pthread_once() at roughly the same
	  time, the threads that are not the first caller do not wait until the
	  first caller thread completes its execution of the initialization
	  routine.

     13.  If a parent process creates one or more POSIX timers and then calls
	  fork(2) or fork1(2), the child process will terminate with an
	  internal libthread error if the child attempts to also create a POSIX
	  timer with timer_create(3C).

     14.  If a parent process creates a POSIX timer with timer_create(3C) and
	  specifies the SIGEV_CALLBACK option and then calls fork(2), the
	  background callback thread will incorrectly exit and remove that
	  POSIX timer from the parent process.

     15.  #117:  sigtimedwait(2) may cause other threads within a process to
	  terminate.  In a multi-threaded process, if one of the threads uses
	  sigtimedwait(2) to catch certain signals, and one of these signals is
	  already pending by the time that thread enters the kernel's
	  sigtimedwait() routine, then the kernel will destroy all the other
	  LWPs in this process if there is no signal catching routine setup to
	  catch this signal and if the default action for the pending signal is
	  to terminate the process.

     16.  It is possible to create a symbolic link on an XFS filesystem in a
	  directory to which the user does not have write permission.

     17.  The kernel may panic with the functions page_sortadd() and
	  xfscr_getpage() in the stack trace under certain XFS file overwrite
	  conditions.  The failure conditions depend on the length and offset
	  of the overwrite, the file disk space allocation boundries and the
	  state of the page cache.  The problem occurs when the overwrite
	  requires the physical read of part of the overwritten data and is due
	  to a fault in the read optimization code.

     18.  #39:  One byte SAPs were not processed correctly on FDDI causing the
	  destination SAP to be based on random user data.  This caused the
	  following problems:

		- data was thrown away even though a properly bound SAP existed

                - data was sent to the wrong SAP

                - the amount of data returned to the user was incorrect

     19.  #39:  The destination SAP specified in the DL_UNITDATA_REQ was being
	  ignored for two-byte SAP messages.  For the one-byte SAP case, it
	  always assumed that a destination SAP was specified in the
	  dl_unitdata_req_t even when it had not been.

     20.  #39:  Because both 802.2 and Ethernet II format messages are
	  supported by the PowerMAX OS Ethernet drivers, it is impossible to
	  support SAPs in the range 0x100 to 0x5dc correctly.  PowerMAX OS did
	  not report an error if SAPs in this range were used for DL_ETHER.

     21.  #39:  DL_TEST_REQ messages do not work correctly.

     22.  #39:  The mac_type field being returned by DL_INFO_REQ was
	  incorrectly set to DL_CSMACD instead of the board type (DL_ETHER or
	  DL_FDDI) if the DL_INFO_REQ was issued before it had done the bind to
	  the desired SAP.

     23.  #39:  Data packets were being dropped when using DLPI with network
	  buffers to achieve maximum throughput over 100BaseT dec Ethernet and
	  pg FDDI. 

     24.  #39:  When a VME device board (i.e pg FDDI) was configured at a
	  VMEIRQ level other than level 5 on a PowerHawk 620 or 640, the system
	  would either:

	 	- panic in the dmac interrupt routine dmac_intr()

	  	- hang CPU 0 and the console

	  when a large amount of data was transferred over the pg FDDI
	  interface at high rates.  These hangs and panics could also occur
	  when using other VME devices (i.e cnd).

     25.  #45:  The system would hang with an out of memory condition when
	  using SOCK_RAW sockets with RAWIP under the following conditions:

		1)  The destination host for the sender is the local system and
		    there is no receiver currently running.

		2)  The destination host for both the sender and receiver is
		    the local system and both tests are currently running.

 	  If the destination host(s) is not the local system (data is going
	  over the wire), the hang does not occur.

     26.  Probes to non-existant VME addresses can result in a hardware
	  deadlock on TurboHawk platforms.

     27.  #47:  Release on Register Access (RORA) mode was not supported for
	  devices in expansion VME I/O on TurboHawk platforms.

     28.  On TurboHawk platforms only one expansion VME bus was supported and
	  this bus was supported only by the PMC connection on the first
	  processor board.
	
     29.  TurboHawk systems would hard hang while booting if the new TurboHawk
	  local memory with interval timer was installed.

     30.  When NightTrace encounters an "int on no int" interrupt event, it
	  displays the incorrect interrupt name for the event.  There are
	  several possible causes of this:

		a.  An interrupt vector is not reserved for the interrupt.
		    Thus, the vector can be allocated later by a device.  When
		    this happens, it becomes impossible to distinguish an
		    "int on no int" interrupt from a valid interrupt for the
		    device which allocated the vector.

		b.  The vector the kernel uses to indicate the "int on no int"
		    interrupt is not the same on all machines.

 Problem Resolution: 
      
      1.  The more expensive sync instruction was replaced in some places with
	  the cheaper eieio instruction.

      2.  When the end of the list is reached, an error message is printed.
	  The following `:ta' then goes back to the first tage in the duplicate
	  tag list.

      3.  mvcrt ports, when opened for reading, now immediately issue a read
	  command, permitting the first read issued by the user to be
	  immediately satisfied when data is available.

	  The VMIN/VTIME code now correctly checks for available data before
	  waiting for the timeout when VMIN=0 and VTIME>0.
 
      4.  The problem was in casting the return value from xdr_double() to a
	  long when it should be cast to a long long.

      5.  A strcasecmp() function that was left out of the nametoaddr library
	  functions from a previous NIS change was restored to its proper
	  location.  Now a statically linked use of gethostbyname() will work
	  as expected. 

      6.  The system(3S) I/O function has been modified to use fork1(2) instead
	  of fork(2) for all applications.

      7.  A global timer is used to keep the more recent time between the
	  time-of-the-day clock and the last file timestamp assigned to any
	  file.  A new file timestamp is assigned based on the global timer.

      8.  Long long integer support has been added to command expr. Now the
	  command can do integer arithmetic operation beyond 2^32 (up to
	  2^63+1).

      9.  When returning from user-level interrupt routine, it will no longer
	  check for and take requested preemptions.  If there is a requested
	  preemption it will be handled after the UI routine completes.

     10.  Removed the messages.

     11.  Fix shared-vector code in user-level interrupt logic.

     12.  Block the other threads so that they do not return from
	  pthread_once() until the initialization routine has been completely
	  executed by the first caller thread.

     13.  The thread library's internal POSIX timer structures are now
	  re-initialized by the first thread that calls timer_create(3C) or
	  timer_delete(3C) within the child process.

     14.  The kernel and thread library code was modified so that fork
	  operations no longer cause the background callback thread to call
	  thr_exit(3thread) upon an interrupted return while waiting on a
	  POSIX timer expiration internally within the thread library.

     15.  Change the kernel's sigtimedwait() routine so that when a signal is
	  already pending, the calling LWP will simply return to the caller
	  with the selected signal number, without interfering with the other
	  LWPs in the same process.

     16.  A check of the user write permission added to the symbolic link
	  create code path.

     17.  The filesystem page read optimization is fixed to request the correct
	  pages for the overwrite boundary conditions.

     18.  The code was using the wrong message offsets to determine the
	  destination SAP for one-byte SAPs for both FDDI and Ethernet.
	  The format of the header for a one-byte SAP message is different than
	  a two-byte SAP message header.  This caused the destination SAP to be
	  based on random user data, which may or may not match one of the
	  bound SAPs.  The code now uses the actual message type (one-byte or
	  two-byte format) to process the message, instead of assuming the
	  message type based on the type of SAP that ends up as the primary
	  receiver (it may not be the same type as the message).  This can
	  occur if the promiscuous SAP is the only receiver.

     19.  The destination SAP specified in the unitdata_req was being ignored
	  for two-byte SAP messages.  For the one-byte SAP case, it always
	  assumed that a destination SAP was specified in the dl_unitdata_req_t
	  even when it had not been.  If a two-byte destination SAP was
	  incorrectly specified when the source was a one-byte SAP, it would
	  use the first byte of the two-byte SAP specified as the destination
	  instead of producing an error.  If a destination is not specified,
	  the destination SAP will now default to be the source SAP number. 
	  Both cases now check to make sure that the source and destination
	  SAPs are the same type (one-byte vs two-byte).
	  
     20.  For SAP numbers in the range 0x100 to DL_MAX_PACKET (= 0x5dc):

		- The sending side was formatting the message in the two-byte
		  SAP format.

		- The receiving side was interpreting it as a one-byte SAP
		  format.

	  When both 802.2 and Ethernet II format messages are supported, it is
	  impossible to support SAPs in the range 0x100 to 0x5dc correctly.
	  DLunitdata_req() was changed so it will not allow bind requests to
	  SAPS in the range 0x100 to 0x5dc.  It will now return an error,
	  rather than sending a message that cannot be interpreted correctly by
	  the receiving side.  This problem occurred only with the Ethernet
	  drivers.  FDDI uses different header format standards that allow a
	  message to be properly identified for all possible one and two-byte
	  SAP values.

     21.  A PowerMAX OS 4.3 change modified the order of the promiscous SAP on
	  the board's valid sap list (SAPs that have been bound to).  Prior to
	  PowerMAX OS 4.3, the NULL SAP (SAP 0) would be in the valid SAP list
	  immediately before the promiscous SAP.  With the change to 4.3, the
	  NULL SAP was placed in the list after the promiscous SAP.  This can
	  cause a difference in the SAP that is selected by DLrecv() to receive
	  the message.

	  DL_TEST_REQ messages do not work correctly on PowerMAX OS 4.3 with
	  this SAP ordering if there is a user bound to the promiscuous SAP.
	  The promiscuous SAP would be chosen as the primary recepient of the
	  message by DLrecv() instead of the proper destination one-byte SAP.
	  DLrsrv() was incorrectly processing the message as a two-byte SAP
	  header.  DLproc_llc() that handles the special processing for test
	  messages was never called. 

	  The ordering of the SAPs done by DLinsert_sap() was changed back to
	  the way it was prior to 4.3. (i.e NULL SAP then promiscuous SAP).
	  DLrsrv() was changed to allocate an indication message for the
	  TEST/XID cases if there is a SAP that wants to receive it in addition
	  to the primary destination SAP.  A user bound to the promiscuous SAP
	  will now receive all messages, including all test messages.

     22.  The mac_type field being returned by DL_INFO_REQ was incorrectly set
	  to DL_CSMACD instead of DL_FDDI if the DL_INFO_REQ was issued before
	  it had done the bind to the desired SAP.  The board type in the
	  DL_sap_t structure being created was not being initialized during the
	  DLopen().  If a SAP structure had originally been bound to a one byte
	  SAP and then closed, the next open that used the DL_sap_t structure
	  would inherit the first bind's type (DL_CSMACD) instead of the board
	  type (DL_FDDI or DL_ETHER).  Bind will change this later to DL_CSMACD
	  if it gets bound to a one byte SAP.

     23.  Data packets were being dropped when using DLPI with network buffers
	  to achieve maximum throughput over 100BaseT dec Ethernet and pg FDDI. 

	  - The DLrecv() routine could not queue some of the incoming data
	    packets to the pg device queue because it was full.  The flow
	    control q_hiwat value on that queue was too small.  If these
	    packets were not processed by the read service routine DLrsrv()
	    quick enough, the interrupt routine would discard new packets that
	    arrived while the queue was full.  The q_hiwat value for pg was
	    changed from (16 * DL_MAX_PACKET) to (96 * DL_MAX_PACKET).

	  - The DLrsrv() routine was not able to queue some of the packets to
	    the stream head because its queue was also full.  The flow control
	    q_hiwat value on the stream head was too small.  If the receiving
	    user process did not read the packets fast enough, the next packet
	    received by DLrsrv() from the device queue would be discarded.
	    DLopen() was changed to set the stream head's q_hiwat to be the
	    same value as the q_hiwat for the device's queue.  This change
	    effects all Ethernet and FDDI devices.

	  - The Receive Load Adjustment constant that is downloaded to the pg
	    FDDI board was too large.  This value defines the maximum number of
	    packets that will be queued by the board to the host on one
	    interrupt.  The original value for PG_RX_LOADK was 8 which meant up
	    to 8 packets would be queued to the pg interrupt routine at one
	    time for an interrupt.  At a size of 8, packets were being dropped
	    by the board because it was running out of available receive
	    buffers.  With the new value of 4, the kernel is able to start
	    processing the received packets sooner and replenish the supply of
	    receive buffers fast enough so the pg FDDI board does not drop any
	    packets when the transfer rate is high.

     24.  The cause of these problems was not actually in the VME device
	  drivers but the dmac_intr() and the Xintr() routines.  A problem in
	  dmac_intr() caused the panic to occur.  It assumed that its queue of
	  work to do would never be empty (i.e point to itself) when it was
	  called.  If this occurred, dmac_intr() would branch to location 0
	  thereby causing the system to panic.  Checks for this condition were
	  added to dmac_intr() that increment a counter and return to its
	  caller.  The system hang was caused by a problem in Xintr() where it
	  processes a VME interrupt using the Universe II Tundra registers. 
	  The MPIC chip was not being cleared properly in certain situations
	  before the exit from the Xintr() routine.  This caused CPU 0 and the
	  console to hang.

     25.  There were a large number of outstanding kernel memory allocations by
	  icmp_pkt() and pullupmsg() that were not being deallocated until the
	  writer socket was closed.  If the test issued a large number of write
	  (sendto) requests to the socket, the system would eventually hang
	  waiting for kernel memory to become available.

	  The outstanding allocations were message blocks that contained
	  ICMP_SOURCE_QUENCH error messages.  These had been sent by ip because
	  the original data message could not be echoed to the read (RD) side
	  of the writer socket because it's queue became full.
	  icmp_inbound_error() was not checking for flow control before passing
	  the ICMP error message upstream to the next module.  It continued
	  sending the ICMP errors up through the rawip module even after the
	  stream head's queue was full.  In addition, rawip should have been
	  discarding these error messages.  Because the application never read
	  any of the echo or ICMP messages from the read side of the writer
	  socket, flow control was never being relieved and eventually the
	  machine ran out of memory.

	  icmp_inbound_error() was changed to call canputnext() to check for
	  flow control before an ICMP error message is passed upstream.
	  rawip_rput() was modified to discard all M_CTL type message blocks.
	  The memory leak detection debug code was also enhanced in the kma
	  and kmadbg kernel drivers.

     26.  Following a VME bus timeout on TurboHawk platforms the kernel relies
	  on the hardware to clear the error state of the PLX9060 bridge.

     27.  RORA is now supported for devices in expansion VME I/O on TurboHawk
	  platforms.  This feature is implemented as a system tunable named
	  TURBO_VME_INT_ROR.  This tunable supports VME devices on the primary
	  VME bus as well as on the expansion VME bus.

     28.  The TurboHawk now supports up to four expansion VME busses.  These
	  busses can be configured via the PMC connectors on any of the four
	  processor boards.
	
     29.  Remove reference to TurboHawk tick timer.  This feature is not
	  available.

     30.  NightTrace problems resolved as follows:

		a.  An interrupt vector is statically reserved in the kernel's
		    interrupt vector table.

		b.  Interrupt vector 127 is reserved on the NightHawk 6800.
		    Interrupt vector 64 is reserved on the PowerMAXION and
		    TurboHawk.

 Enhancements:
      
      None.
 
 Object(s) To Be Replaced: 
      
      /etc/conf/cf.d/except.s
      /etc/conf/cf.d/intr.s
      /etc/conf/cf.d/ivt.s
      /etc/conf/mtune.d/pci
      /etc/conf/mtune.d/vme
      /etc/conf/pack.d/bsp6800t/Driver.o
      /etc/conf/pack.d/fbs/stubs.c
      /etc/conf/pack.d/gd/Driver.o
      /etc/conf/pack.d/io/Driver.o
      /etc/conf/pack.d/kma/Driver.o
      /etc/conf/pack.d/kmadbg/Driver.o
      /etc/conf/pack.d/mem/Driver.o
      /etc/conf/pack.d/name/Driver.o
      /etc/conf/pack.d/pci/Driver.o
      /etc/conf/pack.d/pci/space.c
      /etc/conf/pack.d/proc/Driver.o
      /etc/conf/pack.d/rtserial/Driver.o
      /etc/conf/pack.d/sfs/Driver.o
      /etc/conf/pack.d/svc/Driver.o
      /etc/conf/pack.d/ui/Driver.o
      /etc/conf/pack.d/vme/Driver.o
      /etc/conf/pack.d/vme/space.c
      /etc/conf/pack.d/xfs/Driver.o
      /sbin/config
      /sbin/expr
      /usr/bin/expr
      /usr/bin/vi
      /usr/ccs/lib/libc.a
      /usr/ccs/lib/libc.so
      /usr/ccs/lib/libp/libc.a
      /usr/lib/libthread.a
      /usr/lib/libthread.so
      /usr/lib/libnsl_i.a
      /usr/lib/libnsl_i.so
      /usr/lib/libc.so.1
      /usr/include/sys/fs/sfs_inode.h
      /usr/include/sys/bus.h
      /usr/include/sys/pin.h
      /usr/include/sys/resource.h
      /usr/include/sys/syscx.h

 Special Conditions for Installation: 
      
      The following object(s) will also be replaced by base-002:

                *  /usr/bin/edit
                *  /usr/bin/ex
                *  /usr/bin/vedit
                *  /usr/bin/view
                *  /usr/ccs/lib/libp/libc.so
                *  /usr/lib/libposix1c.a 
                *  /usr/lib/libposix1c.so
                *  /usr/lib/libnsl.a
                *  /usr/lib/libsocket.a
                *  /usr/lib/libxti.a
                *  /usr/lib/libnsl.so
                *  /usr/lib/libxti.so

 Possible Side Effects: 
      
      None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 #############################################################################

 Patch Name:           base-003
 Date Issued:          05/30/2000 12:58:11
 Software Package:     base pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620, 640, PowerStack II, Motorola MCP750
 Related Patches:      crosslibs-002
 Related SARs:         106, 187, 197, 203, 225, 226, 230
 
 Brief Description:

      PowerMAX OS 4.3 base package release updates

 #############################################################################

 PowerMAX OS 4.3 Patch Set 3
 ---------------------------

 Patches for PowerMAX OS are now released officially as "Patch Sets".  A patch
 set is a collection of patches released simultaneously.  Individual patches
 may have dependencies on other patches included in a patch set.  Not all
 patches in a "Patch Set" may be available/applicable on all supported
 platforms.  It is important to install all applicable patches in order to
 ensure proper system operation.

 "4.3P3" is the abbreviated name for "PowerMAX OS 4.3 Patch Set 3".

 New PowerMAX OS 4.3 Software Patch(es):

      base-003       Base System Patch 003 (4.3P3)
      cnd-003        Condor Ethernet Driver Patch 003 (4.3P3)
      crosslibs-002  Libraries for Cross Compiling Patch 002 (4.3P3)
      dec-002        DEC Ethernet Driver Patch 002 (4.3P3)
      diskless-003   Diskless Systems Package Patch 003 (4.3P3)
      egl-002        Eagle Ethernet Driver Patch 002 (4.3P3)
      fibre-002      Fibre Channel Driver Patch 002 (4.3P3)
      inet-003       Internet Utilities Patch 003 (4.3P3)
      ip-002         Interphase 4511 PMC FDDI Driver Patch 002 (4.3P3)
      nfs-001        Network File System Utilities Patch 001 (4.3P3)
      nsu-002        Network Support Utilities Patch 002 (4.3P3)
      pg-002         Peregrine FDDI Driver Patch 002 (4.3P3)
      rvsrv-001      Residential Video Server Tools Patch 001 (4.3P3)
      trace-003      KernelTrace Utilities Patch 003 (4.3P3)
      xfsd-001       Distributed XFS File System Patch 001 (4.3P3)
 
 New PowerMAX OS 4.3 Software Package(s):

      gpib             NI PCI-GPIB Kernel Level Driver

 Note:  The "gpib" package is supported on the Power Hawk 620, Power Hawk 640,
	and PowerStack II.

 ##############################################################################

 Problem Description:

      1.  SAR 106:  On a closely-coupled system (CCS) where a Matrox graphics
	  card is configured on each of the CPU systems the target systems
	  could hang. 

      2.  SAR 187:  Target closely-coupled systems (CCS) intermittently fail to
	  scan disks at boot time.  A disk that is configured a multi-initiator
	  arrangement on a CCS system will sometimes fail to be scanned on the
	  target systems. 

      3.  SAR 197:  iconnect(3C) doesn't work with the Z8536 clocks on Motorola
	  SBCs. 

      4.  SAR 203:  The rtserial read (receive) code could walk off the end of
	  a page and cause a kernel fault.

      5.  SAR 225:  Multi-threaded and/or multi-LWP applications can cause the
	  system to hang if a user-level debugger stop operation is attempted
	  while one of the other threads/LWPs is currently blocked in the
	  kernel on a sigtimedwait(2) or sigwait(2) call. 

      6.  SAR 226:  Trying to fork() a multi-threaded process may hang the
	  process.  If one thread is currently in
	  thr_join(3thread)/pthread_join(3pthread) when another thread in the
	  same process calls fork(2), then the thread blocked in thr_join()
	  causes the fork() operation to never complete.  Additionally, if the
	  thread inside thr_join() call is a multiplexing (MUX, not bound)
	  thread, then it will run continuously, consuming CPU cycles. 

      7.  SAR 230:  The lwp_steal() function attempts to find work for an idle
	  cpu in a multi-processor system.  It does this by taking a waiting
	  and ready LWP from a busy processor's queue and placing it on the
	  idle processor's queue.  The manipulation of these queues was done
	  mostly without the protection of a lock and could result in mangled
	  processor queues and a hung system. 

      8.  xfsrestore(1M) may coredump when trying to restore filesystems with
	  inode numbers higher than 65535.  The dummy entry at the end of a
	  directory block in the dump is not handled correctly in xfsrestore
	  when the inode number is 64K or larger, resulting in an alignment
	  fault. 

      9.  The kernel would panic in page_alloc_blind().  The kernel keeps
	  various lists of free pages to give to applications as they need
	  them.  In one rare circumstance during the walking of this list,
	  looking for a page of the appropriate type was not protected by a
	  semaphore for the entire length of the walk.  This opened the
	  possibility of a corrupted freelist which would cause the panic. 

     10.  Applications sometimes stall waiting for memory forever.  On systems
	  where most of memory was locked down in applications, applications
	  not so locked down would sometimes stall out forever, waiting for
	  memory even though there was some memory available for them to use. 

          The cause:  locked pages not only lock down a physical page, but also
	  a PTE in the system page table.  If most of memory is locked down in
	  applications, then most of the PTEs will be also locked down.  Since
	  any one virtual address has only 16 PTEs into which it can be placed,
	  if all 16 happened to be in use by other locked pages then the new
	  page being faulted in would never be able to complete until some
	  application owning one of the 16 locked pages would release the lock. 

     11.  nanosleep(3C) was failing in certain configurations.

     12.  There were failures where processor run queues were getting
	  destroyed.  The problem was that a single lwp was added to the
	  run queues twice.  This is a problem that leads to the run queues
	  becoming corrupted.  Failures occurred between the interaction with
	  selfblock() (from nanosleep(), etc.) and a process that becomes
	  vm-seized.

     13.  Motorola SBCs made approximately 120 pages of memory unavailable for
	  any use on the typical system.  The PowerPC architecture requires
	  that the PTE page table be allocated on a memory boundary aligned
	  with its size.  This allocation algorithm, under certain
	  circumstances, would allocate memory for a PTE table almost twice the
	  required size in order to achieve this alignment. 

     14.  Certain custom configurations allow third-party VME boards to serve
	  as the VME bus controller.  By default, the Motorola SBC serves as
	  the VME bus controller which may conflict with the third-party VME
	  bus controller. 

 Problem Resolution: 
 
      1.  The cons driver has been modified to correct this problem. 

      2.  The scsi_scan() function of the gd driver would sometimes return
	  IMERR_DEVICE_BUSY during the boot scan for disks on the target CCS
	  systems.  This was possible because the same disk may actually have
	  been busy on the master CCS system at the time of the scan.  The
	  scsi_scan() function was modified such that if the IMERR_DEVICE_BUSY
	  was returned initially then up to five more retries would be
	  attempted.

      3.  The Z8536 clocks share an interrupt vector with 2 secondary UARTs.
	  It is not structured as a standard shared interrupt (although it
	  probably should be).  The interrupt vector is artificially marked as
	  "shared".  This causes a problem with iconnect because it is not
	  recognized and organized like a standard "shared" interrupt.  This
	  was changed so there is a unique interrupt vector for each of the
	  Z8536 clocks. This is invoked indirectly like the RCIM driver does. 

      4.  The rtserialinput() routine now checks the write pointer value when
	  first entered, and if it is beyond the end of the physical queue, it
	  is adjusted to the start of the queue before any of the data is
	  written to the queue.

      5.  The kernel's sigtimedwait() routine was ignoring stop events when
	  checking for signals/events for the current LWP.  This would cause
	  the LWP to loop/run forever inside the sigtimedwait() kernel routine. 
	  The sigtimedwait() routine now checks for EVF_PL_PRSTOP events
	  (debugger stop events), and returns back out of this sigtimedwait()
	  routine so that the kernel can now successfully stop the LWP. 

      6.  The thread library's thr_join() routine (which handles both
	  thr_join(3thread) and pthread_join(3pthread) calls) was re-coded so
	  that it can now process pending signals while waiting to join with
	  another thread.  This change lets the fork(2) processing (which
	  requires all other threads in the same process to receive a signal
	  and subsequently 'rendezvous' in the kernel while a duplicate image
	  of the process is made in order to create the child process) to
	  proceed successfully.  The thr_join() routine was previously blocking
	  signals/events that were posted to this LWP/thread, thus preventing
	  the fork(2) operation from completing. 

      7.  Serialize the operation of lwp_steal() so that multiple processors do
	  not walk over each other should two or more processors be running in
	  lwp_steal() at the same time. 

      8.  Change made to xfsrestore to correct the processing of dummy entries
	  at the end of a directory block. 

      9.  The freelist walking algorithm was modified to be fully protected by
	  the appropriate semaphore. 

     10.  Added a new tunable to PowerMAX OS, PTE_TABLESZ_MULT, which when >1
	  specifies a multiple of how much larger the page table is to be made
	  beyond its default size. 

     11.  Corrected the nanosleep() failure.

     12.  The fix is to totally remove the "wait" state information when an
	  lwp becomes seized. 

     13.  The PTE table allocator is now more intelligent about PTE table
	  placement in the kernel address space. 

     14.  The tunable, VME_UNIV_SYSCON, was added to allow disabling of the
	  Motorola SBC as the VME bus controller.  

 Enhancements:
 
     None.

 Object(s) To Be Replaced: 

      /etc/conf/mtune.d/mem
      /etc/conf/mtune.d/vme
      /etc/conf/pack.d/cons/Driver.o
      /etc/conf/pack.d/gd/Driver.o
      /etc/conf/pack.d/mem/Driver.o
      /etc/conf/pack.d/mem/space.c
      /etc/conf/pack.d/name/Driver.o
      /etc/conf/pack.d/proc/Driver.o
      /etc/conf/pack.d/rtc/Driver.o
      /etc/conf/pack.d/rtserial/Driver.o
      /etc/conf/pack.d/vme/Driver.o
      /etc/conf/pack.d/vme/space.c
      /etc/conf/pack.d/xfs/Driver.o
      /usr/ccs/lib/libc.a
      /usr/ccs/lib/libc.so
      /usr/include/sys/fs/xfs_types.h
      /usr/lib/libc.so.1
      /usr/lib/libthread.a
      /usr/lib/libthread.so
      /usr/lib/fs/xfs/xfsrestore

 Special Conditions for Installation: 

      The following object(s) will also be replaced by base-003:

		*  /usr/ccs/lib/libp/libc.so
		*  /usr/lib/libposix1c.a
		*  /usr/lib/libposix1c.so
		*  /usr/sbin/xfsrestore	
 
 Possible Side Effects: 

      None.

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report
	
 #############################################################################

 Patch Name:           base-003
 Date Issued:          05/30/2000 13:24:44
 Software Package:     base pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         nh
 Platforms:            Night Hawk 6800, PowerMAXION-4, PowerMAXION, TurboHawk
 Related Patches:      crosslibs-002
 Related SARs:         187, 189, 196, 203, 224, 225, 226, 230, 250 
 
 Brief Description:

      PowerMAX OS 4.3 base package release updates

 #############################################################################

 PowerMAX OS 4.3 Patch Set 3
 ---------------------------

 Patches for PowerMAX OS are now released officially as "Patch Sets".  A patch
 set is a collection of patches released simultaneously.  Individual patches
 may have dependencies on other patches included in a patch set.  Not all
 patches in a "Patch Set" may be available/applicable on all supported
 platforms.  It is important to install all applicable patches in order to
 ensure proper system operation.

 "4.3P3" is the abbreviated name for "PowerMAX OS 4.3 Patch Set 3".

 New PowerMAX OS 4.3 Software Patch(es):

      base-003       Base System Patch 003 (4.3P3)
      cnd-003        Condor Ethernet Driver Patch 003 (4.3P3)
      crosslibs-002  Libraries for Cross Compiling Patch 002 (4.3P3)
      dec-002        DEC Ethernet Driver Patch 002 (4.3P3)
      egl-002        Eagle Ethernet Driver Patch 002 (4.3P3)
      ie-002         Night Hawk ISE Ethernet Interface Module Patch 002 (4.3P3)
      inet-003       Internet Utilities Patch 003 (4.3P3)
      nfs-001        Network File System Utilities Patch 001 (4.3P3)
      nsu-002        Network Support Utilities Patch 002 (4.3P3)
      pg-002         Peregrine FDDI Driver Patch 002 (4.3P3)
      trace-003      KernelTrace Utilities Patch 003 (4.3P3)
      xfsd-001       Distributed XFS File System Patch 001 (4.3P3)

 ##############################################################################

 Problem Description:

      1.  SAR 187:  There is a possibility that disk drives could intermittently
	  fail to be scanned at boot time. 

      2.  SAR 189:  User-locked pages with anchored NUMA bindings can panic the
	  system.  The kernel was incorrectly assuming that hard/soft anchored
	  user pages would never be replicated/duplicated in more than one
	  memory pool.   As a result, the kernel would panic when it detected
	  this situation. 
          
      3.  SAR 196:  Frontplane Invalid Address Error sysfaults may panic the
	  system.  The embedded NCR controller hardware performs look-ahead
	  memory reads during I/O write operations for optimization reasons.
	  This look-ahead read request may extend beyond the end of a local
	  memory pool's last physical page, into a 'hole' where no memory
	  exists.  When this occurs, an Frontplane Invalid Address Error
	  results, causing the system to panic. 

      4.  SAR 203:  The rtserial read (receive) code could walk off the end of
	  a page and cause a kernel fault.

      5.  SAR 224:  The ALLINTSONCPU0 kernel tunable was not functioning
	  properly.  It was not targeting non-assigned interrupts to CPU 0 as
	  it should. 

      6.  SAR 225:  Multi-threaded and/or multi-LWP applications can cause the
	  system to hang if a user-level debugger stop operation is attempted
	  while one of the other threads/LWPs is currently blocked in the
	  kernel on a sigtimedwait(2) or sigwait(2) call. 

      7.  SAR 226:  Trying to fork() a multi-threaded process may hang the
	  process.  If one thread is currently in
	  thr_join(3thread)/pthread_join(3pthread) when another thread in the
	  same process calls fork(2), then the thread blocked in thr_join()
	  causes the fork() operation to never complete.  Additionally, if the
	  thread inside thr_join() call is a multiplexing (MUX, not bound)
	  thread, then it will run continuously, consuming CPU cycles. 

      8.  SAR 230:  The lwp_steal() function attempts to find work for an idle
	  cpu in a multi-processor system.  It does this by taking a waiting
	  and ready LWP from a busy processor's queue and placing it on the
	  idle processor's queue.  The manipulation of these queues was done
	  mostly without the protection of a lock and could result in mangled
	  processor queues and a hung system. 

      9.  SAR 250:  Under VME bus traffic load generated by three Peregrine
	  FDDI adapters running at full speed, a PowerMAXION system would panic
	  with a VME BUS timeout.  

     10.  xfsrestore(1M) may coredump when trying to restore filesystems with
	  inode numbers higher than 65535.  The dummy entry at the end of a
	  directory block in the dump is not handled correctly in xfsrestore
	  when the inode number is 64K or larger, resulting in an alignment
	  fault. 

     11.  The kernel would panic in page_alloc_blind().  The kernel keeps
	  various lists of free pages to give to applications as they need
	  them.  In one rare circumstance during the walking of this list,
	  looking for a page of the appropriate type was not protected by a
	  semaphore for the entire length of the walk.  This opened the
	  possibility of a corrupted freelist which would cause the panic. 

     12.  Applications sometimes stall waiting for memory forever.  On systems
	  where most of memory was locked down in applications, applications
	  not so locked down would sometimes stall out forever, waiting for
	  memory even though there was some memory available for them to use. 

          The cause:  locked pages not only lock down a physical page, but also
	  a PTE in the system page table.  If most of memory is locked down in
	  applications, then most of the PTEs will be also locked down.  Since
	  any one virtual address has only 16 PTEs into which it can be placed,
	  if all 16 happened to be in use by other locked pages then the new
	  page being faulted in would never be able to complete until some
	  application owning one of the 16 locked pages would release the lock. 

     13.  nanosleep(3C) was failing when fast interval timers were installed on
	  TurboHawk systems.

     14.  There were failures where processor run queues were getting
	  destroyed.  The problem was that a single lwp was added to the
	  runqueues twice.  This is a problem that leads to the run queues
	  becoming corrupted.  Failures occurred between the interaction with
	  selfblock() (from nanosleep(), etc.) and a process that becomes
	  vm-seized.

     15.  Certain third-party VME boards can not be set to the TurboHawk's
	  default A32 address range on expansion VME busses.  This prevented
	  the boards from being used on the TurboHawk platform. 

 Problem Resolution: 
 
      1.  The scsi_scan() function of the gd driver would sometimes return
	  IMERR_DEVICE_BUSY during the boot scan for disks.  The scsi_scan()
	  function was modified such that if the IMERR_DEVICE_BUSY was returned
	  initially then up to five more retries would be attempted.

      2.  The kernel now properly handles anchored user pages with replicated
	  versions existing in more than one memory pool. 

      3.  During system initialization, the last physical page of the last
	  local memory pool in the system is marked unavailable, thus
	  preventing any I/O operations from occurring on this last page. 
	  Additionally, any local memory pool's last physical page will also be
	  marked unavailable if there is a hole/space between it and the start
	  of the next local memory pool. 

      4.  The rtserialinput() routine now checks the write pointer value when
	  first entered, and if it is beyond the end of the physical queue, it
	  is adjusted to the start of the queue before any of the data are
	  written to the queue.

      5.  The kernel initialization code that assigns interrupts to CPUs now
	  pays attention to the ALLINTSONCPU0 kernel tunable when assigning
	  interrupts to CPUs.  Interrupts that are not limited to specific CPUs
	  and that are not explicitly assigned are now setup to interrupt CPU 0.

      6.  The kernel's sigtimedwait() routine was ignoring stop events when
	  checking for signals/events for the current LWP.  This would cause
	  the LWP to loop/run forever inside the sigtimedwait() kernel routine. 
	  The sigtimedwait() routine now checks for EVF_PL_PRSTOP events
	  (debugger stop events), and returns back out of this sigtimedwait()
	  routine so that the kernel can now successfully stop the LWP. 

      7.  The thread library's thr_join() routine (which handles both
	  thr_join(3thread) and pthread_join(3pthread) calls) was re-coded so
	  that it can now process pending signals while waiting to join with
	  another thread.  This change lets the fork(2) processing (which
	  requires all other threads in the same process to receive a signal
	  and subsequently 'rendezvous' in the kernel while a duplicate image
	  of the process is made in order to create the child process) to
	  proceed successfully.  The thr_join() routine was previously blocking
	  signals/events that were posted to this LWP/thread, thus preventing
	  the fork(2) operation from completing. 

      8.  Serialize the operation of lwp_steal() so that multiple processors do
	  not walk over each other should two or more processors be running in
	  lwp_steal() at the same time. 

      9.  PowerMAXIONs did not get the VME BUS timeout fix that all other Night
	  Hawk platforms received in PowerMAX OS 4.3.  This update extends the
	  fix to that platform.  In addition, the timing windows that the fix
	  opened up for VME bus traffic to use were too small and too widely
	  spaced apart in time to protect against VME bus timeouts in large
	  configurations. 

     10.  Change made to xfsrestore to correct the processing of dummy entries
	  at the end of a directory block. 

     11.  The freelist walking algorithm was modified to be fully protected by
	  the appropriate semaphore. 

     12.  Added a new tunable to PowerMAX OS, PTE_TABLESZ_MULT, which when >1
	  specifies a multiple of how much larger the page table is to be made
	  beyond its default size. 

     13.  nanosleep() now correctly reference fast interval timers.

     14.  The fix is to totally remove the "wait" state information when an
	  lwp becomes seized. 

     15.  Three variables contained in the file /etc/conf/pack.d/vme/space.c
	  can be modified to specify the start address, address range, and an
	  offset for A32 addressing on expansion VME busses on TurboHawks. 

 Enhancements:
 
      None.

 Object(s) To Be Replaced: 

      /etc/conf/mtune.d/mem
      /etc/conf/mtune.d/vme
      /etc/conf/pack.d/bsp6408/Driver.o
      /etc/conf/pack.d/bspall/Driver.o
      /etc/conf/pack.d/gd/Driver.o
      /etc/conf/pack.d/mem/Driver.o
      /etc/conf/pack.d/mem/space.c
      /etc/conf/pack.d/name/Driver.o
      /etc/conf/pack.d/proc/Driver.o
      /etc/conf/pack.d/rtserial/Driver.o
      /etc/conf/pack.d/vme/Driver.o
      /etc/conf/pack.d/vme/space.c
      /etc/conf/pack.d/xfs/Driver.o
      /usr/ccs/lib/libc.a
      /usr/ccs/lib/libc.so
      /usr/include/sys/fs/xfs_types.h
      /usr/lib/libc.so.1
      /usr/lib/libthread.a
      /usr/lib/libthread.so
      /usr/lib/fs/xfs/xfsrestore

 Special Conditions for Installation: 

      The following object(s) will also be replaced by base-003:

		*  /usr/ccs/lib/libp/libc.so
		*  /usr/lib/libposix1c.a
		*  /usr/lib/libposix1c.so
		*  /usr/sbin/xfsrestore	
 
 Possible Side Effects: 

      1.  Reference Problem #3:  The system may mark the last physical page of
	  one or more local memory pools unavailable at system initialization
	  time.  This may cause a reserved memory section error to occur during
	  boot up if an application is also attempting to use/reserve the last
	  page in the local memory pool that has already been marked
	  unavailable.  In this case, the application's last reserved memory
	  entry should be modified so that it no longer uses the last page of
	  that local memory pool. 

                                        return to index
================================================================================


              Concurrent Computer Corporation Software Development
                            Software Patch Report

 #############################################################################
	
 Patch Name:           base-004
 Date Issued:          10/05/2000 13:39:21
 Software Package:     base pkg (Version 4.3)
 OS Release:           PowerMAX OS 4.3
 Architecture:         moto
 Platforms:            Power Hawk 620/640, PowerStack II/III, Motorola MCP750
 Related Patches:      cmds-003, cnd-004, crosslibs-003, crypt-002,
		       crypt-int-002, dec-003, diskless-004, egl-003,
		       fibre-003, inet-004, ip-003, man-003, pg-003
 Related SARs:         194, 230, 257, 277, 319, 322, 327, 338, 348, 369, 374,
		       392, 397
 
 Brief Description:

      PowerMAX OS 4.3 base package release updates
 
 #############################################################################

 PowerMAX OS 4.3 Patch Set 4
 ---------------------------

 Patches for PowerMAX OS are now released officially as "Patch Sets".  A patch
 set is a collection of patches released simultaneously.  Individual patches
 may have dependencies on other patches included in a patch set.  Not all
 patches in a "Patch Set" may be available/applicable on all supported
 platforms.  It is important to install all applicable patches in order to
 ensure proper system operation.

 "4.3P4" is the abbreviated name for "PowerMAX OS 4.3 Patch Set 4".

 New PowerMAX OS 4.3 Software Patch(es):

      base-004		Base System Patch 004 (4.3P4)
      cmds-003		Advanced Commands Patch 003 (4.3P4)
      cnd-004		Condor Ethernet Driver Patch 004 (4.3P4)
      crosslibs-003	Libraries for Cross Compiling Patch 003 (4.3P4)
      crypt-002		Domestic Encryption Utilities Patch 002 (4.3P4)
      crypt-int-002	International Encryption Utilities Patch 002 (4.3P4)
      dec-003		DEC Ethernet Driver Patch 003 (4.3P4)
      diskless-004	Diskless Systems Package Patch 004 (4.3P4)
      egl-003		Eagle Ethernet Driver Patch 003 (4.3P4)
      fibre-003		Fibre Channel Driver Patch 003 (4.3P4)
      inet-004		Internet Utilities Patch 004 (4.3P4)
      ip-003		Interphase 4511 PMC FDDI Driver Patch 003 (4.3P4)
      man-003		On-line Manual Pages Patch 003 (4.3P4)
      pg-003		Peregrine FDDI Driver Patch 003 (4.3P4)


 New PowerMAX OS 4.3 Software Package(s):

      rmxf		RAMiX PMC665 FOB Ethernet Driver

 Note:  The "rmxf" package is supported on the Power Hawk 620 and
	Power Hawk 640.

 ##############################################################################

 Problem Description:

      1.  SAR 194:  Errors using UNIX select(3C) with send(3N) writing to
	  non-blocking sockets.  Part of the frame that was being written to
	  the socket was lost.

      2.  SAR 230:  Multi-CPU systems may hang, especially if interrupt daemons
	  are enabled. The kernel's lwp_steal() routine was dropping IPL to
	  zero while still holding a light-weight process (lwp) lock.  This
	  routine grabs ready to run lwps on an engine that is otherwise about
	  to enter the idle loop.  This could cause the system to hang in an
	  interrupt routine when it tries to wakeup an interrupt daemon lwp, if
	  the l_mutex was already locked in lwp_steal().

      3.  SAR 257:  When utilizing a UDP socket (datagram) and calling the
	  receive calls (recvfrom, recvmsg) with fewer bytes to read than the
	  incoming message contains, the remaining bytes of the message are
	  retained in the buffer.  This condition causes subsequent receive
	  calls to erroneously interpret these bytes as a new
	  message/datagram.

      4.  SAR 277:  When a NFS file system is unmounted, all file privileges
	  set in all the NFS-mounted file system are cleared from the
	  privileges system table.  The privileges system table is searched
	  for a matching device entry.  Since all NFS file systems are
	  assigned the same device value (zero), when one is unmounted all the
	  privileges for all the NFS-mounted file systems are cleared.

      5.  SAR 319:  The system or application may hang when debugging an Ada
	  program.  The rescheduling variable's rv_priority field is used by
	  ADA applications (in the 'ad' scheduling class) to temporarily raise
	  the scheduling priority of an lwp.  This raised priority is used to
	  obtain exclusive access to a resource, such as a user-space spin
	  lock.

	  After a lwp with a raised rv_priority hits a debugger breakpoint,
	  upon continuing the application the original priority of this lwp
	  (not its raised temporary rv_priority) is used as the basis for
	  resuming this lwp in the kernel.

	  Additionally, when the application is continued, the 'wrong' lwp may
	  run before the lwp with the raised priority does, and a deadlock in
	  user-space can occur if the 'wrong' lwp also temporarily raises its
	  scheduling priority and attempts to grab the same resource in user
	  space.

      6.  SAR 322:  All threads are duplicated when popen(3c) is called.  When
	  a thread within a multi-threaded process calls popen(3C), all of the
	  threads are recreated in the new child process with a fork(2) call.

	  This can cause various potential problems for all of the other
	  threads in the parent process, depending upon what they were doing
	  at the time when the one thread called popen(3c).  The fork(2) call
	  inside popen(3c) causes the parent process's lwps