
PROBLEM: (82505, SSRT0691U) (PATCH ID: TCR510-004)
********
  A potential security vulnerability has been discovered, where under
  certain circumstances, system integrity may be compromised. This may
  be in the form of improper file or privilege management. Compaq has
  corrected this potential vulnerability.


PROBLEM: (82592) (PATCH ID: TCR510-006)
********
This is a small TPC-C performance optimization to cfsspec_read.
This is required to be reporting TPC-C single node cluster numbers 
based on this change.


PROBLEM: (82650, 81082, 82110, 81915,
          80967, 80006) (PATCH ID: TCR510-026)
********
This patch fixes the following clu_upgrade command problems:
 
   - When attempting to roll a patch kit on a single member cluster,
     without this patch, the following error messages will be seen
     when running the postinstall stage:
 
     This is cluster upgrade program.
 
     You have indicated that you want to perform the 'postinstall' stage 
     of the upgrade.  Do you want to continue the upgrade of the cluster?
     [yes]: yes
 
     *** Error***
     Members '2' is NOT at the new base software version.
 
     *** Error***
     Members '2' is NOT at the new TruCluster software version.
 
   - During backup stage of "clu_upgrade setup 1", clu_upgrade
     is unable to determine the name of the kernel configuration file.
     The following error  message is displayed:
 
     Message from backup stage of "clu_upgrade setup 1":
     *** Error ***
     The cluster upgrade command was unable to determine the name of the
     kernel configuration file.  Do you want to continue the cluster upgrade
     without backing up this file?   [no]
 
   - clu_upgrade does not check the availabilty of space in / and /usr
     and /usr/i18n.
 
   - During the preinstalled phase, clu_upgrade will ignore a "no" answer
     when user is prompted, during an error condition, if wish to continue.
 
   - clu_upgrade incorrectly assumes that if the directory /usr/i18n
     exists, then it is in its own file system. If the user sets up the
     cluster with i18n in /usr, which is a valid configuration permitted
     by installation, the attempt to run clu_upgrade setup to perform a
     rolling upgrade will fail in the following manner:
 
       # clu_upgrade -c setup 1
 
       *** Error ***
       There is no space available in the root (/), /usr, or /var file 
       systems to back up member ''???'' member-specific files. Increase 
       the available disk space on one of these file systems and rerun 
       this stage of the upgrade.
 
   - After the "clu_upgrade clean" phase, the final step of clu_upgrade,
     no message is displayed that leads the user to believe they have
     completed the upgrade.  Only the prompt is returned and the
     "clu _upgrade -completed clean" command reports that the clean
     had not completed.
 
   - clu_upgrade can display the following "Could not get property..."
     and "...does not exist" error messages during the undo install phase:
 
     Could not get property for file /usr/.smdb./.Old..OSFACCT505.inv
     Could not get property for file /usr/.smdb./.Old..OSFACCT505.lk
     Could not get property for file /usr/.smdb./.Old..OSFACCT505.scp
 
               and
 
   /usr/var/cluster/members/member0/im/webagent/.Old..IMAGES does not exist
   /usr/var/cluster/members/member0/im/webagent/.Old..WEBAGENT.INI does 
    not exist
 
  - The "clu_upgrade undo switch" command after completing a "clu_upgrade 
    switch" command should display an error message instead of claiming it 
    has succeeded.


PROBLEM: (DMO13809, N/A) (PATCH ID: TCR510-020)
********
This patch fixes a problem with disaster recovery whereby the node being
restored will hang on boot. This hang will usually occur after a SCSI bus
reset or 'waiting for cluster mount to complete.' It corresponds to step 11
in section 11.1.6 of the v5.1 Cluster Administration documentation.


PROBLEM: (83724, GOZ14663B) (PATCH ID: TCR510-013)
********
This patch corrects a problem in which a cluster may panic with a 
"cfsdb_assert" message when restoring files from backup while simultaneously
relocating the CFS server for that file system.


PROBLEM: (83952, SOO12306A) (PATCH ID: TCR510-015)
********
This patch corrects a problem in which a cluster member can panic with the
panic string "cfsdb_assert" when a NFS v3 TCP client attempts to create a
socket using mknod(2).


PROBLEM: (83749, VNO76936A, MGO38615A) (PATCH ID: TCR510-017)
********
This patch corrects a problem in which a cluster member will panic with
the patch string "lock_terminate: lock held" from cinactive().


PROBLEM: (BCGM919P3, EVT376821B, EVT376821, 82934) (PATCH ID: TCR510-014)
********
This patch fixes a hang seen while running collect and the vdump
utility.  This patch prevents the hang in tok_wait from occurring.
This also prevents a cfsdb_assert panic that contains the following
message: "Assert Failed: (tcbp->tcb_flags & TOK_GIVEBACK) == 0"


PROBLEM: (84176, TKTBB0088, HPAQC0DRG, EVT0576031,
          HPAQ1093P) (PATCH ID: TCR510-025)
********
This patch prevents a cfsdb_assert panic from occurring in the
cfs block reserve code.  The system is most likely running
process accounting that will receive this type of panic.
Panics seen:

Assert Failed: brp->br_allocated >= 0
file: ../../../../src/kernel/tnc_common/tnc_cfe/cfs_blkrsrv.c line: 1508
caller: 0xfffffc0000861f4c
panic (cpu 2): cfsdb_assert

and

Assert Failed: bdp->bd_svr_out >= blkreturn
file: ../../../../src/kernel/tnc_common/tnc_cfe/cfs_blkrsrv.c line: 2591
caller: 0xfffffc00008d8294
panic (cpu 0): cfsdb_assert


PROBLEM: (BCGM90MM9) (PATCH ID: TCR510-008)
********
This patch is to provide performance enhancements for copying large
(These are files smaller than the total size of client's physical
memory.) files between a CFS client and server within the cluster.


PROBLEM: (82477, 89246) (PATCH ID: TCR510-056)
********
This patch corrects a token hang situation by comparing against 
the correct revision mode.


PROBLEM: (85731, 87231, BCPM422KX) (PATCH ID: TCR510-050)
********
This is a bug in the cluster filesystem that can cause a kernel memory fault.
An identifying stack trace is below:

crash> tf
 >  0 boot                
    1 panic                
    2 trap                 
    3 _XentMM             
    4 cms_nfs_common_args  
    5 cms_copy_mount_args  
    6 cms_mount_preprocess 
    7 cluster_mount        
    8 mount1              
    9 syscall              
   10 _Xsyscall


PROBLEM: (86623) (PATCH ID: TCR510-054)
********
This patch eliminates superfluous AutoFS auto-mount attempts during
rolling upgrade.  These attempted auto-mounts slow down certain
operations and leave the AutoFS namespace polluted with directories
prefexed with ".Old.."


PROBLEM: (GB_G01710) (PATCH ID: TCR510-057)
********
This patch fixes memory leak in cfscall_ioctl().


PROBLEM: (87751, 87526) (PATCH ID: TCR510-046)
********
This patch fixes a panic with the following error message:
        panic: cfsdb_assert


PROBLEM: (HPAQ507XC, SOO21324A) (PATCH ID: TCR510-040)
********
This patch contains corrections required for proper operation of Oracle 9i
with Tru64 UNIX/TruCluster 5.1. The problems corrected include:
   - Processes hanging when using Cluster File System/Direct I/O feature.
   - Improper handling of direct I/O to an AdvFS fileset if a clone fileset
     was already in use, potentially resulting in an inconsistent backup.
   - Using ls -l, the Cluster File System file attribute could be seen
     inconsistently from the server and client members.  For example a
     file's mode could be seen differently from the server and the client.
   - A file opened for Direct I/O on the Cluster File System server may
     inappropriately be opened in non-direct I/O mode by a client.
   - Oracle processes hanging due to shutting down one cluster member.
   - A problem with the Cluster File System which could cause a cluster
     system to panic with the panic string "kernel memory fault" in the
     routine mc_bcopy().
   - A problem with Cluster File System which could cause a cluster
     member to panic with the panic string "uiomove: mode." This problem
     could cause Oracle multi-instance data bases to crash with the
     message similar to the following:
     "ORA-27063: skgfospo: number of bytes read/written is incorrect"


PROBLEM: (EVT0403573, 83149, EVT0683537) (PATCH ID: TCR510-031)
********
This patch fixes data inconsistency problems that can be seen on
clusters that are NFS clients.


PROBLEM: (CH_G01179) (PATCH ID: TCR510-032)
********
This patch prevents a cfsdb_assert panic from occurring in cfs_reclaim.
This panic has been seen while running ensight7
A typical stack trace will look like:

 > 0 stop_secondary_cpu   src/kernel/arch/alpha/cpu.c : 1009
      1 panic                src/kernel/bsd/subr_prf.c : 1222
      2 event_timeout        src/kernel/arch/alpha/cpu.c : 1668
      3 xcpu_puts            src/kernel/bsd/subr_prf.c : 1357
      4 printf               src/kernel/bsd/subr_prf.c : 892
      5 panic                src/kernel/bsd/subr_prf.c : 1287
      6 cfsdb_assert         src/kernel/tnc_common/tnc_cfe/alpha/cfs
      7 cfs_reclaim          src/kernel/tnc_common/tnc_cfe/alpha/cfs
      8 cfsfifo_reclaim      src/kernel/tnc_common/tnc_cfe/alpha/cfs
      9 vclean               src/kernel/vfs/vfs_subr.c : 3031
     10 vgone                src/kernel/vfs/vfs_subr.c : 3172
     11 cfs_inactive         src/kernel/tnc_common/tnc_cfe/alpha/cfs
     12 vrele                src/kernel/vfs/vfs_subr.c : 2554
     13 vn_close             src/kernel/vfs/vfs_vnops.c : 1825
     14 closef               src/kernel/bsd/kern_descrip.c : 2702
     15 close_ufe            src/kernel/bsd/kern_descrip.c : 2660
     16 exit                 src/kernel/bsd/kern_exit.c : 1251
     17 rexit                src/kernel/bsd/kern_exit.c : 1050
     18 syscall              src/kernel/arch/alpha/syscall_trap.c :
     19 _Xsyscall            src/kernel/arch/alpha/locore.s : 1903


PROBLEM: (85744, GB_G01025, GB_G01337) (PATCH ID: TCR510-051)
********
This patch prevents a potential hang due to external NFS servers.
The hang happens when an NFS server becomes unaccessible. However
instead of only the NFS filesystems being served by that server become 
unavailable, it effects ALL NFS mounted filesystems.
This is the cluster specific section of the patch needed for clusters.


PROBLEM: (HPAQ507XC, SOO21324A) (PATCH ID: TCR510-060)
********
This patch provide the user with a warning when running the clu_upgrade switch 
command following the installation of a patch which requires a version switch.
Once the switch stage has completed, you cannot use the standard patch
process to remove patches that require a version switch.

This patch allows the user to continue with the switch stage or to exit
clu_upgrade and continue running the system with patches installed 
but without the version switch.


PROBLEM: (VNO88299B) (PATCH ID: TCR510-044)
********
This patch prevents a potential hang that can occur on a CFS failover.
The cfs_fo_thread's stack trace will look like:
 1:     lock_wait+228:  thread_block()
 2:     lock_read+1004: lock_wait(0x70, 0xfffffc00008eb330,
0xfffffc008839bc00, 0xfffffc0000838544)
 3:   cfs_reclaim+308:  lock_read(0xfffffc00fa5ed440)
 4:        vclean+388:  cfs_reclaim(0xfffffc00a78a9440, 0x7)
 5:         vgone+196:  vclean(0xfffffc00a78a9440, 0x7,
0xfffffc000092e578)
 6:  cfs_inactive+376:  vgone(0xfffffc00a78a9440, 0x3,
0xfffffc000092e578)
 7:         vrele+276:  cfs_inactive(0xfffffc00a78a9440)
 8:       freefid+220:  vrele(0xfffffc00a78a9440)
 9: cfs_remove_client_locks+932:        freefid(0xfffffc008b607da0)
10: cfs_rec_remove_server_state+80:
cfs_remove_client_locks(0xfffffc00f9de8300)
11: cfs_rec_start_server+616:
cfs_rec_remove_server_state(0xfffffc00f9de8300, 0x1)
12: cfs_fo_handle_bid_accept+292:
cfs_rec_start_server(0xfffffc00fa459dc0,
 0xfffffc00faa2a900, 0xfffffc0083bddf80, 0x4)
13: cfs_fo_thread+1204: cfs_fo_handle_bid_accept(0xfffffc00fa5ed400)


PROBLEM: (FR_G01276, 86827) (PATCH ID: TCR510-053)
********
This patch allows POSIX semaphores/msg queues to operate properly on
a CFS client.
These mechanisms are not "clusterized" and cannot be used
across nodes but any application using semaphores or message
that works on a base system should also work when run on a
single node in a cluster (client or server).


PROBLEM: (EVT07519664) (PATCH ID: TCR510-045)
********
This patch allows the command "cfsstat -i" to execute properly.  
Before the patch you would receive the error:
get_val: read: No such device or address
This patch also corrects a memory leak in the command.


PROBLEM: (TKT220054, BCGM80DRR, SE_G01558, 89342) (PATCH ID: TCR510-058)
********
This patch corrects a problem which can cause cluster members to hang, 
waiting for the update daemon to flush /var/adm/pacct.


PROBLEM: (85568) (PATCH ID: TCR510-064)
********
This patch fixes a potential CFS hang on defragment. Deadlock was in
cfs_async_io_thread. The ICS daemon gets a remote write and holds the
transaction slot waiting for flush of a file, which is blocked.


PROBLEM: (90792) (PATCH ID: TCR510-077)
********
There is a small window where if a mount update races with an unmount and
remount of the same mount point, it is possible for one node to experience
and Kernel Memory Fault panic in the cfs_mount_update_accept() function.


PROBLEM: (91051) (PATCH ID: TCR510-100)
********
This patch fixes a possible Kernel Memory Fault panic in the
function ckidtokgs() with the following stack trace:
   Thread 0xfffffc00233aa380: Pid 632125: icssvr_daemon_fr
    0 stop_secondary_cpu() [1202, 0xfffffc00005f5a3c]
    1 panic() [1252, 0xfffffc0000294a04]
    2 event_timeout() [1971, 0xfffffc00005f6c74]
    3 printf() [940, 0xfffffc0000293db8]
    4 panic() [1309, 0xfffffc0000294b38]
    5 trap() [2262, 0xfffffc00005ea680]
    6 _XentMM() [2116, 0xfffffc00005e4458]
    7 ckidtokgs() [8849, 0xfffffc0000946618]
    8 cfs_sentinel_force() [1424, 0xfffffc00008ff064]
    9 crfs_fsync_0() [7302, 0xfffffc00008fd068]
   10 icstnc_rpc_dispatch() [951, 0xfffffc0000802ef0]
   11 icstnc_svr_rcall() [714, 0xfffffc00008029d0]
   12 icssvr_daemon_from_pool() [778, 0xfffffc00008be7bc]


PROBLEM: (81855, 85225) (PATCH ID: TCR510-098)
********
PROBLEM: (84254) (PATCH ID: )
This patch fixes a potential hang on multiple simutaneous node reboots whereby
booting nodes may hang while the following message is spewed to the console:
	WARNING: RETRYING TO LOCK THE BOOT PARTITION DEVICE


PROBLEM: (85225) (PATCH ID: )

This patch fixes the following panic:
	CFS_ADD_MOUNT() - DATABASE ENTRY PRESENT
which could occur when a node leaves the cluster and causes the cluster
to lose quorum and then rejoins the cluster before nodes which remained
in the cluster were able to perform proper clean up.


PROBLEM: (80986) (PATCH ID: TCR510-081)
********
One race condition involves a transient failure to reserve a kernel resource
associated with the file system to be mounted, and results in an ENODEV errno
returned to the mount system call.  The second race condition involves the
use of a stale memory pointer within the kernel, and will likely result in a
panic during the cms_mount_initial() routine.


PROBLEM: (83741, 82017) (PATCH ID: TCR510-072)
********
This patch fixes two AutoFS problems : 
1) Unable to establish an intercept point when mounton directory is busy. 
   An AutoFS intercept mountpoint can now be established even when a mounton
   directory is transiently or inadvertently busied by some program. 
2) Unaligned Kernel Access panic in cfs_vget_fhp().  The resulting dump will
   show a panic in the cited routine.


PROBLEM: (87918) (PATCH ID: TCR510-073)
********
If the mount of a clusterized file system type is attempted onto a 
non-clusterized file system type, a panic 
TRAP: INVALID MEMORY READ ACCESS FROM KERNEL MODE
occurs.


PROBLEM: (87406) (PATCH ID: TCR510-075)
********
This patch prevents panics during unmount processing and during planned
relocation.  In the former case a representative stack trace would indicate
a panic during the cfs_unmount() routine, and in the latter case a panic during
the do_pfs_unmount() routine.


PROBLEM: (GB_G01729) (PATCH ID: TCR510-083)
********
This patch fixes a "deltokp->tok_hldfifo[TOK_RDWR].fifo_req_begin == NULL"
assertion failure following filesystem failover recovery which results in a
"cfsdb_assert" panic orginating from the cfsdb_assert() routine called by
the deletetoken() routine.
A message similar to the following may appear on the console or in the
message buffer just prior to the panic:

    "Assert Failed: deltokp->tok_hldfifo[TOK_RDWR].fifo_req_begin == NULL
        file: ../../../../src/kernel/tnc_common/tnc_cfe/clitok.c line: 1118
        caller: 0xfffffc0000953548"

This problem produces stack traces similar to the following:

    10 panic
    11 cfsdb_assert
    12 deletetoken
    13 send_to_server
    14 revoke_internal
    15 tok_revoke_range
    16 cfstok_revoke
    17 cfs_tokmsg
    18 rcfstok_revoke
    19 svr_rcfstok_revoke
    20 icssvr_daemon_from_pool


PROBLEM: (83157, 83221) (PATCH ID: TCR510-093)
********
This patch fixes three CFS problems.

The first was the result of inadequate serialization in the CFS
read-ahead code.  Under certain rare instances, it was possible that a
buf struct might be accessed after the underlying memory had been
freed, thus potentially resulting in a kernel memory fault.

The second problem is a potential deadlock in the CFS read-ahead code.
Typically, this would present itself as a CFS async I/O thread
blocking indefinitely in cfs_condio_rw(), attempting the acquire the
c_rwlock in the cnode.  Other threads that subsequently attempt to
access the same file may also block indefinitely.

The third problem manifests itself when a filesystem becomes
completely full.  Under certain rare conditions, when writing from a
CFS client node to a filesystem that's completely full, the write
system call will fail with ENOSPC (as expected), but blocks will
actually be allocated to file (the allocated blocks will not have been
initialized).  Thus, the file will appear to be corrupted when these
blocks are subsequently read.


PROBLEM: (88145) (PATCH ID: TCR510-096)
********
File systems mounted on top of one already mounted as server-only, must be
server-only as well.  This is required to fulfill the intended semantics of
server-only.


PROBLEM: (83740, 84096) (PATCH ID: TCR510-069)
********
PROBLEM:
  1) Booting node gets stuck right after "joining deferred sets" message
     on console and the dump shows cms_join_deferred_sets() being stuck
     on the joining node.
  2) Crash due to KMF during cms_comm_lookup() in conjunction
     with a relocation/failover of cluster root.


PROBLEM: (83890) (PATCH ID: TCR510-088)
********
This patch prevents a panic when a file system is accessed late in shutdown
processing.  This problem was seen when an Advfs domain panic occurred after 
the CFS file system was unmounted on a node being shut down.
A representative stack trace is :
          0 boot                 src/kernel/arch/alpha/machdep.c : 2554
          1 panic                src/kernel/bsd/subr_prf.c : 1397
          3 _XentMM              src/kernel/arch/alpha/locore.s : 2137
          4 _domain_panic        src/kernel/msfs/osf/msfs_io.c : 1057
          5 bs_osf_complete      src/kernel/msfs/osf/msfs_io.c : 1524
          6 msfs_async_iodone_lwc  src/kernel/msfs/osf/msfs_io.c : 1790
          7 lwc_schedule         src/kernel/bsd/lwc.c : 198
          8 thread_preempt       src/kernel/kern/sched_prim.c : 4945
          9 smsync_to_readyq     src/kernel/msfs/bs/bs_qio.c : 6108
         10 bs_bflush            src/kernel/msfs/bs/bs_qio.c : 4315
         11 bs_bfdmn_flush_bfrs  src/kernel/msfs/bs/bs_domain.c : 6535
         12 mntflushbuf          src/kernel/vfs/vfs_bio.c : 1898
         13 cms_flushbufs        src/kernel/tnc_common/tnc_cfe/cms_kgs.c : 9561
         14 boot                 src/kernel/arch/alpha/machdep.c : 2757
         15 reboot               src/kernel/bsd/kern_xxx.c : 548
         16 syscall              src/kernel/arch/alpha/syscall_trap.c : 722


PROBLEM: (86769) (PATCH ID: TCR510-076)
********
In the CFS direct I/O service routines (rcfs_condio_read/write()), in
the case of a remote read/write, we were changing the p_pid field of
the ICS worker's proc struct to make the read/write operation look
like it's being done in the context of the remote process that issued
the read/write syscall at the CFS client.  There's really no reason to
be doing this, and in fact, doing so could negatively affect certain
pid-based hashing schemes in the kernel, as well as confuse kernel
debugging tools.


PROBLEM: (86882) (PATCH ID: TCR510-079)
********
There is a race between cluster mount and name space lookup logic which may
result in a transient ENODEV error returned to the lookup.  This problem was
first noticed in the context of auto-mounting a home directory during remote 
login, under AutoFS.  Infrequently, the initial attempt to login would fail but
subsequent attempts would succeed.  This problem may occur, however, with
arbitrary applications and depends only upon timing considerations.


PROBLEM: (83428) (PATCH ID: TCR510-086)
********
This problem will result in inconsistent file attributes being seen by
one or more CFS client nodes (ie, inconsistent in the sense that they
don't match the "actual" values observed at the CFS server).  This
problem can arise when a file's attributes are being changed (ie,
chown(), chmod(), etc) from a CFS client, at the same time that the
CFS client is retrieving the file's attributes from the CFS server
(ie, stat()).


PROBLEM: (88766) (PATCH ID: TCR510-089)
********
This patch fixes a panic of a node already in the cluster, when a node
re-joins the cluster.  This problem is most likely to occur when quorum has been
lost, and has just been regained due the the joining node.  The panic string 
will be :  PANIC: CFS_ADD_MOUNT() - DATABASE ENTRY PRESENT


PROBLEM: (87929) (PATCH ID: TCR510-078)
********
After removing all entries from a file's property list, CFS was not
invalidating the file's access cache.  Thus, entries in the cache may
be stale, and subsequent uses of the cached access rights (ie,
access(), namei(), etc) may yield erroneous results.


PROBLEM: (89527) (PATCH ID: TCR510-099)
********
The race condition fixed by this patch eliminates a kernel memory fault panic 
during the cms_shutdown() routine. 
This patch also fixes a problem wherein some filesets of a domain mounted
as server_only and served on the node shutting down, were not being unmounted
cluster-wide as the node shut down.


PROBLEM: (83290, 84254) (PATCH ID: TCR510-097)
********
This patch addresses two cluster problems:
- Hung unmounts, possibly seen as hung node shutdowns.

  Messages similar to the following will appear on the console of
  the node serving the filesystem being unmounted:

      WARNING: svrcfstok_waitfortokens: svrcfstok structures not
      cleaned up (retries = 25)

      WARNING: svrcfstok_waitfortokens: svrcfstok structures not
      cleaned up (retries = 25)

- A cfsdb_assert panic in cfs_tokmsg().

  This is accompanied by stack traces similar to the following:

      0 panic()
      1 cfsdb_assert()
      2 cfs_tokmsg()
      3 rcfstok_return()
      4 cfstok_send()
      5 process_msgs()
      6 cfs_tokmsg()
      7 rcfstok_request()
      8 svr_rcfstok_request()
      9 icssvr_daemon_from_pool()


PROBLEM: (BCGMB2CCS) (PATCH ID: TCR510-102)
********
This patch fixes the assertion failure ERROR != ECFS_TRYAGAIN.
The stack trace looks like:
0 stop_secondary_cpu: 1205
1 panic: 1252
2 event_timeout: 1971
3 printf: 940
4 panic: 1309
5 cfsdb_assert: 452
6 cfs_create: 5186
7 vn_open: 707
8 copen: 3300
9 syscall: 727
10 _Xsyscall: 1785


PROBLEM: (89728) (PATCH ID: TCR510-101)
********
This patch corrects a CFS problem that could cause a panic with the panic
string of "CFS_INFS full".


PROBLEM: (85708, 87292, 87236, 87824) (PATCH ID: TCR510-103)
********
This patch fixes several potential CFS panics.  Also addressed are the
following:

  - CFS block reservation problem which could result in file
    corruption when writing to a nearly full CFS filesystem.

  - An issue in the CFS readahead code, where under certain rare
    circumstances, could cause an error of EIO to be returned
    erroneously from the write system call.


PROBLEM: (89397) (PATCH ID: TCR510-074)
********
When a node is booting and a mount request is executed on another node whereby
the booting node is selected as the CFS server of the fs, a booting node could
panic if is not ready for the mount request.


PROBLEM: (DE_G02611, 90821, LU_G02822) (PATCH ID: TCR510-080)
********
This patch is to prevent a panic:
Assert failed: vp->v_numoutput > 0
or a system hang when a filesystem becomes full and direct async I/O via
CFS is used.  A vnode will exist that has v_numoutput
with a greater than 0 value and the thread is hung in vflushbuf_aged().


PROBLEM: (GB_G02147) (PATCH ID: TCR510-062)
********
This patch prevents the following panic:
cms_kgs_callback_thr: in use already set on non-initiator
The stack trace will look similar to the following:

>  0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":3102,
0xfffffc00002d21d0]
   1 thread_preempt(thread = (unallocated - symbol optimized away),
may_susp = (unallocated - symbol optimized away)) ["../../../../
src/kernel/kern/sched_prim.c":4962, 0xfffffc00002d4dcc]
   2 smsync_to_readyq(vdp = (unallocated - symbol optimized away),
flushFlag = (unallocated - symbol optimized away)) ["../../../../
src/kernel/msfs/bs/bs_qio.c":6227, 0xfffffc0000422338]
   3 bs_bflush(vdp = (unallocated - symbol optimized away))
["../../../../src/kernel/msfs/bs/bs_qio.c":4434, 0xfffffc000042060c]
   4 bs_bfdmn_flush_bfrs(0xfffffc000056e230, 0x0, 0x0,
0xfffffc0000ab2c40, 0x40)
["../../../../src/kernel/msfs/bs/bs_domain.c":6541,
 0xfffffc00003fcdac]
   5 mntflushbuf(mountp = 0xfffffc000f816a80, flags = (unallocated -
symbol optimized away)) ["../../../../src/kernel/vfs/vfs_bio.c"
:1877, 0xfffffc000056e22c]
   6 cms_flushbufs()
["../../../../src/kernel/tnc_common/tnc_cfe/cms_kgs.c":9263,
0xfffffc000093f50c]
   7 boot(reason = (unallocated - symbol optimized away), howto =
(unallocated - symbol optimized away)) ["../../../../src/kernel/ar
ch/alpha/machdep.c":2744, 0xfffffc00005fabb8]
   8 panic(s = (unallocated - symbol optimized away))
["../../../../src/kernel/bsd/subr_prf.c":1334, 0xfffffc0000294b9c]
   9 cms_kgs_callback_thread()
["../../../../src/kernel/tnc_common/tnc_cfe/cms_kgs.c":2820,
0xfffffc0000933ec8]


PROBLEM: (90178, BCGM918KQ) (PATCH ID: TCR510-068)
********
Fix potential CFS deadlock.


PROBLEM: (92502, 92569) (PATCH ID: TCR510-127)
********
PROBLEM: Lead member is hung during tag file creation.


PROBLEM: (92430) (PATCH ID: TCR510-123)
********
This patch fixes a problem wherein a cluster unmount hangs while holding
a cluster-wide lock that prevents further mounts or unmounts from completing.
It results in the following console message being repeatedly displayed :
  WARNING: svrcfstok_waitfortokens: svrcfstok structures not cleaned up
In an environment configured with an auto-mounting service, applications will
hang when this problem has occurred and an auto-mount is induced.


PROBLEM: (92941) (PATCH ID: TCR510-140)
********
This patch addresses cluster problem that can arise in the case where
a cluster is serving as an NFS server.  The problem can result in
"stale" file data being cached at cluster nodes which are servicing
NFS requests (ie, the cached data will not be invalidated if the file
is subsequently written to).  The problem manifests itself on a
per-file basis, and the net result is that reading a file from
different cluster nodes could yield different results.



