1    Release Notes

This chapter provides information that you must be aware of when working with Tru64 UNIX Version 5.0 Patch Kit-0003.

1.1    Required Storage Space

The following storage space is required to successfully install this patch kit:

Base Operating System

• Temporary Storage Space

  A total of ~250 MB of storage space is required to untar this patch kit. It is recommended that this kit not be placed in the /, /usr, or /var file systems because this may unduly constrain the available storage space for the patching activity.

• Permanent Storage Space

  Up to ~39 MB of storage space in /var/adm/patch/backup may be required for archived original files if you choose to install and revert all patches. See the Patch Kit Installation Instructions for more information.

  Up to ~40 MB of storage space in /var/adm/patch may be required for original files if you choose to install and revert all patches. See Patch Kit Installation Instructions for more information.

  Up to ~542 KB of storage space is required in /var/adm/patch/doc for patch abstract and README documentation.

  A total of ~152 KB of storage space is needed in /usr/sbin/dupatch for the patch management utility.

1.2    New dupatch Features

Beginning with Revision 26-02 of dupatch, this patch tool utility has been enhanced to provide new features, as described in the following sections. For more information, see the Patch Kit Installation Instructions.

1.2.1    Patch Installation from Multiuser Mode

Patches can now be installed when a system is in multiuser mode.

There are no restrictions on performing patch selection and preinstallation checking in multiuser mode.

However, although you can now install patches in multiuser mode, Compaq recommends that you bring down your system to single-user mode when installing patches that affect the operation of the Tru64 UNIX operating system (or the product you are patching). If your system must remain in multiuser mode, it is recommended that you apply the patches when the system is as lightly loaded as possible.

1.2.2    Patch Installation from a Pseudo-Terminal

Patches can now be installed on the system from a pseudo-terminal (pty) while in single-user mode. To do this, log into the system as root from a remote location and specify that the patches are to be installed in single-user mode. Once all the patch prerequisites are completed, the system will be taken to single-user mode while maintaining the network connection for the root user. The patches will then be installed by the system.

1.2.3    Automatic Kernel Build

If the patches installed indicate that a kernel build is required, dupatch will initiate the kernel build automatically.

Most times a reboot is required to complete the installation and bring the system to a consistent running environment. Certain file types, such as libraries, are not moved into place until you reboot the system.

When installing patches in multiuser mode, you can take one of three options after the kernel build is complete:

• Reboot the system immediately.

• Reboot the system at a specified time.

• Forgo a system reboot.

1.3    Release Note for dupatch

When you are installing the patch kit you may see a message similar to the following::

=== Installing "Tru64 UNIX V5.0" Patches:

/usr/sbin/dupatch: //usr/sbin/setld: not found

If you see this message, halt dupatch and restart the installation. The prior operation did not affect your system in any way, and dupatch should now operate properly.

1.4    Release Note for dsfmgr

After installing this patch kit, the following error may be displayed during reboot:

    dsfmgr: ERROR: file "/etc/dfsl.dat" : No such file or directory
    bcheckrc: Device Naming failed boot configure or verify.
      Please correct the problem and continue or reboot
 
    INIT: SINGLE-USER MODE
    #

This error message is benign. There is a small time period when dsfs* files may not be available during an update. You may ignore the message and continue the boot at the single user prompt.

1.5    Release Note for Patch 225.00

A new mount option, throttle, has been added in this patch. To activate this new option, update your /etc/fstab entries to enable the selected mount option (throttle) on the selected UFS filesystems.

For example, change from:

/dev/disk/dsk12e /mnt/test ufs rw 0 2

to:

/dev/disk/dsk12e /mnt/test ufs rw,throttle 0 2

Append to/etc/sysconfigtab any tuning changes. Refer to the Tuning notes that follow for a description of the new io-throttle-shift and io-throttle-maxmzthruput tunables. These tunables are configured in the vfs stanza. The following three lines make up an example:

vfs:
    io-throttle-shift = 1
    io-throttle-maxmzthruput = 1

Note

If you already have a vfs stanza in your sysconfigtab file, then just add the two io-throttle entries.

When removing this patch, be sure to remove any additions to /etc/fstab you may have made (see previous instructions).

Failure to remove /etc/fstab modifications may result in unknown attribute messages, particularly upon system reboot.

Tuning

The purpose of this patch is to minimize system stalls resulting from a heavy system I/O load.

I/O throttling addresses the concern of locking dirty pages on the device queue. It enforces a limit on the number of delayed I/O requests allowed to be on the device queue at any point in time. This allows the system to be more responsive to any synchronous requests added to the device queue, such as a read or the loading of a new program into memory. This may decrease the duration of process stalls for specific dirty buffers, as pages remain available until placed on the device queue.

The relevant tunable variables are as follows:

io-throttle-shift

The greater the number of requests on an I/O device queue, the longer the time required to process those requests and make those pages and device available. The number of concurrent delayed I/O requests on an I/O device queue can be throttled by setting the io-throttle-shift tunable. The throttle value is based on this tunable and the calculated I/O completion rate. The throttle value is proportional to the time required to process the I/O device queue.

The correspondences between io-throttle-shift values and the time to process the device queue areas follows:

io-throttle-shift  time to process device queue (sec)
---------------------------------------------------------------------      -2                   0.25
      -1                   0.5
       0                   1
       1                   2
       2                   4

For example, an io-throttle-shift value of 0 corresponds to accommodating 1 second of I/O requests. The valid range for this tunable is [-4..4] (not all values are shown in the above table; you can extrapolate). The default value of io-throttle-shift is 1. Environments particularly sensitive to delays in accessing the I/O device might consider reducing the io-throttle-shift value.

io-maxmzthruput

This is a toggle which trades off maximizing I/O throughput against maximizing the availability of dirty pages. Maximizing I/O throughput works more aggressively to keep the device busy, but within the constraints of the throttle. Maximizing the availability of dirty pages is more aggressive at decreasing stall time experienced when waiting for dirty pages.

The environment in which you might consider setting io-maxmzthruput to off (0) is one in which I/O is confined to a small number of I/O intensive applications, such that access to a specific set of pages becomes more important for overall performance than does keeping the I/O device busy. The default value of io-maxmzthruput is 1. Environments particularly sensitive to delays in accessing sets of frequently used dirty pages might consider setting io-maxmzthruput to 0.

io-throttle-static

If nonzero, the device queue limit is set to this value and it is not dynamically altered.

1.5.2    UFS delayed mount Option

This new mount option, delayed, allows for disabling synchronous metadata writes on a specified filesystem.

To maintain the file system's consistency, UFS metadata (such as inode, directory, and indirect blocks) is updated synchronously by default.

Metadata updates are typically performed synchronously to prevent filesystem corruption after a crash. The trade-off for this filesystem integrity, however, is performance. In some cases, such as a filesystem serving as a cache, performance (faster metadata update) is more important than preserving data consistency across a system crash; for example, files under /tmp or web proxy servers such as Squid.

This means two things. One is that multiple updates to one block becomes only one block write, as opposed to multiple writes of the same block with traditional synchronous metadata update. The other is that users can experience much better responsiveness when they run metadata intensive applications because metadata writes will not go out to the disk immediately while users get their prompt back as soon as the metadata updates are queued.

This delayed option should not be used on the / or /usr filesystems. It should be used only on filesystems that do not need to survive across a system crash.

To enable the delayed option, run:

mount -o delayed

or

mount -u -o delayed mount -u -o delayed

1.6    Release Note for Patch 25.00

This patch removes a Granularity Hint Regions (also called GH chunks) restriction which may be encountered on AlphaServer DS20 and ES40 systems running the Tru64 UNIX 5.0 release. This restriction can reduce performance for certain data base applications.

The following error message on the system's console terminal (also logged in /var/adm/messages) indicates possible performance loss for applications using GH chunks:

gh_chunks value of # invalid

where # is a number which varies depending on memory size.

To remove the GH chunks restriction you need to modify your target kernel configuration file (and rebuild the kernel) and change the state of a console firmware environment variable. Use the following procedure to make these changes:

1. Follow the steps the Guide to System Adminstration, with the following exceptions:

   In step 4, edit the configuration file and add the following line:

   makeoptions LOADADDR="fffffc0000430000"

   just before the first line starting with makeoptions.

   In step 6, instead of /usr/sbin/shutdown -r now, add the following:

   /usr/sbin/shutdown -h now

2. Check the console firmware version:

   P00>>>show version

   If the version is not V5.5 or later, you need to upgrade your firmware to V5.5 or later.

3. Change the value of the console_memory_allocation environment variable from old to new and reset the system:

   P00>>>set console_memory_allocation new

   P00>>>init

4. Boot the new kernel:

   P00>>>boot

   In the unlikely event the new kernel fails to boot:

   P00>>>set console_memory_allocation old

   P00>>>init

   P00>>>boot -fi vmunix.save

   or:

   P00>>>boot -fi genvmunix

   Correct the error and repeat the above procedure.

Additional Information

• If you encounter the following error message, you have most likely attempted to boot a kernel with the old load address:

  Bootstrap address collision, image loading aborted

  To boot old kernels:

  P00>>>set console_memory_allocation old

  P00>>>init

  P00>>>boot

  Note

  The generic kernel (/genvmunix) will boot with console_memory_allocation set to old or new.

• The patch kit installs a new /usr/sbin/sizer command. If you rebuild the kernel using section 4.5.1 or 4.5.2 of the Guide to System Administration, the new sizer will automatically adjust the kernel's load address.

Note

If you customized your existing configuration file, doconfig allows you to edit the new configuration file so you can restore your customizations.

1.7    Release Note for Patch 282.00

This patch provides additional information for Patch 282.00.

1.7.1    PCI To Ethernet/Graphics Combo Adapter (3X-DEPVD-AA)

This patch provides the driver support for the PCI To Ethernet/Graphics Combo Adapter (3X-DEPVD-AA) (also known as the ITI6021E Fast Ethernet NIC 3D Video Combination Adapter, InterServer Combo, or JIB). In order to obtain full support for the PCI To Ethernet/Graphics Combo Adapter (3X-DEPVD-AA), you must also select Patch 58.00, which is the X server portion of the patch.

If you have a system with this adapter, you will need to reconfigure and rebuild the kernel after installing this patch. To do this, follow these steps:

1. Shut down the system:

   # /usr/sbin/shutdown -h now

2. Boot genvmunix to single-user mode:

   >>> boot -fi genvmunix -fl s

3. After the system boots to single-user mode, mount the file systems, run the update command, and activate the swap partition:

   # sbin/bcheckrc

   # /sbin/update

   # /sbin/swapon -a

4. Run doconfig to create a new kernel configuration file and rebuild the kernel:

   # # /usr/sbin/doconfig

   Note

   Do not specify the -c option to doconfig. If you do, doconfig will use the existing kernel configuration file which will not have the appropriate controller entry for the PCI To Ethernet/Graphics Combo Adapter.

5. Save the old /vmunix file and move the new kernel to /vmunix.

6. Shut down the system:

   # /usr/sbin/shutdown -h now

7. Boot the new kernel:

   >>> boot

If you remove this patch from your system after you have rebuilt the kernel to incorporate support for the PCI To Ethernet/Graphics Combo Adapter as described previously, you will need to rebuild the kernel again to restore generic VGA graphics support. To do this, follow the steps described previously.

If you run doconfig on the original, unpatched genvmunix, it will not recognize the PCI To Ethernet/Graphics Combo Adapter and will include generic VGA graphics support in the resulting kernel.

1.7.2    DEGPA-TA Gigabit Ethernet Device

This patch provides support for DEGPA-TA (1000BaseT) Gigabit Ethernet device. If you have a system with this new Ethernet device, you will need to reconfigure and rebuild the kernel after installing this patch.

To do this, follow these steps:

1. Shut down the system:

   # /usr/sbin/shutdown -h now

2. Boot genvmunix to single-user mode:

   >>> boot -fi genvmunix -fl s

3. After the system boots to single-user mode, mount the file systems, run the update command, and activate the swap partition:

   # /sbin/bcheckrc

   # /sbin/update

   # /sbin/swapon -a

4. Run doconfig to create a new kernel configuration file and rebuild the kernel:

   # /usr/sbin/doconfig

   Note

   Do not specify the -c option to doconfig. If you do, doconfig will use the existing kernel configuration file which will not have the appropriate controller entry for the new graphics card.

5. Save the old /vmunix file and move the new kernel to /vmunix.

6. Shut down the system:

   # /usr/sbin/shutdown -h now

7. Boot the new kernel:

   >>> boot

If you remove this patch from your system after you have rebuilt the kernel to incorporate support for the new Ethernet card as described previously, you will need to rebuild the kernel. To do this, follow the steps given previously. The doconfig running on the original, unpatched genvmunix will not recognize the new Ethernet driver.

1.8    Release Note for Patch 275.00

For more information about the functionality provided and special installation instructions related to Patch 275.00, please refer to the online README file located at:

http://www.service.digital.com/patches/

From this URL directory, click on the link that has the name:

t64v50wlseco2.README

Note

It may be necessary to navigate additional directories below this top-level URL to find the specific README file related to this patch.

1.9    Release Note for Patches 335.00 and 337.00

This release notes contains the new reference page for ttauth.

NAME
 
  ttauth - ToolTalk authority file utility
 
SYNOPSIS
 
  ttauth [[-f] | [authfile] ] [[-vqib] ] [[command arg ...] ]
 
DESCRIPTION
 
  The ttauth program is used to edit and display the authorization
  information used in connecting to ToolTalk.  This program is usually used
  to extract authorization records from one machine and merge them in on
  another (as is the case when using remote logins or granting access to
  other users).  Commands (described below) may be entered interactively, on
  the ttauth command line, or in scripts.  Note that this program does not
  contact the ToolTalk server, ttsession.  Normally ttauth is not used to
  create the authority file entry in the first place; ttsession does that.
 
OPTIONS
 
  The following options may be used with ttauth. They may be given
  individually or may combined.
 
  -f authfile 
             This option specifies the name of the authority file to use.
              By default, ttauth uses the file specified by the TTAUTHORITY
              environment variable or the .TTauthority file in the user's
              home directory.
 
  -q         This option indicates that ttauth should operate quietly and
              not print unsolicited status messages. This is the default if
              an ttauth command is given on the command line or if the
              standard output is not directed to a terminal.
 
  -v         This option indicates that ttauth should operate verbosely and
              print status messages indicating the results of various
              operations (for example, how many records have been read in or
              written out). This is the default if ttauth is reading commands
              from its standard input and its standard output is directed to
              a terminal.
 
  -i          This option indicates that ttauth should ignore any authority
              file locks. Normally, ttauth refuses to read or edit any
              authority files that have been locked by other programs
              (usually ttsession or another ttauth).
 
  -b         This option indicates that ttauth should attempt to break any
              authority file locks before proceeding. Use this option only to
              clean up stale locks.
 
COMMANDS
 
  The following commands may be used to manipulate authority files:
 
  add protoname protodata netid authname authdata
              An authorization entry for the indicated ToolTalk session using
              the given protocol name (protoname), protocol data (protodata),
              ToolTalk session id (netid), authentication name (authname),
              and authentication data (authdata) is added to the
              authorization file. The protocol name should always be the
              string "TT". The protocol data should always be the empty
              string. The ToolTalk session ID is formatted string consisting
              of the ttsession program number, the ttsession authorization
              level, the IP address of the host running ttsession, and the
              RPC version number of the ttsession. See the TTSESSION
              IDENTIFIERS section below for information on constructing
              ToolTalk session ID's for the authority file. The
              authentication name should always be the string "MIT-MAGIC-
              COOKIE-1". The authentication data is specified as an even-
              lengthed string of hexadecimal digits, each pair representing
              one octet. The first digit of each pair gives the most
              significant 4 bits of the octet, and the second digit of the
              pair gives the least significant 4 bits.  For example, a 32
              character hexkey would represent a 128-bit value.
 
  [n]extract filename                  
              Authorization entries which match the specified fields are
              written to the indicated file. If the nextract command is used,
              the entries are written in a numeric format suitable for non-
              binary transmission (such as secure electronic mail). The
              extracted entries can be read back in using the merge and
              nmerge commands.  If the file name consists of just a single
              dash, the entries will be written to the standard output.
 
  [n]list                 
              Authorization entries which match the specified fields (or all
              if nothing is specified) are printed on the standard output.
              If the nlist command is used, entries are shown in the numeric
              format used by the nextract command; otherwise, they are shown
              in a textual format.  Key data is always displayed in the
              hexadecimal format given in the description of the add command.
 
  [n]merge [filename1  ...]
              Authorization entries are read from the specified files and are
              merged into the authorization database, superseding any
              matching existing entries. If the nmerge command is used, the
              numeric format given in the description of the extract command
              is used.  If a file name consists of just a single dash, the
              standard input will be read if it hasn't been read before.
 
  remove                  
              Authorization entries which match the specified fields are
              removed from the authority file.
 
  source filename
              The specified file is treated as a script containing ttauth
              commands to execute. Blank lines and lines beginning with a
              pound sign (#) are ignored. A single dash may be used to
              indicate the standard input, if it has not already been read.
 
  info        
              Information describing the authorization file, whether or not
              any changes have been made, and from where ttauth commands are
              being read is printed on the standard output.
 
  exit       
              If any modifications have been made, the authority file is
              written out (if allowed), and the program exits. An end of file
              is treated as an implicit exit command.
 
  quit       
              The program exits, ignoring any modifications. This may also be
              accomplished by pressing the interrupt character.
 
  help [string]
               A description of all commands that begin with the given string
              (or all commands if no string is given) is printed on the
              standard output.
 
  ?           
              A short list of the valid commands is printed on the standard
              output.
 
TTSESSION IDENTIFIERS
 
  The ToolTalk session identifiers (netid) in the authority file and used by
  the add, [n]extract, [n]list, and remove commands are derived from the
  TT_SESSION identifier constructed by ttsession at startup.  The ttsession
  rendezvous with clients by writing the TT_SESSION identifier as a property
  on the root window or as an environment variable in the client's
  environment (see ttsession -c). In addition, ttsession creates an entry in
  the user's authority file.  The authority file entry has a netid component
  which is derived from the TT_SESSION identifier.
 
  The TT_SESSION(STRING) = "01 1433 1342177279 1 1 2002 130.105.9.22 4"
  identifier is composed of the following elements:
 
    <Dummy Number>                        = 01
    <ttsession Process Id>                = 1433
   <ttsession Program Number>       = 1342177279
   <DummyNumber>                         = 1
   <ttsession Authorization Level>  = 1
   <ttsession UID>                            = 2002           
   <Host IP Address>                       = 130.105.9.22
   <RPC Version Number>               = 4
 
The ToolTalk session identifiers (netid) in the authority file are composed
  of the <ttsession Program Number>,  <ttsession Authorization Level>,  <Host
  IP Address>, and <RPC Version Number> fields of the TT_SESSION identifier
  as follows:
 
  1342177279/1/130.105.9.22/4
 
EXAMPLE
 
  The most common use for ttauth is to extract the entry for the current
  ttsession, copy it to another machine, and merge it into the user's
  authority file on the remote machine:
 
  % xprop -root | grep TT_SESSION
 
  TT_SESSION(STRING) = "01 1433 1342177279 1 1 2002 130.105.9.22 4"
  _SUN_TT_SESSION(STRING) = "01 1433 1342177279 1 1 2002 130.105.9.22 4"
 
  % ttauth extract - netid=1342177279/1/130.105.9.22/4 | rsh otherhost ttauth
  merge -
 
ENVIRONMENT
 
  This ttauth program uses the following environment variables:
 
  TTAUTHORITY 
  Gets the name of the authority file to use if the -f option is not used.
 
FILES
 
  .TTauthority
              Default authority file in the user's home directory if
              TTAUTHORITY is not defined.
 
RESTRICTIONS
 
  Users that have unsecure networks should take care to use encrypted file
  transfer mechanisms to copy authorization entries between machines.
  Similarly, the MIT-MAGIC-COOKIE-1 protocol is not very useful in unsecure
  environments.  Sites that are interested in additional security may need to
  use encrypted authorization mechanisms such as Kerberos.
 
  Spaces are currently not allowed in the protocol name.  Quoting could be
  added for the truly perverse.
 
SEE ALSO
 
  Commands:  ttsession(1)
 
  ToolTalk Reference Manual
 
 
The options section of the ttsession manpage should now look like this:
 
 
  -a level
        Set the server authentication level.  The following level string
        values are supported:
 
        cookie  
        The sender and receiver must share the same cookie.  This
        means that messages which do not specify a handler "ptype"
        are delivered even if the cookies do not match.  This is the
         default authorization scheme.  For "full security" use the -F
          option.  Refer to the ttauth(1) reference page for more
          information.

1.10    Release Note for Patch 437.00

This patch contains a solution for the following issue:

Compaq has advised owners of DS10, DS10L, ES40 AlphaServers, and XP900 AlphaStations that Compaq has determined in laboratory testing that there is a theoretical possibility that during read and write operations to the floppy disk on these systems, a single byte of data may be inaccurately read or written without notice to the user or system. The potential for this anomaly exists only if floppy disk read or write operations are attempted while there is extremely heavy traffic on these Alpha systems' internal input/output busses.

Although Compaq has observed the anomaly only in laboratory tests designed to create atypical system stresses, including almost constant use of the floppy disk drive, Compaq has informed owners of the remote possibility that the anomaly could occur so that they may take precautions to prevent it.

Compaq recommends that the solution be installed by all DS10, DS10L, ES40 AlphaServers, and XP900 AlphaStation customers.

The solution to this issue is also available as an individual, manually installed patch kit named floppy_csp_v50.tar.gz, available from:

http://ftp1.support.compaq.com/public/unix/v5.0