DUV32FAS00003-19980714 DIGITAL UNIX V3.2F Aggregate ECO Summary
TITLE: DUV32FAS00003-19980714 DIGITAL UNIX V3.2F Aggregate ECO Summary
Copyright (c) Compaq Computer Corporation 1998. All rights reserved.
PRODUCT: DIGITAL UNIX [R] 3.2F
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: DUV32FAS00003-19980714
ECO Kit Approximate Size: 39MB
Kit Applies To: DIGITAL UNIX 3.2F
ECO KIT SUMMARY:
An update ECO kit exists for DIGITAL UNIX 3.2F. This is the aggregate,
setld-based, patch kit for DIGITAL UNIX 3.2F. It is a cumulative patch kit
that contains all patches that are currently available for distribution.
The patch kit provides the ability to selectively install patches.
The Release Notes and Installation Instructions document provides patch kit
installation and removal instructions and a summary of each patch. Please read
through the document prior to installing patches on your system.
Note:
At this time, the release note/installation document is only available in
postscript form. It will be available in text and HTML formats in the future.
INSTALLATION NOTES:
1. Install this kit with the dupatch utility that is included in the patch kit.
The Release Notes and Installation Instructions document provides detailed
patch installation, patch removal, and a summary of each patch. You may
need to baseline your system if you have manually changed system files on
your system. The dupatch utility provides the baselining capability.
2. The setld-based patch kits DO NOT know about any of the patches provided in
previous manual-install official or test patch kits. A baseline must be set
for systems that have been manually patched. This can be accomplished by
selecting option 5 "Patch Baseline Analysis/Adjustment" from the dupatch
menu.
SUPERSEDED PATCH LIST:
This patch kit supersedes the following DIGITAL UNIX patches:
DUV32FAS00002-19971001 ! Previous Aggregate Patch Kit
KNOWN PROBLEMS WITH THIS PATCH KIT:
None.
[R] UNIX is a registered trademark in the United States and other countries
licensed exclusively through X/Open Company Limited.
Copyright Compaq Computer Corporation 1998. All Rights reserved.
This software is proprietary to and embodies the confidential technology
of Compaq Computer Corporation. Possession, use, or copying of this
software and media is authorized only pursuant to a valid written license
from Compaq or an authorized sublicensor.
This ECO has not been through an exhaustive field test process.
Due to the experimental stage of this ECO/workaround, Compaq
makes no representations regarding its use or performance. The
customer shall have the sole responsibility for adequate protection
and back-up data used in conjunction with this ECO/workaround.
===============================================================================
The system panics with kernel memory fault, and the fault_pc is in the
u_anon_free() routine.
PROBLEM: (QAR 43968) (Patch ID: OSF370-004)
********
The system panics with kernel memory fault, and the fault_pc is in the
u_anon_free() routine.
> 0 stop_secondary_cpu() [arch/alpha/cpu.c":357, 0xfffffc00004d97a8]
1 panic() [bsd/subr_prf.c":669, 0xfffffc000043d5ac]
2 event_timeout() [arch/alpha/cpu.c":706, 0xfffffc00004da258]
3 xcpu_puts() [bsd/subr_prf.c":810, 0xfffffc000043d864]
4 printf() [bsd/subr_prf.c":355, 0xfffffc000043cbb4]
5 panic() [bsd/subr_prf.c":719, 0xfffffc000043d71c]
6 trap() [arch/alpha/trap.c":1213, 0xfffffc00004edbd0]
7 _XentMM() [arch/alpha/locore.s":1307, 0xfffffc00004dce74]
8 u_anon_free() [vm/u_mape_anon.c":2261, 0xfffffc00003840e4]
9 u_anon_unmap() [vm/u_mape_anon.c":1617, 0xfffffc0000382970]
10 u_map_delete() [vm/vm_umap.c":1188, 0xfffffc000039c650]
11 u_map_deallocate() [vm/vm_umap.c":436, 0xfffffc000039af80]
12 vm_map_deallocate() [vm/vm_map.c":611, 0xfffffc0000391698]
13 task_deallocate() [kern/task.c":472, 0xfffffc00002d6b0c]
14 waitf() [bsd/kern_exit.c":1497, 0xfffffc0000243b94]
15 wait4() [bsd/kern_exit.c":1220, 0xfffffc0000243738]
16 syscall() [arch/alpha/syscall_trap.c":519, 0xfffffc00004eca44]
17 _Xsyscall() [arch/alpha/locore.s":1094, 0xfffffc00004dcc64]
The crash can be reproduced by running the following sample program:
/*
* compile as follows:
* cc vm_deallocate_tail.c -lmach
*/
main(int argc, char **argv)
{
long addr;
int ret;
/*
* Create a >4G region
* The system must have >4G swap or must be running in lazy mode
* (/sbin/swapdefault is not present).
*/
addr = 0;
if (ret = vm_allocate(task_self(), &addr, 0x100000000UL, 1)) {
mach_error("vm_allocate:", ret);
exit(1);
}
/*
* deallocate the last page
*/
if (ret = vm_deallocate(task_self(),
addr+0x100000000UL-0x2000, 0x2000)) {
mach_error("vm_deallocate:", ret);
exit(1);
}
exit(0);
}
FILE(s):
/usr/sys/BINARY/vm_anon.o subset OSFBIN370
CHECKSUM: 18602 73 RCSfile: vm_anon.c RCS: 1.1.45.2
===============================================================================
This patch fixes a problem where a system with more than one PCI bus will fail
to configure the loadable device drivers.
PROBLEM: (42593) (Patch ID: OSF370-010)
********
This patch fixes a problem where a system with more than one PCI bus will fail
to configure the loadable device drivers.
You can see that the device drivers are loaded, but they cannot be configured
or unloaded.
FILE(s):
/usr/sys/BINARY/ldbl_controller_support.o subset OSFHWBIN350
CHECKSUM: 05453 8 RCSfile: ldbl_controller_support.c RCS: 1.1.14.3
/usr/sys/BINARY/pci.o subset OSFHWBIN370
CHECKSUM: 19277 29 RCSfile: pci.c RCS: 1.1.111.2
/usr/sys/BINARY/stanza_resolver.o subset OSFHWBIN350
CHECKSUM: 15866 16 RCSfile: stanza_resolver.c RCS: 1.1.15.3
===============================================================================
Fixes a problem where a system, with a RAID set for a dump device, will not
save the crash dump to the RAID set after a panic.
PROBLEM: (MCPMA0101) (Patch ID: OSF370-015)
********
Fixes a problem where a system, with a RAID set for a dump device, will not
save the crash dump to the RAID set after a panic.
This results in crash dumps not being performed and errors not being logged
to the error log files.
FILE(s):
/usr/sys/BINARY/ruby_common.o subset OSFHWBIN370
CHECKSUM: 27962 15 RCSfile: ruby_common.c RCS: 1.1.34.2
===============================================================================
An ioctl() system call within a user application will fail if the TIOCM_RI flag
is passed as an argument to this system call.
PROBLEM: (HPAQ248A7) (Patch ID: OSF370-365030)
********
An ioctl() system call within a user application will fail if the TIOCM_RI flag
is passed as an argument to this system call.
There are no stack traces associated with this failure, the ioctl() system call
within an application will fail.
FILE(s):
/usr/sys/BINARY/ace.o subset OSFHWBIN370
CHECKSUM: 52334 28 RCSfile: ace.c 1.1.80.2
===============================================================================
This patch prevents duplicate namecache entries on SMP systems. Under heavy
filesystem lookup operations this can eventually result in a simple lock
timeout and a system panic.
PROBLEM: (MCPM750D6, HPXQ36ADF) (Patch ID: OSF370-036)
********
A flaw exists in Digital UNIX SMP systems that results in duplicate namecache
entries being created. Under heavy file system lookup operations this can
eventually result in a simple lock timeout and a system panic.
The typical crash data file stack trace will look like the following:
> 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c"
1 panic(s = 0xfffffc0000607a98 = "event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c"()
["../../../../src/kernel/arch/alpha/cpu.c"
3 xcpu_puts() ["../../../ ../src/kernel/bsd/subr_prf.c"
5 panic(s = "simple_lock: time limit exceeded")
["../../../../src/kernel/bsd/subr_prf.c"
6 simple_lock_fault(slp = "simple_lock : time limit exceeded")
["../../../../src/kernel/kern/lock.c"
7 simple_lock_time_violation(slp = caller = (nil))
["../../../../src/kernel/kern/lock.c "
8 cache_lookup() ["../../../../src/kernel/vfs/vfs_cache.c"
9 ufs_lookup() ["../../../../src/kernel/ufs/ufs_lookup.c"
10 namei() ["../../../../src/kernel/vfs/vfs_lookup.c"
11 unp_connect() ["../../../../src/kernel/bsd/uipc_usrreq.c"
12 uipc_usrreq() ["../../../../src/kernel/bsd/uipc_usrreq.c"
13 sosend() ["../../../../src/kernel/bsd/uipc_s ocket.c"
14 sendit() ["../../../../src/kernel/bsd/uipc_s yscalls.c"
15 sendto() ["../../../../src/kernel/bsd/uipc_syscalls.c"
16 syscall() ["../../../../src/kernel/arch/alpha/syscall_tra
17 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"
FILE(s):
/usr/sys/BINARY/vfs_cache.o subset OSFBIN370
CHECKSUM: 56092 56 RCSfile: vfs_cache.c RCS: 4.2.49.2
===============================================================================
SUPERSEDES PATCHES: OSF370-008 (8.00), OSF370-009 (9.00),
OSF370-027 (27.00)
This patch corrects the following:
- A problem that occurs with the NCR 53C8XX driver (psiop) in which the device
may not appear to be on the SCSI bus.
- Data corruption due to change in DNAD register behavior on Symbios
810A/825A/860/875 chips.
- At boot, when probing the psiop driver, the system may continuously loop
generating the following error message:
"siopintr: interrupt for non-initialized controller"
PROBLEM: (QAR 36371) (Patch ID: OSF370-008, OSF370-009)
********
At boot, when probing the psiop driver, the system may continuously loop
generating the following error message:
"siopintr: interrupt for non-initialized controller"
This error rarely occurs. Our test cases only encountered it when continuously
rebooting for 18+ hours. To cause the machine to reboot, the system usually
started a "shutdown -r now" as part of the bootup sequence
PROBLEM: (QAR 46878) (Patch ID: OSF370-027)
********
Data corruption due to change in DNAD register behavior on Symbios
810A/825A/860/875 chips.
This data corruption problem is difficult to detect as no error report, etc.
is given when it occurs. The data corruption can be identified by the pattern
in the corrupted data. Commonly, at the point of corruption, there will be 3
bytes of unknown data inserted into the valid data stream.
This problem is induced by a chip register behavior change between the 810 and
810a. The register (DNAD) is used to calculate the next dma address whenever a
dma transfer is interrupted by a phase change by the scsi device.
This problem can be reproduced using the UEG engineering test script
"dt_tag_rotate_sh" which tests unaligned data accesses.
PROBLEM: (49240) (Patch ID: OSF370-040)
********
This patch fixes a problem that occurs with the NCR 53C8XX driver (psiop).
In rare cases when negotiating sync xfr rates, the driver may reject the
target's Synchronous Transfer Negotiation, even if the target replied with a
synchronous offset equal to zero, thereby implying asynchronous transfers.
A device not expecting this behavior may not appear to be connected to the
system.
The RW531 Optical Jukebox, with Rev 0.37 firmware or later, does not expect
this behavior and will exhibit the symptoms of the optical disk devices
appearing on the SCSI bus, but not the changer devices.
FILE(s):
/usr/sys/BINARY/psiop.o subset OSFHWBIN370
CHECKSUM: 21323 176 RCSfile: psiop.c RCS: 1.1.65.5
/usr/sys/BINARY/psiop_pci.o subset OSFHWBIN370
CHECKSUM: 29754 27 RCSfile: psiop_pci.c RCS: 1.1.49.3
/usr/sys/include/io/cam/siop/pci_scripthost.h subset OSFBINCOM370
CHECKSUM: 00415 17 RCSfile: pci_scripthost.h RCS: 1.1.37.2
===============================================================================
SUPERSEDES PATCHES: OSF370-039 (39.00)
This patch corrects the following:
- Fixes problem on AlphaServer 2100A system; when the system is shut
down using the "shutdown -r" command, the system will not reboot.
- Alphaserver 2100A system crashes during boot with greater than 1GB of
memory installed.
PROBLEM: (EMZB83716, QAR 48019) (Patch ID: OSF370-039)
********
The Unix kernel crashes during installation if the memory in the system exceeds
1GB. This has only been seen on AlphaServer 2100A class systems with greater
than 1GB of memory.
During driver initialization, a machine check 660 such as the following occurs:
Alpha boot: available memory from 0x29be000 to 0x7fffe000
Digital UNIX V4.0 (Rev. 386); Mon May 20 04:41:58 EDT 1996
physical memory = 2048.00 megabytes.
available memory = 2006.31 megabytes.
using 2618 buffers containing 20.45 megabytes of memory
Master cpu at slot 0.
Firmware revision: 4.5
PALcode: OSF version 1.21
ibus0 at nexus
AlphaServer 2100 5/250
cpu 0 EV-5 4mb b-cache
cpu 1 EV-5 4mb b-cache
gpc0 at ibus0
pci0 at ibus0 slot 0
tu0: DECchip 21040-AA: Revision: 2.3
Machine Check SYSTEM Fatal Abort
pal temp[0-1] = d02cadc77bdecdf9 0000000000000006
pal temp[2-3] = fffffc00004042a0 0000000000004200
pal temp[4-5] = 0000008180000000 0000000380000000
pal temp[6-7] = 0000000198000000 fffffc0000403cf0
pal temp[8-9] = 1f1e161514020100 fffffc0000404010
pal temp[10-11] = fffffc0000407704 fffffc0000403e70
pal temp[12-13] = fffffc0000404210 000ic (cpu 0): System Uncorrectable
Machine Check 660
...
PROBLEM: (MCSM715R1) (Patch ID: OSF370-058)
********
When the system is shut down using the "shutdown -r" command,
the system will not reboot.
FILE(s):
/usr/sys/BINARY/cbus2_pci.o subset OSFHWBIN370
CHECKSUM: 14634 53 RCSfile: cbus2_pci.c RCS: 1.1.40.3
/usr/sys/include/arch/alpha/hal/cbus2_pci.h subset OSFHWBINCOM370
CHECKSUM: 38001 36 RCSfile: cbus2_pci.h RCS: 1.1.16.2
===============================================================================
Fixes a problem in which the io_zero() system call returns
an incorrect value on an AlphaServer 1000.
PROBLEM: (QAR 51566 QAR 49877) (Patch ID: OSF370-059)
********
This patch fixes a problem in which the io_zero() system call returns
an incorrect value on an AlphaServer 1000.
The io_zero() system call now returns "IOA_OKAY".
FILE(s):
/usr/sys/BINARY/apecs.o subset OSFHWBIN370
CHECKSUM: 18215 20 RCSfile: apecs.c RCS: 1.1.50.2
/usr/sys/BINARY/lca.o subset OSFHWBIN370
CHECKSUM: 06954 21 RCSfile: lca.c RCS: 1.1.53.2
===============================================================================
Crash-dumps to non-re0 RAID devices broken on all PCI & EISA machines.
PROBLEM: (QAR 46654) (Patch ID: OSF370-365025)
********
When a system crash is attempted to a RAID disk that is anything but device
"re0", the crash dump will fail.
The typical (console) error message will look something like this:
(this is a dump to re3):
DUMP: 8482815 blocks available for dumping.
DUMP: 524273 required for a full dump.
DUMP: Our last 524272 goes in the 8220671 on 0xb00082, starting at 0
DUMP.prom: dev RAID 1 3 0 3 3 0 0, block 131072
DUMP.prom: I/O error on RAID 1 3 0 3 3 0 0: bn = 262143, status = -1
^.............
the error is that the 5th field should be zero -'
This problem can be reproduced on a PCI or EISA machine with a RAID controller
(SWXCR-xx) by forcing a system crash when the swap device is anything but re0.
To force a system crash, refer to the Guide to Kernel Debugging, section 4.7.
FILE(s):
/usr/sys/BINARY/console.o subset OSFHWBIN370
CHECKSUM: 47029 12 RCSfile: console.c RCS: 1.1.76.2
===============================================================================
SUPERSEDES PATCHES: OSF370-350104 (105.00)
This patch corrects the following:
- Fixes a problem where processes will hang in an uninterruptable state while
using NFS loopback mounts.
- Kernel memory fault in ubc_sync_iodone().
PROBLEM: (MCPMC8AC6) (Patch ID: OSF370-350104)
********
The panic was seen when a large number (~150) of "fastdd" is run using seperate
LSM raw volumes and writing to UFS files. UBC must be constrained as follows:
ubc-minpercent=1
ubc-maxpercent=20
...
13 boot() [arch/alpha/machdep.c":1679, 0xfffffc000045a674]
14 panic() [bsd/subr_prf.c":757, 0xfffffc0000419d54]
15 trap() [arch/alpha/trap.c":1213, 0xfffffc0000468600]
16 _XentMM() [arch/alpha/locore.s":1307, 0xfffffc00004578a4]
17 ubc_sync_iodone() [vfs/vfs_ubc.c":1022, 0xfffffc0000298ddc]
18 ufs_rwblk() [ufs/ufs_vnops.c":4427, 0xfffffc000027a488]
19 ufs_writepages() [ufs/ufs_vnops.c":5385, 0xfffffc000027c15c]
20 ufs_putpage() [ufs/ufs_vnops.c":5187, 0xfffffc000027bc38]
21 ubc_page_alloc() [vfs/vfs_ubc.c":2144, 0xfffffc000029ba00]
22 ubc_lookup() [vfs/vfs_ubc.c":1789, 0xfffffc000029aa70]
23 ufs_getapage() [ufs/ufs_vnops.c":4797, 0xfffffc000027afbc]
24 ufs_getpage() [ufs/ufs_vnops.c":5112, 0xfffffc000027ba5c]
25 ufs_rwip() [ufs/ufs_vnops.c":5859, 0xfffffc000027cd44]
26 ufs_write() [ufs/ufs_vnops.c":1771, 0xfffffc0000276b00]
27 vn_write() [vfs/vfs_vnops.c":932, 0xfffffc00002973a0]
28 rwuio() [bsd/sys_generic.c":1071, 0xfffffc0000250bec]
29 write() [bsd/sys_generic.c":996, 0xfffffc0000250a78]
30 syscall() [arch/alpha/syscall_trap.c":519, 0xfffffc0000467474]
31 _Xsyscall() [arch/alpha/locore.s":1094, 0xfffffc0000457694]
PROBLEM: (HPAQC3A71) (Patch ID: OSF370-360024)
********
This patch fixes a problem where processes on a system may block in an
uninterruptible state and never run again.
This problem occurs when using NFS loopback mounts. The stack trace of the
current running processes on the system will not display a problem. Although,
if the stack trace of the blocked processes is displayed and the trace for some
of the kernel's NFS server threads is displayed - it may look similar to the
following:
THIS IS THE STACK TRACE FOR THE CLIENT:
> 0 thread_block() [kern/sched_prim.c":1903]
1 mpsleep() [bsd/kern_synch.c":441]
2 clntkudp_callit_addr() [rpc/clnt_kudp.c":631]
3 clntkudp_callit() [rpc/clnt_kudp.c":1008]
4 rfscall() [nfs/nfs_subr.c":837]
5 rfs3call() [nfs/nfs_subr.c":974]
6 nfs3commit() [nfs/nfs3_vnodeops.c":3754]
7 nfs3_putpage() [nfs/nfs3_vnodeops.c":3528]
8 ubc_page_alloc() [vfs/vfs_ubc.c":2145]
9 ubc_lookup() [vfs/vfs_ubc.c":1789]
10 page_lookup() [msfs/bs/bs_buffer2.c":872]
11 bs_pinpg_one_int() [msfs/bs/bs_buffer2.c":3218]
12 bs_pinpg_clone() [msfs/bs/bs_buffer2.c":2877]
13 bs_pinpg() [msfs/bs/bs_buffer2.c":2371]
14 fs_write() [msfs/fs/fs_read_write.c":515]
15 msfs_write() [msfs/osf/msfs_vnops.c":1547]
16 vn_write() [vfs/vfs_vnops.c":932]
17 rwuio() [bsd/sys_generic.c":1071]
18 write() [bsd/sys_generic.c":996]
19 syscall() [arch/alpha/syscall_trap.c":519]
20 _Xsyscall() [arch/alpha/locore.s":1094]
THIS IS THE STACK TRACE FOR THE SERVER THREAD WHICH WOKE UP TO HANDLE THE ABOVE
CLIENT's REQUEST:
> 0 thread_block() [kern/sched_prim.c":1891]
1 mpsleep() [bsd/kern_synch.c":441]
2 clntkudp_callit_addr() [rpc/clnt_kudp.c":631]
3 clntkudp_callit() [rpc/clnt_kudp.c":1008]
4 rfscall() [nfs/nfs_subr.c":837]
5 rfs3call() [nfs/nfs_subr.c":974]
6 nfs3commit() [nfs/nfs3_vnodeops.c":3754]
7 nfs3_putpage() [nfs/nfs3_vnodeops.c":3528]
8 ubc_page_alloc() [vfs/vfs_ubc.c":2145]
9 ubc_lookup() [vfs/vfs_ubc.c":1789]
10 page_lookup() [msfs/bs/bs_buffer2.c":872]
11 bs_pinpg_one_int() [msfs/bs/bs_buffer2.c":3218]
12 bs_pinpg_clone() [msfs/bs/bs_buffer2.c":2877]
13 bs_pinpg() [msfs/bs/bs_buffer2.c":2371]
14 get_clean_pg() [msfs/bs/ms_logger.c":1495]
15 lgr_writev_ftx() [msfs/bs/ms_logger.c":1258]
16 log_donerec_nunpin() [msfs/bs/ftx_routines.c":2719]
17 ftx_done_urdr() [msfs/bs/ftx_routines.c":1215]
18 ftx_done_n() [msfs/bs/ftx_routines.c":968]
19 msfs_fsync() [msfs/osf/msfs_vnops.c":1650]
20 rfs3_commit() [nfs/nfs3_server.c":5671]
21 rfs_dispatch() [nfs/nfs_server.c":6333]
22 nfs_rpc_input() [rpc/svc.c":717]
23 nfs_input() [nfs/nfs_server.c":5492]
24 nfs_thread() [nfs/nfs_server.c":5277]
THIS IS THE STACK TRACE FOR A SERVER THREAD WHICH WOKE UP TO HANDLE THE ABOVE
SERVER's REQUEST:
> 0 thread_block() [kern/sched_prim.c":1891]
1 thread_sleep() [kern/sched_prim.c":1581]
2 _cond_wait() [msfs/bs/ms_generic_locks.c":592]
3 _lk_lock() [msfs/bs/ms_generic_locks.c":931]
4 lgr_writev_ftx() [msfs/bs/ms_logger.c":1236]
5 log_donerec_nunpin() [msfs/bs/ftx_routines.c":2719]
6 ftx_done_urdr() [msfs/bs/ftx_routines.c":1215]
7 ftx_done_n() [msfs/bs/ftx_routines.c":968]
8 bs_sync_bf_flush() [msfs/bs/bs_qio.c":2402]
9 msfs_fsync() [msfs/osf/msfs_vnops.c":1608]
10 rfs3_commit() [nfs/nfs3_server.c":5665]
11 rfs_dispatch() [nfs/nfs_server.c":6333]
12 nfs_rpc_input() [rpc/svc.c":717]
13 nfs_input() [nfs/nfs_server.c":5492]
14 nfs_thread() [nfs/nfs_server.c":5277]
FILE(s):
/usr/sys/BINARY/vm_cfg.o subset OSFBIN370
CHECKSUM: 58472 7 RCSfile: vm_cfg.c RCS: 1.1.31.2
/usr/sys/BINARY/vfs_ubc.o subset OSFBIN350
CHECKSUM: 59465 54 RCSfile: vfs_ubc.c RCS: 1.1.118.3
===============================================================================
SUPERSEDES PATCHES: OSF370-360037 (71.00)
This patch corrects the following:
- 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.
- 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: (QAR 33924) (Patch ID: OSF370-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: OSF370-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.
FILE(s):
/usr/sys/BINARY/nfs_vnodeops.o subset OSFBIN370
CHECKSUM: 32783 42 RCSfile: nfs_vnodeops.c RCS: 1.1.104.7
/usr/sys/BINARY/nfs3_vnodeops.o subset OSFBIN370
CHECKSUM: 37658 50 RCSfile: nfs3_vnodeops.c RCS: 1.1.56.3
===============================================================================
The ar command's -x option, which extracts archive files, may, in error, return
a message stating that the file was not found.
PROBLEM: (DJOB3K133, QAR 46595) (Patch ID: OSF370-360062)
********
The ar command's -x option, which extracts archive files, may in error, return
a message stating that the specified archive file was not found.
To duplicate the problem, create a library with the command
'ar r /tmp/foo.a /tmp/bar.o'.
Issuing the command 'ar -x /tmp/foo.a /tmp/bar.o' will generate the message
"ar: Error: /tmp/bar.o not found"
even though the file exists in the archive.
With the fix, the same command extracts /tmp/bar.o from /tmp/foo.a without
generating an error message.
FILE(s):
/usr/ccs/lib/cmplrs/cc/ar subset OSFBASE370
CHECKSUM: 25220 376 RCSfile: ar.c RCS: 4.2.33.2
RCSfile: bsearch.c RCS: 4.2.6.3
===============================================================================
This patch corrects the following:
- This patch allows system managers to both set and obtain quotas for users
and groups which are numeric when using the edquota, vedquota, quota and
vquota programs. It also provides new options to allow them to specify
userids and groupids.
PROBLEM: (HPXQ87072, QAR 46521) (Patch ID: OSF370-360064-1)
********
This patch allows system managers to both set and obtain quotas for users and
groups which are numeric when using the edquota, vedquota, quota and vquota
programs. It also provides new options to allow them to specify userids and
groupids.
In the past, when the input to these commands was a numeric username or
groupname, the commands would either report that the name couldn't be found,
or would interpret it as the wrong user or group (when the name coincidentally
matched a valid userid or groupid).
For circumstances where the user wishes to specify userid or groupid the -U and
-G options have been added.
This correction also extends the edquota and vedquota prototype option to allow
convenient use of names and ids. In the past a numeric argument to the "-p"
option was incorrectly considered an id, not a name. Now, the argument to "-p"
will always refer to a name while the argument to the new option "-P" will
refer to an id.
Examples
To apply the quotas of user1 to user2, specifying both by their names:
edquota -p user1name user2name
To apply the quotas of user1 (specified by id), to user2 (specified by id):
edquota -P user1id -U user2id
Also, note that new versions of the message catalogue files are issued for each
of the programs. These must be updated only if they are on the system.
FILE(s):
/usr/lib/nls/msg/en_US.ISO8859-1/edquota.cat subset OSFBASE350
CHECKSUM: 26567 2
/usr/lib/nls/msg/en_US.ISO8859-1/quota.cat subset OSFBASE350
CHECKSUM: 60092 1
/usr/sbin/edquota subset OSFBASE370
CHECKSUM: 30231 112 RCSfile: edquota.c RCS: 4.2.29.2
/usr/sbin/quota subset OSFBASE370
CHECKSUM: 61455 112 RCSfile: quota.c RCS: 4.2.39.2
RCSfile: rquotaxdr.c RCS: 4.2.4.2
/usr/sbin/vedquota subset OSFADVFS370
CHECKSUM: 38644 568 RCSfile: vedquota.c RCS: 1.1.28.2
/usr/sbin/vquota subset OSFADVFS370
CHECKSUM: 02462 512 RCSfile: vquota.c RCS: 1.1.25.2
===============================================================================
SUPERSEDES PATCHES: OSF370-360052 (280.00)
This patch corrects the following:
- Fixes a "simple_lock: time limit exceeded" panic originating from either:
o ctape_close() routine
o ctape_strategy() routine
- This patch fixes "simple_lock: time limit exceeded" panics coming from
ctape_close() or ctape_strategy() routines.
PROBLEM: (MCPM36085) (Patch ID: OSF370-360052)
********
A "simple_lock: time limit exceeded" panic will be seen originating from the
ctape_close() routine. The stack trace is as follows:
6 panic("simple_lock: time limit exceeded")
7 simple_lock_fault()
8 simple_lock_time_violation()
9 ctape_close()
10 speclose()
11 spec_close()
12 ufsspec_close()
13 vn_close()
14 closef()
15 close()
16 syscall()
17 _Xsyscall()
PROBLEM: (UVO104133) (Patch ID: OSF370-360052)
********
A "simple_lock: time limit exceeded" panic will be seen originating from the
ctape_strategy() routine. The stack trace is as follows:
9 panic("simple_lock: time limit exceeded")
10 simple_lock_fault()
11 simple_lock_time_violation()
12 ccmn_rsq_ccb_bld()
13 ctape_strategy()
14 physio()
15 ctape_write()
16 spec_write()
17 ufsspec_write()
18 vn_write()
19 rwuio()
20 write()
21 syscall()
22 _Xsyscall()
PROBLEM: (MCPMB61A4) (Patch ID: OSF370-360078)
********
This patch fixes a "simple_lock: time limit exceeded".
The following is a list of the typical error messages displayed in the
preserved message buffer when the panic occurs:
simple_lock: time limit exceeded
pc of caller: 0xfffffc00005265ec
lock address: 0xfffffc007f5f3ad0
current lock state: 0x00000000005264c5
(cpu=0,pc=0xfffffc00005264c4,busy)
panic (cpu 12): simple_lock: time limit exceeded
simple lock timeout pc?5i and lock address?5i
(dbx) 0xfffffc00005265ec?5i
[ctape_close:2669, 0xfffffc00005265ec] addq r31, 0x4, r16
[ctape_close:2669, 0xfffffc00005265f0] bsr r26, swap_ipl(line 131)
[ctape_close:2669, 0xfffffc00005265f4] stl r0, 176(sp)
[ctape_close:2669, 0xfffffc00005265f8] bis r9, r9, r16
[ctape_close:2669, 0xfffffc00005265fc] bsr r26, simple_lock(line 26
6)
(dbx) 0xfffffc00005264c4?5i
[ctape_close:2601, 0xfffffc00005264c4] addq r31, 0x4, r16
[ctape_close:2601, 0xfffffc00005264c8] bsr r26, swap_ipl(line 131)
[ctape_close:2601, 0xfffffc00005264cc] stl r0, 176(sp)
[ctape_close:2601, 0xfffffc00005264d0] bis r9, r9, r16
[ctape_close:2601, 0xfffffc00005264d4] bsr r26, simple_lock(line 26
6)
This indicates the code that was improperly holding the lock.
Stack Trace for this problem:
panic("simple_lock: time limit exceeded") ["../../../../src/kernel/bsd/subr_p
rf.c":757]
simple_lock_fault() ["../../../../src/kernel/kern/lock.c":1794]
simple_lock_time_violation() ["../../../../src/kernel/kern/lock.c":1863]
ctape_close() ["../../../../src/kernel/io/cam/ cam_tape.c":2669]
speclose() ["../../../../src/kernel/vfs/spec_vnops.c":2306]
spec_close() ["../../../../src/kernel/vfs/spec_vnops.c":2459]
msfsspec_close() ["../../../../src/kernel/msfs/osf/msfs_vnops.c":3869]
vn_close() ["../../../../src/kernel/vfs/vfs_vnops.c":1220]
closef() ["../../../../src/kernel/bsd /kern_descrip.c":1393]
close() ["../../../../src/kernel/bsd/kern_descrip.c":1071]
FILE(s):
/usr/sys/BINARY/cam_tape.o subset OSFHWBIN370
CHECKSUM: 50865 146 RCSfile: cam_tape.c RCS: 1.1.73.2
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
PROBLEM: (SSRT0329U, USG-01683) (Patch ID: OSF370-350061)
********
A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/bin/rdist subset OSFINET350
CHECKSUM: 23263 88 RCSfile: server.c RCS: 4.2.21.2
===============================================================================
The bootp daemon appends a null character to file names in its responses.
PROBLEM: (BRO100554) (Patch ID: OSF370-350073)
********
The bootp server daemon, /usr/sbin/bootpd, appends a null byte to filenames
in its responses. Some BOOTP clients will fail to boot when they receive
these responses. The response packets will contain the null byte appended to
any filenames and the cooresponding length fields will count the null byte.
FILE(s):
/usr/sbin/bootpd subset OSFINET350
CHECKSUM: 19997 72 RCSfile: bootpd.c RCS: 4.2.25.2
RCSfile: dovend.c RCS: 1.1.8.2
RCSfile: readfile.c RCS: 4.2.12.2
===============================================================================
Corrections to tftpd when using interface aliases, bind() uses the client's
address received rather than INADDR_ANY. This fix accomodates bootpd when
used with ASE for failover purposes.
PROBLEM: (HPAQA69B2,QAR40362) (Patch ID: OSF370-350089)
********
Attempting to tftpd to an aliased interface will give "ICMP Destination
unreachable" messages when multiple read requests are required to transfer data.
Typical Error Messages are "ICMP Destination unreachable" or "Port unreachable".
To reproduce the problem, tftp to an aliased interface and transfer a file
larger than 512 bytes. The transfer will require multiple read requests
and will return an error on the second read request.
FILE(s):
/usr/sbin/tftpd subset OSFINET350
CHECKSUM: 55861 32 RCSfile: tftpd.c RCS: 4.2.11.2
===============================================================================
Fix acctcms hash table overflow error.
PROBLEM: (TKTQ22355) (Patch ID: OSF370-350096)
********
When there are more than 1000 different commands in the accounting
source files, acctcms gives the error "Hash table overflow. Increase
CSIZE" and ignores the command accounting records of those commands
in excess of 1000. This problem can also be seen when running
runacct, the daily accounting procedure, because it uses acctcms
FILE(s):
/usr/sbin/acct/acctcms subset OSFACCT350
CHECKSUM: 37955 32 RCSfile: acctcms.c RCS: 4.2.18.2
===============================================================================
Program using libexc.a suffer corrupted signal masks.
PROBLEM: (EVT101544) (Patch ID: OSF370-350102)
********
Programs linked with the libexc.a library can have their process signal masks
corrupted while handling exceptions at runtime. The problem shows up when the
process stops responding to signals. The ps -s command shows a mask of random
signals blocked, including the one required to make the program function
correctly.
Ada and C++ programs seems to the most likely to experience the program.
FILE(s):
/usr/ccs/lib/cmplrs/cc/libexc.a subset OSFCMPLRSEXT350
CHECKSUM: 21801 23
===============================================================================
Correct nfs server duplicate request problem, by adding timestamps.
PROBLEM: (MGO101612) (Patch ID: OSF370-350109)
********
Fixes file corruption on a Digital UNIX NFS fileserver serving a sole single
non-Digital NFS client. Problem originally encountered when the only client
was an OS/2 client.
This patch should be installed if you observe server corruption and can bypass
that corruption by setting the kernel global variable 'kudp_usedrc' to zero.
Do not consider turning off duplicate record checking (drc) as a solution.
Instead, please use this patch to correctly fix the problem.
FILE(s):
/usr/sys/BINARY/svc_kudp.o subset OSFBIN350
CHECKSUM: 49986 86 RCSfile: svc_kudp.c RCS: 1.1.23.2
===============================================================================
Running tip(1) consumes about 45% of cpu time, resulting in no idle time, even
if tip is about the only thing running on the system.
PROBLEM: (SOO100598) (Patch ID: OSF370-350111)
********
Running tip will use approximately 45% of CPU time.
Use "ps -Ocpu" to see CPU usage. Also, running vmstat will show 0% IDle time.
# vmstat 5
Virtual Memory Statistics: (pagesize = 8192)
procs memory intr cpu
r w u act free wire in sy cs us sy id
3 73 16 1805 129 802 36 70K 245 10 90 0
3 73 16 1805 129 802 3 71K 239 10 90 0
3 73 16 1806 128 802 102 67K 306 10 90 0
# ps -Opcpu | grep tip
PID %CPU S TT TIME COMMAND
14058 46.0 U + ttyp4 0:09.64 tip
14092 0.0 U + ttyp1 0.01 grep tip
FILE(s):
/usr/bin/tip subset OSFCLINET350
CHECKSUM: 56943 120 RCSfile: tip.c RCS: 4.2.21.2
RCSfile: tipout.c RCS: 4.2.4.3
===============================================================================
A potential security vulnerability has been discovered where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
PROBLEM: (QAR 41986) (Patch ID: OSF370-350112)
********
A potential security vulnerability has been discovered where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/sbin/lattelnet subset OSFLAT350
CHECKSUM: 33705 24 RCSfile: lattelnet.c RCS: 1.1.16.2
===============================================================================
This patch fixes a problem with assembler which was causing the following
error message while trying to assemble a valid program:
as1: Internal: filename, line ###: st_pdn_idn: idn (huge_integer)
less than 0 or greater than max (111)
PROBLEM: (QAR 43009, 41198) (Patch ID: OSF350-114)
********
Fix problem with assembler which was causing the following error
message while trying to assemble a valid program:
as1: Internal: filename, line ###: st_pdn_idn: idn (huge_integer)
less than 0 or greater than max (111)
This may be encountered by customers writing assembly language programs
which make use of the .edata directive.
Removal/replacement of the .edata directives can make this behavior
appear and disappear.
FILE(s):
/usr/ccs/lib/cmplrs/cc/as0 subset OSFCMPLRS350
CHECKSUM: 50428 488
===============================================================================
Card lockup problem using the ATM IP convergence module.
PROBLEM: (HPXQC2E60,QAR 42749) (Patch ID: OSF370-350115)
********
Card lockup problem using the ATM IP convergence module.
How to recognize the problem:
In the kern.log file you can see messages similar to:
Dec 19 11:06:47 bcaryf03 vmunix: received 144 bytes for non-existent VC 50
and if you have set up a simple test between two systems using a ping over
the ATM interface, you will see that the signalling between VC's which have
been sending and receiving throughout the test will suddenly stop receiving
packets. The VC's will continue to be able to send packets.
How to reproduce the problem:
Setup two nodes A and B connected through a FORE switch and an ATM IP
PVC between the two.
From node B, issue the ping command over ATM IP. (leave the ping command
running)
On node A, remove the ATM IP PVC which is receiving the ping using the command
"atmconfig -pvc driver=lta0 vpi=0 vci=50"
In the kern.log file you will see a message like:
Dec 19 11:06:47 bcaryf03 vmunix: received 144 bytes for non-existent VC 50
and the output of an atmconfig vclist long will show you that the signalling
between VC's sending and receiving throughout the test will suddenly stop
receiving packets.
FILE(s):
/usr/sys/BINARY/if_otto.o subset OSFATMBIN350
CHECKSUM: 30182 40 RCSfile: if_otto.c RCS: 1.1.19.2
===============================================================================
When using the command /usr/sbin/strace to get STREAMS event trace messages
from STREAMS drivers and modules via the STREAMS log driver (strlog), this
patch fixes a STRLOG bug which causes concatenation of sequential outputs.
PROBLEM: (QAR 38773) (Patch ID: OSF370-350130)
********
The strace command gets STREAMS event trace messages from STREAMS drivers
and modules via the STREAMS log driver (strlog). STRLOG had a bug that
caused concatenation of sequential outputs.
FILE(s):
/usr/sys/BINARY/log.o subset OSFBIN350
CHECKSUM: 09250 8 RCSfile: log.c RCS: 4.2.18.2
===============================================================================
When a user changes virtual memory (vm) tuning parameters due to slow
performance and reboots the machine, the system panics.
PROBLEM: (ISO100191,42778) (Patch ID: OSF370-350138)
********
When a user changes virtual memory (vm) tuning parameters due to slow
performance and reboots the machine, the system panics. This can occur when
setting vm tuning parameters to improve X Windows performance in systems under
heavy memory loads. This problem is commonly referred to as "window freeze"
and was first discovered on Alphastation 500/600's. Note, the problem is not
exclusive to 500/600's.
The following is an example of a system panic:
Digital UNIX boot - Tue Jan 30 21:31:11 EST 1996
Loading vmunix ...
Loading at fffffc0000230000
Current PAL Revision <0x1000000010111>
Switching to OSF PALcode Succeeded
New PAL Revision <0x1000000020115>
Sizes:
text = 4149488
data = 777600
bss = 2298896
Starting at 0xfffffc00004cb8f0
trap: invalid memory read access from kernel mode
faulting virtual address: 0x0000000000000040
pc of faulting instruction: 0xfffffc00004b2080
ra contents at time of fault: 0xfffffc00004b207c
sp contents at time of fault: 0xffffffffffff78c0
panic (cpu 0): kernel memory fault
DUMP: No primary swap, no explicit dumpdev.
Nowhere to put header, giving up.
halted CPU 0
halt code = 5
HALT instruction executed
PC = fffffc00004cd350
>>>
WORKAROUND:
Apply this patch and determine whether the vm tuning parameters should be
adjusted. The guidelines for changing vm tuning parameters are listed below.
VERIFICATION / VM TUNING PARAMETER ADJUSTMENTS:
The windowing system on AlphaStation 500/600's may experience poor window
response in a heavy paging environment. Although this problem occurs
on all platforms, it is most pronounced on AlphaStation 500/600's.
Mouse movement on the system is uneffected, but windowing operations such as
exposing a window, dragging a window, and so on, are degraded. When this
condition occurs, you may not be able to telnet or rlogin to the system. These
symptoms can occur for some period of time (greater than 2 minutes), or may
subside after a few seconds. The cause of these symptoms is due to a memory
intensive application(s) depleting the number of pages on the free list to an
absolute minimum. When this occurs, only privileged tasks are able to get
memory (for example, free pages) and all others tasks are blocked (in this
case the window manager).
Check to see if your system is experiencing this problem by running "vmstat 2"
in a separate xterm while your application(s) are running. Your system will
display output similar to the following:
#
vmstat 2
Virtual Memory Statistics: (pagesize = 8192)
procs memory pages intr cpu
r w u act free wire fault cow zero react pin pout in sy cs us sy id
2 37 15 5832 4021 1108 20K 5975 4575 285 4761 0 62 196 266 1 1 98
2 37 15 5851 4002 1108 99 13 50 0 8 0 4 13 239 0 1 99
3 37 15 7039 2788 1134 26 0 26 0 0 0 17 51 255 1 9 90
3 37 15 9791 10 1140 7291 17 7258 0 13 48 288 12 422 1 68 31
3 37 15 9790 9 1149 1049 0 1048 39 1 146 472 15 527 0 32 68
3 36 15 9784 9 1116 743 0 741 0 2 106 446 12 466 0 22 78
3 36 15 9811 9 1096 460 0 459 0 1 107 434 12 459 0 20 79
Note the amount of free pages available under the column "free". If this
number falls below the reserved amount (vm-page-free-reserved), your system
has hit this condition.
In the previous example, "vm-page-free-reserved" is set to its default value
of ten pages. The previous example shows that the VM subsystem has been
overwhelmed. If this is the case on your system, you will most likely
experience degraded window performance along with other performance
degradations. If the vmstat output on your system does not exhibit these
results (or similar ones), DO NOT tune your system per the recommendations
in this note.
GUIDELINES FOR CHANGING VM TUNING PARAMETERS:
1. Run "vmstat 2" to determine if vm tuning parameters should be changed.
(See previous section, "PROBLEM VERIFICATION").
2. Update the vm-page-free-target, vm-page-free-optimal, and vm-page-free-min
tuning parameters in the /etc/sysconfigtab file. If your system has less
than 128 MB of memory, try doubling from the default values until you reach
a happy medium between application performance and user interactivity. Note,
the default values are 128, 74, and 20, respectively. Refer to the "System
Tuning and Performance Management Manual" for more information on system
tuning. The following parameter values provide fairly good interactivity
with moderate performance degradation on a Alphastation 6000 with 128M of
physical memory:
vm:
vm-page-free-target=4096
vm-page-free-optimal=4096
vm-page-free-min=2048
The numbers provided in the previous example are designed to keep a larger
than normal number of pages on the free list (as a buffer) by starting to page
earlier than normal (via a larger vm-page-free-min) and by stopping paging
later than usual (via a larger vm-page-free-target). In addition, swapping
of tasks is enhanced to force the memory crunching task to be swapped out
occasionally (via a larger vm-page-free-optimal). You may find that your
system behaves fine with some manipulation of these parameters. Note
that these tuning parameters were devised to provide some level of user
interactivity in a heavy paging/swapping environment. They may not be the
best solution for your particular needs, but may provide a reasonable starting
place. Note, if your system does not have 128M of memory, pare down these
numbers. The units for these values are pages (which are 8KB) resulting in
some hefty chunks of memory (for example, 32MB). Again, try doubling the
default values until you reach some happy medium. You can check the default
values using dbx as follows:
# dbx -k /vmunix
(dbx) p vm_page_free_target
2048
(dbx) p vm_page_free_optimal
1029
(dbx) p vm_page_free_min
20
(dbx) p vm_page_free_reserved
10
3. Reboot the system.
4. Raise the priority of the window manager (mwm or dtwn).
a. Open a DECterm and kill the currently running manager. For example:
kill -9 pid
Note that the pid is the process ID of the window manager found using
the ps ax command.
b. Restart the window manager using the system utility "nice". For example:
nice -2 mwm &
or
nice -2 dtwm &
If the system is tuned correctly, what you should see happen is a small
latency when the memory intensive application starts which will balance as
the memory subsystem recovers. You should be able to expose
windows and drag them around, and so on. If you expose a window that
has not been used for some time, expect some latency. Remember, you are now
working in a heavy paging/swapping environment and those pages are not yet
available.
You will need to kill and restart the window manager each time you terminate
your X session. Remember, you will need to be a privileged user (for example,
root).
After performing the previous steps, you should see marked improvement in user
interactivity when the system experiences heavy memory loads.
FILE(s):
/usr/sys/BINARY/vm_pagelru.o subset OSFBIN370
CHECKSUM: 27175 77 RCSfile: vm_pagelru.c RCS: 1.1.63.2
===============================================================================
SUPERSEDES PATCHES: OSF370-350054 (90.00)
This patch corrects the following:
- "ufs_getapage: allocation failed" panic.
- Applications that continuously map and unmap large data files hang in
uninterruptable state.
PROBLEM: (uvo103444) (Patch ID: OSF370-350054)
********
The user's large data base application would hang in an uninterruptible state
after running for a while. The process could not be terminated by any user
action except to reboot the system.
The user's program was memory mapping large data files, and was continually
unmapping and remapping pages of the file. Eventually the process would hang
in an uninterruptible state when it tried to write to a part of the mapped file
that was swapped out.
Here is a typical stack trace of a thread hung in this condition:
thread_block
lock_read
ufs_getpage
u_vp_fault
vm_fault
trap
_XentMM
bcopy
uiomove
ufs_rwip
ufs_write
vn_write
rwuio
write
syscall
Running in lockmode=4 produced a panic with the message:
"lock_read: lock already owned by thread"
instead of a hung process.
PROBLEM: (Patch ID: OSF370-350139)
********
The system panics with "ufs_getapage: allocation failed" message.
A typical stack trace is as follows:
panic()
ufs_getapage()
ufs_getpage()
u_vp_fault()
u_map_fault()
vm_fault()
trap()
_XentMM()
FILE(s):
/usr/sys/BINARY/ufs_vnops.o subset OSFBIN350
CHECKSUM: 46211 133 RCSfile: ufs_vnops.c RCS: 4.2.118.3
===============================================================================
A call-share executable with a text, data or bss region greater than 4 gbytes,
the application will segment fault.
PROBLEM: (QAR 43033) (Patch ID: OSF370-350143)
********
A call-share executable with a text, data or bss region
greater than 4 gbyte application will segment fault.
As a work around you can build your application non-share.
This test demonstrates the problem:
csh> cat test.c
#define ARRAY_SIZE (1024*1024*512) - 1
long buf1[ARRAY_SIZE];
main()
{
printf("sizeof(buf1) = 0x%lx\n", sizeof(buf1));
buf1[1] = 42;
buf1[ARRAY_SIZE-2] = 169;
}
csh> cc test.c
csh>
csh> a.out
Segmentation fault (core dumped)
csh>
FILE(s):
/sbin/loader subset OSFBASE350
CHECKSUM: 18200 112
===============================================================================
Using Peer Server 1.3 ECO1 and token ring network interface(s), source routing
discovery is not working as expected. Additional interfaces will not
initialize and links between remote stations cannot be established.
PROBLEM: (MCPM26D74/QAR 43974) (Patch ID: OSF370-350144)
********
After installing and configuring Digital Peer Server version 1.3, EC01, token
ring source routing tables may not be built correctly. If you have multiple
token ring interfaces, additional interfaces will not initialize and links
between remote stations cannot be established.
How to recognize the problem:
Typical error messages will appear with multiple interfaces indicating
unreliable connections. You may observe console messages similar to the
following:
Event: Link Halted
from: Node 0:. LLC2 SAP sna-1 Link msamss-1
at : 1996-02-12-12:35:28.984-05:00I-----
Link Halted Reason = Implementation Specific
Check source routing module level:
"srconfig -rc" command displays several failures with no responses for
ARE packets. One may not notice these errors if source routing was
not enabled
Check at Applications level:
The applications like Peer server may not be able establish links with
remote SNA nodes. This can be verified with NCL command:
ncl> show sna cp serv t g * all
The above command displays status of the Transmission Groups as either
"Idle" or "On-connecting".
FILE(s):
/usr/sys/BINARY/trn_sr.o subset OSFHWBIN350
CHECKSUM: 02248 92 RCSfile: trn_sr.c RCS: 1.1.19.2
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances users may "gain unauthorized access" to the system. Digital
has corrected this potential vulnerability.
PROBLEM: (SSRT0376X) (Patch ID: OSF370-350152)
********
A potential security vulnerability has been discovered, where under certain
circumstances users may "gain unauthorized access" to the system. Digital
has corrected this potential vulnerability.
FILE(s):
/etc/sia/OSFC2_matrix.conf subset OSFC2SEC350
CHECKSUM: 51764 3 RCSfile: OSFC2_matrix.conf RCS: 1.1.17.2
===============================================================================
The mold daemon component of the Common Agent leaks memory when running with the
DEC SNA PeerServer product.
PROBLEM: (CFS.27284) (Patch ID: OSF370-350169)
********
The DEC SNA PeerServer product instantiates a new (protocol engine) daemon that
connects to the mold daemon component of the Common Agent each time an incoming
request is received by the DEC SNA PeerServer product from the network.
The PeerServer product can handle hundreds of requests per minute, each time
starting and then stopping its protocol engine daemon that connects to the mold
daemon. The mold daemon does not clean up the socket connection that gets
created each time the PeerServer creates a new connection to the mold, leaking
several thousand bytes of virtual memory per connection, plus leaves the socket
connection dangling.
Over time, the mold component can consume all available virtual memory, causing
unpredictable results and system performance degradation. Ultimately, the
customer is forced to stop and restart the PeerServer product, which is not
acceptable to the customer, as this process is very resource intensive and
can take many minutes to complete.
Errors may get logged in the /var/adm/syslog.dated//daemon.log file,
including messages similar to these (t21mcd and t21mad are DEC SNA PeerServer
daemon components; mold is a Common Agent daemon component):
t21mcd[1184]: Daemon process t21mad(1188)
terminated, signal=6
t21mcd[1184]:
Started daemon process t21mad (3617)
mold[324]: S011 - mold_*() call failed -
(MAN_C_OBJECT_ALREADY_EXISTS)
last message repeated 6 times
t21mcd[1184]: Daemon process t21mad(3617)
terminated, signal=6
t21mcd[1184]:
Started daemon process t21mad (3892)
mold[324]: S011 - mold_*() call failed -
(MAN_C_OBJECT_ALREADY_EXISTS)
last message repeated 6 times
t21mcd[1184]: Daemon process t21mad(3892)
terminated, signal=6
t21mcd[1184]: Started daemon process -
t21mad (3910)
mold[324]: S011 - mold_*() call failed -
(MAN_C_OBJECT_ALREADY_EXISTS)
etc., etc.
none.
FILE(s):
/usr/sbin/mold subset OSFCOMAGENT350
CHECKSUM: 36591 176 RCSfile: mold.c RCS: 1.1.2.8
dd RCSfile: mold_agent. RCS: 1.1.2.2
RCSfile: mold_mo.c RCS: 1.1.2.2
RCSfile: mold_msg_text.c RCS: 1.1.2.3
RCSfile: sck_mold_sstb.c RCS: 1.1.6.2
===============================================================================
This patch fixes a problem where the find command returns a invalid status
code upon encountering a file in an "ffm" set.
PROBLEM: (MCPM269A8) (Patch ID: OSF370-350176)
********
Fixes a problem where the find command returns a invalid status code upon
encountering a file in an "ffm" set.
The find command will return a code of 2 (EINVAL) upon encountering a file
in an "ffm" set, generally associated when System V environment is being used.
When this happens, the user's application receives an invalid status code;
the system does not crash or hang.
FILE(s):
/usr/sys/BINARY/ffm_vfsops.o subset OSFBIN350
CHECKSUM: 63529 12 RCSfile: ffm_vfsops.c RCS: 1.1.27.2
===============================================================================
After yppasswd has been run, NIS passwd dbm files will have read and write
permissions for other users.
PROBLEM: (HPAQB5F05) (Patch ID: OSF370-350185)
********
After yppasswd has been run, NIS passwd dbm files will have read and write
permissions for other users:
-rw-rw-rw- 1 root system 0 Nov 30 11:17 passwd.byname.dir
-rw-rw-rw- 1 root system 1024 Nov 30 11:17 passwd.byname.pag
-rw-rw-rw- 1 root system 0 Nov 30 11:17 passwd.byuid.dir
-rw-rw-rw- 1 root system 1024 Nov 30 11:17 passwd.byuid.pag
FILE(s):
/usr/sbin/rpc.yppasswdd subset OSFINET350
CHECKSUM: 01460 32 RCSfile: rpc.yppasswdd.c RCS: 4.2.15.2
===============================================================================
This patch resolves a problem with "strsetup -i -f" creating duplicate major
and minor numbers.
PROBLEM: (MCPM41A3D) (Patch ID: OSF370-350186)
********
After running "strsetup -i -f" /dev/streams/kinfo and /dev/streams/strkinfo
can have the same major and minor numbers. This causes "netsetup" to report
"ioctl: invalid argument" errors.
FILE(s):
/usr/sbin/strsetup subset OSFCLINET350
CHECKSUM: 12759 32 RCSfile: strsetup.c RCS: 4.2.29.2
===============================================================================
This patch adds support for file system ids ffm and nfsv3.
PROBLEM: ( MCPM4AD1A ) (Patch ID: OSF370-350190)
This patch adds support for file system ids ffm and nfsv3. Previous to this
patch, the sysfs system calls would give the following error message:
"sysfs: Function not implemented"
FILE(s):
/usr/sys/BINARY/kern_sysfs.o subset OSFBIN350
CHECKSUM: 63656 5 RCSfile: kern_sysfs.c RCS: 1.1.16.2
/usr/sys/include/sys/fsid.h subset OSFBINCOM350
CHECKSUM: 37787 3 RCSfile: fsid.h RCS: 1.1.8.2
===============================================================================
This patch resolves the condition that results when there is no default shell
in the password file causing rexecd to fail.
PROBLEM: (UVO103915) (Patch ID: OSF370-350191)
********
If a user uses chsh(1) to change their shell to /bin/sh then the shell
definition in the password file for that user is removed.
This is standard BSD behavior and the system defaults all such password entries
to /bin/sh at login time.
rexecd(8) however has a problem with accounts like this and fails to run
commands issued from programs using the rexec(3) library function.
FILE(s):
/usr/sbin/rexecd subset OSFCLINET350
CHECKSUM: 23848 24 RCSfile: rexecd.c RCS: 4.2.12.2
===============================================================================
This patch fixes a problem in which the rcp program fails when the file being
copied is greater than 2 Gigabytes in size. The error message from rcp is:
"connection closed".
PROBLEM: (QAR 36912, QAR 45643) (Patch ID: OSF370-350198)
********
This patch fixes a problem in which the rcp program fails when the file being
copied is greater than 2 Gigabytes in size. The error message from rcp is:
"connection closed".
FILE(s):
/usr/bin/rcp subset OSFCLINET350
CHECKSUM: 37159 32 RCSfile: rcp.c RCS: 4.2.20.2
===============================================================================
This patch fixes a problem in which the output from the df command displays
incorrectly formatted columns.
PROBLEM: (29818) (Patch ID: OSF370-350200-1)
********
This patch fixes a problem in which the output from the df command displays
incorrectly formatted columns.
The problem occurs because the number of inodes in Digital UNIX is quite large.
This causes the columns displayed by the df command to run together.
Run /usr/bin/df -i and examine the output.
FILE(s):
/usr/bin/df subset OSFBASE350
CHECKSUM: 63429 24 RCSfile: df.c RCS: 4.3.29.2
/sbin/df subset OSFBASE350
CHECKSUM: 58056 128 RCSfile: df.c RCS: 4.3.29.2
===============================================================================
SUPERSEDES PATCHES: OSF370-350062 (94.00), OSF370-350065 (95.00),
OSF370-350243 (188.00), OSF370-350244 (189.00),
OSF370-350244-1 (189.01)
This patch corrects the following:
- Fixes a problem on ASE systems where LSM volumes remain in SYNC state
when no volume resync or volplex att command is running.
This results in performance degradation.
- A problem in which an LSM configuration database becomes corrupted when it
grows beyond 128 KB. The LSM daemon displays an error message similar to
the following when it starts up: bad magic number
- A problem with vold not detaching a disk when the kernel fails a plex.
- A problem where vold core dumps in ASE. Happens when there is a SCSI
reservation conflict.
- Fixes several problems that occur during certain LSM operations involving
disklabel changes.
PROBLEM: (HPXQ943DC) (Patch ID: OSF370-350062)
********
A system using LSM, AdvFS, and ASE will crash with AdvFS I/O error
messages on the console when one volulme of a two-plex LSM mirrored
volume is failed out, then recovered, and the other plex is failed out.
PROBLEM: (QAR 36808) (Patch ID: OSF370-350065)
********
In systems where LSM is used with ASE, when there is a SCSI reservation
conflict, the LSM configuration daemon, vold, dumps core during an
ASE service start and stop.
PROBLEM: (QAR28740) (Patch ID: OSF370-350243)
********
When voldisk is used to init/define simple disks, the disklabel is modified
to add LSMsimp disklabel tag for the partition.
This is currently being done in vold. On failure to update the disklabel
vold does not return proper messages.
PROBLEM: (QAR31374) (Patch ID: OSF370-350243)
********
When a sliced LSM disk is removed from LSM, the disklabel is not updated
to show that LSM is no longer using the disk.
PROBLEM: (QAR42417) (Patch ID: OSF370-350243)
********
The voldisk command fails when attempting to 'init' a disk that has been
previously initialized but is no longer in use by LSM.
The voldisk command will update the disk label but will not add the disk
into LSM.
PROBLEM: (QAR 44567, QAR 46976) (Patch ID: OSF370-350244-1)
********
This patch fixes a problem in which an LSM configuration database
becomes corrupted when it grows beyond 128 KB.
The LSM daemon displays an error message similar to the following
when it starts up:
bad magic number
Attempting to create 1019 LSM volumes also corrupts the LSM configuration
database (since the size grows beyond 128KB).
Once the LSM configuration database is corrupted, it will have to be re-created.
PROBLEM: (QAR 39624) (Patch ID: OSF370-350213)
********
This patch fixes a problem on ASE systems where LSM volumes remain
in SYNC state when no volume resync or volplex att command is running.
This results in performance degradation.
The volprint command shows that the state of the volume is SYNC, as in:
# volprint -g oracledg -vl oracle
Volume: oracle
info: len=8379551
type: usetype=fsgen
state: state=SYNC kernel=ENABLED
assoc: plexes=oracle-01,oracle-02
policies: read=ROUND exceptions=GEN_DET_SPARSE
flags: open rwback (offset=0) writecopy writeback
logging: type=BLKNO loglen=1 serial=0/5 (enabled)
device: minor=8 bdev=40/8 cdev=40/8 path=/dev/vol/oracledg/oracle
perms: user=root group=system mode=0600
However, ps shows no volresync or volplex att command executing, as:
# ps -e -o command | egrep 'volume|volplex'
#
The problem can be reproduced with the following scenario:
1) Create a volume by giving the two plexes in the same volmake.
Thus the volume will contain the two plexes before it is started
2) Ensure the volume uses plexes having a log sub-disk, even if the
volume log_type is not using the log sub-disks.
3) Once the volume is started by the 'volume start' command,
abort the copy process by either:
a) Shutting down the system.
b) Deporting the disk group.
c) Killing the volume start process.
d) Restarting the ASE service utilizing that volume.
e) Relocating the ASE service utilizing that volume.
Now the volume will stay in SYNC state across reboots
and ASE restart and stop/start sequences.
FILE(s):
/sbin/gen/volume subset OSFLSMBASE350
CHECKSUM: 14718 264 RCSfile: comstart.c RCS: 1.1.8.3
/sbin/vold subset OSFLSMBASE370
CHECKSUM: 42693 584 RCSfile: dbcopy.c RCS: 1.1.13.2
/sbin/voldisk subset OSFLSMBASE350
CHECKSUM: 35986 328 RCSfile: syslog.c RCS: 4.2.18.4
===============================================================================
This patch corrects the problem where "ping -p ff" results in a segmentation
fault and core dump.
PROBLEM: (QAR-45312) (Patch ID: OSF370-350206)
********
"ping -p ff" results in a segmentation fault and core dump.
FILE(s):
/usr/sbin/ping subset OSFCLINET350
CHECKSUM: 64503 32 RCSfile: ping.c RCS: 4.2.23.2
===============================================================================
NIS slaveservers will not accept a push from the master server of a new map.
PROBLEM: (qar 46193) (Patch ID: OSF370-350210)
********
NIS slaveservers will not accept a push from the master server of a new map.
On the master server a push is generally done automatically when a map
is built (cd /var/yp; make
European Site
Files on this server are as follows:
duv32fas00003-19980714.README
duv32fas00003-19980714.CHKSUM
duv32fas00003-19980714.tar
duv32fas00003-19980714.ps
|
