****  ****
*** hp ***    General Systems Division
****  ****    19447 Pruneridge Ave.  Cupertino, CA 95014
---------------------------------------------------------------------------
memo to : HP-UX Release 3.0 Customers
from    : Integration
date    : Dec. 23, 1988
subject : Release 3.0 Patch Tape


The purpose of this "README" file is to describe the procedure to install
the fixes  provided  by the Patch Tape for HP-UX  Release  3.0 on HP 9000
Series 800 Systems, and the defects which are fixed by the patch.


The  procedure to install the new versions of "uucico"  (Revision  64.4)
and  "libhp-ux.a"  (Revision  A.B3.01.1A)  from the Patch  Tape for HP-UX
Release 3.0 is:

   a. Login as a  superuser  and make sure that you are the only  user on
      the system.

   b. Execute the following commands to retrieve and overlay the affected
      files:

      		cd /
     		tar xv

      
      Files provided on the tape are:

      		tmp/README
		tmp/patch.scr
		usr/lib/uucp/uucico
		etc/conf/lib/libhp-ux.a

      Files affected by this patch are:

		/usr/lib/uucp/uucico
		/hp-ux
		/etc/conf/lib/libhp-ux.a

   c. Make sure that you have a correct version of the /etc/conf/gen/S800
      system  generation  file for your system.  The  "patch.scr"  script
      will ask for this information, and will regen the kernel using your
      specified system generation file.

   d. Now you can run the "patch.scr" script by executing:

		/tmp/patch.scr

      This script will ask if you want to regen the kernel.  Answer "y".

      Answer  "y"  when  regen  asks if you  want to use the  S800  file,
      otherwise  specify the system  generation  file that reflects  your
      system's hardware configuration.

   e. Finally, the system will need to be rebooted to get the new kernel.

   f. After  booting up with the new  kernel, you can verify  your kernel
      version number by executing:

		what /etc/conf/lib/libhp-ux.a | grep HP-UX

      This should report HP-UX (sys.A.B3.01.1A/S800).




The defects  that have been found in HP-UX  Release 3.0 on HP 9000 Series
800 Systems are in the AFI driver (gpio11.c), uucico,  umount/sync, panic
handling, and a compliance problem with X/OPEN.  A brief synopsis of each
defect follows.

   1.  Description of the gpio11.c defect:

      The EDGE bit, used to select the edge of PFLAG (a  handshake  line)
      to clock data on or off the AFI card, defaults to a value  opposite
      the default  value used on releases  prior to 3.0 (the PFLAG signal
      is  driven  by  the  customer's   peripheral).  If  the  customer's
      peripheral uses the handshake  signals  properly, the AFI card will
      hang waiting for the  handshake to complete.  The patch  contains a
      new version of the gpio11.o  which  correctly  sets the EDGE bit to
      the original default value.

   2.  Description of the uucico defect:

      When you use the command "uucico" with the "f" protocol to transfer
      files, uucico exhibits the following behavior:

      a. It  correctly  logs  onto the  remote  system  to start  the "f"
         protocol  and requests the remote  system to send the file to be
         transferred by issuing the message:

	 S file1 file2 user_options

      b. It then expects the remote system to send an "SY" message before
         the file is to be  transferred.  The remote  system  never sends
         the  "SY"  message,  so the  process  eventually  times  out and
         aborts.  The file is never transferred.

      c. The /usr/spool/uucp/.Log/uucico/system-name logfile reports error
         messages similar to the followings: 

         root hpisog2 (11/21-22:29:45,19826,0) SUCCEEDED (call to hpisog2)
         root hpisog2 (11/21-22:29:50,19826,0) OK (startup)
         root hpisog2 hpisog2N3f96 (11/21-22:29:50,19826,0) REQUEST 
	 (hpisoe2!D.hpiso3f96a
         7d --> hpisog2!X.hpisog2N3f96 (root))
         root hpisog2 hpisog2N3f96 (11/21-22:30:56,19826,1) BAD READ 
	 (expected 'S' got FAIL)

   3. Description of the umount/sync defect:

      The files being  changed are  machdep.o,  vfs.o, and  ufs_vfsops.o.
      The change will fix a race condition  between umount and sync which
      can   potentially   lead  to  a  panic.  The   change   will   also
      significantly improve performance if more than one sync is executed
      concurrently.

   4. Description of the panic handling defect:

      If a panic occurs early enough after I/O  configuration  completes,
      it results in an HPMC on Series 850  systems,  and it also causes a
      corrupted  dump on Series 840 Systems.  An attempt was made to test
      this failure on the following Series 800 machines:

      a. Series 840 systems:

        o       Revision   1.87.9.19  of  the   cio_ca0.c   (CAM)  module
                successfully panics and saves core.

        o       Revision  1.87.9.20 of the cio_ca0.c  (CAM) module states
                successful  completion  of the core dump but results in a
                partial dump or corrupted dump image.

      b. Series 850 systems:

        o       Revision   1.87.9.19  of  the   cio_ca0.c   (CAM)  module
                successfully panics and saves core.

        o       Revision  1.87.9.20 of the cio_ca0.c  (CAM) module states
                successful  completion  of the core dump but periodically
                generates unusual HPMC and corrupted core dump.

      In order to provide a fix to this  defect  with the  provided  time
      constraint, it was decided to roll the cio_ca0.c  (CAM) module from
      Revision  1.87.9.20 to Revision  1.87.9.19.  With this fix, we have
      re-introduced the problem "TOC doesn't work on Indigo with A-link",
      described in DTS# DSDa201461 and SR# 4700-685313.

   5. Description of the X/OPEN defect:
     
      The  fcntl(2)  system  call does not  conform to X/OPEN  standards.
      This can be seen under the following combination of circumstances:

      a. Multiple  locks  exist on  different  regions of the same  file,
         including at least one read (shared) lock on a region  preceding
         another region with an (exclusive) write lock.

      b. A  request  is made  either  to  obtain a  (shared)  read  lock,
         determine if a (shared) read lock is obtainable,  or read a file
         with  enforcement-  locking  mode, and the lock or read  request
         applies to a region of the file that  contains or overlaps  with
         both of the locks described in (a).

      c. The request in (b) should be denied  because of the  (exclusive)
         write lock.  The defect is that the request is allowed.

      This type of failure permits read  operations to occur in violation
      of write  locks.  In general,  this means that corrupt  data may be
      read.  It is  possible  that  corrupt  data  based on this read may
      later be written,  damaging  data  integrity.  However,  writes are
      never directly permitted in violation of locks.


