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.