PROBLEM: (81635, 85286) (PATCH ID: OSF520-078) ******** Dynamic drivers are not getting unloaded and reloaded correctly because their ctlr_unattach() routines do not get called when unloaded. Additionally, upon subsequent loads and reloads, their probe() routines do not get called. PROBLEM: (87646) (PATCH ID: OSF520-077) ******** This patch fixes a problem where when using VX1 graphics module, mouse cursor disappears when moved along left and top most edge. PROBLEM: (87008) (PATCH ID: OSF520-126) ******** This problem is seen when debugging kernel crash dumps. The corruption is always page-aligned and usually in the sparse VM "managed" space. "kmem -v" under the "crash" analysis tool may identify this type of corruption, however this problem is not limited to kmem allocations. The corruption can take any form -- application data, kernel data, database -- depending on which wrong page happens to be selected. PROBLEM: (89626) (PATCH ID: OSF520-007) ******** This patch fixes a "simple_lock timeout" system panic due to a bug between mcs_unlock and mcs_lock_try on the same cpu. A common statck trace will look like the following: mcs_unlock_C thread_list_wakeup wakeup_prim_result .... _XentINT mcs_unlock_C PROBLEM: (none) (PATCH ID: OSF520-115) ******** This patch provides the following: - NHD4 enablers for future hardware support - A new /usr/sbin/wol command that utilizes the Wake (remotely power) feature for a future platform through the network (Lan) PROBLEM: (none, none) (PATCH ID: OSF520-121) ******** This patch provides NHD4 enables for future hardware support of a graphics device. PROBLEM: (87422) (PATCH ID: OSF520-009) ******** This patch fixes a time loss problem seen on DS systems (TSUNAMI) only when using console callbacks. The patch resynchronizes the clock when a time loss is detected. PROBLEM: (88013) (PATCH ID: OSF520-074) ******** This patch fixes a rare panic in the driver for the DE600/DE602 10/100 Ethernet adapter. The panic is the result of a kernel memory fault that occurs when an ioctl is sent to the driver (for instance using "ifconfig"), or when a machine is shutting down to reboot. Typically it will only occur when there is high traffic on the network. The stack trace may show ee_rint as the routine in which the kernel memory fault occurred: 1 panic() 2 trap() 3 _XentMM() 4 ee_rint() 5 ee_rx_intr_work_thread() The stack trace may alternatively show ee_add_rfd_buf as the routine in which the kernel memory fault occurred: 1 panic() 2 trap() 3 _XentMM() 4 ee_add_rfd_buf() PROBLEM: (90892) (PATCH ID: OSF520-207) ******** This patch provides NHD4 enablers for future hardware support of a new platform. PROBLEM: (89958) (PATCH ID: OSF520-097) ******** Domain panics and points to quotaUndo not being able to open the offending fileset, when a domain has a fileset with a clone and the clone is deleting and a file in the fileset finds no space available in the domain. PROBLEM: (CA1Q62704, 89522) (PATCH ID: OSF520-081) ******** This patch corrects a problem where the network subsystem sometimes sends a null TCP packet when a connection is reset. PROBLEM: (89942) (PATCH ID: OSF520-116) ******** Enabler support for Enterprise Volume Manager product PROBLEM: (89088, TKT205463) (PATCH ID: OSF520-044) ******** This patch fixes a system panic with "malloc_check_checksum: memory pool corrution" A vnode is being referenced after it has been freed and return to kmem. The pmsgbuf has the bucket infomation: memory pool corruption memory address: 0xfffffc00807fafc0 memory size: 0x240 ra of last caller freeing memory: 0xfffffc00004a477c panic (cpu 0): malloc_check_checksum: memory pool corruption The memory address shows that the last locker was wait_for_vxlock: (dbx) 0xfffffc00807fafc0/10X 0xfffffc00807fafc0: 0xfffffc00004a35ae 0xdeadbeefdeadbeef 0xfffffc00807fafd0: 0xdeadbeefdeadbeef 0xdeadbeefdeadbeef 0xfffffc00807fafe0: 0xdeadbeefdeadbeef 0xdeadbeefdeadbeef 0xfffffc00807faff0: 0xdeadbeefdeadbeef 0xdeadbeefdeadbeef 0xfffffc00807fb000: 0xdeadbeefdeadbeef 0xdeadbeefdeadbeef crash> 0xfffffc00004a35ae/i (dbx) 0xfffffc00004a35ae/i [wait_for_vxlock:1000, 0xfffffc00004a35ac] bsr ra, simple_unlock(line 1497) PROBLEM: (85229) (PATCH ID: OSF520-020) ******** This patch fixes a problem in which issuing a "quot -h" command causes a memory fault when the /etc/fstab file contains a mount point that is not mounted. PROBLEM: (SSRT0742U) (PATCH ID: OSF520-021) ******** A potential security vulnerability has been discovered in the kernel, where under certain circumstances a race condition can occur that could allow a non-root user to modify any file and possibly gain root access. PROBLEM: (90091) (PATCH ID: OSF520-138) ******** The user is unable to create a raw IPv6 socket with protocol other then 0 or IPPROTO_RAW. PROBLEM: (89728) (PATCH ID: OSF520-089) ******** This patch corrects a CFS problem that could cause a panic with the panic string of "CFS_INFS full". Note, this problem only exists when running in a cluster environment. PROBLEM: (90018) (PATCH ID: OSF520-128) ******** This patch fixes a problem if an error occurs while calling the DEVIOCGET ioctl, in which the user's buffer would not be filled in and would return zeros. PROBLEM: (BCGM80NF5) (PATCH ID: OSF520-075) ******** This patch fixes a problem in which a tcp socket can continue to receive data with no application running. PROBLEM: (89177, 87242, ZUO61276A) (PATCH ID: OSF520-031) ******** This patch fixes a performance problem and the results are large performance increases in configurations where more than 8 tapes are supported on a fibre channel (usually behind an MDR or FCTCII). PROBLEM: (82005) (PATCH ID: OSF520-142) ******** This patch should be installed if either of the following are true: 1) If the configuration includes any devices behind FCTCIIs or MDRs. 2) If the tape device does not properly select desired densities or compression. PROBLEM: (90118, BCGM91KNL) (PATCH ID: OSF520-141) ******** Fix problem seen in low-memory situations within task swapping code This would most frequently be seen as a panic from within thread_continue(), with a message in the pmsgbuf looking like: thread_continue: thread 0x7fe38380 in state 0x15 panic (cpu 1): thread_continue Examining the trace back of the noted thread (which is also the first argument to thread_continue()), one will find a blocking idle_thread, that looks like something along the lines of this: crash> tf > 0 thread_block src/kernel/kern/sched_prim.c : 3102 1 lock_wait src/kernel/kern/lock.c : 852 2 lock_write src/kernel/kern/lock.c : 947 3 k_map_delete src/kernel/vm/vm_kmap.c : 1419 4 kmem_stack_free src/kernel/vm/vm_kmap.c : 1151 5 stack_free src/kernel/vm/vm_kmap.c : 1288 6 thread_deallocate src/kernel/kern/thread.c : 1900 7 thread_continue src/kernel/kern/sched_prim.c : 3284 8 thread_block src/kernel/kern/sched_prim.c : 3101 9 idle_thread src/kernel/kern/sched_prim.c : 4518 PROBLEM: (87647, 88665, HPAQ617CN) (PATCH ID: OSF520-039) ******** This problem can occur if the vm_swap_wcluster parameter is not set to a page multiple. A typical stack trace my look like the following: > 0 stop_secondary_cpu 1 panic 2 event_timeout 3 printf 4 panic 5 trap 6 _XentMM 7 vm_swap_async_done 8 lwc_schedule 9 thread_block 10 xpt_callback_thread PROBLEM: (89536, 89930) (PATCH ID: OSF520-127) ******** This patch provides the following: - NHD4 enablers for future hardware support of an array controller. - Fixes to some problems found with Raid Services that include: raid services not acknowledging presence of CAM RAID device, a hang, the inability to prohibit a user from deleting a logical volume while it's in use, and a "malloc_check_checksum: memory pool corruption" system panic. 1. Devices reporting a device type of Raid are being recognized by the CAM subsystem as valid control port devices. Applications that use Raid services need to determine how many control ports are present in the system in order to gain specific information about each control. If product installed on the system that utilizes a control port (ie. CAM Raid device) and raid services doesn't acknowledge its presence then this patch should be installed. 2. Applications that use the Maintenence pass thru mode of Raid services and issue multiple pass thru commands will hang. 3. Applications that use Raid services for online deletion of logical units could delete a unit that is in use. 4. A system panic with panic string: panic (cpu 8): malloc_check_checksum: memory pool corruption The problem occurs due to an uninitialized section of a CCMN_SPECIFIC pd structure. PROBLEM: (MGO10736A, EVT0396650, TPOB36405, BCSM10NZK, BCGM5280J) (PATCH ID: OSF520-033) ******** This patch fixes a problem where threads can hang in x_load_inmem_xtnt_map() when called from x_page_to_blkmap(). A typical hung thread will have the following calls at the top of its stack trace: 0 thread_block 1 lock_read 2 x_load_inmem_xtnt_map 3 x_page_to_blkmap 4 x_page_to_iolist 5 blkmap This patch also fixes a problem where the IO transfer rate writing to a file in an AdvFS domain can suddenly drop. All of the following conditions must be met in order for this problem to occur. 1. The file must be on a multi-volume AdvFS domain. 2. The file must be sparse. That is, it must have unwritten areas within the file. 3. The file must fill its initial volume while still sparse. 4. All writes to the interior of the file will exhibit the problem after step 3. 5. All writes to the end of the file will not exhibit the problem. This problem is only seen on the specific file or files meeting the above criteria. All other files will perform normally. PROBLEM: (88816, 89170, 83043, 89185, 89301, 89352) (PATCH ID: OSF520-024) ******** This patch fixes the following Virtual Memory problems. The first three are seen on NUMA systems only, and the forth problem can be seen on any system type: Problem 1: ----------- A "vm_pg_alloc: page not free" system panic that occurs during process migration. This panic occurs because during kernel stack migration, some of the steps involved in allocating a new stack page, copying the contents from the current page, and disposing of the current page were being done in the incorrect order. Problem 2: ------------ A "vm_pageout_activate: page already active" system panic that occurs if one thread is unlocking some pages in memory while another thread is migrating them. An example stack trace would be as follows: 4 panic src/kernel/bsd/subr_prf.c : 1353 5 vm_pageout_activate src/kernel/vm/vm_pagelru.c : 2146 6 u_anon_faultpage src/kernel/vm/u_mape_anon.c : 1978 7 u_anon_fault src/kernel/vm/u_mape_anon.c : 1463 8 u_anon_lockop src/kernel/vm/u_mape_anon.c : 3147 9 u_map_lockvas src/kernel/vm/vm_umap.c : 1540 10 memlk src/kernel/bsd/kern_mman.c : 2360 11 syscall src/kernel/arch/alpha/syscall_trap.c : 725 12 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 or: 4 panic src/kernel/bsd/subr_prf.c : 1353 5 vm_pageout_activate src/kernel/vm/vm_pagelru.c : 2146 6 u_anon_faultpage src/kernel/vm/u_mape_anon.c : 1978 7 u_anon_fault src/kernel/vm/u_mape_anon.c : 1463 8 u_map_fault src/kernel/vm/vm_umap.c : 756 9 vm_fault src/kernel/vm/vm_fault.c : 176 10 trap src/kernel/arch/alpha/trap.c : 2329 11 _XentMM src/kernel/arch/alpha/locore.s : 2143 Problem 3: ----------- Memory inconsistancies caused by fault path for large shared memory regions prematurely releasing a hold on a page it just locked. This can cause variety of problems including user program errors and system panics. The conditions under which this corruption can happen are unique. The system must be a NUMA machine in which SSM migration is enabled (it is enabled by default). Users of large shared memory regions (must be 8 MB or larger) that are also locking the shared memory while the memory is migrating could create the right set of conditions that would result in this problem. Problem 4: ------------ A "simple_lock: time limit exceeded" system panic that occurs if very large (8MB or larger) System V Shared memory regions are in use. An example stack trace would be as follows: 4 panic src/kernel/bsd/subr_prf.c : 1309 5 simple_lock_fault src/kernel/kern/lock.c : 2805 6 simple_lock_time_violation src/kernel/kern/lock.c : 2938 7 pmap_ssm_enter src/kernel/arch/alpha/pmap.c : 7827 8 u_ssm_fault src/kernel/vm/u_mape_ssm.c : 2386 9 u_map_fault src/kernel/vm/vm_umap.c : 740 10 vm_fault src/kernel/vm/vm_fault.c : 168 11 trap src/kernel/arch/alpha/trap.c : 2325 12 _XentMM src/kernel/arch/alpha/locore.s : 2115 PROBLEM: (88846) (PATCH ID: OSF520-120) ******** This patch fixes a problem with the memory troller attempting to post an EVM event indicating that a particular PFN has been mapped out. The problem stems from the post memory event attempting to delete an event that was never created. The failure to create an event is due to the troller's elevated SPL. The EVM event delete code then attempts to delete a null event which results in a failure. Symptoms would be a kernel memory fault in either post_memory_event or EvmEventDestroy. "trap: invalid memory read access from kernel mode" PROBLEM: (86244, 88931, HPAQ21NL3, 86987, 87977, BCSM51NH2) (PATCH ID: OSF520-029) ******** This patch fixes ubc performance problems and lock timeout issues. PROBLEM: (87578, 84358, 84926, 86046, 87027, 87578) (PATCH ID: OSF520-051) ******** Below are descriptions of problems that have been fixed with this patch: - There is performance related problem with applications that use mutexes which are allocated in shared memroy. This problem manifests itself when trying to allocate large quantitiies of mutexes in shared memory. - When developing applications that use mutexes which are allocated in shared memeory, unexpected EINVAL errors would appear if these mutexes and their condition variables were not in the same shared memory regions. PROBLEM: (HPAQ90Q79, BCSM40W91, 64343, 87051) (PATCH ID: OSF520-052) ******** This patch fixes a bug that can cause performance problems for certain applications when the sysconfigtab parmaeter ipc:sem_broadcast_wakeup is set to 0. Otherwise, the original behavior is preserved, which is to wake-up all threads waiting on a semaphore value change. PROBLEM: (DE_G02243, DE_G02261) (PATCH ID: OSF520-131) ******** A check for managed address may return an invalid value when called with the address of a gh region not on rad 0. A panic may occur with the following stack trace: 0 stop_secondary_cpu 1 panic 2 event_timeout 3 printf 4 panic 5 trap 6 _XentMM 7 mcs_lock_try 8 pmap_dup 9 vm_dup_va 10 volkiomem_iter 11 volkiocopyout 12 volsio_unstabilize 13 vol_mv_wrback_done 14 voliod_iohandle 15 voliod_loop PROBLEM: (BCPM205PB) (PATCH ID: OSF520-055) ******** This fixes a kernel memory fault panic in msg_rpc_trap(). An example stack trace would be: panic() trap() _XentMM() msg_rpc_trap() _Xsyscall() PROBLEM: (88778) (PATCH ID: OSF520-059) ******** There are 2 scenarios that needed to be fixed. Scenario 1: A file with a hole at page 10 is opened for cached IO and the hole is filled. Then this file is closed and opened for directIO, and page 10 is written successfully. If the system crashes before the log page describing the addition of the hole storage has been flushed to disk, then after recovery, the data written via directIO to page 10 will be lost since it will be reverted to a hole. This is an error for directIO since the write is considered "to disk", and should not return success unless the metadata has been flushed to disk. Scenario 2: This is the same scenario as above, but the thread that opens the file for directIO is a CFS client. CFS retrieves the extent maps (which are in memory only) and writes to page 10 successfully. The system then crashes and, after recovery, page 10 does not exist because the extent maps were never flushed to disk. The first scenario was fixed by setting the dirty_alloc bit in the file context when storage is added via the directIO code. This is detected in fs_write() and ensures that both the file stats and the log pages are flushed to disk before returning to the caller. This is the same as if the file were opened with the O_SYNC flag. The second scenario was fixed by modifying msfs_open() to flush the log when a file is opened for directIO iff it is being opened for a CFS file, and there is an outstanding allocation that needs to be written to disk. PROBLEM: (90110) (PATCH ID: OSF520-130) ******** This patch fixes a crash that occurs when disk controllers are restarted repeatedly. This occurs when memory associated with the disk controller is unallocated more than once. The following message is displayed: PANIC: "malloc_leak: free with wrong type" PROBLEM: (90031) (PATCH ID: OSF520-098) ******** This patch fixes a "u_shm_oop_deallocate: reference count mismatch" due to a bug in locking mechanism when gh_chunks are in use. PROBLEM: (89245, 90061) (PATCH ID: OSF520-129) ******** There is a firmware issue in the HSG80 controllers that during a cluster transistion can cause the HSG80 controllers to crash. This controller crash can then cause loss of data access to those logical volumes on that pair of HSG80 controllers. If cluster root is on that HSG80 a cluster domain panic can result. The symptoms of this problem are DRD barrier errors logged to the /usr/adm/messages files and to the console. This can also be verified by examining the HSG80 fmu logs and the HSGO console. The key text in determining this problem is as follows: During processing to maintain consistency of the data for Persistent Reserve SCSI commands, an internal inconsistency was detected. > Last Failure Parameter[0] contains a code defining the precise nature Example output run fmu FMU> show last most Last Failure Entry: 6. Flags: 006FF901 Template: 1.(01) Description: Last Failure Event Occurred on 26-SEP-2001 at 10:10:29 Power On Time: 1. Years, 30. Days, 9. Hours, 1. Minutes, 11. Seconds Controller Model: HSG80 Serial Number: ZG02900845 Hardware Version: E05(2D) Software Version: XCF4P-0(FF) Instance Code: 0102030A Description: An unrecoverable software inconsistency was detected or an intentional restart or shutdown of controller operation was requested. Reporting Component: 1.(01) Description: Executive Services Reporting component's event number: 2.(02) Event Threshold: 10.(0A) Classification: SOFT. An unexpected condition detected by a controller software component (e.g., protocol violations, host buffer access errors, internal inconsistencies, uninterpreted device errors, etc.) or an intentional restart or shutdown of controller operation is indicated. Last Failure Code: 43230101 Last Failure Parameter[0.] 00000013 Last Failure Code: 43230101 Description: During processing to maintain consistency of the data for Persistent Reserve SCSI commands, an internal inconsistency was detected. > Last Failure Parameter[0] contains a code defining the precise nature of the inconsistency. Reporting Component: 67.(43) Description: Host Port Protocol Layer Reporting component's event number: 35.(23) Restart Type: 0.(00) Description: Full software restart Active Thread: FOC I960 Priority: 0.(00) Interrupt Stack Guard is intact NULL Thread Stack Guard is intact Thread Stack Guard State Flags (ID# Bit; 0=intact,1=not intact): 00000000 PROBLEM: (BCSM80J37) (PATCH ID: OSF520-035) ******** This patch corrects the problem of a thread deadlocking against itself under the following conditions: o Running in a cluster. o Opening (and then closing) a directory that has an index file. o Trying to open the index file through .tags (e.g. defragment does that) and by coincidence getting the vnode that pointed to the directory that the index file is attached to. PROBLEM: (85224) (PATCH ID: OSF520-064) ******** Fix for internal kernel panic "bs_invalidate_rsvd_access_struct: bad access struct" PROBLEM: (88220) (PATCH ID: OSF520-109) ******** This patch ensures that DMAPI region information maintains consistency across CFS server and client nodes in the case that an unexpected node failure occurs. PROBLEM: (89643) (PATCH ID: OSF520-100) ******** This patch fixes a problem where additional HSZ70 control ports, /dev/cport/scpN, were created during HSZ70 controller failover operations. When this condition occurs, anyone using /usr/lbin/hsxterm5 would have trouble talking to the HSZ70 using the original control port. PROBLEM: (87934) (PATCH ID: OSF520-101) ******** This patch fixes a problem uncovered when using 'hwmgr' to delete devices with lockmode=4. When deleting a device was not successful, a lock was not released properly. Later, this dangling lock could cause a lock hierarchy violation and we would panic. PROBLEM: (HGO091469, 87558) (PATCH ID: OSF520-062) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This could result in a panic with the string: "lock_clear_recursive: recursion not enabled." Compaq has corrected this potential vulnerability. PROBLEM: (86800, 89135) (PATCH ID: OSF520-106) ******** This patch fixes a problem where new devices could be created when following the HSZ70 controller failover procedure. When this problem is encountered, you will see inconsistencies reported by the "hwmgr -show comp -i" command. PROBLEM: (QAR85485) (PATCH ID: OSF520-117) ******** This patch will fix the following problem: * Reading a clone file that is still in the cache after an rmvol may panic the system. The problem is that pages in the UBC for a clone file may end up mapped to invalid volume indexes after an rmvol. If a clone file has been read into the UBC and a subsequent rmvol removes a volume that any of the clone's non-cowed pages were mapped to, the migrate code as part of the rmvol fails to remap those pages to the new volume. If read ahead code is executed on those pages still in the UBC, the system will panic with a "trap: invalid memory read access from kernel mode" error. Here is an example stack trace: > 0 boot(reason = (unallocated - symbol optimized away), howto =(unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/machdep.c":2644, 0xfffffc0000676414] 1 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/ bsd/subr_prf.c":1401, 0xfffffc000029f220] 2 trap(a0 = (...), a1 = (...), a2 = (...), code = (unallocated - symbol optimized away), exc_frame = (unallocated - symbol optimized away)) ["../../../ ../src/kernel/arch/alpha/trap.c":2266, 0xfffffc00006644a0] 3 _XentMM(0x0, 0xfffffc00004243d8, 0xfffffc000086b6a0, 0x0, 0xfffffc0005949008) ["../../../../src/kernel/arch/alpha/locore.s":2143, 0xfffffc000065df14] 4 seq_ahead_cont(bfap = (unallocated - symbol optimized away), bp = (unallocated - symbol optimized away), bsPage = (unallocated - symbol optimized away)) ["../../../../src/kernel/msfs/bs/bs_buffer2.c":6298, 0xfffffc00004243d4] 5 bs_refpg_int(bfPageRefH = (unallocated - symbol optimized away), bfPageAddr = (unallocated - symbol optimized away), bfap = (unallocated - symbol optimized away), bsPage = (unallocated - symbol optimized away), refHint = (unallocated - symbol optimized away), protp = (unallocated - symbol optimized away), pl = (unallocated - symbol optimized away), plsz = (unallocated - symbol optimized away), getflag = 0, rwflg = (unallocated - symbol optimized away), chkFlg = 0, fetchPages = 0, offset = 0, len = 0) ["../../../../src/kernel/msfs/bs/bs_buffer2.c":3153, 0xfffffc0000420c1c] 6 bs_refpg(bfPageRefH = (unallocated - symbol optimized away), bfPageAddr = (unallocated - symbol optimized away), bfap = (unallocated - symbol optimized away), bsPage = (unallocated - symbol optimized away), refHint = 162657712) ["../../../../src/kernel/msfs/bs/bs_buffer2.c" :2670, 0xfffffc00004203c0] 7 fs_read(0xc00, 0x0, 0x3e8000003e8, 0x0, 0xfffffc00035e3740) ["../../../../ src/kernel/msfs/fs/fs_read_write.c":4061, 0xfffffc0000488280] 8 msfs_read(vp = (unallocated - symbol optimized away), uio = (unallocated - symbol optimized away), ioflag = (unallocated - symbol optimized away), cred = (unallocated - symbol optimized away)) ["../../../../src/kernel/msfs/osf/ msfs_vnops.c":3293, 0xfffffc000049e220] 9 vn_read(0xfffffc00002b2d00, 0xfffffe0409b1f878, 0xfffffc00011eeb40, 0x1, 0xfffffe0409b1f840) ["../../../../src/kernel/vfs/vfs_vnops.c":1257, 0xfffffc00005f0958] 10 rwuio(0xfffffe0409b18000, 0xfffffc000665e700, 0xfffffc00021f5880, 0xfffffe0409b1f8f0, 0x0) ["../../../../src/kernel/bsd/sys_generic.c":2257, 0xfffffc00002b2d54] 11 read(0x7ce000, 0xfffffc0000000001, 0x2000, 0x0, 0xffffffff00000001) ["../../../../src/kernel/bsd/sys_generic.c":2206, 0xfffffc00002b2c58] 12 syscall(0x2000, 0x0, 0x0, 0x1200019a8, 0x0) ["../../../../src/kernel/arch/ alpha/syscall_trap.c":725, 0xfffffc000065a4c0] 13 _Xsyscall(0x8, 0x3ff800d1b48, 0x3ffc009e310, 0x3, 0x140006008) ["../../../ ../src/kernel/arch/alpha/locore.s":1814, 0xfffffc000065dc9c] PROBLEM: (none) (PATCH ID: OSF520-125) ******** This patch fixes a problem where a variable was used without being initialized, which could lead to a possible kernel memory fault. PROBLEM: (89942) (PATCH ID: OSF520-063) ******** New functionality, freezefs and thawfs Enablers to support the Enterprise Volume Manager product PROBLEM: (87884, 83022, 84591, 84891) (PATCH ID: OSF520-016) ******** This patch corrects several CAM errors including: passthru IOCTL fails with EIO (CAM_BUSY) problem; RESERVATION CONFLICT driver BUSY problem; enforce super user only access for SCSI passthru. PROBLEM: (86529) (PATCH ID: OSF520-096) ******** This patch enables access to SCSI control ports (/dev/cport/scp??), allowing managment of some types of RAID controllers. A system which does not have this patch will report an error of the nature shown below: Unable to open device '/dev/cport/scp0', EINVAL (22) - Invalid argument PROBLEM: (86764) (PATCH ID: OSF520-092) ******** The unintended auto-mounts create certain slow-downs which lengthens the boot process and which increases the liklihood of other mounts being slowed down. PROBLEM: (86761, 89906) (PATCH ID: OSF520-112) ******** Cluster members appear to lose communications with other members which cause one or more nodes to panic with a "This node removed from cluster" event. The machine then reboots and seems to run correctly. PROBLEM: (89215) (PATCH ID: OSF520-108) ******** This patch fixes a panic that occurs if DMAPI operations are erroneously executed on an NFS filesystem. stack trace: 1 panic 2 trap 3 _XentMM 4 kdm_k_pathtohandle 5 kdm_dmapi_ioctl 6 kdm_ioctl 7 hwc_iomap_ioctl 8 spec_ioctl 9 vn_ioctl 10 ioctl_base 11 syscall 12 _Xsyscall PROBLEM: (88985) (PATCH ID: OSF520-133) ******** Processes triggering stack growth with anon_rss_enforce set to 2, and exceeding the set resident memory limit hang (lockmode < 4) or panic (lockmode 4). A panic triggered by this problem will have the following section in its trace: panic lock_read u_anon_rss_enforce u_anon_fault u_stack_fault vm_fault PROBLEM: (84916, 89288) (PATCH ID: OSF520-137) ******** Fix for internal kernel panic "xfer_hole_stg: unaligned kernel access" -or- "xfer_hole_stg: kernel memory fault" PROBLEM: (ALC-2-076, 86181, 88669, 88057) (PATCH ID: OSF520-067) ******** 1. This patch fixes a timing window where flushing data to disk can be incomplete when a system is going down. Note this can only occur if all of these conditions are true: o More than one thread calls the reboot() system call without first going through shutdown, /sbin/reboot, or /sbin/halt (note the operating system itself does not do this, it would have to be an application program which is calling reboot()). o O_SYNC is not in use. o AdvFS data logging is not in use. 2. If a file is opened for O_DIRECTIO and O_APPEND, and several threads write data to the file expecting the data to be appended to the file, it is possible that two threads will write their data to the same offset in the file. If this happens, the data from the second thread will overwrite the data from the first. This fix ensures that the threads are properly synchronized and that all data is appended to the end of the file. 3. This patch fixes a problem with the following symptoms. a. live_dump: aio_run_completion: ACQ_UNREF not set b. vmunix: trap: invalid memory write access from kernel mode stack trace: _XentMM src/kernel/arch/alpha/locore.s : 2115 dequeue_head src/kernel/kern/queue.c : 148 aio_run_completion src/kernel/bsd/kern_aio.c : 1946 aio_rw src/kernel/bsd/kern_aio.c : 2521 syscall src/kernel/arch/alpha/syscall_trap.c : 713 _Xsyscall src/kernel/arch/alpha/locore.s : 1785 c. Have not seen this, but there is the potential to see a thread hang waiting to reclaim a vnode with its vnode->v_numoutput being non-zero. 4. This patch fixes a condition where the smoothsync thread, in attempting to flush dirty buffers for memory-mapped files, would also flush buffers for non-memory-mapped files. This did not cause any errors, but could cause more IO than necessary to be done. Occasionally, buffers that are scheduled to be lazily written to disk get written before the normal smooth-sync scheduling. This was discovered in the routine responsible for flushing dirty memory-mapped buffers which can also flush dirty buffers for non-memory-mapped buffers. This would happen at 'smoothsync_age' intervals, which is every 30 seconds by default. PROBLEM: (FR_G01276, 86827) (PATCH ID: OSF520-032) ******** 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: (89670, 89680) (PATCH ID: OSF520-086) ******** Qar 89670 - An error path in del_clean_mcell_list() attempts to acquire locks out of hierarchy order. This will cause a lock hierarchy violation. Qar 89680 - It is possible to read to far into a log record. This will cause a kernel memory fault to occur. PROBLEM: (88758) (PATCH ID: OSF520-111) ******** The routine msfs_unmount() could cause a hang if the underlying filesystem is currently busy. PROBLEM: (90136) (PATCH ID: OSF520-147) ******** A deadlock can occur when setting "failover" or "nofailover" on an HSZ70. The deadlock could occur if you invoke "hwmgr -show comp" during the HSZ70 requests. The deadlock will not hang your system, but it will hang the hwmgr show comp request and other hwmgr requests. PROBLEM: (BCGM7243T, TKT194594) (PATCH ID: OSF520-080) ******** This patch fixes a problem where network interfaces can appear unresponsive to network traffic. PROBLEM: (87926) (PATCH ID: OSF520-047) ******** A device that has been seen at various different paths may not be available at any one of those paths during boot. For example, a device that has been moved from one location to another, will have a previously known path that no longer exists for that device. If the system tries to access that path, the following message may be printed to indicate that the path is no longer there: Path to device has been reduced This message may be printed when a previously known path to a device is not available, even though another valid path is available to access that device. This patch limits the printing of this message at boot time to just the last path to the device. If there are any valid paths to the device, then this message will be suppressed. It continues to be important to print this message for any device which has no valid paths at all. PROBLEM: (84361, 89376, 89912) (PATCH ID: OSF520-073) ******** This fix enables the quick reclaim and deallocation of a vnode. PROBLEM: (87881) (PATCH ID: OSF520-107) ******** Under stress conditions where the DMAPI functionality is in use, a panic may occur. A fix is available for this problem. stack trace: boot panic trap _XentMM kdm_msfs_pathtohandle kdm_k_pathtohandle kdm_dmapi_ioctl kdm_ioctl hwc_iomap_ioctl spec_ioctl vn_ioctl ioctl_base syscall _Xsyscall PROBLEM: (83661, 85312, STL111443) (PATCH ID: OSF520-002) ******** This patch fixes a problem where the setgid bit of a directory was not being set when created, if its parent directory has the setgid bit set. PROBLEM: (LACCH0001, 87717, 85433, 80908) (PATCH ID: OSF520-060) ******** This patch corrects several problems in kernel routing: - Fix panic when deleting an IP address. - Fix panic when performing IP re-configuration. - Fix to add interface route on address configuration. PROBLEM: (90297) (PATCH ID: OSF520-151) ******** Fix for panic "ics_unable_to_make_progress: input thread stalled" on a clustered system running with rt_preempt_opt enabled. The stack trace of the panic will look like the following: crash> tf > 0 boot 1 panic 2 ics_mct_llassert_not_stalled 3 ics_mct_thread PROBLEM: (88975, 86987, 89590) (PATCH ID: OSF520-070) ******** This patch addresses three types of ubc system issues: Change #1 Reinstate ubc_maxpercent hard limit behavior, like V4.0f, V5.0/a. Change #2 Allows ubc to purge and steal pages under very low free memory conditions during page allocation. This is a performance enhancement to the system during very low free memory conditions. Change #3 Remove memory mapping for NFS page being invalidated and freed. Pages were being freed but still mapped to the process. PROBLEM: (89942, 89918) (PATCH ID: OSF520-113) ******** This patch is for another patch, both will be distributed together. Therefore customers will not see the symptoms that this patch addresses. PROBLEM: (HPAQ3245Q, 89096) (PATCH ID: OSF520-110) ******** This patch corrects a performance problem where NFS V3 I/O used larger than necessary buffers when writing to locked files resulting in lower throughput. PROBLEM: (89942) (PATCH ID: OSF520-123) ******** This patch provides a script that will allow a user to remove the evm patch after the version switch has been thrown by running clu_upgrade -switch. This script will set back the version identifiers and request a cluster shutdown and reboot to finish the deletion of the patch. Another rolling upgrade will be required to delete the patch with dupatch. The /usr/sbin/evm_versw_undo script must be run by root in multiuser mode after the evm patch has been completely rolled in and before another rolling upgrade has begun. A system or cluster shutdown will be required to remove the evm patch. IMPORTANT: Since the removal of a version switched patch requires a cluster shutdown only run this script when you are absolutely sure that this patch is the cause of your problem. This script must be run by root in multiuser mode after completing the rolling upgrade that installed the patch and before starting another rolling upgrade. The final removal of the patch can only be accomplished by rebooting the system or cluster after this script completes its processing. This script will offer to shutdown your system or cluster at the end of its processing. If you choose to wait it is your responsiblity to execute the shutdown of the system or cluster. DO NOT FORGET OR WAIT FOR AN EXTENDED PERIOD OF TIME BEFORE SHUTTING DOWN THE CLUSTER. CLUSTER MEMBERS WHICH ATTEMPT TO REBOOT BEFORE THE ENTIRE CLUSTER IS SHUTDOWN CAN EXPERIANCE PANICS OR HANGS. PROBLEM: (89942) (PATCH ID: OSF520-093) ******** This patch establishes a new version.id for the enabling of version switched capabilities. This patch will be interdependent on all other patches which require version switches. PROBLEM: (90396) (PATCH ID: OSF520-150) ******** The KZPEA adapter returned a Check Condition with invalid sense data. This condition is being looked for by the disk driver and will now be retried. PROBLEM: (89775) (PATCH ID: OSF520-156) ******** A root user could panic the system if an illegal argument is passed to UFS mount. Example: mount -u extend /mnt/tmp Stack trace: (dbx) t > 0 boot(reason = (unallocated - symbol optimized away), howto = (unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/machdep.c":2644, 0xfffffc000067b854] 1 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/bsd/subr_prf.c":1401, 0xfffffc000029f4a0] 2 trap(a0 = (...), a1 = (...), a2 = (...), code = (unallocated - symbol optimized away), exc_frame = (unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/trap.c":2266, 0xfffffc00006696e0] 3 _XentMM(0x0, 0xfffffc000065fed4, 0xfffffc00008409a0, 0x0, 0x5de14a) ["../../../../src/kernel/arch/alpha/locore.s":2143, 0xfffffc0000663154] 4 simple_lock(0x0, 0xfffffc000065fed4, 0xfffffc00008409a0, 0x0, 0x5de14a) ["../../../../src/kernel/arch/alpha/lockprim.s":709, 0xfffffc000065fed4] 5 vrele(vp = (unallocated - symbol optimized away)) ["../../../../src/kernel/vfs/vfs_subr.c":2628, 0xfffffc00005de0c0] 6 ufs_mount(0x11fffe028, 0xfffffffe00000000, 0x0, 0x11fffaa38, 0xfffffe0428347d10) ["../../../../src/kernel/ufs/ufs_vfsops.c":1227, 0xfffffc00005b9480] 7 local_mount(0x130003600000000, 0xfffffc0000000002, 0x200, 0x3bd81bc900002000, 0x3bd81bc900000000) ["../../../../src/kernel/vfs/vfs_syscalls.c":1608, 0xfffffc00005e0294] 8 mount1(0x2, 0x3bd81bc9, 0x3bd81bc9, 0x3bd81bf9, 0x2000) ["../../../../src/kernel/vfs/vfs_syscalls.c":1767, 0xfffffc00005e0660] 9 syscall(0x14000, 0x11fffaec8, 0x0, 0xfffffe0428347900, 0x0) ["../../../../src/kernel/arch/alpha/syscall_trap.c":725, 0xfffffc000065f700] 10 _Xsyscall(0x8, 0x12005d8b8, 0x1200148c0, 0x1, 0x11fffaa38) ["../../../../src/kernel/arch/alpha/locore.s":1814, 0xfffffc0000662edc] Console message: trap: invalid memory read access from kernel mode faulting virtual address: 0x0000000000000000 pc of faulting instruction: 0xfffffc000065fed4 ra contents at time of fault: 0xfffffc00005de0c4 sp contents at time of fault: 0xfffffe0428347680 panic (cpu 0): kernel memory fault syncing disks... done PROBLEM: (QAR90619) (PATCH ID: OSF520-172) ******** This is a fix to the freezefs code that went into IPK BL0, it is not a separate patch. PROBLEM: (90504) (PATCH ID: OSF520-168) ******** Symptom: System appears hung or has poor response times. A 2-CPU system stalls while performing multiple parallel AdvFS file copies. CPU utilization drops to near zero. File copies proceed but at only a tiny fraction of their usual pace. System interactive response time is very poor even with tons of idle CPU. The same thing happens with only 1 CPU enabled also. PROBLEM: (90156, 90525, 90580) (PATCH ID: OSF520-183) ******** If you get a "panic: RDG unwire" while running with RDG and GH chunks, this patch will fix it. This scenario is especially likely to happen when running Oracle 9i, although it can happen at other times as well. PROBLEM: (QAR#90397, QAR#90784) (PATCH ID: OSF520-192) ******** The problem causes duplicate attributes to be registered for all CAM devices present in the system. A "hwmgr -get attr -id ?" command can be used to validate that the duplicate entries exist. Use the following command: > # hwmgr -get attr -id 65 | more This problem also causes duplicate statistics to be reported when CAM devices are selected. Here's an example: # iostat dsk1 dsk2 tty dsk1 dsk2 dsk1 dsk2 cpu tin tout bps tps bps tps bps tps bps tps us ni sy id 1 57 0 1 683 78 0 0 0 0 2 0 21 77 PROBLEM: (90685, 90503) (PATCH ID: OSF520-203) ******** There is a firmware issue in the HSG80 controllers that during a cluster transistion can cause the HSG80 controllers to crash. This controller crash can then cause loss of data access to those logical volumes on that pair of HSG80 controllers. If cluster root is on that HSG80 a cluster domain panic can result. The symptoms of this problem are DRD barrier errors logged to the /usr/adm/messages files and to the console. This can also be verified by examining the HSG80 fmu logs and the HSGO console. The key text in determining this problem is as follows: During processing to maintain consistency of the data for Persistent Reserve SCSI commands, an internal inconsistency was detected. > Last Failure Parameter[0] contains a code defining the precise nature Example output run fmu FMU> show last most Last Failure Entry: 6. Flags: 006FF901 Template: 1.(01) Description: Last Failure Event Occurred on 26-SEP-2001 at 10:10:29 Power On Time: 1. Years, 30. Days, 9. Hours, 1. Minutes, 11. Seconds Controller Model: HSG80 Serial Number: ZG02900845 Hardware Version: E05(2D) Software Version: XCF4P-0(FF) Instance Code: 0102030A Description: An unrecoverable software inconsistency was detected or an intentional restart or shutdown of controller operation was requested. Reporting Component: 1.(01) Description: Executive Services Reporting component's event number: 2.(02) Event Threshold: 10.(0A) Classification: SOFT. An unexpected condition detected by a controller software component (e.g., protocol violations, host buffer access errors, internal inconsistencies, uninterpreted device errors, etc.) or an intentional restart or shutdown of controller operation is indicated. Last Failure Code: 43230101 Last Failure Parameter[0.] 00000013 Last Failure Code: 43230101 Description: During processing to maintain consistency of the data for Persistent Reserve SCSI commands, an internal inconsistency was detected. > Last Failure Parameter[0] contains a code defining the precise nature of the inconsistency. Reporting Component: 67.(43) Description: Host Port Protocol Layer Reporting component's event number: 35.(23) Restart Type: 0.(00) Description: Full software restart Active Thread: FOC I960 Priority: 0.(00) Interrupt Stack Guard is intact NULL Thread Stack Guard is intact Thread Stack Guard State Flags (ID# Bit; 0=intact,1=not intact): 00000000 PROBLEM: (90349, 90810) (PATCH ID: OSF520-196) ******** SMP and NUMA system with high load averages can see negative load averages as displayed by /usr/bin/uptime command. If this occurs, the kernel scheduler will dispatch runnable threads in an unfair manner. This can result in non-optimal performance. This patch also fixes initial placement decisions by the scheduler on NUMA platforms (GS80, GS160 and GS320). The incorrect placement will result in non-optimal performance. PROBLEM: (90555) (PATCH ID: OSF520-186) ******** This patch fixes a rmvol failure that would be seen as an E_PAGE_NOT_MAPPED error when no more space is available for user data migration to another volume in the domain. The error would appear like the following: # rmvol -F dsk2b rmvol_dmn1 rmvol: Removing volume '/dev/disk/dsk2b' from domain 'rmvol_dmn1' rmvol: Can't move file /rmvol_fset1/file12 pages rmvol: Error = E_PAGE_NOT_MAPPED (-1035) rmvol: Can't move file /rmvol_fset1/file12 metadata rmvol: Can't remove volume '/dev/disk/dsk2b' from domain 'rmvol_dmn1' PROBLEM: (87242, 90632) (PATCH ID: OSF520-191) ******** This patch fixes the following tape drive problems: - a problem where tape devices spuriously rewind or go offline. It will only allow one HBA to be selected for tape I/O because using more than one path causes a problem with the MDR queuing up Unit Attentions on more paths than the tape driver is prepared to handle. - When executing the following commands; mt -f /dev/tape/tape1_d1 rewind vdump -0 -f /dev/tape/tape1_d1 -D /etc vdump fails to close and displays the following message: vdump: unable to properly close device ; [5] I/O error An example output would be: > # mt -f /dev/tape/tape1_d1 rewind > # vdump -0 -f /dev/tape/tape1_d1 -D /etc > path : /etc > dev/fset : cluster_root#root > type : advfs > advfs id : 0x3aedd0ed.000452ac.1 > vdump: Date of last level 0 dump: the start of the epoch > vdump: Dumping directories > vdump: Dumping 2749504 bytes, 69 directories, 1062 files > vdump: Dumping regular files > vdump: Rewinding and unloading tape > > vdump: unable to properly close device ; [5] I/O error > > vdump: Status at Fri Nov 2 15:52:20 2001 > vdump: Dumped 2846062 of 2749504 bytes; 103.5% completed > vdump: Dumped 69 of 69 directories; 100.0% completed > vdump: Dumped 1062 of 1062 files; 100.0% completed > vdump: Dump completed at Fri Nov 2 15:52:20 2001 PROBLEM: (90642) (PATCH ID: OSF520-204) ******** Opening a disk partition sometimes fails when the disk is on shared bus. PROBLEM: (BCGMB0G74/90845) (PATCH ID: OSF520-201) ******** System panics with kernel memory fault. Typical stack trace were ubc page being released faults because lru is corrupt. cpu 1 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1205 1 panic src/kernel/bsd/subr_prf.c : 1252 2 event_timeout src/kernel/arch/alpha/cpu.c : 1971 3 printf src/kernel/bsd/subr_prf.c : 940 4 panic src/kernel/bsd/subr_prf.c : 1309 5 trap src/kernel/arch/alpha/trap.c : 2262 6 _XentMM src/kernel/arch/alpha/locore.s : 2115 7 ubc_page_release src/kernel/vfs/vfs_ubc.c : 4852 8 cfs_rwvp_cache src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 837 9 cfs_cacheread src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 502 10 cfs_read src/kernel/tnc_common/tnc_cfe/cfs_vm_osi.c : 995 11 vn_read src/kernel/vfs/vfs_vnops.c : 1250 12 rwuio src/kernel/bsd/sys_generic.c : 2264 13 read src/kernel/bsd/sys_generic.c : 2213 14 syscall src/kernel/arch/alpha/syscall_trap.c : 713 15 _Xsyscall src/kernel/arch/alpha/locore.s : 1785 Second cpu stack trace is in ubc_written_kluster 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1205 1 panic src/kernel/bsd/subr_prf.c : 1294 2 event_timeout src/kernel/arch/alpha/cpu.c : 1971 3 mcs_lock_miss src/kernel/arch/alpha/lockprim.s : 3973 4 ubc_written_kluster_do_ubcpages src/kernel/vfs/vfs_ubc.c : 5805 5 ubc_written_kluster src/kernel/vfs/vfs_ubc.c : 5969 6 cfs_putpage src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 314 7 ubc_page_alloc src/kernel/vfs/vfs_ubc.c : 3773 8 ubc_clean_page src/kernel/vfs/vfs_ubc.c : 5631 9 ubc_kluster src/kernel/vfs/vfs_ubc.c : 5734 10 cfs_getapage src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 8 46 11 cfs_getpages src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 6 70 12 cfs_getpage src/kernel/tnc_common/tnc_cfe/cfs_vm_osi.c : 1563 13 cfs_rwvp_cache src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 791 14 cfs_cacheread src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 502 15 cfs_read src/kernel/tnc_common/tnc_cfe/cfs_vm_osi.c : 995 16 vn_read src/kernel/vfs/vfs_vnops.c : 1250 17 rwuio src/kernel/bsd/sys_generic.c : 2264 18 read src/kernel/bsd/sys_generic.c : 2213 19 syscall src/kernel/arch/alpha/syscall_trap.c : 713 20 _Xsyscall src/kernel/arch/alpha/locore.s : 1785 PROBLEM: (90017) (PATCH ID: OSF520-205) ******** When sequentially writing files that consume all of available system memory, other users sometimes see very poor interactive response. This includes hanging ls commands and hanging logins. Processes doing the writing often show random drops in their I/O rate. This may be reproduced using multiple large "cp" or "dd" commands running in parallel in the background. PROBLEM: (94038) (PATCH ID: OSF520-221) ******** Problem: This patch fixes a potential problem in which stale data (data which is out-of-date) may be returned to an application running on a CFS client when it reads data from a file on a CFS server. Compaq has corrected this problem. Problem: An fsync() or synchronous write may return to the application before some data has been flushed to disk. The data will still be queued to go out to disk but if the system crashes before it does, the update will be lost. The amount of data that will be lost will be no greater than 8192 bytes. Compaq has corrected this problem. PROBLEM: (SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-215) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (91148) (PATCH ID: OSF520-247) ******** This problem will not be seen by customers since this bug only exists in the V51a IPK pools. The I/O Barrier code will not take a reservation on a device after registration. This will occur on new devices and new cluster installations. PROBLEM: (91287, 91302) (PATCH ID: OSF520-284) ******** HSV110 Persistent Reserve with a Reservation conflict SCSI status gets passed off to cam_notify when it should not, resulting in incorrect reservation status. The error logs will have a numbers of Reservation Conflict errors with the reporting module of cdisk_handle_pr_ccb. PROBLEM: (91142) (PATCH ID: OSF520-313) ******** This fix addresses a data inconsistency that can occur when a CFS client reads a file that was recently written to. Stale data can be returned to the client. PROBLEM: (90733) (PATCH ID: OSF520-189) ******** This fixes SEL logging problem where panic events were logged as misc events. It also adds new event types that can be logged. PROBLEM: (89045) (PATCH ID: OSF520-119) ******** While performing CPU hotswap, once a CPU is removed for added into the system, a system panic would occur. PROBLEM: (SSRT0740U) (PATCH ID: OSF520-079) ******** A potential security vulnerability has been discovered in the networking, where under certain circumstances a remote system can take over packets destined for another host. PROBLEM: (89363) (PATCH ID: OSF520-084) ******** Link Aggregation groups can successfully be created and configured. However, packets can NOT be successfully transmitted nor received over the resulting lag interface. PROBLEM: (85933, HPALA1VFH) (PATCH ID: OSF520-274) ******** This patch prevents a potential panic with non-StorageWorks raid controllers that used the same name for a controller and a disk drive. This conflict was resolved in a prior release but left open the possibility that any attempt to access this disk drive by the kernel could result in a system panic caused by a kernel memory fault. PROBLEM: (89086) (PATCH ID: OSF520-305) ******** This patch is in support of a cluster patch. PROBLEM: (90523, 91030) (PATCH ID: OSF520-248) ******** Enabling anon_rss_enforce on a NUMA system breaks with the panic line of this variety: panic (cpu 6): u_anon_oop_deallocate: anon_rss_pagelist has pages queued This will occur in a stack trace along these lines: > 0 stop_secondary_cpu 1 panic 2 event_timeout 3 printf 4 panic 5 u_anon_oop_deallocate 6 vm_map_entry_delete 7 u_map_delete 8 vm_map_exit 9 exit 10 syscall 11 _Xsyscall PROBLEM: (SSRT0759U) (PATCH ID: OSF520-237) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of file corruption due to the manner in which setuid/setgid programs core dump. Compaq has corrected this potential vulnerability. PROBLEM: (BCGMB1N21) (PATCH ID: OSF520-299) ******** This patch fixes a kernel memory fault in wait_to_readyq(), or advfs_page_busy(), or potentially other routines which may reference a vm_page, bsBuf, or ioDesc that has been freed prematurely. The following events need to be present to cause this panic. (a) It has to be on a cluster. (b) A thread has to be opening the quota.user or quota.group file with the O_DIRECTIO option . (c) At the same time the thread in (b) is opening the quota.user or quota.group file, there has to be another thread adding or deleting storage to another file on the same domain#fileset. A typical stack trace for the panicing thread is the following. 4 panic 5 trap 6 _XentMM 7 wait_to_readyq 8 check_cont_bits 9 bs_io_thread PROBLEM: (83002) (PATCH ID: OSF520-293) ******** The files were incompatible with C++ due to the usage of reserved words. PROBLEM: (90757) (PATCH ID: OSF520-309) ******** The published cam_logger() interface was modified in V5.1A to accept a hardware id in its parameter list. This patch restores the cam_logger interface to its published specifications, and introduces the cam_logger3() interface to accept a hardware id in its parameter list. PROBLEM: (90221, 91235) (PATCH ID: OSF520-316) ******** This patch addresses a problem where, under certain very rare conditions, a panic with a stack trace similar to the following could result: PANIC: "pgl_remove: remove from empty (vop)->vu_cleanpl" 4 panic src/kernel/bsd/subr_prf.c 5 ubc_page_release src/kernel/vfs/vfs_ubc.c 6 cfs_putpage src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c 7 ubc_invalidate src/kernel/vfs/vfs_ubc.c 8 vclean src/kernel/vfs/vfs_subr.c 9 vgone src/kernel/vfs/vfs_subr.c PROBLEM: (LU_G01229) (PATCH ID: OSF520-275) ******** This fixes a problem with vm_faults against anon objects mapped by multiple map entires. PROBLEM: (90551) (PATCH ID: OSF520-277) ******** Patch adds ECC information to error log. PROBLEM: (BCGMA1Q9S, 89434) (PATCH ID: OSF520-250) ******** This patch fixes a problem where decreasing the smoothsync_age does not always have an effect. PROBLEM: (86861) (PATCH ID: OSF520-193) ******** System will panic and/or data corruption may occur by changing fifo parameter pipe-databuf-size while fifo operations are in flight. Panic information: (dbx) t > 0 boot(reason = (unallocated - symbol optimized away), howto = (unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/machdep.c":2644, 0xfffffc000067b854] 1 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/ bsd/subr_prf.c":1401, 0xfffffc000029f4a0] 2 trap(a0 = (...), a1 = (...), a2 = (...), code = (unallocated - symbol optimized away), exc_frame = (unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/trap.c":2266, 0xfffffc00006696e0] 3 _XentMM(0x1, 0xfffffc00005d0fc0, 0xfffffc00008409a0, 0xfffffc0059d72400, 0x0) ["../../../../src/kernel/arch/alpha/locore.s":2143, 0xfffffc0000663154] 4 fifo_write(vp = (unallocated - symbol optimized away), uiop = (unallocated - symbol optimized away), ioflag = (unallocated - symbol optimized away), cred = (unallocated - symbol optimized away)) ["../../../../src/kernel/vfs/ fifo_vnops.c":1161, 0xfffffc00005d0fc0] 5 nfsfifo_write(0xfffffc00005f7044, 0xfffffc00927b00c0, 0xfffffe04a223f878, 0xfffffc0030481d40, 0xfffffe04a223f878) ["../../../../src/kernel/nfs/ nfs_vnodeops.c":3939, 0xfffffc0000533e38] 6 vn_write(0xfffffc00002b3230, 0xfffffe04a223f878, 0xfffffc004dd7f200, 0x0, 0x4000) ["../../../../src/kernel/vfs/vfs_vnops.c":1427, 0xfffffc00005f7040] 7 rwuio(0xfffffe04a2238000, 0xfffffc000cbc9880, 0xfffffc00927b00c0, 0xfffffe04a223f8f0, 0x1) ["../../../../src/kernel/bsd/sys_generic.c":2257, 0xfffffc00002b3284] 8 write(0xb4000, 0xfffffc0000000001, 0x4000, 0x100000000, 0xffffffff00000002) ["../../../../src/kernel/bsd/sys_generic.c":2179, 0xfffffc00002b3118] 9 syscall(0x4000, 0x0, 0x0, 0x1200012fc, 0x0) ["../../../../src/kernel/arch/ alpha/syscall_trap.c":725, 0xfffffc000065f700] 10 _Xsyscall(0x8, 0x3ff800d1d18, 0x1400080b0, 0x3, 0x11fff8000) ["../../../.. /src/kernel/arch/alpha/locore.s":1814, 0xfffffc0000662edc] PROBLEM: (89964, 85632, 85344) (PATCH ID: OSF520-206) ******** This problem typically manifests itself as a kernel memory fault in bs_io_thread. The problem can be exacerbated by setting kmem_debug=0x40 and kmem_protect=4096. PROBLEM: (none) (PATCH ID: OSF520-242) ******** This patch adds code and bug fixes needed Encore Real Time Computing Inc software to run on Tru64 UNIX. PROBLEM: (91062) (PATCH ID: OSF520-320) ******** Change the rmvol error messages to more accurately reflect why rmvol failed. Change showfdmn so that it does not say it succeeded when it failed. PROBLEM: (90178, BCGM918KQ) (PATCH ID: OSF520-188) ******** Fix potential CFS deadlock. PROBLEM: (90185, 90558) (PATCH ID: OSF520-209) ******** A vfs bug was introduced in Compaq UNIX v5.1 which causes a directory look up problem in applications such as ssh. ssh v2.4.0 and v2.4.1 running on Compaq Tru64 UNIX V5.1 and later, user will see the problem when doing "ls" in sftp and when uploading public key using ssh-pubkeymgr. The problem results in an indefinite output display of effected commands. File systems which use the "new" directory format are impacted. These include NFSv3, autofs, dvdfs and cdfs. PROBLEM: (90733) (PATCH ID: OSF520-337) ******** This fixes SEL logging problem where panic events were logged as misc events. It also adds new event types that can be logged. PROBLEM: (90548, 89701, AT_G01933) (PATCH ID: OSF520-177) ******** This patch corrects a problem that is encountered when trying to create an Oracle database on a wildfire system that has a memoryless QBB. Without this patch, direct i/o to to an advfs file using asynchronous i/o will hang if it is completed on a memoryless QBB. 1. Error Message Creation of a Oracle (8.1.7.2) database fails when datafiles or redologfiles are created. Message: WARNING: aio_results_np timed out 1 times, waited 120 secs WARNING: aio_results_np timed out 1 times, waited 590 secs 2. Symptoms Oracle processes hang after this message. They can't be killed, system has to be rebootet. 3. Process leading to the symptom. Creation of a Oracle database. PROBLEM: (91327) (PATCH ID: OSF520-307) ******** This patch corrects problems when running the dd utility on a disk with a label. It would not return errors when expected. PROBLEM: (IT_G01812, SSRT0756U) (PATCH ID: OSF520-256) ******** 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: (91175) (PATCH ID: OSF520-330) ******** This patch fixes a situation in which a cluster running with multiple rads, some of which do not have valid and initialized paths, experiences problems with devices hanging with outstanding I/O. PROBLEM: (87654, 90761, FR_G02688) (PATCH ID: OSF520-285) ******** This patch fixes a problem that causes bugchecks from applications running decthreads. PROBLEM: (90130) (PATCH ID: OSF520-132) ******** This change is a fix for locking on retry case for multi-threaded select/poll. A panic with the following stack trace is indicative of this problem: PANIC: "thread_block: simple lock owned" panic thread_block() lock_wait lock_write solock soclose soo_close closef selscan do_scan select syscall _Xsyscall PROBLEM: (86308, BCSM3169H) (PATCH ID: OSF520-267) ******** This patch fixes a potential problem where system responsiveness may be impacted. In certain situations, this impact may prevent other processes from running for several seconds. This problem can occur during a filesystem synch when there are many filesystems where each contains several hundred thousand files. Note that AdvFS filesystems do not exhibit this problem. PROBLEM: (90127) (PATCH ID: OSF520-152) ******** This problem is manifested by a KMF in copyinstr under stress conditions in the DMAPI path kdm_k_pathtohandle. PROBLEM: (86747) (PATCH ID: OSF520-271) ******** This patch corrects a calculation which leads to less-than-optimal distribution of NFS client mountpoints in a hash table used by cluster mount logic. PROBLEM: (86764) (PATCH ID: OSF520-298) ******** The unintended auto-mounts create certain slow-downs which lengthens the boot process and which increases the liklihood of other mounts being slowed down. PROBLEM: (BCSMC22DM, TPO073157, FR_G02923, DJO333030) (PATCH ID: OSF520-297) ******** This patch corrects a problem where multi-volume AdvFS v3 domains exhibit I/O errors (not attributable to hardware). The same problem also causes a failed mkfset due to ENO_XTNTS. PROBLEM: (86332) (PATCH ID: OSF520-245) ******** Prior to this modification, storage allocation for a file opened for directIO could, depending on the write sizes requested, have large extent maps even though the disk is not fragmented. Although the file function correctly, performance is reduced by the numerous extent maps. This fix reduces the number of extent maps generated, and subsequently gives better IO performance on the resulting file. Extent maps for a file can be seen by using the showfile utility. PROBLEM: (91427) (PATCH ID: OSF520-328) ******** File permissions inherited from a default ACL may be different than expected in rare cases. Instead of rw------- permissions, core files are created with no permissions. Files and directories created on NFS clients are given the permissions from the default ACL, the permissions are not modified by the requested mode. When ACLs are enabled on the system and there is a default ACL on a directory, files and directories created in that directory should inherit the default ACL and permissions based on the rules that are discussed in detail in the Security manual. In particular, the file permissions should be based on the intersection of requested mode and the permissions from the default ACL, but not modified by the umask. The NFS protocol doesn't allow for passing the requested mode without the umask applied. Therefore, after this patch has been applied files and directories created on NFS clients will be given the permissions from the default ACL intersected with the requested permissions modified by the umask. This is the same as the pre-V5.0 behavior. PROBLEM: (EVT0496318B, 87204) (PATCH ID: OSF520-184) ******** This patch is to correct the problem where the DLI queue stalls when there is no traffic in the TCP/IP or HDLC stacks. In order to enable this fix, one needs to set the netisrwakeupthreshold = 0 as this will allow more than one netisr to be run by a user process. PROBLEM: (TKT262782) (PATCH ID: OSF520-240) ******** This patch corrects a problem whereby clocks on systems could move backwards after subsequent relocations of the root file system using cfsmgr. PROBLEM: (BCGM72B9W, BCGM713NZ) (PATCH ID: OSF520-262) ******** Two problems are corrected for non-NUMA systems: 1. A kernel stack not valid halt on a cpu, which will trigger a "PANIC TB_SHOOT ACK TIMEOUT" or lock timeout. From /var/adm/messages ---------------------- Jul 24 05:49:32 drpesdb02 vmunix: pmap_update_send: missing ack from cpu 9 Jul 24 05:49:32 drpesdb02 vmunix: panic (cpu 0): tb_shoot ack timeout REVISION: 2.2 DUMPFILE: vmzcore.7 NAMELIST: vmunix.7 NOTE: compressed dumpfile NOTE: kmem_debug 0x26 NOTE: CPU 9 has a haltcode of 2: kernel stack not valid PANIC: "tb_shoot ack timeout" CPUS: 10 VERSION: V5.1 (Rev. 732) MACHINE: Compaq AlphaServer GS140 6/700 2. A simple lock timeout, or a panic due to holding a simple lock during a context switch. 0 thread_block 1 lock_wait 2 lock_read 3 k_map_fault 4 vm_fault 5 trap 6 _XentMM 7 pmap_dup 8 vm_dup_va 9 aio_init 10 syscall 11 _Xsyscall PROBLEM: (85560, FR_G01693, HPAQ11R1R, SC45-0500) (PATCH ID: OSF520-180) ******** This patch corrects an issue seen on NFS clients. The aggressive behaviour of client negative lookup cache for concurrent create/lookup was tamed. PROBLEM: (BCGM21ZXL, 86314, BCGMB0PS8) (PATCH ID: OSF520-190) ******** This patch corrects an issue with mmap()ed files on a NFS mounted filesystem. Changes to a mmap()ed file were not being immediately seen. PROBLEM: (90599) (PATCH ID: OSF520-259) ******** This patch fixes a problem where the tape changer is only accessible from member that's the drd server for the changer. PROBLEM: (MXOM80005) (PATCH ID: OSF520-356) ******** This patch fixes a problem where socket based applications can hang in soclose() PROBLEM: (MGO94097A) (PATCH ID: OSF520-157) ******** During Filesystem relocation the system may panic due to a kernel memory fault when a directory larger than 8192 bytes has been deleted while simultaneously being accessed by another thread. PROBLEM: (89494, 89457, 89699, BCGM8198G) (PATCH ID: OSF520-198) ******** This patch corrects a kernel memory fault on multiple cpu systems when two or more cpus find an AdvFS problem at the same time. PROBLEM: (85887) (PATCH ID: OSF520-258) ******** Problem Description: This patch addresses a fix that is required if a system crashes while a volume is being removed from one of the AdvFS domains. If that crash occurs while a specific portion of code is being executed, the subsequent recovery of that domain will fail. This patch removes that window. The resulting domain panic will yield the following stack trace: 7 domain_panic 8 ftx_bfmeta_rec_redo 9 ftx_recovery_pass 10 ftx_bfdmn_recovery 11 bs_bfdmn_activate 12 bs_bfdmn_tbl_activate 13 bs_get_dmntbl_params 14 msfs_real_syscall 15 msfs_syscall 16 syscall PROBLEM: (HPAQ90VL6, 90457) (PATCH ID: OSF520-197) ******** This patch corrects the problem where attempts to delete psets can hang the system. PROBLEM: (90244) (PATCH ID: OSF520-315) ******** If a metadata page is about to be put onto the blocking queue, we need to first check to see if the log needs to be flushed in order to maintain the log write-ahead rule. PROBLEM: (91440) (PATCH ID: OSF520-325) ******** The corruption found was traced to error handling in certain conditions when multiple volumes are full. AdvFS would rearrange the last extent because it thought there was a hole. All cases will have a sub extent map with a hole descriptor whose page number is greater than the following extent's page number. This is not allowed under any circumstances and is a corruption of the extent map and therefore a corruption of the domain. An example you would see would look like: submap vd# Offset Cnt extentCnt bsPage vdBlk ====================================================== [11] 4 71 5 4 71 276672 72 260672 75 276960 76 -1 updateStart [12] 4 71 5 4 71 276672 72 260672 75 276960 76 -1 [13] 3 76 1 2 76 3550320 77 -1 [14] 12 77 3 3 77 -1 <--- error out of order 76 619223 79 -1 PROBLEM: (DEK063069, BE_G01725, BCSM20DQH, STL351462, BCSM20RBF, HPAQC1VVB, 91815, HPAQ12S9K, BE_G03046) (PATCH ID: OSF520-360) ******** This patch fixes a problem with multi-threaded applications that can cause the application to consume 100% of the CPU usage time. The problem is two-fold: (1) a race condition in posting and delivering signals exists and (2) nxm_idle() fails to clear a condition that keeps it from ultimately blocking as it should when invoked by an idle scheduler thread. PROBLEM: (90755) (PATCH ID: OSF520-286) ******** This patch fixes a domain panic in a cluster when a file system is mounted on a disk accessed remotely over the cluster interconnect. PROBLEM: (87371) (PATCH ID: OSF520-140) ******** This patch corrects locking problems in vclean(). PROBLEM: (90560) (PATCH ID: OSF520-266) ******** This patch fixes the CEH bus/target and lun number when lun > 127. PROBLEM: (90511) (PATCH ID: OSF520-326) ******** A kernel memory fault can occur when a device is deleted while there is outstanding IO. PROBLEM: (85196) (PATCH ID: OSF520-342) ******** This corrects problems with USB causing panics under heavily stressed systems. PROBLEM: (TKT232044) (PATCH ID: OSF520-278) ******** NetRAIN virtual interface counters are not maintained properly, which affects reporting via netstat and snmp, and affects the proper operation of NetRAIN. PROBLEM: (91393, 91102) (PATCH ID: OSF520-327) ******** This patch provides the following: - NHD4 enablers for future hardware support of an array controller - Fix to a problem found with raid services. o Applications that use Raid Services for online deletion of logical units could delete a unit that is in use. PROBLEM: (90956) (PATCH ID: OSF520-296) ******** The psrinfo -v command may print an incorrect CPU cache size in a mixed CPU size/speed environment. In addition different runs of the command may report different cache sizes for a specific CPU. PROBLEM: (GB_G02319, 90174, CFS.87260) (PATCH ID: OSF520-314) ******** This patch fixes a problem where a panic in assert_wait_mesg can occur. The problem can only occur in a cluster environment where the cluster configuration is modified (automatically or manuall) during times of excessive IO loads. PROBLEM: (SEARS-479) (PATCH ID: OSF520-166) ******** This change fixes a problem where tape and changer devices on fibre could occassionally return an incorrect offline status. This happens when there are more than 2 unit attentions presently queued up for the device. PROBLEM: (90922) (PATCH ID: OSF520-302) ******** This patch resolves the long-standing problem of saving a kernel crash dump after the disk driver shutdown code has been invoked. Previously, rather than taking a crash dump, the kernel would display the message: "DUMP: crash dump skipped: 'dont_dump' enabled." With this patch, a crash dump to memory is attempted. Additionally, it may be possible to write crash dumps to disk even after driver shutdown. This worked in limited testing (and may become commonplace). For now, to enable this, enter the following commands (as root) after boot: # dbx -k /vmunix /dev/mem (dbx) assign dump_usedowndisk=1 (dbx) quit PROBLEM: (90937) (PATCH ID: OSF520-202) ******** This patch fixes a potential race condition in the Virtual Memory subsystem. There is code in the vm_page_clean() routine that modifies a vm_page pg_busy and pg_reserved fields without the page lock being held. This might lead to potential vm_page list corruption in the kernel. This patch corrects the code to properly modify those fields while the vm_page lock is held. PROBLEM: (90985, 90394) (PATCH ID: OSF520-310) ******** This patch adds support for DS25 This will also fix a minor bug in the ES45 environmental error handling code. This bug may cause an incorrect print out on a 680 environmental machine check. This does not effect the data written to the binary log. PROBLEM: (86377, 87380, 90190, TKTB30117, BCGM40Z3J, TKT216655, SE_G02157) (PATCH ID: OSF520-263) ******** This patch corrects problems with NFS server V3 and AdvFS. Specifically NFS V3 can use large buffers and without this correction hangs could occur. Additionally, AdvFS could return EIO errors under certain conditions which have been fixed with this patch. PROBLEM: (BCGM51RKR) (PATCH ID: OSF520-264) ******** This addresses a kernel memory fault panic in malloc_thread(). panic() trap() _XentMM() malloc_thread() PROBLEM: () (PATCH ID: OSF520-257) ******** This patch fixes the predictable TCP Sequence Number. PROBLEM: (91142) (PATCH ID: OSF520-319) ******** This fix addresses a data inconsistency that can occur when a CFS client reads a file that was recently written to. Stale data can be returned to the client. PROBLEM: (90070) (PATCH ID: OSF520-311) ******** This patch is in support of a cluster patch. PROBLEM: (90736) (PATCH ID: OSF520-253) ******** This problem manifests itself as a deadlock between thawfs and addvol (or rmvol). If multiple domains are frozen, an addvol (or rmvol) on one of the domains (domain 1) will hang until the domain thaws. If a thawfs is run on on the other domain (domain 2), it will hang waiting for a resource that is being held by the addvol (or rmvol). Once that thawfs hangs, it blocks all subsequent thawfs's and deadlock occurs. PROBLEM: (87391, 89027, 84361, 89376, 89775) (PATCH ID: OSF520-323) ******** This patch fixes the following problems: - KMF while unmounting cfs file system - panic with "simple lock: minumum_spl violation" - panic with "simple lock: time limit exceeded" in "spec_reclaim" - specalias structures not being freed - mount command with the extend -u option caused panic PROBLEM: (90245, 90054) (PATCH ID: OSF520-329) ******** Attempting to modify the MTU of a lag interface (for example: ifconfig lag0 ipmtu 1000) would modify the MTUs of the attached ports, but would not modify the MTU of the lag interface itself. As a result, link aggregation would not work with gigabit ethernet jumbo frames, nor did it work properly if the MTU was decreased below 1500. If a port was down when it was enabled for link aggregation, LAG would attempt to use it anyway, resulting in lost packets and inability to communicate. The load distribution algorithm used by link aggregation resulted in poor performance in server-to-server configurations (for example: one link receives all the traffic, while other links are idle). PROBLEM: (90640) (PATCH ID: OSF520-287) ******** This patch fixes a situation where a failed open to a device will cause an error that the device cannot be deleted using hwmgr. The following is an example of how to reproduce the problem: Physically remove a disk like dsk2 hwmgr -scan scsi hwmgr -show scsi (there should be no path to dsk2) disklabel -r dsk2 (forces an open to the device, should get no such device error) hwmgr -delete scsi -did 2 (did for dsk2, should get an error here) This patch will allow the hwmgr -delete command above to complete successfully. PROBLEM: (91113) (PATCH ID: OSF520-238) ******** An incorrect return type in a logging routine prevented proper operation of the memory troller on a DS20L. This patch fixes the return type PROBLEM: (90376) (PATCH ID: OSF520-145) ******** In rare cases, when off-lining a CPU the kernel may panic as follows panic:lock_done: lock not owned by thread A stack trace of the resultant crashdump will appear as follows (editted for brevity):(dbx) t > 0 stop_secondary_cpu() "src/kernel/arch/alpha/cpu.c":1343 1 panic() "src/kernel/bsd/subr_prf.c":1296 2 event_timeout() "src/kernel/arch/alpha/cpu.c":2206 3 printf() "src/kernel/bsd/subr_prf.c":981 4 panic() "src/kernel/bsd/subr_prf.c":1353 5 lock_fault() "src/kernel/kern/lock.c":2765 6 lock_done() "src/kernel/kern/lock.c":1027 7 mapped_alloc() "src/kernel/bsd/kern_malloc.c":4605 8 malloc_internal() "src/kernel/bsd/kern_malloc.c":1677 9 _evmmiscRealloc() "src/kernel/kevm/evmmisc.c ":429 10 _evmuiAllocateEvent() "src/kernel/kevm/evmcreate.c":352 11 EvmItemSetVa() "src/kernel/kevm/evmitem.c":686 12 EvmVarSet() "src/kernel/kevm/evmvar.c":346 13 hwc_post_state_chg_event() "src/kernel/io/common/hwc/hwc_events.c":1024 14 hwc_set_access_state() "src/kernel/io/common/hwc/hwc_common.c":1866 15 ehm_cpu_offline() "src/kernel/arch/alpha/hal/platform_switch.c":1609 16 halt_secondary() "src/kernel/arch/alpha/cpu.c":1430 17 idle_thread() "src/kernel/kern/sched_prim.c":4598 (dbx) This problem has rarely been seen and can not be reliably reproduced. PROBLEM: (90914) (PATCH ID: OSF520-231) ******** The vdf and showfdmn commands might incorrectly claim that you have the error showfdmn: No such file or directory This will occur when, for example, you create a domain with two volumes. Now you remove the initial volume, When you issue either the vdf or "showfdmn -mk" commands, the error will appear. PROBLEM: (AT_G02174, 90034) (PATCH ID: OSF520-265) ******** This problem causes ADVFS to access kernel memory which has been freed. If that memory was reallocated to another subsystem, the panic may occur in a subsystem other than ADVFS. This problem will usually result in the message: PANIC: 'kernel memory fault' A typical ADVFS stack trace is: 4 panic src/kernel/bsd/subr_prf.c : 1309 5 trap src/kernel/arch/alpha/trap.c : 2262 6 _XentMM src/kernel/arch/alpha/locore.s : 2115 7 advfs_ubc_page_hold src/kernel/vfs/vfs_ubc.c : 2987 8 advfs_page_hold src/kernel/msfs/bs/bs_buffer2.c : 2071 9 bfflush_start src/kernel/msfs/bs/bs_qio.c : 3746 10 bs_bf_flush_nowait src/kernel/msfs/bs/bs_qio.c : 4395 11 cp_copy_page_range src/kernel/msfs/bs/bs_copy.c : 309 12 migrate_normal src/kernel/msfs/bs/bs_migrate.c : 1648 13 migrate_normal_one_disk src/kernel/msfs/bs/bs_migrate.c : 1275 14 mig_migrate src/kernel/msfs/bs/bs_migrate.c : 1050 15 bs_migrate src/kernel/msfs/bs/bs_migrate.c : 933 16 msfs_syscall_op_migrate src/kernel/msfs/bs/bs_misc.c : 5749 17 msfs_real_syscall src/kernel/msfs/bs/bs_misc.c : 3637 18 msfs_syscall src/kernel/msfs/osf/msfs_syscalls.c : 145 PROBLEM: (88138, 87569, 87369, 86825, 87636, 88029, 89152, 89464, 89563, 89575, 89603, 89732, 89801, 89804, 90757) (PATCH ID: OSF520-334) ******** PROBLEM: (86825, 87569, 88138, 89603 and 89732) (PATCH ID: ) Application and system hangs may occur when I/O fails to abort. PROBLEM: (87369) (PATCH ID: ) The KZPEA driver failed to clear pending I/O when a 3rd party bus reset or hardware requested initialization occurred. PROBLEM: (88029, 89152, 89801 and 89804) (PATCH ID: ) Open errors may occur when attempting to open a device connected to the KZPEA during a bus or device reset. PROBLEM: (89464, 89563, 89575 and 89763) (PATCH ID: ) A "Kenerl Memory Fault" panic could occur due to a timing window where an aborted I/O could be sent to the device while the I/Os resources were released. Depending on the timing the resulting panic trace could be one of the following: Trace #1 > 0 boot src/kernel/arch/alpha/machdep.c : 2774 1 panic src/kernel/bsd/subr_prf.c : 1255 2 lock_fault src/kernel/kern/lock.c : 2745 3 lock_write src/kernel/kern/lock.c : 899 4 lgr_flush_start src/kernel/msfs/bs/ms_logger.c : 4326 5 msfs_mntflushbuf src/kernel/msfs/osf/msfs_vfsops.c : 4851 6 mntflushbuf src/kernel/vfs/vfs_bio.c : 1877 7 boot src/kernel/arch/alpha/machdep.c : 2685 8 panic src/kernel/bsd/subr_prf.c : 1334 9 lock_fault src/kernel/kern/lock.c : 2745 10 lock_read src/kernel/kern/lock.c : 1239 11 k_map_fault src/kernel/vm/vm_kmap.c : 426 12 vm_fault src/kernel/vm/vm_fault.c : 168 13 trap src/kernel/arch/alpha/trap.c : 2137 14 _XentMM src/kernel/arch/alpha/locore.s : 2115 15 SCSIhAbortTask src/kernel/io/cam/aha_chim/chim/src/hwmtask.c : 1308 16 SCSIHQueueSpecialHIOB src/kernel/io/cam/aha_chim/chim/src/hwmtask.c : 265 17 SCSIrAbortTask src/kernel/io/cam/aha_chim/chim/src/rsmtask.c : 1112 18 SCSIRQueueSpecialHIOB src/kernel/io/cam/aha_chim/chim/src/rsmtask.c : 175 19 SCSIQueueIOB src/kernel/io/cam/aha_chim/chim/src/xlmtask.c : 3946 20 EnqueueAdapterOsmIOB src/kernel/io/cam/aha_chim/aha_chim_if.c : 1931 21 aha_chim_abort_job src/kernel/io/cam/aha_chim/aha_chim.c : 2770 22 aha_chim_job_timeout src/kernel/io/cam/aha_chim/aha_chim.c : 2519 23 softclock_scan src/kernel/bsd/kern_clock.c : 1681 Trace #2 > 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1343 1 panic src/kernel/bsd/subr_prf.c : 1296 2 event_timeout src/kernel/arch/alpha/cpu.c : 2206 3 printf src/kernel/bsd/subr_prf.c : 981 4 panic src/kernel/bsd/subr_prf.c : 1353 5 xpt_callback src/kernel/io/cam/xpt.c : 3702 6 aha_chim_cam_sio_done src/kernel/io/cam/aha_chim/aha_chim_scsi.c : 2877 7 NormalPostRoutine src/kernel/io/cam/aha_chim/aha_chim_if.c : 2578 8 SCSIBackEndISR src/kernel/io/cam/aha_chim/chim/src/xlmtask.c : 5345 9 OSMBackEndIntHandler src/kernel/io/cam/aha_chim/aha_chim_if.c : 2440 10 aha_chim_intr_deferred src/kernel/io/cam/aha_chim/aha_chim.c : 2452 11 aha_chim_interrupt_thread src/kernel/io/cam/aha_chim/aha_chim.c : 2350 PROBLEM: (SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-338) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (92854) (PATCH ID: OSF520-418) ******** Fixes the no-roll undo of the evm related version switched patch. When deleting the evm version switched patch. The following error message can occur if this patch was not installed: Failure to switch versions because the new version is older than than the active version PROBLEM: (91034) (PATCH ID: OSF520-501) ******** This patch fixes a problem with the logging of MUNSA reject status messages to the console during boot which could cause a system to boot extremely slow. This is a sample of what the messages could look like: 21:45:06 cam_logger: SCSI event packet 21:45:06 cam_logger: hardware_idA9 bus 23 target 17 lun 2 21:45:06 cdisk_op_spin 21:45:06 Device Not Ready 21:45:06 Hard Error Detected 21:45:06 Hardware ID = 419 21:45:06 DEC HSG80 V86F 21:45:06 Active CCB at time of error 21:45:06 Unknown CAM Status 21:45:14 cam_logger: SCSI event packet 21:45:14 cam_logger: hardware_idH3 bus 23 target 29 lun 2 21:45:14 cdisk_op_spin 21:45:14 Device Not Ready 21:45:14 Hard Error Detected 21:45:14 Hardware ID = 483 21:45:14 DEC HSG80 V86F 21:45:14 Active CCB at time of error 21:45:14 Unknown CAM Status 21:45:22 cam_logger: SCSI event packet 21:45:22 cam_logger: hardware_idB0 bus 22 target 17 lun 3 21:45:22 cdisk_op_spin 21:45:22 Device Not Ready 21:45:22 Hard Error Detected 21:45:22 Hardware ID = 420 21:45:22 DEC HSG80 V86F 21:45:23 Active CCB at time of error 21:45:23 Unknown CAM Status 21:45:31 cam_logger: SCSI event packet 21:45:31 cam_logger: hardware_idB5 bus 22 target 17 lun 1 21:45:31 cdisk_op_spin 21:45:31 Device Not Ready