Prior Release Notes

This kit provides two new kernel tunable variables, tcp_rst_win and tcp_syn_win to protect systems against potential vulnerabilities called TCP RST attack and TCP SYN attack. For more information, see “Potential Security Vulnerability Identified ” and a revised sys_attrs_inet(8) reference page, which is installed with this kit.

A new option, -a, has been added to the fuser command to expand a query to search of all cluster members. See the fuser(8) reference page for more information.

This kit provides a new boolean /etc/printcap option, sr, to suppress the reprinting of jobs under conditions that indicate to the print daemon that a reprint is needed. The syntax for this entry is similar to that of the sh (suppress header) option.

You can use this option to suppress an unexpected or unneeded reprinting of jobs that are completed but are reprinted a second time due to miscommunication between the printer and the print daemon.

Be aware that if you set this option, incomplete jobs that trigger reprint conditions will not reprint.

A fix to remote job reprinting that this patch kit provides can trigger reprints which, under conditions previously described, do not appear to be needed.

The Name Service Switch (NSS) has been added to Tru64 UNIX as a replacement for the svc.conf database service selection. The NSS provides a more extensible database service selector and supports a dynamic list of databases. Using the NSS allows you to add LDAP as a source for netgroup data.

Configuring the NSS converts entries from the /etc/svc.conf file into entries for /etc/nsswitch.conf file. The/etc/svc.conf is then only used for pre-nsswitch statically-built applications and sendmail. For more information about this feature, see nssetup(8), nsswitch(4), and nss2svc(8)

This patch kit provides the following new hardware support.

This kit replaces the Motif 2.1 Advanced Developer's Kit (ADK) with a production version of Motif 2.1. This new version will be supported in future Version 5.1B releases. The production version of Motif 2.1 will also be available for downloading from the Web.

This kit provides a security feature to prevent the execution of instructions that reside in heap or other data areas of process memory. The result is additional protection against buffer overflow exploits. This feature is similar in concept to Tru64 UNIX executable stack protection.

This feature is implemented as a dynamic sysconfig tunable variable, executable_data, in the proc subsystem. The supported settings allow system administrators to cause requests from privileged processes for writable and executable memory to fail, or to be treated as a request for writable memory, and to optionally generate a message when such a request occurs.

In a buffer overflow exploitation, an attacker feeds a privileged program an unexpectedly large volume of carefully constructed data through inputs such as command line arguments and environment variables. If the program is not coded defensively, the attacker can overwrite areas of memory adjacent to the buffer.

Depending upon the location of the buffer (stack, heap, data area), the attacker can deceive these programs into executing malicious code that takes advantage of the program's privileges or alter a security-sensitive program variable to redirect program flow.

With some expertise, such an attack can be used to gain root access to the system.

Enabling the executable_data tunable changes a potential system compromise into, at worst, a denial-of-service attack. A vulnerable program may still contain a buffer overflow, but an exploit that writes an instruction stream into the buffer and attempts to transfer control to those instructions will fail, because memory protection will prohibit instruction execution from that area of memory.

Many applications never execute from the memory even though they unnecessarily request write-execute memory directly or as a result of an underlying function acting on their behalf. By substituting writable memory for the requested write-execute memory, the executable_data tunable allows such applications to benefit from the additional protection without requiring application modification. See sys_attrs_proc(5) for more information.

Before enabling executable_data (changing it from the default value of 0), you must run the /usr/sbin/javaexecutedata script. Otherwise, privileged Java™ applications will fail in unpredictable ways. See javaexecutedata(8) for more information.

	NOTE: The Java language interprets byte code at runtime. Unless marked as exempt, privileged applications written in Java will receive an error when they attempt to execute instructions residing in the unexecutable memory. The manner in which these errors are handled is application-specific and thus unpredictable. This is why you must run the /usr/sbin/javaexecutedata before you enable executable_data.

The following example demonstrates the failing behavior to expect for a privileged process if execute_data is set to 53 but runs the /usr/sbin/javaexecutedata script. Other Java applications run with privilege may exhibit different (but still failing) behavior.

# java -classic -jar SwingSet2.jar
Process 1185 Invalid write/execute mmap call denied.
Process 1185 Invalid write/execute mmap call denied.
Process 1185 Invalid write/execute mmap call denied.
(...)
Process 1185 Invalid write/execute mmap call denied.
Process 1185 Invalid write/execute mmap call denied.
**Out of memory, exiting**

The following example demonstrates the failing behavior to expect for a privileged processes if execute_data is set to 37 but runs the /usr/sbin/javaexecutedata script. Other java applications run with privilege may exhibit different (but still failing) behavior.

# java -classic -jar SwingSet2.jar
Process 1185 Invalid write/execute mmap call modified.
Process 1185 Invalid write/execute mmap call modified.
 (...)
Process 1185 Invalid write/execute mmap call modified.
Process 1185 Invalid write/execute mmap call modified.
Process 1185 Invalid write/execute mmap call modified.
SIGSEGV   11*  segmentation violation
(...)
Abort (core dumped)

Certain privileged Pascal programs may also fail when executable_data is enabled. Such programs should also be marked as exempt, using the new chatr utility as follows:

$chatr +ed enable priv_pascal_executable
  current values:
     64-bit COFF executable
     execute from data: disabled
  new values:
     64-bit COFF executable
     execute from data: enabled

See chatr(1) for information about the chatr utility.

Patches in this kit provide enhancements to the performance manager metrics server daemon, pmgrd, and the collect utility.

Performance Manager Metrics Server Daemon (pmgrd)

The following features have been added to pmgrd:

• Support for monitoring the disk I/O rates.

  Enables pmgrd to provide details on disk I/O rates, such as the average number of bytes transferred per second and the average number of transfers completed per second over the past 1 minute, 5 minutes, 30 minutes, and 60 minutes.

• Support for monitoring the AdvFS statistics.

  Enables pmgrd to provide the following types of details on AdvFS file systems:

  • The domain name

  • The fileset name

  • Number of files and blocks

  • Soft and hard limits of files

  • Soft and hard limits of blocks

  • The status of user and group quotas

  • Grace time and fileset clone information

  It can also provide AdvFS volume details such as available blocks, percentage of volume used, I/O consolidation mode, and the number of read/write blocks. The new MIB file pmAdvfs.mib has been added to provide these statistics.

  The collect utility displays these new AdvFS statistics. (See “New Features Added to collect Utility”).

As a result of the improvements made to pmgrd, we recommend that you use the SysMan Menu to manage AdvFS file systems rather than the dtadvfs graphical user interface and the advfsd daemon. To use SysMan Menu, select Storage - File System Management Utilities - Advanced File System (AdvFS) Utilities. You can also enter the following command:

# sysman advfs

See pmgrd(8) for more details.

Enhancements to the SysMan Menu file system management applications delivered in this patch kit significantly improve their performance.

This kit provides the following new control option for the /usr/sbin/audit_tool command:

# /usr/sbin/audit_tool -. [path]

This option causes audit_tool to use [path] for the archive/recovery directory that contains archived audit logs, thereby overriding the directory specified in the audit log, which by default is /var/audit.

This patch kit modifies the Environmental Monitoring daemon, envmond, to improve performance on systems with many sensors.

With the default monitor period of envmond (ENVMON_MONITOR_PERIOD), systems having large number of sensors may experience a performance degradation. The changes to envmond address this problem by polling sensors at a lower frequency.

The Security Integration Architecture (SIA) sialog logging process is only intended for use in debugging SIA problems. It should not be enabled for extended periods of time. Doing so can cause login delays or other problems.

Use the audit subsystem to monitor authentications on the system, not the sialog process

To disable sialog debug logging, delete the /var/adm/sialog file. For more information, see the sialog(4) and sia_log(3) reference pages and the Tru64 UNIX Security Programming manual.

Note that when used in a TruCluster Server cluster, the sialog file is a cluster-wide file.

Prior to setting the tunable attribute executable_data to a non-zero value, you must run the following script:

# /usr/sbin/javaexecutedata

The industry standard TCP specification, RFC793, has a vulnerability in which an attacker can reset established TCP connections using the TCP RST (Reset) or SYN (Synchronize) flags.

These packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.

The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP. According to RFC 793, an RST or SYN attack is only possible when the source IP address and TCP port can be forged (also called spoofed). In that case TCP sessions, including Telnet, SSH, SFTP and HTTP may be disconnected without warning. TCP sessions that have been disconnected can be re-established.

Normally, a TCP SYN packet (request for a new connection) that arrives on a server using a matching IP address, port number, and matching sequence number for an existing connection causes a TCP RST packet to be returned to the client. An attacker can guess the proper sequence number, along with the port and IP addresses, to cause an existing connection to be terminated with a TCP RST.

When a client is rebooted without closing an old connection to the server, a subsequent attempt to connect to the server that matches the old connection tuple and sequence number will require a TCP RST in order to purge the old (stale) connection.

HP has addressed these potential vulnerabilities, called TCP RST attack and TCP SYN attack, by providing two new kernel tunable variables, tcp_rst_win (TCP RST window) and tcp_syn_win (TCP SYN window).

These variables mitigate the TCP reset attack by reducing the window sizes in which a TCP RST/SYN packet will be accepted by the Tru64 UNIX system.

The attributes for these variables are described in a revised sys_attrs_inet(5) reference page included in this kit.

After the patch kit is installed, you can adjust the variables using the sysconfig and sysconfigdb commands, as described in the following sections.

Adjusting the tcp_rst_win Variable

You can adjust the TCP RST window variable, tcp_rst_win, as follows:

# sysconfig -q inet tcp_rst_win inet: tcp_rst_win = -1 # sysconfig -r inet tcp_rst_win=2048 tcp_rst_win: reconfigured # sysconfig -q inet tcp_rst_win inet: tcp_rst_win = 2048 # sysconfig -q inet tcp_rst_win /tmp/tcp_rst_win_merge # sysconfigdb -m -f /tmp/tcp_rst_win_merge inet # sysconfigdb -l inet inet: tcp_rst_win = 2048

Adjusting the tcp_syn_win Variable

You can adjust the TCP SYN window variable, tcp_syn_win, as follows:

# sysconfig -q inet tcp_syn_win inet: tcp_syn_win = -1 # sysconfig -r inet tcp_syn_win=2048 tcp_syn_win: reconfigured # sysconfig -q inet tcp_syn_win inet: tcp_syn_win = 2048 # sysconfig -q inet tcp_syn_win /tmp/tcp_syn_win_merge # sysconfigdb -m -f /tmp/tcp_syn_win_merge inet # sysconfigdb -l inet inet: tcp_syn_win = 2048

As a side effect of resolving issues with multiple access to the changer, the changer driver now requires a short period of exclusive access to the changer device as part of opening the device. For applications that have several threads or processes accessing a single changer simultaneously, this can result in waits for access to the changer device in the process of an open call. That wait can be lengthy as some changer commands can have long response times.

In general this behavioral change will not affect the overall throughput to a changer device, as this wait would have occurred at the time of any I/O (for example, IOCTLS) to the changer.

If having the changer wait in this fashion presents a problem, the old behavior can be approximated by passing either the O_NONBLOCK or O_NDELAY flags at the open of the changer device. In that situation the first actual I/O (usually an IOCTL) may incur the wait as the open is partially delayed in that case.

The net_tcp_stray_packet, net_udp_stray_packet, and net_tcp_rejectd_conn network events are handled by the audit subsystem differently from other auditable events. As a result, these events may be placed into the audit log out of order with respect to other events.

Previously, the sorting of audit data on single CPU systems was unnecessary. This changed, however, when the capability for auditing these network events was introduced. Now, to view these network events in order with respect to other events, you must sort the data on a single CPU system. To do this, use the audit_tool -S command.

The tunable attribute new_wire_method has been retired. After you install this kit, setting new_wire_method to either 0 or 1 will no longer affect your system.

When using AdvFS administration commands, the advfsd and smsd daemons rescan filesets, domains and volumes for system information. Depending on the number of filesets, domains, and volumes, you may experience a pause — sometimes quite long — between the commands.

If you experience this performance degradation, you may want to stop advfsd (required for dtadvfs, the AdvFS graphical user interface) and smsd (required for SysMan Station) daemons before running multiple AdvFS administration commands.

See “New Variable Aids Performance of AdvFS Administration Commands” for information on disabling the advfsd daemon at boot time.

To temporarily stop the daemons enter the following commands:

# /sbin/init.d/advfsd stop
# /sbin/init.d/smsd stop
 

To restart the daemons enter the following commands:

# /sbin/init.d/advfsd start
# /sbin/init.d/smsd start
 

When upgrading older releases of sendmail, be aware that the 5.1B version of sendmail has MIME header/content marker size limits and message header length limits. These limits have been added to stop a Denial of Service (DoS) attack on the sendmail server. The values default to the following:

MIME Header Length Size = 2048 characters
MIME Content Marker Size = 1024 characters

The MaxHeadersLength value is the maximum message header length allowed and its size can be installation dependent (the value defaults to 8192 bytes).

Some legacy applications may be affected by this security addition if the application is sending mail messages with long lines of text and no new-line markers. These limitations may cause sendmail to insert a carriage return at these boundaries.

To revert back to the old sendmail behavior, do the following:

For certain applications where Oracle instances are running in a cluster and Memory Channel is used as the interconnect, console messages of “rdg: out of objects” may occur.

Tuning the sysconfigtab value max_objs (under the rdg subsystem) can eliminate these messages. We recommend doubling your current value.

Because this parameter is not dynamic, you can only change it by modifying the sysconfigtab file and rebooting your system. After doing this, observe your cluster to see if the messages have been eliminated.

You can set this value to a maximum of 50,000.

If a problem with your Smart Array controller generates the following message, try rebooting your system:

Smart Array at ciss(1) not responding - disabled.

If the reboot does not re-enable the hardware, you will need to call your HP support representative to have the unit repaired.

This kit fixes a potential security vulnerability in IP security (IPsec). If you have one or more IPsec connections configured on your system, you need to ensure that you have restricted access to each IPsec connection based on the identity of the remote hosts. You can accomplish this after installing this kit by starting the IPsec SysMan configuration tool from the command line:

# sysman ipsec

Once you have started SysMan, you will need to modify the configuration of each IPsec and IKE connection to add the identity of the remote hosts that are allowed to connect.

You enter this information on the third dialog box you see during the connection configuration wizard; the dialog box is titled “Manage IPsec: Add/Modify Connection: IKE Proposal.” Although you can leave the “Restrict To The Following Remote IDs” list empty, doing so will mean that any identity given to the local machine by the remote hosts will be considered valid as long as they send the correct certificate or preshared key.

Repeated simultaneous overwriting of many files can cause retransmitted writes to be processed after recent writes of a file to the same location. This problem occurs more often on systems configured with a LAN cluster interconnect than on those configured with Memory Channel.

This behavior is inherent in the "stateless" design of NFS. Although the behavior has been mitigated via a "duplicate request cache" that replays old replies instead of reexecuting retransmitted requests, extremely heavy loads on large systems can overwhelm the cache when requests are stalled. Customers are unlikely to see problems because applications rarely rewrite files almost immediately.

If the problem occurs, the NFS server displays the following message several times a minute on the system console, indicating that the NFS server is being overwhelmed with requests :

"NFS server xxx not responding"

When an "overwhelmed duplicate request cache" condition has occurred, the NFS client will display multiple occurrences of either of the following messages:

NFS3 server xxx not responding still trying
NFS3 server xxx ok

NFS2 server xxx not responding still trying
NFS2 server xxx ok

This indicates that the client is observing transient unresponsive periods at the server. This is the only notification that the client will display if the server's duplicate request cache becomes overwhelmed. When the client detects this behavior, it increases the retransmission interval until it gets a response from the server. This behavior is generally undistinguishable from the server going up and down, except that the messages are displayed with such frequency that the server system/member cannot have gone down and then come back up in that short an interval.

You can minimize the likelihood of these problems as follows:

You can monitor the number of NFS retransmissions using the nfsstat -c command. The retrans field indicates the number of retransmissions. A retransmission rate higher than 2% indicates a potential problem.

The following example shows the output from the nfstat -c command. The retransmission fields are marked with asterisks (*). This example is of a client workstation in a typical environment.

If an overwhelmed duplicate request cache condition occurs, we recommend you perform one or more of the following tasks:

To avoid overwhelming the duplicate request cache:

Use the netstat command to determine if your network is saturated. For Ethernet networks, a high number of collisions indicates that the network may be saturated. The following example shows the output from the netstat -I tu0 command:

The NFS server maintains a list of recently completed nonrepeatable requests. This list is used to reply to client retransmissions of the request in the event that the initial request transmission's reply was lost or that the server took too long to satisfy the request.

Problems may occur with the duplicate request cache in some cases, under heavy NFS server load and over high aggregate network bandwidth involving changes to file systems (changes caused by the use of the creat, link, unlink, mkdir, rmdir, truncate, utimes, and write commands). These problems can occur if all the elements in the duplicate request cache are cycled between an initial client transmission and subsequent retransmission. If this occurs, the NFS server cannot detect that the retransmission is in fact a retransmission. This may result in the repetition of a request and may cause out-of-order writes or truncation and subsequent retruncation of a file.

This patch kit provides a tuning variable, nfs_dupcache_size, to control the size of the NFS server's duplicate request cache, which is measured in the number of elements that are allocated at NFS server initialization.

If it is determined that the size of the duplicate cache needs to be modified, you should change nfs_dupcache_size. The new value for nfs_dupcache_size should be set to equal two times the value of nfs_dupcache_entries.

You must use the dbx command to modify nfs_dupcache_size. There is no sysconfig interface to this tuning variable.

On large system configurations, certain hwmgr commands may take a long time to run and can produce voluminous output. For example:

The output from these commands is gathered and sorted in memory before the report begins to be displayed. In a system with hundreds or thousands of attached storage units, the processing stage can take several minutes and you will not see any output during that time.

When using the command hwmgr -view devices -cluster, the time can be even longer and the size of the report can be larger because in most clustered configurations, mass storage devices are reported by every member and thus appear multiple times in the generated report. Therefore, you may need to relax the memory limits for the process running the command, because with such a large number of devices in the configuration, the system may be unable to gather all of the data with the default memory limit.

We recommend that you run commands that generate large reports in the background (for example, in a batch job) and save their output into a file or set of files for subsequent examination or historical comparison.

A patch in this kit addresses a spin lock issue in the LSM kernel that may occur under extremely heavy I/O loads on multiprocessor systems.

To reduce the need for certain spin locks in the kernel I/O code, you can set a new sysconfigtab variable, Max_LSM_IO_PERFORMANCE, to 1 (the default is 0). Doing this will increase LSM I/O performance if it is found that performance is degraded because of a highly contentious spin lock.

Note that using this spin lock performance feature reduces some of the debugging statistics that are normally maintained.

In order to use this feature, you must allow at least one LSM I/O daemon (voliod). The voliod daemon was changed to prevent the number of LSM kernel I/O daemons from being set to zero if this spin lock performance feature is turned on.

The change to the following voliod command produces an error and the number of LSM kernel I/O daemons remain unchanged:

# voliod -f set 0
lsm:voliod: ERROR: VOL_IO_DAEMON_SET failed: Permission denied

When running commands or scripts that must process a large amount of command parameters, your system may hang or you may see an error similar to this: /sbin/ls: arg list too long.

If this occurs, try rerunning the command or script after entering the following command to relax the command-line limits:

# sysconfig -r proc exec_disable_arg_limit=1

This kernel setting should not be used as a default. It should only be enabled when encountering a problem where the exec() argument size limit has been approached.

You can also use the xargs command to break a long argument list into smaller lists. For more information, see the xargs(1) reference page.

The fwupgrade command has been modified to allow the specified firmware update image to be loaded from a BOOTP server in a connected network. This process must use the bootpd daemon.

Create a symbolic link from the shipping location of bootpd to the expected location:

# ln -s /usr/opt/obsolete/usr/sbin/bootpd /usr/sbin/bootp

You must manually create the bootptab file on the server. The following is an example of how to set up the bootptab file on the server for this procedure:

# Example bootptab file for BOOTP support

.default1:\
:hd=/install/firmware:\
:sm=255.255.255.0\
:gw=16.69.255.1:

# 
tab:tc=.default1:ht=ethernet:ha=08002b86f234:ip=16.69.222.42:
bobafett:tc=.default1:ht=ethernet:ha=0008c73a5a47:ip=16.69.222.48:

#

In this example, the directory /install/firmware was created on the bootp server. This directory must contain the firmware of the systems to be updated. The file names must match the entry on the fwupgrade command line. The firmware files must have read permissions, that is, 444.

You must edit the inetd.conf file so that the file name passed by fwupgrade is found by the console firmware. Edit the line /etc/inetd.conf file on the bootp server to look like the following:

tftp   dgram   udp  wait    root /usr/sbin/tftpd tftp -r /install/firmware

Enable bootpd to start by removing the comment symbol (#) from the beginning of the line in the /etc/inetd.conf file;

bootps dgram   udp  wait    root /usr/sbin/bootpd  bootpd

See the fwupgrade(8), bootptab(4), and bootpd(8) reference pages for more information.

When extracting or listing an archive using the tar, pax, or cpio commands, specifying a slash (/) at the end of argument will cause the command to act upon the directory and not the contents in the directory. For example:

# tar xvf filename.tar dir1/

When creating an archive with these commands, specifying multiple slashes will result in the placement of one slash for any directory entry in the archive header. Previously, specifying multiple slashes would put these slashes in the archive header. For example:

# tar cvf filename.tar dir1//////////

Specifying a single slash when creating the archive will cause tar, pax, or cpio to pick up all of the directory's contents. For example:

# tar cvf filename.tar dir1/

The vdump and vrestore programs have been tuned to disallow block sizes greater than 64 KB blocks. This is to avoid forward compatibility problems. With the installation of this kit, the valid range is 2 through 64 KB blocks.

This section describes the steps you should take if your system is configured with a Smart Array controller and you see the following event logged:

Host name: unx104 
SCSI CAM ERROR PACKET 
SCSI device class: CISS (Smart Array) 
Bus Number: 6 
Target Number: 4 
Lon Number: 0 
… 
... 
Event Information: Command timed out...resetting controller

If this occurs, take the following steps:

When performing a baseline analysis with the dupatch utility, you will encounter the following message during Phase 4:

Phase 4 - Report changed system files and missing files
=======================================================
 
This phase provides information to help you make choices later in 
this process.  It reports both 'missing' and files whose origin
cannot be determined.  Some of these files may affect patch 
installation.  You will want to consider this information when you 
later make decisions in phase 5.
 
* list of changed files with unknown origin:
------------------------------------------

./etc/lprsetup.dat                                       OSFPRINT540 UNKNOWN
./usr/share/doclib/annex/man/man3/Thread.3               OSFTCLBASE540 UNKNOWN
BROKEN HARDLINK TO ./usr/share/doclib/annex/man/man3/Tcl_ConditionNotify.3
./usr/share/doclib/annex/man/man3/Tcl_ConditionNotify.3  OSFTCLBASE540 UNKNOWN
BROKEN HARDLINK TO ./usr/share/doclib/annex/man/man3/Thread.3

Press RETURN to proceed...

You can disregard this information. The presence of these broken links will not affect your system operation, the installation of dupatch or dupatch tools, the successful installation of patches, or the rebuilding of kernels on the system.

The new Russian 3R-LKQ48–BT keyboard, for which this kit provides an updated keyboard map, comes with five extra keycaps. To enable any of those extra keycaps, you will need to modify the file /usr/lib/X11/xkb/symbols/digital/russian. For example:

//    KEY <AD09 can be replaced by an extra keycap.
//    If you replace it with the extra keycap, please uncomment
//    the following definition and comment out the original one.
//
//    key <AD09 {
//      symbols[Group1]=3D [               o,               O ],
//      symbols[Group2]=3D [     Ukrainian_i,     Ukrainian_I ]
//    };
    key <AD09 {
        symbols[Group1]=3D [               o,               O ],
        symbols[Group2]=3D [  Cyrillic_shcha,  Cyrillic_SHCHA ]
    };

The following information pertains to the new AlphaServer ES47, ES80, and GS1280 systems, which require Tru64 UNIX Version 5.1B operating system and patch kit to be installed.

Problem with Capacity-on-Demand Process

A problem has been discovered with the capacity on demand process in which a CPU can be designated as spare, but is not taken off line as expected.

With the capacity-on-demand process, the codconfig [cpu_id_list] command lets you specify which CPUs you have paid for and which are spares. The command is supposed to mark the others as spare and then take them off line. Once a CPU is marked as spare, the hwmgr command and Manage CPUs suitlet will not let you put them on line until you use the ccod -l or ccod -p command to either loan or purchase the CPU.

The workaround is to use the codconfig [cpu_id_list] command to mark the CPUs as spare, and then use either the hwmgr command or the Manage CPUs suitlet to take them off line (sometimes referred to as offlining them). In the following example, N is the CPU number.

# hwmgr -offline -name cpuN

If, for example, the codconfig command returns the message "Error for CPU 2: Unable to offline this CPU," you would enter the following hwmgr command:

# hwmgr -offline -name cpu2

For more information, see codconfig(8) and hwmgr(8).

The Manage CPUs suitlet is available from the SysMan Menu and SysMan Station.

Do not attempt to do an update installation or rolling upgrade from Version 5.1A to Version 5.1B when the network device is a DEGXA-TA or DEGXA-SA and you have the Version 5.1A Patch Kit 4 and the New Hardware Devices V6 (NHD6) Kit installed.

The NHD6 kit and Patch Kit 4 have provided fixes that are not in the base operating system release for Version 5.1B. Once the update is completed using another network device and the Version 5.1B Patch Kit 1 or higher has been applied, the DEGXA network interface cards (NICs) can again be used for the network connection.