PROBLEM: (QAR 33924) (Patch ID: OSF375-360037) ******** This patch fixes a problem in which mmap activity to a file that is NFS mounted may cause the client process to hang after the file is deleted. PROBLEM: (MGO101779, QAR 46334) (Patch ID: OSF375-360050) ******** This patch fixes a problem in which PATHWORKS client does not see all the files in a directory when the directory is an NFS mounted OpenVMS UCX exported directory. On an Digital UNIX system a nfs mount to a VMS-UCX system exists. For this mount point a share is setup in Pathworks. PCs connect to this share and don't see all files of this VMS directory, some files and subdirectories are missing. But on the pc it is possible to type the files which are not seen or it is possible to do a cd to the directory which is not seen. In Pathworks the user has all permissions for that share so he can read all files, he can delete the file but it is not possible to write a file to this directory. The same files which are seen on DOS are shown in PWADMIN - Shared Resources - Permit! Examples: 1. It is not possible to see the file x.txt. If x.txt is renamed to a.txt then the file is seen in the directory listing. 2. It is not possible to copy a file to this share (drive X) COPY C:\CONFIG.SYS X: returns the error File not found - X:CONFIG.SYS 0 Files copied --------------- There is no problem in the directory listing if ls command is executed on Digital UNIX. Besides ls -al displays root as owner for every file. PROBLEM: (HPAQ68777) (Patch ID: OSF375-049) ******** A system can crash with: panic: "pmap_remove_range: page wired" if certain kernel functions try to malloc more memory pages than allowed by the vm configuration parameter vm-vpagemax, which by default is set to 16384. While this parameter could be set higher as a temporary workaround, the proper fix is to install this patch. A typical stack trace is: 0 stop_secondary_cpu() [src/kernel/arch/alpha/cpu.c:368] 1 panic("event_timeout: panic request") [src/kernel/bsd/subr_prf.c:669] 2 event_timeout() [src/kernel/arch/alpha/cpu.c:725] 3 xcpu_puts() [src/kernel/bsd/subr_prf.c:810] 4 printf() [src/kernel/bsd/subr_prf.c:355] 5 panic("pmap_remove_range: page wired") [src/kernel/bsd/subr_prf.c:719] 6 pmap_remove_range() [src/kernel/arch/alpha/pmap.c:1804] 7 pmap_remove() [src/kernel/arch/alpha/pmap.c:1946] 8 u_anon_unmap() [src/kernel/vm/u_mape_anon.c:1635] 9 u_map_delete() [src/kernel/vm/vm_umap.c:1211] 10 vm_map_delete() [src/kernel/vm/vm_map.c:1214] 11 munmap() [src/kernel/bsd/kern_mman.c:814] 12 syscall() [src/kernel/arch/alpha/syscall_trap.c:519] 13 _Xsyscall() [src/kernel/arch/alpha/locore.s:1094] PROBLEM: (MGO102099, MGO102041) (Patch ID: OSF375-050) ******** System will crash with " u_shm_oop_deallocate: reference count mismatch." A typical stack trace is shown below: boot panic u_shm_oop_deallocate vm_map_entry_delete u_map_delete u_map_lockvas_expand u_map_enter shmat syscall _Xsyscall The problem is closely related to processes that use the "plock" system call in order to lock their text and/or data segments in memory. When such a process attaches itself to a shared memory segment, the "shmat" system call allocates the required physical pages and "locks" them in memory. There may be a resource shortage in this situation if there aren't enough free pages available. PROBLEM: (CA6Q61192,UVO104419) (Patch ID: OSF375-056) ******** Processes can become hung during a system call to table(). Debuggers are particularly prone to this problem. PROBLEM: (UVO105527) (Patch ID: OSF375-350435) ******** This patch fixes a problem that causes systems to panic with a "kernel memory fault" from u_dev_lockop(). This has happened when a database tried to memory map a file. A typical stack trace follows: 5 panic("kernel memory fault") [src/kernel/bsd/subr_prf.c:753] 6 trap() [src/kernel/arch/alpha/trap.c:1512] 7 _XentMM() [src/kernel/arch/alpha/locore.s:1424] 8 u_dev_lockop() [src/kernel/vm/u_mape_dev.c:535] 9 u_dev_unmap() [src/kernel/vm/u_mape_dev.c:481] 10 u_map_delete() [src/kernel/vm/vm_umap.c:1321] 11 u_dev_create() [src/kernel/vm/u_mape_dev.c:202] 12 spec_mmap() [src/kernel/vfs/spec_vnops.c:2962] 13 smmap() [src/kernel/bsd/kern_mman.c:831] 14 syscall() [src/kernel/arch/alpha/syscall_trap.c:540] 15 _Xsyscall() [src/kernel/arch/alpha/locore.s:1209] kernel_memory_fault_data: faulting virtual address: 0x001ffc003568af9c pc of faulting instruction: 0xfffffc000042dd4c ra contents at time of fault: 0xfffffc000042dcb8 sp contents at time of fault: 0xffffffffa9243600 PROBLEM: (HPAQB18Q8 QAR 51560) (Patch ID: OSF375-096) ******** This patch fixes a file corruption problem that may occur with certain applications, for example Realtime applications, that use the plock() system call or the mlock() and mlockall() library routines. PROBLEM: (QAR 51574, QAR 55127) (Patch ID: OSF375-125) ******** This patch fixes an NFS problem that causes the system to hang. A sample stack trace is as follows: 0 thread_block() 1 ubc_invalidate() 2 vclean() 3 vgone() 4 getnewvnode() 5 vdealloc() 6 vrele() 7 mntflushbuf() 8 nfs_sync() 9 sync() 10 syscall() 11 _Xsyscall() PROBLEM: (QAR 49966, QAR 42030) (Patch ID: OSF375-130) ******** This patch corrects a problem in which a filesystem may fail to unmount during shutdown or reboot. An error message similar to the following is displayed: msfs_unmount EBUSY failed for usr with error 16 during shutdown PROBLEM: (CLD STLB91880 QAR 52188) (Patch ID: OSF375-149) ******** This patch fixes the panic "vm_object_free: res count > 1". The typical stack trace is a follows: > 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":403, 0xfffffc0000477b58] 1 panic(s = 0xfffffc00005c55e8 = "event_timeout: panic request") ["../../../../src/kernel/bsd/subr_prf.c":669, 0xfffffc000043e4ec] 2 event_timeout(func = 0xfffffc000043e740, arg = 0xfffffc0000657118, timeout = 0) ["../../../../src/kernel/arch/alpha/cpu.c":863,0xfffffc0000478908] 3 xcpu_puts(s = 0xffffffffb7947170, prfbufp = 0xfffffc0000657118) ["../../../../src/kernel/bsd/subr_prf.c":810, 0xfffffc000043e7a4] 4 printf(va_alist = -4398040475760) ["../../../../src/kernel/bsd/subr_prf.c": 355, 0xfffffc000043daf4] 5 panic(s = 0xfffffc00005ae1a8 = "vm_object_free: res count > 1") ["../../../../src/kernel/bsd/subr_prf.c":719, 0xfffffc000043e65c] 6 vm_object_free(0xfffffc007893d400, 0xfffffc007893d408, 0x10000, 0xfffffc007893d400, 0xfffffc00774b8980) ["../../../../src/kernel/vm/vm_object.c":320, 0xfffffc0000391e5c] 7 u_anon_oop_deallocate(0xfffffc00774b8980, 0x100000000, 0xfffffc0000391548, 0xfffffc0017d7e2a0, 0x10000) ["../../../../src/kernel/vm/u_mape_anon.c":2622, 0xfffffc0000383bd8] 8 vm_map_entry_delete(0xfffffc00774b8900, 0xfffffc0017d7fb00, 0x10000, 0xfffffc007fd7c030, 0xfffffc000039bec4) ["../../../../src/kernel/vm/vm_map.c":1288, 0xfffffc0000391544] 9 u_map_delete(0xfffffc00774b8900, 0x11fff0000, 0x40000000000, 0x0, 0xfffffc0000432a38) ["../../../../src/kernel/vm/vm_umap.c":1264, 0xfffffc000039c0a0] 10 u_map_deallocate(0xfffffc00774b8900, 0xfffffc0014def080, 0xfffffc00734f3b80, 0xfffffc0000432874, 0xfffffc0000433e98) ["../../../../src/kernel/vm/vm_umap.c":470, 0xfffffc000039a8a0] 11 vm_map_deallocate(0xfffffc0000000000, 0xfffffc00774b8930, 0xfffffc00774b8970, 0xfffffc0000433e94, 0xfffffc0000000000) ["../../../../src/kernel/vm/vm_map.c":619, 0xfffffc0000390778] 12 task_deallocate(task = 0xfffffc00006f65d8) ["../../../../src/kernel/kern/task.c":472, 0xfffffc00002dc26c] 13 waitf(0xfffffc00734f3210, 0xfffffc0000200400, 0xffffffffb79478b8, 0x0, 0xffffffffb79478b8) ["../../../../src/kernel/bsd/kern_exit.c":1506, 0xfffffc0000244624] 14 wait4(0xffffffffb79478b8, 0x0, 0xffffffffb79478b8, 0xfffffc000048c96c, 0xfffffc000048bd58) ["../../../../src/kernel/bsd/kern_exit.c":1229, 0xfffffc00002441c8] 15 syscall(0x3, 0x0, 0x9c, 0xffffffffffffffff, 0x7) ["../../../../src/kernel/arch/alpha/syscall_trap.c":519, 0xfffffc000048bd54] 16 _Xsyscall(0x8, 0x120017368, 0x14000a900, 0xffffffffffffffff, 0x11ffff458) ["../../../../src/kernel/arch/alpha/locore.s":1094, 0xfffffc000047b324](kdbx) p * (struct vm_object *) 0xfffffc007893d400 PROBLEM: (QAR 56327, QAR 59459) (Patch ID: OSF375-165) ******** This patch fixes a panic in the virtual memory management system. The system displays the following error message: trap: invalid memory read access from kernel mode The stack trace is as follows: 0 boot 1 panic 2 trap 3 _XentMM 4 vm_pageout_scan 5 vm_pageout_loop PROBLEM: (QAR 59773, QAR 55941, QAR 56416) (Patch ID: OSF375-177) ******** This patch fixes a problem that produced a deadlock betweeen process threads. Typically, the deadlock caused the msfs_getpage routine to wait forever for a lock to be released. Here are examples of stack traces: 0 thread_block() 1 lock_read() 2 msfs_getpage() 3 u_vp_fault() 4 u_map_fault() 5 vm_fault() 6 trap() 7 _XentMM() Stack trace of a thread: 0 thread_block() 1 lock_read() 2 ufs_fsync_int() 3 ufs_fsync() 4 fsync() 5 syscall() 6 _Xsyscall() Stack trace where the thread is servicing a ufs_write request that calls ufs_rwip and requests a page that needs to be faulted in: 0 thread_block() 1 lock_read() 2 u_map_fault() 3 vm_fault() 4 trap() 5 _XentMM() Stack trace of a thread: 0 thread_block() 1 ubc_clean_free() 2 ubc_msync() 3 u_vp_msync() 4 u_map_control() 5 msync() 6 syscall() 7 _Xsyscall() PROBLEM: (QAR 59847) (Patch ID: OSF375-214) ******** This patch prevents a kernel malloc leak when changing the protection of a System V shared memory region that uses gh-chunks. PROBLEM: (QAR 62831,QAR 62627) (Patch ID: OSF375-228) ******** This patch fixes a virtual memory problem in which an uninitialized pointer in u_dev_protect() causes a kernel memory fault to occur. Here's the stack trace: ---------------------- > 0 boot(0x0, 0x0, 0xfffffc0000777ab0, 0xd, 0x0) ["../../../../src/kernel/arch/ alpha/machdep.c":1795 , 0xfffffc000045ed5c] 1 panic(s = 0xfffffc0000777ab0 = "kernel memory fault") ["../../../../src/ker nel/bsd/subr_prf.c":7 57, 0xfffffc000041ce84] 2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1243, 0xfffffc000046d934 ] 3 _XentMM(0x0, 0xfffffc0000366380, 0xfffffc0000888740, 0x0, 0x190) ["../../.. /../src/kernel/arch/a lpha/locore.s":1307, 0xfffffc000045be24] 4 u_dev_protect(0xfffffc000b3a4b40, 0xfffffc0000000000, 0xfffffc0000000001, 0 xffffffff00000003, 0x ffffffff00000020) ["../../../../src/kernel/vm/u_mape_dev.c":602, 0xfffffc0000366 37c] 5 u_map_protect(0xfffffc000b3a4b40, 0xfffffc000bf30900, 0x38000, 0x3, 0xfffff fff8bd178b8) ["../../ ../../src/kernel/vm/vm_umap.c":1378, 0xfffffc000037a35c] 6 vm_map_protect(0x38000, 0x3, 0xffffffff8bd178b8, 0xffffffff8bd17768, 0xffff fc000037d024) ["../.. /../../src/kernel/vm/vm_map.c":1295, 0xfffffc000036f3f4] 7 vm_protect(0xffffffff8bd178b8, 0xffffffff8bd17768, 0xfffffc000037d024, 0xff fffc000bf30900, 0xfff ffc000040d050) ["../../../../src/kernel/vm/vm_user.c":206, 0xfffffc000037d020] 8 mprotect(0xfffffc000304e210, 0xffffffff8bd17758, 0xffffffff8bd178b8, 0x1, 0 x0) ["../../../../src crash-data.1 (61%) /kernel/bsd/kern_mman.c":879, 0xfffffc000040d04c] 9 syscall(0x3ffc0093530, 0x1, 0x1, 0x0, 0x4a) ["../../../../src/kernel/arch/a lpha/syscall_trap.c": 527, 0xfffffc000046c72c] 10 _Xsyscall(0x8, 0x3ff801588d8, 0x140008120, 0x24000, 0x14000) ["../../../../ src/kernel/arch/alpha /locore.s":1094, 0xfffffc000045bc14] End Trace for machine_slot[paniccpu].cpu_panic_thread: