All Patches for PowerMAX 5.1 are:
1553v5drv-001 crypt-001 fbs-007 man-005 pg-003
1553v5drv-002 crypt-002 fbsman-001 man-006 pg-004
1553v5drv-003 crypt-003 fibre-001 man-007 pg-005
1553v5lib-001 crypt-004 gf-001 man-008 rpc-001
audit-001 crypt-005 gpib-001 mvc-001 rpc-002
base-001 crypt-int-001 gpib-002 mvc-002 rpc-003
base-002 crypt-int-002 gpib-003 mvc-003 rpc-004
base-003 crypt-int-003 hps-001 mvcs-001 rpc-005
base-004 dec-001 hsde-001 ncr-001 softint-001
base-005 dec-002 ide-001 ncr-002 softint-002
base-006 dec-003 ie-001 ncr-003 softint-003
base-007 dec-004 ie-002 netcmds-001 softint-004
base-008 dec-005 ie-003 netcmds-002 sym-001
base-009 diskless-001 inet-001 netcmds-003 sym-002
base-010 diskless-002 inet-002 nfs-001 sym-003
cdfs-001 diskless-003 inet-003 nfs-002 sym-004
cdfs-002 diskless-004 inet-004 nfs-003 sym-005
cdfs-003 diskless-005 inet-005 nfs-004 trace-001
cmds-001 diskless-006 inet-006 nfs-005 trace-002
cmds-002 diskless-007 inet-007 nfs-006 trace-003
cmds-003 diskless-008 inet-008 nfs-007 trace-004
cmds-004 egl-001 inet-009 nfs-008 trace-005
cmds-005 egl-002 ip-001 nsu-001 trace-006
cmds-006 egl-003 ip-002 nsu-002 vhsd-001
cmds-007 fbs-001 ip-003 nsu-003 vhsd-002
cmds-008 fbs-002 is-001 nsu-004 via-001
cnd-002 fbs-003 man-001 oam-001 via-002
cnd-003 fbs-004 man-002 oam-002 via-003
cnd-004 fbs-005 man-003 pg-001 xfsd-001
cnd-005 fbs-006 man-004 pg-002
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
##############################################################################
Software Update Name:1553v5drv-001
Date Issued: 10/25/2001 14:02:43
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: moto
Platforms: Power Hawk 620/640, PowerStack II/III, Motorola MCP750
Related Packages: none
Related SARs: none
Brief Description:
PowerMAX OS 5.1 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-001
Date Issued: 10/22/2001 12:39:29
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: nh
Platforms: Night Hawk 6800, PowerMAXION, TurboHawk
Related Packages: base-002
Related SARs: #533
Brief Description:
PowerMAX OS 5.1 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-001
Date Issued: 10/31/2001 09:18:56
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX_OS 5.1
Architecture: synergy
Platforms: Power Hawk 710/720/740
Related Packages: base-002
Related SARs: none
Brief Description:
PowerMAX_OS 5.1 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-002
Date Issued: 09/18/2002 12:31:17
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: moto
Platforms: Power Hawk 620/640, PowerStack II/III, Motorola MCP750
Related Packages: base-005
Related SARs: none
Brief Description:
PowerMAX OS 5.1 1553v5drv package release updates
###############################################################################
P1. The 1553v5drv(7) manpage gave incorrect information with respect to
the VME address to supply to the abiconfig utility for Power Hawk
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
Power Hawk 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 Service Release Report
###############################################################################
Software Update Name:1553v5drv-002
Date Issued: 10/09/2002 10:44:56
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: nh
Platforms: Night Hawk 6800, PowerMAXION, TurboHawk
Related Packages: base-005
Related SARs: none
Brief Description:
PowerMAX OS 5.1 1553v5drv package release updates
###############################################################################
P1. The 1553v5drv(7) manpage gave incorrect information with respect to
the VME address to supply to the abiconfig utility for Power Hawk
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
Power Hawk 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 Service Release Report
###############################################################################
Software Update Name:1553v5drv-002
Date Issued: 09/26/2002 16:02:59
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: synergy
Platforms: Power Hawk 710/720/740
Related Packages: base-005
Related SARs: none
Brief Description:
PowerMAX OS 5.1 1553v5drv package release updates
###############################################################################
P1. The 1553v5drv(7) manpage gave incorrect information with respect to
the VME address to supply to the abiconfig utility for Power Hawk
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
Power Hawk 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 Service Release Report
###############################################################################
Software Update Name:1553v5drv-003
Date Issued: 04/23/2004 10:29:05
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: moto
Platforms: Power Hawk 620/640, PowerStack II/III, Motorola MCP750
Related Packages: base-008
Brief Description: PowerMAX OS 5.1 1553v5drv package release updates
###############################################################################
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 to the CFLAGS variable in the examples Makefile. Also
modified /usr/include/1553v5drv/abi.h to add comments around
ABIV5_ERROR_STRINGS in #endif ABIV5_ERROR_STRINGS.
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 Service Release Report
###############################################################################
Software Update Name:1553v5drv-003
Date Issued: 05/07/2004 08:34:17
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: nh
Platforms: Night Hawk 6800, PowerMAXION, TurboHawk
Related Packages: base-008
Brief Description: PowerMAX OS 5.1 1553v5drv package release updates
###############################################################################
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 to the CFLAGS variable in the examples Makefile. Also
modified /usr/include/1553v5drv/abi.h to add comments around
ABIV5_ERROR_STRINGS in #endif ABIV5_ERROR_STRINGS.
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 Service Release Report
###############################################################################
Software Update Name:1553v5drv-003
Date Issued: 05/11/2004 09:07:42
Software Package: 1553v5drv pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: synergy
Platforms: Power Hawk 710/720/740
Related Packages: base-008
Brief Description: PowerMAX OS 5.1 1553v5drv package release updates
###############################################################################
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 to the CFLAGS variable in the examples Makefile. Also
modified /usr/include/1553v5drv/abi.h to add comments around
ABIV5_ERROR_STRINGS in #endif ABIV5_ERROR_STRINGS.
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 Service Release Report
###############################################################################
Software Update Name:1553v5lib-001
Date Issued: 04/23/2004 10:29:12
Software Package: 1553v5lib pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: moto
Platforms: Power Hawk 620/640, PowerStack II/III, Motorola MCP750
Related Packages: base-008
Brief Description:
PowerMAX OS 5.1 1553v5lib package release updates
###############################################################################
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 to the CFLAGS variable in the examples Makefile. Also
modified /usr/include/1553v5drv/abi.h to add comments around
ABIV5_ERROR_STRINGS in #endif ABIV5_ERROR_STRINGS.
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 Service Release Report
###############################################################################
Software Update Name:1553v5lib-001
Date Issued: 05/07/2004 08:34:23
Software Package: 1553v5lib pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: nh
Platforms: Night Hawk 6800, PowerMAXION, TurboHawk
Related Packages: base-008
Brief Description: PowerMAX OS 5.1 1553v5lib package release updates
###############################################################################
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 to the CFLAGS variable in the examples Makefile. Also
modified /usr/include/1553v5drv/abi.h to add comments around
ABIV5_ERROR_STRINGS in #endif ABIV5_ERROR_STRINGS.
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 Service Release Report
###############################################################################
Software Update Name:1553v5lib-001
Date Issued: 05/11/2004 09:07:48
Software Package: 1553v5lib pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: synergy
Platforms: Power Hawk 710/720/740
Related Packages: base-008
Brief Description: PowerMAX OS 5.1 1553v5lib package release updates
###############################################################################
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 to the CFLAGS variable in the examples Makefile. Also
modified /usr/include/1553v5drv/abi.h to add comments around
ABIV5_ERROR_STRINGS in #endif ABIV5_ERROR_STRINGS.
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 Service Release Report
###############################################################################
Software Update Name:audit-001
Date Issued: 09/25/2006 11:49:12
Software Package: audit pkg (Version 5.1)
OS Release: PowerMAX_OS 5.1
Architecture: moto
Platforms: Power Hawk 620/640, PowerStack II/III, Motorola MCP750
Related Packages: base-010
Brief Description:
PowerMAX_OS 5.1 audit package release updates
###############################################################################
P1: DT5354: If the auditmap is regenerated on a system after the
initialization of NIS, then future invocations of auditrpt(1M)
will result in an error similar to the following:
UX:auditrpt: ERROR: bad map record type 0
A miscalculation of the size of the user id map portion in the
auditmap(1M) command caused a miscalculation of the size of the
user id map portion of the auditmap, thereby corrupting the
auditmap such that auditrpt(1M) could not use it.
R1: The bug in the auditmap(1M) command has been removed.
Enhancements:
Object(s) To Be Replaced:
/usr/sbin/auditmap
Special Conditions for Installation:
None.
Possible Side Effects:
None.
return to index
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
###############################################################################
Software Update Name:audit-001
Date Issued: 09/25/2006 14:16:01
Software Package: audit pkg (Version 5.1)
OS Release: PowerMAX_OS 5.1
Architecture: nh
Platforms: Night Hawk 6800, PowerMAXION, TurboHawk
Related Packages: base-010
Brief Description:
PowerMAX_OS 5.1 audit package release updates
###############################################################################
P1: DT5354: If the auditmap is regenerated on a system after the
initialization of NIS, then future invocations of auditrpt(1M)
will result in an error similar to the following:
UX:auditrpt: ERROR: bad map record type 0
A miscalculation of the size of the user id map portion in the
auditmap(1M) command caused a miscalculation of the size of the
user id map portion of the auditmap, thereby corrupting the
auditmap such that auditrpt(1M) could not use it.
R1: The bug in the auditmap(1M) command has been removed.
Enhancements:
Object(s) To Be Replaced:
/usr/sbin/auditmap
Special Conditions for Installation:
None.
Possible Side Effects:
None.
return to index
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
###############################################################################
Software Update Name:audit-001
Date Issued: 09/25/2006 14:37:12
Software Package: audit pkg (Version 5.1)
OS Release: PowerMAX_OS 5.1
Architecture: synergy
Platforms: Power Hawk 720/740
Related Packages: base-010
Brief Description:
PowerMAX_OS 5.1 audit package release updates
###############################################################################
P1: DT5354: If the auditmap is regenerated on a system after the
initialization of NIS, then future invocations of auditrpt(1M)
will result in an error similar to the following:
UX:auditrpt: ERROR: bad map record type 0
A miscalculation of the size of the user id map portion in the
auditmap(1M) command caused a miscalculation of the size of the
user id map portion of the auditmap, thereby corrupting the
auditmap such that auditrpt(1M) could not use it.
R1: The bug in the auditmap(1M) command has been removed.
Enhancements:
Object(s) To Be Replaced:
/usr/sbin/auditmap
Special Conditions for Installation:
None.
Possible Side Effects:
None.
return to index
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
##############################################################################
Software Update Name:base-001
Date Issued: 07/16/2001 14:06:12
Software Package: base pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: moto
Platforms: Power Hawk 620/640, PowerStack II/III, Motorola MCP750
Related Packages: nfs-001
Related SARs: none
Brief Description:
PowerMAX OS 5.1 base package release updates
##############################################################################
PowerMAX OS 5.1 Service Release 1
Software updates for PowerMAX OS are now released officially as "Service
Releases". A service release set is a collection of software package
updates released simultaneously. Individual update packages may have
dependencies on other update packages included in a service release.
Not all update packages in a "Service Release" may be available or
applicable on all supported platforms. It is important to install all
applicable software updates in order to ensure proper system operation.
"5.1SR1" is the abbreviated name for "PowerMAX OS 5.1
Service Release 1".
PowerMAX OS 5.1SR1 Software Update Package(s):
base-001 Base System Patch 001 (5.1SR1)
nfs-001 Network File System Utilities Patch 001 (5.1SR1)
##############################################################################
Problem Description:
1. When multiple autoconfigurable devices of the same type
are connected to the system and devcfg is invoked with
the -C option, devcfg generates incorrect device names.
For example, when two ncr disk controllers are attached
and the -C option is invoked, devcfg will list both
devices as ncr0 instead of ncr0 and ncr1.
2. Probe of missing 8042PC chips on a single port VQP-M PMC card
fails, which leads to extended boot times while trying to
initialize non-existent keyboard interfaces.
Problem Resolution:
1. Devcfg generates an internal list of devices sorted based on the
adapter type field in the adapter structure. Autoconfigurable
devices do not use this field as originally intended and hence
multiple instances of autoconfigurable devices are not seen as
the same device type. Changed the algorithm to sort the list
by adapter name instead of by adapter type.
2. Correct the probe logic so that only equipped keyboard interfaces
are initialized.
Enhancements:
None.
Object(s) To Be Replaced:
/usr/bin/devcfg
/etc/conf/pack.d/pkbd/Driver.o
/etc/conf/pack.d/name/Driver.o
Special Conditions for Installation:
None.
Possible Side Effects:
None.
return to index
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
##############################################################################
Software Update Name:base-001
Date Issued: 07/17/2001 07:54:46
Software Package: base pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: nh
Platforms: Night Hawk 6800, PowerMAXION, TurboHawk
Related Packages: nfs-001
Related SARs: none
Brief Description:
PowerMAX OS 5.1 base package release updates
##############################################################################
PowerMAX OS 5.1 Service Release 1
Software updates for PowerMAX OS are now released officially as "Service
Releases". A service release set is a collection of software package
updates released simultaneously. Individual update packages may have
dependencies on other update packages included in a service release.
Not all update packages in a "Service Release" may be available or
applicable on all supported platforms. It is important to install all
applicable software updates in order to ensure proper system operation.
"5.1SR1" is the abbreviated name for "PowerMAX OS 5.1
Service Release 1".
PowerMAX OS 5.1SR1 Software Update Package(s):
base-001 Base System Patch 001 (5.1SR1)
nfs-001 Network File System Utilities Patch 001 (5.1SR1)
##############################################################################
Problem Description:
1. When multiple autoconfigurable devices of the same type
are connected to the system and devcfg is invoked with
the -C option, devcfg generates incorrect device names.
For example, when two ncr disk controllers are attached
and the -C option is invoked, devcfg will list both
devices as ncr0 instead of ncr0 and ncr1.
Problem Resolution:
1. Devcfg generates an internal list of devices sorted based on the
adapter type field in the adapter structure. Autoconfigurable
devices do not use this field as originally intended and hence
multiple instances of autoconfigurable devices are not seen as
the same device type. Changed the algorithm to sort the list
by adapter name instead of by adapter type.
Enhancements:
None.
Object(s) To Be Replaced:
/usr/bin/devcfg
/etc/conf/pack.d/name/Driver.o
Special Conditions for Installation:
None.
Possible Side Effects:
None.
return to index
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
##############################################################################
Software Update Name:base-001
Date Issued: 07/16/2001 13:37:32
Software Package: base pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: synergy
Platforms: Power Hawk 710/720/740
Related Packages: nfs-001
Related SARs: none
Brief Description:
PowerMAX OS 5.1 base package release updates
##############################################################################
PowerMAX OS 5.1 Service Release 1
---------------------------------
Software updates for PowerMAX OS are now released officially as "Service
Releases". A service release set is a collection of software package
updates released simultaneously. Individual update packages may have
dependencies on other update packages included in a service release.
Not all update packages in a "Service Release" may be available or
applicable on all supported platforms. It is important to install all
applicable software updates in order to ensure proper system operation.
"5.1SR1" is the abbreviated name for "PowerMAX OS 5.1
Service Release 1".
PowerMAX OS 5.1SR1 Software Update Package(s):
base-001 Base System Patch 001 (5.1SR1)
nfs-001 Network File System Utilities Patch 001 (5.1SR1)
##############################################################################
Problem Description:
1. When multiple autoconfigurable devices of the same type
are connected to the system and devcfg is invoked with
the -C option, devcfg generates incorrect device names.
For example, when two ncr disk controllers are attached
and the -C option is invoked, devcfg will list both
devices as ncr0 instead of ncr0 and ncr1.
2. Probe of missing 8042PC chips on a single port VQP-M PMC card
fails, which leads to extended boot times while trying to
initialize non-existent keyboard interfaces.
Problem Resolution:
1. Devcfg generates an internal list of devices sorted based on the
adapter type field in the adapter structure. Autoconfigurable
devices do not use this field as originally intended and hence
multiple instances of autoconfigurable devices are not seen as
the same device type. Changed the algorithm to sort the list
by adapter name instead of by adapter type.
2. Correct the probe logic so that only equipped keyboard interfaces
are initialized.
Enhancements:
None
Object(s) To Be Replaced:
/usr/bin/devcfg
/etc/conf/pack.d/pkbd/Driver.o
/etc/conf/pack.d/name/Driver.o
Special Conditions for Installation:
None.
Possible Side Effects:
None.
return to index
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
##############################################################################
Software Update Name:base-002
Date Issued: 10/25/2001 16:05:36
Software Package: base pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: moto
Platforms: Power Hawk 620/640, PowerStack II/III, Motorola MCP750
Related Packages: 1553v5drv-001,cmds-001,crypt-001,crypt-int-001,
dec-001,diskless-001,fbs-001,fibre-001,gpib-001,
inet-001,man-001,mvc-001,ncr-001,netcmds-001,
nfs-002,trace-001,via-001
Related SARs: #536, #495, #503, #520, #430, #108, #565, #498, #501,
#556, #576, #569, #227, #258, #583, #588, #613
Brief Description:
PowerMAX OS 5.1 base package release updates
##############################################################################
PowerMAX OS 5.1 Service Release 2
Software updates for PowerMAX OS are now released officially as "Service
Releases". A service release set is a collection of software package
updates released simultaneously. Individual update packages may have
dependencies on other update packages included in a service release.
Not all update packages in a "Service Release" may be available or
applicable on all supported platforms. It is important to install all
applicable software updates in order to ensure proper system operation.
"5.1SR2" is the abbreviated name for "PowerMAX OS 5.1 Service Release 2".
PowerMAX OS 5.1SR2 Software Update Package(s):
1553v5drv-001 1553v5-ABI User Level Driver Software Update 001 (5.1SR2)
base-002 Base System Software Update 002 (5.1SR2)
cmds-001 Advanced Commands Software Update 001 (5.1SR2)
crypt-001 Domestic Encryption Utilities Software Update 001 (5.1SR2)
crypt-int-001 International Encryption Utilities Software Update 001 (5.1SR2)
dec-001 DEC Ethernet Driver Software Update 001 (5.1SR2)
diskless-001 Diskless Systems Package Software Update 001 (5.1SR2)
fbs-001 Frequency Based Scheduler Software Update 001 (5.1SR2)
fibre-001 Fibre Channel Driver Software Update 001 (5.1SR2)
gpib-001 NI PCI/PMC-GPIB Kernel Level Driver Software Update 001 (5.1SR2)
ide-001 Internal IDE/ATA Disk Controller Software Update 001 (5.1SR2)
inet-001 Internet Utilities Software Update 001 (5.1SR2)
man-001 On-line Manual Pages Software Update 001 (5.1SR2)
mvc-001 Multiplexor VME Controller Driver Software Update 001 (5.1SR2)
ncr-001 NCR/Symbios SCSI Controller Software Update 001 (5.1SR2)
netcmds-001 Commands Networking Extension Software Update 001 (5.1SR2)
nfs-002 Network File System Utilities Software Update 002 (5.1SR2)
trace-001 KernelTrace Utilities Software Update 001 (5.1SR2)
via-001 VIA SCSI Adapter Interface Software Update 001 (5.1SR2)
##############################################################################
Problem Description:
1. SAR #536:
In order for additional swap devices identified in /etc/vfstab
to be added during bootup, the /sbin/mountall script must be
modified. The line: /usr/sbin/swap -a $special must be changed
to /sbin/swap -a $special
2. SAR's #495, #503:
When an application containing gethostbyname() was staticly
linked with libnsl.a and the gethostbyname() followed one of
the getservXXX() routines the application would core dump
with a segmentation violation. This was due to the tcpip
portion of libnsl accessing the same exact data structure for
its host data that was used for the services data from the
getservXXX() routine. It used the same data structure because
the initialization routine (_tcpip_init()) was not being invoked
in a static object for allocation of the data structure to hold
the host data.
3. The function prototypes for the set_timeout_resolution()
/get_timeout_resolution() routines are not properly declared in
an associated header file. This causes compilation errors under
the new ec++ compiler.
4. SAR #520:
A previous patch introduced a possibility in the dispatcher
wherein a real-time process could not preempt. The IPL could
be left at a level other than the one with which the dispatcher
was entered. This sometimes resulted in disallowing real-time
process preemption.
5. SAR #430:
The pthread_cond_timedwait() routine exposed a race condition
on PowerMAXION systems such that it could block and not be resumed.
On a PowerMAXION system if a process was running on CPU 0 and
was programmed to block, the wakeup routine scheduled on the
global callout queue could have been called via hardclk before the
process had actually reached the blocking routine.
As such, when the process did block it could not have been awakened
again because its wakeup routine had already run.
6. SAR #108:
Symptom: an application with an sbrk(2) area that incrementally
grew into the hundreds of megabytes would occasionally
self-deadlock waiting for the next chunk of virtual memory to be
allocated to the sbrk(2) area of that application.
Problem: one of the kernel data structures needed to manage
application virtual address space would grow so large that there
was danger that not enough *kernel* virtual address space could
be found to hold the next incarnation of that table.
7. Symptom: mlock(2)ing a region of application memory that had
been created with the SHM_NCACHE flag of shmget(2) would panic
the system.
Problem: code in the kernel Driver mem/Driver.o that created PTEs
differed slightly from code nearby that would re-use an already
existing PTE; the net effect of this difference was confusion on
the kernel's part with regard to the cached/not-cached state of
the pages created by shmget(2).
8. Symptom: sometimes a large application distributed among a large
number of local memory pools would self-deadlock when an attempt
was made to lock the application down in memory.
Problem: The way PTEs were allocated was defective, resulting in
all of an applications PTEs being allocated in at most one eighth
of the available PTE buckets. When a bucket was full of locked
down PTEs, and Yet Another had to go into that particular bucket,
the application would wait for a free PTE to become available in
that bucket. That wait would never complete if the application
itself was the owner of all the PTEs already in the bucket.
9. Symptom: The cpu_bias(2) system call would sometimes return with
r1 corrupted when run on nighthawks and when the process was under
the control of a debugger.
Problem: reading and writing of another process's u-area was not
cache coherent when that u-area was in remote memory. Access to
another process's u-area is something done by only a debugger.
10. Symptom: the core dumps of some applications that utilized
dynamically loaded libraries could not be processed by the
debugger.
Problem: the core dump logic in the kernel erroneously assumed
that the text of dynamically loaded libraries was accurately
represented by the corresponding text sections in the library
files, and failed to save off those regions of the address space
to the core file.
11. On a console auto-reboot operation, such as a "shutdown ... -i6",
or on an auto-reboot after a system panic, the 2nd CPU was
entering the kernel's start routine with a bad 'msr' register value.
(The 'msr' register controls CPU attributes such as whether
or not virtual memory is enabled, and whether or not
the instruction and data caches are enabled, etc.)
In the auto-reboot case, a bad 'msr' register value could
cause us to write to random locations in memory while making
some early subroutine calls in the kernel's low-level startup
routine, before the 2nd CPU's registers could be properly
initialized by the kernel.
Eventually, the kernel would sometimes end up panic()ing in a
random fashion, when it tried to use the corrupted memory
locations.
12. SAR #565:
The thread that calls pthread_cond_timedwait() does not return
when a another thread calls pthread_cond_signal(), if the timeout
resolution is set to CLOCK_REALTIME with a
set_timeout_resolution(CLOCK_REALTIME, RUTN_PTHRCONDTWAIT) call.
In this case, the caller of pthread_cond_timedwait() doesn't
return until the timeout expires.
The problem was that the sq_wakeup() kernel routine that wakes up
a light-weight process (LWP) as the result of a
pthread_cond_signal() call was not accounting for the fact that
an LWP that had blocked itself with a high-resolution timeout
pending (CLOCK_REALTIME) would be in a different sleep state than
an LWP that had blocked itself with a low-resolution time
pending (CLOCK_UNIX).
Therefore, when the sq_wakeup() routine checked the sleep state
of the LWP that was blocked with the high-resolution timeout
pending, it erroneously decided that this LWP was not currently
blocked/sleeping in the kernel on the associated sleep queue,
and it failed to wakeup the blocked LWP.
13. SAR #520:
On multi-CPU systems it is sometimes possible to read the wrong
POSIX time of day. This is due to the fact that a race
condition existed between one CPU reading the three POSIX timer
assist page variables at the same time that these same variables
were being updated on the other CPU.
The three POSIX timer assist page variables are used in the
computation of the current POSIX time of day.
When a mix of old and new POSIX timer assist variable values
are read, then the wrong POSIX time of day is computed/obtained,
and operations such as nanosleep(3C) will not function properly.
14. The following kernel panics occurred on systems with
an enabled kmadbg kernel module:
- The kernel PANICed in the fbs_srv_unreg_dev() routine
during the un-registration of a FBS Coupled timing device.
This routine was referencing the fbs data structure of the
virtual fbs scheduler after this structure had already been
kmem_free()ed.
- The kernel PANICed in the memfs_dirtrunc() routine during
a closely-coupled client boot up sequence. This routine was
referencing a kma block after the block had already been freed.
- The kernel PANICed in the sbc_msg_recv() routine when
processing a received message; typically, on the server SBC
when the server SBC had received fbsd(1M) messages from a
client SBC in a closely-coupled system. This routine was
referencing a kmem_alloc()ed sbc message structure after
it had already been kmem_free()ed.
15. When a debugger issues a stop request on a LWP that is scheduled
by a FBS scheduler, the kernel may panic if the LWP has exited
by the time that the FBS module processes the FBS scheduler stop
operation.
If the LWP structure has already been kmem_free()ed, and
re-allocated for a different purpose, then examining the
l_fbslwpp field in the previous LWP structure can cause a kernel
data access exception panic.
16. On single CPU moto-based platforms, the allocation and
use of the next available kernel trace record would
sometimes allocate the same trace record structure twice,
thus corrupting the information stored into this same trace
record for two trace events.
This corruption would occur when the tracing of a spurious
interrupt event took place just as the CPU was allocating a
kernel trace record for another event. The method used to
serialize the kernel trace record allocation was unable to
successfully hold out spurious interrupts.
17. If one of the LWPs in a multi-lwp or multi-threaded
application hit a debugger breakpoint and the entire process
was stopped, and one of the other LWPs in the same process
is currently scheduled on a running FBS scheduler, the running
scheduler was not being stopped. The FBS scheduler would
continue to run, even though it had a LWP that had been placed
into a stopped state.
18. SAR#498:
A problem with clocks /dev/rrtc/1cN. The stop command does not
always work.
SAR#501:
An accuracy problem with the RCIM real time clock.
19. SAR #540:
The pci/Driver.o provided in Patch Set #4 causes a
target system w/PCI Expansion connected to panic.
20. Adding or removing PCI bridges can dramaticly renumber the SCSI
device number convention. This can result in the gd driver
being open using old NODE numbers. The 'idmknod' does not
automaticly execute during boot sequence, since it is still
using the same kernel.
While opening invalid devices using bad node information is not
harmful, certain sequences in XFS used a gdsize entry point which
did not have similar protection. The result was a kernel crash
somewhere in beyond the single user boot phase, if the 'gd' nodes
had not been rebuilt.
21. netperf was hanging because allocb() calls were failing. This
occurred on the receiving system when heavy network traffic
occurred and the sending system was much faster than the
receiving system, or when the receiving system is low on
available memory. The receiving system was not processing this
load of packets fast enough such that a backup of queued packets
occurred. Eventually there were no whole pages available which
caused allocb to hang.
22. The number of cached rpcbind addresses was low. This could
have caused performance issues if an application was using
many different addresses (host, netid).
23. In fpsticky(), the wrong register was referenced causing bit_mask to
be set to a random value.
24. In fpsetmask(), the wrong register was referenced causing bit_mask to
be set to a random value.
25. memalign() corrupts memory.
26. Problem with count and number of vector registers participating in
varargs.
27. Problem in <signal.h> and <sys/signal.h> because of confusion
(for C++ only) due to sigaction the type and sigaction the function.
28. acpp had problems tokenizing a decimal constant ending with some
combination of "ULLull".
29. There were some Altivec and mpc750 instructions missing.
30. Quitting an nview debug session from within a multi-threaded or
multi-LWP (such as ADA) process that contains one or more
ienabled LWPs may cause the system to panic or hang.
This problem is due to a race in the kernel between the ienable
disconnection kernel daemon and the LWP within the process that
is executing the exit(2) kernel code. This race could cause
the ienabled LWP to be placed into the kernel's runqueue
twice, instead of just once. This problem causes either
kernel page fault panics or system hangs.
31. Using the ktrace(1) command may cause kernel stack overflow
panics or other system hangs, especially when ktrace(1) is used
on a system with a heavy interrupt load.
32. Fixes a data corruption problem within xfs filesystems.
33. The dump utility could not deal with the Yellow Dog Linux g++
compiler.
34. The use of ktrace(1) can sometimes cause the system to
hang, lock up, or panic with kernel stack overruns.
The kernel trace records are protected with a fast spin lock.
This fast spin lock is used when various places in the kernel call
the ktrace kernel code in order to log a kernel trace record.
The standard fast spin lock routines that are normally used to
lock and unlock a fast spin lock will always re-enable interrupts
after the fast spin lock has been unlocked.
However, several places in the kernel that call the kernel trace
code to log a ktrace record have interrupts disabled, and this
code expects that interrupts remain disabled during the logging
of the ktrace log record. The fact that interrupts were being
re-enabled during the logging of the kernel trace record is
what was causing the various kernel problems when ktrace(1)
was running.
35. ldexp() and ldexpl() has to return infinity if an infinity is
supplied as its input argument.
36. cpu_bias(2) sometimes returns back to the calling application
with r1 register value corrupted. This would only occur if the
application was under the control of the NightView debugger, and
its ublock was in a local memory remote with regards to NightView.
37. PowerMAX OS would occasionally panic when NightView was detached
from a process.
38. NightHawk systems with local memory were panicing, especially
when running top(1). Running all applications with a memory
policy of ublock_global would fix the problem.
39. PowerMAX OS 5.1 occasionally panics with the kernel routine
pvn_done() showing up in the stack traceback.
40. In certain debug situations it would be helpful to have the
cpu number where a kernel memory allocation or deallocation
occurred saved in the kmadbg circular list entries.
41. In the combine2(1) utility the os_dep_read_line() routine was
putting a null byte after the end of the buffer , rather than
into the last byte of the buffer. It then called fgets(3S) with
a count one less than the actual size of the buffer. This led
to the possibility of the null byte steeping on the FILE *
pointer that happened to be on the stack after the input buffer.
42. Probe of missing 8042PC chips on a single port VQP-M PMC card
fails, which leads to extended boot times while trying to
initialize non-existent keyboard interfaces.
43. pclose() eats process id's that don't belong to it. pclose() called
wait() instead of waitpid() which caused the problem. To determine
if we had a newer system where waitpid() could be employed, the
return value of uname(struct utsname *name) was being used, but
a '#undef uname' statement in common/lib/libc/port/stdio/popen.c
made it impossible to call the appropriate system service. The
'#undef' line was removed.
44. Kernel-mode address fault on kernel address 0x00000000. Kernel
page fault caused by ts_insque/sv_wait_sig bad link.
45. SAR #227:
SCSI_SCAN on NH6400 systems takes too long. Turning off the SCSISCAN
tunable causes system panics.
46. SAR #258:
Mounting of a removable hard disk sometimes fails. If
the disk is scanned at boot time, it is fine, but if
the disk is inserted into the system while it's up and
running, the first mount command fails with "drive not
ready". The second mount will work. This was NOT a
problem in PowerMAX OS 4.2 release. Something has changed.
47. Magneto optical(MO) SCSI drives behave poorly. hangs, and
data corruption, unable to support media sector sizes other
than 512 bytes.
48. SAR #583
Can't open disks on via above ID 6.
49. SAR #540:
The pci/Driver.o provided in PowerMAX OS 4.3 Patch Set #4 causes
a target system w/PCI Expansion connected to panic.
50. Interrupt sharing flags were not set for interrupt vectors assigned
to PCI expansion slots on Power Hawk 700 series platforms.
51. SAR #588:
After some time period an XFS mounted file system may be forced
into a readonly state. This problem arises due to lots of disk
write activity to the file system and an arbitrary open of the
special device file associated with it. The open causes
gd_initialize() to incorrectly perform an initialization of the
device again. This causes a perceived corruption of the file
system by the XFS driver which will then force the file system
to a readonly state by design.
52. SAR #613:
During system initialization a parallel fsck is performed on all
UFS disk partitions configured in /etc/vfstab. If there is more
than one of these partitions on the same disk which have the same
fsckpass number, then the system will panic. The cause of this
problem was the introduction of new SLEEP_LOCK()s in the gd/Driver.o
which used an improper wakeup priority.
Problem Resolution:
1. Changed /sbin/mountall to reference /sbin/swap instead of
/usr/sbin/swap
2. The tcpip portion of libnsl was corrected so that it would use
the proper initialization routine (_tcpip_init()) for allocation
of the data structure to hold the host data.
3. The function prototypes for these routines have been properly
declared in /usr/include/sys/posix_timers.h so that compilation
with the ec++ compiler succeeds.
4. The dispatcher code was corrected so that the IPL upon exit
would be the same as upon entrance.
5. The problem was a misplaced lwp flag setting designed to
prevent this race condition. The L_USYNCTIMEDOUT lwp flag
should have been set upon entry to the wakeup routine,
usync_timedsetrun(), but there was a possible exit from this
routine without the lwp flag being set. The blocking routine,
sq_block(), checks for this flag before blocking in order to
prevent blocking if the wakeup had already occurred. This
patch sets the flag upon entry to usync_timedsetrun().
6. Added a new tuneable, MAX_SEGSIZE, which specifies the maximum
size an address space segment can reach before a new, adjacent
segment is silently born. This puts an upper limit of the size of
the segment data structure the kernel uses to track address
space segments. The default value of MAX_SEGSIZE is 64 megabytes.
7. Corrected code in the kernel Driver mem/Driver.o that created PTEs
to differ slightly from code nearby that would re-use an already
existing PTE.
8. Replaced the address space VSID allocator with a more robust
algorithm that evenly scatters PTE allocations amoung all the
available PTE buckets.
9. Modified remote u-area access code in mem/Driver.o to properly
flush remote memory before and after the access.
10. Core dumps now contain the text sections of dynamically
loaded libraries.
11. The console processor CPU startup code was changed for the
auto-reboot case so that the 2nd CPU's 'msr' register is now
properly initialized before it enters the kernel's low-level
CPU startup code.
12. The sq_wakeup() kernel routine was modified so that it now
properly recognizes both high-resolution and low-resolution
timeout LWPs that are awaiting either a wakeup or timeout to
occur.
13. The coding for reading and updating the POSIX timer assist page
variables was modified so that the reading of these variables
will always result in reading a coherent set of values, even
when they are being updated at roughly the same time on the
other CPU.
14. All three of these problems were re-coded so that they no longer
reference an already kmem_free()ed memory block. Any needed
information from these kma memory areas is now stored into a
local variable before the kma block is freed.
15. The fix is to place a lwp_hold() on the LWP structure until
the FBS stop operation completes. In this way, the LWP structure
will remain allocated until after the FBS stop code can examine
the LWP structure.
16. The kernel trace record allocation code now disables interrupts
on the Power PC processor chip, rather than attempting to raise
the Interrupt Priority Level (IPL). By disabling interrupts inside
the processor, we are now able to successfully hold out spurious
interrupts while we allocate the next available ktrace record.
17. The kernel routine that is called by all LWPs in a process that
is being stopped is called prstopped(). Within this routine,
there is a call to the fbsstop_dbg() routine. This is the
routine that will additionally stop the corresponding FBS
scheduler of the calling LWP when that LWP is scheduled on a FBS
scheduler.
The fbsstop_dbg() call was located in the wrong place within the
prstopped() routine, such that only the very last LWP to stop
within the process would make the fbsstop_dbg() routine call.
The call to fbsstop_dbg() was moved forward within the
prstopped() routine so that now all LWPs calling prstopped()
will also call fbsstop_dbg(), and thus stop any corresponding
FBS scheduler that they may be currently scheduled on.
18. Changes were made to function rtc_z8536_timer_intr() and
set_time_constant_rcim().
19. Fixed code to discriminate between PCI bridges and other types
of Bridges. P4 fix added support for mixed multifunction devices
which also included PCI to PCI bridges.
20. Add invalid device protection to gdsize entry point.
21. allocb(), strioccall(), dupb(), pullupmsg(), stropen(), strioctl(),
and qattach() should not have been calling mem_resv_check() before
they call kmem_alloc() because they don't allocate whole pages.
A call to poolrefresh_outofmem() was added to mem_resv_check()
when it detects that there are no whole memory pages available.
22. The number of cached rpcbind addresses was increased from 6 to 24.
23. fpsticky() now references the correct register.
24. fpsetmask() now references the correct register.
25. Low order bit of freed blocks is now cleared.
26. Fix of count and number of vector registers participating in varargs.
27. Make sure we get only one "using std::sigaction"
28. acpp was tought to deal with any combination.
29. Added missing instructions to the assembler.
30. The window in time where it was possible for both the ienable
kernel daemon and the kernel exit code to both place the same
ienabled LWP into the runqueues was closed.
The ienable disconnection processing sequence was modified so
that the exit processing code can now always successfully detect
and skip over ienabled LWPs, and thus let the ienable kernel
daemon be the only one to place this LWP into the runqueue after
it has been successfully disconnected from the connected interrupt.
31. The kernel code that handles the locking and unlocking of the
fast-spin lock for kernel tracing was re-enabling the ability to
receive interrupts at a point in time when the low-level kernel
entry or exit code required interrupts to be held out.
The kernel code that handles the locking and unlocking of the
kernel trace fast-spin lock was modified so that it now
properly handles the disabling and re-enabling of interrupts.
32. The fix was to set the SM_WRITE flag before the call to
segmap_release in xfscr_writex() which is in xfs_rdwrx.c.
I also set the SM_ASYNC flag for performance reasons and
because it was logically correct. I removed the setting of
SM_DONTNEED because it was a bit presumptuous to assume that
because we just wrote the seg's mapped pages out that they
could be put at the head of the free list for immediate
reallocation. Setting the SM_WRITE flag causes the mapped pages
to be written out via the VOP_PUTPAGE macro upon release.
33. Modified dump utility so it could deal with Yellow Dog Linux
g++ compiler.
34. The kernel trace code now makes use of a pair of new fast spin
lock and unlock routines that only re-enable interrupts when
appropriate. These routines leave interrupts disabled if the
calling code expects interrupts to remain disabled during, and
also upon return, from logging a kernel trace record.
35. Added a segment of code that sets errno to ERANGE and return an
infinity.
36. Fixed. The /proc filesystem (used by Nightview to manipulate a
process's registers) was not properly flushing caches before and
after referencing data in a ublock that is in remote local
memory. Such flushing is necessary since the NightHawk platform
is not cache coherent with regards to memory accesses made to
remote local memories.
37. Fixed. The crash dump clearly showed that there was a race in the
/proc filesystem between grabbing a process and that process exiting.
If the timing was right, the /proc filesystem would end up with a
proc data structure in hand that was no longer in use.
38. Fixed. Cpu temperature measurement code that was added to
PowerMAX OS 5.0 was coded in a way that was sensitive to ublocks
migrating while the temperature measurement was in progress.
Also a new tuneable was added, GLOBAL_UBLOCKS, which if set
forces all ublocks to reside in global memory and forces all user
requests to migrate them to other memories to be ignored.
39. Fixed. b_numpages was increased in size from uchar_t to ushort_t
and all hackery associated with it being too small at size
uchar_t removed.
This change is safe (binary compatible) in the sense that all
other structure offsets and sizes in buf_t did not shift in
response to the b_numpages size change, so only the small amount
of code that actually utilize b_numpages needed to be replaced.
In addition, there does not appear to be any user-land programs
that utilize b_numpages for anything, other than, of course,
crash(1m).
40. The flag field in the kmadbg circular list entries was shortened
to a byte so a new cpu number (also a byte) could be added to
the entry without increasing the size of the entry.
41. The call to fgets(3S) in combine2(1) was corrected.
42. Corrected the probe logic so that only equipped keyboard interfaces
are initialized.
43. Removed '#undef uname' statement in common/lib/libc/port/stdio/popen.
c
which had made it impossible to call the appropriate system service.
44. The fix was to back-out four lines of code from proc/disp.c in
the swtch() module. The code that was backed out was new to
PowerMAX OS 4.3 patchset 3 and did not appear to be needed.
Heavy duty stress testing seems to have proved that out.
45. System failed to boot if SCSISCAN in gd driver was not enabled.
System will now spin up fixed media disk drives at first open,
if not already started at IPL time.
46. Disk drives would not start if not connected to the system at IPL
time. Logic to spin up the drive was only present at IPL time.
Special logic is now located in first open/last close to provide
a fresh re-initialization of core control code. Changed code in
ncr, is, via drivers to use async form of start_unit command for
disk drives when SCSISCAN flag is set, likewise similar command
is sent during first open, and status is polled for 40 seconds.
47. Enhanced Magneto optical SCSI drive support. Added code to
support drive initiated sync negotiation before data phase to
NCR driver. Added partial sector read/write I/O support to GD
driver. Now supports, 1K and 2K MO media sector sizes. Added
first open/last close logic for reload of critical structures.
Added code to convert reads/writes smaller than a sector size
in to full sector reads or RMW operations. Added extra code
to support general physical DMA lists, and as needed, ordered
I/O processing in fibre, ide, via, ncr, and is drivers.
48. Can't open disks on via above ID 6, device table for via
controller incorrectly sized, data corruption when scanning
ID 15 caused via driver to enforce narrow scsi bus rules.
Table size issue corrected.
49. SAR 540:
Fixed code to discriminate between PCI bridges and other types
of Bridges. Added support for mixed multifunction devices which
also included PCI to PCI bridges.
50. Set sharing flags in bsp control structures for appropriate
Power Hawk Series 700 platforms, (bspall, bspvgm5, bspvss4).
51. The gd_initialize() code has been corrected to test if the
file system has already been initialized before attempting
to re-initialize it.
52. The SLEEP_LOCK()s have been modified to use a more appropriate
wakeup priority.
Enhancements:
None.
Object(s) To Be Replaced:
/etc/conf/mdevice.d/gd
/etc/conf/mtune.d/gd
/etc/conf/mtune.d/mem
/etc/conf/pack.d/bspall/Driver.o
/etc/conf/pack.d/bspvgm5/Driver.o
/etc/conf/pack.d/bspvss4/Driver.o
/etc/conf/pack.d/elf/Driver.o
/etc/conf/pack.d/fs/Driver.o
/etc/conf/pack.d/gd/Driver.o
/etc/conf/pack.d/gd/space.c
/etc/conf/pack.d/io/Driver.o
/etc/conf/pack.d/kernel/Driver.o
/etc/conf/pack.d/kmadbg/Driver.o
/etc/conf/pack.d/mem/Driver.o
/etc/conf/pack.d/mem/space.c
/etc/conf/pack.d/memfs/Driver.o
/etc/conf/pack.d/name/Driver.o
/etc/conf/pack.d/pci/Driver.o
/etc/conf/pack.d/pkbd/Driver.o
/etc/conf/pack.d/proc/Driver.o
/etc/conf/pack.d/processorfs/Driver.o
/etc/conf/pack.d/procfs/Driver.o
/etc/conf/pack.d/rtc/Driver.o
/etc/conf/pack.d/scsi/Driver.o
/etc/conf/pack.d/stream/Driver.o
/etc/conf/pack.d/svc/Driver.o
/etc/conf/pack.d/ui/Driver.o
/etc/conf/pack.d/util/Driver.o
/etc/conf/pack.d/xfs/Driver.o
/sbin/mountall
/sbin/rc2
/stand/cp1
/usr/bin/combine2
/usr/ccs/bin/as
/usr/ccs/bin/dump
/usr/ccs/lib/acpp
/usr/ccs/lib/libc.a
/usr/ccs/lib/libc.so
/usr/include/signal.h
/usr/include/stdarg.h
/usr/include/stdvar_args.h
/usr/include/sys/buf.h
/usr/include/sys/dsk.h
/usr/include/sys/gd.h
/usr/include/sys/im.h
/usr/include/sys/ksynch.h
/usr/include/sys/ksynch_p.h
/usr/include/sys/lwp.h
/usr/include/sys/posix_timers.h
/usr/include/sys/signal.h
/usr/include/sys/swtimer.h
/usr/include/varargs.h
/usr/include/vm/vm_hat.h
/usr/lib/libc.so.1
/usr/lib/libnsl_i.a
/usr/lib/libnsl_i.so
/usr/lib/libthread.a
/usr/lib/libthread.so
Special Conditions for Installation:
1. Thebase-002 patch contains a change to the standalone console image.
In order to insure sane operation it is recommended to power cycle
or reset the host cpu board before the first reboot after adding the
patch.
Possible Side Effects:
1. Reference Line item 13: staticly linked applications that use
nanosleep(3C) and/or clock_gettime(3C) with CLOCK_REALTIME as the
clock_id must be relinked in order to take advantage of this fix.
return to index
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
#############################################################################
Software Update Name:base-002
Date Issued: 10/22/2001 16:44:06
Software Package: base pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: Night Hawk 6800, PowerMAXION, TurboHawk
Related Packages: 1553v5drv-001,cmds-001,crypt-001,crypt-int-001,
dec-001,fbs-001,fibre-001,gpib-001,inet-001,
is-001,man-001,mvc-001, ncr-001,netcmds-001,
nfs-002,trace-001,via-001.
Related SARs: #536, #495, #503, #520, #430, #108, #565, #498, #501,
#556, #576, #569, #227, #258, #583, #588, #613
Brief Description:
PowerMAX OS 5.1 base package release updates
##############################################################################
PowerMAX OS 5.1 Service Release 2
Software updates for PowerMAX OS are now released officially as "Service
Releases". A service release set is a collection of software package
updates released simultaneously. Individual update packages may have
dependencies on other update packages included in a service release.
Not all update packages in a "Service Release" may be available or
applicable on all supported platforms. It is important to install all
applicable software updates in order to ensure proper system operation.
"5.1SR2" is the abbreviated name for "PowerMAX OS 5.1 Service Release 2".
PowerMAX OS 5.1SR2 Software Update Package(s):
base-002 Base System Patch 002 (5.1SR2)
1553v5drv-001 1553v5-ABI User Level Driver Patch 001 (5.1SR2)
cmds-001 Advanced Commands Patch 001 (5.1SR2)
crypt-001 Domestic Encryption Utilities Patch 001 (5.1SR2)
crypt-int-001 International Encryption Utilities Patch 001 (5.1SR2)
dec-001 DEC Ethernet Driver Patch 001 (5.1SR2)
fbs-001 Frequency Based Scheduler Patch 001 (5.1SR2)
fibre-001 Fibre Channel Driver Patch 001 (5.1SR2)
gpib-001 NI PCI/PMC-GPIB Kernel Level Driver Patch 001 (5.1SR2)
inet-001 Internet Utilities Patch 001 (5.1SR2)
is-001 Night Hawk ISE SCSI Interface Module Patch 001 (5.1SR2)
man-001 On-line Manual Pages Patch 001 (5.1SR2)
mvc-001 Multiplexor VME Controller Driver Patch 001 (5.1SR2)
ncr-001 NCR Internal SCSI Controller Patch 001 (5.1SR2)
netcmds-001 Commands Networking Extension Patch 001 (5.1SR2)
nfs-002 Network File System Utilities Patch 002 (5.1SR2)
trace-001 KernelTrace Utilities Patch 001 (5.1SR2)
via-001 VIA SCSI Adapter Interface Patch 001 (5.1SR2)
##############################################################################
Problem Description:
1. SAR #536:
In order for additional swap devices identified in /etc/vfstab
to be added during bootup, the /sbin/mountall script must be
modified. The line: /usr/sbin/swap -a $special must be changed
to /sbin/swap -a $special
2. SAR's #495, #503:
When an application containing gethostbyname() was staticly
linked with libnsl.a and the gethostbyname() followed one of
the getservXXX() routines the application would core dump
with a segmentation violation. This was due to the tcpip
portion of libnsl accessing the same exact data structure for
its host data that was used for the services data from the
getservXXX() routine. It used the same data structure because
the initialization routine (_tcpip_init()) was not being invoked
in a static object for allocation of the data structure to hold
the host data.
3. The function prototypes for the set_timeout_resolution()
/get_timeout_resolution() routines are not properly declared in
an associated header file. This causes compilation errors under
the new ec++ compiler.
4. SAR #520:
A previous patch introduced a possibility in the dispatcher
wherein a real-time process could not preempt. The IPL could
be left at a level other than the one with which the dispatcher
was entered. This sometimes resulted in disallowing real-time
process preemption.
5. SAR #430:
The pthread_cond_timedwait() routine exposed a race condition
on PowerMAXION systems such that it could block and not be resumed.
On a PowerMAXION system if a process was running on CPU 0 and
was programmed to block, the wakeup routine scheduled on the
global callout queue could have been called via hardclk before the
process had actually reached the blocking routine.
As such, when the process did block it could not have been awakened
again because its wakeup routine had already run.
6. SAR #108:
Symptom: an application with an sbrk(2) area that incrementally
grew into the hundreds of megabytes would occasionally
self-deadlock waiting for the next chunk of virtual memory to be
allocated to the sbrk(2) area of that application.
Problem: one of the kernel data structures needed to manage
application virtual address space would grow so large that there
was danger that not enough *kernel* virtual address space could
be found to hold the next incarnation of that table.
7. Symptom: mlock(2)ing a region of application memory that had
been created with the SHM_NCACHE flag of shmget(2) would panic
the system.
Problem: code in the kernel Driver mem/Driver.o that created PTEs
differed slightly from code nearby that would re-use an already
existing PTE; the net effect of this difference was confusion on
the kernel's part with regard to the cached/not-cached state of
the pages created by shmget(2).
8. Symptom: sometimes a large application distributed among a large
number of local memory pools would self-deadlock when an attempt
was made to lock the application down in memory.
Problem: The way PTEs were allocated was defective, resulting in
all of an applications PTEs being allocated in at most one eighth
of the available PTE buckets. When a bucket was full of locked
down PTEs, and Yet Another had to go into that particular bucket,
the application would wait for a free PTE to become available in
that bucket. That wait would never complete if the application
itself was the owner of all the PTEs already in the bucket.
9. Symptom: The cpu_bias(2) system call would sometimes return with
r1 corrupted when run on nighthawks and when the process was under
the control of a debugger.
Problem: reading and writing of another process's u-area was not
cache coherent when that u-area was in remote memory. Access to
another process's u-area is something done only by a debugger.
10. Symptom: the core dumps of some applications that utilized
dynamically loaded libraries could not be processed by the
debugger.
Problem: the core dump logic in the kernel erroneously assumed
that the text of dynamically loaded libraries was accurately
represented by the corresponding text sections in the library
files, and failed to save off those regions of the address space
to the core file.
11. SAR #565:
The thread that calls pthread_cond_timedwait() does not return
when a another thread calls pthread_cond_signal(), if the timeout
resolution is set to CLOCK_REALTIME with a
set_timeout_resolution(CLOCK_REALTIME, RUTN_PTHRCONDTWAIT) call.
In this case, the caller of pthread_cond_timedwait() doesn't
return until the timeout expires.
The problem was that the sq_wakeup() kernel routine that wakes up
a light-weight process (LWP) as the result of a
pthread_cond_signal() call was not accounting for the fact that
an LWP that had blocked itself with a high-resolution timeout
pending (CLOCK_REALTIME) would be in a different sleep state than
an LWP that had blocked itself with a low-resolution time
pending (CLOCK_UNIX).
Therefore, when the sq_wakeup() routine checked the sleep state
of the LWP that was blocked with the high-resolution timeout
pending, it erroneously decided that this LWP was not currently
blocked/sleeping in the kernel on the associated sleep queue,
and it failed to wakeup the blocked LWP.
12. SAR #520:
On multi-CPU systems it was sometimes possible to read the wrong
POSIX time of day. This was due to the fact that a race
condition existed between one CPU reading the three POSIX timer
assist page variables at the same time that these same variables
were being updated on another CPU.
The three POSIX timer assist page variables are used in the
computation of the current POSIX time of day.
When a mix of old and new POSIX timer assist variable values
are read, then the wrong POSIX time of day is computed/obtained,
and operations such as nanosleep(3C) will not function properly.
13. The following kernel panics will occur on systems with
an enabled kmadbg kernel module:
- The kernel would panic in the fbs_srv_unreg_dev() routine
during the un-registration of a FBS Coupled timing device.
This routine was referencing the fbs data structure of the
virtual fbs scheduler after this structure had already been
kmem_free()ed.
14. When a debugger issues a stop request on a LWP that is scheduled
by a FBS scheduler, the kernel may panic if the LWP has exited
by the time that the FBS module processes the FBS scheduler stop
operation.
If the LWP structure has already been kmem_free()ed, and
re-allocated for a different purpose, then examining the
l_fbslwpp field in the previous LWP structure can cause a kernel
data access exception panic.
15. On single CPU platforms, the allocation and use of the next
available kernel trace record would sometimes allocate the
same trace record structure twice, thus corrupting the
information stored into this same trace record for two
trace events.
This corruption would occur when the tracing of a spurious
interrupt event took place just as the CPU was allocating
a kernel trace record for another event. The method used
to serialize the kernel trace record allocation was unable
to successfully hold out spurious interrupts.
16. If one of the LWPs in a multi-lwp or multi-threaded application
hit a debugger breakpoint and the entire process was stopped,
and one of the other LWPs in the same process was currently
scheduled on a running FBS scheduler, the running scheduler was
not being stopped. The FBS scheduler would continue to run,
even though it had a LWP that had been placed into a stopped state.
17. SAR#498:
A problem with clocks /dev/rrtc/1cN. The stop command does not
always work.
SAR#501:
An accuracy problem with the RCIM real time clock.
18. SAR #540:
The pci/Driver.o provided in Patch Set #4 causes a
target system w/PCI Expansion connected to panic.
19. Adding or removing PCI bridges can dramaticly renumber the SCSI
device number convention. This can result in the gd driver
being open using old NODE numbers. The 'idmknod' does not
automaticly execute during boot sequence, since it is still
using the same kernel.
While opening invalid devices using bad node information is not
harmful, certain sequences in XFS used a gdsize entry point which
did not have similar protection. The result was a kernel crash
somewhere in beyond the single user boot phase, if the 'gd' nodes
had not been rebuilt.
20. netperf was hanging because allocb() calls were failing. This
occurred on the receiving system when heavy network traffic
occurred and the sending system was much faster than the
receiving system, or when the receiving system was low on
available memory. The receiving system was not processing this
load of packets fast enough such that a backup of queued packets
occurred. Eventually there were no whole pages available which
caused allocb to hang.
21. The number of cached rpcbind addresses was low. This could have
caused performance issues if an application was using many
different addresses (host, netid).
22. The number of cached rpcbind addresses was low. This could
have caused performance issues if an application was using
many different addresses (host, netid).
23. In fpsticky(), the wrong register was referenced causing bit_mask to
be set to a random value.
24. In fpsetmask(), the wrong register was referenced causing bit_mask to
be set to a random value.
25. memalign() corrupts memory.
26. Problem with count and number of vector registers participating in
varargs.
27. Problem in <signal.h> and <sys/signal.h> because of confusion
(for C++ only) due to sigaction the type and sigaction the function.
28. acpp had problems tokenizing decimal constant ending with some
combination of "ULLull".
29. Quitting a nview debug session from within a multi-threaded or
multi-LWP (such as ADA) process that contains one or more
ienabled LWPs may cause the system to panic or hang.
This problem is due to a race in the kernel between the ienable
disconnection kernel daemon and the LWP within the process that
is executing the exit(2) kernel code. This race could cause
the ienabled LWP to be placed into the kernel's runqueue
twice, instead of just once. This problem causes either
kernel page fault panics or system hangs.
30. Using the ktrace(1) command may cause kernel stack overflow
panics or other system hangs, especially when ktrace(1) is used
on a system with a heavy interrupt load.
31. Fixes a data corruption problem within xfs filesystems.
32. The use of ktrace(1) can sometimes cause the system to
hang, lock up, or panic with kernel stack overruns.
The kernel trace records are protected with a fast spin lock.
This fast spin lock is used when various places in the kernel call
the ktrace kernel code in order to log a kernel trace record.
The standard fast spin lock routines that are normally used to
lock and unlock a fast spin lock will always re-enable interrupts
after the fast spin lock has been unlocked.
However, several places in the kernel that call the kernel trace
code to log a ktrace record have interrupts disabled, and this
code expects that interrupts remain disabled during the logging
of the ktrace log record. The fact that interrupts were being
re-enabled during the logging of the kernel trace record is
what was causing the various kernel problems when ktrace(1)
was running.
33. ldexp() and ldexpl() has to return infinity if an infinity is
supplied as its input argument.
34. cpu_bias(2) sometimes returns back to the calling application
with r1 register value corrupted. This would only occur if the
application was under the control of the NightView debugger, and
its ublock was in a local memory remote with regards to NightView.
35. PowerMAX OS would occasionally panic when NightView was detached
from a process.
36. NightHawk systems with local memory were panicing, especially
when running top(1). Running all applications with a memory
policy of ublock_global would fix the problem.
37. PowerMAX OS 5.1 occasionally panics with the kernel routine
pvn_done() showing up in the stack traceback.
38. In certain debug situations it would be helpful to have the
cpu number where a kernel memory allocation or deallocation
occurred saved in the kmadbg circular list entries.
39. In the combine2(1) utility the os_dep_read_line() routine was
putting a null byte after the end of the buffer , rather than
into the last byte of the buffer. It then called fgets(3S) with
a count one less than the actual size of the buffer. This led
to the possibility of the null byte steeping on the FILE *
pointer that happened to be on the stack after the input buffer.
40. pclose() eats process id's that don't belong to it. pclose() called
wait() instead of waitpid() which caused the problem. To determine
if we had a newer system where waitpid() could be employed, the
return value of uname(struct utsname *name) was being used, but
a '#undef uname' statement in common/lib/libc/port/stdio/popen.c
made it impossible to call the appropriate system service. The
'#undef' line was removed.
41. Kernel-mode address fault on kernel address 0x00000000. Kernel
page fault caused by ts_insque/sv_wait_sig bad link.
42. SAR #227:
SCSI_SCAN on NH6400 systems taking too long. Turning off the
SCSISCAN tunable causes system panics.
43. SAR #258:
Mounting of a removable hard disk sometimes fails. If
the disk is scanned at boot time, it is fine, but if
the disk is inserted into the system while it's up and
running, the first mount command fails with "drive not
ready". The second mount will work. This was NOT a
problem on PowerMAX OS 4.2 release. Something has changed.
44. Magneto optical(MO) SCSI drives behave poorly. hangs, and
data corruption, unable to support media sector sizes other
than 512 bytes.
45. SAR #583
Can't open disks on via above ID 6.
46. SAR #540:
The pci/Driver.o provided in PowerMAX OS 4.3 Patch Set #4 causes
a target system w/PCI Expansion connected to panic.
47. SAR #588:
After some time period an XFS mounted file system may be forced
into a readonly state. This problem arises due to lots of disk
write activity to the file system and an arbitrary open of the
special device file associated with it. The open causes
gd_initialize() to incorrectly perform an initialization of the
device again. This causes a perceived corruption of the file
system by the XFS driver which will then force the file system
to a readonly state by design.
48. SAR #613:
During system initialization a parallel fsck is performed on all
UFS disk partitions configured in /etc/vfstab. If there is more
than one of these partitions on the same disk which have the same
fsckpass number, then the system will panic. The cause of this
problem was the introduction of new SLEEP_LOCK()s in the gd/Driver.o
which used an improper wakeup priority.
Problem Resolution:
1. Changed /sbin/mountall to reference /sbin/swap instead of
/usr/sbin/swap
2. The tcpip portion of libnsl was corrected so that it would use
the proper initialization routine (_tcpip_init()) for allocation
of the data structure to hold the host data.
3. The function prototypes for these routines have been properly
declared in /usr/include/sys/posix_timers.h so that compilation
with the ec++ compiler succeeds.
4. The dispatcher code was corrected so that the IPL upon exit
would be the same as upon entrance.
5. The problem was a misplaced lwp flag setting designed to
prevent this race condition. The L_USYNCTIMEDOUT lwp flag
should have been set upon entry to the wakeup routine,
usync_timedsetrun(), but there was a possible exit from this
routine without the lwp flag being set. The blocking routine,
sq_block(), checks for this flag before blocking in order to
prevent blocking if the wakeup has already occurred. This
patch sets the flag upon entry to usync_timedsetrun().
6. Added a new tuneable, MAX_SEGSIZE, which specifies the maximum
size an address space segment can reach before a new, adjacent
segment is silently born. This puts an upper limit on the size of
the segment data structure the kernel uses to track address
space segments. The default value of MAX_SEGSIZE is 64 megabytes.
7. Corrected code in the kernel Driver mem/Driver.o that created PTEs
to differ slightly from code nearby that would re-use an already
existing PTE.
8. Replaced the address space VSID allocator with a more robust
algorithm that evenly scatters PTE allocations amoung all the
available PTE buckets.
9. Modified remote u-area access code in mem/Driver.o to properly
flush remote memory before and after the access.
10. Core dumps now contain the text sections of dynamically
loaded libraries.
11. The sq_wakeup() kernel routine was modified so that it now
properly recognizes both high-resolution and low-resolution
timeout LWPs that are waiting for either a wakeup or timeout to
occur.
12. The coding for reading and updating the POSIX timer assist page
variables was modified so that the reading of these variables
will always result in reading a coherent set of values, even
when they are being updated at roughly the same time on the
other CPU.
13. All three of these problems were re-coded so that they no longer
reference an already kmem_free()ed memory block. Any needed
information from these kma memory areas is now stored into a
local variable before the kma block is freed.
14. The fix is to place a lwp_hold() on the LWP structure until
the FBS stop operation completes. In this way, the LWP structure
will remain allocated until after the FBS stop code can examine
the LWP structure.
15. The kernel trace record allocation code now disables interrupts
on the Power PC processor chip, rather than attempting to raise
the Interrupt Priority Level (IPL). By disabling interrupts inside
the processor, we are now able to successfully hold out spurious
interrupts while we allocate the next available ktrace record.
16. The kernel routine that is called by all LWPs in a process that
is being stopped is called prstopped(). Within this routine,
there is a call to the fbsstop_dbg() routine. This is the
routine that will additionally stop the corresponding FBS
scheduler of the calling LWP when that LWP is scheduled on a FBS
scheduler.
The fbsstop_dbg() call was located in the wrong place within the
prstopped() routine such that only the very last LWP to stop
within the process would make the fbsstop_dbg() routine call.
The call to fbsstop_dbg() was moved forward within the
prstopped() routine so that now all LWPs calling prstopped()
will also call fbsstop_dbg(), and thus stop any corresponding
FBS scheduler on which they may be currently scheduled.
17. Changes were made to function rtc_z8536_timer_intr() and
set_time_constant_rcim().
18. Fixed code to discriminate between PCI bridges and other types
of bridges. P4 fix added support for mixed multifunction devices
which also included PCI to PCI bridges.
19. Added invalid device protection to gdsize entry point.
20. allocb(), strioccall(), dupb(), pullupmsg(), stropen(), strioctl(),
and qattach() should not have been calling mem_resv_check() before
they called kmem_alloc() because they don't allocate whole pages.
A call to poolrefresh_outofmem() was added to mem_resv_check()
when it detects that there are no whole memory pages available.
21. The number of cached rpcbind addresses was increased from 6 to 24.
22. The number of cached rpcbind addresses was increased from 6 to 24.
23. fpsticky() now references the correct register.
24. fpsetmask() now references the correct register.
25. low order bit of freed blocks is now cleared.
26. Fix of count and number of vector registers participating in varargs.
27. Make sure we get only one "using std::sigaction"
28. acpp was tought to deal with any combination.
29. The window in time where it was possible for both the ienable
kernel daemon and the kernel exit code to both place the same
ienabled LWP into the runqueues was closed.
The ienable disconnection processing sequence was modified so
that the exit processing code can now always successfully detect
and skip over ienabled LWPs, and thus let the ienable kernel
daemon be the only one to place this LWP into the runqueue after
it has been successfully disconnected from the connected interrupt.
30. The kernel code that handles the locking and unlocking of the
fast-spin lock for kernel tracing was re-enabling the ability to
receive interrupts at a point in time when the low-level kernel
entry or exit code required interrupts to be held out.
The kernel code that handles the locking and unlocking of the
kernel trace fast-spin lock was modified so that it now
properly handles the disabling and re-enabling of interrupts.
31. The fix was to set the SM_WRITE flag before the call to
segmap_release in xfscr_writex() which is in xfs_rdwrx.c.
I also set the SM_ASYNC flag for performance reasons and
because it was logically correct. I removed the setting of
SM_DONTNEED because it was a bit presumptuous to assume that
because we just wrote the seg's mapped pages out that they
could be put at the head of the free list for immediate
reallocation. Setting the SM_WRITE flag causes the mapped pages
to be written out via the VOP_PUTPAGE macro upon release.
32. The kernel trace code now makes use of a pair of new fast spin
lock and unlock routines that only re-enable interrupts when
appropriate. These routines leave interrupts disabled if the
calling code expects interrupts to remain disabled during, and
also upon return, from logging a kernel trace record.
33. Added a segment of code that sets errno to ERANGE and return an
infinity.
34. Fixed. The /proc filesystem (used by Nightview to manipulate a
process's registers) was not properly flushing caches before and
after referencing data in a ublock that is in remote local
memory. Such flushing is necessary since the NightHawk platform
is not cache coherent with regards to memory accesses made to
remote local memories.
35. Fixed. The crash dump clearly showed that there was a race in the
/proc filesystem between grabbing a process and that process exiting.
If the timing was right, the /proc filesystem would end up with a
proc data structure in hand that was no longer in use.
36. Fixed. Cpu temperature measurement code that was added to
PowerMAX OS 5.0 was coded in a way that was sensitive to ublocks
migrating while the temperature measurement was in progress.
Also a new tuneable was added, GLOBAL_UBLOCKS, which if set
forces all ublocks to reside in global memory and forces all user
requests to migrate them to other memories to be ignored.
37. Fixed. b_numpages was increased in size from uchar_t to ushort_t
and all hackery associated with it being too small at size
uchar_t removed.
This change is safe (binary compatible) in the sense that all
other structure offsets and sizes in buf_t did not shift in
response to the b_numpages size change, so only the small amount
of code that actually utilize b_numpages needed to be replaced.
In addition, there does not appear to be any user-land programs
that utilize b_numpages for anything, other than, of course,
crash(1m).
38. The flag field in the kmadbg circular list entries was shortened
to a byte so a new cpu number (also a byte) could be added to
the entry without increasing the size of the entry.
39. The call to fgets(3S) in combine2(1) was corrected.
40. Removed '#undef uname' statement in
common/lib/libc/port/stdio/popen.c which made it impossible to
call the appropriate system service.
41. The fix was to back-out four lines of code from proc/disp.c in
the swtch() module. The code that was backed out was new to
PowerMAX OS 4.3 patchset 3 and did not appear to be needed.
Heavy duty stress testing seems to have proved that out.
42. System failed to boot if SCSISCAN in gd driver is not enabled.
System will now spin up fixed media disk drives at first open,
if not already started at IPL time.
43. Disk drives would not start if not connected to system at IPL
time. Logic to spin up drive was only present at IPL time.
Special logic is now located in first open/last close to provide
a fresh re-initialization of core control code. Changed code in
ncr, is, via drivers to use async form of start_unit command for
disk drives when SCSISCAN flag is set, likewise similar command
is sent during first open, and status is polled for 40 seconds.
44. Enhanced Magneto optical SCSI drive support. Added code to
support drive initiated sync negotiation before data phase to
NCR driver. Added partial sector read/write I/O support to gd
driver. Now supports, 1K and 2K MO media sector sizes. Added
first open/last close logic for reload of critical structures.
Added code to covert reads/writes smaller than a sector size
in to full sector reads or RMW operations. Added extra code
to support general physical DMA lists, and as needed, ordered
I/O processing in fibre, ide, via, ncr, and is drivers.
45. Can't open disks on via above ID 6, device table for via
controller incorrectly sized, data corruption when scanning
ID 15 caused via driver to enforce narrow scsi bus rules.
Table size issue corrected.
46. SAR 540:
Fixed code to discriminate between PCI bridges and other types
of bridges. Added support for mixed multifunction devices which
also included PCI to PCI bridges.
47. The gd_initialize() code has been corrected to test if the
file system has already been initialized before attempting
to re-initialize it.
48. The SLEEP_LOCK()s have been modified to use a more appropriate
wakeup priority.
Enhancements:
None
Object(s) To Be Replaced:
/etc/conf/mdevice.d/gd
/etc/conf/mtune.d/gd
/etc/conf/mtune.d/mem
/etc/conf/pack.d/bspall/Driver.o
/etc/conf/pack.d/elf/Driver.o
/etc/conf/pack.d/fs/Driver.o
/etc/conf/pack.d/gd/Driver.o
/etc/conf/pack.d/gd/space.c
/etc/conf/pack.d/io/Driver.o
/etc/conf/pack.d/kernel/Driver.o
/etc/conf/pack.d/kmadbg/Driver.o
/etc/conf/pack.d/mem/Driver.o
/etc/conf/pack.d/mem/space.c
/etc/conf/pack.d/memfs/Driver.o
/etc/conf/pack.d/name/Driver.o
/etc/conf/pack.d/pci/Driver.o
/etc/conf/pack.d/proc/Driver.o
/etc/conf/pack.d/processorfs/Driver.o
/etc/conf/pack.d/procfs/Driver.o
/etc/conf/pack.d/rtc/Driver.o
/etc/conf/pack.d/scsi/Driver.o
/etc/conf/pack.d/stream/Driver.o
/etc/conf/pack.d/svc/Driver.o
/etc/conf/pack.d/ui/Driver.o
/etc/conf/pack.d/util/Driver.o
/etc/conf/pack.d/xfs/Driver.o
/sbin/mountall
/usr/bin/combine2
/usr/ccs/bin/as
/usr/ccs/bin/dump
/usr/ccs/lib/acpp
/usr/ccs/lib/libc.a
/usr/ccs/lib/libc.so
/usr/include/signal.h
/usr/include/stdarg.h
/usr/include/stdvar_args.h
/usr/include/sys/buf.h
/usr/include/sys/dsk.h
/usr/include/sys/gd.h
/usr/include/sys/im.h
/usr/include/sys/ksynch.h
/usr/include/sys/ksynch_p.h
/usr/include/sys/lwp.h
/usr/include/sys/posix_timers.h
/usr/include/sys/signal.h
/usr/include/sys/swtimer.h
/usr/include/varargs.h
/usr/include/vm/vm_hat.h
/usr/lib/libc.so.1
/usr/lib/libnsl_i.a
/usr/lib/libnsl_i.so
/usr/lib/libthread.a
/usr/lib/libthread.so
Special Conditions for Installation:
None.
Possible Side Effects:
1. Reference Line item 12: staticly linked applications that use
nanosleep(3C) and/or clock_gettime(3C) with CLOCK_REALTIME as the
clock_id must be relinked in order to take advantage of this fix.
return to index
================================================================================
Concurrent Computer Corporation Software Development
Software Service Release Report
##############################################################################
Software Update Name:base-002
Date Issued: 10/31/2001 12:05:28
Software Package: base pkg (Version 5.1)
OS Release: PowerMAX OS 5.1
Architecture: synergy
Platforms: Power Hawk 710/720/740
Related Packages: 1553v5drv-001,cmds-001,crypt-001,crypt-int-001,
dec-001,diskless-001,fbs-001,fibre-001,gpib-001,
inet-001,man-001,mvc-001,ncr-001,netcmds-001,
nfs-002,trace-001,via-001
Related SARs: #536, #495, #503, #520, #430, #108, #565, #498, #501,
#556, #576, #569, #227, #258, #583, #588, #613
Brief Description:
PowerMAX OS 5.1 base package release updates
##############################################################################
PowerMAX OS 5.1 Service Release 2
Software updates for PowerMAX OS are now released officially as "Service
Releases". A service release set is a collection of software package
updates released simultaneously. Individual update packages may have
dependencies on other update packages included in a service release.
Not all update packages in a "Service Release" may be available or
applicable on all supported platforms. It is important to install all
applicable software updates in order to ensure proper system operation.
"5.1SR2" is the abbreviated name for "PowerMAX OS 5.1 Service Release 2".
PowerMAX OS 5.1SR2 Software Update Package(s):
1553v5drv-001 1553v5-ABI User Level Driver Software Update 001 (5.1SR2)
base-002 Base System Software Update 002 (5.1SR2)
cmds-001 Advanced Commands Software Update 001 (5.1SR2)
crypt-001 Domestic Encryption Utilities Software Update 001 (5.1SR2)
crypt-int-001 International Encryption Utilities Software Update 001 (5.1SR2)
dec-001 DEC Ethernet Driver Software Update 001 (5.1SR2)
diskless-001 Diskless Systems Package Software Update 001 (5.1SR2)
fbs-001 Frequency Based Scheduler Software Update 001 (5.1SR2)
fibre-001 Fibre Channel Driver Software Update 001 (5.1SR2)
gpib-001 NI PCI/PMC-GPIB Kernel Level Driver Software Update 001 (5.1SR2)
inet-001 Internet Utilities Software Update 001 (5.1SR2)
man-001 On-line Manual Pages Software Update 001 (5.1SR2)
mvc-001 Multiplexor VME Controller Driver Software Update 001 (5.1SR2)
ncr-001 NCR/Symbios SCSI Controller Software Update 001 (5.1SR2)
netcmds-001 Commands Networking Extension Software Update 001 (5.1SR2)
nfs-002 Network File System Utilities Software Update 002 (5.1SR2)
trace-001 KernelTrace Utilities Software Update 001 (5.1SR2)
via-001 VIA SCSI Adapter Interface Software Update 001 (5.1SR2)
##############################################################################
Problem Description:
1. SAR #536:
In order for additional swap devices identified in /etc/vfstab
to be added during bootup, the /sbin/mountall script must be
modified. The line: /usr/sbin/swap -a $special must be changed
to /sbin/swap -a $special
2. SAR's #495, #503:
When an application containing gethostbyname() was staticly
linked with libnsl.a and the gethostbyname() followed one of
the getservXXX() routines the application would core dump
with a segmentation violation. This was due to the tcpip
portion of libnsl accessing the same exact data structure for
its host data that was used for the services data from the
getservXXX() routine. It used the same data structure because
the initialization routine (_tcpip_init()) was not being invoked
in a static object for allocation of the data structure to hold
the host data.
3. The function prototypes for the set_timeout_resolution()
/get_timeout_resolution() routines are not properly declared in
an associated header file. This causes compilation errors under
the new ec++ compiler.
4. SAR #520:
A previous patch introduced a possibility in the dispatcher
wherein a real-time process could not preempt. The IPL could
be left at a level other than the one with which the dispatcher
was entered. This sometimes resulted in disallowing real-time
process preemption.
5. SAR #430:
The pthread_cond_timedwait() routine exposed a race condition
on PowerMAXION systems such that it could block and not be resumed.
On a PowerMAXION system if a process was running on CPU 0 and
was programmed to block, the wakeup routine scheduled on the
global callout queue could have been called via hardclk before the
process had actually reached the blocking routine.
As such, when the process did block it could not have been awakened
again because its wakeup routine had already run.
6. SAR #108:
Symptom: an application with an sbrk(2) area that incrementally
grew into the hundreds of megabytes would occasionally
self-deadlock waiting for the next chunk of virtual memory to be
allocated to the sbrk(2) area of that application.
Problem: one of the kernel data structures needed to manage
application virtual address space would grow so large that there
was danger that not enough *kernel* virtual address space could
be found to hold the next incarnation of that table.
7. Symptom: mlock(2)ing a region of application memory that had
been created with the SHM_NCACHE flag of shmget(2) would panic
the system.
Problem: code in the kernel Driver mem/Driver.o that created PTEs
differed slightly from code nearby that would re-use an already
existing PTE; the net effect of this difference was confusion on
the kernel's part with regard to the cached/not-cached state of
the pages created by shmget(2).
8. Symptom: sometimes a large application distributed among a large
number of local memory pools would self-deadlock when an attempt
was made to lock the application down in memory.
Problem: The way PTEs were allocated was defective, resulting in
all of an applications PTEs being allocated in at most one eighth
of the available PTE buckets. When a bucket was full of locked
down PTEs, and Yet Another had to go into that particular bucket,
the application would wait for a free PTE to become available in
that bucket. That wait would never complete if the application
itself was the owner of all the PTEs already in the bucket.
9. Symptom: The cpu_bias(2) system call would sometimes return with
r1 corrupted when run on nighthawks and when the process was under
the control of a debugger.
Problem: reading and writing of another process's u-area was not
cache coherent when that u-area was in remote memory. Access to
another process's u-area is something done by only a debugger.
10. Symptom: the core dumps of some applications that utilized
dynamically loaded libraries could not be processed by the
debugger.
Problem: the core dump logic in the kernel erroneously assumed
that the text of dynamically loaded libraries was accurately
represented by the corresponding text sections in the library
files, and failed to save off those regions of the address space
to the core file.
11. On a console auto-reboot operation, such as a "shutdown ... -i6",
or on an auto-reboot after a system panic, the 2nd CPU was
entering the kernel's start routine with a bad 'msr' register value.
(The 'msr' register controls CPU attributes such as whether
or not virtual memory is enabled, and whether or not
the instruction and data caches are enabled, etc.)
In the auto-reboot case, a bad 'msr' register value could
cause us to write to random locations in memory while making
some early subroutine calls in the kernel's low-level startup
routine, before the 2nd CPU's registers could be properly
initialized by the kernel.
Eventually, the kernel would sometimes end up panic()ing in a
random fashion, when it tried to use the corrupted memory
locations.
12. SAR #565:
The thread that calls pthread_cond_timedwait() does not return
when a another thread calls pthread_cond_signal(), if the timeout
resolution is set to CLOCK_REALTIME with a
set_timeout_resolution(CLOCK_REALTIME, RUTN_PTHRCONDTWAIT) call.
In this case, the caller of pthread_cond_timedwait() doesn't
return until the timeout expires.
The problem was that the sq_wakeup() kernel routine that wakes up
a light-weight process (LWP) as the result of a
pthread_cond_signal() call was not accounting for the fact that
an LWP that had blocked itself with a high-resolution timeout
pending (CLOCK_REALTIME) would be in a different sleep state than
an LWP that had blocked itself with a low-resolution time
pending (CLOCK_UNIX).
Therefore, when the sq_wakeup() routine checked the sleep state
of the LWP that was blocked with the high-resolution timeout
pending, it erroneously decided that this LWP was not currently
blocked/sleeping in the kernel on the associated sleep queue,
and it failed to wakeup the blocked LWP.
13. SAR #520:
On multi-CPU systems it is sometimes possible to read the wrong
POSIX time of day. This is due to the fact that a race
condition existed between one CPU reading the three POSIX timer
assist page variables at the same time that these same variables
were being updated on the other CPU.
The three POSIX timer assist page variables are used in the
computation of the current POSIX time of day.
When a mix of old and new POSIX timer assist variable values
are read, then the wrong POSIX time of day is computed/obtained,
and operations such as nanosleep(3C) will not function properly.
14. The following kernel panics occurred on systems with
an enabled kmadbg kernel module:
- The kernel PANICed in the fbs_srv_unreg_dev() routine
during the un-registration of a FBS Coupled timing device.
This routine was referencing the fbs data structure of the
virtual fbs scheduler after this structure had already been
kmem_free()ed.
- The kernel PANICed in the memfs_dirtrunc() routine during
a closely-coupled client boot up sequence. This routine was
referencing a kma block after the block had already been freed.
- The kernel PANICed in the sbc_msg_recv() routine when
processing a received message; typically, on the server SBC
when the server SBC had received fbsd(1M) messages from a
client SBC in a closely-coupled system. This routine was
referencing a kmem_alloc()ed sbc message structure after
it had already been kmem_free()ed.
15. When a debugger issues a stop request on a LWP that is scheduled
by a FBS scheduler, the kernel may panic if the LWP has exited
by the time that the FBS module processes the FBS scheduler stop
operation.
If the LWP structure has already been kmem_free()ed, and
re-allocated for a different purpose, then examining the
l_fbslwpp field in the previous LWP structure can cause a kernel
data access exception panic.
16. On single CPU moto-based platforms, the allocation and
use of the next available kernel trace record would
sometimes allocate the same trace record structure twice,
thus corrupting the information stored into this same trace
record for two trace events.
This corruption would occur when the tracing of a spurious
interrupt event took place just as the CPU was allocating a
kernel trace record for another event. The method used to
serialize the kernel trace record allocation was unable to
successfully hold out spurious interrupts.
17. If one of the LWPs in a multi-lwp or multi-threaded
application hit a debugger breakpoint and the entire process
was stopped, and one of the other LWPs in the same process
is currently scheduled on a running FBS scheduler, the running
scheduler was not being stopped. The FBS scheduler would
continue to run, even though it had a LWP that had been placed
into a stopped state.
18. SAR#498:
A problem with clocks /dev/rrtc/1cN. The stop command does not
always work.
SAR#501:
An accuracy problem with the RCIM real time clock.
19. SAR #540:
The pci/Driver.o provided in Patch Set #4 causes a
target system w/PCI Expansion connected to panic.
20. Adding or removing PCI bridges can dramaticly renumber the SCSI
device number convention. This can result in the gd driver
being open using old NODE numbers. The 'idmknod' does not
automaticly execute during boot sequence, since it is still
using the same kernel.
While opening invalid devices using bad node information is not
harmful, certain sequences in XFS used a gdsize entry point which
did not have similar protection. The result was a kernel crash
somewhere in beyond the single user boot phase, if the 'gd' nodes
had not been rebuilt.
21. netperf was hanging because allocb() calls were failing. This
occurred on the receiving system when heavy network traffic
occurred and the sending system was much faster than the
receiving system, or when the receiving system is low on
available memory. The receiving system was not processing this
load of packets fast enough such that a backup of queued packets
occurred. Eventually there were no whole pages available which
caused allocb to hang.
22. The number of cached rpcbind addresses was low. This could
have caused performance issues if an application was using
many different addresses (host, netid).
23. In fpsticky(), the wrong register was referenced causing bit_mask to
be set to a random value.
24. In fpsetmask(), the wrong register was referenced causing bit_mask to
be set to a random value.
25. memalign() corrupts memory.
26. Problem with count and number of vector registers participating in
varargs.
27. Problem in <signal.h> and <sys/signal.h> because of confusion
(for C++ only) due to sigaction the type and sigaction the function.
28. acpp had problems tokenizing a decimal constant ending with some
combination of "ULLull".
29. There were some Altivec and mpc750 instructions missing.
30. Quitting an nview debug session from within a multi-threaded or
multi-LWP (such as ADA) process that contains one or more
ienabled LWPs may cause the system to panic or hang.
This problem is due to a race in the kernel between the ienable
disconnection kernel daemon and the LWP within the process that
is executing the exit(2) kernel code. This race could cause
the ienabled LWP to be placed into the kernel's runqueue
twice, instead of just once. This problem causes either
kernel page fault panics or system hangs.
31. Using the ktrace(1) command may cause kernel stack overflow
panics or other system hangs, especially when ktrace(1) is used
on a system with a heavy interrupt load.
32. Fixes a data corruption problem within xfs filesystems.
33. The dump utility could not deal with the Yellow Dog Linux g++
compiler.
34. The use of ktrace(1) can sometimes cause the system to
hang, lock up, or panic with kernel stack overruns.
The kernel trace records are protected with a fast spin lock.
This fast spin lock is used when various places in the kernel call
the ktrace kernel code in order to log a kernel trace record.
The standard fast spin lock routines that are normally used to
lock and unlock a fast spin lock will always re-enable interrupts
after the fast spin lock has been unlocked.
However, several places in the kernel that call the kernel