|
|
 |
HP Services Software Patches - duv32de2as00004-19980311
|
Copyright (c) DIGITAL Equipment Corporation 1998. All rights reserved.
PRODUCT: DIGITAL UNIX [R] 3.2DE2
SOURCE: DIGITAL Equipment Corporation
ECO INFORMATION:
ECO Name: DUV32DE2AS00004-19980311
ECO Kit Approximate Size: 39MB
Kit Applies To: DIGITAL UNIX 3.2DE2
ECO KIT SUMMARY:
An update ECO kit exists for DIGITAL UNIX 3.2DE2. This is the aggregate,
setld-based, patch kit for DIGITAL UNIX 3.2DE2. 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.
SUPERSEDED PATCH LIST:
This patch kit supersedes the following DIGITAL UNIX patches:
DUV32DE2AS00003-19971029 ! Previous Aggregate Patch Kit
duv32de2ss0000200029100-19970624 ! Early release of Patch 291.00
KNOWN PROBLEMS WITH THE PATCH KIT:
None.
[R] UNIX is a registered trademark in the United States and other countries
licensed exclusively through X/Open Company Limited.
Copyright DIGITAL Equipment Corporation 1998. All Rights reserved.
This software is proprietary to and embodies the confidential technology
of DIGITAL Equipment Corporation. Possession, use, or copying of this
software and media is authorized only pursuant to a valid written license
from DIGITAL or an authorized sublicensor.
This ECO has not been through an exhaustive field test process.
Due to the experimental stage of this ECO/workaround, DIGITAL
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.
===============================================================================
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: OSF365-008)
********
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: 28835 8 RCSfile: ldbl_controller_support.c RCS: 1.1.14.3
/usr/sys/BINARY/pci.o subset OSFHWBIN365
CHECKSUM: 23435 29 RCSfile: pci.c RCS: 1.1.103.2
/usr/sys/BINARY/stanza_resolver.o subset OSFHWBIN350
CHECKSUM: 56519 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: OSF365-011)
********
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 OSFHWBIN365
CHECKSUM: 57663 16 RCSfile: ruby_common.c RCS: 1.1.27.2
---------------------
===============================================================================
Crash-dumps to non-re0 RAID devices broken on all PCI & EISA machines.
PROBLEM: (QAR 46654) (Patch ID: OSF365-025)
********
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 OSFHWBIN365
CHECKSUM: 52048 12 RCSfile: console.c RCS: 1.1.76.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: OSF365-030)
********
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 OSFHWBIN365
CHECKSUM: 12790 28 RCS: ace.c Revision: 1.1.80.2
===============================================================================
SUPERSEDES PATCHES: OSF365-006 (6.00), OSF365-024 (24.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: OSF365-006)
********
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: OSF365-024)
********
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: OSF365-039)
********
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 OSFHWBIN365
CHECKSUM: 48036 173 RCSfile: psiop.c RCS: 1.1.53.5
/usr/sys/BINARY/psiop_pci.o subset OSFHWBIN365
CHECKSUM: 43032 26 RCSfile: psiop_pci.c RCS: 1.1.39.3
/usr/sys/include/io/cam/siop/pci_scripthost.h subset OSFBINCOM365
CHECKSUM: 18806 16 RCSfile: pci_scripthost.h RCS: 1.1.36.2
===============================================================================
SUPERSEDES PATCHES: OSF365-023 (23.00)
This patch corrects the following:
- This patch fixes a Token Ring transmission timeout. The driver can experience
"ID 380PCI20001 (8/13/95)" as described in the TI380PCI Errata.
- The token ring driver, when storing the product_id, can cause corruption
which can result in a kernel read access panic.
PROBLEM: (UVO104380, HPAQ47704) (Patch ID: OSF365-023)
********
The corruption caused by the token ring driver can result in
an invalid memory read access from kernel mode panic.
The significant indicator is the faulting virtual address,
being repeated 'ef'. A representative example follows:
trap: invalid memory read access from kernel mode
faulting virtual address: 0xefefefefefeff28f
pc of faulting instruction: 0xfffffc00005675e4
ra contents at time of fault: 0xfffffc000056b54c
sp contents at time of fault: 0xffffffff87dc6a20
PROBLEM: (HPAL83FE3) (Patch ID: OSF365-042)
********
This patch fixes a Token Ring transmission timeout. The driver can experience
"ID 380PCI20001 (8/13/95)" as described in the TI380PCI Errata.
FILE(s):
/usr/sys/BINARY/if_tra.o subset OSFHWBIN365
CHECKSUM: 02692 66 RCSfile: if_tra.c RCS: 1.1.56.5
===============================================================================
SUPERSEDES PATCHES: OSF365-350104 (108.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: OSF365-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: OSF365-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 OSFBIN365
CHECKSUM: 27273 7 RCSfile: vm_cfg.c RCS: 1.1.31.2
/usr/sys/BINARY/vfs_ubc.o subset OSFBIN350
CHECKSUM: 38443 54 RCSfile: vfs_ubc.c RCS: 1.1.118.3
===============================================================================
SUPERSEDES PATCHES: OSF365-360003 (48.00), OSF365-360037 (68.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.
- Large memory growth of ucred structures can occur. This is especially
prevalent if a user is using setuid programs.
PROBLEM: (BRO100600) (Patch ID: OSF365-360003)
********
Large memory growth of ucred structures can occur. This is especially
prevalent if a user is using setuid programs.
PROBLEM: (QAR 33924) (Patch ID: OSF365-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: OSF365-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 OSFBIN365
CHECKSUM: 61827 42 RCS: nfs_vnodeops.c Revision: 1.1.104.7
/usr/sys/BINARY/nfs3_vnodeops.o subset OSFBIN365
CHECKSUM: 36031 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: OSF365-360062)
********
The ar command's -x option, which extracts archive files, may
in error, return a message stating that the 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 OSFBASE365
CHECKSUM: 44375 376 RCS: ar.c Revision: 4.2.33.2
===============================================================================
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: OSF365-360064)
********
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 RCS:
/usr/lib/nls/msg/en_US.ISO8859-1/quota.cat subset OSFBASE350
CHECKSUM: 60092 1 RCS:
/usr/sbin/edquota subset OSFBASE365
CHECKSUM: 05679 112 RCS: edquota.c Revision: 4.2.29.2
/usr/sbin/quota subset OSFBASE365
CHECKSUM: 17675 112 RCS: quota.c Revision: 4.2.39.2
rquotaxdr.c Revision: 4.2.4.2
/usr/sbin/vedquota subset OSFADVFS365
CHECKSUM: 41580 576 RCS: vedquota.c Revision: 1.1.28.2
/usr/sbin/vquota subset OSFADVFS365
CHECKSUM: 08099 504 RCS: vquota.c Revision: 1.1.25.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: OSF365-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: 30097 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: OSF365-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: 43516 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
===============================================================================
Fixes "timeout table overflow" panic on multiprocessor system.
PROBLEM: (QAR 39990) (Patch ID: OSF365-350079)
********
Fixes "timeout table overflow" panic on multiprocessor system.
FILE(s):
/usr/sys/BINARY/lwc.o subset OSFBIN350
CHECKSUM: 28630 6 RCSfile: lwc.c RCS: 1.1.22.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: OSF365-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: 30385 32 RCSfile: tftpd.c RCS: 4.2.11.2
---------------------
===============================================================================
Fix acctcms hash table overflow error.
PROBLEM: (TKTQ22355) (Patch ID: OSF365-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: 21117 32 RCSfile: acctcms.c RCS: 4.2.18.2
---------------------
===============================================================================
Program translated with FreePort Express (SunOS --> Digital UNIX)
binary translator does not run correctly.
PROBLEM: (QAR 39134) (Patch ID: OSF365-350097)
********
Program translated with FreePort Express (SunOS --> Digital UNIX)
binary translator does not run correctly.
The problem is due to calls to mmap() specifying /dev/zero.
The address returned was other than the address (hint) provided.
Compile and run the following program to verify the problem exists:
#include
#include
#include
#include
main(argc, argv)
int argc;
char **argv;
{
int fd;
char *addr;
if((fd = open("/dev/zero", O_RDWR)) == -1) {
perror("mmap: open");
exit(1);
}
if((addr = mmap(0x20000000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE, fd, 0L)) == (void *)-1) {
perror("mmap: mmap");
exit(1);
}
close(fd);
if (addr == (char *)0x20000000)
printf("SUCCESS\n");
else
printf("FAILURE: mapped /dev/zero at address 0x%lx\n", addr);
exit(0);
}
FILE(s):
/usr/sys/BINARY/devz.o subset OSFBIN350
CHECKSUM: 35943 6 RCSfile: devz.c RCS: 1.1.10.2
---------------------
===============================================================================
Program using libexc.a suffer corrupted signal masks.
PROBLEM: (EVT101544) (Patch ID: OSF365-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: 12745 23
---------------------
===============================================================================
Correct nfs server duplicate request problem, by adding timestamps.
PROBLEM: (MGO101612) (Patch ID: OSF365-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.
You need this patch 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 this problem.
FILE(s):
/usr/sys/BINARY/svc_kudp.o subset OSFBIN350
CHECKSUM: 55255 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: OSF365-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: 20697 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: OSF365-350112)
********
Users could use lattelnet to invoke a subshell, a potential security issue in
some installations.
FILE(s):
/usr/sbin/lattelnet subset OSFLAT350
CHECKSUM: 22781 24 RCSfile: lattelnet.c RCS: 1.1.16.2
---------------------
===============================================================================
Card lockup problem using the ATM IP convergence module.
PROBLEM: (HPXQC2E60,QAR 42749) (Patch ID: OSF365-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: 30053 40 RCSfile: if_otto.c RCS: 1.1.19.2
===============================================================================
The system panics with kernel memory fault, and the fault_pc is in the
u_anon_free() routine.
PROBLEM: (43968) (Patch ID: OSF365-350136)
********
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 OSFBIN365
CHECKSUM: 16520 73 RCS: vm_anon.c Revision: 1.1.36.2
===============================================================================
SUPERSEDES PATCHES: OSF365-350054 (93.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: OSF365-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: OSF365-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: 36046 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: OSF365-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: 56855 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: OSF365-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: 59360 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: OSF365-350152)
********
A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access to the system.
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: (IPMT Case CFS.27284) (Patch ID: OSF365-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.
FILE(s):
/usr/sbin/mold subset OSFCOMAGENT350
CHECKSUM: 19886 176 RCSfile: sck_mold_sstb.c RCS: 1.1.6.2
RCSfile: socket.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: OSF365-350176)
********
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: 44792 12 RCS: ffm_vfsops.c Revision: 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: OSF365-350185-1)
********
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: 60219 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: OSF365-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: 28582 32 RCSfile: strsetup.c RCS: 4.2.29.2
===============================================================================
This patch adds support for file system ids ffm and nfsv3.
PROBLEM: (MCPM4AD1A) (Patch ID: OSF365-350190)
********
This patch adds support for file system ids ffm and nfsv3.
Previous to this patch, the sysfs system call would give
the following error message:
"sysfs: Function not implemented"
FILE(s):
/usr/sys/BINARY/kern_sysfs.o subset OSFBIN350
CHECKSUM: 13517 5 RCS: kern_sysfs.c Revision: 1.1.16.2
/usr/sys/include/sys/fsid.h subset OSFBINCOM350
CHECKSUM: 38534 3 RCS: fsid.h Revision: 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: OSF365-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: 39000 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: OSF365-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: 48003 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: OSF365-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):
/sbin/df subset OSFBASE350
CHECKSUM: 58038 128 RCSfile: df.c RCS: 4.3.29.2
/usr/bin/df subset OSFBASE350
CHECKSUM: 33081 24 RCSfile: df.c RCS: 4.3.29.2
===============================================================================
This patch corrects the problem where "ping -p ff" results in a segmentation
fault and core dump.
PROBLEM: (QAR-45312) (Patch ID: OSF365-350206)
********
"ping -p ff" results in a segmentation fault and core dump.
FILE(s):
/usr/sbin/ping subset OSFCLINET350
CHECKSUM: 53783 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: OSF365-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 |
