PROBLEM: (94970) (PATCH ID: OSF540-169) ******** This problem manifests itself as a process hang. It results when a multithreaded process marks a piece of a memory object KEEP_ON_EXEC or INHERIT. Some of the threads will appear to hang forever, waiting for nonexistant faulters to finish faulting. The stack trace looks like this: 0 thread_block src/kernel/kern/sched_prim.c : 2376 1 u_map_delete src/kernel/vm/vm_umap.c : 1456 2 u_map_exec src/kernel/vm/vm_umap.c : 1798 3 vm_exec src/kernel/vm/vm_unix.c : 1082 4 coff_ungetxfile src/kernel/bsd/coff_exec.c : 477 5 exec_ungetxfile src/kernel/bsd/kern_exec.c : 1016 6 common_exec src/kernel/bsd/kern_exec.c : 638 7 execve src/kernel/bsd/kern_exec.c : 378 8 syscall src/kernel/arch/alpha/syscall_trap.c : 632 9 _Xsyscall src/kernel/arch/alpha/locore.s : 1505 PROBLEM: (94444) (PATCH ID: OSF540-170) ******** System panicks with "thread_block: simple lock held" while trying to MALLOC memory in a low-memory situation. Routine calling malloc_internal() would be swap_alloc(). PROBLEM: (94860) (PATCH ID: OSF540-173) ******** System takes a KMF during a memory error machine check. PROBLEM: (94399) (PATCH ID: OSF540-174) ******** The patch corrects a problem in which 3d clients using the Radeon graphics card can corrupt the pagetables mapping various shared libraries. This causes all processes using those libraries to loop in the pagefault code (u_seg_fault). PROBLEM: (94598) (PATCH ID: OSF540-188) ******** Some customers see a drop in performance while using Oracle when running with gh_chunks or rad_gh_regions. PROBLEM: (94986) (PATCH ID: OSF540-182) ******** Irregular cache parameters can yield a non-power of two color bucket count. This can lead to a "get_color_bucket: empty buckets!" panic or a "kernel memory fault". PROBLEM: (GB_G03575, 89303, 94404, 93414, 94528, 94736) (PATCH ID: OSF540-028) ******** PROBLEM: System crashes with a kernel memory fault in u_seg_global_destroy. PROBLEM: The symptom of this problem is a kernel memory fault, most often originating in the fault path for anonymous memory. A typical stack traceback is shown below: 0 boot src/kernel/arch/alpha/machdep.c 1 panic src/kernel/bsd/subr_prf.c 2 trap src/kernel/arch/alpha/trap.c 3 _XentMM src/kernel/arch/alpha/locore.s 4 _a_lock_C src/kernel/arch/alpha/lockprim.s 5 anon_getpage src/kernel/vm/vm_anon.c 6 u_anon_fault src/kernel/vm/u_mape_anon.c 7 u_map_fault src/kernel/vm/vm_umap.c 8 vm_fault src/kernel/vm/vm_fault.c 9 trap src/kernel/arch/alpha/trap.c 10 _XentMM src/kernel/arch/alpha/locore.s PROBLEM: When the system starts swapping, a process goes to sleep in an uninterruptable state (hangs). The condition remedied by this patch is being encountered if there is a vm_object in the process which has the OB_SWAP bit set, but which is not being swapped. PROBLEM: Kernel memory fault while running with protection on the 128-byte bucket. The typical stack trace is: 0 stop_secondary_cpu 1 panic 2 trap 3 _XentMM 4 u_anon_fault_page 5 u_anon_fault 6 u_map_copy_overwrite 7 procfs_write PROBLEM: A taso application begins to fail memory allocations after an mmap is bumped to be above the heap, since the space below the stack is in use. (calls to malloc, etc.) PROBLEM: (95046) (PATCH ID: OSF540-172) ******** A panic can occur when reading granularity hint memory from another process via the procfs interface. Typical stack trace as follows: 4 panic 5 trap 6 _XentMM 7 vm_handle_if_gran_hint 8 procfs_read 9 vn_read 10 rwuio 11 read 12 syscall 13 _Xsyscall PROBLEM: (94687) (PATCH ID: OSF540-194) ******** Panic string is "u_seg_vop_remove: seg not found in vop". The stack traces of the two racing threads may look similar to the following: > 0 stop_secondary_cpu(do_lwc = (unallocated - symbol optimized away)) ["../../ ../../src/kernel/arch/alpha/cpu.c":1205, 0xfffffc00004f4300] 1 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/bsd /subr_prf.c":1252, 0xfffffc00002931e4] 2 event_timeout(func = (unallocated - symbol optimized away), arg = (unallocate d - symbol optimized away), timeout = (unallocated - symbol optimized away)) [". ./../../../src/kernel/arch/alpha/cpu.c":1971, 0xfffffc00004f5534] 3 printf(fmt = (unallocated - symbol optimized away)) ["../../../../src/kernel/ bsd/subr_prf.c":940, 0xfffffc0000292598] 4 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/bsd /subr_prf.c":1309, 0xfffffc0000293318] 5 u_seg_vop_remove(0x1, 0xfffffc000a1fae18, 0x10, 0xb3f7f600, 0x400000000000000 ) ["../../../../src/kernel/vm/u_mape_seg.c":707, 0xfffffc00004aaa84] 6 u_seg_global_destroy(0xfffffc00004ad660, 0xfffffc00fa345900, 0x120000000, 0x4 0000000000, 0xfffffc00b46aea00) ["../../../../src/kernel/vm/u_mape_seg.c":983, 0 xfffffc00004ab1b8] 7 u_seg_oop_terminate(0xfffffc00b46aea00, 0x800000, 0xfffffc00004bb304, 0xfffff c005c69ac80, 0xfffffc0002306040) ["../../../../src/kernel/vm/u_mape_seg.c":2175, 0xfffffc00004ad65c] 8 vm_map_entry_delete(0xfffffc00004bb304, 0xfffffc005c69ac80, 0xfffffc000230604 0, 0xfffffc000a1fae68, 0xfffffc00004c93e0) ["../../../../src/kernel/vm/vm_map.c" :2318, 0xfffffc00004bb300] 9 u_map_delete(0xfffffc001f3ab680, 0x0, 0xfffffc000a1fae68, 0xfffffc0000000000, 0xfffffc00fa345900) ["../../../../src/kernel/vm/vm_umap.c":1678, 0xfffffc00004c 93dc] 10 vm_map_exit(0xfffffc00fa345900, 0xfffffc000a1fae00, 0xfffffc000026c900, 0xff fffc003d6a3740, 0x0) ["../../../../src/kernel/vm/vm_map.c":2727, 0xfffffc00004bb 808] 11 exit(0xfffffc003d6a3814, 0x900000000, 0xfffffc003d6a3500, 0xfffffc003d6a3838 , 0x0) ["../../../../src/kernel/bsd/kern_exit.c":1515, 0xfffffc000026c8fc] 12 sigexit(p = (unallocated - symbol optimized away), sig = (unallocated - symb ol optimized away)) ["../../../../src/kernel/bsd/kern_sig.c":5974, 0xfffffc00002 86c0c] 13 psig(sig = (unallocated - symbol optimized away)) ["../../../../src/kernel/b sd/kern_sig.c":5681, 0xfffffc000028608c] 14 mach_checksig() ["../../../../src/kernel/bsd/kern_sig.c":4837, 0xfffffc00002 84620] 15 nxm_extra_idle(arg = (unallocated - symbol optimized away)) ["../../../../sr c/kernel/kern/syscall_subr.c":3237, 0xfffffc00002d7da8] 16 nxm_thread_destroy() ["../../../../src/kernel/kern/syscall_subr.c":4747, 0xf ffffc00002d9c38] 17 _Xsyscall(0x8, 0x3ff805cadbc, 0x3ffc01be510, 0x0, 0x0) ["../../../../src/ker nel/arch/alpha/locore.s":1990, 0xfffffc00004e2bf8] > 0 stop_secondary_cpu(do_lwc = (unallocated - symbol optimized away)) ["../../. ./../src/kernel/arch/alpha/cpu.c":1205, 0xfffffc00004f4300] 1 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/bsd /subr_prf.c":1252, 0xfffffc00002931e4] 2 event_timeout(func = (unallocated - symbol optimized away), arg = (unallocate d - symbol optimized away), timeout = (unallocated - symbol optimized away)) [". ./../../../src/kernel/arch/alpha/cpu.c":1971, 0xfffffc00004f5534] 3 printf(fmt = (unallocated - symbol optimized away)) ["../../../../src/kernel/ bsd/subr_prf.c":940, 0xfffffc0000292598] 4 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/bsd /subr_prf.c":1309, 0xfffffc0000293318] 5 u_seg_vop_remove(0x1, 0xfffffc000a1fae18, 0x10, 0xb3f7f600, 0x400000000000000 ) ["../../../../src/kernel/vm/u_mape_seg.c":707, 0xfffffc00004aaa84] 6 u_seg_global_destroy(0xfffffc00004ad660, 0xfffffc00fa345900, 0x120000000, 0x4 0000000000, 0xfffffc00b46aea00) ["../../../../src/kernel/vm/u_mape_seg.c":983, 0 xfffffc00004ab1b8] 7 u_seg_oop_terminate(0xfffffc00b46aea00, 0x800000, 0xfffffc00004bb304, 0xfffff c005c69ac80, 0xfffffc0002306040) ["../../../../src/kernel/vm/u_mape_seg.c":2175, 0xfffffc00004ad65c] 8 vm_map_entry_delete(0xfffffc00004bb304, 0xfffffc005c69ac80, 0xfffffc000230604 0, 0xfffffc000a1fae68, 0xfffffc00004c93e0) ["../../../../src/kernel/vm/vm_map.c" :2318, 0xfffffc00004bb300] 9 u_map_delete(0xfffffc001f3ab680, 0x0, 0xfffffc000a1fae68, 0xfffffc0000000000, 0xfffffc00fa345900) ["../../../../src/kernel/vm/vm_umap.c":1678, 0xfffffc00004c 93dc] 10 vm_map_exit(0xfffffc00fa345900, 0xfffffc000a1fae00, 0xfffffc000026c900, 0xff fffc003d6a3740, 0x0) ["../../../../src/kernel/vm/vm_map.c":2727, 0xfffffc00004bb 808] 11 exit(0xfffffc003d6a3814, 0x900000000, 0xfffffc003d6a3500, 0xfffffc003d6a3838 , 0x0) ["../../../../src/kernel/bsd/kern_exit.c":1515, 0xfffffc000026c8fc] 12 sigexit(p = (unallocated - symbol optimized away), sig = (unallocated - symb ol optimized away)) ["../../../../src/kernel/bsd/kern_sig.c":5974, 0xfffffc00002 86c0c] 13 psig(sig = (unallocated - symbol optimized away)) ["../../../../src/kernel/b sd/kern_sig.c":5681, 0xfffffc000028608c] 14 mach_checksig() ["../../../../src/ke rnel/bsd/kern_sig.c":4837, 0xfffffc0000284620] 15 nxm_extra_idle(arg = (unallocated - symbol optimized away)) ["../../../../sr c/kernel/kern/syscall_subr.c":3237, 0xfffffc00002d7da8] 16 nxm_thread_destroy() ["../../../../src/kernel/kern/syscall_subr.c":4747, 0xfffffc00002d9c38] 17 _Xsyscall(0x8, 0x3ff805cadbc, 0x3ffc01be510, 0x0, 0x0) ["../../../../src/ker nel/arch/alpha/locore.s":1990, 0xfffffc00004e2bf8] PROBLEM: (92310) (PATCH ID: OSF540-110) ******** The mlockall() function, when given the MCL_FUTURE flag, is supposed to cause all future memory allocations in that process to become wired. However, memory obtained from the mmap() function was not being wired correctly after using mlockall(). This results in low performance from the mmap memory pages. PROBLEM: (94399) (PATCH ID: OSF540-178) ******** The patch corrects a probelm in which 3d clients using the Radeon graphics card can corrupt the pagetables mapping various shared libraries. This causes all processes using those libraries to loop in the pagefault code (u_seg_fault). PROBLEM: (95190) (PATCH ID: OSF540-209) ******** When a program calls mmap() several times on consecutive parts of a file, a "panic: Bigpage Assertion Failed" may result. The stack trace will show a call to vm_bigpg_info_grow() which caused the panic. PROBLEM: (95255, 95263) (PATCH ID: OSF540-223) ******** Problem 1: The vm attribute vm_bigpg_thresh is being rounded incorrectly. This can result in considerably more bigpages of the smaller sizes on the free page lists. Applications may not be able to take full advantage of bigpages due to the lack of the larger page sizes. Problem 2: If a system running with bigpages enabled is experiencing memory problems, some of the bad page information can be lost. This can result in a machine check panic. Problem 3: If an application uses mmap on dev/mem to gain access to bigpages on the free page list, the system could panic with "vm_pg_free: page mapped" PROBLEM: (95450) (PATCH ID: OSF540-291) ******** If a set of kernel virtual addresses at the high end of virtual memory are unmapped, the system may panic with "delete_pv_entry: mapping not in pv_list". The failure can be identified with the following stack trace: 1 panic src/kernel/bsd/subr_prf.c : 1325 2 event_timeout src/kernel/arch/alpha/cpu.c : 2341 3 printf src/kernel/bsd/subr_prf.c : 1008 4 panic src/kernel/bsd/subr_prf.c : 1382 5 delete_pv_entry src/kernel/arch/alpha/pmap.c : 2496 6 pmap_remove_range src/kernel/arch/alpha/pmap.c : 3389 7 pmap_remove src/kernel/arch/alpha/pmap.c : 3588 8 anon_remap src/kernel/vm/vm_anon.c : 1412 9 anon_grow src/kernel/vm/vm_anon.c : 1126 10 u_anon_grow src/kernel/vm/u_mape_anon.c : 5414 11 u_map_entry_grow src/kernel/vm/vm_umap.c : 1424 12 u_map_enter src/kernel/vm/vm_umap.c : 1490 13 u_anon_create src/kernel/vm/u_mape_anon.c : 1558 14 smmap src/kernel/bsd/kern_mman.c : 1309 15 syscall src/kernel/arch/alpha/syscall_trap.c : 725 PROBLEM: (93958) (PATCH ID: OSF540-184) ******** PROBLEM: When an external USB hub is disconnected, subsequent USB device connections may not work. PROBLEM: (HPAQ31380) (PATCH ID: OSF540-017) ******** This change removes a restriction where dynamic VMEbus device drivers could only probe one controller per driver. Multiple controllers per driver now configure successfully. PROBLEM: (95076) (PATCH ID: OSF540-171) ******** This patch fixes a potential floating point register corruption. This could be seen as an application coredump or incorrect floating point data. PROBLEM: (94705) (PATCH ID: OSF540-198) ******** This patch fixes multiple problems affecting a system with peripheral USB hubs attached, as well as problems that might occur when moving or adding USB host adapters. PROBLEM: Repeatedly disconnecting and connecting USB hubs results in a failure to configure the USB hub or devices below it. PROBLEM: The kernel can not be built (with doconfig) with a peripheral hub connected. PROBLEM: After moving or adding USB host adapters, rebuilding the kernel, and rebooting, the host adapters may not configure correctly. PROBLEM: (95461) (PATCH ID: OSF540-314) ******** When running a heavy IO load, the lockinfo utility will show contention for the kernel_pmap.other_lock lock. When an IO completes, certain locks have to be taken out to update the address space for the process issuing the IO. On a numa system, a change to the way the address space is mapped can be made which eliminates the need for the locks. This can improve IO performance by removing the contention on those locks. PROBLEM: (95102) (PATCH ID: OSF540-181) ******** GS1280 system will hang when using Open3d graphics over the AGP bus. PROBLEM: (93637, 94706) (PATCH ID: OSF540-120) ******** PROBLEM: In order to see this problem, a program must open a file without direct I/O enabled and access it enough so that a large portion of it is resident in the UBC. The program must then close the file and reopen it with direct I/O enabled. Accesses to the file at this point will become very slow because the pages resident in the UBC need to be removed. This was being done very ineffieciently which was causing a noticeable performance impact. The patch corrects the inefficiency and improves performance in this case. PROBLEM: Under certain conditions, appending data to a file can cause the system to panic. It is known to happen when using UFS. PROBLEM: (94058, DSATL0KQN, 94312) (PATCH ID: OSF540-060) ******** Patch 1) This patch fixes an AdvFS asynchronous direct IO problem that could cause a thread to hang. The asynchronous IO completion handling by AdvFS did not always decrement the v_numoutput field in the vnode. When the vnode was eventually put on the free list it still had an non-zero count in v_numoutput. When another thread tried to get a new vnode, and happened upon this one, it would hang waiting for v_numoutput to go to zero during vclean(). A typical stack trace for the hung thread is: 0 thread_block() ["/kernel/kern/sched_prim.c":3284, 0xfffffc00002e72e0] 1 vflushbuf_aged() ["/kernel/vfs/vfs_bio.c":2149, 0xfffffc0000602d14] 2 vclean() ["/kernel/vfs/vfs_subr.c":3231, 0xfffffc000060ca04] 3 vgone() ["/kernel/vfs/vfs_subr.c":3496, 0xfffffc000060cdc0] 4 getnewvnode() ["/kernel/vfs/vfs_subr.c":2120, 0xfffffc000060b6cc] 5 vdealloc() ["/kernel/vfs/vfs_subr.c":1746, 0xfffffc000060af48] 6 vrele() ["/kernel/vfs/vfs_subr.c":2841, 0xfffffc000060c39c] ... Patch 2) This patch addresses an issue when truncating AdvFS files within a trailing fragment. If such a truncation was performed leaving a segment of valid data virtual memory-based accesses (e.g, mmap and NFS server) would erroneously see zeroes for the untruncated data. PROBLEM: (93075) (PATCH ID: OSF540-187) ******** Changed behavior of migrate_normal and migrate_stripe when migrating an original file that has a clone. If the clone was marked out of sync, migrate could come back with E_CLONE_OUT_OF_SYNC even though the migrate succeeded. Now this case is caught, and handled. PROBLEM: (93869, 93585) (PATCH ID: OSF540-002) ******** This patch replaces the system panics caused by "Can't clear bit twice" with a domain panic. Panic strings include: "bad v0 frag free list" "get bf set attr failed." "invalid fragSlot" "bs_frag_alloc: invalid frag" "bs_frag_alloc: invalid frag group Also included in this path is some code clean up. There are times when a routine will only return success, yet we were checking return value for failure. PROBLEM: (BCSM81VX7, GB_G01823, 89491) (PATCH ID: OSF540-025) ******** This fixes an invalid pointer access panic in AdvFS. This happens after AdvFS has encountered various I/O errors that cause AdvFS to put a filesystem into its domain panic state. AdvFS error handling was not properly initializing a fileset pointer variable to NULL. During cleanup, the non-null variable would falsely indicate a filesystem fileset needed to be closed and would panic due to a bad fileset pointer. PROBLEM: (94831) (PATCH ID: OSF540-193) ******** This patch fixes an issue encountered in configurations where the primary processor is not the first processor within a rad. It would most likely be seen as a kmf during boot: Compaq Tru64 UNIX T5.1B-6 (Rev. 2635); Thu Aug 29 16:38:29 EDT 2002 physical memory = 16384.00 megabytes. available memory = 15855.22 megabytes. using 62829 buffers containing 490.85 megabytes of memory Master cpu at slot 11 Starting secondary cpu 0 Starting secondary cpu 1 Starting secondary cpu 2 Starting secondary cpu 3 Starting secondary cpu 4 Starting secondary cpu 5 Starting secondary cpu 6 Starting secondary cpu 7 Starting secondary cpu 8 trap: invalid memory read access from kernel mode faulting virtual address: 0x0000000000000078 PROBLEM: (94224, 91581, 93794) (PATCH ID: OSF540-080) ******** PROBLEM: Some CDROM media created by third party software can be mounted, but not viewed with commands such as ls() or find(). PROBLEM: When using synchronous IO, a false indication of success will be returned when writing to a file and exceeding the file size limits imposed by the operating system. PROBLEM: _PC_FILESIZEBITS used by pathconf to determine file characteristics was calculated incorrectly. PROBLEM: (93714, 92650, 92648, KMF, 92212, 83371, 94138) (PATCH ID: OSF540-141) ******** PROBLEM: Not all audit data in the log is displayed after being sorted. PROBLEM: System panic in audit_rec_build. PROBLEM: Setting select/deselect flag on a directory does not affect if an audit event is generated (with obj select/obj deselect) when an audited file operation is performed. PROBLEM: (94558) (PATCH ID: OSF540-015) ******** There was a race between the IO completion routine and the routine that waits for all IOs to be completed when removing a volume. Under certain conditions, the volume removal could occur before the IO completion routine was done touching the in-memory structure for the volume. This fix corrects that race. PROBLEM: (92703, 93126, 93724) (PATCH ID: OSF540-019) ******** Corrects insmntque() to use proper locking when inserting and removing vnodes from the mount vlist. Adds a check in shadowvode() to validate the specinfo structure pointer before using the macro to obtain the pointer to the shadow vnode. Excessive FIDS lock contention is observed when large number of files using system based file locking. Result from "lockinfo -sort=misses -d 20 -f 200 -p 25 -l 20" will show at the top of the list with a high miss rate. PROBLEM: (BCGMC1CKJ, FR_G03239) (PATCH ID: OSF540-033) ******** This correction avoids a silent infinite loop in vdump by correcting the AdvFS system call OP_GET_BKUP_XTNT_MAP. The call will now return the valid xtntCnt when it fails due to E_NOT_ENOUGH_XTNTS. PROBLEM: (94079) (PATCH ID: OSF540-098) ******** PROBLEM: (94079) (PATCH ID: ) This fix address a problem in the swapping subsystem where the proper locks were not being held during a thread state check. A possible symptom for this problem could be the panic string "thread_setrun: non null runq" with the following stack trace: 4 panic 5 thread_setrun 6 thread_doswapin 7 swapin_thread PROBLEM: (94453, 94489, 94517, 94376, 94375) (PATCH ID: OSF540-108) ******** PROBLEM: qar 94453 An MFS filesystem cannot be unmounted if the mfs daemon is not present. # umount /mnt/mfs /tmp_mnt/mfs: I/O error # umount -f /mnt/mfs /mnt/mfs: I/O error PROBLEM: qar 94489 MFS can panic in unmount. # mfs -s 500 /mnt/mfs; cd /mnt/mfs # kill the MFS daemon # sleep 1; cd; umount /mnt/mfs One example of a stack trace: > 0 boot() 1 panic() 2 simple_lock_fault() 3 simple_lock_minspl_violation() 4 vfs_busy() 5 dounmount() 6 mfs_mount_block() 7 mfs_start() 8 local_mount() 9 mount1() 10 syscall() 11 _Xsyscall() PROBLEM: qar 94517 Error paths in ufs_mount can lead to panic. This is only seen if the system would fail a mount operation due to insufficient memory. PROBLEM: qar 94376 A getdirentries operation on the FDFS filesystem shows an error: # ls /dev/fd /dev/fd: Invalid argument ... PROBLEM: qar 94375 The FDFS filesystem cannot be unmounted after an attempt is made to create a file within it. # touch /dev/fd/abc touch: /dev/fd/abc cannot create # umount /dev/fd /cluster/members/member0/dev/fd: Device busy PROBLEM: (DE_G03592, 92540) (PATCH ID: OSF540-099) ******** | This problem is an unaligned access from the kernel. The symptoms are a panic similar to the following: | Unaligned kernel access va=0xfffffc0023aad1a3 pc=0xfffffc000047f460 ra=... | panic (cpu 0): Unaligned kernel space access from kernel mode 0 boot src/kernel/arch/alpha/machdep.c : 2644 1 panic src/kernel/bsd/subr_prf.c : 1401 2 afault_trap src/kernel/arch/alpha/trap.c : 3089 3 _XentUna src/kernel/arch/alpha/locore.s : 2278 4 seq_search src/kernel/msfs/fs/fs_dir_lookup.c : 1685 5 msfs_lookup src/kernel/msfs/osf/msfs_lookup.c : 869 6 cfs_comm_lookup src/kernel/tnc_common/tnc_cfe/alpha/cfs_server.c :2922 7 cfscall_lookup src/kernel/tnc_common/tnc_cfe/alpha/cfs_vnops.c : 4958 8 cfs_lookup src/kernel/tnc_common/tnc_cfe/alpha/cfs_vnops.c : 4855 9 namei src/kernel/vfs/vfs_lookup.c : 1010 10 vn_open src/kernel/vfs/vfs_vnops.c : 783 11 copen src/kernel/vfs/vfs_syscalls.c : 3487 12 syscall src/kernel/arch/alpha/syscall_trap.c : 725 13 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 | This problem may show itself from advfs routines other than seq_search. | The other routines include setup_for_glom_dir_entries, idx_convert_dir, | new_parent, check_path_back, and remove_dots. | This problem will continue to occur with each access of the bad data from the disk. So do not remount the filesystem causing the problem unless you wish a recurrence. PROBLEM: (93501) (PATCH ID: OSF540-013) ******** There was improper synchronization between threads writing to files via directIO and the copy-on-write of that file's pages if it is cloned. This could allow a stale copy of data to be left in the UBC which would be returned on a subsequent read operation of that page. This would appear to the application as a read of stale data from the file, even though the data on disk was correct. PROBLEM: (91901, 93789) (PATCH ID: OSF540-001) ******** advscan can be fooled into thinking everything is OK, when it is not. If you create a domain and add a volumes to it. Say the domain is TEST and two volumes are ${DISK}a and ${DISK}b. Now do the following: mkdir /etc/fdmns/BAD mv /etc/fdmns/test/${DISK}b /etc/fdmns/BAD/ when advscan is run on ${DISK}, it will report everything as ok. : Actual partitions found: ${DISK}a ${DISK}b Now when you try to mount the domain, it will fail: mount TEST#TEST /mnt /etc/fdmns/TEST has 2 links. TEST#TEST on /mnt: I/O error The new behavior will yield: Actual partitions found: ${DISK}a ${DISK}b *** Incorrectly located in *** /etc/fdmns/BAD The mount will still fail, but it is now expected. The other issue will now print an error message like: AdvFS I/O error: Domain#Fileset: dombac#fsetbac Mounted on: /bac Volume: /dev/disk/dsk630c Tag: 0x000000c1.8001 Page: 548676 Block: 2431675264 Block count: 256 Type of operation: Write Error: 30 (see /usr/include/errno.h) <<<---NEW ... PROBLEM: (94228) (PATCH ID: OSF540-168) ******** This patch fixes a panic within the two level scheduling subsystem. One would see this panic while performing system management in the form of online'ing and offline'ing processors. A likely stack trace would be: 4 panic src/kernel/bsd/subr_prf.c : 1378 5 trap src/kernel/arch/alpha/trap.c : 2285 6 _XentMM src/kernel/arch/alpha/locore.s : 2219 7 pag_move_thread src/kernel/kern/processor.c : 1074 8 processor_doaction src/kernel/kern/machine.c : 1503 9 action_thread src/kernel/kern/machine.c : 1221 PROBLEM: (BCGM5159Z) (PATCH ID: OSF540-024) ******** This patch forces a domain panic instead of a system panic if AdvFS metadata is discovered to be incorrect in frag_group_dealloc. PROBLEM: (94231) (PATCH ID: OSF540-192) ******** When removing a volume from a domain, rmvol sometimes fails with E_BMT_NOT_EMPTY error. As a result a volume cannot be removed with no apparent reason. PROBLEM: (88114, 93775) (PATCH ID: OSF540-016) ******** The accounting for moving of buffers onto the device queue in AdvFS failed to include buffers being moved from the blocking queue. This would include metadata buffers and buffers for files opened for directIO. The result is that when monitoring IO via advfsstat, these buffers were not represented. In some cases, it appeared that IO was not happening. PROBLEM: (94478) (PATCH ID: OSF540-096) ******** Fix a rare case of a thread blocking when waiting for memory. you would get a panic THREAD_BLOCK: SIMPLE LOCK OWNED when using AIO. PROBLEM: (94964) (PATCH ID: OSF540-190) ******** This problem can produce two distinct stack traces. "idx_lookup_node_int: bs_refpg failed" 4 domain_panic 5 idx_lookup_node_int 6 idx_lookup_node_int 7 idx_lookup_filename 8 seq_search 9 msfs_lookup 10 namei 11 vn_open 12 copen 13 syscall 14 _Xsyscall "bs_frag_dealloc: rbf_pinpg (4) failed, return code = -1035" 7 domain_panic 8 bs_frag_dealloc 9 fs_delete_frag 10 copy_and_del_frag 11 fs_write_add_stg 12 fs_write 13 msfs_write 14 vn_write 15 rwuio 16 write 17 syscall 18 _Xsyscall PROBLEM: (117-1-20845, 93742, 88820) (PATCH ID: OSF540-117) ******** This patch fixes a problem in which fuser is unable to report on all referenced resources. This is a problem when attempting to identify reasons for unmount failures. This code enhancement improves the process exit procedure for processes that have had the "nice" command used on them 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: (94382, 94807, FR_G04495, FR_G05021) (PATCH ID: OSF540-027) ******** PROBLEM: (94382, 94807, FR_G04495, FR_G05021) (PATCH ID: ) This patch corrects a problem in AdvFS where it avoids a potential stranded log record in memory that doesn't get out to disk by fixing a race condition. PROBLEM: (91654, 93118) (PATCH ID: OSF540-066) ******** This patch will fix a rmvol E_PAGE_NOT_MAPPED error seen as follows: rmvol: Removing volume '/dev/disk/dsk4b' from domain 'test' rmvol: Can't move file /test/FILE89 pages rmvol: Error = E_PAGE_NOT_MAPPED (-1035) rmvol: Can't move file /test/FILE89 metadata rmvol: Can't remove volume '/dev/disk/dsk4b' from domain 'test' This patch will also eliminate an ENO_MORE_BLKS error seen when COWing a to a clone file while a rmvol is in progress. The following error will be seen: WARNING: AdvFS cannot copy-on-write data to a clone file. WARNING: encountered the following error: ENO_MORE_BLKS (-1040) WARNING: encountered the following error: ENO_MORE_BLKS (-1040) WARNING: do not continue using the clone fileset. PROBLEM: (94269) (PATCH ID: OSF540-214) ******** When free memory becomes tight, many processes wait for memory to become available. Normally, when a process waits for a long time, it's scheduling priority is boosted to give it better access to the processor. There was a "scheduling window" where a process at a certain priority (43) would not get that boost. The result was that there would be many processes, waiting at a higher priority, for memory that would get it before the process stuck at priority 43. When this process was the ics input thread, ICS would notice that it was stalled and panic the system. If you see this panic, look at the dump and look at the scheduling priority (sched_pri) of all threads waiting for anonymous memory. If all of these threads are at sched_pri 42 (or less) and the "ics_mct_input_thread_main" thread is at sched_pri 43, this patch will solve the problem. PROBLEM: (none) (PATCH ID: OSF540-244) ******** Added code to support CPU indictment on Marvel. PROBLEM: (95015) (PATCH ID: OSF540-229) ******** GS1280 supports option cards that require MSI capabilities. Added support in the platform code to handle MSI capable adapters. PROBLEM: (95193) (PATCH ID: OSF540-243) ******** Added support to get live status information for airmovers and powersupplies on marvel and to log intrution packets to the errlog. Disabled printing of machine check frames to the console. PROBLEM: (95168) (PATCH ID: OSF540-208) ******** In some cases, a process waiting on a semaphore is instructed to wake up (by another process) but the kernel does not deliver the wake up. The waiting process, therefore, waits "forever". If you think that you are experiencing this problem perform the following 3 step process: 1. create a file called "ipc_config" that contains the following: ipc: sem_broadcast_wakeup=1 2. As root, configure the system with the above using the sysconfigdb command: sysconfigdb -a -f ipc_config ipc 3. reboot the system If this solves your problem, apply this patch and remove the ipc configuration entry described above. Failure to remove this configuration parameter MAY in some cases cause a performance loss. PROBLEM: (95155, 95156) (PATCH ID: OSF540-203) ******** PROBLEM: Under some conditions, increasing the size of a live UFS file system via the mount command as documented in the mount(8) man pages, will make that file system unusable. The df command and other UFS tools will report the data size of the file system as (1) block. PROBLEM: Some LSM/UFS based systems may experience a panic() after a live UFS filesystem extension is complete. PROBLEM: (94590) (PATCH ID: OSF540-242) ******** This rmvol hang is seen after a cluster node failure. If a node crashes while in the middle of migration of the frag file, when rmvol is attempted again, it will hang looping trying to remigrate the frag file. The hang has only been seen on cluster_usr frag file migration. The looping rmvol will look similar to the following if rmvol is run with the -v flag: vanhal1:/ (ROOT) > rmvol -v /dev/vol/rootdg/cluster_usrvol cluster_usr rmvol: Removing volume '/dev/vol/rootdg/cluster_usrvol' from domain 'cluster_usr' rmvol: Moving file file name: (setTag: 1.32769 (0x1.0x8001), tag: 1.32769 (0x1.0x8001)) no pages moved rmvol: Moving file file name: (setTag: 1.32769 (0x1.0x8001), tag: 1.32769 (0x1.0x8001)) no pages moved rmvol: Moving file prime mcell file name: (setTag: 1.32769 (0x1.0x8001), tag: 1.32769 (0x1.0x8001)) rmvol: Moving file file name: (setTag: 1.32769 (0x1.0x8001), tag: 1.32769 (0x1.0x8001)) no pages moved ... ... This hang may also be seen running volmigrate or volunmigrate, since both of these utilities perform rmvol. PROBLEM: (95174) (PATCH ID: OSF540-216) ******** This patch corrects a locking problem with NFS running over UFS. A code path had been introduced which failed to take the proper locks. The missing lock was to protect specific fields within the on-disk inode. This problem could show as either a data corruption or a system panic. PROBLEM: (95470) (PATCH ID: OSF540-297) ******** If writes made to a file seem to vanish or a newly written file has some unexpected data in it, then this could be the cause. PROBLEM: (90064) (PATCH ID: OSF540-086) ******** This patch addresses two potential problems with the NFS version 3 client. The first is where a COMMIT RPC retransmission could complete the RPC before the actual commit was complete. The second is where colliding commits can result in a return before the unstable data is committed to storage. PROBLEM: (93039, BCGM603V0,) (PATCH ID: OSF540-121) ******** This fix prevents a sign promotion generated by the compiler while comparing 32 bit int variable with 64 bit unsigned long variable. This leads to an incorrect comparison which, in turns, leads to an unnecessary directory lookup warning message on the nfs client when the client receives a directory fileid with bit 31 sign bit on. On a lesser extend, it also causes a slight nfs client caching performance penalty. PROBLEM: (93539) (PATCH ID: OSF540-084) ******** This patch handles potential problems when reading files from an NFS server that reside on a third-party filesystem. The NFS server read mechanism was recently reworked to use the buffer cache to read the underlying filesystem data. These changes did not handle the case where the underlying filesystem did not implement the buffer cache callbacks and resulted in a kernel memory fault panic with a stack trace similar to the following: 6 _XentMM 7 rfs_read_common 8 rfs3_read 9 rfs_dispatch 10 nfs_rpc_recv 11 nfs_rpc_input 12 nfs_input 13 nfs_thread This patch detects, intercepts and handles requests to underlying filesystems that do not support the buffer cache callbacks. PROBLEM: (94612) (PATCH ID: OSF540-014) ******** This patch fixes a loss of single system image when a Cluster acts as an NFS client to some external NFS server. Certain error conditions may lead to some of the CFS client nodes being unable to access an NFS filesystem that is still mounted and accessible from other nodes in the cluster. The problem scenario involves a an unsuccessfull unmount attempt, an entry not found in the NFS attribute cache at the CFS server, and an error returned from the NFS server. PROBLEM: (94485) (PATCH ID: OSF540-082) ******** This patch fixes a memory leak in the NFS server when it receives malformed NFS packets. If there are a large number of bad NFS packets, then the system will eventually run out of free memory, resulting in messages like "vmunix: malloc_wait:1: no space in map" being displayed on the console. PROBLEM: (94638) (PATCH ID: OSF540-212) ******** This patch allows the system administrator to adjust the size of the NFS server duplicate request cache (DRC). The DRC is used by the NFS server to reply to retransmissions of non-repeatable operations (e.g., write, set file attributes). An undersized DRC for a given request load does not allow the NFS server to detect that a non-repeatable operation's RPC has been retransmitted, and hence the server performs the operation again. This can result in data loss or inconsistency. This patch allows the system administrator to adjust the size, as needed, to accomodate the anticipated load on the NFS server. PROBLEM: (92687, 93735) (PATCH ID: OSF540-218) ******** This patch contains two fixes. The first fix is for Tru64 nfs client panic when the client receives a null entry as a response to a readdirplus request from the Tru64 nfs server. The second fix is for a Tru64 nfs server panic caused by receiving illegal file access mode from the Tru64 nfs client. PROBLEM: (95049, TKT370920) (PATCH ID: OSF540-240) ******** This patch addresses three basic issues: 1) The TCP window has been increased from 96 KB to 500 KB for performance improvements. 2) This patch will have the netisr thread dynamically estimate the reply size and subsequently reserve the space in the socket buffer. 3) A new timeout check has been added to notice when the data hasn't been ACKnowledged in 30-50 seconds and copies those buffers. This will allow the UBC to free up those mbufs and not tie them up. PROBLEM: (95387) (PATCH ID: OSF540-278) ******** This patch fixes a flaw in the NFS server which could cause it to crash upon reception of malformed UDP input. PROBLEM: (95407, 95449) (PATCH ID: OSF540-294) ******** This patch addresses two potential crashes with the NFS server. The first can occur with concurrent read and truncate behavior on an AdvFS file and could result in a system crash with a kernel memory fault dereferencing a null pointer. The second can occur with malformed or malicious NFSv3 READDIR or READDIRPLUS RPCs, where the desired return buffer size is specified as zero. The size used could result in the dereferencing of a null or invalid pointer. PROBLEM: (TKT400347) (PATCH ID: OSF540-251) ******** This patch prevents an incorrect timestamp from being written to the time of year (TOY) clock on boot. PROBLEM: (95021, ZPOQCA010, 'cfs_stop_server_accept:) (PATCH ID: OSF540-290) ******** PROBLEM: (95021, ZPOQCA010, 'cfs_stop_server_accept:) (PATCH ID: ) This patch prevents a panic that may occur in a cluster when a fileset mounted -o dual is failed over or unmounted during shutdown. Typical stack trace: > 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1339 1 panic src/kernel/bsd/subr_prf.c : 1296 2 event_timeout src/kernel/arch/alpha/cpu.c : 2227 3 printf src/kernel/bsd/subr_prf.c : 981 4 panic src/kernel/bsd/subr_prf.c : 1353 5 cfs_stop_server_accept src/kernel/tnc_common/tnc_cfe/cfs_reloc.c : 1272 6 cms_handle_send_msg src/kernel/tnc_common/tnc_cfe/cms_kgs.c : 3728 7 cms_kgs_callback_thread src/kernel/tnc_common/tnc_cfe/cms_kgs.c : 3303 The panic string is: "cfs_stop_server_accept: error setting domain relocating flag" PROBLEM: (94581) (PATCH ID: OSF540-383) ******** When your system is configured to use ntp, whether the ntp daemon is running or not the time will be kept accurately. PROBLEM: (95481) (PATCH ID: OSF540-418) ******** If a system uncorrectable error occurs that is caused by a double bit memory error the system will crash. The problem is seen as a recursive panic situation. As the system goes down it saves it state in a crash dump but to do that it reads the memory location with the error, causing another hard error to occur. This problem is only on a ES47 platfrom. PROBLEM: (LACCOL004) (PATCH ID: OSF540-386) ******** This patch corrects the problem of a possible panic in audit_rec_build when auditing execve with the exec_argp or exec_envp audit style enabled. PROBLEM: (95053) (PATCH ID: OSF540-313) ******** The maximum size of a property list name for files was inadvertently set to 245. This maximum name size has been increased to 255. PROBLEM: (94955) (PATCH ID: OSF540-263) ******** When setting gh_min_seg_size to a value of 4M, a message is printed at boot time stating: vm_configure: gh_min_seg_size too small or not aligned on 8meg boundary PROBLEM: (94724) (PATCH ID: OSF540-318) ******** This patch will improve the performance of AdvFS under heavy I/O loads. This improvement was accomplished by rewriting a code path that was taking out a lock even if it was not needed. By only taking out the lock when it was needed, lock misses and lock contention is reduced. This reduces a large amount of wait time under heavy I/O loads. PROBLEM: (95472) (PATCH ID: OSF540-416) ******** CPUs that do not take interrupts (either directly from the attached IO7 or indirectly from IO7s attached to offlined CPU) will now always be allowed to be offlined. PROBLEM: (BCGMC00N0, BCGMC00MX) (PATCH ID: OSF540-412) ******** This patch is required for Sierra systems to prevent issues in the DCE/DFS file system when pages are being flushed as part of a vnode. PROBLEM: (94877) (PATCH ID: OSF540-345) ******** This patch allows AdvFS to record if a domain panic has occurred, even if a system panic results. Without this patch, the system logs would need to be searched to gather this information. PROBLEM: (AT_G04801) (PATCH ID: OSF540-255) ******** This correction adds the following improvements to AdvFS: - checks for property list namelength to protect against having the kernel be confused by corrupted values (which could lead to various crashes) - properly accesses reserved files, avoiding considering the possibility of property lists for them (which avoids an aliasing problem that could lead to file corruption OR kernel memory faults) PROBLEM: (94741) (PATCH ID: OSF540-371) ******** The AdvFS migration code, on a clustered system, needs to ensure that pages are flushed before they are invalidated following the migration. This fix ensures that this is done. PROBLEM: (DSATP26SZ, HPAQC000P) (PATCH ID: OSF540-393) ******** This patch fixes a problem where two threads can hang in a deadlock. One thread hangs during the rename of an AdvFS file, while another thread hangs during a defragment (or rmvol, or balance, or migrate) in the same AdvFS domain. The stack traces of the deadlocked threads are similar to the following. Thread A: > 0 thread_block 1 lock_wait 2 lock_read 3 msfs_rename 4 cfs_comm_rename 5 cfs_rename 6 rename 7 syscall 8 _Xsyscall Thread B: 0 thread_block 1 lock_wait 2 lock_write 3 migrate_normal 4 migrate_normal_one_disk 5 mig_migrate 6 bs_migrate 7 msfs_syscall_op_migrate 8 msfs_real_syscall 9 msfs_syscall 10 syscall PROBLEM: (95474) (PATCH ID: OSF540-397) ******** This patch fixes a system panic in the ubc_page_stealer routine. The panic is caused by a lock timeout on the ubc_clru_lock. PROBLEM: (95079) (PATCH ID: OSF540-272) ******** On a cluster, the following sequence of commands results in a system panic: # mfs -s 500 /mnt/mfs # cd /mnt/mfs # kill -9 "MFSPID"; sleep 1; cd; umount /mnt/mfs (The kill and the umount must be occur within 5 seconds of each other.) The panic stack may look like: (dbx) t 0 stop_secondary_cpu() 1 panic() 2 event_timeout() 3 printf() 4 panic() 5 lock_fault() 6 lock_write() 7 dounmount() 8 mfs_mount_block() 9 cluster_mount() 10 mount1() 11 syscall() 12 _Xsyscall() PROBLEM: (94858) (PATCH ID: OSF540-265) ******** This patch fixes a problem with cluster failover of UFS filesets. PROBLEM: (95073) (PATCH ID: OSF540-404) ******** The violation of the O_DSYNC semantics occurs when 1. User creates a new file. 2. Writes to it asynchronously, which allocates storage. 3. Closes file. 4. Vnode for file is recycled. 5. Reopens file with O_DSYNC flag. 6. Writes to file, overwriting already allocated storage 7. Write from step 5 returns to application. 8. System crashes. PROBLEM: (95277) (PATCH ID: OSF540-346) ******** If an error is found while trying to reset the AdvFS on disk state, a panic would occur. Since this error is really a problem with one domain and not a system problem, AdvFS now panics the domain instead of crashing the system. PROBLEM: (89799) (PATCH ID: OSF540-433) ******** This patch is for a minor change to the fwupgrade command to allow the specified firmware update image to be located on a BOOTP server in a connected network. PROBLEM: (94136, SSRT2275) (PATCH ID: OSF540-358) ******** This patch provides protection against a class of potential security vulnerabilities called buffer overflows. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. This patch allows a system administrator to enable memory management protections that limit potential buffer overflow vulnerabilities. PROBLEM: (91222) (PATCH ID: OSF540-400) ******** No actual code modification is required. 0x10000000 and 0x20000000 need to be reserved for AUTOFS flags. These two are for di_flags bits in dinode.h and st_flags bits in fs_dir.h PROBLEM: (95130) (PATCH ID: OSF540-342) ******** This patch corrects a function call made while running on a cluster. The old code tried to call a routine XXX() to verify that the system is configured in a cluster, but the code called XXX. This caused the call to XXX to always succeed. Specifying the call correctly as XXX() allows AdvFS to verify that the system is configured in a cluster. PROBLEM: (95506) (PATCH ID: OSF540-385) ******** This patch fixes a deadlocking problem in the kernel where a file open on a clone could hang when ACLs are enabled. This problem is recognizable by a number of processes in the "U" state. PROBLEM: (95169, 95152) (PATCH ID: OSF540-351) ******** This patch helps improve scalability by o turning off the collection of some internal statistics o prefetching some data, by using locals to collect changes in two globals so that the globals only need to be modified once o rearranging the order of some instructions to get a better chance of being ready for our use when needed. PROBLEM: (93839) (PATCH ID: OSF540-270) ******** Internal testing uncovered a potential problem when a recent domain had paniced, and soon afterward the domain was rebooted. PROBLEM: (93289, 93291) (PATCH ID: OSF540-283) ******** This patch address the problem of two very small memory leaks when a CPU attribute changes or when a power state changes. The memory leak is several bytes and it is expected that these events occur infrequently. PROBLEM: (94158) (PATCH ID: OSF540-399) ******** The existing freezefs displays an incorrect error message of "XXX is frozen" when "freezefs -q" is executed on a non-AdvFS filesystem XXX. This patch corrects this behavior by displaying "freezefs XXX: Function not implemented" instead. PROBLEM: (95223, 95254, 96063) (PATCH ID: OSF540-354) ******** PROBLEM: This problem can occur when any process is writing a large, sequential, file to disk. There are two system tunables (vm_ubcseqpercent and vm_ubcseqstartpercent) that are supposed to restrict sequentially accessed files from consuming too much of the UBC. These tunables were not being strictly enforced and could be ignored if a large amount of data was written very quickly, thus allowing a file to use more of the UBC than the user had specified. PROBLEM: This problem causes the system to be unresponsive when in low memory situations. If there is a lot of I/O being created on a system, and it is low on memory, it can become unresponsive to user commands. Attempts to execute a command will appear to hang but will execute eventually given enough time. PROBLEM: (BCSMM2J85, 94958) (PATCH ID: OSF540-250) ******** Fix a standards violation, as it causes ENOSPC for writes that previously returned EOK to their callers (standards require that writes that will fail due to ENOSPC should return such indication immediately to the caller). PROBLEM: (95230) (PATCH ID: OSF540-300) ******** System panics with "ialloc: dup alloc". Possible stack trace: > 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":1339, 0xff 1 panic() ["../../../../src/kernel/bsd/subr_prf.c":1296, 0xfffffc00002a1b04] 2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":2227, 0xfffffc0 3 printf() ["../../../../src/kernel/bsd/subr_prf.c":981, 0xfffffc00002a0e08] 4 panic() ["../../../../src/kernel/bsd/subr_prf.c":1353, 0xfffffc00002a1c74] 5 ialloc() ["../../../../src/kernel/ufs/ufs_alloc.c":623, 0xfffffc00005b1fa8 6 maknode() ["../../../../src/kernel/ufs/ufs_vnops.c":5153, 0xfffffc00005c96 7 ufs_create() ["../../../../src/kernel/ufs/ufs_vnops.c":1903, 0xfffffc00005 8 vn_open() ["../../../../src/kernel/vfs/vfs_vnops.c":765, 0xfffffc00005ff3a 9 copen() ["../../../../src/kernel/vfs/vfs_syscalls.c":3582, 0xfffffc00005eb 10 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":732, 0xfffff 11 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1814, 0xfffffc00 PROBLEM: (95595) (PATCH ID: OSF540-378) ******** I/O errors could result in a "blkfree: freeing free block" panic. Possible stack trace: > 0 stop_secondary_cpu() 1 panic() 2 event_timeout() 3 printf() 4 panic() 5 blkfree() 6 itrunc() 7 ufs_inactive() 8 vrele() 9 ufs_remove() 10 unlink() 11 syscall() 12 _Xsyscall() PROBLEM: (95134) (PATCH ID: OSF540-343) ******** This patch improves the scalabilty and performance of AdvFS. The patch accomplishes this by being smarter about when it needs a particular AdvFS lock and when it does not. PROBLEM: (HPAQP2FLS) (PATCH ID: OSF540-423) ******** This patch fixes a problem where an I/O error (EIO) can occassionally be returned after a page fault. No errors appear in the binary.errlog file. When this occurs using Oracle 10i, the following error messages may appear on your screen: ORA-19755, ORA-19750, and ORA-27047, as well as the message "Tru64 UNIX Error: 5: I/O error". PROBLEM: (94050) (PATCH ID: OSF540-312) ******** Under a heavy system load, when vfast is working hard, it is possible that the "vfast stop" command, issued by the system during a system shutdown or reboot can hang. This resulted in administrators having to reset the system manually. No other consequences of this rare problem have been detected. PROBLEM: (95529) (PATCH ID: OSF540-360) ******** PROBLEM: a kernel memory fault panic occurs in the audcntl routine (kern_auditcalls.c) the first time the audit daemon attempts flush its kernel buffers to the audit log at user selected frequency (auditd -d freq). This problem may also occur when the audcntl syscall GET_DATALEN function is used from a privileged user id. PROBLEM: (95463) (PATCH ID: OSF540-330) ******** This patch adds defensive programming to stat.h to avoid stat.h getting confused if one of its internal temporary #defines is defined before stat.h is processed. PROBLEM: (95393) (PATCH ID: OSF540-289) ******** This patch fixes a memory management fault in UFS. The fault resulted from attempting to perform I/O to a file after reclaiming its inode. The identifying part of the stack trace is: > 0 boot() 1 panic() 2 trap() 3 _XentMM() 4 ufs_writepages() 5 ufs_putpage() 6 ubc_invalidate() 7 ubc_object_free() 8 vclean_ops() 9 vclean() 10 vgone() PROBLEM: (DE_G05472) (PATCH ID: OSF540-387) ******** This patch fixes a problem where a device file, such as /dev/console, can become inaccessible, returning the error 'Bad File Number'. PROBLEM: (SSRT2275) (PATCH ID: OSF540-296) ******** This patch provides protection against a class of potential security vulnerabilities called buffer overflows. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. This patch allows a system administrator to enable memory management protections that limit potential buffer overflow vulnerabilities. PROBLEM: (88548) (PATCH ID: OSF540-034) ******** 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. HP has corrected this potential vulnerability. PROBLEM: (94686) (PATCH ID: OSF540-133) ******** This patch allows the auditing of login and su events based in part on what's in user profiles (for Enhanced Security), the prevailing auditing characteristics of the originating process, and the system-wide audit mask. Previously, only the system audit mask was referenced. HP has corrected this deficiency. For example, assume the following scenario. The system audit mask has login failures reported, but not login successes. The target user profile is set to add in the auditing of successful logins. Under these circumstances, only the login failures would previously have been found in the audit log. PROBLEM: (93908) (PATCH ID: OSF540-090) ******** This patch corrects a failure in the safe_open() routine which caused symbolic links given by a relative path from the current working directory sometimes to give ENOENT errors incorrectly. This was specific to having no 'real' (non-".") leading components before the first symlink was found. PROBLEM: (95110) (PATCH ID: OSF540-196) ******** This patch fixes a potential floating point error in threaded applications. Without this solution, it is possible for a process to get different floating point values after a context switch. PROBLEM: (DE_G04979) (PATCH ID: OSF540-003) ******** In a non-C locale, extended regular expressions of the form "[a-z]{m,n}" and ".{m,n}" may be handled incorrectly, as if the interval expression is {m,n+1}. This patch fixes the problem. PROBLEM: (94494) (PATCH ID: OSF540-059) ******** When the Internet Express DLAP Authentication Module is configured onto the system and an LDAP group is created and a user assigned to that group, depending on the placement of LDAP in the /etc/sia/matrix.conf file, the user wouldn't be assigned to that group at login time. A "groups" or "id" would not have the user authorized for that group. PROBLEM: (87802, 84422, 87576, 87802, 90472, 92015, 93597) (PATCH ID: OSF540-135) ******** This patch addresses one problem. When the system discovers a new device,it generates a new name for it to create the device special file (dsf). The instance part, a number, can get quite large when doing many disk backups using a clone-copy-delete procedure. Since the instance is always increasing, the names quickly become hard to manage. Also, the backup program must determine the new numbers each time it runs. To fix this problem, the dsfmgr program has added a new option that will minimize (or set) the instance numbers to the lowest possible value. If your system deletes and creates a large number of devices or deletes and creates devices often, this patch will help keep the values lower. For systems that have a fixed configuration except for the backup procedure, it will mean that each new set of cloned backup devices will always have the same new names. It can simplify the backup procedure. - an illegal input argument causes a core dump This usually occurs when no arguments are entered. - improper error handling by the stat function during boot dsfmgr fails with: dsfmgr: NOTE: creating device special files for system at / dsfmgr: ERROR: stat( "/dev/disk/dsk19a" ) = kernel database - duplicate device ID's +dsk19a /sbin/dn_setup: 1573120 Memory fault - core dumped - the move/exchange may cause data errors This occurs when it encountered a partial set of device nodes. - during boot the following message is seen: ============================= Problem occurred again while booting all nodes of the cluster. The problem occurred on two nodes: tcr6b: Checking device naming: ERROR : DEC_CHW_COMP : /etc/dec_hwc_cdb: invalid database size. Is 412648, sb 412408. ERROR : DEC_CHW_COMP : /etc/dec_hwc_cdb.bak: invalid backup size. Is 412648, sb 412408. bcheckrc: Device Naming failed initial check. Correct errors and then continue or reboot. ============================= This can be caused by a file update during the dsfmgr read of the file. Nothing is wrong and a ^D (ctrl D) will continue the boot again. This fix will detect this senerio and the system will boot without any operator intervention. PROBLEM: (94735, PROBLEM, 86294, reading) (PATCH ID: OSF540-113) ******** This patch fixes the performance problem with cp with respect to the Change in the I/O buffer size from 64K to 8K that went to the support pools. This patch also fixes a problem in which cp(1) and cat(1) produce different file sizes when reading from a tape device The soultion was to change the I/O buffer size of cp to 64K and change the I/O buffer size of cat to 64K. PROBLEM: (92820) (PATCH ID: OSF540-031) ******** 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. HP has corrected this potential vulnerability. PROBLEM: (117-1-19737) (PATCH ID: OSF540-040) ******** This fix corrects a problem in which sh was using a high amount of CPU time. PROBLEM: (93526) (PATCH ID: OSF540-166) ******** This patch fixes the problem while encoding "$@" in bourne shell. PROBLEM: (94413) (PATCH ID: OSF540-224) ******** Update the SSH Tru64 UNIX V1.1 (2.4.1) to SSH 3.2. This is required for supporting IPV6, interoperablity with other ssh implementations, and fix interoperability issues of the ssh client/server configuration files. PROBLEM: (88559, 94472, 94255, Patch, SSRT2301, Patch, SSRT2275) (PATCH ID: OSF540-030) ******** Patch 1) and 2) 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. HP has corrected this potential vulnerability. Patch 3) A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised when a buffer overflow occurs in the uucp utility. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. HP has corrected this potential vulnerability. PROBLEM: (SSRT2275) (PATCH ID: OSF540-356) ******** This patch provides protection against a class of potential security vulnerabilities called buffer overflows. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. This patch allows a system administrator to enable memory management protections that limit potential buffer overflow vulnerabilities. PROBLEM: (91618) (PATCH ID: OSF540-322) ******** When enhanced core file naming is on, an incorrect msg is printed when core umps. The message file has been modifed accordingly to correct this problem. PROBLEM: (STL526315) (PATCH ID: OSF540-326) ******** The runtime loader reports that it was trying to free a null pointer and displays the following message: "/sbin/loader: Attempt to free null pointer". This patch fixes this problem. PROBLEM: (95264) (PATCH ID: OSF540-245) ******** Ill-formed TCP connections can cause RPC-based services to hang in accept(2), waiting for the connection to be completed. The ill-formed TCP connections typically come as a result of portscanning activity on a network. PROBLEM: (91547) (PATCH ID: OSF540-317) ******** When two concurrent process tries to move a file, only one process will be able to "unlink" the original file. In case, if both the process completes simultaneously, only one of the process can unlink the file after moving it to the specified destination. Since, the errno is not checked while unlinking the file, both the process return from "mv" command without any error. This fix takes care of this situation. PROBLEM: (95085, SSRT2384) (PATCH ID: OSF540-264) ******** A potential security vulnerability has been discovered in the HP Tru64 UNIX operating system that may result in a Denial of Service (DoS). This potential vulnerability may be in the form of local and remote security domain risks. The following potential security vulnerability has been corrected: SSRT2384 rpc (Severity - High) PROBLEM: (94889) (PATCH ID: OSF540-246) ******** This patch allows mount(8) options that require values to be correctly processed on a cluster. Previously, all option values would be essentially ignored, accompanied by a warning message such as: "WARNING: bad value for wsize option". The new behaviour is to correctly parse the specified option, as on a single system. PROBLEM: (95001) (PATCH ID: OSF540-303) ******** Memory leaks are avoided in bourne shell. PROBLEM: (93321, 87630, 93320, 86058) (PATCH ID: OSF540-406) ******** This patch fixes following problems in sh. o Service denial problem when a quoted here doc script is executed. o Problem with handling ELF files. o The shell variable $- not holding -C set option when it is turned on. o Printing broken characters when type builtin utility of sh is invoked in Japanese locale. PROBLEM: (95126) (PATCH ID: OSF540-256) ******** This patch prevents segmentation faults when sia_ses_init is passed a malformed argument vector. This problem was discovered when dxchpwd was passed several -x arguments. The Motif libraries modified the argument vector during intialization. This modified vector eventually caused a segmentation fault in SIA initialization. PROBLEM: (BCGMS0LJC) (PATCH ID: OSF540-369) ******** This change fixes client (login, su, rshd, edauth, and sshd2) hangs and long delays under Enhanced Security, as well as some intermittent errors or failures seen with prpasswdd or rpc.yppasswdd. Of particular note are the following externally-visible changes. In a TruCluster environment, the prpasswdd and rpc.yppasswdd daemons now watch to see whether the CFS service for the /var filesystem is moved. If so, the active instance of the daemon will also migrate to the appropriate cluster member. The prpasswdd and rpc.yppasswdd daemons now monitor whether their start-up portmapper registrations disappear or otherwise become unavailable to their clients. If this happens, they attempt to re-register with the portmapper. This is done by having the child ('worker') process exit, and the parent ('monitor') process re-start it. Some syslog messages for the LOG_AUTH facility have been clarified, and some additional ones have been added for monitoring whether the rpc.yppasswdd or prpasswdd daemon is unresponsive. [The clients will log intermittent messages at level LOG_NOTICE, approximately at 50-second intervals, if they can't get responses from the daemons.] The rpc.yppasswdd and prpasswdd daemons now make a syslog entry to the LOG_AUTH facility at level LOG_NOTICE when they become active and start trying to service client requests. This is most useful in a cluster, since it helps to identify the 'active instance' of the relevant daemon. The prpasswdd daemon no longer leaves core files in / (the root directory). If it leaves a core dump at all (which now normally should only happen in response to a SIGQUIT signal), it will be found in the /var/tcb/files directory. It is still true that any attempt to manage the rpc.yppasswdd and prpasswdd daemons with signals should only be done with the child ('worker') processes, and not with the parent ('monitor') processes. The child processes are the ones which write their pids in the (member-specific) /var/run/rpc.yppasswdd.pid and /var/run/prpasswdd.pid files. Delivery of SIGINT or SIGTERM to one of the child processes causes a graceful exit, also terminating the parent process. Delivery of SIGUSR2 causes a graceful re-start of the child process. A SIGQUIT causes a re-start after a core dump. Finally, a SIGHUP causes the child to terminate, and the parent to re-exec itself with the same argument vector, which will then cause a re-start of the child process. This last case is to minimize the down-time for the daemons should future patches to them or to the libsecurity.so library be necessary. PROBLEM: (66873, 80677, 80944, 89274, 89286, 91627, 93013, 94285) (PATCH ID: OSF540-320) ******** The getdate() function uses mktime() to normalize the tm struct being generated for it's input data. However, getdate() was not properly checking both the return value and errno for a potential out-of-range indication from it's mktime() call. This patch fixes this problem. The strptime() routine matches input incorrectly to the format string. According to the Single UNIX Spec for strptime(), "Any other conversion specification is executed by scanning characters until a character matching the next directive is scanned, or until no more characters can be scanned." Instead, the strptime() routine makes assumptions of how many characters to scan based on the number of digits in the maximum value for that particular conversion specification. This algorithm does not give consistent results and does not follow the Single UNIX Spec. This patch modifies the parsing algorithm to provide full compliance. The strptime() routine matches white space incorrectly to %n and %t. It matches white space up to the first tab character for %t and matches white space up to the first newline character for %n. The Single UNIX Spec for strptime defines both %n and %t as "is any white space". This patch fixes strptime() so it matches any white space to both %n and %t. The callrpc() routine tracks information related to an rpc call, including the socket used for communication and a valid field. If the valid flag is false, the code closes the socket. In some instances, this results in closing sockets not owned by the process. This patch modifies callrpc() to track whether or not the process has opened the socket. The socket is closed only if this field indicates that the socket is owned by the process. The fork() routine calls the internal routine, __common_fork(). Compiler optimizations in V5.1B added tailcall optimizations for __common_fork() which cause certain failures in the Visual Threads instrumentation tool (vti). This patch fixes this problem by removing the tailcalls for __common_fork(). The strncasecmp() and strcasecmp() routines did not check the input parameters for NULL. Attempts to access the data through the NULL parameters resulted in seg faults. This patch fixes this problem by handling NULL parameters as special cases. The header /usr/include/sgtty.h did not specify explicit return types for the gtty() and stty() function declarations. This omission results in inappropriate warnings from the compiler when this header is included. This patch fixes the problem by adding explicit 'int' return types to these declarations. The nacreate() routine in the libnuma library calls nmmap() and is supposed to return NULL if the call failed. The failure check was incorrectly coded and could result in a seg fault instead of the correct NULL return from nacreate(). This patch fixes the failure check from the nmmap() call in nacreate(), thus avoiding the potential seg fault. PROBLEM: (95197) (PATCH ID: OSF540-267) ******** This security related patch fixes a problem where the Home Directory and login shell attributes for a user account were not suppled to the audit daemon for authentication failures. HP has resolved this problem. PROBLEM: (57545, 77428, 81750, 81751, 83165, 84829, 89529, 90030, 90424, 91329, 92149, 92758, 93693, 93909, 95259) (PATCH ID: OSF540-332) ******** This patch corrects problems in the dbx and object file tools: dbx, ostrip, strip, mcs, dis, cord, file, and stdump. dbx - When reading an incomplete core file, dbx erroneously reports a "cannot attach to loader" error. With this patch, dbx now issues a warning when it detects an incomplete core file. - For some applications that use Fortran runtime libraries, dbx will core dump during initialization. (This problem was first seen with an application using Fortran V5.5-1877-48BBF runtime libraries, but it occurs infrequently.) This problem has been fixed. - After a debugged application has forked, dbx loses track of the breakpoints set by the user. These breakpoints can neither be listed nor deleted, but remain in effect. The patch corrects this problem by modifying dbx to restore the appropriate breakpoints when a process switch occurs. ostrip - ostrip -m reported a fatal error such as "aux_indice mapping nil...". This problem has been corrected. - A failure while processing an object prevented ostrip from processing additional objects on the link line. This problem has been fixed. - ostrip does not process all of the options on the command line. For example, "ostrip -cjtxz ..." processes only the -j option and ignores the remaining options. With this patch, these options are now processed in the following order: -j, -c, -x, -t, and -z. - ostrip terminates with the fatal error "File offsets overlap" for executables that have been instrumented by Atom-based tools such as pixie, third, or hiprof. This has been corrected. strip - For executables that have been instrumented by Atom-based tools such as pixie, third, or hiprof, strip terminates with the fatal error "File offsets overlap." This has been corrected. mcs - For executables that have been instrumented by Atom-based tools such as pixie, third, or hiprof, mcs terminates with the fatal error "File offsets overlap." This has been corrected. dis - The disassembly output source file name was incorrect for source lines occuring in header files. This has been corrected. - The disassembly output source file previously showed incorrect procedure names for object files with source lines occuring in header files. This has been corrected. - The "clrfen" pal call was disassembled as "0xae". With this patch, the disassembler will now display it as "clrfen". - Some nop (no-operation) instructions were incorrectly disassembled as "esr26" or "esr28" pseudo-ops. With this patch, the disassembler will display these nops as "lda" and "ldah" instructions. cord - Previously, the cord tool did not warn the user about unsupported object types such as OMAGIC and NMAGIC files. Users are now warned not to use cord on these unsupported object file types. - cord did not update file-descriptor addresses in the symbol table. This has problem has been fixed. - cord does not preserve segment padding for objects built with the linker's -disk_block option. This problem has been fixed. file - A memory leak caused the file command to fail and report "no aouthdr" error messages when ~300 or more objects were processed in one command. This problem has been fixed. stdump - A small memory leak caused stdump to occassionaly fail and report an "I/O error" message. If the heap size was limited to less than 100 mB, this error occurred when 1000 or more objects were processed in one command. This problem has been fixed. PROBLEM: (95674) (PATCH ID: OSF540-442) ******** Some networking applications, especially X.25 and X.29, stopped working as expected with version V5.1B because of interactions with security-related fixes in V5.1B and how fstat(2) behaves on their sockets. HP has fixed this deficiency. In particular, x29logind would fail to answer incoming calls. The daemon.log syslog files would show lines with the following message from x29logind: Cannot read packet sizes from port: Socket operation on non-socket PROBLEM: (BCSMB00Z8/221-1-457, 95332) (PATCH ID: OSF540-319) ******** The code for mktime() (and related time routines) in libc was updated in V5.0 to support more robust time transition rules and new time zones around the world. This update introduced a regression from the pre-V5.0 mktime() behavior in the handling of potentially ambiguous tm structs (ie: those that fall within a backward clock shift & which have an initially negative tm_isdst value). The pre-V5.0 mktime() would favor the later end of such transitions. The V5.0 (and later) mktime() varied as to which end of the transition it would favor, due to a lack of intentional constraints for such cases. This patch adjusts the algorithm to favor the later end of such transitions and restores mktime() behavior consistent with pre-V5.0 systems. PROBLEM: (95711) (PATCH ID: OSF540-451) ******** This patch fixes an internal problem in the kernel's advfs, ufs and nfs filesystems where extended attributes with extremely long names, greater than 247 characters, could not be set on files. The new limit is 254 + a Null string terminator. PROBLEM: (95765) (PATCH ID: OSF540-454) ******** PROBLEM: The console device boot string is being incorrectly calculated for devices on subbordinate buses in PCI-based systems. When using consvar to set a console boot environment variable to a device on a subbordinate bus, the hose and bus numbers are incorrectly calculated and consvar fails. PROBLEM: When using consvar to display a console boot environment variable, one garbage character may appear at the end. PROBLEM: (95682, 95733, SSRT2439, SSRT2341) (PATCH ID: OSF540-450) ******** In certain conditions a too-small buffer could be allocated. Similarly, under certain circumstances, pointers to a buffer within the RPC subsystem could be set beyond the buffer's bounds. This patch fixes these problems. PROBLEM: (95630) (PATCH ID: OSF540-455) ******** This patch fixes sh problem while executing a here document through command substitution. PROBLEM: (95697) (PATCH ID: OSF540-453) ******** Prevent TB_SHOOT ACK timeout on EV7 based platforms when the user tried to set known console environment variable from secondary cpu's that get stored onto the NVRAM. PROBLEM: (95821) (PATCH ID: OSF540-479) ******** This patch addresses a system panic with the following string: "pg_nwriters going negative". A typical stack trace is listed below. 0 boot src/kernel/arch/alpha/machdep.c : 2710 1 panic src/kernel/bsd/subr_prf.c : 1432 2 ubc_page_release src/kernel/vfs/vfs_ubc.c : 8103 3 ubc_rem_excess_pages src/kernel/vfs/vfs_ubc.c : 6064 4 ubc_page_alloc src/kernel/vfs/vfs_ubc.c : 5688 5 ubc_lookup src/kernel/vfs/vfs_ubc.c : 4881 6 bs_pinpg_one_int src/kernel/msfs/bs/bs_buffer2.c : 4448 7 bs_pinpg_clone src/kernel/msfs/bs/bs_buffer2.c : 4186 8 bs_pinpg src/kernel/msfs/bs/bs_buffer2.c : 3913 9 fs_write src/kernel/msfs/fs/fs_read_write.c : 2399 10 msfs_write src/kernel/msfs/osf/msfs_vnops.c : 3647 11 vn_write src/kernel/vfs/vfs_vnops.c : 1470 12 rwuio src/kernel/bsd/sys_generic.c : 2274 13 write src/kernel/bsd/sys_generic.c : 2196 14 syscall src/kernel/arch/alpha/syscall_trap.c : 725 15 _Xsyscall src/kernel/arch/alpha/locore.s : 1864 PROBLEM: (95813) (PATCH ID: OSF540-478) ******** This patch fixes a system panic. The problem is most likely to happen when system is under heavy load and low on memory. There are two possible panic strings. panic string: "mcs_lock: lock already owned by cpu" stack trace: 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1398 1 panic src/kernel/bsd/subr_prf.c : 1325 2 event_timeout src/kernel/arch/alpha/cpu.c : 2348 3 printf src/kernel/bsd/subr_prf.c : 1008 4 panic src/kernel/bsd/subr_prf.c : 1382 5 simple_lock_fault src/kernel/kern/lock.c : 2874 6 mcs_lock_state_violation src/kernel/kern/lock.c : 3170 7 vm_ops_reference_def src/kernel/vm/vm_object.c : 495 8 stack_alloc src/kernel/vm/vm_kmap.c : 988 9 thread_create_internal src/kernel/kern/thread.c : 1628 10 procdup src/kernel/vm/vm_unix.c : 893 11 newproc src/kernel/bsd/kern_fork.c : 1094 12 fork1 src/kernel/bsd/kern_fork.c : 902 13 fork src/kernel/bsd/kern_fork.c : 690 14 syscall src/kernel/arch/alpha/syscall_trap.c : 725 15 _Xsyscall src/kernel/arch/alpha/locore.s : 1864 panic string: "thread_block: simple lock owned" stack_trace: 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1398 1 panic src/kernel/bsd/subr_prf.c : 1325 2 event_timeout src/kernel/arch/alpha/cpu.c : 2348 3 printf src/kernel/bsd/subr_prf.c : 1008 4 panic src/kernel/bsd/subr_prf.c : 1382 5 thread_block src/kernel/kern/sched_prim.c : 3096 6 thread_preempt src/kernel/kern/sched_prim.c : 5162 7 ubc_page_stealer src/kernel/vfs/vfs_ubc.c : 3794 8 vm_bigpg_alloc src/kernel/vm/vm_resident.c : 3096 9 vm_page_alloc src/kernel/vm/vm_resident.c : 2890 10 stack_alloc src/kernel/vm/vm_kmap.c : 1030 11 thread_create_internal src/kernel/kern/thread.c : 1628 12 procdup src/kernel/vm/vm_unix.c : 893 13 newproc src/kernel/bsd/kern_fork.c : 1094 14 fork1 src/kernel/bsd/kern_fork.c : 902 15 fork src/kernel/bsd/kern_fork.c : 690 16 syscall src/kernel/arch/alpha/syscall_trap.c : 725 17 _Xsyscall src/kernel/arch/alpha/locore.s : 1864 PROBLEM: (95633) (PATCH ID: OSF540-449) ******** This patch fixes a problem on a cluster NFS client where a hard mounted NFS filesystem can incur ETIMEDOUT errors. This situation can occur when a cluster is accessing a filesystem on a server that the cluster thinks is down (either when the server is truly down or temporarily appears down because it is busy). PROBLEM: (95952, 84758, 86349) (PATCH ID: OSF540-554) ******** This patch corrects problems in UFS extendfs functionality which could cause filesystem metadata inconsistency. Prior to this patch, not all new inode blocks were properly zero'ed. Stale data in such inode blocks would appear as filesystem metadata inconsistency and could result in a system panic. This patch also corrects problems of using excessive memory for UFS cylinder summary data, and writing superblocks synchronously when asynchronous operations are sufficient. PROBLEM: (95352) (PATCH ID: OSF540-556) ******** A kernel memory fault can occur which using the table syscall to retrieve the TBL_ARGUMENTS information. The panic is usually triggered by using the "ps" command. The stack trace: 0 boot src/kernel/arch/alpha/machdep.c : 2706 1 panic src/kernel/bsd/subr_prf.c : 1426 2 trap src/kernel/arch/alpha/trap.c : 2285 3 _XentMM src/kernel/arch/alpha/locore.s : 2219 4 _OtsZero src/kernel/arch/alpha/ots_zero_alpha.s : 404 5 table src/kernel/bsd/cmu_syscalls.c : 1800 6 syscall src/kernel/arch/alpha/syscall_trap.c : 725 7 _Xsyscall src/kernel/arch/alpha/locore.s : 1864 PROBLEM: (95959) (PATCH ID: OSF540-562) ******** This patch addresses an issue on large systems where kernel threads might not be executed for extended periods of time. On a GS160 or GS1280, 2 high priority threads assigned to the same processor might not be able to benefit from available processing resources. PROBLEM: (GB_G06823, DE_G06812, 96050) (PATCH ID: OSF540-571) ******** This patch resolves a problem that results in multiple cluster members crashing with Kernel Memory Fault in rfs_find_fsid(). A typical stack trace is: 0 boot 1 panic 2 trap 3 _XentMM 4 rfs_find_fsid 5 rfs_find_clua 6 clua_round_robin 7 clua_register_remote_service_small_rpc 8 svr_clua_register_remote_service_small_rpc 9 icssvr_daemon_per_node PROBLEM: (95907, 95719) (PATCH ID: OSF540-548) ******** Reduced the hwmgr sensor probing delay on EV7 based machines, by reducing the number of calls to the console. PROBLEM: (93841) (PATCH ID: OSF540-476) ******** "quot -v" may report that some users have less file blocks that have not been accessed for 30, 60, and 90 days. This can be seen by customers who runs "quot -v" on a UFS.